Systems, methods, and apparatus for enhanced presentation remotes

The present application is a Non-Provisional of, and claims benefit and priority to U.S. Provisional Patent Application No. 63/033,195, titled “SYSTEMS, METHODS, AND APPARATUS FOR ENHANCED PRESENTATION REMOTES”, and filed Jun. 1, 2020 in the name of Jorasch et al., the entirety of which is hereby incorporated by reference herein for all purposes.

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

People use presentation remote devices for purposes of navigating content in meetings and pointing to content on a screen with a laser pointer.

Various embodiments include an integration of data from many sources, and enable intelligent processing of that data such that many elements of the system can be optimized and enhanced. Various embodiments enhance meeting presentations, content control, video calls, educational communications, and/or game experiences by improving interactions of people through the collection and output of images, video and sensor data from presentation remotes and/or peripherals. Various embodiments allow for improved control of presentation content, and/or enhanced engagement of presentation participants.

An understanding of embodiments described herein and many of the attendant advantages thereof may be readily obtained by reference to the following detailed description when considered with the accompanying drawings, wherein:

FIG. 1 is a block diagram of a system consistent with at least some embodiments described herein;

FIG. 2 is a block diagram of a resource device consistent with at least some embodiments described herein;

FIG. 3 is a block diagram of a user device consistent with at least some embodiments described herein;

FIG. 4 is a block diagram of a peripheral device consistent with at least some embodiments described herein;

FIG. 5 is a block diagram of a third-party device consistent with at least some embodiments described herein;

FIG. 6 is a block diagram of a central controller consistent with at least some embodiments described herein;

FIGS. 7 through 29 are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIGS. 30A and 30B are diagrams of a process flow consistent with at least some embodiments described herein

FIGS. 31 through 37 are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIG. 38 is a computer mouse consistent with at least some embodiments described herein;

FIG. 39 is a computer keyboard consistent with at least some embodiments described herein;

FIG. 40 is a headset consistent with at least some embodiments described herein;

FIG. 41 depicts a presentation remote unit consistent with at least some embodiments described herein;

FIG. 42 is a camera consistent with at least some embodiments described herein;

FIG. 43 is a headset with motion sensor consistent with at least some embodiments described herein;

FIG. 44 is a mousepad consistent with at least some embodiments described herein;

FIG. 45 is a conference table consistent with at least some embodiments described herein;

FIG. 46 is a living room consistent with at least some embodiments described herein;

FIG. 47 is a screen from an app for configuring a presentation remote consistent with at least some embodiments described herein;

FIG. 48 is a screen from an app for configuring a presentation remote consistent with at least some embodiments described herein;

FIG. 49 is a plot of a derived machine learning model consistent with at least some embodiments described herein;

FIGS. 50 through 53 are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIGS. 54A and 54B are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIGS. 55 through 62 are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIG. 63 is a block diagram of a system consistent with at least some embodiments described herein;

FIGS. 64A and 64B are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIGS. 65 through 66 are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIG. 67 is a user interface of an example user device consistent with at least some embodiments described herein;

FIG. 68 is a map of a campus with buildings consistent with at least some embodiments described herein;

FIG. 69 is a block diagram of a peripheral consistent with at least some embodiments described herein;

FIG. 70 is block diagram of an example data storage structure consistent with at least some embodiments described herein;

FIG. 71A , FIG. 71B , FIG. 71C , FIG. 71D , and FIG. 71E are perspective diagrams of exemplary data storage devices consistent with at least some embodiments described herein;

FIG. 72 is an illustration of an individual with biometric information consistent with at least some embodiments described herein;

FIG. 73A , FIG. 73B , and FIG. 73C are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIGS. 74 through 78 are block diagrams of example data storage structures consistent with at least some embodiments described herein;

FIG. 79A , FIG. 79B , and FIG. 79C , together show a diagram of a process flow consistent with at least some embodiments described herein;

FIG. 80 is a block diagram of a peripheral (presentation remote) consistent with at least some embodiments described herein;

FIG. 81 is a block diagram of a system consistent with at least some embodiments described herein;

FIG. 82A and FIG. 82B together show a diagram of a process flow consistent with at least some embodiments described herein;

FIG. 83 is a block diagram of a system consistent with at least some embodiments described herein;

FIG. 84 is a diagram of a process flow consistent with at least some embodiments described herein;

FIG. 85 is a user interface for a virtual meeting consistent with at least some embodiments described herein;

FIG. 86A , FIG. 86B , and FIG. 86C , together show a diagram of a process flow consistent with at least some embodiments described herein;

FIGS. 87 through 89 are block diagrams of example data storage structures consistent with at least some embodiments described herein; and

FIG. 90 is a diagram of a process flow consistent with at least some embodiments described herein.

Embodiments described herein are descriptive of systems, apparatus, methods, interfaces, and articles of manufacture for utilizing devices and/or for managing meetings.

Headings, section headings, and the like are used herein for convenience and/or to comply with drafting traditions or requirements. However, headings are not intended to be limiting in any way. Subject matter described within a section may encompass areas that fall outside of or beyond what might be suggested by a section heading; nevertheless, such subject matter is not to be limited in any way by the wording of the heading, nor by the presence of the heading. For example, if a heading says “Mouse Outputs”, then outputs described in the following section may apply not only to computer mice, but to other peripheral devices as well.

As used herein, a “user” may include a human being, set of human beings, group of human beings, an organization, company, legal entity, or the like. A user may be a contributor to, beneficiary of, agent of, and/or party to embodiments described herein. For example, in some embodiments, a users actions may result in the user receiving a benefit.

In various embodiments, the term “user” may be used interchangeably with “employee”, “attendee”, or other party to which embodiments are directed.

A user may own, operate, or otherwise be associated with a computing device, such as a personal computer, desktop, Apple® Macintosh®, or the like, and such device may be referred to herein as “user device”. A user device may be associated with one or more additional devices. Such additional devices may have specialized functionality, such as for receiving inputs or providing outputs to users. Such devices may include computer mice, keyboards, headsets, microphones, cameras, and so on, and such devices may be referred to herein as “peripheral devices”. In various embodiments, a peripheral device may exist even if it is not associated with any particular user device. In various embodiments, a peripheral device may exist even if it is not associated with any particular other device.

As used herein, a “skin” may refer to an appearance of an outward-facing surface of a device, such as a peripheral device. The surface may include one or more active elements, such as lights, LEDs, display screens, electronic ink, e-skin, or any other active elements. In any case, the surface may be capable of changing its appearance, such as by changing its color, changing its brightness, changing a displayed image, or making any other change. When the outward service of a device changes its appearance, the entire device may appear to change its appearance. In such cases, it may be said that the device has taken on a new “skin”.

As used herein, pronouns are not intended to be gender-specific unless otherwise specified or implied by context. For example, the pronouns “he”, “his”, “she”, and “her” may refer to either a male or a female.

As used herein, a “mouse-keyboard” refers to a mouse and/or a keyboard, and may include a device that has the functionality of mouse, a device that has the functionality of a keyboard, a device that has some functionality of a mouse and some functionality Of a keyboard and/or a device that has the functionality of both a mouse and a keyboard.

Systems

Referring first to FIG. 1 , a block diagram of a system 100 according to some embodiments is shown. In some embodiments, the system 100 may comprise a plurality of resource devices 102 a - n in communication via or with a network 104 . According to some embodiments, system 100 may comprise a plurality of user devices 106 a - n , a plurality of peripheral devices 107 a - n and 107 p - z , third-party device 108 , and/or a central controller 110 , In various embodiments, any or all of devices 106 c - n , 107 a , 107 p - z , may be in communication with the network 104 and/or with one another via the network 104 .

Various components of system 100 may communicate with one another via one or more networks (e.g., via network 104 ). Such networks may comprise, for example, a mobile network such as a cellular, satellite, or pager network, the Internet, a wide area network, a Wi-Fi® network, another network, or a combination of such networks. For example, in one embodiment, both a wireless cellular network and a Wi-Fi® network may be involved in routing communications and/or transmitting data among two or more devices or components. The communication between any of the components of system 100 (or of any other system described herein) may take place over one or more of the following: the Internet, wireless data networks, such as 802.11 Wi-Fi®, PSTN interfaces, cable modem DOCSIS data networks, or mobile phone data networks commonly referred to as 3G, LTE, LTE-advanced, etc.

In some embodiments, additional devices or components that are not shown in FIG. 1 may be part of a system for facilitating embodiments as described herein. For example, one or more servers operable to serve as wireless network gateways or routers may be part of such a system. In other embodiments, some of the functionality described herein as being performed by system 100 may instead or in addition be performed by a third party server operating on behalf of the system 100 (e.g., the central controller 110 may outsource some functionality, such as registration of new game players). Thus, a third party server may be a part of a system such as that illustrated in FIG. 1 .

It should be understood that any of the functionality described herein as being performed by a particular component of the system 100 may in some embodiments be performed by another component of the system 100 and/or such a third party server. For example, one or more of the functions or processes described herein as being performed by the central controller 110 (e.g., by a module or software application of the central controller) or another component of system 100 may be implemented with the use of one or more cloud-based servers which, in one embodiment, may be operated by or with the help of a third party distinct from the central controller 110 . In other words, while in some embodiments the system 100 may be implemented on servers that are maintained by or on behalf of central controller 110 , in other embodiments it may at least partially be implemented using other arrangements, such as in a cloud-computing environment, for example.

In various embodiments, peripheral devices 107 b and 107 c may be in communication with user device 106 b , such as by wired connection (e.g., via USB cable), via wireless connection (e.g., via Bluetooth®) or via any other connection means. In various embodiments, peripheral devices 107 b and 107 c may be in communication with one another via user device 106 b (e.g., using device 106 b as an intermediary). In various embodiments, peripheral device 107 d may be in communication with peripheral device 107 c , such as by wired, wireless, or any other connection means. Peripheral device 107 d may be in communication with peripheral device 107 b via peripheral device 107 c and user device 106 b (e.g., using devices 107 c and 106 b as intermediaries). In various embodiments, peripheral devices 107 b and/or 107 c may be in communication with network 104 via user device 106 b (e.g., using device 106 b as an intermediary). Peripheral devices 107 b and/or 107 c may thereby communicate with other devices (e.g., peripheral device 107 p or central controller 110 ) via the network 104 . Similarly, peripheral device 107 d may be in communication with network 104 via peripheral device 107 c and user device 106 b (e.g., by using both 107 c and 106 b as intermediaries). In various embodiments, peripheral device 107 d may thereby communicate with other devices via the network 104 .

In various embodiments, local network 109 is in communication with network 104 . Local network 109 may be, for example, a Local Area Network (LAN), Wi-Fi® network, Ethernet-based network, home network, school network, office network, business network, or any other network. User device 106 a and peripheral devices 107 e - n may each be in communication with local network 109 . Devices 106 a and 107 e - n may communicate with one another via local network 109 . In various embodiments, one or more of devices 106 a and 107 e - n may communicate with other devices (e.g., peripheral device 107 p or central controller 110 ) via both the local network 109 network 104 . It will be appreciated that the depicted devices 106 a and 107 e - n are illustrative of some embodiments, and that various embodiments contemplate more or fewer user devices and/or more or fewer peripheral devices in communication with local network 109 .

It will be appreciated that various embodiments contemplate more or fewer user devices than the depicted user devices 106 a - n . Various embodiments contemplate fewer or more local networks, such as local network 109 . In various embodiments, each local network may be in communication with a respective number of user devices and/or peripherals. Various embodiments contemplate more or fewer peripheral devices than the depicted peripheral devices 107 a - n and 107 p - z . Various embodiments contemplate more or fewer resource devices than the depicted resource devices 102 a - n . Various embodiments contemplate more or fewer third-party devices than the depicted third-party device 108 . In a similar vein, it will be understood that ranges of reference numerals, such as “ 102 a - n ”, do not imply that there is exactly one such device corresponding to each alphabet letter in the range (e.g., in the range “a-n”). Indeed, there may be more or fewer such devices than the number of alphabet letters in the indicated range.

In various embodiments, resource devices 102 a - n may include devices that store data and/or provide one or more services used in various embodiments. Resource devices 102 a - n may be separate from the central controller 110 . For example, a resource device may belong to a separate entity to that of the central controller. In various embodiments, one or more resource devices are part of the central controller, have common ownership with the central controller, or are otherwise related to the central control. In various embodiments, resource devices 102 a - n may include one or more databases, cloud computing and storage services, calling platforms, video conferencing platforms, streaming services, voice over IP services, authenticating services, certificate services, cryptographic services, anonymization services, biometric analysis services, transaction processing services, financial transaction processing services, digital currency transaction services, file storage services, document storage services, translation services, transcription services, providers of imagery, image/video processing services, providers of satellite imagery, libraries for digital videos, libraries for digital music, library for digital lectures, libraries for educational content, libraries for digital content, providers of shared workspaces, providers of collaborative workspaces, online gaming platforms, game servers, advertisement aggregation services, advertisement distribution services, facilitators of online meetings, email servers, messaging platforms, Wiki hosts, website hosts, providers of software, providers of software-as-a-service, providers of data, providers of user data, and/or any other data storage device and/or any other service provider.

For example, a resource device (e.g., device 102 a ), may assist the central controller 110 in authenticating a user every time the user logs into a video game platform associated with the central controller. As another example, a resource device may store digital music files that are downloaded to a user device as a reward for the user's performance in a video game associated with the central controller. As another example, a resource device may provide architectural design software for use by users designing a building in a shared workspace associated with the central controller. According to some embodiments, communications between and/or within the devices 102 a - n , 106 a - n , 107 a - n and 107 p - z , 108 , and 110 of the system 100 may be utilized to (i) conduct a multiplayer game, (ii) conduct a meeting, (iii) facilitate a collaborative project, (iv) distribute advertisements, (v) provide teaching, (vi) provide evaluations and ratings or individuals or teams, (vii) facilitate video conferencing services, (viii) enhance educational experiences, and/or for any other purpose.

Fewer or more components 102 a - n , 104 , 106 a - n , 107 a - n , 107 p - z , 108 , 110 and/or various configurations of the depicted components 102 a - n , 104 , 106 a - n , 107 a - n , 107 p - z , 108 , 110 may be included in the system 100 without deviating from the scope of embodiments described herein. In some embodiments, the components 102 a - n , 104 , 106 a - n , 107 a - n , 107 p - z , 108 , 110 may be similar in configuration and/or functionality to similarly named and/or numbered components as described herein. In some embodiments, the system 100 (and/or portion thereof) may comprise a platform programmed and/or otherwise configured to execute, conduct, and/or facilitate the methods (e.g., 3000 of FIG. 30 ; 7900 of FIGS. 79A-C ; 8400 of FIG. 84 ; 8600 of FIGS. 86A-C ; 9000 of FIG. 90 ) herein, and/or portions thereof.

According to some embodiments, the resource devices 102 a - n and/or the user devices 106 a - n may comprise any type or configuration of computing, mobile electronic, network, user, and/or communication devices that are or become known or practicable. The resource devices 102 a - n and/or the user devices 106 a - n may, for example, comprise one or more Personal Computer (PC) devices, computer workstations, server computers, cloud computing resources, video gaming devices, tablet computers, such as an iPad® manufactured by Apple®, Inc. of Cupertino, Calif., and/or cellular and/or wireless telephones, such as an iPhone® (also manufactured by Apple®, Inc.) or an LG V50 THINQ™ 5G smart phone manufactured by LG® Electronics, Inc. of San Diego, Calif., and running the Android® operating system from Google®, Inc. of Mountain View, Calif. In some embodiments, the resource devices 102 a - n and/or the user devices 106 a - n may comprise one or more devices owned and/or operated by one or more users (not shown), such as a Sony PlayStation® 5, and/or users/account holders (or potential users/account holders). According to some embodiments, the resource devices 102 a - n and/or the user devices 106 a - n may communicate with the central controller 110 either directly or via the network 104 as described herein.

According to some embodiments, the peripheral devices 107 a - n , 107 p - z may comprise any type or configuration of computing, mobile electronic, network, user, and/or communication devices that are or become known or practicable. The peripheral devices 107 a - n , 107 p - z may, for example, comprise one or more of computer mice, computer keyboards, headsets, cameras, touchpads, joysticks, game controllers, watches (e.g., smart watches), microphones, etc. In various embodiments, peripheral devices may comprise one or more of Personal Computer (PC) devices, computer workstations, video game consoles, tablet computers, laptops, and the like. The network 104 may, according to some embodiments, comprise a Local Area Network (LAN; wireless and/or wired), cellular telephone, Bluetooth®, Near Field Communication (NFC), and/or Radio Frequency (RF) network with communication links between the central controller 110 , the resource devices 102 a - n , the user devices 106 a - n , and/or the third-party device 108 . In some embodiments, the network 104 may comprise direct communication links between any or all of the components 102 a - n , 104 , 106 a - n , 107 a - n , 107 p - z , 108 , 110 of the system 100 . The resource devices 102 a - n may, for example, be directly interfaced or connected to one or more of the central controller 110 , the user devices 106 a - n , the peripheral devices 107 a - n , 107 p - z and/or the third-party device 108 via one or more wires, cables, wireless links, and/or other network components, such network components (e.g., communication links) comprising portions of the network 104 . In some embodiments, the network 104 may comprise one or many other links or network components other than those depicted in FIG. 1 . The central controller 110 may, for example, be connected to the resource devices 102 a - n via various cell towers, routers, repeaters, ports, switches, and/or other network components that comprise the Internet and/or a cellular telephone (and/or Public Switched Telephone Network (PSTN) network, and which comprise portions of the network 104 .

While the network 104 is depicted in FIG. 1 as a single object, the network 104 may comprise any number, type, and/or configuration of networks that is or becomes known or practicable. According to some embodiments, the network 104 may comprise a conglomeration of different sub-networks and/or network components interconnected, directly or indirectly, by the components 102 a - n , 104 , 106 b - n , 107 a , 107 p - z , 108 , 109 , 110 of the system 100 . The network 104 may comprise one or more cellular telephone networks with communication links between the user devices 106 b - n and the central controller 110 , for example, and/or may comprise an NFC or other short-range wireless communication path, with communication links between the resource devices 102 a - n and the user devices 106 b - n , for example.

According to some embodiments, the third-party device 108 may comprise any type or configuration of a computerized processing device, such as a PC, laptop computer, computer server, database system, and/or other electronic device, devices, or any combination thereof. In some embodiments, the third-party device 108 may be owned and/or operated by a third-party (i.e., an entity different than any entity owning and/or operating either the resource devices 102 a - n , the user devices 106 a - n , the peripheral devices 107 a - n and 107 p - z , or the central controller 110 ; such as a business customer or client of the central controller). The third-party device 108 may, for example, comprise an advertiser that provides digital advertisements for incorporation by the central controller 110 into a multiplayer video game, and which pays the central controller to do this. The third-party device 108 may, as another example, comprise a streaming channel that purchases footage of video games from the central controller.

According to some embodiments, the third-party device 108 may comprise a plurality of devices and/or may be associated with a plurality of third-party entities. In some embodiments, the third-party device 108 may comprise the memory device (or a portion thereof), such as in the case the third-party device 108 comprises a third-party data storage service, device, and/or system, such as the Amazon® Simple Storage Service (Amazon® S3™) available from Amazon®.com, Inc. of Seattle, Wash. or an open-source third-party database service, such as MongoDB™ available from MongoDB, Inc. of New York, N.Y. In some embodiments, the central controller 110 may comprise an electronic and/or computerized controller device, such as a computer server and/or server cluster communicatively coupled to interface with the resource devices 102 a - n and/or the user devices 106 a - n , and/or the peripheral devices 107 a - n and 107 p - z , and/or local network 109 (directly and/or indirectly). The central controller 110 may, for example, comprise one or more PowerEdge™ M910 blade servers manufactured by Dell®, Inc. of Round Rock, Tex., which may include one or more Eight-Core Intel® Xeon® 7500 Series electronic processing devices. According to some embodiments, the central controller 110 may be located remotely from one or more of the resource devices 102 a - n and/or the user devices 106 a - n and/or the peripheral devices 107 a - n and 107 p - z . The central controller 110 may also or alternatively comprise a plurality of electronic processing devices located at one or more various sites and/or locations (e.g., a distributed computing and/or processing network).

According to some embodiments, the central controller 110 may store and/or execute specially programmed instructions (not separately shown in FIG. 1 ) to operate in accordance with embodiments described herein. The central controller 110 may, for example, execute one or more programs, modules, and/or routines (e.g., AI code and/or logic) that facilitate the analysis of meetings (e.g., contributors to the emissions of a meeting; e.g., of contributors to the performance of a meeting), as described herein. According to some embodiments, the central controller 110 may execute stored instructions, logic, and/or software modules to (i) determine meeting configurations consistent with requirements for a meeting, (ii) determine emissions associated with heating a room, (iii) determine emissions associated with a meeting, (iv) determine a route for a participant to take on his way to a meeting, (v) conduct an online game, (vi) facilitate messaging to and between peripheral devices, (vii) determine alterations to a room that may enhance meeting productivity, (ix) provide an interface via which a resource and/or a customer (or other user) may view and/or manage meetings, and/or (x) perform any other task or tasks, as described herein.

In some embodiments, the resource devices 102 a - n , the user devices 106 a - n , the third-party device 108 , the peripheral devices 107 a - n and 107 p - z and/or the central controller 110 may be in communication with and/or comprise a memory device (not shown). The memory device may comprise, for example, various databases and/or data storage mediums that may store, for example, user information, meeting information, cryptographic keys and/or data, login and/or identity credentials, and/or instructions that cause various devices (e.g., the central controller 110 , the third-party device 108 , resource devices 102 a - n , the user devices 106 a - n , the peripheral devices 107 a - n and 107 p - z ) to operate in accordance with embodiments described herein.

The memory device may store, for example, various AI code and/or mobile device applications and/or interface generation instructions, each of which may, when executed, participate in and/or cause meeting enhancements, improvements to meeting performance, reductions in emissions associated with meeting, enhancements to online gameplay, or any other result or outcome as described herein. In some embodiments, the memory device may comprise any type, configuration, and/or quantity of data storage devices that are or become known or practicable. The memory device may, for example, comprise an array of optical and/or solid-state hard drives configured to store predictive models (e.g., analysis formulas and/or mathematical models and/or models for predicting emissions), credentialing instructions and/or keys, and/or various operating instructions, drivers, etc. In some embodiments, the memory device may comprise a solid-state and/or non-volatile memory card (e.g., a Secure Digital (SD) card such as an SD Standard-Capacity (SDSC), an SD High-Capacity (SDHC), and/or an SD eXtended-Capacity (SDXC)) and any various practicable form-factors, such as original, mini, and micro sizes, such as are available from Western Digital Corporation of San Jose, Calif. In various embodiments, the memory device may be a stand-alone component of the central controller 110 . In various embodiments, the memory device 140 may comprise multiple components. In some embodiments, a multi-component memory device may be distributed across various devices and/or may comprise remotely dispersed components. Any or all of the resource devices 102 a - n , the user devices 106 a - n , the peripheral devices 107 a - n and 107 p - z , the third-party device 108 , and/or the central controller 110 may comprise the memory device or a portion thereof, for example.

Resource Devices

Turning now to FIG. 2 , a block diagram of a resource device 102 a according to some embodiments is shown. Although FIG. 2 depicts resource device 102 a , it will be appreciated that other resource devices (e.g., resource devices 102 b - n , may have similar constructions). In various embodiments, different resource devices may have different constructions. With reference to FIG. 2 (and to any other figures depicting software, software modules, processors, computer programs, and the like), it should be understood that any of the software module(s) or computer programs illustrated therein may be part of a single program or integrated into various programs for controlling processor 205 (or the processor depicted in the relevant figure). Further, any of the software module(s) or computer programs illustrated therein may be stored in a compressed, uncompiled, and/or encrypted format and include instructions which, when performed by the processor, cause the processor to operate in accordance with at least some of the methods described herein. Of course, additional and/or different software module(s) or computer programs may be included and it should be understood that the example software module(s) illustrated and described with respect to FIG. 2 (or to any other relevant figure) are not necessary in any embodiments. Use of the term “module” is not intended to imply that the functionality described with reference thereto is embodied as a stand-alone or independently functioning program or application. While in some embodiments functionality described with respect to a particular module may be independently functioning, in other embodiments such functionality is described with reference to a particular module for ease or convenience of description only and such functionality may in fact be a part of integrated into another module, program, application, or set of instructions for directing a processor of a computing device.

According to an embodiment, the instructions of any or all of the software module(s) or programs described with respect to FIG. 2 (or to any other pertinent figure) may be read into a main memory from another computer-readable medium, such from a ROM to RAM. Execution of sequences of the instructions in the software module(s) or programs causes processor 205 (or other applicable processor) to perform at least some of the process steps described herein. In alternate embodiments, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of the embodiments described herein. Thus, the embodiments described herein are not limited to any specific combination of hardware and software. In various embodiments, resource device 102 a comprises a processor 205 . Processor 205 may be any suitable processor, logic chip, neural chip, controller, or the like, and may include any component capable of executing instructions (e.g., computer instructions, e.g., digital instructions). Commercially available examples include the Apple® eight-core M1 chip with Neural Engine, AMD® Ryzen™ Threadripper 3990x with 64 cores, and the Intel eight-core Core i9-11900K chip.

In various embodiments, processor 205 is in communication with a network port 210 and a data storage device 215 . Network port 210 may include any means for resource device 102 a to connect to and/or communicate over a network. Network port 210 may include any means for resource device 102 a to connect to and/or communicate with another device (e.g., with another electronic device). For example, network port 210 may include a network interface controller, network interface adapter, LAN adapter, or the like. Network port 210 may include a transmitter, receiver, and/or transceiver. Network port 210 may be capable of transmitting signals, such as wireless, cellular, electrical, optical, NFC, RFID, or any other signals. In various embodiments, network port 210 may be capable of receiving signals, such as wireless, cellular, electrical, optical, or any other signals. Storage device 215 may include memory, storage, and the like for storing data and/or computer instructions. Storage device 215 may comprise one or more hard disk drives, solid state drives, random access memory (RAM), read only memory (ROM), and/or any other memory or storage. Storage device 215 may store resource data 220 , which may include tables, files, images, videos, audio, or any other data. Storage device 215 may store program 225 . Program 225 may include instructions for execution by processor 205 in order to carry out various embodiments described herein. Further, resource data 220 may be utilized (e.g., referenced) by processor 205 in order to carry out various embodiments described herein. It will be appreciated that, in various embodiments, resource device 102 a may include more or fewer components than those explicitly depicted.

User Devices

Turning now to FIG. 3 , a block diagram of a user device 106 a according to some embodiments is shown. Although FIG. 3 depicts user device 106 a , it will be appreciated that other user devices (e.g., user devices 106 b - n , may have similar constructions). In various embodiments, different user devices may have different constructions. The user device manages the various peripheral devices associated with one or more users, facilitating communication between them and passing information back to the user device. In some embodiments the user device is a Mac® or PC personal computer with suitable processing power, data storage, and communication capabilities to enable various embodiments. In various embodiments, a user device may include a PC, laptop, tablet, smart phone, smart watch, netbook, room AV controller, desktop computer, Apple Macintosh computer, a gaming console, a workstation, or any other suitable device.

Suitable devices that could act as a user device include: Laptops (e.g., MacBook® Pro, MacBook® Air, HP® Spectre™ x360, Google® Pixelbook™ Go, Dell® XPS™ 13); Desktop computers (e.g., Apple® iMac 5K, Microsoft® Surface™ Studio 2, Dell® Inspiron™ 5680); Tablets (e.g., Apple® iPad® Pro 12.9, Samsung® Galaxy™ Tab S6, iPad® Air, Microsoft® Surface™ Pro); Video game systems (e.g., PlayStation® 5, Xbox® One, Nintendo® Switch™, Super NES® Classic Edition, Wii U®); Smartphones (e.g., Apple® iPhone® 12 Pro or Android® device such as Google® Pixel™ 4 and OnePlus™ 7 Pro); IP enabled desk phone; Watches (e.g., Samsung® Galaxy® Watch, Apple® Watch 5, Fossil® Sport, TicWatch™ E2, Fitbit® Versa™ 2); Room AV Controller (e.g., Crestron® Fusion, Google® Meet hardware); Eyeglasses (e.g., Iristick.Z1™ Premium, Vuzix® Blade, Everysight® Raptor™ Solos®, Amazon® Echo™ Frames); Wearables (e.g., watch, headphones, microphone); Digital assistant devices (e.g., Amazon® Alexa® enabled devices, Google® Assistant, Apple® Siri™); or any other suitable devices. In various embodiments, user device 106 a comprises a processor 305 . As with processor 205 , processor 305 may be any suitable processor, logic chip, controller, or the like.

In various embodiments, processor 305 is in communication with a network port 310 , connection port 315 , input device 320 , output device 325 , sensor 330 , screen 335 , power source 340 , and a data storage device 345 . As with network port 210 , network port 310 may include any means for user device 106 a to connect to and/or communicate over a network. Network port 310 may comprise similar components and may have similar capabilities as does network port 210 , so the details need not be repeated. Connection port 315 may include any means for connecting or interfacing with another device or medium, such as with a peripheral device (e.g., a headset, mouse, a keyboard), a storage medium or device (e.g., a DVD, a thumb drive, a memory card, a CD), or any other device or medium. Connection port 315 may include a USB port, HDMI port, DVI port, VGA port, Display port, Thunderbolt, Serial port, a CD drive, a DVD drive, a slot for a memory card, or any variation thereof, or any iteration thereof, or any other port. Input device 320 may include any component or device for receiving user input or any other input. Input device 320 may include buttons, keys, trackpads, trackballs, scroll wheels, switches, touch screens, cameras, microphones, motion sensors, biometric sensors, or any other suitable component or device. Input device 320 may include a keyboard, power button, eject button, fingerprint button, or any other device.

Output device 325 may include any component or device for outputting or conveying information, such as to a user. Output device 325 may include a display screen, speaker, light, laser pointer, backlight, projector, LED, touch bar, haptic actuator, or any other output device. Sensor 330 may include any component or device for receiving or detecting environmental, ambient, and/or circumstantial conditions, situations, or the like. Sensor 330 may include a microphone, temperature sensor, light sensor, motion sensor, accelerometer, inertial sensor, gyroscope, contact sensor, angle sensor, or any other sensor. Screen 335 may include any component or device for conveying visual information, such as to a user. Screen 335 may include a display screen and/or a touch screen. Screen 335 may include a CRT screen, LCD screen, projection screen, plasma screen, LED screen, OLED screen, DLP screen, laser projection screen, virtual retinal display, or any other screen.

Power source 340 may include any component or device for storing, supplying and/or regulating power to user device 106 a and/or to any components thereof. Power source 340 may include a battery, ultra-capacitor, power supply unit, or any other suitable device. Power source 340 may include one or more electrical interfaces, such as a plug for connecting to an electrical outlet. Power source 340 may include one or more cords, wires, or the like for transporting electrical power, such as from a wall outlet and/or among components of user device 106 a.

Storage device 345 may include memory, storage, and the like for storing data and/or computer instructions. Storage device 345 may comprise one or more hard disk drives, solid state drives, random access memory (RAM), read only memory (ROM), and/or any other memory or storage. Storage device 345 may store data 350 , which may include tables, files, images, videos, audio, or any other data. Storage device 345 may store program 355 . Program 355 may include instructions for execution by processor 305 in order to carry out various embodiments described herein. Further, data 350 may be utilized (e.g., referenced) by processor 305 in order to carry out various embodiments described herein. It will be appreciated that, in various embodiments, user device 106 a may include more or fewer components than those explicitly depicted. It will be appreciated that components described with respect to user device 106 a need not necessarily be mutually exclusive. For example, in some embodiments, an input device 320 and a screen 335 may be the same (e.g., a touch screen). For example, in some embodiments, an input device 320 and a sensor 330 may be the same (e.g., a microphone). Similarly, components described herein with respect to any other device need not necessarily be mutually exclusive.

Peripheral Devices

Turning now to FIG. 4 , a block diagram of a peripheral device 107 a according to some embodiments is shown. Although FIG. 4 depicts peripheral device 107 a , it will be appreciated that other peripheral devices (e.g., peripheral devices 107 b - n and 107 p - z , may have similar constructions). In various embodiments, different peripheral devices may have different constructions. Peripheral devices 107 a according to various embodiments include: mouse, trackpad, trackball, joystick, video game controller, wheel, camera, exercise device, footpad, pedals, pedal, foot pedal, yoke, keyboard, headset, watch, stylus, soft circuitry, drone or other action camera (e.g., GoPro®), or any other suitable device. Peripheral devices 107 a might include suitably adapted furniture, accessories, clothing, or other items. For example, furniture might include built-in sensors and/or built-in electronics. Peripherals may include: chair, musical instrument, ring, clothing, hat, shoes, shirt, collar, mousepad, or any other suitable object or device. Peripheral devices 107 a might include: green screens or chroma key screens; lights such as task lights, or specialized key lights for streaming; webcams; a desk itself, including a conventional or sit-stand desk; desk surface; monitor stand (e.g., which is used to alter the height of a monitor) or laptop computer stand (which may include charger and connections); monitor mount or swing arms; speakers; dongles, connecters, wires, cables; printers and scanners; external hard drives; pens; phones and tablets (e.g., to serve as controllers, second screens, or as a primary device); other desk items (e.g., organizers, photos and frames, coaster, journal or calendar); glasses; mugs; water bottles; etc.

Peripheral device 107 a may include various components. Peripheral device 107 a may include a processor 405 , network port 410 , connector 415 , input device 420 , output device 425 , sensor 430 , screen 435 , power source 440 , and storage device 445 . Storage device 445 may store data 450 and program 455 . A number of components for peripheral device 107 a depicted in FIG. 4 have analogous components in user device 106 a depicted in FIG. 3 (e.g., processor 405 may be analogous to processor 305 ), and so such components need not be described again in detail. However, it will be appreciated that any given user device and any given peripheral device may use different technologies, different manufacturers, different arrangements, etc., even for analogous components. For example, a particular user device may comprise a 20-inch LCD display screen, whereas a particular peripheral device may comprise a 1-inch OLED display screen. It will also be appreciated that data 450 need not necessarily comprise the same (or even similar) data as does data 350 , and program 455 need not necessarily comprise the same (or even similar) data or instructions as does program 350 .

In various embodiments, connector 415 may include any component capable of interfacing with a connection port (e.g., with connection port 315 ). For example, connector 415 may physically complement connection port 315 . Thus, for example, peripheral device 107 a may be physically connected to a user device via the connector 415 fitting into the connection port 315 of the user device. The interfacing may occur via plugging, latching, magnetic coupling, or via any other mechanism. In various embodiments, a peripheral device may have a connection port while a user device has a connector. Various embodiments contemplate that a user device and a peripheral device may interface with one another via any suitable mechanism. In various embodiments, a user device and a peripheral device may interface via a wireless connection (e.g., via Bluetooth®, Near Field Communication, or via any other means).

A peripheral may include one or more sensors 430 . These may include mechanical sensors, optical sensors, photo sensors, magnetic sensors, biometric sensors, or any other sensors. A sensor may generate one or more electrical signals to represent a state of a sensor, a change in state of the sensor, or any other aspect of the sensor. For example, a contact sensor may generate a “1” (e.g., a binary one, e.g., a “high” voltage) when there is contact between two surfaces, and a “0” (e.g., a binary “0”, e.g., a “low” voltage) when there is not contact between the two surfaces. A sensor may be coupled to a mechanical or physical object, and may thereby sense displacement, rotations, or other perturbations of the object. In this way, for example, a sensor may detect when a button has been depressed (e.g., contact has occurred between a depressible surface of a button and a fixed supporting surface of the button), when a wheel has been turned (e.g., a spoke of the wheel has blocked incident light onto an optical sensor), or when any other perturbation has occurred. In various embodiments, sensor 430 may be coupled to input device 420 , and may thereby sense user inputs at the input device (e.g., key presses; e.g., mouse movements, etc.).

In various embodiments, sensor 430 may detect more than binary states. For example, sensor 430 may detect any of four different states, any of 256 different states, or any of a continuous range of states. For example, a sensor may detect the capacitance created by two parallel surfaces. The capacitance may change in a continuous fashion as the surfaces grow nearer or further from one another. The processor 405 may detect the electrical signals generated by sensor 430 . The processor may translate such raw sensor signals into higher-level, summary, or aggregate signals. For example, processor 405 may receive a series of “1-0” signals from the sensor that is repeated 45 times. Each individual “1-0” signal may represent the rotation of a mouse wheel by 1 degree. Accordingly, the processor may generate a summary signal indicating that the mouse wheel has turned 45 degrees. As will be appreciated, aggregate or summary signals may be generated in many other ways. In some embodiments, no aggregate signal is generated (e.g., a raw sensor signal is utilized).

In various embodiments, processor 405 receives an electrical signal from sensor 430 that is representative of 1 out of numerous possible states. For example, the electrical signal may represent state number 139 out of 256 possible states. This may represent, for example, the displacement by which a button has been depressed. The processor may then map the electrical signal from sensor 430 into one of only two binary states (e.g., ‘pressed’ or ‘not pressed’). To perform the mapping, the processor 405 may compare the received signal to a threshold state. If the state of the received signal is higher than the threshold state, then the processor may map the signal to a first binary state, otherwise the signal is mapped to a second binary state. In various embodiments, the threshold may be adjustable or centrally configurable. This may allow, for example, the processor 405 to adjust the amount of pressure that is required to register a “press” or “click” of a button.

Processor 405 may create data packets or otherwise encode the summary signals. These may then be transmitted to a user device (e.g., device 106 b ) via connector 415 (e.g., if transmitted by wired connection), via network port 410 (e.g., if transmitted by network; e.g., if transmitted by wireless network), or via any other means. User device 106 b may include a computer data interface controller (e.g., as network port 410 ; e.g., as connector 415 ; e.g., as part of network port 410 ; e.g., as part of connector 415 ; e.g., in addition to network port 410 and/or connector 415 ), which may receive incoming data from peripheral device 107 a . The incoming data may be decoded and then passed to a peripheral driver program on the user device 106 b . In various embodiments, different models or types of peripheral devices may require different drivers. Thus, for example, user device 106 b may include a separate driver for each peripheral device with which it is in communication. A driver program for a given peripheral device may be configured to translate unique or proprietary signals from the peripheral device into standard commands or instructions understood by the operating system on the user device 106 b . Thus, for example, a driver may translate signals received from a mouse into a number of pixels of displacement of the mouse pointer. The peripheral device driver may also store a current state of the peripheral device, such as a position of the device (e.g., mouse) or state of depression of one or more buttons. A driver may pass peripheral device states or instructions to the operating system as generated, as needed, as requested, or under any other circumstances. These may then be used to direct progress in a program, application, process, etc.

Sensors

Various embodiments may employ sensors (e.g., sensor 330 ; e.g., sensor 430 ). Various embodiments may include algorithms for interpreting sensor data. Sensors may include microphones, motion sensors, tactile/touch/force sensors, voice sensors, light sensors, air quality sensors, weather sensors, indoor positioning sensors, environmental sensors, thermal cameras, infrared sensors, ultrasonic sensors, fingerprint sensors, brainwave sensors (e.g., EEG sensors), heart rate sensors (e.g., EKG sensors), muscle sensors (e.g., EMG electrodes for skeletal muscles), barcode and magstripe readers, speaker/ping tone sensors, galvanic skin response sensors, sweat and sweat metabolite sensors and blood oxygen sensors (e.g., pulse oximeters), electrodermal activity sensors (e.g., EDA sensors), or any other sensors. Algorithms may include face detection algorithms, voice detection algorithms, or any other algorithms.

Motion sensors may include gyroscopes, accelerometers, Wi-Fi® object sensing (e.g. using Wi-Fi® signals that bounce off of objects in a room to determine the size of an object and direction of movement), magnetometer combos (inertia measurement units), or any other motion sensors. Motion sensors may be 6 or 9 axis sensors, or sensors along any other number of axes. Motion sensors may be used for activity classification. For example, different types of activities such as running, walking, cycling, typing, etc., may have different associated patterns of motion. Motion sensors may therefore be used in conjunction with algorithms for classifying the recorded motions into particular activities. Motion sensors may be used to track activity in a restricted zone of a building, identify whether an individual is heading toward or away from a meeting, as a proxy for level of engagement in a meeting, steps taken, calories burned, hours slept, quality of sleep, or any other aspect of user activity. Motion sensors may be used to quantify the amount of activity performed, e.g., the number of steps taken by a user. Motion sensors can also be used to track the movement of objects, such as the velocity or distance traveled of a user's mouse. Motion sensors may be used to identify whether an individual is approaching an entry to a house, and if so, trigger a doorbell within the house, and send an alert to a user device or peripheral devices of a user associated with the house.

Motion sensors may use passive infrared (PIR) technology which can detect body and changes in body temperatures. Motion sensors using microwave technology send out microwave pulses and measure how those pulses bounce off moving objects. Ultrasonic motion sensors are another option. Motion sensors can also employ dual use technology by combining multiple detection methods, such as using both passive infrared and microwave technologies. Vibration motion sensors can pick up vibrations caused by people walking through a room. Area reflective motion sensors use infrared waves from an LED and can calculate the distance to an object based on the reflection of the waves.

Motion sensors may be used in conjunction with reminders, such as reminders to change activity patterns. For example, if motion sensors have been used to detect that a user has been sitting for a predetermined period of time, or that the user has otherwise been sedentary, a reminder may be generated for the user to encourage the user to stand up or otherwise engage in some physical activity.

Motion sensors may be used to detect wrist gestures, such as shakes, taps or double taps, or twists. Motion sensors may detect device orientation (e.g., landscape/portrait mode, vertical orientation). A motion sensor may include a freefall sensor. A freefall sensor may be used to monitor handling of packages/devices (e.g., that packages were not dropped or otherwise handled too roughly) or to protect hard drives (e.g., to refrain from accessing the hard drive of a device if the device is undergoing too much motion). In various embodiments, accelerometers may be used as microphones. For example, accelerometers may detect vibrations in air, in a membrane, or in some other medium caused by sound waves. In various embodiments, accelerometers may be used for image stabilization (e.g., to move a displayed image in a direction opposite that of a detected motion of a camera).

Tactile/touch/force sensors may include sensors that are sensitive to force, such as physical pressure, squeezing, or weight. Flex sensors may sense bending. 3-D accelerometers, such as the Nunchuck®/Wiichuck®, may sense motion in space (e.g., in three dimensions). Light sensors may sense ambient light. Light sensors, such as RGB sensors, may sense particular colors or combinations of colors, such as primary colors (e.g., red green and blue). Light sensors may include full spectrum luminosity sensors, ultraviolet (UV) sensors, infrared (IR) sensors, or any other sensors. Light sensors may include proximity sensors. Indoor positioning sensors may include sensors based on dead reckoning, pedestrian dead reckoning (such as the combination of accelerometer and gyroscope, including systems unreliable on infrastructure), geomagnetic or RF signal strength mapping, Bluetooth® beacons, or based on any other technology. Environmental sensors may include barometers, altimeters, humidity sensors, smoke detectors, radiation detectors, noise level sensors, gas sensors, temperature sensors (e.g., thermometers), liquid flow sensors, and any other sensors. Infrared sensors may be used to detect proximity, body temperature, gestures, or for any other application. Ultrasonic sensors may be used for range-finding, presence/proximity sensing, object detection and avoidance, position tracking, gesture tracking, or for any other purpose.

Outputs

In various embodiments, outputs may be generated by various components, devices, technologies, etc. For example, outputs may be generated by output device 325 and/or by output device 425 . Outputs may take various forms, such as lights, colored lights, images, graphics, sounds, laser pointers, melodies, music, tones, vibrations, jingles, spoken words, synthesized speech, sounds from games, sounds from video games, etc. Light outputs may be generated by light emitting diodes (LED's), liquid crystals, liquid crystal displays (LCD's), incandescent lights, display screens, electronic ink (E-ink), e-skin, or by any other source. In various embodiments, outputs may include vibration, movement, or other motion. Outputs may include force feedback or haptic feedback. Outputs may include temperature, such as through heating elements, cooling elements, heat concentrating elements, fans, or through any other components or technologies. In various embodiments, an output component may include a motor. A motor may cause a mouse to move on its own (e.g., without input of its owner). In various embodiments, a first mouse is configured to mirror the motions of a second mouse. That is, for example, when the other second mouse is moved by a user, the motor in the first mouse moves the first mouse in a series of motions that copy the motions of the second mouse. In this way, for example, a first user can see the motions of another user reflected in his own mouse. In various embodiments, outputs may take the form of holograms. In various embodiments, outputs may take the form of scents or odors or vapors. These may be generated with dispensers, for example. In various embodiments, outputs may consist of alterations to an in-home (or other indoor) environment. Outputs may be brought about by home control systems. Alterations to the environment may include changing temperature, humidity, light levels, state of window shades (e.g., open are closed), state of door locks, security cameras settings, light projections onto walls, or any other alteration.

Third-Party Devices

Turning now to FIG. 5 , a block diagram of a third-party device 108 according to some embodiments is shown. In various embodiments, a third-party device 108 may be a server or any other computing device or any other device. Third-party device 108 may include various components. Third-party device 108 may include a processor 505 , network port 510 , and storage device 515 . Storage device 515 may store data 520 and program 525 . A number of components for third-party device 108 depicted in FIG. 5 have analogous components in resource device 102 a depicted in FIG. 2 (e.g., processor 505 may be analogous to processor 205 ), and so such components need not be described again in detail. However, it will be appreciated that any given resource device and any given third-party device may use different technologies, different manufacturers, different arrangements, etc., even for analogous components. It will also be appreciated that data 520 need not necessarily comprise the same (or even similar) data as does data 220 , and program 525 need not necessarily comprise the same (or even similar) data or instructions as does program 225 .

Central Controllers

Turning now to FIG. 6 , a block diagram of a central controller 110 according to some embodiments is shown. In various embodiments, central controller 110 may be a server or any other computing device or any other device. Central controller 110 may include various components. Central controller 110 may include a processor 605 , network port 610 , and storage device 615 . Storage device 615 may store data 620 and program 625 . A number of components for central controller 110 depicted in FIG. 6 have analogous components in resource device 102 a depicted in FIG. 2 (e.g., processor 605 may be analogous to processor 205 ), and so such components need not be described again in detail. However, it will be appreciated that any given resource device and central controller 110 may use different technologies, different manufacturers, different arrangements, etc., even for analogous components. It will also be appreciated that data 620 need not necessarily comprise the same (or even similar) data as does data 220 , and program 625 need not necessarily comprise the same (or even similar) data or instructions as does program 225 .

In various embodiments, the central controller may include one or more servers located at the headquarters of a company, a set of distributed servers at multiple locations throughout the company, or processing/storage capability located in a cloud environment—either on premise or with an outside vendor such as Amazon® Web Services, Google® Cloud Platform, or Microsoft® Azure™. In various embodiments, the central controller may be a central point of processing, taking input from one or more of the devices herein, such as a user device or peripheral device. The central controller has processing and storage capability along with the appropriate management software as described herein. In various embodiments, the central controller may include an operating system, such as Linux, Windows® Server, Mac® OS X Server, or any other suitable operating system.

Communications with the central controller could include user devices, game controllers, peripheral devices, outside websites, conference room control systems, video communication networks, remote learning communication networks, game consoles, streaming platforms, corporate data systems, etc. In various embodiments, the central controller may include hardware and software that interfaces with user devices and/or peripheral devices in order to facilitate communications. The central controller may collect analytics from devices (e.g., user device, e.g., peripheral devices). Analytics may be used for various purposes, such as for the purpose of enhancing the experience of a user.

In various embodiments, the central controller may perform various other functions, such as authenticating users, maintaining user accounts, maintaining user funds, maintaining user rewards, maintaining user data, maintaining user work products, hosting productivity software, hosting game software, hosting communication software, facilitating the presentation of promotions to the user, allowing one user to communicate with another, allowing a peripheral device to communicate with another, or any other function.

In various embodiments, the central controller may include software for providing notifications and/or status updates. The central controller may notify a user when one or more other users is present (e.g., at their respective office locations, e.g., at their respective home computers), when another user wishes to communicate with the user, when a collaborative project has been updated, when the user has been mentioned in a comment, when the user has been assigned work, when the user's productivity has fallen, when the user has been invited to play in a game, or in any other circumstance. Notifications or status updates may be sent to peripheral devices, user devices, smartphones, or to any other devices.

In various embodiments, the central controller may include voting software. The voting software may facilitate voting, decision-making, or other joint or group action. Example votes may determine a plan of action at a company, or a strategy in a team video game. Voting software may permit users or other participants to receive notification of votes, receive background information about decisions or actions they are voting on, cast their votes, and see the results of votes. Voting software may be capable of instituting various protocols, such as multiple rounds of runoffs, win by the majority, win by the plurality, win by unanimous decision, anonymous voting, public voting, secure voting, differentially weighted votes, voting for slates of decisions, or any other voting protocol, or any other voting format. Voting results may be stored in data storage device 615 , or sent to other devices for storage.

Game Controllers

In various embodiments, a game controller may include software and/or hardware that interfaces with the user device in order to facilitate game play. Example games include Pokemon®, Call of Duty®, Wii®, League of Legends®, Clash of Clans™, Madden® NFL®, Minecraft®, Guitar Hero®, Fortnite®, solitaire, poker, chess, go, backgammon, bridge, Magic: The Gathering®, Scrabble®, etc. In various embodiments, a game controller may be part of the central controller 110 . In various embodiments, a game controller may be in communication with the central controller 110 , and may exchange information as needed. In various embodiments, a game controller may be a standalone device or server (e.g., a server accessed via the internet). In various embodiments, a game controller could be housed within a user computer. In various embodiments, a game controller may be part of, or may operate on any suitable device. In various embodiments, the game controller enables gameplay and can communicate with a user device and one or more computer peripherals. In various embodiments, a game controller may perform such functions as maintaining a game state, updating a game state based on user inputs and game rules, creating a rendering of a game state, facilitating chat or other communication between players of a game, maintaining player scores, determining a winner of a game, running tournaments, determining a winner of a tournament, awarding prizes, showing in-game advertisements, are performing any other function related to a game, or performing any other function.

Data Structures

FIGS. 7-29, 31-37, 50-62, 64-66, 70, 73-78, 87-89 , show example data tables according to some embodiments. A data table may include one or more fields, which may be shown along the top of the table. A given field may serve as a category, class, bucket, or the like for data in the table corresponding to the given field (e.g., for data in cells shown beneath the field). Each cell or box in a data table may include a data element. Data elements within the same row of a table may be associated with one another (e.g., each data element in a row may be descriptive of the same underlying person, object, entity, or the like). In various embodiments, data elements may include identifiers or indexes, which may serve to identify (e.g., uniquely identify) the current row and/or the underlying person, object, or entity. In various embodiments, data elements may include keys, which may allow a row from a first table to be associated with a row from a second table (e.g., by matching like keys in the first and second tables). Through use of keys (or through any other means) two or more data tables may be relatable to one other in various ways. In various embodiments, relationships may include one-to-one, one-to-many, many-to-many, or many-to-one relationships.

It will be appreciated that FIGS. 7-29, 31-37, 50-62, 64-66, 70, 73-78, 87-89 represent some ways of storing, representing, and/or displaying data, but that various embodiments contemplate that data may be stored, represented and/or displayed in any other suitable fashion. It will be appreciated that, in various embodiments, one or more tables described herein may include additional fields or fewer fields, that a given field may be split into multiple fields (e.g., a “name” field could be split into a “first name” field and a “last name” field), that two or more fields may be combined, that fields may have different names, and/or that fields may be structured within tables in any other suitable fashion. It will be appreciated that, in various embodiments, one or more tables described herein may include additional rows, that rows may be split or combined, that rows may be re-ordered, that rows may be split amongst multiple tables, and/or that rows may be rearranged in any other suitable fashion.

It will be appreciated that, in various embodiments, one or more tables described herein may show representative rows of data elements. Rows are not necessarily shown in any particular order. The rows are not necessarily shown starting from the beginning nor approaching the end in any conceivable ordering of rows. Consecutive rows are not necessarily shown. In some embodiments, fewer or more data fields than are shown may be associated with the data tables (e.g., of FIGS. 7-29, 31-37, 50-62, 64-66, 70, 73-78, 87-89 ). Only a portion of one or more databases and/or other data stores is necessarily shown in the data table 700 of FIG. 7 , for example, and other fields, columns, structures, orientations, quantities, and/or configurations may be utilized without deviating from the scope of some embodiments. Further, the data shown in the various data fields is provided solely for exemplary and illustrative purposes and does not limit the scope of embodiments described herein. In various embodiments, data or rows that are depicted herein as occurring in the same data table may actually be stored in two or more separate data tables. These separate data tables may be distributed in any suitable fashion, such as being stored within separate databases, in separate locations, on separate servers, or in any other fashion.

In various embodiments, data or rows that are depicted herein as occurring in separate or distinct data tables may actually be stored in the same data tables. In various embodiments, two or more data tables may share the same name (e.g., such data tables may be stored in different locations, on different devices, or stored in any other fashion). Such data tables may or may not store the same types of data, may or may not have the same fields, and may or may not be used in the same way, in various embodiments. For example, central controller 110 may have a “user” data table, and third-party device 108 may be an online gaming platform that also has a “user” data table. However, the two tables may not refer to the same set of users (e.g., one table may store owners of peripheral devices, while the other table may store rated online game players), and the two tables may store different information about their respective users. In various embodiments, data tables described herein may be stored using a data storage device (e.g., storage device 615 ) of central controller 110 . For example, “data” 620 may include data tables associated with the central controller 110 , which may reside on storage device 615 . Similarly, “data” 520 may include data tables associated with the third-party device 108 , which may reside on storage device 515 . In various embodiments, data tables associated with any given device may be stored on such device and/or in association with such device.

Referring to FIG. 7 , a diagram of an example user table 700 according to some embodiments is shown. User table 700 may, for example, be utilized to store, modify, update, retrieve, and/or access various information related to users. The user table may comprise, in accordance with various embodiments, a user ID field 702 , a name field 704 , an email address field 706 , a password field 708 , a phone number field 710 , a nicknames field 712 , an address field 714 , a financial account information field 716 , a birthdate field 718 , a marital status field 720 , a gender field 722 , a primary language field 724 , and an image(s) field 726 . Although not specifically illustrated in user table 700 , various additional fields may be included, such as fields containing unique identifiers of friends, user achievements, presentations delivered, presentation decks created, value earned, statistics (e.g., game statistics), character unique identifiers, game login information, preferences, ratings, time spent playing games, game software owned/installed, and any other suitable fields.

As depicted in FIG. 7 , user table 700 is broken into three sections. However, this is only due to space limitations on the page, and in fact user table 700 is intended to depict (aside from the field names) three continuous rows of data elements. In other words, data elements 703 and 713 are in the same row. Of course, FIG. 7 is merely an illustrative depiction, and it is contemplated that a real world implementation of one or more embodiments described herein may have many more than three rows of data (e.g. thousands or millions of rows). Although not specifically referred to in all cases, other tables described herein may similarly be broken up for reasons of space limitations on the printed page, when in actuality it is contemplated that such tables would contain continuous rows of data, in various embodiments. User ID field 702 may store an identifier (e.g., a unique identifier) for a user. Password field 708 may store a password for use by a user. The password may allow the user to confirm his identity, log into a game, log into an app, log into a website, access stored money or other value, access sensitive information, access a set of contacts, or perform any other function in accordance with various embodiments.

Nicknames field 712 may store a user nickname, alias, screen name, character name, or the like. The nickname may be a name by which a user will be known to others in one or more contexts, such as in a game or in a meeting. In various embodiments, a user may have more than one nickname (e.g., one nickname in a first context and another nickname in a second context). Financial account information field 716 may store information about a financial account associated with the user, such as a credit or debit card, bank account, stored value account, PayPal® account, Venmo® account, rewards account, coupons/discounts, crypto currency account, bitcoin account, or any other account. With this information stored, a user may be given access to peruse his account balances or transaction history, for example. A user may be rewarded through additions to his account, and charged through deductions to his account. In various embodiments, a user may utilize his account to pay another user or receive payment from another user. Various embodiments contemplate other uses for financial account information. User table 700 depicts several fields related to demographic information (e.g., marital status field 720 , gender field 722 , and primary language field 724 ). In various embodiments, other items of demographic information may be stored, such as number of children, income, country of origin, etc. In various embodiments, fewer items of demographic information may be stored. Images field 726 may store one or more images associated with a user. An image may include an actual photograph of a user (e.g., through a webcam). The image may be used to help other users recognize or identify with the user. In various embodiments, image field 726 may store an item favored by the user, such as the users pet or favorite vacation spot. In various embodiments, image field 726 may store an image of a character or avatar (e.g., an image by which the user wishes to be identified in a game or other online environment).

Referring to FIG. 8 , a diagram of an example networks table 800 according to some embodiments is shown. In various embodiments, a local network may include one or more devices that are in communication with one another either directly or indirectly. Communication may occur using various technologies such as ethernet Wi-Fi®, Bluetooth® or any other technology. In various embodiments, devices on a local network may have a local or internal address (e.g., IP address) that is visible only to other devices on the local network. In various embodiments, the network may have one or more external-facing addresses (e.g., IP addresses), through which communications may be transmitted to or received from external devices or Networks. Networks table 800 may store characteristics of a user's local network, such as their connection speed, bandwidth, encryption strength, reliability, etc. With knowledge of a user's Network characteristics, the central controller may determine the content that is transmitted to or requested from a user. For example if the user has a slow network connection, then the central controller may transmit to the user lower bandwidth videos or live game feeds. The central controller may also determine the frequency at which to poll data from a user device or a peripheral device. For example, polling may occur less frequently if the user has a slower network connection. In another example, the central controller may determine whether or not to request sensitive information from the user (such as financial account information) based on the security of the user's network. As will be appreciated, Various other embodiments may consider information about a user's Network and may utilize such information in making one or more decisions.

In various embodiments, network table 800 may store characteristics of any other network. Network ID field 802 may include an identifier (e.g., unique identifier) for a user's network. Network name field 804 may store a name, such as a human readable name, nickname, colloquial name, or the like for a users network. Network IP address field 806 may store an IP address for the network, such as an externally facing IP address. User ID field 808 , may store an indication of a user who owns this network, if applicable. In various embodiments, the network may be owned by some other entity such as a company, office, government agency etc. Specified connection speed field 810 may store a specified, advertised, and/or promised connection speed for a network. The connection speed that is realized in practice may differ from the specified connection speed. Actual upload-speed field 812 may store an indication of an upload speed that is or has been realized in practice. For example, the upload speed may store an indication of the upload speed that has been realized in the past hour, in the past 24 hours, or during any other historical time frame. The upload speed may measure the rate at which a network is able to transmit data.

Actual download-speed field 814 may store an indication of a download speed that is or has been realized in practice (such as during some historical measurement period). The download speed may measure the rate at which a network is able to receive data. The download speed may be important, for example, in determining what types of videos may be streamed to a user network and/or user device. Encryption type field 816 may store an indication of the security that is present on the network. In some embodiments, field 816 stores the type of encryption used by the network. For example, this type of encryption may be used on data that is communicated within the network. In some embodiments, field 816 may store an indication of the security measures that a user must undergo in order to access data that has been transmitted through the network. For example, field 816 may indicate that a user must provide a password or biometric identifiers in order to access data that has been transmitted over the network. Uptime percentage field 818 may store an indication of the amount or the percentage of time when a network is available and/or functioning as intended. For example, if a network is unable to receive data for a one-hour period (perhaps due to a thunderstorm), then the one-hour period may count against the network uptime percentage. In various embodiments, an uptime percentage may be used to determine activities in which a user may engage. For example, a user may be allowed to participate in a multi-person video conference or video game requiring extensive team communication, only if the user's network uptime exceeds a certain minimum threshold.

Referring to FIG. 9 , a diagram of an example user device table 900 according to some embodiments is shown. User device table 900 may store one or more specifications for user devices. The specifications may be used for making decisions or selections, in various embodiments. For example, a user may be invited to play in a graphically intensive video game or participate in a collaborative conference call only if the user device can handle the graphics requirements (such as by possessing a graphics card). In another example, a user interface for configuring a peripheral device may be displayed with a layout that depends on the screen size of the user device. As will be appreciated, many other characteristics of a user device may be utilized in making decisions and or carrying out steps according to various embodiments. User device ID field 902 may include an identifier (e.g., a unique identifier) for each user device. Form factor field 904 may include an indication of the form factor for the user device. Example form factors may include desktop PC, laptop, tablet, notebook, game console, or any other form factor.

Model field 906 may indicate the model of the user device. Processor field 908 may indicate the processor, CPU, Neural Chip, controller, logic, or the like within the device. In various embodiments, more than one processor may be indicated. Processor speed field 910 may indicate the speed of the processor. Number of cores field 912 may indicate the number of physical or virtual cores in one or more processors of the user device. In various embodiments, the number of cores may include the number of processors, the number of cores per processor, the number of cores amongst multiple processors, or any other suitable characterization. Graphics card field 914 may indicate the graphics card, graphics processor, or other graphics capability of the user device. RAM field 916 may indicate the amount of random access memory possessed by the user device. Storage field 918 may indicate the amount of storage possessed by that user device. Year of manufacture field 920 may indicate the year when the user device was manufactured. Purchase year field 922 may indicate the year in which the user device was purchased by the user.

Operating System field 924 may indicate the operating system that user device is running. MAC Address field 926 may indicate the media access control address (MAC address) of the user device. Physical location field 928 may indicate the physical location of the user device. This may be the same as the owner's residence address, or it may differ (e.g., if the owner has carried the user device elsewhere or is using it at the office, etc.). Timezone field 930 may indicate the time zone in which the user device is located, and or the time zone to which the user device is set. In one example, the central controller may schedule the user device to participate in a video conference call with a particular shared start time for all participants. In another example, the central controller may schedule the user device to participate in a multiplayer game, and wish to alert the user device as to the game's start time using the user device's time zone. Owner ID field 932 may indicate the owner of the user device. The owner may be specified for example in terms of a user ID, which may be cross-referenced to the user table 700 if desired. Network ID(s) field 934 may indicate a network, such as a local network, on which the user device resides. The network may be indicated in terms of a network ID, which may be cross-referenced to the network table 800 if desired.

IP address field 936 may indicate the IP address (or any other suitable address) of the user device. In some embodiments, such as if the user device is on a local network, then the user device's IP address may not be listed. In some embodiments, IP address field 936 may store an internal IP address. In some embodiments, IP address field 936 may store a network IP address, such as the public-facing IP address of the network on which the user device resides. As well be appreciated, user device table 900 may store various other features and characteristics of a user device.

Referring to FIG. 10 , a diagram of an example peripheral device table 1000 according to some embodiments is shown. Peripheral device table 1000 may store specifications for one or more peripheral devices. Peripheral device ID field 1002 may store an identifier (e.g., a unique identifier) for each peripheral device. Type field 1004 may store an indication of the type of peripheral device, e.g., mouse, keyboard, headset, exercise bike, camera, presentation remote, projector, chair controller, light controller, coffee maker, etc. Model field 1006 may store an indication of the model of the peripheral device. Purchase year field 1008 may store the year in which the peripheral device was purchased.

IP Address field 1010 may store the IP address, or any other suitable address, of the peripheral device. In some embodiments, such as if the peripheral device is on a local network, then the peripheral device's IP address may not be listed. In some embodiments, IP address field 1010 may store an internal IP address. In some embodiments, IP address field 1010 may store a network IP address, such as the public-facing IP address of the network on which the peripheral device resides. In some embodiments, IP address field 1010 may store the IP address of a user device to which the associated peripheral device is connected.

Physical location field 1012 may store an indication of the physical location of the peripheral device. Owner ID field 1014 may store an indication of the owner of the peripheral device. Linked user device ID(s) field 1016 may store an indication of one or more user devices to which the peripheral device is linked. For example, if a peripheral device is a mouse that is connected to a desktop PC, then field 1016 may store an identifier for the desktop PC. Communication modalities available field 1018 may indicate one or more modalities through which the peripheral device is able to communicate. For example, if a peripheral device possesses a display screen, then video may be listed as a modality. As another example, if a peripheral device has a speaker, then audio may be listed as a modality. In some embodiments, a modality may be listed both for input and for output. For example, a peripheral device with a speaker may have ‘audio’ listed as an output modality, and a peripheral with a microphone may have ‘audio’ listed as an input modality.

In various embodiments, a peripheral device might have the capability to output images, video, characters (e.g., on a simple LED screen), lights (e.g., activating or deactivating one or more LED lights or optical fibers on the peripheral device), laser displays, audio, haptic outputs (e.g., vibrations), altered temperature (e.g. a peripheral device could activate a heating element where the user's hand is located), electrical pulses, smells, scents, or any other sensory output or format. In various embodiments, any one of these or others may be listed as modalities if applicable to the peripheral device. In various embodiments, a peripheral device may have the capability to input images (e.g., with a camera), audio (e.g., with a microphone), touches (e.g., with a touchscreen or touchpad), clicks, key presses, motion (e.g., with a mouse or joystick), temperature, electrical resistance readings, positional readings (e.g., using a positioning system, e.g., using a global positioning system, e.g., by integrating motion data), or any other sensory or any other sensor or any other information. Such input modalities may be listed if applicable to the peripheral device.

In some embodiments, modalities may be specified in greater detail. For example, for a given peripheral device, not only is the video modality specified, but the resolution of the video that can be displayed is specified. For example, a keyboard with a display screen may specify a video modality with up to 400 by 400 pixel resolution. Other details may include number of colors available, maximum and minimum audio frequencies that can be output, frame refresh rate that can be handled, or any other details. Network ID(s) field 1020 may store an indication of a network (e.g., a local network) on which a peripheral device resides. If the peripheral device does not reside on a network, or is not known, then a network may not be indicated. As will be appreciated, peripheral device table 1000 may store one or more other features or characteristics of a peripheral device, in various embodiments.

Referring to FIG. 11 , a diagram of an example peripheral configuration table 1100 according to some embodiments is shown. Peripheral configuration table 1100 may store configuration variables like mouse speed, color, audio level, pressure required to activate a button, etc. A peripheral device may have one or more input and/or sensor components. The peripheral device may, in turn, process any received inputs before interpreting such inputs or converting such inputs into an output or result. For example, a mouse may detect a raw motion (i.e., a change in position of the mouse itself), but may then multiply the detected motion by some constant factor in order to determine a corresponding motion of the cursor. As another example, a presentation remote may receive audio input in the form of words spoken by a presenter. The presentation remote might, in turn, pass such pressure information through a function to determine whether or not to register or store the words. Table 1100 may store one or more parameters used in the process of converting a raw input into an output or a result. In various embodiments, parameters can be altered. Thus, for example, the sensitivity with which a mouse registers a click may be altered, the ratio of cursor motion to mouse motion may be altered, the ratio of page motion to scroll wheel motion may be altered, and so on.

Table 1100 may also store one or more parameters controlling how a peripheral device outputs information. A parameter might include the color of an LED light, the brightness of an LED light, the volume at which audio is output, the temperature to which a heating element is activated, the brightness of a display screen, the color balance of a display screen, or any other parameter of an output. Table 1100 may also store one or more parameters controlling a physical aspect or configuration of a peripheral device. A parameter might include the default microphone sensitivity, the angle at which a keyboard is tilted, the direction in which a camera is facing, or any other aspect of a peripheral device. Table 1100 may also store one or more parameters controlling the overall functioning of a peripheral device. In some embodiments, parameters may control a delay with which a peripheral device transmits information, a bandwidth available to the peripheral, a power available to the peripheral, or any other aspect of a peripheral device's function or operation.

In various embodiments, table 1100 may also store constraints on how parameters may be altered. Constraints may describe, for example, who may alter a parameter, under what circumstances the parameter may be altered, the length of time for which an alteration may be in effect, or any other constraint. Configuration ID field 1102 may store an identifier (e.g., a unique identifier), of a given configuration for a peripheral device. Peripheral device ID field 1104 may store an indication of the peripheral device (e.g., a peripheral device ID) to which the configuration applies. Variable field 1106 may include an indication of which particular parameter, variable, or aspect of a peripheral device is being configured. Example variables include mouse speed, mouse color, headset camera resolution, etc. Default setting field 1108 may include a default setting for the variable. For example, by default a mouse speed may be set to “fast”. In some embodiments, a default setting may take effect following a temporary length of time in which a parameter has been altered.

Outsider third-party control field 1110 may indicate whether or not the parameter can be modified by an outsider (e.g., by another user; e.g., by an opponent). For example, in some embodiments, a user playing a multiplayer video game may have their peripheral device's performance degraded by an opposing player as part of the ordinary course of the game (e.g., if the opposing player has landed a strike on the player). In some embodiments, table 1100 may specify the identities of one or more outside third-parties that are permitted to alter a parameter of a peripheral device. In some embodiments, an outsider is permitted to alter a parameter of a peripheral device only to within a certain range or subset of values. For example, an outsider is permitted to degrade the sensitivity of a user's mouse, however the sensitivity can only be degraded to as low as 50% of maximum sensitivity.

Current setting field 1112 may store the current setting of a parameter for a peripheral device. In other words, if the user were to use the peripheral device at that moment, this would be the setting in effect. Setting expiration time field 1114 may store the time at which a current setting of the parameter will expire. Following expiration, the value of the parameter may revert to its default value, in some embodiments. For example, if the performance of a user's peripheral device has been degraded, the lower performance may remain in effect only for 30 seconds, after which the normal performance of the peripheral device may be restored. As will be appreciated, an expiration time can be expressed in various formats, such as an absolute time, as an amount of time from the present, or in any other suitable format. Expiration time can also be expressed in terms of a number of actions completed by the user. For example, the current setting may expire once a user has clicked the mouse button 300 times.

Referring to FIG. 12 , a diagram of an example peripheral device connections table 1200 according to some embodiments is shown. In various embodiments, table 1200 stores an indication of which peripheral devices have been given permission to communicate directly with one another. Peripheral devices may communicate with one another under various circumstances. In some embodiments, two users may pass messages to one another via their peripheral devices. A message sent by one user may be displayed on the peripheral device of the other user. In some embodiments, user inputs to one peripheral device may be transferred to another peripheral device in communication with the first. In this way, for example, a first user may control the peripheral device of a second user by manipulating his own peripheral device (i.e., the peripheral device of the first user). For example, the first user may guide a second users game character through a difficult phase of a video game. As will be appreciated, there are various other situations in which one peripheral device may communicate with another peripheral device.

In various embodiments, peripheral devices may communicate directly with one another, such as with a direct wireless signal sent from one to the other. In various embodiments, one peripheral device communicates with another peripheral device via one or more intermediary devices. Such intermediary devices may include, for example, a user device, a router (e.g., on a local network), the central controller, or any other intermediary device. In other embodiments, one peripheral device may communicate with two or more other peripheral devices at the same time.

As shown, table 1200 indicates a connection between a first peripheral device and a second peripheral device in each row. However, as will be appreciated, a table may store information about connections in various other ways. For example, in some embodiments, a table may store information about a three-way connection, a four-way connection, etc. Connection ID field 1202 may store an identifier (e.g., a unique identifier) for each connection between a first peripheral device and a second peripheral device. Peripheral device 1 ID field 1204 may store an indication of the first peripheral device that is part of the pair of connected devices. Peripheral device 2 ID field 1206 may store an indication of the second peripheral device that is part of the pair of connected devices. Time field 1208 may store the time when the connection was made and/or terminated. Action field 1210 may store the action that was taken. This may include the relationship that was created between the two peripheral devices. Example actions may include initiating a connection, terminating a connection, initiating a limited connection, or any other suitable action.

Maximum daily messages field 1212 may store one or more limits or constraints on the communication that may occur between two peripheral devices. For example, there may be a limit of one thousand messages that may be exchanged between peripheral devices in a given day. As another example, there may be constraints on the number of words that can be passed back and forth between peripheral devices in a given day. Placing constraints on communications may serve various purposes. For example, the owner of a peripheral device may wish to avoid the possibility of being spammed by too many communications from another peripheral device. As another example, the central controller may wish to limit the communications traffic that it must handle.

Referring to FIG. 13 , a diagram of an example peripheral device groups table 1300 according to some embodiments is shown. Peripheral device groups may include peripherals that have been grouped together for some reason. For example, any peripheral device (e.g. presentation remote, headset, mouse, camera, keyboard) in a group is permitted to message any other device in the group, all peripheral devices in a group are on the same video game team, all peripheral devices are on the same network, any peripheral device is allowed to take control of any other, or any peripheral device in the group is allowed to interact with a particular app on a computer. Peripheral device group ID field 1302 may include an identifier (e.g., a unique identifier) for a group of peripheral devices. Group name field 1304 may include a name for the group. Group type field 1306 may include a type for the group. In some embodiments, the group type may provide an indication of the relationship between the peripheral devices in the group. For example, peripheral devices in a group may all belong to respective members of a team of software architects of a large software project. This group type may be called a functional team. In some embodiments, a group of peripheral devices may belong to meeting owners, such as people who often lead meetings at a company. Another group type may be for peripheral devices that are proximate to one another. For example, such peripheral devices may all be in the same home, or office, or city. Other types of groups may include groups of peripheral devices with the same owner, groups of peripheral devices belonging to the same company, groups of peripheral devices that are all being used to participate in the same meeting, or any other type of group.

Settings field 1308 may include one or more settings or guidelines or rules by which peripheral devices within the group may interact with one another and/or with an external device or entity. In various embodiments, a setting may govern communication between the devices. For example, one setting may permit device-to-device messaging amongst any peripheral devices within the group. One setting may permit any peripheral device in a group to control any other peripheral device in the group. One setting may permit all peripheral devices in a group to interact with a particular online video game. As will be appreciated, these are but some examples of settings and many other settings are possible and contemplated according to various embodiments. Formation time field 1310 may store an indication of when the group was formed. Group leader device field 1312 may store an indication of which peripheral device is the leader of the group. In various embodiments, the peripheral device that is the leader of a group may have certain privileges and/or certain responsibilities. For example, in a meeting group, the group leader device may be the only device that is permitted to start the meeting or to modify a particular document being discussed in the meeting. Member peripheral devices field 1314 may store an indication of the peripheral devices that are in the group.

Referring to FIG. 14 , a diagram of an example user connections table 1400 according to some embodiments is shown. User connections table 1400 may store connections between users. Connections may include “co-worker” connections as during a video conference call, “friend” connections as in a social network, “teammate” connections, such as in a game, etc. In various embodiments, table 1400 may include connections that have been inferred or deduced and were not explicitly requested by the users. For example, the central controller may deduce that two users are members of the same company, because they are each members of the same company as is a third user. Connection ID field 1402 may include an identifier (e.g., a unique identifier) that identifies the connection between two users. User 1 ID field 1404 may identify a first user that is part of a connection. User 2 ID field 1406 may identify a second user that is part of a connection.

Time field 1408 may indicate a time when a connection was made, terminated, or otherwise modified. Action field 1410 may indicate an action or status change that has taken effect with respect to this connection. For example, the action field may be ‘initiate connection’, ‘terminate connection’, ‘initiate limited connection’, or any other modification to a connection. Relationship field 1412 may indicate a type of relationship or a nature of the connection. For example, two users may be related as friends, teammates, family members, co-workers, neighbors, or may have any other type of relationship or connection. Maximum daily messages field 1414 may indicate one or more constraints on the amount of communication between two users. For example, a user may be restricted to sending no more than one hundred messages to a connected user in a given day. The restrictions may be designed to avoid excessive or unwanted communications or to avoid overloading the central controller, for example. Various embodiments may include many other types of restrictions or constraints on the connection or relationship between two users.

Referring to FIG. 15 , a diagram of an example user groups table 1500 according to some embodiments is shown. Table 1500 may store an indication of users that belong to the same group. User group ID field 1502 may include an identifier (e.g., a unique identifier) of a user group. Group name field 1504 may include a name for the group. Group type field 1506 may include an indication of the type of group. The type of group may provide some indication of the relationship between users in the group, of the function of the group, of the purpose of the group, or of any other aspect of the group. Examples of group types may include ‘Department’, ‘Project team x’, ‘Meeting group’, ‘Call group’, ‘Functional area’, or any other group type. In some embodiments, a group type may refer to a group of people in the same functional area at a company, such as a group of lawyers, a group of developers, a group of architects or a group of any other people at a company. Formation Time field 1508 may indicate the time/date at which a group was formed. Group leader field 1510 may indicate the user who is the group leader. In some cases, there may not be a group leader. Member users field 1512 may store indications of the users who are members of the group.

Referring to FIG. 16 , a diagram of an example ‘user roles within groups’ table 1600 according to some embodiments is shown. Table 1600 may store an indication of which users have been assigned to which roles. In some embodiments, there are standard predefined roles for a group. In some embodiments, a group may have unique roles. Role assignment ID field 1602 may include an identifier (e.g., a unique identifier) for a particular assignment of a user to a role. User group ID field 1604 may store an indication of the group in which this particular role has been assigned. User ID field 1606 may store an indication of the user to which the role has been assigned. Role field 1608 may store an indication of the particular role that has been assigned, such as ‘Project Manager’, ‘Minutes Keeper’, ‘Facilitator’, ‘Coach’, Presenter, ‘Mentor’, ‘Leader’, ‘Teacher’, etc.

Referring to FIG. 17 , a diagram of an example user achievements table 1700 according to some embodiments is shown. User achievements table 1700 may store achievements, accolades, commendations, accomplishments, records set, positive reviews, or any other noteworthy deeds of a user. Achievements may be from a professional setting, from a game setting, from an educational setting, or from any other setting. Achievement ID field 1702 may store an identifier (e.g., a unique identifier) of a particular achievement achieved by a user. User ID field 1704 may store an indication of the user (or multiple users) that have made the achievement. Time/date field 1706 may store the date and time when the user has achieved the achievement. Achievement type field 1708 may indicate the type of achievement, the context in which the achievement was made, the difficulty of the achievement, the level of the achievement, or any other aspect of the achievement. Examples of achievement types may include ‘professional’, ‘gaming’, ‘educational’, or any other achievement type. Achievement field 1710 may store an indication of the actual achievement. Example achievements may include: the user got through all three out of three meeting agenda items; the user reached level 10 in Star Attack Blasters; the user learned pivot tables in Excel; or any other achievement.

Reward field 1712 may indicate a reward, acknowledgement, or other recognition that has or will be provided to the user for the achievement. Example rewards may include: the users office mouse glows purple for the whole day of 7/22/20; a congratulatory message is sent to all users in the same game group; the user receives three free music downloads; the user receives a financial payment (such as money, digital currency, game currency, game items, etc.); the user receives a discount coupon or promotional pricing, the users name is promoted within a game environment; the users video conference photo is adorned with a digital crown, or any other reward. Provided field 1714 may indicate whether or not the reward has been provided yet. In some embodiments, table 1700 may also store an indication of a time when a reward has been or will be provided.

Referring to FIG. 18 , a diagram of an example stored value accounts table 1800 according to some embodiments is shown. Stored value accounts table 1800 may store records of money, currency, tokens, store credit, or other value that a user has on deposit, has won, is owed, can receive on demand, or is otherwise associated with a user. A users stored-value account may store government currency, cryptocurrency, game currency, game objects, etc. A user may utilize a stored-value account in order to make in-game purchases, in order to pay another user for products or services, in order to purchase a product or service, or for any other purpose. Stored value account ID field 1802 may store an identifier (e.g., a unique identifier) for a user's stored-value account. Owner(s) field 1804 may store an indication of the owner of a stored-value account. Password field 1806 may store an indication of a password required in order for a user to gain access to a stored-value account (e.g., to her account). For example, the password may be required from a user in order for the user to withdraw funds from a stored-value account. In other embodiments, authentication data field 1808 includes authentication values like a digital fingerprint and/or voice recording that are used to access stored value. In various embodiments, a table such as table 1800 may store a username as well. The username may be used to identify the user when the user is accessing the stored-value account.

Currency type field 1810 may store an indication of the type of currency in the stored-value account. The currency may include such traditional currencies as dollars or British pounds. The currency may also include stock certificates, bonds, cryptocurrency, game currency, game tokens, coupons, discounts, employee benefits (e.g. one or more extra vacation days), game skins, game objects (e.g. a +5 sword, a treasure map), cheat codes, merchant rewards currency, or any other type of currency or stored value. Balance field 1812 may store a balance of funds that the user has in her stored-value account. In some embodiments, a negative balance may indicate that a user has overdrawn an account and/or owes funds to the account. Hold amount field 1814 may indicate an amount of a hold that has been placed on funds in the user account. The hold may restrict the user from withdrawing funds beyond a certain amount, and/or may require the user to leave at least a certain amount in the account. The hold may ensure, for example, that the user is able to meet future obligations, such as financial obligations.

Referring to FIG. 19 , a diagram of an example asset library table 1900 according to some embodiments is shown. Asset library table 1900 may store records of digital assets, such as music, movies, TV shows, videos, games, books, e-books, textbooks, presentations, spreadsheets, newspapers, blogs, graphic novels, comic books, lectures, classes, interactive courses, exercises, cooking recipes, podcasts, software, avatars, etc. These assets may be available for purchase, license, giving out as rewards, etc. For example, a user may be able to purchase a music file from the central controller 110 . As another example, a user who has achieved a certain meeting quality level may have the opportunity to download a free electronic book. In various embodiments, asset library table 1900 may store analog assets, indications of physical assets (e.g., a catalog of printed books or software), or any other asset, or an indication of any other asset.

Asset ID field 1902 may store an identifier (e.g., a unique identifier) for a digital asset. Type field 1904 may store an indication of the type of asset, such as ‘software’, ‘music’, ‘movie’, ‘video game’, ‘podcast’, etc. Title field 1906 may store a title associated with the asset. For example, this might be the title of software, a movie, the title of a song, the title of a class, etc. Publisher field 1908 may store an indication of the publisher who created the asset. In various embodiments, table 1900 may store an indication of any contributor to the making of a digital asset. For example, table 1900 may store an indication of a songwriter, producer, choreographer, creator, developer, author, streamer, editor, lecturer, composer, cinematographer, dancer, actor, singer, costume designer, or of any other contributor. Artist field 1910 may store an indication of the artist associated with an asset. The artist may be, for example, the singer of a song. The artist could also be the name of a production company that created the asset. Duration field 1912 may store the duration of a digital asset. For example, the duration may refer to the length of a movie, the length of a song, the number of words in a book, the number of episodes in a podcast, or to any other suitable measure of duration. Size field 1914 may store an indication of the size of the digital asset. The size may be measured in megabytes, gigabytes, or in any other suitable format. Synopsis field 1916 may store a synopsis, summary, overview, teaser, or any other descriptor of the digital asset. Reviews field 1918 may store an indication of one or more reviews that are associated with the digital asset. The reviews may come from professional critics, previous users, or from any other source. Reviews may take various forms, including a number of stars, number of thumbs up, an adjective, a text critique, an emoji, or any other form.

Referring to FIG. 20 , a diagram of an example ‘user rights/licenses to assets’ table 2000 according to some embodiments is shown. Table 2000 may store an indication of software, music, videos, games, books, educational materials, etc. that a user has acquired access to, such as through purchasing or winning a prize. Table 2000 may also store an indication of the nature of the rights or the license that a user has obtained to the acquired asset. User rights/license ID field 2002 may store an identifier (e.g., a unique identifier) for a particular instance of rights being assigned. The instance may include, for example, the assignment of a particular asset to a particular user with a particular set of rights in the asset. Asset ID field 2004 may store an indication of the asset to which rights, license and/or title have been assigned. User ID(s) field 2006 may store an indication of the user or users that has (have) acquired rights to a given asset. Rights field 2008 may store an indication of the nature of rights that have been conferred to the user in the asset. For example, the user may have acquired unlimited rights to view a movie, but not to show the movie in public. A user may have acquired rights to listen to a song up to ten times. A user may have acquired rights to download software up to five user devices. A user may have acquired rights to view an image on a particular peripheral device (e.g. she can listen to a song only via a headset that she has identified). A user may have acquired rights to play a video game for up to seventy-two hours. A user may have acquired rights to view a television series through the end of a particular season. A user may have acquired rights to download a lecture up to three times. A user may have acquired rights to use a software application on up to three devices. A user may have a right to use a movie clip in a presentation deck. A user may have a right to use software only while in a particular location. As will be appreciated, the aforementioned are but some examples according to some embodiments, and various embodiments contemplate that a user may receive other types of rights or licenses to an asset.

Referring to FIG. 21 , a diagram of an example user device state log table 2100 according to some embodiments is shown. User device state log table 2100 may store a log of what programs or apps are/were in use at any given time. Table 2100 may include what program or app was at the forefront, what web pages were open, which app was the last to receive input (e.g., user input), which app occupies the most screen real estate, which app is visible on the larger of two screens, which app is using the most processor cycles, etc. Data stored in table 2100 may, for example, help to ascertain productivity of a user. Data stored in table 2100 may help to link keystrokes (or mouse movements, or other peripheral device activity) to a particular app the user was using. For instance, data stored in table 2100 may allow a determination that a particular set of keystrokes was intended to control the Excel app. In various embodiments, table 2100 may provide snapshots over time of the prominence of different programs, apps, or other processes. Data stored in table 2100 may also be used to detect cheating in a game or educational environment. In other embodiments, it provides an indication of the level of engagement of a person participating in a meeting or video conferencing session.

In various embodiments, table 2100 does not store a comprehensive state. Rather, for example, table 2100 may indicate the state of one or more apps, programs, or processes on a user device, such as at a given point in time. In various embodiments, table 2100 may store a substantially complete indication of a state of a user device, such as at a given point in time. In various embodiments, individual rows or records in table 2100 may store a partial state of a user device (e.g., each row may store information about a single app on the user device, such as the prominence of the app). In various embodiments, a more complete or a substantially complete indication of a state of a user device may be ascertained by combining information from multiple rows of table 2100 . User device state log ID field 2102 may store an identifier (e.g., a unique identifier) of a state or partial state of a user device. User device ID field 2104 may store an indication of a user device for which the state or partial state is recorded. Time field 2106 may store an indication of a time at which the user device was in a particular state or partial state. Program/app field 2108 may store an indication of a program, app, or other process, such as a program that was running at the time indicated in field 2106 . Program/app field 2108 could also store an indication of the operating system version of the user device. Sub-app field 2110 may store an indication of a subordinate program, app, or process, such as a subordinate program that was running at the time indicated in field 2106 . The subordinate program, app, or process may be subordinate to the program, app, or process which is stored in field 2108 . For example, field 2108 may refer to a browser (e.g., to the Chrome browser), while field 2110 may refer to a particular web page that is being visited by the browser (e.g., to the Google®.com page). Prominence field 2112 may indicate the prominence of the program or app of field 2108 and/or the prominence of the subordinate program or app of field 2110 . The prominence may refer to the visibility, or other state of usage for the program, app, etc. Example prominence values may include ‘forefront’, ‘background’, ‘minimized’, ‘sleeping’, ‘first tab’, ‘50% of processor cycles’, ‘last used’, ‘full screen’, or any other indication of a state of usage, etc.

Referring to FIG. 22 , a diagram of an example ‘peripheral activity log’ table 2200 according to some embodiments is shown. Peripheral activity log table 2200 may keep track of activities of a peripheral device. Activities may include mouse movement and clicks, keystrokes, which lights on a peripheral device lit up, what direction a joystick was moved in, what image was displayed on a mouse, what direction a camera was facing, how much a headset was shaken, what direction a presentation remote is pointed, how fast an exercise bike wheel is spinning, or any other activity. Peripheral activity ID field 2202 may store an identifier (e.g., a unique identifier) of an activity in which a peripheral device was engaged. Peripheral ID field 2204 may store an indication of the peripheral device that was involved in the activity. Start time field 2206 may store the time at which the activity started. End time field 2208 may store the time at which the activity ended. For example, if an activity is a mouse motion, the activity start time may be recorded as the time when the mouse first started moving in a given direction, and the end time may be recorded as the time when the mouse either stopped moving or changed directions.

Component field 2210 may store the particular component or part of a peripheral device that was involved in an activity. The component field 2210 may store an indication of a button on a presentation remote, a key on a keyboard, a microphone on a headset, a scroll wheel on a mouse, or any other relevant component of a peripheral device. In some embodiments, the component may be the entire peripheral device, such as when an entire mouse is moved. Action field 2212 may store the action that was performed. Actions may include pressing, tapping, moving, shaking, squeezing, throwing, lifting, changing position (e.g., moving 120 mm in an ‘x’ direction and moving −80 mm in a ‘y’ direction) or any other action. Recipient program field 2214 may store the application, program, or other computer process towards which an action was directed. For example, if a user was using the program Microsoft® PowerPoint, then a given action may have been directed towards doing something in Microsoft® PowerPoint, such as advancing a slide. In some embodiments, an action may be directed towards an operating system, a browser, or to any other process. In various embodiments, peripheral device activities may be recorded at varying levels of granularity. In some embodiments, every keystroke on a keyboard may be recorded as a separate activity. In some embodiments, the typing of an entire sentence at a keyboard may be recorded as a single activity. In some embodiments, a series of related activities is recorded as a single activity. For example, when a presentation remote shakes back and forth, this may be recorded as a single shake of the presentation remote. In some embodiments, each individual motion of the presentation remote within the shake is recorded as a separate activity. As will be appreciated, various embodiments contemplate that peripheral device activities may be tracked or recorded at any suitable level of granularity.

Referring to FIG. 23 , a diagram of an example ‘peripheral sensing log’ table 2300 according to some embodiments is shown. Peripheral sensing log table 2300 may store a log of sensor readings. In various embodiments, a peripheral device may contain one or more sensors. The sensors may, from time to time (e.g., periodically, when triggered) capture a sensor reading. In various embodiments, such sensor readings may capture passive or involuntary activities, such as a user's temperature, skin conductivity, glucose levels, brain wave readings, pupil dilation, breathing rate, breath oxygen levels, or heart rate. A sensor may capture ambient conditions, such as a temperature, ambient level of lighting, ambient light polarization, ambient level of noise, air pressure, pollution level, presence of a chemical, presence of a pollutant, presence of an allergen, presence of a microorganism, wind speed, wind direction, humidity, pollen count, or any other ambient condition or conditions. In various embodiments, a sensor may capture a position, location, relative position, acceleration, movement, direction of gaze, orientation, tilt, or the like. In various embodiments, a sensor may capture any suitable data.

Sensor reading ID field 2302 may store an identifier (e.g., a unique identifier) of a particular sensor reading. Peripheral ID field 2304 may store an indication of the peripheral device at which the sensor reading has been captured. Sensor field 2306 may store an indication of which sensor has captured the reading. For example, sensor field 2306 may explicitly identify a single sensor or type of sensor from among multiple sensors that are present on a peripheral device. The sensor may be identified, for example, as a heart rate sensor. In some embodiments, a sensor may have a given identifier, serial number, component number, or some other means of identification, which may be stored in field 2306 . Start time field 2308 may store the time at which a sensor began to take a reading. End time field 2310 may store the time at which a sensor finished taking a reading. As will be appreciated, different sensors may require differing amounts of time in order to capture a reading. For instance, capturing a reading of a heart rate may require the reading to be taken over several seconds in order to allow for multiple heartbeats. Reading field 2312 may store the actual reading that was captured. For example, the field may store a graph of the acceleration of an accelerometer. In other embodiments, the reading may be a recording of an EKG signal from the start time to an end time.

Referring to FIG. 24 , a diagram of an example peripheral message log table 2400 according to some embodiments is shown. Peripheral message log table 2400 may store messages that were passed from one peripheral to another. Message ID field 2402 may store an identifier (e.g., a unique identifier) for each message that is passed. Time field 2404 may store the time of the message. In various embodiments, the time represents the time when the message was transmitted. In other embodiments, the time represents the time that the message was received by a user. In various embodiments, the time may represent some other relevant time pertaining to the message. Initiating peripheral ID field 2406 may store an indication of the peripheral device that originated or sent the message. Receiving peripheral ID field 2408 may store an indication of the peripheral device(s) that received the message. Message content field 2410 may store the content of the message. In various embodiments, a message may comprise instructions, such as instructions for the receiving peripheral device. An example instruction might be that the receiving peripheral device (e.g. presentation remote, camera, headset) light up LED light #3 for three seconds, play an attached advertising jingle, or disable the left button (e.g., of a mouse). In some embodiments, the message may include human-readable content. The content might be intended for display by the receiving peripheral device. For example, the message might include the text “Meeting room 8602 is running 20 minutes late” or “good job”, which would then be displayed by the receiving peripheral device. In various embodiments, the message may include further instructions as to how, when, where, or under what circumstances the message should be displayed.

Referring to FIG. 25 , a diagram of an example ‘generic actions/messages’ table 2500 according to some embodiments is shown. Generic actions/messages table 2500 may store a set of generic or common actions or messages that might be initiated by a user. For example, in the context of a multiplayer video game, it may be common for one team member to send to another team member a message such as “nice going”, or “cover me”. In the context of a business meeting, messages could include expressions such as “good idea” or “excellent facilitation.” In the context of an educational setting, messages might include “it's your turn” or “that answer is correct.” In situations where certain messages or actions may be commonplace, it may be beneficial that a user have a quick way of sending such messages or taking such actions. In various embodiments, there may be a shortcut for a given action. In various embodiments, the shortcut may comprise a predefined series of motions, button presses, key presses, voice commands, etc. In some embodiments, having a shortcut to sending a message or taking an action may allow a user to overcome an inherent barrier of a given peripheral device. For example, a mouse may not have keys with letters on them, so sending a custom text message using a mouse might otherwise be cumbersome. Generic action ID field 2502 may store an identifier (e.g., a unique identifier) for a particular action. Action/message field 2504 may store an actual message or action. Example messages might include, “excellent presentation” or “I have an idea”. Example actions might include a command to proceed to the next slide in a PowerPoint® presentation, an instruction to paste a stored format to a highlighted portion of a document, an instruction to order cheese pizza, or any other message action or instruction.

Referring to FIG. 26 , a diagram of an example ‘mapping of user input to an action/message’ table 2600 according to some embodiments is shown. Mapping of user input to an action/message table 2600 may store a mapping or correspondence between a user input and an associated action or message. The user input may be essentially a shortcut for the desired action or message. The user input may provide a quick or accessible means for sending what might otherwise be a more complicated or cumbersome message. The user input may provide a quick or accessible means for taking an action or issuing an instruction that would otherwise be cumbersome or difficult to specify. A user input may be, for example, a particular sequence of mouse clicks or keystrokes, movement of a presentation remote, a particular motion of the head, or any other user input. Actions might include giving a thumbs-up to another user, ordering a pizza, or any action specified in table generic actions/messages table 2500 . Mapping ID field 2602 may store an identifier (e.g., a unique identifier) for a particular mapping between a user input and an action or message. Peripheral type field 2604 may store an indication of the type of peripheral on which the user input would be valid or relevant. For example, inputting a set of alpha-numeric keys may only be valid on a keyboard. Shaking one's head may only be valid using a headset, for example.

In various embodiments, a peripheral device may be in any of two or more different modes or states. For example, a peripheral device might be in “in use” mode, or it might be in “idle” mode. For example, a peripheral device might be in “game” mode, or it might be in “work” mode. When a peripheral device is in a first mode, it may be operable to initiate one or more actions. However, when a peripheral device is in a second mode, it may not be operable to initiate one or more actions. For instance, when a peripheral device is in “game” mode, the peripheral device may be operable to send a message to a teammate with just a few predetermined keystrokes. However, when the same peripheral device is in “work” mode, the same message might, at best, be meaningless, and at worst interfere with work. Mode of peripheral field 2606 may be a mode or state of a peripheral device that is relevant to a particular action. For example, field 2606 may store a mode in which a peripheral device is operable to take an associated action. In some embodiments, field 2606 may store a mode in which a peripheral device is not operable to take an associated action. In various embodiments, a given input sequence may be valid in more than one mode of a peripheral device, however the input sequence may have different meanings in the different modes. Example modes may include action mode, messaging mode, in-use mode, idle mode, etc.

Input sequence field 2608 may store the user inputs that will trigger an associated action. User inputs may comprise a set of clicks, button presses, motions, or any other set of inputs. Action field 2610 may store an action that the user wishes to take when he provides the user inputs. The action may include a generic action from table 2500 , in which case an identifier for such an action from table 2500 may be stored in field 2610 . The action may include any other action, message, instruction or the like. In some embodiments, certain actions may be valid only when both an originating peripheral device and a receiving peripheral device are both in the proper modes. For example, in order for a text message to be sent from one peripheral device to another peripheral device, the initiating peripheral device must be in “text” mode, and the receiving peripheral device must be in “idle” mode. In such embodiments, for example, table 2600 may store modes for two peripheral devices (e.g., for both an initiating and for a receiving peripheral device). In some embodiments, the relevant mode is the mode of the receiving peripheral device. In such embodiments, for example, table 2600 made store modes for the receiving peripheral device.

Object Information

Referring to FIG. 27 , a diagram of an example objects table 2700 according to some embodiments is shown. Objects may include one or more items of interest, such as in a household. Objects may include books, toys, electronics, dishes, utensils, clothing, shoes, exercise equipment, furniture, food, etc. Objects may include fixtures, such as wall outlets, lights, windows, mirrors, floorboards, vents, doors, ceiling fans, faucets, etc. Objects may include parts or components of some larger object or structure (e.g., a leg of a couch, a corner of a room, a panel of a window, etc.). In various embodiments, objects may include inanimate or animate objects. In various embodiments, objects may include plants, pets, and/or people.

Objects may be associated with information, such as history, tasks, etc. For example, a guest interacting with an object (e.g., with a painting) may be informed about the object's history (e.g., about the artist, time of purchase, etc.). In various embodiments, a family member (e.g., a child) may be assigned tasks associated with an object. For example, a child is assigned a task to put away a toy. In various embodiments, attributes of the object can also be used to trigger warnings about associated hazards, or to prioritize tasks related to the object. For example, if an object is heavy and is elevated (e.g., a vase on the table), the object may trigger a warning to a parent if a two-year-old child comes within the vicinity of the object.

Object identifier field 2702 may include an identifier (e.g., a unique identifier) for an object.

Instantiation field 2704 may include an indication of whether the record refers to an “actual” object (e.g., to a particular toy that exists in a home), or to a “prototype” object. A record that refers to a “prototype” object may allow a camera (or the central controller) to recognize/classify new objects that it finds in the home if such objects resemble the prototype object. For example, by reference to data about a prototype sweater, the camera may be capable of recognizing a sweater in an image it captures, even if the particular sweater has never been registered with or otherwise indicated to the camera.

Description field 2706 may include description of an object, such as “vase”, “toy car”, “potted plant”, etc.

Image field 2708 may include image data (e.g., jpeg files, png files, bitmap files, compressed images, image features, etc.) for one or more images of an object. In various embodiments, the camera 4100 may reference image data in field 2708 in order to identify objects in newly captured images. In various embodiments, field 2708 may include image data for the object in one or more orientations, one or more different lighting conditions (e.g., strong light, weak light, colored light, light incident from different angles, etc.), at one or more distances, in one or more configurations (e.g., a “door” object may have associated images for the open and closed positions; e.g., a “plate” may have associated images with and without food on top of it) and/or under one or more other circumstances and/or in one or more other states. In various embodiments, a given image may be annotated or otherwise have associated information describing the state or circumstance of the object as shown in the image.

Dimensions field 2710 may include dimensions of the object, such as a length, width, and height. In various embodiments, dimensions represent dimensions of a cross-section of the object (e.g., of the widest cross-section as it might appear in an image). This may make it more convenient to identify the object from an image. In various embodiments, more complicated or involved measurements may be stored, such as dimensions of different components of an object, dimensions of an object in different configurations, or any other suitable dimensions, measurements, or the like.

Weight field 2712 may include a weight (or mass) of the object. Knowing an object's weight may allow the camera 4100 and/or central controller 110 to judge hazards, assign tasks, and/or perform any other applicable functions. For example, if an object is heavy, any task requiring moving the object may be assigned only to an adult. Also, if the object is heavy, the camera may generate a warning if there is a possibility the object might fall.

Monetary value field 2714 may include a monetary value of the object (if applicable). Objects that cannot readily be sold (e.g., a wall outlet) may not have any associated monetary value.

Sentimental value field 2716 may include a sentimental value of the object. This may be designated using any suitable scale (e.g., “high/medium/low”, 1-10, etc.).

A monetary or sentimental value may allow the camera 4100 and/or central controller 110 to assign tasks, prioritize tasks, determine what to keep and what to discard, and/or to perform any other applicable function. For example, if an object has a high sentimental value, the camera 4100 may broadcast an urgent warning if a puppy is about to chew the object.

Fragility field 2718 may include an indication of an object's fragility. For example, an object made of glass or porcelain may have a “high” associated fragility, whereas a cushion or pair of pants may have a “low” associated fragility.

Hazards field 2720 may include an indication of any potential hazards associated with an object. Hazards may include hazards to people, hazards to pets, hazards to property, and/or any other potential hazards, dangers, or inconveniences. For example, a potted plant has associated hazards of falling (e.g., falling onto a person or pet), sharding (e.g., breaking and creating sharp shards that can harm a person or pet) and staining (e.g., breaking and dispersing, mud and water).

Information about an object's fragility and/or associated hazards may allow camera 4100 and/or central controller 110 to assign tasks, prioritize tasks, generate warnings, and/or perform any other suitable function. For example, camera 4100 may prioritize tasks to put away objects that are hazardous as compared to putting away objects with no associated hazards.

Referring to FIG. 28 , a diagram of an example object history table 2800 according to some embodiments is shown. Object history table 2800 may include historical events, background information, context and/or other information about objects. With reference to object history table 2800 , camera 4100 and/or central controller 110 may recount (e.g., output) information about an object for the benefit of a user (e.g., a user who is viewing or handling the object). For example, a relative who has given an object as a gift to a child may pick up the object when they visit the child's home. The camera may then cause an output device (e.g., a projector or a television) to display a video of the child when he first opened the gift. In various embodiments, an object's history may be utilized in any other suitable fashion and/or for any other purpose.

Event identifier field 2802 may include an identifier (e.g., a unique identifier) for an event. Object identifier 2804 may include an identifier for an object that is the focus or subject of an event. In various embodiments, there may be multiple events associated with a given object, and therefore multiple rows may have the same entry for field 2804 .

Event description field 2806 may include a description of an event with which an object was involved. The object may have been a birthday gift, the object may have been purchased, the object may have been moved (e.g., when the owner brought the object along during a change of address), the object may have been worn during a significant occasion (e.g., the object may be a jersey worn during a championship game), the object may have been received as an award, the object may have been found (e.g., the object was found on a remote beach), or the object may have been part of any other event.

Date field 2808 may include a date and/or a time of the event. Location field 2810 may include a location of the event.

Party 1 field 2812 may include an indication of a first user, entity, or other party involved in an event. Party 1 function field 2814 may include an indication of the function or role that party 1 played in the event. Similarly, party 2 field 2816 and party 2 function field 2818 may include, respectively, an indication of a second party involved in an event and a function played by the second party in the event. In various embodiments, only one party is involved in an event. In various embodiments, no parties are involved. In various embodiments, more than two parties are involved.

In one or more examples, an event is the gifting of the object, party 1 is the gift recipient, and party 2 is the gift giver. In one or more examples, an event is the purchase of the object, party 1 is the seller, and party 2 is the buyer. In one or more examples party 1 is the wearer of an object. Various embodiments contemplate that parties may be involved in an event in any suitable fashion.

Assets field 2820 may include pictures, video, audio, and/or any other digital assets, and/or any other assets associated with the event and/or object.

In various embodiments, central controller 110 finds images, videos, and/or other media associated with the object on a social media platform (e.g., on Instagram®), on a website, online, and/or in any other location. The central control 110 may save such images, media, etc. in assets field 2820 .

In various embodiments, an initial image of an object may come from social media, a website, etc. The central controller 110 may find the image, determine background information about the object (e.g., from text posted to the social media platform, e.g., from the user), and then create one or more records associated with the object (e.g., in objects table 2700 , in object history database 2800 ).

Referring to FIG. 29 , a diagram of an example task table 2900 according to some embodiments is shown. Task table 2900 may include one or more tasks, such as tasks that are associated with objects. Tasks might indicate that an object should be put away (e.g., in its customary place), that an object should be cared for (e.g., polished in the case of silver, or watered in the case of plants), that an object should be fixed and/or that any other action should be taken. In various embodiments, a task does not involve a particular object (or any object at all). In various embodiments, a task involves more than one object.

Task identifier field 2902 may include an identifier (e.g., a unique identifier) for a task. Object identifier 2904 may include an identifier for an object that is the focus or subject of a task.

Assignor field 2906 may include an indication of a user who has assigned the task. This may or may not be the same user who has created the task.

Assignee field 2908 may include an indication of a user who has been assigned to perform the task.

In various embodiments, an assignee may be the central controller 110 , the camera 4100 , and/or any device or system according to various embodiments. For example, a task may specify that an object (e.g., a painting) be put in better lighting. The camera 4100 or central controller 110 may fulfill the task by directing lights, controlling lights, changing the color of lights, changing the brightness of lights, etc.

Target state field 2910 may include an indication of a target state for an object. A target state may represent a state of the object after the task has been completed. As such, the task itself may represent the process of bringing the object from its initial or current state to its target state. A target state may be for the object to be in a particular location (e.g., the task is to put the object in that location). A target state may be for the object to be clean (e.g., the task is to clean the object). A target state may be for the object to be watered (e.g., the object is a plant and the task is to water the plant). A target state may be for the object to have new batteries (e.g., the object is a clock and the task is to put new batteries in the clock).

In various embodiments, a target state represents a location of an object, a configuration of an object (e.g., a target state specifies that an item of clothing should be folded), a state of cleanliness of an object, a state of repair of an object, a position of an object relative to another object (e.g., a target state specifies that a book should be next to a companion book), a state of construction or assembly of an object (e.g., a target state specifies that a new bicycle should be assembled), and/or any other state of an object.

In various embodiments, a target state is specified in general, somewhat general, abstract, and/or non-specific terms. It may then be left up to the assignee to perform a task (e.g., in a discretionary way) which leaves the object in the target state. For example, a target state for a vase should be “not dangerous”. It may then be left to the assignee to decide where to put the vase, so long as the vase is not dangerous wherever or however it ends up. For example, the task may be adequately completed by putting the vase on any of four available shelves that are out of reach of a 2-year old child. Or the task may be adequately completed by putting the vase on its side on the ground.

In various embodiments, a target state is specified in relative terms, such as in relation to an initial or current state. In one or more examples, a target state specifies that an object should be in a “better”, “improved”, “cleaner”, “less dangerous”, and/or “better working” state, or in any other relative state. It may then be left to the assignee to decide what to do with the object to reach a state that satisfies the specified target state. In various embodiments, a target state is specified as an optimized condition or state. For example, a crystal chandelier should look as clean as possible, or as shiny as possible.

In various embodiments, a target state is conditional on one or more circumstances. For example, by default, a target state may be for a vase to be located on a coffee table, where it may be most visible. However, in the event that a toddler is present, the target state for the vase may be to be located on an upper shelf where it is out of reach of the toddler.

In various embodiments, a task may be specified in terms of a process or action rather than in terms of a final state of an object. In various embodiments, a task may be specified in any suitable fashion.

Assignee date field 2912 may include an indication of a date and/or time the task was assigned. Deadline field 2914 may include an indication of a date and/or time the task is due to be completed.

Notification method field 2916 may include an indication of a method by which the assignee of a task should be notified about the task. Notification methods may include flashing a laser pointer on the object (e.g., the object indicated in field 2904 ), shining a spotlight on the object, circling the object with a laser pointer, and/or any other highlighting of the object. These methods may catch the assignee's attention. They may also indicate to the assignee what object he will be dealing with when performing the task.

Notification methods may include an audio broadcast. In various embodiments, the central controller 110 and/or camera 4100 may cause an audible message to be output (e.g., via a speaker associated with the camera or via a standalone speaker). The message may describe the task to be performed (e.g., “dust the bookshelf”). In various embodiments, a statement of the task is projected on the wall.

Reward field 2916 may include an indication of a reward to be provided upon completion of the task (e.g., to the assignee of field 2908 ). A reward may take the form of cash, sweets, permission to play video games for a certain period of time (e.g., as granted to a child), and/or an award may take any other form.

Priority field 2918 may include an indication of a priority of a task. The priority may be indicated using any suitable scale (e.g., “high/medium/low”, 1-10, etc.). In various embodiments, the central controller 110 or camera 4100 may inform assignees of tasks based on the tasks' priorities. For example, if there are two tasks assigned to an assignee, central controller 110 may inform the assignee of the higher priority task first.

Completion date field 2920 may include an indication of a date and/or time when a task was completed. A task that is still open may be listed as “Pending” or the like, and a task that was not completed by the deadline (field 2914 ) may be listed as “Not completed” or the like.

Coaching/Instructions field 2924 may include an indication of instructions or coaching on how to perform the task. In various embodiments, the camera 4100 and/or the central controller 110 may output such instructions to the assignee of the task. For example, if a task is to water plants, instructions may specify, “pour just one cup of water”. Instructions may be output in any suitable fashion, such as via audio, display screen, projection, message to the assignee's mobile device, etc. In various embodiments, the camera 4100 and/or the central controller 110 may output instructions to an assignee step by step as needed (e.g., as performed) by the assignee.

In various embodiments, coaching/instructions may include spotlighting or highlighting (e.g., with a laser pointer or spotlight) an object or location that is pertinent to the task at hand. In one or more examples, camera 4100 causes a laser pointer to spotlight a drawer where batteries can be found (e.g., when the task is to replace the batteries in the remote control). In one or more examples, camera 4100 causes a laser pointer to trace out a path (e.g., on the floor) that an assignee should follow to reach the location where he can put away an object.

Referring now to FIG. 30 , a flow diagram of a method 3000 according to some embodiments is shown. Method 3000 may include a method for identifying an object, for associating history, tasks, and/or other information with the object, and/or for conveying the information to a user (e.g., when the user comes in contact with the object). For convenience, method 3000 will be described as being performed by camera 4200 and/or presentation remote 4100 . However, as will be appreciated, various embodiments contemplate that method 3000 may be performed by central controller 110 , by a user device, by a headset, by a peripheral device, and/or by any other device and/or combination of devices.

At step 3003 , camera 4200 may capture a second image at a second time before a first time, according to some embodiments. The second image may be an image captured from a room or other location in a house (or other building or other location), an outdoor area for a house, a shed, a garage, a patio, a porch, and/or from any other location. In various embodiments, the “second time” when the second image is captured, is before a subsequent “first time” when a “first image” is captured. The first and second images may each show at least one object in common, and thus the “first image” may show the object at a later time than does the “second image”.

In various embodiments, camera 4200 may capture a video of the object at the second time. The video may include the second image (e.g., as a frame in the video). In various embodiments, a video may allow camera 4200 to recognize a dynamic gesture made by a user (e.g., a sweep of the arm), to capture an audio clip from the user, to see the object from multiple vantage points, and/or to perform any other function.

At step 3006 , camera 4200 may identify an object in the second image. The object may be a household item, item of furniture, fixture, location, part of a larger object, and/or any other item.

Camera 4200 may use any object recognition algorithm, object classification algorithm, and/or any other method for identifying an object. In various embodiments, camera 4200 may reference data (e.g., image data 10308 ) about a prototype object (field 10304 ) or about any other object in object table 10300 . The second image may be compared to the reference data in order to identify the object in the second image. In various embodiments, a user may assist with identifying an object. For example, a user may view the second image via an app, and may enter or select information about the object.

In various embodiments, camera 4200 does not a priori seek to find any particular object or type of object. Rather, in various embodiments, camera 4200 may seek to identify any object that it finds in the second image. In various embodiments, camera 4200 may identify multiple images in the second image.

In various embodiments, camera 4200 does seek to find a particular object or type of object. In one or more examples, camera 4200 may seek to find artwork. In one or more examples, camera 4200 may seek to find antiques. In one or more examples, camera 4200 may seek to find a skateboard (or any other particular object and/or any other type of object).

In various embodiments, once identified, a record for the object may be created in objects table 10300 .

At step 3009 , camera 4200 may identify a state of the object in the second image. A state of the object may include the object's color, size (e.g., if the object is a plant), configuration, state of repair, location, orientation, an indication of a possessor of the object, an indication of a user of an object, and/or any other state of the object.

In various embodiments, a state of the object may be of future historical interest. For example, a user admiring a piece of furniture (at some future date) may be informed that the furniture used to be blue, but was later reupholstered in green. A user looking at a toy may be informed that it originally belonged to Sammy, but then was passed down to Joey.

In various embodiments, a state of the object may be of interest for future comparison (e.g., with respect to cleanliness). For example, at a future date, a user may desire to restore an object to an earlier state of shine, sparkle, smoothness, etc.

In various embodiments, a state of the object may be of interest for any suitable or applicable purpose.

At step 3012 , camera 4200 may identify a second user in the second image. The second user may be responsible for indicating, designating, and/or otherwise pointing out the object in the first place. In various embodiments, the second user may indicate, designate, and/or otherwise provide information about an object.

In various embodiments, the second user may be identified using facial recognition algorithms, face-detection algorithms, person-detection algorithms, and/or any other suitable algorithms. In various embodiments, the second user may be identified using voice recognition. For example, the second user may speak at or near the second time, when the second image is captured. In various embodiments, the second user may be identified via any biometric, any gesture, or via any other means. In various embodiments, the second user may possess a mobile phone or other electronic device or other device that produces and/or reflects a signal. Such a signal may be used as a signature or other identifier of the second user.

In various embodiments, the object is identified in the second image based on the object's relationship (e.g., physical relationship) to the second user. The object may be identified based on its proximity to the second user, based on its possession by the second user, based on the second user being in contact with the object, based on the second user pointing to the object, based on the second user looking at the object and/or based on any other relationship to the second user.

At step 3015 , camera 4200 may determine a gesture made by the second user with respect to the object. In various embodiments, the gesture serves to identify or designate the object (e.g., as an object of historical interest, as an object with which a task may become associated, etc.). In various embodiments, the gesture provides information about the object (e.g., historical information, background information, task information, a target state for the object, and/or any other information).

A gesture may take any form, in various embodiments. A gesture by the second user may include placing his hand on the object, touching the object, lifting the object, looking at the object, pointing at the object, standing next to the object, standing behind the object, holding the object, casting a shadow on the object holding his hands apart from one another (e.g., to indicate a size or measurement associated with the object), and/or making any other gesture. In various embodiments, the second user makes a gesture using an electronic device or other signal emitting (or reflecting) device. Camera 4200 may then identify the gesture based on the location and/or trajectory of the signal source.

Camera 4200 may identify, recognize, and/or interpret gestures in any suitable fashion. In various embodiments, camera 4200 identifies a user's hand (or other body part) and determines the hand's proximity to the object (e.g., determines whether the hand is in contact with the object based on the adjacency in the image of the user's hand to the object). In various embodiments, camera 4200 compares the second image (or a sequence of images) of the second user to one or more reference images, in which a given reference image is associated with a known gesture.

In various embodiments, camera 4200 determines an interaction between the object and the second user. The user may be opening a present containing the object (and thereby having his first interaction with the object). The second user may otherwise by unveiling the object. The user may be playing with the object (e.g., if the object is a toy). The user may be creating the object (e.g., if the object is a work of art, a piece of furniture, a culinary dish, etc.). The user may be watching, holding, wearing, using, sitting on, and/or otherwise interacting with the object, and/or otherwise associating with the object.

In various embodiments, camera 4200 identifies a third user in the second image. The third user may be interacting with the object and/or with the second user. For example, the third user may be gifting the object to the second user, selling the object to the second user, looking at the object with the second user, and/or otherwise interacting with or associating with the object and/or the second user.

In various embodiments, a record may be created in object history table 2800 in which an indication of the second user is stored at field 2812 (“Party 1”) and an indication of the third user is stored at field 2816 (“Party 2”). Other fields in table 2800 may be populated as appropriate (e.g., with roles for the second and third users, etc.).

At step 3018 , camera 4200 may determine, based on the gesture, the information about the object.

In various embodiments, if the second user first points at the object, then points away into the distance, the users gesture indicates that the object should be put away (e.g., the user is assigning a task to put the object away). If the user makes small circular hand movements over the object, the user's gesture indicates that the object should be cleaned. If the user points to an object, then crosses his arms in front of his face, then the gesture means the object is dangerous. If the user holds an object to his chest, then the gesture means that the object has high sentimental value. In various embodiments, gestures may have any other predetermined meaning and/or any other meaning. In various embodiments, any other type of gesture may be used.

In various embodiments, camera 4200 determines a gesture by identifying and tracking two parts of a users body (e.g., two “appendages”). In various embodiments, the two body parts are the user's face, and the users hand. In various embodiments, camera 4200 determines the distance between the two body parts at any given time, and then tracks this distance over time (e.g., over many instants in time). In various embodiments, the distance between the two body parts is sampled at regular intervals, such as at every 50 milliseconds, at every frame, or over any other suitable interval.

In various embodiments, not only the distance, but the relative positions of the two body parts are tracked over time.

In various embodiments, one of the two body parts may be regarded as fixed (e.g., the user's head may be regarded as fixed). The gesture may then be represented as a function or waveform, with the dependent variable distance as a function of the independent variable time. If full relative positions are tracked, then the independent variable may be position (e.g., a position in x, y, and z coordinates). In various embodiments, the position may be represented as a vector, such as a vector in 1, 2, or 3-dimensional space. Changes in the position of the user's body parts may be represented as a “movement vector”.

The process of gesture recognition may thereby be reduced to a process of matching a detected or determined waveform to waveforms for one or more reference gestures. In various embodiments, the reference gesture most closely matching the detected gesture (e.g., having the lowest sum-of-squares difference from the detected gesture) may be regarded as the intended gesture, and the user's meaning may be regarded as the meaning associated with the reference gesture. In various embodiments, detected gestures may be classified as reference gestures in any suitable fashion, such as by using any suitable classification algorithm.

In various embodiments, any two other body parts may be used to determine a gesture (e.g., the left and right hands, etc.). In various embodiments, more than two body parts may be used to determine a gesture. In various embodiments, a gesture may be determined in any other suitable fashion.

Further details on performing gesture recognition can be found in U.S. Pat. No. 9,697,418, entitled “Unsupervised movement detection and gesture recognition” to Shamaie, issued Jul. 4, 2017, e.g., at columns 17-20, which is hereby incorporated by reference.

In various embodiments, the second user may provide information to camera 4200 in any other fashion (e.g., in any fashion besides gestures). In various embodiments, a user provides information via an electronic device, user device and/or peripheral device. A user may interact with an app where the user can enter information about an object. The user may snap a picture of the object using a mobile phone (or other device), designate the object as an object of interest (e.g., as an object for storage in object table 2700 ), and enter information about the object (e.g., type in information, speak information, etc.).

In various embodiments, the second user holds an electronic device near to an object (e.g., touching the object). The camera detects a signal from the electronic device (e.g., a Bluetooth® or Wi-Fi® signal), determines the location of the device, and thereby determines the location of the object. The camera may then capture a picture of the object. In this way, the second user may designate the object. In various embodiments, a user designates an object by placing a marker, pattern, beacon, sticker, signaling device, and/or any other indicator on the object. For example, the user may illuminate the object with the flashlight of his mobile phone. Camera 4200 may detect the resultant spot of light, and may thereby recognize that it should store information about the object on which the light is falling.

In various embodiments, the second user verbally describes information about the object, e.g., within audible range of camera 4200 .

In various embodiments, a user wearing a headset may look at an object. The headset may include a camera, which may thereby see the object in its view. The user may designate the object, identify the object, say the name of the table, and/or provide any other information about the object. The camera 4200 may thereby associate information with the object.

In various embodiments, camera 4200 identifies an object and then asks the user to provide information about the object. The user may be asked when the image is captured and/or at a time substantially after the image is captured. For example, when a user is sitting at his home computer, the camera 4200 may communicate with the computer and cause an app on the computer to show images to the user that were captured by the camera. The app may ask the user about the images. For example, the app may provide one or more fields where the user can enter information about the images.

In various embodiments, a camera 4200 captures an image of an object but does not necessarily recognize the image. The camera may ask the user to identify the object in the image (e.g., to provide a name, type, category, brand, model, use, purpose, etc. for the object).

At step 3021 , camera 4200 may store information (which may include state information) in association with the object. Information may include state information (e.g., location, state of repair, orientation, etc.) for the object. Information may include background and/or historical information. In various embodiments, information may be stored in the form of an event, such as in object history table 2800 . For example, a user's interaction with an object may be stored as an event.

In various embodiments, camera 4200 may store actual images or footage of the second user's interaction with the object. The images and/or footage may include gestures made by the second user. In such embodiments, camera 4200 need not necessarily interpret such gestures. Rather, it may be presumed that such gestures will later be recognized by another user (e.g., a first user) to whom the footage is subsequently shown. For example, the first user will know that the gesture is telling the first user to put the object away (e.g., as part of a task).

In various embodiments, information may include a classification and/or category for an object. In various embodiments, an object may be classified as educational. A category or classification may be stored in a table such as table 2700 (classification field not shown).

Information may include task information, which may be stored, e.g., in task database 2900 . Information may include any other information about the object, about the second user, about the third user and/or about anything else.

Information may include information on dangers or hazards of an object. In various embodiments, an object may present such hazards as the potential to fall, cut, shock, create a mess, etc. In various embodiments, an object may present a hazard only under certain conditions. For example, a glass object may only be hazardous when a toddler or pet is present and able to reach the object.

In various embodiments, information may include a triggering condition which, when met, may cause a warning, alarm and/or other output to be generated. In various embodiments, a triggering condition may include the presence of a child, the presence of a pet, a predetermined proximity of a child or pet, etc. In various embodiments, a triggering condition may include that a child is heading in the direction of an object, a child is looking at an object, a child is reaching for an object, and/or any other suitable triggering condition.

At step 3024 , camera 4200 may capture a first image at a first time that is after the second time. Put another way, the second time may be a “previous time” with respect to the first time. The first image may show a first user and the object (e.g., in the same room with one another, near to one another, touching, etc.). Camera 4200 may capture the first image as part of a video (e.g., as part of routine surveillance video). Camera 4200 may capture the first image in response to a sensor reading (e.g., a motion sensor signals that there is a user in the room, so the camera takes a picture). Camera 4200 may capture the first image for any other reason.

In various embodiments, the first image is captured by a different camera (or different device) than the camera (or device) that captured the second image. The first image may be captured in a different room or different location than the second image. The first image may be captured from a different vantage point than the second image. The object may have moved between the second time when the second image was captured, and the first time when the first image is captured.

At step 3027 , camera 4200 may identify the object in the first image. Camera 4200 may identify the object using object recognition algorithms, using a beacon or signaling device placed on the object (e.g., a beacon with a unique identifying signal, an RFID tag) using the sound of an object (e.g., the sound of a wood sculpture as it is placed on a glass table), and/or based on any other property of the object.

In various embodiments, camera 4200 may identify the object using the location of the object. For example, camera 4200 may infer what an object is because of its location. For instance, if an object is on a bookshelf, camera 4200 may infer that it is a book. For example, if an object is on a shoe rack, camera 4200 may infer that it is a shoe. In various embodiments, camera 4200 may retrieve stored data about what object is typically at a given location, and may infer that an object seen at the location corresponds to the object from the stored data.

At step 3030 , camera 4200 may identify a first user in the first image. The first user may be a friend, relative and/or other houseguest and/or other user who is looking at the object. The first user may be a child and/or other family member and/or other user. The first user may be a pet. The first user may be one and the same as the second user.

In various embodiments, camera 4200 may identify an interaction of the first user and the object. The interaction may be any sort of interaction as described herein with respect to the second user (and/or with respect to any other user). The first user may be looking at, holding, using, touching, approaching, reaching for, wearing, examining, and/or otherwise interacting with the object.

In various embodiments, camera 4200 may compute a distance or “proximity” from the first user to the object. The distance may be computed in any suitable fashion. In various embodiments, the distance may be computed via triangulation, as described herein. For example, camera 4200 may compute distances and angles to each of the object and the first user, thereby obtaining a “SAS” triangle amongst the object, user, and camera. The distance between the first user and the object may then be computed based on the known sides and angle of the triangle.

In various embodiments, camera 4200 may determine if the distance between the first user and the object is less than or equal to a predetermined proximity threshold (e.g., less than or equal to two feet, less than or equal to zero). In various embodiments, if the distance is less than or equal to a predetermined proximity threshold, a triggering condition may be satisfied, and a signal may subsequently be output (e.g., projected). Various embodiments contemplate other triggering conditions, such as conditions where the user is looking at the object, looking in the direction of the object, gesturing towards the object (e.g., a “movement vector” computed for the motion of the first user's appendages is directed towards the object), holding the object, and/or interacting with and/or relating to the object in some other way. In various embodiments, a triggering condition may trigger the output of a signal. In various embodiments, different signals may be associated with (e.g., output in the event of) different triggering conditions.

At step 3033 , camera 4200 may retrieve information (which may include a stored state) associated with the object. Information may include background and/or historical information (e.g., from object table 2700 , from object history table 2800 ), task information (e.g., from task table 2900 ), images, video, text, audio, and/or any other information. Information may include a prior location of the object, a prior use of the object, an identity of an individual from which the object was received, historic purchase data for the object, a date of manufacture of the object, and/or a country of manufacture of the object. Information may include a current value of the object, a sales price for the object, a status of the object, a video associated with the object, and/or audio associated with the object.

At step 3036 , camera 4200 may output a signal based on the retrieved information. The signal may be output in any form, such as in the form of an audible broadcast, images, video, lighting, light changes, text, smells, vibrations, and/or in any other format. The signal may be output in accordance with notification method 2916 .

The signal may be a directed spotlight, laser pointer, or other lighting output or change. The signal may be output from camera 4200 (e.g., from display 4246 , speaker 4210 , light 4242 a / 4242 b , optical fibers 4272 , projector 4276 , laser pointer 4278 , smell generator 4280 , vibration generator 4282 ), from a separate speaker, display screen, projector, laser, light, and/or from any other device.

In various embodiments, the signal may be output in such a way that it is likely to be perceived by the first user. For example, the signal may be text projected on a wall in front of the first user. For example, an audio signal may be output at sufficient volume as to be heard by a user (e.g., taking into account the user's proximity to camera 4200 or other audio output device, taking into account ambient noise levels, etc.).

In various embodiments, outputting a signal may include printing a document. For example, if there is a task associated with an object, camera 4200 may cause a printer to print a document describing the task (e.g., the goal of the task, instructions for performing the tasks, etc.). In various embodiments, outputting a signal may include sending an email, text message, electronic document, and/or any other communication.

In various embodiments, the signal may convey information (e.g., literal information about the object). For example, the signal may be a picture of the object as it was 5 years ago. For example, the signal may be text describing the date and circumstances of when the object was first acquired.

In various embodiments, the signal may convey information associated with a task. The signal may provide instructions (e.g., projected text, e.g., audible instructions) describing the task and/or how to perform the task. In various embodiments, the signal may convey information about a reward associated with the task (e.g., from field 2918 ). In various embodiments, the signal may convey any other information associated with a task.

In various embodiments, the signal represents an action or a part of an action that camera 4200 is taking based on the information. If there is a task associated with the object (e.g., as stored in table 2900 ), then the signal may follow or conform to the notification method 2916 . In various embodiments, a signal is a laser beam, a laser pulse, a spotlight, or the like, that shines on the object. The resultant laser dot appearing on the object may convey to the user that there is a task associated with the object. In various embodiments, a signal is a laser beam, etc. that shines on another location, such as a location where the object should be put away, on another object with which the object is associated (e.g., a laser may alternately shine on three sculptures to show that the three are part of a set by the same artist), on a tool that the user needs to perform a task (e.g., on a screwdriver, on cleaning equipment), on a location where the object should not be placed (e.g., on a little shelf accessible to a child), on a place where the object should be connected or plugged in (e.g., an outlet where the object should be plugged in, a USB drive where the object should be connected, etc.), and/or any other location or object pertinent to the task.

In various embodiments, a signal describes a game in which the object will play a part. For example, the object may be a pillow and the game may involve 3 pillows (including the object), with the objective of stacking the three pillows in a particular arrangement. The signal may include a diagram or a rendering (e.g., projected on a wall) of how the pillows should be arranged. The signal may include a spotlight or other illumination of places where the pillows should be placed (e.g., in a row on a floor). The signal may include any other instructions or specifications for playing a game.

In various embodiments, a game is a geography-based game where a user must indicate a particular location or set of locations on a map. In various embodiments, the user must indicate a location using an object. For example, the user must toss the object (e.g., a beanbag) at a rendering of a map, and try to hit the geographic location of interest (e.g., Mount Everest). Various geographic game challenges may include showing where the “ring of fire” is located, locating a desert, pointing out a water-based route between two cities, etc.

In various embodiments, a user may interact with a map by casting a shadow on the map. For example, a user is asked to indicate the location of the state of Arkansas by casting a shadow onto that state on a map (e.g., on a projected map). In various embodiments, a user may interact with a map by pointing a laser pointer at the map, or in any other fashion.

In various embodiments, a game is an anatomy based game where the user is asked to point out bones, organs, limbs, and/or other anatomical features.

In various embodiments, the signal is a tone, a chime, a flashing light, or some other signal that may get a user's attention. In various embodiments, a signal may convey that there is danger or a warning associated with an object (e.g., a fragile object is near the edge of a table, a toddler is near a wall socket, a window is open during a storm, a pot is boiling over, a pipe is leaking, a door is unlocked at night, etc.).

In various embodiments, a signal may distract a pet, toddler, etc. from a potentially dangerous, destructive, or messy situation or encounter. For example, if a toddler is approaching a potted plant, camera 4200 may anticipate that the toddler could knock the plant over, and may therefore shine a laser pointer at a nearby toy to draw the toddlers attention to the toy. In various embodiments, camera 4200 need not necessarily anticipate a particular event, but rather may simply output a signal based on stored information or instructions. E.g., instructions associated with the plant may specify that, whenever a toddler is within 3 feet, a tone should be played, and a spotlight shined on the toy nearest the plant.

In various embodiments, camera 4200 attempts to divert an individual (e.g., user, toddler, pet) from an object by creating a distraction at least a threshold distance (e.g., a “threshold offset value”) from the object. For example, camera 4200 attempts to create a distraction at least six feet away from the object. To do so, camera 4100 may determine, in an image, a first vector between the object and the individual (e.g., user, toddler, pet), which may represent a first distance and a first direction separating the object and the individual. Camera 4100 may also identify at least one location in the image that defines a second vector with the individual. The second vector may represent a second distance and a second direction separating the location and the individual. The location is where camera 4200 will create the distraction (e.g., by projecting a laser pointer or other light to the location). As such, the camera may identify the location such that the second vector is offset from the first vector by at least a threshold offset value, e.g., the distraction is at least the threshold offset value away from the object. The camera may then determine a direction (“bearing”) from an output device (e.g., a laser pointer, light, etc.) to the location. The camera may then cause the output device to project a signal (e.g., the distracting signal) in accordance with the bearing (e.g., in the direction of the bearing).

At step 3039 , camera 4200 may verify performance of a task (e.g., a task assigned via a signal and/or otherwise associated with the signal). The camera may take a third image. The camera may identify the object in the third image. The camera may determine a location, position, configuration, and/or other state of the object. If the determined state matches target state 2910 associated with the task, then camera 4200 may determine that the task has been completed. Camera 4200 may accordingly update completion field 2922 in table 2900 with the completion date.

At step 3042 , camera 4200 may provide a reward. In various embodiments, if the task has been completed by deadline 2914 , then camera 4200 may cause reward 2918 to be provided to assignee 2908 . For example, camera 4200 may cause a stored value account associated with the assignee to be credited. Camera 4200 may notify the assignor 2906 that the task has been completed.

In various embodiments, once a task has been completed, camera 4200 may notify assignee 2908 of another task, such as the highest priority (field 2920 ) task that has been assigned to the assignee, and which has not yet been completed.

Referring to FIG. 31 , a diagram of an example shared projects table 3100 according to some embodiments is shown. Shared projects table 3100 may store information pertinent to joint, team, shared and/or collaborative work products or projects. Projects may include shared documents, collaborative workspaces, etc. Table 3100 may include data about the work product itself (e.g., an in-progress document), identities of contributors or collaborators to a project, a record of project states over time, historical snapshots of the project, goals for the project, checklist for the project, dependencies of different components of the project, or any other aspect of the project. Project ID field 3102 may store an identifier, (e.g., a unique identifier) for a project (e.g., for a shared project). Project type field 3104 may include an indication of the type of project. Example project types may include text document, spreadsheet, presentation deck, whiteboard, architectural design, paintings, sculptures, drawings, virtual visual arrangements of interiors, music, or any other project type. Participants field 3106 may store an indication of participants in the project. Participants may include contributors, collaborators, reviewers, or other stakeholders. Data field 3108 may include data about the work product. For example, if the project is to construct a text document, then field 3108 may include the text that has been generated so far. If the project is to create an advertising flyer, then field 3108 may include the text copy and the images that are to appear on the flyer. As will be appreciated, the data may take many other forms, and the form of the data may depend on the nature of the project.

Referring to FIG. 32 , a diagram of an example of a ‘shared project contributions’ table 3200 according to some embodiments is shown. Shared project contributions table 3200 may record the individual contributions made by participants in shared projects. Contribution ID field 3202 may include an identifier (e.g., a unique identifier) of a contribution made to a project. Project ID field 3204 may include an indication of a project to which the contribution was made. The indication may be, for example, a project identifier that cross references to table 3100 . Participant ID field 3206 may include an indication of the participant or participants who made a particular contribution. Time of contribution field 3208 may store an indication of the time at which a contribution was made. Contribution type field 3210 may store an indication of the type of contribution that was made. A contribution may take various forms, in various embodiments. A contribution might add directly to the final work product. For example the contribution may be a paragraph in a text document. The contribution may be an idea or direction. The contribution may be feedback on a suggestion made by someone else. The contribution may be feedback on an existing work product. The contribution may be a datapoint that a contributor has researched which informs the direction of the project. The contribution may take the form of a message that is exchanged in a chat or messaging area. A contribution may be a rating of the quality of the content created to that point. A contribution may be made in any applicable fashion or form. In various embodiments, contribution type field 3210 may store a place or location to which the contribution was made (e.g., “main document”, “chat window”). In various embodiments, field 3210 may store the nature of the contribution. The nature of the contribution may be, for example, ‘background research’, ‘work product’, ‘suggestion’, ‘vote’, ‘expert opinion’, ‘edit’, ‘correction’, ‘design’, and so on. Contribution content field 3212 may store the content or substance of the contribution. For example, if the contribution was for the user to write part of a document, then field 3212 may store the text of what the user wrote. If the contribution was an image, then field 3212 may store the image or a link to the image. If the contribution was a suggestion, field 3212 may store the text of the suggestion. As will be appreciated, various embodiments contemplate a contribution may be stored in other forms.

Referring to FIG. 33 , a diagram of an example of advertisement table 3300 according to some embodiments is shown. Advertisement table 3300 may include information about one or more advertisements, promotions, coupons, or other marketing material, or other material. In various embodiments, an advertisement may be presented to a user. An advertisement may be presented to a user in various modalities, such as in a visual form, in audio form, in tactile form, or in any other applicable form. An advertisement may be presented via a combination of modalities, such as via visual and audio formats. In various embodiments, an advertisement may be presented to a user via one or more peripheral devices. For example, an advertisement may be displayed on a display screen built into a presentation remote. In another example, the advertisement is a message spelled out by sequentially lighting up individual keys of a user's keyboard. In various embodiments, an advertisement may be presented to a user via one or more user devices. Advertisement table 3300 may store the content of an advertisement, instructions for how to present the advertisement, instructions for what circumstances the advertisement should be presented under, or any other information about the advertisement. Advertisement ID field 3302 may store an identifier (e.g., a unique identifier) for an advertisement. Advertiser field 3304 may store an indication of an advertiser that is promoting the advertisement. For example, the advertiser may be a company with products to sell.

Ad server or agency field 3306 may store an indication of an ad server, an advertising agency, or other intermediary that distributed the ad. Target audience demographics field 3308 may include information about a desired target audience. Such information may include demographic information, e.g., age, race, religion, gender, location, marital status, income, etc. A target audience may also be specified in terms of one or more preferences (e.g., favorite pastimes, favorite types of vacations, favorite brand of soap, political party). A target audience may also be specified in terms of historical purchases, or other historical behaviors. In some embodiments, a target audience may be specified in terms of video game preferences. Such preferences may be readily available, for example, to a game server. Various environments contemplate that a target audience may be specified in any suitable form, and/or based on any suitable information available. Ad trigger field 3310 may store an indication of what events or circumstances should trigger the presentation of an ad to a user. Events may include an initiation of gameplay by the user, a change in a user's performance while playing a game (e.g., a user's rate of play slows down 10%), a certain level being achieved in a game, a certain score being achieved in a game, or any other situation that occurs in a game. Triggers for presenting advertisements may include ambient factors, such as the temperature reaching a certain level, the noise level exceeding a certain threshold, pollution levels reaching a certain level, humidity reaching a certain level, or any other ambient factors. Triggers may include times of day, e.g., the time is 4 PM. Various embodiments contemplate that any suitable trigger for an advertisement may be used.

In various embodiments, limits field 3312 may store limits or constraints on when an ad may or must be presented, or under what circumstances an ad may be presented. For example, a limit may specify that no more than one thousand ads per day are to be presented across all users. As another example, a limit may specify that a maximum of two of the same advertisements may be presented to a given user. As another example, a constraint may specify that an ad should not be presented between the hours of 11 p.m. and 8 a.m. Another constraint may specify that an ad should not be presented when a mouse is in use (e.g., the ad may be intended for presentation on the mouse, and it may be more likely that the ad is seen if the user is not already using the mouse for something else). Various embodiments contemplate that any suitable constraints on the presentation of an advertisement may be specified. Presenting devices field 3314 may indicate which types of devices (e.g., which types of peripheral devices, which types of user devices), and/or which combination of types of devices, should be used for presenting an advertisement. Example presenting devices may include: a keyboard; a mouse; a PC with mouse; a tablet; a headset; a presentation remote; an article of digital clothing; smart glasses; a smartphone; or any other device; or any other device combination. Modality(ies) field 3316 may indicate the modalities with which an advertisement may or must be presented. Example modalities may include video; tactile; video and LED; image and tactile; heating, or any other modality or combination of modalities. In various embodiments, when an advertisement is presented, it is presented simultaneously using multiple modalities. For example, a video of a roller coaster may be displayed while a mouse simultaneously rumbles. As another example, an image of a relaxing ocean resort may be presented while a speaker simultaneously outputs a cacophony of horns honking (as if to say, “get away from the noise”). Ad content field 3318 may store the actual content of an advertisement. Such content may include video data, audio data, tactile data, instructions for activating lights built into peripheral devices or user devices, instructions for activating heating elements, instructions for releasing fragrances, or any other content or instructions.

Referring to FIG. 34 , a diagram of an example of ‘advertisement presentation log’ table 3400 according to some embodiments is shown. Advertisement presentation log 3400 may store a log of which ads were presented to which users and when, in various embodiments. Advertisement presentation ID field 3402 may store an identifier (e.g., a unique identifier) of an instance when an ad was presented to a user. Advertisement ID field 3404 may store an indication of which advertisement was presented. User ID field 3406 may store an indication of the user to whom the ad was presented. Presentation device field 3408 may store an indication of one or more devices (e.g., user devices, peripheral devices) through which the ad was presented. For example, field 3408 may store an indication of a presentation remote on which a video was presented. In another example, field 3408 may store an indication of a keyboard and a speaker through which an ad was presented (e.g., using two different modalities simultaneously). Time field 3410 may store an indication of when the ad was presented. User response field 3412 may store an indication of how the user responded to the ad. Example responses might include, the user clicked on the ad, the user opened the ad, the user viewed the ad, the user responded with their email address, the user made a purchase as a result of the ad, the user forwarded the ad, the user requested more information, the user agreed to receive product updates via email, the user's heart rate increased after viewing the ad, the user took a recommendation made in the ad, the user had no response to the ad, or any other response.

Referring to FIG. 35 , a diagram of an example of ‘AI models’ Table 3500 according to some embodiments is shown. As used herein, “AI” stands for artificial intelligence. An AI model may include any machine learning model, any computer model, or any other model that is used to make one or more predictions, classifications, groupings, visualizations, or other interpretations from input data. As used herein, an “AI module” may include a module, program, application, set of computer instructions, computer logic, and/or computer hardware (e.g., CPU's, GPU's, tensor processing units) that instantiates an AI model. For example, the AI module may train an AI model and make predictions using the AI model. AI Models Table 3500 may store the current ‘best fit’ model for making some prediction, etc. In the case of a linear model, table 3500 may store the ‘best fit’ values of the slope and intercept. In various embodiments, as new data comes in, the models can be updated in order to fit the new data as well.

For example, central controller 110 may wish to estimate a user's skill level at a video game based on just a few minutes of play (this may allow the central controller, for example, to adjust the difficulty of the game). Initially, the central controller may gather data about users' actions within the first few minutes of the video game, as well as the final score achieved by the users in the game. Based on this set of data, the central controller may train a model that predicts a user's final score in a game based on the user's actions in the first few minutes of the game. The predicted final score may be used as a proxy for the user's skill level. As another example, a central controller may wish to determine a user's receptivity to an advertisement based on the motions of the user's head while the user views the advertisement. Initially, the central controller 110 may gather data from users who watch an advertisement and subsequently either click the advertisement or ignore the advertisement. The central controller may record users' head motions while they watch the advertisement. The central controller may then train a model to predict, based on the head motions, the chance that the user will click the advertisement. This may allow the central controller, for example, to cut short the presentation of an ad if it is clear that the user is not receptive to the ad.

AI Model ID field 3502 may store an identifier (e.g., a unique identifier) for an AI model. Model type field 3504 may store an indication of the type of model. Example model types may include ‘linear regression’, ‘2nd degree polynomial regression’, ‘neural network’, deep learning, backpropagation, and so on. Model types may be specified in terms of any desired degree of specificity (e.g., the number of layers in a neural network, the type of neurons, the values of different hyperparameters, etc.). ‘X’ data source field 3506 may store information about the input data that goes into the model. Field 3506 may indicate the source of the data, the location of the data, or may store the data itself, for example. Example input data may include game scores after the first five minutes of play for game gm14821, or the content of team messages passed for game gm94813. ‘Y’ data source field 3508 may store information about the data that is intended to be predicted by the model. This may also be data that is used to train the model, to validate the model, or to test the model. Field 3508 may indicate the source of the data, the location of the data, or may store the data itself, for example. Example output data may include final game scores for game gm14821, or final team scores for game gm94813. For example, a team's final score may be predicted based on the content of the messages that are being passed back and forth between team members. This may help to determine whether a team can improve its methods of communication.

Parameter Values field 3510 may store the values of one or more parameters that have been learned by the model, or which have otherwise been set for the model. Examples of parameters may include a slope, an intercept, or coefficients for a best fit polynomial. Accuracy field 3512 may store an indication of the accuracy of the model. The accuracy may be determined based on test data, for example. As will be appreciated, accuracy may be measured in a variety of ways. Accuracy may be measured in terms of a percentage of correct predictions, a root mean squared error, a sensitivity, a selectivity, a true positive rate, a true negative rate, or in any other suitable fashion. Last update field 3514 may store an indication of when the model was last updated. In various embodiments, the model may be retrained or otherwise updated from time to time (e.g., periodically, every day). New data that has been gathered may be used to retrain the model or to update the model. This may allow the model to adjust for changing trends or conditions. Update trigger field 3516 may store an indication of what would trigger a retraining or other update of the model. In some embodiments, a retraining is triggered by a date or time. For example, a model is retrained every day at midnight. In some embodiments, the model is retrained when a certain amount of new data has been gathered since the last retraining. For example, a model may be retrained or otherwise updated every time 1000 new data points are gathered. Various other triggers may be used for retraining or updating a model, in various embodiments. In various embodiments, a person may manually trigger the retraining of a model.

Referring to FIG. 36 , a diagram of an example authentication table 3600 according to some embodiments is shown. Authentication table 3600 may store user data, such as biometric data, that can be used to authenticate the user the next time it is presented. In various embodiments, table 3600 may store multiple items of user data, such as multiple items of biometric data. Different applications may call for different types or different combinations of user data. For example, a very sensitive application may require a user to authenticate himself using three different points of data, such as fingerprint, voiceprint, and retinal scan. A less sensitive application may require only a single point of data for a user to authenticate himself. Authentication ID field 3602 may store an identifier (e.g., a unique identifier) that identifies the authentication data. User ID field 3604 may store an indication or identifier for a user, i.e., the user to whom the data belongs. Image(s) field 3606 may store an image of the user. These may be images of a user's eye, ear, overall face, veins, etc. Fingerprint images field 3608 may store fingerprint data for the user, such as images of the user's fingerprint. Retinal scans field 3610 may store one or more retinal or iris scans for the user. Voiceprint field 3612 may store voice data, voiceprint data, voice recordings, or any other signatures of a user's voice. Gait field 3614 may store body movements of a user. Head movement field 3616 may store the direction in which a user's head is pointing, head movements up and down, side to side, and angle of lean. In various embodiments, other types of data may be stored for a user. These may include other types of biometric data, such as DNA, facial recognition, keystroke data (e.g., a series of keystrokes and associated timestamps), electrocardiogram readings, brainwave data, location data, walking gait, shape of ear, or any other type of data. In various embodiments, data that is personal to a user and/or likely to be known only by the user may be stored. For example, the name of the user's first pet, or the users favorite ice cream may be stored.

In various embodiments, when a user is to be authenticated, the user presents information, and the information presented is compared to user information on file in table 3600 . If there is a sufficient match, then it may be concluded that the user is in fact who he claims to be. In one embodiment, after a user is authenticated, the central controller 110 looks up the user in employee table 5000 (or in some embodiments user table 700 ) to verify that the user is clear to work with objects in a particular location. For example, one user might be cleared to use a particular chemical, but is not allowed into a room because a different chemical is present which the user is not cleared to handle. So even though the user is authenticated, they may not have the right credentials as a user for the chemical in that particular location. Examples of things that may require a level of authentication include radioactive elements, hazardous chemicals, dangerous machinery, government contracts, encryption keys, weapons, company sensitive information such as financials or secret projects, personnel information such as salary data, confined space entry, etc.

Referring to FIG. 37 , a diagram of an example privileges table 3700 according to some embodiments is shown. Privileges table 3700 may store one or more privileges that are available to a user, together with criteria that must be met for the user to receive such privileges. For example, one privilege may allow a user to read a document, and the user may be required to provide a single datapoint to prove his identity (i.e., to authenticate himself). As another example, a privilege may allow a user to delete a document, and the user may be required to provide three data points to prove his identity. The different number of data points required by different privileges may reflect the potential harm that might come about from misuse of a privilege. For example, deleting a document may cause more harm than can be caused merely by reading the document. Privilege ID field 3702 may store an identifier (e.g., a unique identifier) of a privilege that may be granted to a user. Privilege field 3704 may store an indication of the privilege that is to be granted. ‘Points of authentication required’ field 3706 may store an indication of the amount of authenticating or identifying information that would be required of a user in order to receive the privilege. In various embodiments, the amount of authenticating information required may be specified in terms of the number of data points required. For example, if two data points are required, then the user must provide two separate items of information, such as a retinal scan and a fingerprint. In some embodiments, some data points may carry more weight than others in terms of authenticating a user. For example, a retinal scan may be worth three points, whereas a fingerprint may be worth only two points. In this case, a user may satisfy an authentication requirement by using any combination of information whose combined point value meets or exceeds a required threshold. As will be appreciated, a user may be required to meet any suitable set of criteria in order to be granted a privilege. In one embodiment, the number of authentication points required may vary by the job title of a user, for example, a senior safety manager may require less authentication than a lower-level user.

Authentication

In various embodiments, various applications can be enhanced with authentication protocols performed by a peripheral, user device 107 a , central controller 110 , and/or other device. Information and cryptographic protocols can be used in communications with other users and other devices to facilitate the creation of secure communications, transfers of money, authentication of identity, and authentication of credentials. Peripheral devices could be provided to a user who needs access to sensitive areas of a company, or to sensitive information. The peripheral might be issued by the company and come with encryption and decryption keys securely stored in a data storage device of the peripheral. In various embodiments, encryption is an encoding protocol used for authenticating information to and from the peripheral device. Provided the encryption key has not been compromised, if the central controller can decrypt the encrypted communication, it is known to be authentic. Alternatively, the cryptographic technique of “one-way functions” may be used to ensure communication integrity. As used herein, a one-way function is one that outputs a unique representation of an input such that a given output is likely only to have come from its corresponding input, and such that the input can not be readily deduced from the output. Thus, the term one-way function includes hashes, message authenticity codes (MACs—keyed one-way functions), cyclic redundancy checks (CRCs), and other techniques well known to those skilled in the art. See, for example, Bruce Schneier, “Applied Cryptography,” Wiley, 1996, incorporated herein by reference. As a matter of convenience, the term “hash” will be understood to represent any of the aforementioned or other one-way functions throughout this discussion.

Tamper Evidence/Resistance

One or more databases according to various embodiments could be stored within a secure environment, such as within a secure enterprise or off-premises datacenter within locked doors and 24/7 security guards, or in a cloud computing environment managed by a third party storage/compute provider such as Google® Cloud or Amazon® Web Services. These databases could be further secured with encryption software that would render them unreadable to anyone without access to the secure decryption keys. Encryption services are commonly offered by cloud database storage services. Security could be used to protect all databases according to various embodiments, or it could be applied only to select databases—such as for the storage of user passwords, financial information, or personal information. An alternative or additional form of security could be the use of tamper evident or tamper resistant enclosures for storage devices containing databases. For example, a dedicated computer processor (e.g., processor 605 ) may have all of its components—including its associated memory, CPU and clock housed in a tamper-resistant and/or tamper-evident enclosure to prevent and reveal, respectively, tampering with any of these components. Tamper-evident enclosures include thermoset wraps which, upon inspection, can reveal any attempt to physically open the structure. Tamper-resistant structures may electronically destroy the memory contents of data should a player try to physically open the structure.

Devices and Interactions

With reference to FIG. 38 , a computer mouse 3800 according to some embodiments is shown. The mouse has various components, including left button 3803 , right button 3806 , scroll wheel 3809 , sensors 3812 a and 3812 b , screen 3815 , lights 3818 a and 3818 b , speaker 3821 , and cord 3824 . In various embodiments, hardware described herein (e.g., mouse 3800 ) may contain more or fewer components, different arrangements of components, different component appearances, different form factors, or any other variation. For example, in various embodiments, mouse 3800 may have a third button (e.g., a center button), may lack a cord (e.g., mouse 3800 may be a wireless mouse), may have more or fewer sensors, may have the screen in a different location, or may exhibit any other variation. In various embodiments, screen 3815 may be a display screen, touch screen, or any other screen. Screen 3815 may be a curved display using LCD, LED, mini-LED, TFT, CRT, DLP, or OLED technology or any other display technology that can render pixels over a flat or curved surface, or any other display technology. Screen 3815 may be covered by a chemically tempered glass or glass strengthened in other ways, e.g., Gorilla® Glass®, or covered with any other materials to stand up to the wear and tear of repeated touch and reduce scratches, cracks, or other damage. One use of a display screen 3815 is to allow images or video, such as dog image 3830 , to be displayed to a user. Such an image could be retrieved from user table 700 (e.g., field 726 ) by central controller 110 . Images displayed to a user could include game updates, game tips, game inventory lists, advertisements, promotional offers, maps, work productivity tips, images of other players or co-workers, educational images, sports scores and/or highlights, stock prices, news headlines, and the like. In some embodiments, display screen 3815 displays a live video connection with another user which may result in a greater feeling of connection between the two users. Sensors 3812 a and 3812 b may be contact sensors, touch sensors, proximity sensors, heat sensors, fingerprint readers, moisture sensors, or any other sensors. Sensors 3812 a and 3812 b need not be sensors of the same type. Sensors 3812 a and/or 3218 b may be used to sense when a hand is on the mouse, and when to turn display 3830 off and on.

With reference to FIG. 39 , a computer keyboard 3900 according to some embodiments is shown. The keyboard has various components, including keys 3903 , a screen 3906 , speakers 3909 a and 3909 b , lights 3912 a and 3912 b , sensors 3915 a and 3915 b , microphone 3920 , optical fibers 3928 , 3930 a , 3930 b , and 3930 c , and memory and processor 3925 . In various embodiments, the keyboard is wireless. In some embodiments, the keyboard 3900 may connect to a user device, e.g., user device 106 b (or other device), via a cord (not shown). Keyboard 3900 could be used by a user to provide input to a user device or to central controller 110 , or to receive outputs from a user device or from central controller 110 . Keys 3903 can be pressed in order to generate a signal indicating the character, number, symbol, or function button selected. It is understood that there may be many such keys 3903 within keyboard 3900 , and that more or fewer keys 3903 may be used in some embodiments. Keys 3903 may be physical keys made of plastic. In some embodiments, keys 3903 are virtual keys or physical keys with display screens on top that can be programmed to display characters on top of the key which can be updated (e.g., updated at any time). Screen 3906 may include any component or device for conveying visual information, such as to a user. Screen 3906 may include a display screen and/or a touch screen. Screen 3906 may include a CRT screen, LCD screen, plasma screen, LED screen, mini-LED screen, OLED screen, TFT screen, DLP screen, laser projection screen, virtual retinal display, or any other screen, and it may be covered by a chemically tempered glass or glass strengthened in other ways, e.g., Gorilla® Glass®, or covered with any other materials to stand up to the wear and tear of repeated touch—and reduce scratches, cracks, or other damage. In some embodiments, displayed visual information can include game tips, game inventory contents, images or other game characters such as teammates or enemy characters, maps, game achievements, messages from one or more other game players, advertisements, promotions, coupons, codes, passwords, secondary messaging screens, presentation slides, data from a presentation, images of other callers on a virtual call, text transcriptions of another user, sports scores and/or highlights, stock quotes, news headlines, etc. In some embodiments, two players are using a keyboard 3900 with both keyboards connected through central controller 110 . In these embodiments, one player can type a message using keys 3903 with the output of that typing appearing on screen 3906 of the other player. In some embodiments screen 3906 displays video content, such as a clip from a game in which one user scored a record high number of points, or a message from a company CEO. In some embodiments, light sources such as lasers, LED diodes, or other light sources, can be used to light up optical fibers 3928 , 3930 a , 3930 b , and 3930 c with a choice of colors; in some embodiments, the colors controlled by central controller 110 for the keyboards of various players in a game, or various participants in a meeting, can be synchronized, or used to transmit information among players or participants, e.g. when players or participants are available, unavailable, away for a time, in “do not disturb” mode, or any other status update that is desired.

Speakers 3909 a and 3909 b can broadcast sounds and audio related to games, background music, game character noises, game noises, game environmental sounds, sound files sent from another player, etc. In some embodiments, two game players can speak to each other through microphone 3920 , with the sound being transmitted through microphone 3920 to memory and processor 3925 and then to central controller 110 to speakers 3915 a and 3915 b on the other player's keyboard 3900 . Lights 3912 a and 3912 b can illuminate all or part of a room. In some embodiments, suitable lighting technology could include LED, fluorescent, or incandescent. In various embodiments, lights 3912 a and 3912 b can serve as an alerting system to get the attention of a user such as a game player or a virtual meeting attendee by flashing or gradually increasing the light's intensity. In some embodiments, one user can send a request signal to memory and processor 3920 to flash the lights 3915 a and 3915 b of the other users keyboard 3900 . Sensors 3915 a and 3915 b may include mechanical sensors, optical sensors, photo sensors, magnetic sensors, biometric sensors, or any other sensors. A sensor may generate one or more electrical signals to represent a state of a sensor, a change in state of the sensor, or any other aspect of the sensor. For example, a contact sensor may generate a “1” (e.g., a binary one, e.g., a “high” voltage) when there is contact between two surfaces, and a “0” (e.g., a binary “0”, e.g., a “low” voltage) when there is not contact between the two surfaces. A sensor may be coupled to a mechanical or physical object, and may thereby sense displacement, rotations, or other perturbations of the object. In this way, for example, a sensor may detect when a surface has been touched, when a surface has been occluded, or when any other perturbation has occurred. In various embodiments, sensors 3915 a and 3915 b may be coupled to memory and processor 3925 , and may thereby pass information on to central controller 110 or to a room controller.

Microphone 3920 can pick up audible signals from a user as well as environmental audio from the surroundings of the user. In one embodiment, microphone 3920 is connected to memory and processor 3925 . Memory and processor 3925 allows for the storage of data and processing of data. In one embodiment, memory and processor 3925 is connected to central controller 110 and can send messages to other users, receive files such as documents or presentations, store digital currencies or financial data, store employee ID numbers, store passwords, store cryptographic keys, store photos, store video, and store biometric values from the keypad and store them for processing. In various embodiments, memory and processor 3925 can communicate via wired or wireless network with central controller 110 and house controller 6305 . Memory and processor 3925 may include memory such as non-volatile memory storage. In some embodiments, this storage capacity could be used to store software, user images, business files (e.g. documents, spreadsheets, presentations, instruction manuals), books (e.g., print, audio), financial data (e.g. credit card information, bank account information), digital currency (e.g., Bitcoin™), cryptographic keys, user biometrics, user passwords, names of user friends, user contact information (e.g., phone number, address, email, messaging ID, social media handles), health data (e.g. blood pressure, height, weight, cholesterol level, allergies, medicines currently being taken, age, treatments completed), security clearance levels, message logs, GPS location logs, and the like.

Various embodiments contemplate the use of diffusing fiber optics, such as optical fiber 3928 or shorter strand optical fibers 3930 a , 3930 b , and 3930 c . These may include optical glass fibers where a light source, such as a laser, LED light, or other source is applied at one end and emitted continuously along the length of the fiber. As a consequence, the entire fiber may appear to light up. Optical fibers may be bent and otherwise formed into two or three dimensional configurations. Furthermore, light sources of different or time varying colors may be applied to the end of the optical fiber. As a result, optical fibers present an opportunity to display information such as a current state (e.g., green when someone is available and red when unavailable), or provide diverse and/or visually entertaining lighting configurations.

With reference to FIG. 40 , a headset 4000 according to some embodiments is shown. Headband 4002 may serve as a structural element, connecting portions of the headset that are situated on either side of the user's head. The headband may also rest on the user's head. Further, the headband may serve as a conduit for power lines, signal lines, communication lines, optical lines, or any other communication or connectivity between attached parts of the headset. Headband 4002 may include slidable components 4004 a and 4004 b (e.g., “sliders”), which may allow a user to alter the size of the headband to adjust the fit of the headset. Slidable component 4004 a may attach to base 4006 a and slidable component 4004 b may attach to base 4006 b . Right base 4006 a and left base 4006 b connect into slidable components 4004 a and 4004 b , and connect to housing 4008 a and 4008 b . In various embodiments, one or both of the left and right housings may comprise other electronics or other components, such as a processor 4055 , data storage 4057 , network port 4060 , heating element 4065 , or any other components. The left and right speakers 4010 a and 4010 b may broadcast sound into the users left and right ears, respectively. Right cushion 4012 a may substantially cover right speaker 4010 a , thereby enclosing the right speaker. Right speaker cushion 4012 a may be padded along its circumference to surround a user's right ear, and provide a comfortable contact surface for the user. Right speaker cushion 4012 a may include perforations or other transmissive elements to allow sound from the left speaker to pass through to the user's ear. Left speaker cushion 4012 b may have analogous construction and function for the user's left ear.

In various embodiments, one of right speaker cushion 4012 a or left speaker cushion 4012 b includes one or more tactile dots 4035 . A tactile dot may include a small elevated or protruding portion designed to make contact with the user's skin when the headset 4000 is worn. This could allow for embodiments in which processor 4055 could direct a haptic signal to alert a user via tactile dots 4035 , or direct heat via heating element 4065 , or provide a puff of air. As the headset may have a similar appearance from the front and from the back, a tactile dot (when felt on the appropriate side) may also serve as a confirmation to the user that the headset is facing in the proper direction. A microphone 4014 together with microphone boom 4016 may extend from base 4006 b , placing the microphone in a position where it may be proximate to a user's mouth. Headset 4000 may include one or more camera units 4020 . Two forward-facing cameras 4022 a and 4022 b are shown atop the headband 4002 . In some embodiments, two such cameras may provide stereoscopic capability. An additional camera (e.g., a backward facing camera) (not shown) may lie behind camera unit 4020 and face in the opposite direction. Camera unit 4020 may also include a sensor 4024 such as a rangefinder or light sensor. Sensor 4024 may be disposed next to forward facing camera 4022 a . In some embodiments, sensor 4024 may be a laser rangefinder. The rangefinder may allow the headset to determine distances to surrounding objects or features. In one embodiment, sensor 4024 includes night vision capability which can provide data to processor 4055 , which can in some embodiments direct the user in gameplay to avoid danger, capture enemies, or perform other enhanced maneuvers. Camera unit 4020 may include one or more lights 4026 which can help to illuminate objects captured by forward facing cameras 4022 a - b.

Buttons 4030 a and 4030 b , may be available to receive user inputs. Exemplary user inputs might include instructions to change the volume, instructions to activate or deactivate a camera, instructions to mute or unmute the user, or any other instructions or any other inputs. In various embodiments, headset 4000 may include one or more additional input components. In some embodiments, an extendible stalk 4028 is included to allow the camera unit 4020 to be raised to a higher level, which could allow for sampling of air quality at a higher level, for example. In some embodiments, extendible stalk 4028 may be bendable, allowing a user to position camera unit 4020 at various angles.

In various embodiments, headset 4000 may include one or more attachment structures 4037 a and 4037 b consisting of connector points for motion sensors, motion detectors, accelerometers, gyroscopes, and/or rangefinders. Attachment structures 4037 a and 4037 b may be electrically connected with processor 4055 to allow for flow of data between them. Attachment structures 4037 a and 4037 b could include one or more points at which a user could clip on an attachable sensor 4040 . In some embodiments, standard size structures could enable the use of many available attachable sensors, enabling users to customize their headset with just the types of attachable sensors that they need for a particular function. For example, a firefighter might select several types of gas sensors to be worn on the headset, or even attach a sensor for a particular type of gas prior to entering a burning building suspected of containing that gas. In another embodiment, the attachment structures 4037 a and 4037 b could be located on other portions of headset 4000 such as on speakers 4010 a - b or on bases 4006 a - b . The attachable sensors 4040 may be used to detect a user's head motions, such as nods of the head or shaking of the head. The sensors may be used for other purposes, too. In some embodiments, a user may take a sensor from attachment structures 4037 a or 4037 b and clip it to their clothing (or to another user's clothing) and then later return the sensor to attachment structures 4037 a or 4037 b.

In various embodiments, instead of forward facing cameras 4022 a - b (or instead of a backward facing camera), headset 4000 may include a 360-degree camera on top of headband 4002 within camera unit 4020 . This may allow for image capture from all directions around the user. In some embodiments, microphone boom lights 4044 may be capable of illuminating the user, such as the user's face or skin or head or other body part, or the user's clothing, or the user's accessories, or some other aspect of the user. In other embodiments, headband lights 4042 a and 4042 b may be disposed on headband 4002 , facing away from a prospective user. Such lights might have visibility to other users, for example. When activated, such lights might signal that the user has accomplished something noteworthy, that it is the user's turn to speak, that the user possesses some rank or office, or the lights may have some other significance, some aesthetic value, or some other purpose.

Display 4046 may be attached to microphone boom 4016 . In various embodiments, display 4046 faces inwards towards a prospective user. This may allow a user to view graphical information that is displayed through his headset. In various embodiments, display 4046 faces outwards. In various embodiments, display 4046 is two-sided and may thereby display images both to the user and to other observers. In various embodiments, an inward facing display and an outward facing display need not be part of the same component, but rather may comprise two or more separate components. Headband display 4048 may be disposed on headband 4002 , e.g., facing away from a prospective user, and may thereby display images to other observers.

Cushion sensor 4050 may be disposed on right cushion 4012 a . When the headset is in use, cushion sensor 4050 may be in contact with a user's skin. The sensor may be used to determine a user's skin hydration, skin conductivity, body temperature, heart rate, or any other vital sign of the user, or any other signature of the user. In various embodiments, additional sensors may be present, such as on left cushion 4012 b . Cushion sensor 4050 may be used as a haptic for feedback to the user, to impart some sensory input, which may be a buzzing, a warm spot, or any other sensory information. In various embodiments, additional sensors may be present, such as on left cushion 4012 b . Cable 4052 may carry power to headset 4000 . Cable 4052 may also carry signals (e.g., electronic signals, e.g., audio signals, e.g., video signals) to and from the headset 4000 . Cable 4052 may terminate with connector 4054 . In some embodiments, connector 4054 is a USB connector.

Terminals 4067 a and 4067 b may lead into speaker bases 4006 a and 4006 b , and may serve as an attachment point for electronic media, such as for USB thumb drives, for USB cables, or for any other type of media or cable. Terminals 4067 a - b may be a means for charging headset 4000 (e.g., if headset 4000 is wireless). data storage 455 may comprise non-volatile memory storage. In some embodiments, this storage capacity could be used to store software, user images, business files (e.g. documents, spreadsheets, presentations, instruction manuals), books (e.g. print, audio), financial data (e.g. credit card information, bank account information), digital currency (e.g., Bitcoin™), cryptographic keys, user biometrics, user passwords, names of user friends, user contact information (e.g. phone number, address, email, messaging ID, social media handles), health data (e.g. blood pressure, height, weight, cholesterol level, allergies, medicines currently being taken, age, treatments completed), security clearance levels, message logs, GPS location logs, current or historical environmental data (e.g. humidity level, air pressure, temperature, ozone level, smoke level, CO2 level, CO level, chemical vapors), and the like. In various embodiments, headset 4000 includes a Bluetooth® antenna (e.g., an 8898016 series GSM antenna) (not shown). In various embodiments, headset 4000 may include any other type of antenna. In various embodiments, headset 4000 includes an earbud (not shown), which may be a component that fits in the ear (e.g., for efficient sound transmission).

Headset 4000 may also include accelerometers 4070 a and 4070 b which are capable of detecting the orientation of headset 4000 in all directions and the velocity of headset 4000 . Such accelerometers might be used for detecting the direction of gaze of a user, speed of walking, nodding of the users head, etc. Optical fibers 4072 a and 4072 b are a thin strand of diffusing optical fiber. These may include optical glass fibers where a light source, such as a laser, LED light, or other source is applied at one end and emitted continuously along the length of the fiber. As a consequence, the entire fiber may appear to light up. Optical fibers may be bent and otherwise formed into two or three dimensional configurations. Furthermore, light sources of different or time varying colors may be applied to the end of the optical fiber. As a result, optical fibers present an opportunity to display information such as a current state (e.g., red when a user is in an environment with low oxygen levels), or provide diverse and/or visually entertaining lighting configurations. In some embodiments, headset 4000 includes outward speakers 4074 which can generate a sound hearable by other users. A projector 4076 could be used to project information in front of a user. In some embodiments, projector 4076 may project text from a machine instruction manual onto a wall in front of the user. In some embodiments, a smell generator 4078 is capable of generating smells which may be used to alert the user or to calm down the user. Vibration generator 4080 may be used to generate vibrations that a user feels on the surface of cushion 4012 a . Piezoelectric sensor 4082 may be attached to headband 4002 so as to detect bending of headband 4002 (e.g. detecting when a user removes or puts on a headset).

In some embodiments, a heads up display (“HUD”) (not shown) and/or “helmet mounted display” (“HMD”) (not shown) is included in headset 4000 and used to display various data and information to the wearer. In some embodiments, HUD and/or HMD capability may be incorporated into projector 4076 . The HUD and/or HMD can use various technologies, including a collimator to make the image appear at an effective optical infinity, project an image on a facemask or windshield, or “draw” the image directly on the retina of the user. Some advantages of a HUD and/or HMD include allowing the user to check on various important data points while not changing their visual focus, which might be beneficial when used in aircraft and automobile embodiments. Other applications could include military settings, for motorcyclists, etc. A HUD and/or HMD may display important operational information in industrial settings, such as ambient temperatures, oxygen levels, a timer, the presence of toxic elements, or any other information or data that is needed. A HUD and/or HMD may display status information of another user, such as their heart rate, respiration rate, blood alcohol level, etc. A HUD and/or HMD may display environmental information of another user, such as oxygen level, temperature, location, presence of dangerous gasses, etc. A HUD and/or HMD may also display important information to a gamer, such as health levels, shield strength, remaining ammunition, opponent statistics, or any other relevant information. In some embodiments, a HUD and/or HMD may comprise text output such as instruction steps for fixing a machine, or text instructions for a student who is struggling with a math problem, or recipe instructions for a user baking a cake, etc. In some embodiments, a HUD and/or HMD can be utilized to present augmented reality (“AR”) images, or virtual reality (“VR”) images to the wearer. In some embodiments, a HUD and/or HMD can be used to enhance night vision, enabling the user to be more effective in industrial settings where light is low, or in gaming scenarios where night vision can aid in game play.

In some embodiments, headset 4000 may be constructed in such a way that the earpieces fit inside the ears rather than cover the ears. In these embodiments, headset 4000 is lighter and less cumbersome, and certain features, sensors, etc. are relocated. In embodiments that fit inside the ears, there is more situational awareness that is possible; this may be important in various industrial scenarios in which process noises, alerts, and emergency notifications need to be monitored for safety and/or productivity.

In various embodiments, headset 4000 may facilitate the ability to sense smoke and alert users to stop smoking. In some embodiments, sensors may be used to detect smoke and alert the user. A user may want to try and stop smoking cigarettes and need some coaching from headset 4000 . A smoke sensor may be attached to connector point 4037 a - b by the user or as displayed in attachable sensor example 4040 . When a user lights a cigarette and smoke emits, an attachable sensor 4040 may detect the smoke, provide the information to processor 4055 and provide an alert to the user reminding them to stop smoking. This alert from the processor may be in the form of a vibration from vibration generator 4080 , an audible alert saying, ‘please stop smoking, it is bad for you’ in speakers 4010 a - b , or in any other forms of feedback (e.g. buzz, beep, chirp). Boom lights 4044 may display a color or pattern (e.g. red blinking) and/or display 4046 may provide an image to distract the user and remind the user to stop smoking (e.g. a video showing someone suffering from lung disease or a picture of their family). The alerts may be selected in advance by the user on a device (e.g., on a user device, peripheral device, personal computer, phone, etc.), loaded using network port 4060 and stored locally in data storage 4057 .

In various embodiments, headset 4000 may facilitate the ability to sense smoke and provide safety warnings, with sensors used to detect smoke and alert the user or others around them. A user may be working in a warehouse or industrial setting in building 6802 with flammable substances. If a flammable substance ignites, the headset 4000 may detect the smoke and alert the user more quickly than human senses are possible. A smoke sensor may be attached to connector point 4037 a - b by the user or as displayed in attachable sensor 4040 . If a flammable substance ignites in an area away from the user, attachable sensor 4040 may detect the smoke, provide the information to processor 4055 and provide an alert to exit the area immediately. This alert from the processor may be in the form of a vibration from vibration generator 4080 , an audible alert saying, ‘smoke detected, please exit immediately and call 9-1-1’ in speakers 4010 a - b , lights 4042 a - b flashing red to alert others around the user to evacuate and take the individual, boom lights 4044 on microphone boom 4016 may display a color or pattern (e.g. blinking red) and/or display 4046 may provide an image to alert the user to exit (e.g. a floor plan and path to the exit the room and building). Likewise, optical fibers 4072 a - b may light up in orange for immediate visual alerts to others or emergency workers. The outward speaker 4074 may provide a high pitched burst of beeps to indicate the need to evacuate or a verbal warning that ‘smoke has been detected, please exit immediately’. Attachable sensor 4040 may detect the type of smoke (e.g. chemical, wood, plastic) based on information stored in data storage 4057 and interpreted by processor 4055 . If the smoke detected is from a chemical fire, communications to company safety teams may occur through internal satellite, Bluetooth® or other communications mechanisms within headset 4000 and housing 4008 a - b to alert them to the type of fire for improved response and specific location. Projector 4076 may display a message on the wall indicating that ‘smoke has been detected and it is a chemical fire—exit immediately—proceed to the wash station’. Also, the projector 4076 may display a map of building 6802 with the nearest exit or provide on display 4046 .

In various embodiments, headset 4000 may facilitate the ability to sense various gases (e.g. natural gas, carbon monoxide, sulfur, chlorine) and provide safety warnings. In some embodiments, sensors (e.g. natural gas, carbon monoxide, sulfur) may be used to detect odors or gas composition (e.g. odorless carbon monoxide) and alert the user. A user may be working in their living room where a gas fireplace is located. During the day, the pilot light may go out, but the gas remains on due to a faulty fireplace gas sensor. The user's senses become saturated to a point they no longer smell the gas posing a danger to her family. The headset 4000 may detect the natural gas and alert the user more quickly than human senses are possible. A natural gas sensor may be attached to connector point 4037 a - b by the user or as displayed in attachable sensor 4040 . Attachable sensor 4040 may detect the natural gas, provide the information to processor 4055 and provide an alert to the user to exit the house immediately or open the windows and doors. This alert from the processor may be in the form of a headset vibration with vibration generator 4080 , an audible alert saying, ‘natural gas detected, please exit immediately and call 9-1-1’ in speaker 4010 a - b and/or outward speaker 4074 , boom lights 4044 may display a color or pattern (e.g. blinking red) and/or display 4046 may provide an image to alert the user to exit (e.g. a floor plan and path to the exit the room and home). The attachable sensor 4040 may be used to detect the type of gas as well (e.g. natural gas, carbon monoxide, non-lethal sulfur, chlorine) based on information saved in data storage 4057 and interpreted by processor 4055 . The headset 4000 may alert the fire department, other emergency agencies or family members with headsets through the communications mechanisms (e.g. antenna, satellite, Bluetooth®, GPS) within housing 4008 a - b about the gas and composition and location of the user for more rapid response. Likewise, a research and development employee in building 6800 biohazard room 6870 may be working on an experiment to make chlorine gas. Instead of adding small amounts of concentrated hydrochloric acid to the potassium permanganate solution, the researcher adds too much hydrochloric acid, creating an unstoppable reaction and creating too much lethal chlorine gas. The headset 4000 may immediately detect elevated levels of chlorine gas through the attachable sensor 4040 based on values in data storage 4057 and interpreted by processor 4055 and immediately alerts the employee, safety teams, public emergency works and other employees. This alert sent from processor 4055 may be in the form of a buzz from cushion sensor 4050 , an audible alert in speaker 4010 a - b saying, ‘chlorine gas detected, please exit immediately and call 9-1-1’, boom lights 4044 or headband lights 4042 a - b may display a color or pattern (e.g. blinking and solid red variation) and/or display 4046 may provide an image to alert the user to exit (e.g. a floor plan and path to the nearest exit the room). Headset 4000 may alert the fire department, other emergency agencies, local safety team members or employees in close proximity with headsets through the internal communications (e.g. antenna, satellite, Bluetooth, GPS) within housing 4008 a - b about the chlorine gas for more rapid and accurate response (e.g. correct equipment to combat the chlorine gas). Alerts (e.g. chlorine gas detected in room 6870 ) may also be displayed on building 6802 walls using projectors 6850 a - f and lights 6808 a - g (e.g. red flashing) along with evacuation notices from speakers 6850 a - e.

In various embodiments, headset 4000 may facilitate the ability for a user to progress through a checklist (e.g. recipe). In various embodiments, forward facing cameras 4022 a - b may be able to detect steps on a checklist and assist the user. A user may store a recipe (e.g. pasta fagioli soup) in data storage 4057 using an electronic device (e.g. computer, phone, tablet) through network port 4060 . This recipe may be interpreted by processor 4055 and stored in data storage 4057 with a unique name (e.g. pasta fagioli soup) for later retrieval. The user may access the recipe by speaking into microphone 4014 to request retrieval of the pasta fagioli soup using a voice command (e.g. ‘retrieve pasta fagioli recipe’). As the user is preparing the soup, the forward facing camera 4022 a - b on extendible stalk 4028 may capture the movements and steps and communicate with processor 4055 . The processor may determine that the user has skipped adding a dash of tabasco sauce from the recipe and informs the user through speaker 4010 a - b that a step was missed and tells the user the ingredient that was left out (e.g. tabasco). Likewise, display 4046 or projector 4076 may also show the steps of the recipe and indicate they are completed (e.g. crossing through the step, checking off the step). If a step is missed or performed out of order or incorrectly as determined by forward facing camera 4022 a - b and processor 4055 , the headset 4000 may provide alerts such as vibrations from the vibration generator 4080 , notices on display 4046 (e.g. ‘stop—a step was missed in the recipe’), boom lights 4044 may display yellow, outward speaker 4074 or speaker 4010 a - b may provide verbal warnings (e.g. ‘review steps or ingredients’) of missed steps or missing ingredients. Likewise, a user may decide to by-pass the warning or message if they do not want to include the ingredient by pressing the button 4030 a - b indicating to processor 4055 to skip the step or ingredient.

In various embodiments, headset 4000 may facilitate the ability to detect steps on a checklist and assist the user. A pilot or company may input the pre-flight checklist for all aircraft in the headset 4000 and save in data storage 4057 from an electronic device (e.g. computer, phone, digital tablet) through the network port 4060 . The pilot, using microphone 4014 , may request retrieval of the pre-flight checklist using a voice command (e.g. ‘load pre-flight checklist for MD-11’). The pre-flight checklist may be shown on display 4046 as a reminder to the pilot along with scrolling capabilities. As the pilot is performing the pre-flight check, the forward facing camera 4022 a - b may capture the movements and steps of the pilot during the pre-flight activities and communicate those with processor 4055 . The accelerometer 4070 a - b may detect that the head movement and focus did not occur on an element of the plane referenced in the checklist. The processor detects that the pilot may have skipped checking the flaps on the right wing and may inform the pilot through speaker 4010 a - b (e.g. check right wing flaps), vibration to the pilot from vibration generator 4080 to alert the pilot of a missed step, colors on microphone boom lights 4044 (e.g. solid red) and/or communication to the flight control team through communication mechanisms (e.g. Bluetooth, satellite, cellular) that a step was missed. The flight control team may communicate directly to the pilot through the headset 40000 asking her to recheck the pre-flight steps or inform the captain. Likewise, display 4046 may also show the pre-flight checklist and indicate the completed (e.g. crossing through the step, checking off the step) or missing (e.g. highlighting in bold and red) steps.

In various embodiments, headset 4000 may facilitate the ability to coach a user through steps and provide analysis. There may be situations where repeating a step is needed for ongoing improvement and coaching analysis is needed. A new basketball player may have to shoot thousands of free throws to improve their performance. Coaching after every shot may not be appropriate. The headset 4000 with cameras 4022 a - b may record each free throw taken by the player during practice. After every 50 shots, processor 4055 may perform an analysis of all shots and provide a coaching summary. The analysis may be in the form of written comments on display 4046 (e.g. 45% shots made, too many dribbles before shooting, not enough arch on the ball, too long of a delay before shooting), highlights of good and poor shots displayed on a wall with projector 4076 for review by the player, verbal feedback in speaker 4010 a - b providing steps for improvement or encouragement (e.g. ‘good shot’). Likewise, so as to not interrupt the player, feedback may be given to the coach or others watching. Headband lights 4042 a - b may display green when processor 4055 determines the technique in shooting was performed well or red when improvements are needed. The coach observing the player may immediately see the lights and determine if they should stop the player and provide more coaching or encouragement.

In various embodiments, headset 4000 may facilitate the ability to coach or provide feedback to users regarding verification of performed steps. In some embodiments, a user may need to understand what steps of a process were missed for training purposes, but interruption during the process is not desired. A factory worker may be required to assemble small components on a computer board. The user may have been trained and now the employer needs to verify they can successfully complete the steps. The user wearing a headset 4000 begins to assemble the computer board. The forward facing cameras 4022 a - b may record each step of assembly along with the duration of each step and communicate this information to processor 4055 and data storage 4057 . Once the assembly is completed, processor 4055 may review the steps for accuracy and time and inform the user. The feedback may be through display 4046 or projector 4076 on a wall that a step was missed and/or the time to complete specific steps took too long (e.g. step 3 took 30 seconds and only 15 seconds is allocated). The user may make the necessary corrections and perform the steps again with headset 4000 until there are no missed assembly steps and the time to perform the steps are within an acceptable range. Likewise, when all steps are performed correctly and within an acceptable time, headband lights 4042 a - b , lights 4026 or optical fibers 4072 a - b may light up (e.g. solid green) to indicate to the supervisor that there are no issues. The factory worker may also get notification through boom lights 4044 (e.g. green) or display 4046 (e.g. “OK—great work”) that there are no performance issues.

In various embodiments, headset 4000 may facilitate the ability to capture records of completing checklist items for later recall. In some embodiments, there may be situations where a user needs to recall specific actions performed as proof that there were no deficiencies. In a manufacturing room 6885 where chemical cleaning occurs on parts, it may be necessary to provide evidence that a part was cleaned according to specific instructions and steps to defend the company's actions in court or appease an upset customer. Using headset 4000 , forward facing cameras 4022 a - b may record the actions of a user cleaning parts in the chemical room with acid tanks 6885 . The forward facing cameras record the specific part by reading the part measurements, barcode or image. The processor 4055 compares measurements or images to stored parts in data storage 4057 to retrieve the checklist or procedures for the specific part. While the user is cleaning the part, the forward facing cameras capture the video of the item, date, time, and procedures performed according to the documented checklist. This information may be stored in data storage 4057 for uploading to company databases from network port 4060 or other communications capabilities in housing 4008 a - b (e.g. Bluetooth®, satellite, USB connection). In some embodiments, the information stored in data storage 4057 may be used as an audit trail which can be provided to company auditors, regulators, safety inspectors, etc. In various embodiments, a company may use information stored in data storage 4057 to prove in court that a part number was cleaned properly. The company may retrieve the part number and actions that were performed on the part to defend themselves in court. Likewise, they may retrieve all video of the part cleaning process to defend their standard operating procedure.

In various embodiments, headset 4000 may facilitate the ability to include a checklist with criteria that can be verified by eye gaze/head/body orientation. In some embodiments there may be situations where assembly line workers are needed to visually inspect items for quality control. An automobile manufacturer may require a visual inspection of final painted vehicles for scratches or paint flaws. The employee with a headset 4000 and forward facing cameras 4022 a - b may inspect the automobiles coming off the assembly line. Accelerometers 4070 a - b may be used to monitor eye gaze time and head movements to validate that a user is actually looking at the exterior of the automobile for defects and not in other locations. If the camera or accelerometer detects the user gazing in a direction other than the automobile, vibration from vibration generator 4080 may occur to alert the user to pay attention, a tone in speaker 4010 a - b may occur (e.g. short chirping sound), headband lights 4042 a - b may flash orange giving the supervisor and opportunity to coach the employee to pay more attention or the display 4046 may show a message to the worker to look in the direction of the automobile. Boom lights 4044 may also blink in red to alert the worker to pay attention.

In various embodiments, headset 4000 may provide an opportunity for another person to observe an action such as in industrial settings, construction, healthcare, fast food and the like without physically being in the room. In healthcare environments where highly contagious or seriously ill people require limited contact, it may be necessary for other medical professionals to assess the patient through the eyes of only one person in the room. A person suffering from meningitis may have a doctor with headset 4000 evaluate their condition while other physicians observe in remote locations. As this is a highly contagious disease, other doctors may want to evaluate them without entering the room. The forward facing cameras 4022 a - b may record in the direction the physician is looking at the patient. The physician may dictate through microphone 4014 to turn on lights 4026 so she can evaluate the dilation of the eyes. A doctor watching in a remote location through the eyes of the on-site physician may notice a slow dilation response and ask the doctor in the room to perform a different alertness assessment. The physician may decide to prescribe a new drug and speak into microphone 4014 and show the dosage and drug interactions on display 4046 before writing the prescription. Later, the physician may want to perform a new evaluation technique but needs to see the exact process. Projector 4076 displays on the wall behind the patient the steps and video of the procedure before the doctor performs the evaluation. In some embodiments, evaluation of hearing may take place by having the physician request audible sounds be delivered from outward speaker 4074 so the patient can respond (e.g. hold up your hand if you hear a tone). The overall evaluation may be recorded by cameras 4022 a - b and stored in data storage 4057 for future reference and training of interns.

In various embodiments, headsets may facilitate good cleaning practices. Office cleaning may become more important to remove germs and create a safe work environment. In some embodiments, maintenance personnel with headset 4000 may be instructed to spray the desk, wait for 30 seconds and wipe until dry, spending a minimum of 2 minutes per desk to ensure a safe work environment. During cleaning, forward facing cameras 4022 a - b may collect the desk cleaning activities of the maintenance worker, send a record to processor 4055 for evaluation against standards and store the results in data storage 4057 . The processor determines that in one situation cleaning spray was not applied and the speaker 4010 a - b may alert the user to reclean the desk and apply a cleaning solution. The processor may also determine that desks are only being cleaned an average of 1 minute 30 seconds, not the required 2 minutes. Cushion sensor 4050 may provide a haptic response to the worker (e.g. buzz), while display 4046 reminds the worker with a message to clean each desk for 2 minutes and to redo the cleaning, and microphone boom lights flash in multi-colors indicating the worker should reclean the surface. In some embodiments, this information may be sent from data storage 4057 by internal communications (e.g. Bluetooth®, satellite, cellular) in housing 4008 a - b to the company facility and maintenance team databases for evaluation. This information may be reviewed with the cleaning company for improvement and compliance. Likewise, when employees approach their desk each day and don a headset 4000 , the piezoelectric sensor 4082 may recognize the person is putting on a headset. Forward facing camera 4022 a - b or GPS in the housing 4008 a - b recognizes the specific desk and location. In some embodiments, processor 4055 may retrieve data from the company database and provide information regarding the cleaning status to display 4046 (e.g. all cleaned) and/or microphone boom lights 4044 (e.g. display solid green for cleaned desk or red for unclean desk) to the employee. Likewise, the employee may be presented with a brief video on display 4046 showing successful cleaning the night before indicating it is safe to sit and begin work.

With reference to FIG. 41 , a presentation remote 4100 according to some embodiments is shown. Two views of the presentation remote are shown: a top view 4105 and a front view 4105 (which shows elements at the front of the presentation remote in the direction in which it may be pointed). While various elements of presentation remote 4100 are described here in particular locations on/in the device, it is understood that elements may be placed in many different locations and configurations. Presentation remote 4100 may take many forms, such as being incorporated into headset, projector, hat, belt, eyeglasses, chair, conference table, mouse, keyboard, etc.

Front view 4105 includes a forward facing camera 4122 at the front of presentation remote 4100 which may capture photos/video of objects (e.g. capturing an image/video of one or more meeting attendees, capturing an image of the setup of a room, capturing an image of a presentation slide) that the presentation remote is pointed at. In various embodiments, instead of (or in addition to) forward facing camera 4122 , presentation remote 4100 may include a 360-degree camera. This may allow for a wider field of image capture. In various embodiments, an inward facing camera 4123 may be pointed toward the user of the device, allowing the capture of facial expressions of the user, biometric information of the user (e.g. iris, face geometry), etc. Front view 4105 also shows a sensor 4124 such as a rangefinder or light sensor. Sensor 4124 may be disposed next to forward facing camera 4122 . In one embodiment, sensor 4124 includes night vision capability which can provide data to processor 4155 , which can identify safety issues (e.g. an object blocking a pathway) even in low light situations. In another embodiment, sensor 4124 may be a thermal sensor which allows infrared wavelengths to be detected which can be used to detect hot machine parts, user temperatures, leaking window seals, etc. Front view 4105 may include one or more camera lights (not shown) which can help to illuminate objects captured by forward facing camera 4122 . A projector 4176 and laser pointer 4178 may also be positioned on presentation remote 4100 so as to output in the direction in which forward facing camera 4122 is facing. In some embodiments, projector 4176 and laser pointer 4178 may include rotational capabilities that allow them to point in directions away from forward facing camera 4122 . In some embodiments, laser pointer 4178 may be capable of displaying different colors, may flash in order to get the attention of the presenter and/or meeting participants, may display a variety of icons or symbols, may “draw” an image or text by quick movements of laser pointer 4178 , etc. Front view 4105 may also include range finder 4184 which may be a laser rangefinder. The rangefinder may allow the presentation remote to determine distances to surrounding objects or people, and/or determine distances to a screen on which a presentation is being projected. A barcode reader 4186 may also be used, allowing presentation remote 4100 to read barcodes, such as a barcode on the wall of a meeting room which contains information about the room, or one or more barcodes incorporated into a presentation that provide supplemental information. Barcode reader 4186 may also be used to scan barcodes of objects (such as supplemental device 4190 ) in order to register that device with presentation remote 4100 .

Presentation remote 4100 may include one or more physical buttons and/or one or more virtual buttons (e.g. small displays that can register touch input from a user). Selection button 4132 may allow a user to select from various options presented on display screen 4146 . Forward and back buttons 4130 may allow the user to step forward or backward in the slides of a presentation. Side buttons 4133 a and 4133 b may be physical (or virtual) buttons that allow a user to provide input while holding presentation remote 4100 in one hand even when looking in a different direction. Configurable buttons 4144 a , 4144 b , anf 4144 c may be virtual buttons that a user can define to allow for customizable functionality when pressed (e.g. pressing 4144 a retrieves v1 of a presentation, pressing 4144 b retrieves v2 of a presentation, pressing 4144 c retrieves v3 or a presentation). Jump buttons 4152 a and 4152 b may be virtual buttons that can be programmed to jump to predetermined locations within a presentation (e.g. pressing jump button 4152 a may bring up a ‘milestones’ slide that has an embedded tag named ‘milestones’) which may reduce having to go forward or back through many slides in order to get to a particular slide that is often used in a presentation. Exemplary user inputs might include entering data, changing slides, initiating presentation software, saving a voice file of an idea, selecting from options, identifying a meeting participant from an image, instructions to change the volume, instructions to activate or deactivate a camera, instructions to mute or unmute the user, or any other instructions or any other inputs. In some embodiments, another form of input is a scroll wheel, which allows for selections from display 4146 or other forms of input (e.g. moving forward or backward within a presentation).

In various embodiments, presentation remote 4100 includes lights as signaling, alerts, communication, etc. Facing lights 4126 may be disposed around display 4146 , and could alert a user by flashing when a new message or notification is displayed on the display. In some embodiments, facing lights could be associated with particular participants in a room. For example, six facing lights could be individually connected to supplemental devices 4190 of six meeting participants, so that a user of presentation remote 4100 would see one of the facing lights light up when that particular participant wanted to speak. Side lights 4128 could be used to signal to meeting participants, such as by flashing when a meeting break time has ended.

In various embodiments, presentation remote 4100 may include an attachment structure 4137 consisting of connector points for motion sensors, motion detectors, accelerometers, gyroscopes, microphones, speakers, accelerometers, supplemental devices, rangefinders, etc. Attachment structure 4137 may be electrically connected with processor 4155 to allow for flow of data between them. Attachment structure 4137 could include one or more points at which a user could clip on an attachable sensor (not shown). In some embodiments, standard size structures could enable the use of many available attachable sensors, enabling users to customize the presentation remote with just the types of attachable sensors that they need for a particular function. In some embodiments, a user may take a sensor from attachment structure 4137 and clip it to their clothing (or to another user's clothing) and then later return the sensor to attachment structure 4137 . A detachable microphone 4116 might be removed and placed in the middle of a conference room table in order to capture audio from the meeting, such as capturing what participants are saying.

In some embodiments, a record button 4162 may allow a user to store audio or video during a meeting or presentation. For example, a brainstorming session facilitator may press record button 4162 to record an idea, then press record button 4162 again to stop the recording and save the audio file to data storage 4157 . The facilitator might then use presentation remote 4100 to transmit that audio file of the idea to another user.

Speakers 4110 a and 4110 b may allow for messages to be broadcast to users and for others (such as meeting participants) who are within hearing range. A microphone 4114 may be used to detect audio signals (e.g., voice of the user, voice of the presenter, room sounds, participant sounds).

Display 4146 may allow for messaging and displaying options to a user. In various embodiments, display 4146 faces towards a prospective user. This may allow a user to view graphical information that is displayed by presentation remote 4100 , such as messages (e.g. meeting participants want to take a break, one meeting participant has not returned from a break). In some embodiments, display 4146 is touch enabled so that options (e.g. list of presentation versions to use, list of participants in the room, list of questions that participants have asked) on display 4146 may be selected by a user touching them. In other embodiments, a user may employ selection button 4132 to select from items listed on display 4146 . In some embodiments, a secondary display 4148 allows for additional information to be provided to the user, such as by displaying questions that have been received by an audience or meeting participants. Communication displays 4150 a and 4150 b may be touch enabled, allowing a user to touch one or more displays 4150 a - b which show options to a user. In one example, communication display 4150 a shows “Mary Chao” and will call her or open other forms of communication (e.g. text, instant messaging) when selected by a user. Similarly, touching communication display 4150 b may open an audio channel to meeting room TR68 so that a meeting owner might check on whether or not that particular room was currently occupied, or to open communications with that room, such as for the purposes of asking an expert in that room to provide some needed knowledge.

Terminal 4167 may serve as an attachment point for electronic media, such as for USB thumb drives, for USB cables, or for any other type of media or cable. Terminal 4167 may be a means for charging presentation remote 4100 (e.g., if presentation remote 4100 is wireless). Processor 4155 may provide computational capability needed for the functionality (e.g. running software, managing communications, directing elements such as lights, processing inputs) of presentation remote 4100 . Data storage 4157 may comprise non-volatile memory storage. In some embodiments, this storage capacity could be used to store software, presentations, user images, business files (e.g. documents, spreadsheets, presentations, instruction manuals), books (e.g. print, audio), financial data (e.g. credit card information, bank account information), digital currency (e.g., Bitcoin™), cryptographic keys, user biometrics, user passwords, names of user friends, user contact information (e.g. phone number, address, email, messaging ID, social media handles), health data (e.g. blood pressure, height, weight, cholesterol level, allergies, medicines currently being taken, age, treatments completed), security clearance levels, message logs, GPS location logs, current or historical environmental data (e.g. humidity level, air pressure, temperature, ozone level, smoke level, CO2 level, CO level, chemical vapors), and the like. In various embodiments, presentation remote 4100 includes a Bluetooth® antenna (e.g., an 8898016 series GSM antenna) (not shown). In various embodiments, presentation remote 4100 may include any other type of antenna. In various embodiments, presentation remote 4100 includes an earbud (not shown), which may be a component that fits in the ear (e.g., for efficient sound transmission).

Presentation remote 4100 may also include accelerometers 4170 a and 4170 b which are capable of detecting the orientation of presentation remote 4100 in all directions and the velocity of presentation remote 4100 . Accelerometers can aid in determining the direction in which presentation remote 4100 is pointed (e.g. for determining which meeting participants that it is pointed at), as well as detecting the movements of a user (e.g. a presenter) during a presentation of meeting facilitation. Optical fibers 4172 a and 4172 b are thin strands of diffusing optical fiber. These may include optical glass fibers where a light source, such as a laser, LED light, or other source is applied at one end and emitted continuously along the length of the fiber. As a consequence, the entire fiber may appear to light up. Optical fibers may be bent and otherwise formed into two or three dimensional configurations. Furthermore, light sources of different or time varying colors may be applied to the end of the optical fiber. As a result, optical fibers present an opportunity to display information such as a current state (e.g., red when a presentation is expected to exceed a meeting end time), or provide diverse and/or visually entertaining lighting configurations.

Network port 4160 may allow for data transfers with supplemental devices 4190 , user devices, peripheral devices, and/or with central controller 110 .

In some embodiments, tactile dots 4135 may include a small elevated or protruding portion designed to make contact with the user's skin when presentation remote 4100 is held. This could allow for embodiments in which processor 4155 could direct a haptic signal to alert a user via tactile dots 4135 , or direct heat via heating element 4165 , or provide a puff of air.

In some embodiments, a smell generator 4180 is capable of generating smells which may be used to alert the user or to calm down the user. Vibration generator 4182 may be used to generate vibrations that a user feels, such as a vibration (e.g. an alert to the user) that travels through presentation remote 4100 .

Supplemental device 4190 may be associated with presentation remote 4100 , but be mobile and thus may be provided to other users (e.g. meeting participants) in order to provide input and/or output capability during a meeting or presentation. It may include a clip 4192 which allows supplemental device 4190 to be attached to objects or clothing. In some embodiments, supplemental device 4190 may store photos and video, or transmit them in realtime to presentation remote 4100 . In various embodiments, the supplemental device is wired to presentation remote 4100 to facilitate the transfer of data and to supply power. In some embodiments, the supplemental device may have display capabilities and/or include one or more capabilities of GPS, wireless communications, processing, data storage, a laser pointer, range finder, sensors, accelerometers, voting software, feedback software, signaling, vibrations, etc. In some embodiments, supplemental device 4190 includes signaling lights 4194 a , 4194 b , and 4194 c which may be directed by presentation remote 4100 to light up (in many colors) in order to communicate to meeting participants. In various embodiments, signaling lights 4194 a - c may also be under the control of the user, allowing a user to provide visual feedback to a presenter or to other participants in a meeting. In some embodiments, colors indicated via signaling lights 4194 a - c may indicate that two participants are in alignment, that a participant would like to speak, that a participant is not clear about something, that a participant has a candid observation that they would like to make, etc. A supplemental camera 4196 may be used by a meeting participant to capture images (e.g. a whiteboard with brainstorming notes, photos of other participants, broken object in a room) and/or videos (e.g. capturing a meeting participant explaining a decision that has been made in a meeting). In some embodiments, input buttons 4198 a , 4189 b , and 4198 c allow users to provide information (e.g. voting, ratings, tags, selections from options, questions, identifications or other participants, to presentation remote 4100 or to other supplemental devices 4190 . Similarly, slider 4199 may allow for inputs from a user (e.g. providing a rating of meeting quality on a sliding scale).

In various embodiments, presentation remote 4100 may include communications functionality so that a user may connect to another user (e.g. over a phone network, cell network, Wi-Fi®, instant messaging, email) and communicate synchronously and/or asynchronously. In such an embodiment, microphone 4114 and speakers 4110 a and 4110 b may enable the user to speak and hear responses from another user. In one example, a presenter may point presentation remote 4100 at a meeting participant in order to initiate a text messaging channel so that the presenter may communicate in a side channel with the participant which does not disrupt the flow of the meeting. In some embodiments, meeting participants may text messages (e.g. feedback, questions, ratings) to presentation remote 4100 which are then displayed on display 4146 .

In various embodiments, presentation remote 4100 may facilitate the ability to sense smoke and provide safety warnings, with sensors used to detect smoke and alert the user or others around them. If the smoke detected is from a chemical fire, communications to company safety teams may occur through internal satellite, Bluetooth® or other communications mechanisms within presentation remote 4100 to alert them to the type of fire for improved response and specific location. Projector 4176 may display a message on the wall indicating that ‘smoke has been detected and it is a chemical fire—exit immediately—proceed to the wash station’. Also, the projector 4176 may display a map of a building with the nearest exit or provided on display 4146 .

In various embodiments, presentation remote 4100 may facilitate the ability for a user to manage checklists (e.g. recipes, task lists, chores lists) as described more fully in FIG. 40 .

With reference to FIG. 42 , a camera 4200 according to some embodiments is shown. Mounting arm 4206 and mounting plate 4208 may serve as structural elements, in some embodiments serving to connect camera 4200 to a wall or other suitable surface that serves as a solid base. In some embodiments, rotational motor 4204 and rotational mechanism 4202 may also serve to function as mechanisms which may be used to pan, tilt, and swivel camera 4200 , while also providing structure for anchoring camera 4200 . In various embodiments, one or more of rotational mechanism 4202 , rotational motor 4204 , mounting arm 4206 , and mounting plate 4208 may serve as a conduit for power lines, signal lines, communication lines, optical lines, or any other communication or connectivity between attached parts of the camera.

A speaker 4210 may be attached to the base of camera 4200 , and allow for messages to be broadcast to users within hearing range. A microphone 4214 may be used to detect audio signals (e.g., user voices, crashing objects, dogs barking, kids playing in a pool, games being played).

A forward facing camera 4222 is shown at the front of camera 4200 . In some embodiments, a side facing camera 4286 may be pointed 90 degrees in the other direction from forward facing camera 4222 , allowing for a greater field of view, and in some embodiments enabling stereoscopic imaging when the two cameras are used together. Forward facing camera 4222 may be part of camera unit 4220 which may also include a sensor 4224 such as a rangefinder or light sensor. Sensor 4224 may be disposed next to forward facing camera 4222 . In some embodiments, sensor 4224 may be a laser rangefinder. The rangefinder may allow the camera to determine distances to surrounding objects or features. In one embodiment, sensor 4224 includes night vision capability which can provide data to processor 4255 , which can identify safety issues (e.g. an object blocking a pathway) even in low light situations. Camera unit 4220 may include one or more camera lights 4242 a and 4242 b which can help to illuminate objects captured by forward facing camera 4222 . A thermal sensor 4226 may also be disposed next to forward facing camera 4222 , and allow infrared wavelengths to be detected which can be used to detect hot machine parts, user temperatures, leaking window seals, etc. A projector 4276 and laser pointer 4278 may also be positioned on camera 4200 so as to output in the direction in which forward facing camera is facing. In some embodiments, projector 4276 and laser pointer 4278 may include rotational capabilities that allow them to point in directions away from forward facing camera 4222 .

Buttons 4230 a , 4230 b , and 4230 c may be available to receive user inputs. Exemplary user inputs might include instructions to change the volume, instructions to activate or deactivate a camera, instructions to mute or unmute the user, or any other instructions or any other inputs.

In various embodiments, camera 4200 may include one or more attachment structures 4237 consisting of connector points for motion sensors, motion detectors, accelerometers, gyroscopes, and/or rangefinders. Attachment structure 4237 may be electrically connected with processor 4255 to allow for flow of data between them. Attachment structure 4237 could include one or more points at which a user could clip on an attachable sensor 4240 . In some embodiments, standard size structures could enable the use of many available attachable sensors, enabling users to customize the camera with just the types of attachable sensors that they need for a particular function. For example, a manufacturing facility might select several types of gas sensors to be attached to attachment structure 4237 . In some embodiments, a user may take a sensor from attachment structure 4237 and clip it to their clothing (or to another users clothing) and then later return the sensor to attachment structure 4237 .

In various embodiments, instead of forward facing camera 4222 , camera 4200 may include a 360-degree camera on top. This may allow for image capture from all directions around the environment. In some embodiments, camera lights 4242 a and 4242 b may be capable of illuminating a user, such as the user's face or skin or head or other body part, or the user's clothing, or the users accessories, or some other aspect of the user. When activated, such lights might signal to users that there is a safety issue in the area of view of camera 4200 .

Display 4246 may be directly beneath camera 4222 . In various embodiments, display 4246 faces towards a prospective user. This may allow a user to view graphical information that is displayed by camera 4200 , such as messages (e.g. maximum room occupancy has been exceeded, there is water on the floor, a child just dropped a hazardous object on the floor).

Terminal 4267 may serve as an attachment point for electronic media, such as for USB thumb drives, for USB cables, or for any other type of media or cable. Terminals 4267 may be a means for charging camera 4200 (e.g., if camera 4200 is wireless). Data storage 4257 may comprise non-volatile memory storage. In some embodiments, this storage capacity could be used to store software, user images, business files (e.g. documents, spreadsheets, presentations, instruction manuals), books (e.g. print, audio), financial data (e.g. credit card information, bank account information), digital currency (e.g., Bitcoin™), cryptographic keys, user biometrics, user passwords, names of user friends, user contact information (e.g. phone number, address, email, messaging ID, social media handles), health data (e.g. blood pressure, height, weight, cholesterol level, allergies, medicines currently being taken, age, treatments completed), security clearance levels, message logs, GPS location logs, current or historical environmental data (e.g. humidity level, air pressure, temperature, ozone level, smoke level, CO2 level, CO level, chemical vapors), and the like. In various embodiments, camera 4200 includes a Bluetooth® antenna (e.g., an 8898016 series GSM antenna) (not shown). In various embodiments, camera 4200 may include any other type of antenna. In various embodiments, camera 4200 includes an earbud (not shown), which may be a component that fits in the ear (e.g., for efficient sound transmission).

Camera 4200 may also include accelerometers 4270 a and 4270 b which are capable of detecting the orientation of camera 4200 in all directions and the velocity of camera 4200 . Optical fibers 4272 are thin strands of diffusing optical fiber. These may include optical glass fibers where a light source, such as a laser, LED light, or other source is applied at one end and emitted continuously along the length of the fiber. As a consequence, the entire fiber may appear to light up. Optical fibers may be bent and otherwise formed into two or three dimensional configurations. Furthermore, light sources of different or time varying colors may be applied to the end of the optical fiber. As a result, optical fibers present an opportunity to display information such as a current state (e.g., red when a user is in an environment with low oxygen levels), or provide diverse and/or visually entertaining lighting configurations.

Network port 4260 may allow for data transfers with user devices, peripheral devices, and/or with central controller 110 . Mounting arm lights 4244 a and 4244 b may help to illuminate the view of camera 4200 , and in some embodiments may be used to communicate to users (e.g., flashing red as a warning).

In some embodiments, a smell generator 4280 is capable of generating smells which may be used to alert the user or to calm down the user. Vibration generator 4282 may be used to generate vibrations that a user feels, such as a vibration that travels along a wall emanating from mounting plate 4208 .

Supplemental camera 4284 may be associated with camera 4200 , but be mobile and thus may be used to get video or photos from other angles and from other places. It may include a clip which allows supplemental camera 4284 to be attached to objects or clothing. In some embodiments, supplemental camera 4284 may store photos and video, or transmit them in realtime to camera 4200 . In various embodiments, the supplemental camera is wired to camera 4200 to facilitate the transfer of data and to supply power. In some embodiments, the supplemental camera may include one or more capabilities of GPS, wireless communications, processing, data storage, a laser pointer, range finder, sensors, etc.

In various embodiments, camera 4200 may facilitate the ability to sense smoke and provide safety warnings, with sensors used to detect smoke and alert the user or others around them. A user may be working in a warehouse or industrial setting in building 6802 with flammable substances. If a flammable substance ignites, the camera 4200 may detect the smoke and alert the user more quickly than human senses are possible. A smoke sensor may be attached to attachment structure 4237 by the user or as displayed in attachable sensor 4240 . If a flammable substance ignites in an area away from the user, attachable sensor 4240 may detect the smoke, provide the information to processor 4255 and provide an alert to exit the area immediately. This alert from the processor may be in the form of a vibration from vibration generator 4282 , an audible alert saying, ‘smoke detected, please exit immediately and call 9-1-1’ from speaker 4210 , camera lights 4242 flashing red to alert others around the user to evacuate and take the individual, and/or display 4246 may provide an image to alert the user to exit (e.g. a floor plan and path to the exit the room and building). Likewise, optical fibers 4272 may light up in orange for immediate visual alerts to others or emergency workers. The speaker 4210 may provide a high pitched burst of beeps to indicate the need to evacuate or a verbal warning that ‘smoke has been detected, please exit immediately’. Attachable sensor 4240 may detect the type of smoke (e.g. chemical, wood, plastic) based on information stored in data storage 4257 and interpreted by processor 4255 . If the smoke detected is from a chemical fire, communications to company safety teams may occur through internal satellite, Bluetooth® or other communications mechanisms within camera 4200 to alert them to the type of fire for improved response and specific location. Projector 4276 may display a message on the wall indicating that ‘smoke has been detected and it is a chemical fire—exit immediately—proceed to the wash station’. Also, the projector 4276 may display a map of building 6802 with the nearest exit or provide on display 4246 .

In various embodiments, camera 4200 may facilitate the ability for a user to manage checklists (e.g. recipes, task lists, chores lists) as described more fully in FIG. 40 .

With reference to FIG. 43 , a headset 4300 with motion sensor 4301 according to some embodiments is shown. Motion sensor 4301 comprises a capsule 4308 , which may be substantially spherical in shape. Multiple fixed conductors 4304 line the inside of capsule 4308 . A movable conductor 4302 is free to move about inside the capsule. Movable conductor 4302 may be substantially spherical in shape. Fixed conductors 4304 may be in electrical communication with one of a plurality of wires 4312 (e.g., with wires 4312 a , 4312 b , and 4312 c ). In various embodiments, adjacent wires (e.g., 4312 a and 4312 b ) are of opposite polarities (e.g., one is grounded while the other is connected to the positive supply voltage). When movable conductor 4302 bridges the gap between two fixed conductors on adjacent wires (e.g., between wires 4312 a and 4312 b ), a circuit is completed.

The circuit completion can be detected by a logic gate bridging the two particular wires that are now in electrical communication. For example, an “AND” gate is connected at one input to the positive voltage supply (e.g., via wire 4312 a ), and at the other input (e.g., via wire 4312 b ), through a resistor, to ground. Normally, with only one input connected to the positive voltage supply (i.e., to logic “1”), the AND gate will output a “0” signal. However, when movable conductor 4302 bridges the two wires connecting to the respective inputs of the AND gate, both inputs will now be logically positive, and the AND gate will output a “1” signal. Depending on which AND gate outputs a logical “1” at any given time, it may be determined which two wires are being bridged by the movable conductor 4302 . In various embodiments, other methods (e.g., other logic gates, etc.) may be used to determine which wires are bridged at any given time.

By sequentially detecting which wires are being bridged, a trajectory (or some information about a trajectory) of movable conductor 4302 may be inferred. Since movable conductor 4302 is under the influence of gravity, it may thereby be inferred how the headset has moved so as to change the relative location of movable conductor 4302 within capsule 4308 . For example, if movable conductor 4302 is detected bridging wires 4312 a and 4312 b , it may be inferred that such wires are closest to the physical ground at the moment. In various embodiments, headset 4300 may contain multiple capsules, each with wires in different orientations relative to one another. In this way, for example, more precise positioning information may be obtained.

In various embodiments, repeatedly sampled position information from one or more sensors such as sensor 4301 may be differentiated to obtain velocity information, and may be twice differentiated to obtain acceleration information.

As will be appreciated, sensor 4301 represents a method of obtaining motion data according to some embodiments, but any suitable sensor or sensors may be used in various embodiments.

Motion sensor 4301 and other motion sensors may be found in U.S. Pat. No. 8,315,876, entitled “Headset wearer identity authentication with voice print or speech recognition” to Reuss issued Nov. 20, 2012, at columns 7-9, which is hereby incorporated by reference.

With reference to FIG. 44 , an advertisement 4400 according to some embodiments is shown. In various embodiments, advertisement 4400 may provide a means to input commands to a presentation remote. The advertisement may comprise a page (print or digital) of a magazine, newspaper, direct mail piece, etc. The advertisement may include one or more barcodes, such as traditional barcodes or two-dimensional barcodes. Each barcode may be associated with an input, a command, an instruction, or the like. Barcode 4402 may serve as an authenticator for the user. For example, the barcode 4402 may encode a unique password for the user. Barcode 4404 may serve as an authenticator for the user in a particular context, such as for playing a particular video game. As will be appreciated, barcodes may be used to authenticate a user in other contexts. Barcodes 4406 and 4408 may serve as instructions to order food, e.g., particular items of food associated with each barcode. For example, barcode 4406 may be used to order pizza, while barcode 4408 is used to order French fries. As will be appreciated, barcodes could be used for ordering other items. Barcodes 4410 and 4412 may be used to modify parameters of a presentation remote's functionality. For example, bar code 4410 may be used to change the color of laser pointer 4178 , while bar code 4412 may be used to turn off the functionality of optical fibers 4172 a and 4172 b . As will be appreciated, barcodes could be used for other types of modifications to presentation remote parameters. Barcode 4414 may be used to create a message, such as a text message that will be sent to another user. In various embodiments, the barcode may trigger a predefined message, such as, “How's it going?” In various embodiments, the barcode may place the presentation remote in a receptive mode, after which the presentation remote will accept verbal dictation and transcribe a text message. In various environments, barcodes may be used for various other instructions, and for various other purposes.

In various embodiments, a presentation remote 4100 (not shown) includes functionality of a barcode reader, and is thereby able to read and interpret instructions represented by a barcode. For example, presentation remote 4100 may include a barcode reader 4186 , or other optical element in order to read barcodes. In various embodiments, an advertisement may incorporate or embed instructions using other means. For example, an advertisement may incorporate RFID chips, NFC chips, proximity chips, or the like, which may trigger an instruction for the presentation remote when the presentation remote is nearby. In various embodiments, form factors besides an advertisement may incorporate barcodes, proximity chips, or any other device for triggering instructions. In various embodiments, peripheral devices other than a presentation remote may detect and/or respond to barcodes, proximity chips, or the like.

With reference to FIG. 45 , a conference room 4500 is depicted in accordance with various embodiments. While conference room 4500 depicts an exemplary environment and arrangement of objects, devices, etc., various embodiments are applicable in any suitable environment and/or with any suitable arrangement of objects, devices, etc.

Presenter 4505 has a headset 4515 and presentation remote 4520 that may be used to control the main presentation 4530 (e.g., PowerPoint® slides) as well as one or more other devices, and which may have one or more other functions.

Attendee 4510 is physically present in room 4500 , e.g., to view the presentation. Other attendees may be participating from other rooms (e.g., overflow rooms) as indicated at connected rooms sign 4545 , which shows which other rooms are “connected”. In some embodiments, connected rooms sign 4545 may indicate rooms which are separate meetings, but may be connected in that the meetings share a topic (e.g., ‘Project X”), share a type (e.g., a decision is being made), share a level (e.g., officers and directors are present), share a purpose (e.g., ‘training’), or for any other reason. Presenter 4505 , attendee 4510 , or any other attendee may contact a connected room using phone 4540 , headset 4515 , or presentation remote 4520 (e.g. touching communication display 4150 b or presentation remote 4100 to connect with room TR64). In some embodiments, contact with a user in another room may be made by touching communication display 4150 a to connect with a user such as Mary Chao.

Cameras 4525 a and 4525 b may track one or more events during the meeting and/or take actions based on such events. Cameras may track attendee attentiveness, engagement, whether or not the meeting stays on track, etc. Cameras may track any other events.

Projector 4535 may output a timely message, such as a projected message 4560 “Congratulations on the record sales level!” message to a meeting attendee who, for example, has just set a sales record.

Physical sign 4550 with 2D barcode may allow a user to scan the barcode and obtain relevant information. In various embodiments, headset 4515 or presentation remote 4520 act as a barcode scanner. In various embodiments, a user may scan the barcode to obtain or load the presentation (e.g., the presentation for the current meeting), to get a list of meeting attendees, to get the room schedule (e.g., schedule of meetings), and/or for any other purpose.

Display screen 4555 may include messages and/or information pertinent to the meeting (e.g., logistics, attendee whereabouts, attendee schedules), and/or any other information.

With reference to FIG. 46 , a room 4600 with objects is depicted in accordance with various embodiments. Room 4600 may be a living room, such as in a home. Room 4600 may be any other room in any other location. Room 4600 may include one or more objects, such as toys, fixtures, furniture etc. Room 4600 may include one or more users. Room 4600 may include one or more devices. While room 4600 depicts an exemplary environment and arrangement of objects, users, and devices, various embodiments are applicable in any suitable environment and/or with any suitable arrangement of objects and/or users and/or devices.

In various embodiments, room 4600 includes devices and/or sensors such as cameras 4605 a and 4605 b , motion sensor 4607 , projector 4609 , and digital picture frame 4638 . Room 4600 includes objects such as door 4612 , toy car 4614 , present 4618 , baby 4620 , vase 4622 , electrical outlet 4624 , sock 4626 , spinning tops 4628 , pacifier 4630 , tv remote 4632 , keys 4634 , painting 4636 , window 4640 , flies 4642 , and pizza 4644 . Room 4600 includes users such as adult 4646 , child 4616 , and child 4620 .

In one or more examples, child 4620 is crawling towards vase 4622 and/or electrical outlet 4624 , either of which present potential hazards. Namely, the vase can potentially fall and hurt the child, break, cause a mess, etc., and the outlet can cause shocks. One or more of cameras 4605 a and 4605 b and motion sensor 4607 may detect that the child is headed towards the vase and/or outlet. Projector 4609 may thereupon project a distracting image or video (e.g., a video of two fish playing) onto the floor in front of the child. This may delay the child. Camera 4605 a (or some other device) may output an audible warning message for the adult 4646 to hear. The message may say, “Baby heading in a dangerous direction—please intervene” or the like.

In one or more examples, toy car 4614 lies on the floor near doorway 4612 , and so causes a tripping hazard. Camera 4605 a may cause projector 4609 (or a laser pointer, or any other light) to spotlight the toy car. The adult 4646 may see the spotlight, investigate, and realize he should pick up the car. Or, another person who enters the room may have their attention drawn to the car by the spotlight, and thereby avoid tripping.

In one or more examples, child 4616 is opening present 4618 . This may represent a special moment that the gifter of the present (e.g., the child's aunt) would want to see. Accordingly, cameras 4605 a and 4605 b may capture and store images and/or video footage of the child opening the present. In various embodiments, images and/or video footage may be immediately streamed and/or sent to the giftor. In various embodiments, when the giftor subsequently visits the home and sees the opened gift, camera 4605 a may detect and identify the interaction between the gifter and the gift, and retrieve historical information about the gift. Such historical information may include the video footage. The video footage may then be projected on a wall (e.g., by projector 4609 ) for the giftor to see. In various embodiments, an image of the child opening the gift may appear on digital picture frame 4638 .

In one or more examples, spinning tops 4628 are on the floor near where a user (e.g., adult 4646 ) may step on them. Further the tops may not be in view of camera 4605 b , but they may be in view of camera 4605 b . Accordingly, camera 4605 b may identify the tops in an image and, when adult 4646 stands up, cause a warning to be output to the adult. In various embodiments, the warning includes light illumination by projector 4609 . However, since projector 4609 does not have a line-of-sight to the tops, projector 4609 may instead project onto the nearby coffee table an arrow, where the arrow is pointing toward the tops.

In one or more examples, a task may be associated with painting 4636 . The task may be to move the painting so as to cover a crack in the wall. A camera (e.g., camera 4605 a ) may identify the crack, and cause projector 4609 to highlight the crack. The task may be assigned to adult 4646 and/or to another user.

In one or more examples, room 4600 includes lost or misplaced items, such as pacifier 4630 , sock 4626 remote 4632 , and pizza 4644 . In various embodiments, a camera may identify such objects and assign a task to put them away (e.g., to put the pacifier in the sink to be washed, to put the sock in a hamper, to put the remote on the coffee table, to put the pizza in the refrigerator). When the task is assigned to a user, the projector 4609 may spotlight the objects so the user can more easily find them.

In one or more examples, room 4600 includes flies. In various embodiments, projector 4609 may spotlight the flies (e.g., guided by cameras 4605 a and 4605 b ). An audio message may accompany the spotlight (e.g., “Please catch the flies”, “Please shut the window so that more flies do not get in”).

In one or more examples, a user in the household returns from driving the family car, but forgets to leave the car key out for other drivers. Camera 4605 b may identify the driver, and also determine that the key to the family car is not among keys 4634 . Accordingly a prompt may be output to the user to leave the car key with the other keys 4634 .

With reference to FIG. 47 , a screen 4700 from an app used by presenters according to some embodiments is shown. The depicted screen shows app presentation remote setup functionality that can be employed by a user to set up parameters and functionality for a presentation remote 4100 . In some embodiments, the setup data is provided via central controller 110 to one or more presentation remotes. In FIG. 47 , the app is in a mode whereby presenters (or other users) can answer questions in order to define the parameters of a presentation remote. However various embodiments contemplate that an app may interact with other team members or meeting participants, including peripheral devices used by meeting participants (e.g. headsets, mice, cameras).

In some embodiments, the presenter 4705 (e.g. ‘Marlene Davis’) may select from a menu 4703 which displays one or more different modes of the software. In some embodiments, modes include ‘presentation remote setup’, ‘presentation remote commands setup’, ‘presentation remote supplemental devices setup’, ‘communication default modes’, etc.

In accordance with some embodiments, the GUI of screen 4700 may be made available via a software application operable to receive and output information in accordance with embodiments described herein. It should be noted that many variations of such graphical user interfaces may be implemented (e.g., menus and arrangements of elements may be modified, additional graphics and functionality may be added). The graphical user interface of FIG. 47 is presented in simplified form in order to focus on particular embodiments being described.

In some embodiments, the app may show categories of selectable options for a presenter, such as ‘presentation options’ 4710 . In this example, choices have been provided at 4715 , and represent a number of presentation files that may be chosen for storage in presentation remote 4100 data storage 4157 for use during upcoming presentations. In some cases, two versions of the same presentation may be listed, such as a ‘tech stack review (long version) and ‘tech stack review (short version). In such an embodiment, the presenter may be able to choose from one of those versions just prior to the presentation, selecting the appropriate one which reflects the current level of understanding of the participants, or reflects an amount of time that the presenter has for the presentation (which may change during the middle of the presentation and warrant the retrieval of the short version of the presentation). Presentation option 4720 relates to desired alert options which are provided at 4725 . For example, presenter 4705 might select ‘buzz presentation remote if I am not to slide 15 in 20 minutes’, providing the user with a warning if she is taking too much time to get through the slides. Presentation option 4730 relates to ways to designate the functionality of a configurable button #1 at 4735 . For example, presenter 4705 might select ‘assign task’ as the functionality of configurable button #1 (e.g. configurable button 4144 a of presentation remote 4100 ). During the presentation, pushing this button might therefore initiate a protocol of assigning a task to one or more meeting participants.

In some embodiments, the app could provide notifications to presenters as to presentation location changes, time changes, participant changes, cancellations, etc. Various embodiments contemplate that any other feedback data, or any other input data from a peripheral device, may be shown, may be shown over time, or may be shown in any other fashion.

In various embodiments, the device running the app (e.g., a smartphone or tablet), may communicate directly with central controller 110 and directly with peripheral devices (e.g., via Bluetooth®; e.g., via local wireless network), or may communicate with the corresponding peripheral devices through one or more intermediary devices (e.g., through the central controller 110 ; e.g., through the user device), or in any other fashion.

With reference to FIG. 48 , a screen 4800 for configuring a peripheral device according to some embodiments is shown. The screen may represent a screen in an app. The screen may be an output or rendering from a peripheral device. For example, a presentation remote may output text or graphics to a computer monitor (e.g., via a direct connection, via a user device to which the presentation remote is connected). The screen may be from a set-up wizard for a peripheral. Various embodiments contemplate that the user may configure a peripheral device in any suitable or applicable fashion. At 4802 , the user may configure which apps will have “enhanced presentation remote access”. Example apps include “PowerPoint®”, “Keynote®”, “Google Slides®”, etc. However, one or more alternative or additional apps may appear in various embodiments. Selected apps may interact with the presentation remote in non-standard, non-traditional, enhanced, ways. In various embodiments, such apps may have the ability to display information on a display screen of a presentation remote itself. In various embodiments, such apps may have the ability to send signals, alerts or warnings to the presentation remote, such as by causing lights on the presentation remote to shine, such as by causing lights on the presentation remote to change colors, such as by broadcasting a tone to the presentation remote, such as by causing the presentation remote to rumble, or in any other fashion. In various embodiments, a selected app may allow a presentation remote to move a presentation remote laser pointer in a custom fashion, such as by following lines in the app, moving stepwise from cell to cell in a spreadsheet app, or in any other fashion.

At 4804 , the user may select one or more other users or parties that may be associated with the presentation remote. These users may have the ability to send messages to the presentation remote, receive messages from the presentation remote, take control of the presentation remote, alter the function of the presentation remote, be on the same team as the owner of the presentation remote, combine inputs of the presentation remote with inputs from their own presentation remote or peripheral, or have any other relationship or any other association with the presentation remote. In various embodiments, for each user selected, the user may configure individual abilities or privileges (e.g., such as with a sub-menu for each selected user). At 4806 , the user may designate a default image for the presentation remote (e.g., to be displayed on a display screen of the presentation remote). At 4808 , the user may indicate default text that is to appear on the presentation remote. In various embodiments, a user may configure one or more other aspects of the presentation remote. In various embodiments, a user may configure special key combinations (e.g., hotkeys, shortcuts) on the presentation remote, and match them to what the effects will be in the corresponding app. In various embodiments, parameters for configuration may be presented in any suitable order or arrangement. There may be multiple screens, multiple windows, multiple tabs, selections that become visible when scrolling down a page, etc. While screen 4800 has been depicted with respect to a presentation remote, various embodiments contemplate that similar screens could be used for other peripheral devices.

With reference to FIG. 49 , a plot 4900 of a derived machine learning model according to some embodiments is shown. For the indicated model, data has been gathered relating an average number of meeting attendees (represented on the ‘X’ axis 4902 ) to the users meeting agenda items completed (represented on the ‘Y’ axis 4904 ). Each marker in the plot represents a single data point. Using the individual data points, a machine learning program has derived a best-fit model, represented by the continuous curve 4906 . The machine learning model seeks to predict a number of meeting agenda items completed based on the number of meeting attendees, even where no data has been gathered for similar average numbers of meeting attendees. In various embodiments, any suitable machine learning, artificial intelligence, or other algorithm may be used to derive a model from data. Any suitable cost or benefit function may be used, such as one that seeks to minimize a mean squared error between the model's prediction, and the measured values of the data. In various embodiments, more or less data may be used. Higher dimensional data may be used. Other types of data may be used. Other types of predictions may be made or sought.

Methods

Referring now to FIGS. 86A, 86B, and 86C , a flow diagram of a method 8600 according to some embodiments is shown. In some embodiments, the method 8600 may be performed and/or implemented by and/or otherwise associated with one or more specialized and/or specially-programmed devices and/or computers (e.g., the resource devices 102 a - n , the user devices 106 a - n , the peripheral devices 107 a - n and 107 p - z , the third-party device 108 , the and/or the central controller 110 ), computer terminals, computer servers, computer systems and/or networks, and/or any combinations thereof. In some embodiments, the method 8600 may cause an electronic device, such as the central controller 110 to perform certain steps and/or commands and/or may cause an outputting and/or management of input/output data via one or more graphical interfaces such as the interfaces depicted in FIGS. 67 and 85 .

The process diagrams and flow diagrams described herein do not necessarily imply a fixed order to any depicted actions, steps, and/or procedures, and embodiments may generally be performed in any order that is practicable unless otherwise and specifically noted. While the order of actions, steps, and/or procedures described herein is generally not fixed, in some embodiments, actions, steps, and/or procedures may be specifically performed in the order listed, depicted, and/or described and/or may be performed in response to any previously listed, depicted, and/or described action, step, and/or procedure. Any of the processes and methods described herein may be performed and/or facilitated by hardware, software (including microcode), firmware, or any combination thereof. For example, a storage medium (e.g., a hard disk, Random Access Memory (RAM) device, cache memory device, Universal Serial Bus (USB) mass storage device, and/or Digital Video Disk (DVD); e.g., the data storage devices 215 , 345 , 445 , 515 , 615 ) may store thereon instructions that when executed by a machine (such as a computerized processor) result in performance according to any one or more of the embodiments described herein. According to some embodiments, the method 8600 may comprise various functional modules, routines, and/or procedures, such as one or more AI-based algorithm executions.

Games

A process 8600 for conducting a game with a user participating in the game is now described according to some embodiments. At step 8603 , a user may register with the central controller 110 , according to some embodiments. The user may access the central controller 110 by visiting a website associated with the central controller, by utilizing an app that communicates with the central controller 110 , by engaging in an interactive chat with the central controller (e.g., with a chatbot associated with the central controller), by speaking with a human representative of the central controller (e.g., over the phone) or in any other fashion. The aforementioned means of accessing the central controller may be utilized at step 8603 and/or during any other step and/or in conjunction with any other embodiments. Using the example of a website, the user may type into one or more text entry boxes, check one or more boxes, adjust one or more slider bars, or provide information via any other means. Using an example of an app, a user may supply information by entering text, speaking text, transferring stored information from a smartphone, or in any other fashion. As will be appreciated, the user may supply information in any suitable fashion, such as in a way that is consistent with the means of accessing the central controller 110 . The user may provide such information as a name, password, preferred nickname, contact information, address, email address, phone number, demographic information, birthdate, age, occupation, income level, marital status, home ownership status, citizenship, gender, race, number of children, or any other information. The user may provide financial account information, such as a credit card number, debit card number, bank account number, checking account number, PayPal account identifier, Venmo account identifier or any other financial account information.

In some embodiments, the user may create or establish a financial account with the central controller 110 . The user may accomplish this, for example, by transferring funds from an external account (e.g., from a Venmo® account) to the central controller 110 , at which point the transferred funds may create a positive balance for the user in the new account. In some embodiments, the user may provide information about one or more preferences. Preferences may relate to one or more activities, such as playing games, learning, professional development, interacting with others, participating in meetings, or doing any other activities. In the context of a game, for example, preferences may include a preferred game, a preferred time to play, a preferred character, a preferred avatar, a preferred game configuration, or any other preferences. In the context of learning, preferences may include a preferred learning format (e.g., lecture or textbook or tutorial, etc.; e.g., visual versus aural; e.g., spaced sessions versus single crash course; etc.), a subject of interest, a current knowledge level, an expertise level in prerequisite fields, or any other preferences. In various embodiments, a user may provide preferences as to desired products or services. These preferences may, for example, guide the central controller in communicating advertisements or other promotions to the user. In various embodiments, preferences may include preferences regarding any field or activity.

The central controller 110 may store user information and user preferences, such as in user table 700 , user game profiles table 2700 , and/or in any other table or data structure. In various embodiments, a user may provide biometric or other identifying or other authenticating information to the central controller 110 . Such information may include, photographs of the user, fingerprints, voiceprints, retinal scans, typing patterns, or any other information. When a user subsequently interacts with the central controller 110 , the user may supply such information a second time, at which point the central controller may compare the new information to the existing information on file to make sure that the current user is the same user that registered previously. Biometric or other authenticating information may be stored by the central controller in a table, such as in authentication table 3600 . Further details on how biometrics can be used for authentication can be found in U.S. Pat. No. 7,212,655, entitled “Fingerprint verification system” to Turney, et al. issued May 1, 2007, at columns 4-7, which is hereby incorporated by reference.

At step 8606 , a user may register a peripheral device with the central controller 110 , according to some embodiments. Through the process of registering a peripheral device, the central controller may be made aware of the presence of the peripheral device, the fact that the peripheral device belongs to (or is otherwise associated with) the user, and the capabilities of the peripheral device. The user may also provide to the central controller one or more permissions as to how the central controller may interact with the peripheral device. The user may provide any other information pertinent to a peripheral device. In various embodiments, registering a peripheral device may be performed partly or fully automatically (e.g., the peripheral device may upload information about its capabilities automatically to the central controller 110 ). The user may provide information about the peripheral itself, such as type, the manufacturer, the model, the brand, the year of manufacture, etc. The user may provide specifications for the peripheral. These specifications may indicate what buttons, keys, wheels, dials, sensors, cameras, or other components the peripheral possesses. Specifications may include the quantities of various components (e.g., a mouse may have two or three buttons; e.g., a mouse may have one, two, or more LED lights; e.g., a camera peripheral may have one, two, three, etc., cameras). Specifications may include the capabilities of a given component. For example, a specification may indicate the resolution of a camera, the sensitivity of a mouse button, the size of a display screen, or any other capability, or any other functionality.

In various embodiments, the central controller 110 may obtain one or more specifications automatically. For example, once given information about the model of a peripheral, the central controller may access a stored table or other data structure that associates peripheral models with peripheral specifications. In various embodiments, information about a peripheral may be stored in a table, such as in peripheral device table 1000 . Any information stored in peripheral device table 1000 may be obtained from a user, may be obtained automatically from a peripheral, or may be obtained in any other fashion. In various environments, a user may provide the central controller with guidelines, permissions, or the like for interacting with the peripheral device. Permissions may include permissions for monitoring inputs received at the peripheral device. Inputs may include active inputs, such as button presses, key presses, touches, mouse motions, text entered, intentional voice commands, or any other active inputs. Inputs may include passive inputs (e.g., inputs supplied unconsciously or passively by the user), such as a camera image, a camera feed (e.g., a camera feed of the user), an audio feed, a biometric, a heart rate, a breathing rate, a skin temperature, a pressure (e.g., a resting hand pressure), a glucose level, a metabolite level, or any other passive input.

In some embodiments, separate permissions may be granted for separate types of inputs. In some embodiments, a global permission may be granted for all types of inputs. In some embodiments, a global permission may be granted while certain exceptions are also noted (e.g., the central controller is permitted to monitor all inputs except for heart rate). In various embodiments, permissions may pertain to how the central controller may use the information (e.g., the information can be used for adjusting the difficulty but not for selecting advertisements). In various embodiments, permissions may pertain to how long the central controller can store the information (e.g., the central controller is permitted to store information only for 24 hours). In various embodiments, permissions may pertain to what other entities may access the information (e.g., only that user's doctor may access the information). In various environments, the user may grant permissions to the central controller to output at or via the peripheral.

The user may indicate what components of the peripheral device may be used for output. For example, a mouse might have a display and a heating element. The user may grant permission to output text on the display, but not to activate the heating element. With reference to a given component, the user may indicate the manner in which an output can be made. For example, the user may indicate that a speaker may output at no more than 30 decibels, a text message on a screen may be no more than 50 characters, or any other restriction. The user may indicate when the central controller 110 may output via the peripheral (e.g., only during weekends; e.g., only between 9 p.m. and 11 p.m.). The user may indicate circumstances under which an output may be made on a peripheral. For example an output may be made only when a user is playing a particular type of game. This may ensure, for example, that the user is not bombarded with messages when he is trying to work.

In various embodiments, a user may indicate what other users or what other entities may originate a message or content that is output on the peripheral. For example, the user may have a group of friends or teammates that are granted permission to send messages that are then output on the user's peripheral device. A user may also grant permission to a content provider, an advertiser, a celebrity, or any other entity desired by the user. In various embodiments, a user may indicate what other users or entities may activate components of a peripheral device, such as triggering a heating element. In various embodiments, a user may grant permissions for one or more other users to take control of the peripheral device. Permission may be granted to take full control, or partial control. When a second user takes control of a first user's peripheral device, the second user may cause the peripheral device to transmit one or more signals (e.g., signals that control the movements or actions of a game character; e.g., signals that control the progression of slides in a slide presentation; e.g., signals that control the position of a cursor on a display screen).

It may be desirable to allow a second user to control the peripheral device of a first user under various circumstances. For instance, the second user may be demonstrating a technique for controlling a game character. As another example, the second user may be indicating a particular place on a display screen to which he wishes to call the attention of the first user (e.g., to a particular cell in a spreadsheet). In various embodiments, a user may indicate times and/or circumstances under which another user may take control of his peripheral device. For example, another user may only control a given user's peripheral device when they are on the same team playing a video game. Permissions for another user or a third-party to control a peripheral device may be stored in a table, such as in peripheral configuration table 1100 (e.g. in field 1110 ). Aforementioned steps (e.g., granting of permission) have been described in conjunction with a registration process. However, it will be appreciated that in various embodiments, the aforementioned steps may be performed at any suitable time and/or may be updated at any suitable time. For example, at any given time a user may update a list of other users that are permitted to control the users peripheral device. In various embodiments, a registration process may include more or fewer steps or items than the aforementioned.

At step 8609 , a user may configure a peripheral device, according to some embodiments. The user may configure such aspects as the operation of the peripheral device, what key sequences will accomplish what actions, the appearance of the device, and restrictions or parental controls that are placed on the device. With regard to the operation of the peripheral device, the user may configure one or more operating variables. These may include variables governing a mouse speed, a mouse acceleration, the sensitivity of one or more buttons or keys (e.g., on a mouse or keyboard), the resolution at which video will be recorded by a camera, the amount of noise cancellation to be used in a microphone, or any other operating characteristic. Operating characteristics may be stored in a table, such as in peripheral configuration table 1100 . In various embodiments, a user may configure input sequences, such as key sequences (e.g., shortcut key sequences). These sequences may involve any user input or combination of user inputs. Sequences may involve keys, scroll wheels, touch pads, mouse motions, head motions (as with a headset), hand motions (e.g., as captured by a camera) or any other user input. The user may specify such sequences using explicit descriptions (e.g., by specifying text descriptions in the user interface of a program or app, such as “left mouse button—right mouse button”), by checking boxes in an app (e.g., where each box corresponds to a user input), by actually performing the user input sequence one or more times (e.g., on the actual peripheral), or in any other fashion. For a given input sequence, a user may specify one or more associated actions. Actions may include, for example, “reload”, “shoot five times”, “copy formula” (e.g., in a spreadsheet), send a particular message to another user, or any other action. In various embodiments, an action may be an action of the peripheral itself. For example, pressing the right mouse button three times may be equivalent to the action of physically moving the mouse three feet to the right.

In various embodiments, a user may specify a sequence of actions that corresponds to an input sequence. For example, if the user scrolls a mouse wheel up and then down quickly, then a game character will reload and shoot five times in a row. A sequence of actions triggered by a user input may be referred to as a “macro”. A macro may allow a user to accomplish a relatively cumbersome or complex maneuver with minimal input required. In some embodiments, a peripheral device (or other device) may record a user's actions or activities in a live scenario (e.g., as the user is playing a live video game; e.g., as the user is editing a document). The recording may include multiple individual inputs by the user (e.g., multiple mouse movements, multiple key presses, etc.). These multiple inputs by the user may be consolidated into a macro. Thus in the future, for example, the user may repeat a similar set of multiple inputs, but now using a shortcut input. Configuration of user input sequences may be stored in a table, such as in table “mapping of user input to an action/message” 2600 .

In various embodiments, a user may configure the appearance of a peripheral device. The appearance may include a default or background image that will appear on the device (e.g., on a screen of the device). The appearance may include a color or intensity of one or more lights on the peripheral device. For example, LED lights on a keyboard may be configured to shine in blue light by default. The appearance may include a dynamic setting. For example, a display screen on a peripheral may show a short video clip over and over, or lights may cycle between several colors. An appearance may include a physical configuration. For example, a camera is configured to point in a particular direction, a keyboard is configured to tilt at a certain angle, or any other physical configuration. As will be appreciated, various embodiments contemplate other configurations of an appearance of a peripheral device. In various embodiments, a user may configure a “footprint” or other marker of a peripheral device. For example, the user may configure a mouse pointer as it appears on a user device (e.g., on a personal computer). In various embodiments, a configuration of an appearance may be stored in a table, such as in “peripheral configuration table” 1100 . In various embodiments, a user may configure restrictions, locks, parental controls, or other safeguards on the use of a peripheral.

Restrictions may refer to certain programs, apps, web pages, Facebook® pages, video games, or other content. When an attempt is made to use a peripheral in conjunction with restricted content, the functionality of the peripheral may be reduced or eliminated. For example, if a user attempts to click on a link on a particular web page (e.g., a web page with restricted content), then the users mouse button may not register the user's click. In various embodiments, restrictions may pertain to the motion or other usage of the peripheral device itself. A restriction may dictate that a peripheral device cannot be moved at more than a certain velocity, cannot be moved more than a certain distance, cannot be in continuous motion for more than some predetermined amount of time, cannot output sound above a particular volume, cannot flash lights at a particular range of frequencies (e.g., at 5 to 30 hertz), or any other restriction. Such restrictions may, for example, seek to avoid injury or other harm to the user of the peripheral, or to the surrounding environment. For example, a parent may wish to avoid having a child shake a peripheral too violently while in the vicinity of a fragile crystal chandelier. In various embodiments, a peripheral may identify its current user. For example, the peripheral may identify whether an adult in a house is using a peripheral, or whether a child in a house is using the peripheral. A peripheral may explicitly ask for identification (or some means of ascertaining identification, such as a password unique to each user), or the peripheral may identify a user in some other fashion (e.g., via a biometric signature, via a usage pattern, or in any other fashion).

In various embodiments, a peripheral may require authentication for a user to use the peripheral. For example, the peripheral may require a password, fingerprint, voiceprint or other authentication. In various embodiments, restrictions or parental controls may apply to individual users. For example, only the child in a particular house is restricted from accessing certain web content or video games. In this way, after identifying a user, a peripheral may implement or enforce restrictions only if such restrictions apply to the identified user. In various embodiments, a peripheral device may not function at all with one or more users (e.g., with any user other than its owner). This may, for example, discourage someone from taking or stealing another user's peripheral. In various embodiments, a user designates restricted content by checking boxes corresponding to the content (e.g., boxes next to a description or image of the content), by providing links or domain names for the restricted content, by designating a category of content (e.g., all content rated as “violent” by a third-party rating agency; e.g., all content rated R or higher) or in any other fashion. A user may designate one or more users to which restrictions apply by entering names or other identifying information for such users, by checking a box corresponding to the user, or in any other fashion. In various embodiments, a user may set up restrictions using an app (e.g., an app associated with the central controller 110 ), program, web page, or in any other fashion.

At step 8612 , a user may register for a game, according to some embodiments. The user may identify a game title, a time to play, a game level, a league or other desired level of competition (e.g., an amateur league), a mission, a starting point, a stadium or arena (e.g., for a sports game), a time limit on the game, one or more peripheral devices he will be using (e.g., mouse and keyboard; e.g., game console controller), a user device he will be using (e.g., a personal computer; e.g., a game console; e.g., an Xbox), a character, a set of resources (e.g., an amount of ammunition to start with; e.g., a weapon to start with), a privacy level (e.g., whether or not the game can be shown to others; e.g., the categories of people who can view the game play), or any other item pertinent to the game. In various embodiments, a user may sign a consent form permitting one or more aspects of the user's game, character, likeness, gameplay, etc. to be shown, shared, broadcast or otherwise made available to others. In various embodiments, a user may pay an entry fee for a game. The user may pay in any suitable fashion, such as using cash, game currency, pledges of cash, commitments to do one or more tasks (e.g., to visit a sponsors website), or in any other form.

In various embodiments, a user may register one or more team members, one or more opponents, one or more judges, one or more audience members, or any other participant(s). For example, the user may provide names, screen names, or any other identifying information for the other participants. In various embodiments, a user may designate a team identifier (e.g., a team name). One or more other users may then register and indicate that they are to be part of that team. Similarly, in various embodiments, a user may designate a game. Subsequently, one or more other users may then register and indicate that to are to be part of that game. Various embodiments contemplate that multiple participants may register for the same team or same game in any suitable fashion. In various embodiments, user information provided when registering with the central controller, when registering for a game, or provided at any other time or in any other fashion, may be stored in one or more tables such as in “user game profiles” table 2700 . In various embodiments, when a user has registered for a game, the user may be provided with messages, teasers, reminders, or any other previews of the game. In various embodiments, a peripheral device may show a timer or clock that counts down the time remaining until the game starts. In various embodiments, a peripheral device may change colors as game time approaches. For example, the peripheral device might change from displaying a green color to displaying a red color when there are less than five minutes remaining until game time. In various embodiments, a peripheral may sound an alarm when a game is about to start.

In the lead-up to a game (or at any other time) a user may take a tutorial. The tutorial may explain how to play a game, how to efficiently play a game, how to execute one or more actions during a game, how to use a peripheral effectively during a game, or may cover any other task or subject. In various embodiments, one or more components of a peripheral will attempt to draw a user's attention during a tutorial. For example, a key or a button may blink, light up, or change color. In another example, a button may heat up or create a haptic sensation. The intention may be for the user to press or actuate whatever component is drawing attention. For example, if the tutorial is teaching a user to press a series of buttons in succession, then the buttons may light up in the order of which they should be pressed. Once the user presses a first button that has been lit, the first button may go off and a second button may light up indicating that it too should be pressed. In various environments, a tutorial uses a combination of text or visual instruction, in conjunction with hands-on actuation of peripheral device components by the user. The text or visual instruction may be delivered via a user device, via a peripheral device (e.g., via the same peripheral device that the user is actuating), or via any other means.

At step 8615 , a user may initiate a game, according to some embodiments. In various embodiments, the game starts based on a predetermined schedule (e.g., the game was scheduled to start at 3 p.m., and does in fact start at 3 p.m.). In various embodiments, the user manually initiates gameplay (e.g., by clicking “start”, etc.). When a user begins playing, any team members, opponents, judges, referees, audience members, sponsors, or other participants may also commence their participation in the game. In various embodiments, a user may join a game that has been initiated by another user. For example, the user may join as a teammate to the initiating user or as some other participant.

At step 8618 , the central controller 110 may track user gameplay, according to some embodiments. The central controller 110 may track one or more of: peripheral device use; game moves, decisions, tactics, and/or strategies; vital readings (e.g., heart rate, blood pressure, etc.); team interactions; ambient conditions (e.g., dog barking in the background; local weather); or any other information. In various embodiments, the central controller 110 may track peripheral device activity or use. This may include button presses, key presses, clicks, double clicks, mouse motions, head motions, hand motions, motions of any other body part, directions moved, directions turned, speed moved, distance moved, wheels turned (e.g., scroll wheels turned), swipes (e.g., on a trackpad), voice commands spoken, text commands entered, messages sent, or any other peripheral device interaction, or any combination of such interactions. The peripheral device activity may be stored in a table, such as in ‘peripheral activity log’ table 2200 . Each activity or action of the peripheral device may receive a timestamp (e.g., see fields 2206 and 2208 ). In this way, for example, peripheral device activity may be associated with other circumstances that were transpiring at the same time. For example, a click of a mouse button can be associated with a particular game state that was in effect at the same time, and thus it may be ascertainable what a user was trying to accomplish with the click of the mouse (e.g., the user was trying to pick up a medicine bag in the game).

Peripheral device activities may be stored in terms of raw signals received from the peripheral device (e.g., bit streams), higher-level interpretations of signals received from the peripheral device (e.g., left button clicked), or in any other suitable fashion. In various embodiments, two or more actions of a peripheral device may be grouped or combined and stored as a single aggregate action. For example, a series of small mouse movements may be stored as an aggregate movement which is the vector sum of the small mouse movements. In various embodiments, the central controller may track vital readings or other biometric readings. Readings may include heart rate, breathing rate, brain waves, skin conductivity, body temperature, glucose levels, other metabolite levels, muscle tension, pupil dilation, breath oxygen levels, or any other readings. These may be tracked, for example, through sensors in a peripheral device. Vital readings may also be tracked indirectly, such as via video feed (e.g., heart rate may be discerned from a video feed based on minute fluctuations in skin coloration with each heartbeat). Vital readings or biometrics may be tracked using any suitable technique.

In some embodiments, the vital readings of a first user may be broadcast to one or more other users. This may add a level of excitement or strategy to the game. For example, one player may be able to discern or infer when another player is tense, and may factor that knowledge into a decision as to whether to press an attack or not. In various embodiments, the central controller 110 may track ambient conditions surrounding gameplay. These may include room temperature, humidity, noise levels, lighting, local weather, or any other conditions. The central controller may track particular sounds or types of sounds, such as a dog barking in the background, a horn honking, a doorbell ringing, a phone ringing, a tea kettle sounding off, or any other type of sound. In various embodiments, ambient conditions may be correlated to a user's gameplay. For example, the central controller 110 may determine that the user tends to perform better in colder temperatures. Therefore, ambient conditions may be used to make predictions about a user's game performance, or to recommend to a user that he seek more favorable ambient conditions (e.g., by turning on the air conditioning). In various embodiments, ambient conditions may be detected using one or more sensors of a peripheral device, using a local weather service, or via any other means.

In various embodiments, the central controller 110 may track game moves, decisions, tactics, strategies, or other game occurrences. Such a occurrences may include a weapon chosen by a user, a road chosen by a user, a path chosen, a door chosen, a disguise chosen, a vehicle chosen, a defense chosen, a chess move made, a bet made, a card played, a card discarded, a battle formation used, a choice of which player will covered which other player (e.g., in a combat scenario, which player will protect the back of which other player), a choice of close combat versus distant combat, or any other game choice made by a player or team of players. In various embodiments, the central controller may track decisions made by referees, judges, audience members, or any other participants. In various embodiments, the central controller 110 may track team interactions. The central controller may track text messages, messages, voice messages, voice conversations, or other signals transmitted between team members. The central controller may track resources passed between player characters (e.g., ammunition or medical supplies transferred). The central controller may track the relative positioning of player characters. The central controller may track any other aspect of team interaction. In various embodiments, the central controller 110 may utilize an aspect of a user's gameplay to identify the user. For example, the user may have a unique pattern of moving a mouse or hitting a keyboard. In some embodiments, a user may be subsequently authenticated or identified based on the aspect of the user's gameplay.

At step 8621 , the central controller 110 may react or respond to user gameplay, according to some embodiments. In various embodiments, the central controller may adjust one or more aspects of the game (e.g., difficulty level) based on user gameplay. The central controller may increase difficulty level if the user is scoring highly relative to other users, or relative to the current users prior scores at the same game. The central controller may decrease difficulty level if the user is scoring poorly relative to other users, is dying quickly, or is otherwise performing poorly. In various embodiments, if a user is primarily or overly reliant on one resource (e.g., on one particular weapon or vehicle), or on a small group of resources, then the central controller 110 may steer the game in such a way that the one resource (or small group of resources) is no longer as useful. For example, if the user has been relying on a motorcycle as transportation, then the central controller may steer the game such that the user has to navigate a swamp area where other vehicles (e.g., a canoe) may be preferable to a motorcycle. This may incentivize the user to become acquainted with other resources and/or other aspects of the game. In various embodiments, the central controller 110 may steer a game towards circumstances, situations, environments, etc., with which the player may have had relatively little (or no) experience. This may encourage the player to gain experience with other aspects of the game.

In various embodiments, elements of ambient conditions may be incorporated into a game itself. For example, if the central controller 110 detects a dog barking in the background, then a dog might also appear within a game. In various embodiments, the central controller 110 may advise or tell the user of an action to take based on observations of the user's gameplay. If the central controller has detected low metabolite levels (e.g., low sugar or low protein) with the user, the central controller may advise the user to eat and/or to quit. In various embodiments, the central controller may infer user health status from game play. In various embodiments, one or more vital signs (e.g., blood pressure) may be obtained directly or indirectly from sensors. In various embodiments, the central controller may utilize user actions as an indicator of health state or status. If a user's game performance has declined, then this may be indicative of health problems (e.g., dehydration, fatigue, infection, heart attack, stroke, etc.). In various embodiments, game performance may be measured in terms of points scored, points scored per unit of time, opponents neutralized, levels achieved, objectives achieved, time lasted, skill level of opponents beaten, or in terms of any other factor.

A decline in game performance may be defined as a reduced performance during a given time interval (e.g., the last 15 minutes, today, the most recent seven days) versus game performance in a prior time interval (e.g., the 15-minute period ending 15 minutes ago; e.g., the 15-minute period ending one hour ago; e.g., the 15-minute period ending this time yesterday; e.g., the day before yesterday; the seven-day period ending seven days ago; etc.). In various embodiments, the central controller may monitor for a decline of a certain amount (e.g., at least 10%) before conclusively determining that performance has declined. In various embodiments, a player's performance may be compared to that of other players (such as to that of other players of a similar skill level, such as to that of other players with a similar amount of experience, such as to all other players). If a player's performance is significantly worse than that of other players (e.g., 20% or more worse), then the central controller 110 may infer a health problem.

In various embodiments, improvements in a player's performance may be used to infer positive changes in health status (e.g., that the user is better rested; e.g., that the user has overcome an illness; etc.). In various embodiments, the central controller 110 may combine data on vital signs with data on player performance in order to infer health status. For example, an increased body temperature coupled with a decline in performance may serve as a signal of illness in the player. In various embodiments, the central controller 110 may initiate recording and/or broadcasting of user gameplay based sensor readings from a peripheral. Such sensor readings may include readings of vital signs. The central controller may also initiate recording and/or broadcasting based on inferred vital signs. This may allow the central controller, for example, to detect a level of excitement with the user, and initiate recording when the user is excited. The central controller may thereby capture footage that is more likely to be exciting, interesting, memorable, or otherwise noteworthy. In various embodiments, the central controller 110 may initiate recording when a user's heart rate exceeds a certain level. The level may be an absolute heart rate (e.g., one hundred beats per minute) or a relative heart rate (e.g., 20% above a user's baseline heart rate). In various embodiments, the central controller may initiate recording in response to a change in skin conductivity, blood pressure, skin coloration, breath oxygen levels, or in response to any other change in a user's vital signs.

In various embodiments, the central controller 110 may stop or pause recording when a user's vital sign or vital signs have fallen below a certain threshold or have declined by predetermined relative amount. In various embodiments, the central controller 110 may start recording or broadcasting when vital signs have fallen below a certain threshold (or decreased by a certain relative amount). The central controller may stop or pause recording when vital signs have increased above a certain threshold. In various embodiments, the central controller 110 may use a combination of sensor readings (e.g., of user vital signs) and user gameplay as a determinant of when to commence or terminate recording. For example, if the user's heart rate increases by 10% and the number of clicks per minute has increased by 20%, then the central controller may commence recording. In various embodiments, the central controller may track sensor inputs or other inputs from other users or participants, such as from audience members. These inputs may be used to determine when to start or stop recording or broadcasting. For example, the central controller may detect excitement levels in an audience member, and may thereby decide to record the ensuing gameplay action, as it may have a high chance of being interesting.

At step 8624 , a peripheral device may feature some aspect of the game, according to some embodiments. In various embodiments, a peripheral device may feature, convey, or otherwise indicate some aspect of the game. A peripheral may explicitly display information, such as an amount of ammunition remaining with a player, a number of damage points sustained by a player, a set of coordinates detailing a player's location in a game, the number of opponent characters within a particular radius of the player's character, or any other game information. The information may be displayed using alphanumeric characters, bar graphs, graphs, or using any other means of presentation. In various embodiments, game information may be conveyed by a peripheral indirectly. In various embodiments, the color of a component of a peripheral (e.g., of an LED) may vary based on the health of the player's game character. For instance, if the game character is at full strength, the LED may be green, while if the game character is one hit away from dying, then the LED may be red. In various embodiments, the LED may show a range of colors between red and green (e.g., each color within the range having a different mixture of red and green), to convey intermediate health statuses of the game character.

In various embodiments, a peripheral device may convey game information using a level of sound (e.g., louder sounds convey poorer health statuses of the game character), using a volume of sound, using a pitch of sound, using a tempo (e.g., which can be varied from slow to fast), using vibrations, using a level of heat, using a level of electric shock, or via any other means. In various embodiments, a peripheral device may display or otherwise convey an attribute of another player, such as an attribute of another player's gameplay or a vital sign of another player. For example, a peripheral device may display the heart rate of another player. As another example, the color of a component of a peripheral device may cycle in sync with the breathing cycle of another player (e.g., the LED varies from orange on an inhale to yellow on an exhale then back to orange on the next inhale, and so on).

At step 8627 , the central controller 110 may broadcast a game feed to others, according to some embodiments. For example, the feed may be broadcast via Twitch, via another streaming platform, via television broadcast, or via any other means. In various embodiments, part or all of a feed may be broadcast to a peripheral device, such as a peripheral device of an observing user. A feed may seek to mimic or replicate the experience of the playing user with the observing user. For example, if the playing user is receiving haptic feedback in his mouse, then similar haptic feedback may be broadcast to an observing user's mouse.

At step 8630 , the central controller 110 may trigger the presentation of an advertisement, according to some embodiments. In various embodiments, step 8630 may include the presentation of a promotion, infomercial, white paper, coupon, or any other similar content, or any other content. The advertisement may be triggered based on one or more factors, including: events in the game; detected user gameplay; sensor inputs; detected user vital signs; stored user preferences; ambient conditions; or based on any other factors. For example, upon detection of low glucose levels, an ad for a candy bar may be triggered. The advertisement may be presented to the user in various ways. the advertisement may appear within the gaming environment itself, such as on an in-game billboard. The advertisement may appear in a separate area on a screen, such as on the screen of a user device. The advertisement may appear as an overlay on top of the game graphics. The advertisement may temporarily interrupt gameplay, and may, e.g., appear full screen. In various embodiments, an advertisement may appear in full or in part on a peripheral device. For example, an advertisement may appear on a display screen of a mouse or of a keyboard. In various embodiments, a company's colors may be displayed with lights on a peripheral device. For example, LED Lights on a mouse may shine in the red white and blue of the Pepsi logo when a Pepsi advertisement is featured. In various embodiments, a peripheral device may broadcast sound, vibrations, haptic feedback, or other sensory information in association with an advertisement. For example, in conjunction with an advertisement for potato chips, a mouse may rumble as if to mimic the crunching of a potato chip.

At step 8633 , the user makes an in-game purchase, according to some embodiments. The user may purchase a game resource (e.g., a weapon, vehicle, treasure, etc.), an avatar, an aesthetic (e.g., a background image; e.g., a dwelling; e.g., a landscape), a game shortcut (e.g., a quick way to a higher-level or to a different screen; e.g., a quick way to bypass an obstacle), a health enhancement for a game character, a revival of a dead character, a special capability (e.g., invisibility to other players, e.g., flight), or any other item pertinent to a game. In various embodiments, the user may purchase an item external to a game, such as an item that has been advertised to the user (e.g., a pizza from a local restaurant). In various embodiments, the user may make a purchase using a financial account, such as a financial account previously registered or created with the central controller 110 . In various embodiments, prior to completing a purchase, the user may be required to authenticate himself. To authenticate himself, a user may enter a password, supply a biometric, and/or supply a pattern of inputs (e.g., mouse movements, e.g., keystrokes) that serve as a unique signature of the user. In various embodiments, an amount of authentication may increase with the size of the purchase. For example, one biometric identifier may be required for a purchase under $10, but two biometric identifiers may be required for a purchase over $10.

At step 8636 , User 1 and user 2 pass messages to each other's peripheral devices, according to some embodiments. In various embodiments, a message may include words, sentences, and the like, e.g., as with traditional written or verbal communication. A message may include text and/or spoken words (e.g., recorded voice, e.g., synthesized voice). In various embodiments, a message may include images, emojis, videos, or any other graphic or moving graphic. In various embodiments, a message may include sounds, sound effects (e.g., a drum roll; e.g., a well-known exclamation uttered by a cartoon character) or any other audio. In various embodiments, a message may include other sensory outputs. A message may include instructions to heat a heating element, instructions for generating haptic sensations, instructions for increasing or decreasing the resistance of a button or scroll wheel or other actuator, instructions for releasing scents or perfumes or other olfactory stimulants, or instructions for inducing any other sensation. For example, user 1 may wish to send a message to user 2 with text “you are on fire!” and with instructions to increase the temperature of a heating element in user 2's mouse. The message may generate increased impact for user 2 because the message is experienced in multiple sensory modalities (e.g., visual and tactile).

In various embodiments, a user may explicitly type or speak a message. In various embodiments, a user may employ a sequence of inputs (e.g., a shortcut sequence) to generate a message. The central controller 110 may recognize a shortcut sequence and translate the sequence using one or more tables, such as “mapping of user input to an action/message” table 2600 and “generic actions/messages” table 2500 . In various embodiments, a user may receive an alert at his peripheral device that he has received a message. The user may then read or otherwise perceive the message at a later time. The alert may comprise a tone, a changing color of a component of the peripheral device, or any other suitable alert. In various embodiments, a message may include an identifier, name, etc., for an intended recipient. In various embodiments, a message may include an indication of a peripheral device and/or a type of peripheral device that is the intended conveyor of the message. In various embodiments, a message may include an indication of a combination of devices that are the intended conveyors of the message. For example, a message may include instructions for the message to be conveyed using a mouse with a display screen and any peripheral device or user device with a speaker. In various embodiments, a message may be broadcast to multiple recipients, such as to all members of a gaming team. The message may be presented to different recipients in different ways. For example the recipients might have different peripheral devices, or different models of peripheral devices. In various embodiments, a message may contain instructions for conveying the message that specify a device-dependent method of conveyance. For example, if a recipient has a mouse with LED lights, then the LED lights are to turn purple. However, if a recipient has a mouse with no LED lights, then the recipient's computer monitor is to turn purple.

At step 8639 , User 1 and user 2 jointly control a game character, according to some embodiments. In various embodiments, user 1 may control one capability of the game character while user 2 controls another capability of the game character. Different capabilities of the same game character may include: moving, using a weapon, firing a weapon, aiming a weapon, using individual body parts (e.g., arms versus legs; e.g., arms for punching versus legs for kicking), looking in a particular direction, navigating, casting a spell, grabbing or procuring an item of interest (e.g., treasure, e.g., medical supplies), building (e.g., building a barricade), breaking, solving (e.g., solving an in-game puzzle), signaling, sending a message, sending a text message, sending a spoken message, receiving a message, interpreting a message, or any other capability. For example, user 1 may control the movement of a character, while user 2 may control shooting enemy characters with a weapon. For example, user 1 may control the arms of a character, while user 2 may control the legs of a character. For example, user 1 may control the movement of a character, while user 2 communicates with other characters. In various embodiments, user 1 and user 2 jointly control a vehicle (e.g., spaceship, tank, boat, submarine, robot, mech robot), animal (e.g., horse, elephant), mythical creature (e.g., dragon, zombie), monster, platoon, army, battalion, or any other game entity. For example, user 1 may control the navigation of a spaceship, while user 2 may control shooting enemy spaceships.

In operation, the central controller 110 may receive inputs from each of user 1 and user 2. The central controller may interpret each input differently, even if they are coming from similar peripheral devices. For example, inputs from user 1 may be interpreted as control signals for a character's legs, while inputs from user 2 are interpreted as control signals for a character's arms. Prior to a game (e.g., during registration), two or more users may indicate an intent to control the same character. The users may then collectively select what aspect of the character each will control. For example, each user may check a box next to some aspect of a character that they intend to control. Subsequently, the central controller may interpret control signals from the respective users as controlling only those aspects of the character for which to respectively signed up. In various embodiments, one or more users may indicate an intent to control the same character at some other time, such as after a game has started. In various embodiments, inputs from two or more users may be combined or aggregated in some way to control the same character, and even to control the same aspect(s) of the same character. For example, the motion of a character may be determined as the sum of the control signals from the respective users. For example, if both user 1 and user 2 attempt to move the character to the right, then the character may in fact move right. However, if user 1 and user 2 attempt to move the character in opposite directions, then the character may not move at all. In various embodiments, control signals from two or more users may be combined in different ways in order to determine an action of a character. For example, the control signal of one user may take priority over the control signal of another user when there is conflict, or the control signal of one user may be weighted more heavily than the control signal of another user. In various embodiments, more than two users may jointly control a game character, vehicle, animal, or any other game entity.

At step 8642 , User 1 and user 2 vote on a game decision, according to some embodiments. A game decision may include any action that can be taken in a game. A game decision may include a route to take, a weapon to use, a vehicle to use, a place to aim, a shield to use, a message to send, a signal to send, an evasive action to take, a card to play, a chess piece to move, a size of a bet, a decision to fold (e.g., in poker), an alliance to make, a risk to attempt, a bench player to use (e.g., in a sports game), an item to purchase (e.g., a map to purchase in a game) or any other game decision. In various embodiments, when a decision is to be made, the central controller may explicitly present the available choices to all relevant users (e.g., via menu). Users may then have the opportunity to make their choice, and the choice with the plurality or majority of the vote may be implemented. In various embodiments, decisions are not presented explicitly. Instead, users may signal their desired actions (e.g., using standard game inputs), and the central controller may implement the action corresponding to majority or plurality of received signals. As will be appreciated, various other methods may be used for voting on an action in a game and such methods are contemplated according to various embodiments. In various embodiments, the votes of different users may be weighted differently. For example, the vote of user 1 may count 40%, while the votes for each of users 2, 3 and 4 may count for 20%. A candidate action which wins the weighted majority or weighted plurality of the vote may then be implemented.

At step 8645 , user 2 controls user 1's peripheral device, according to some embodiments. There may be various reasons for user 2 to control the peripheral device of user 1. User 2 may be demonstrating a technique, tactic, strategy, etc., for user 1. User 2 may configure the peripheral device of user 1 in a particular way, perhaps in a way that user 1 was not able to accomplish on his own. The peripheral device belonging to user 1 may have more capabilities than does the peripheral device belonging to user 2. Accordingly, user 2 may need to “borrow” the capabilities of user 1's peripheral device in order to execute a maneuver, or perform some other task (e.g., in order to instruct or control user 2's own character). User 2 may take control of the peripheral device of user 1 for any other conceivable reason. In various embodiments, to control the peripheral device of user 1, user 2 (e.g., a peripheral device of user 2, e.g., a user device of user 2) may transmit control signals over a local network, such as a network on which both user 1's peripheral and user 2's peripheral reside. In various embodiments, control signals may be sent over the internet or over some other network, and may be routed through one or more other devices or entities (e.g., through the central controller 110 ). In various embodiments, the peripheral device of user 1 may include a module, such as a software module, whose inputs are control signals received from user 2 (or from some other user), and whose outputs are standard component outputs that would be generated through direct use of the peripheral device of user 1. For example, a control signal received from user 2 may be translated by the software module into instructions to move a mouse pointer for some defined distance and in some defined direction.

In various embodiments, the peripheral device of user 1 may include a module, such as a software module, whose inputs are control signals received from user 2 (or from some other user), and whose outputs become inputs into the peripheral device of user 1 and/or into components of the peripheral device of user 1. For example, the output of the software module may be treated as an input signal into a mouse button, as an input signal to a sensor on the peripheral device of user 1, or as an input signal to the entire mouse. The output of the software module would thereby mimic, for example, the pressing of a mouse button on the peripheral device of user 1, or the moving of the peripheral device of user 1. In various embodiments, the software module may store a table mapping inputs (e.g., control signals received from user 2), to output signals for: (a) transmission to a user device; or (b) use as inputs to components of the peripheral device of user 1. In various embodiments, the software module may translate inputs received from another user into outputs using any other algorithm or in any other fashion.

In various embodiments, a control signal received from user 2 can be used directly (e.g., can be directly transmitted to the user device of user 1; e.g., can be directly used for controlling a game character of user 1), without modification. The peripheral device of user 1 would then be simply relaying the control signal received from user 2. In various embodiments, a hardware module or any other module or processor may be used for translating received control signals into signals usable by (or on behalf of) the peripheral device of user 1. In various embodiments, user 2 must have permission before he can control the peripheral device of user 1. User 1 may explicitly put user 2 on a list of users with permissions. User 1 may grant permissions to a category of users (e.g., to a game team) to which user 2 belongs. User 1 may grant permission in real time, such as by indicating a desire to pass control of a peripheral to user 2 in the present moment. In various embodiments, permissions may be temporary, such as a lasting a fixed amount of time, lasting until a particular event (e.g., until the current screen is cleared), lasting until to are withdrawn (e.g., by user 1), or until any other suitable situation. In various embodiments, user 1 may signal a desire to regain control of his peripheral device and/or to stop allowing user 2 to control his peripheral device. For example, user 1 may enter a particular sequence of inputs that restore control of the peripheral device to user 2.

At step 8648 , a game occurrence affects the function of a peripheral device, according to some embodiments. A game occurrence may include a negative occurrence, such as being hit by a weapon, by a strike, or by some other attack. A game occurrence may include crashing, falling into a ravine, driving off a road, hitting an obstacle, tripping, being injured, sustaining damage, dying, or any other mishap. A game occurrence may include losing points, losing resources, proceeding down a wrong path, losing a character's ability or abilities, or any other occurrence. A game occurrence may include striking out in a baseball game, having an opponent score points, having a goal scored upon you (e.g., in soccer or hockey), having a touchdown scored upon you, having a team player get injured, having a team player foul out, or any other occurrence. A game occurrence may include losing a hand of poker, losing a certain amount of chips, losing material in a chess game, losing a game, losing a match, losing a skirmish, losing a battle, or any other game occurrence.

The functionality of a peripheral device may be degraded in various ways, in various embodiments. A component of the peripheral device may cease to function. For example, a button of a mouse or a key on a keyboard may cease to register input. An output component may cease to function. For example, an LED on a mouse may cease to emit light. A display screen may go dark. A speaker may stop outputting sound. In various embodiments, a component of a peripheral device may partially lose functionality. For example, a speaker may lose the ability to output sounds above a particular frequency. A display screen may lose the ability to output color but retain the ability to output black and white. As another example, a display screen may lose the ability to output graphics but may retain the ability to output text. In various embodiments, the peripheral may lose sensitivity to inputs. A button or key may require more pressure to activate. A button or key may not register some proportion or percentage of inputs. For example, a mouse button may not register every second click. Thus, in order to accomplish a single click, a player would have to press the mouse button twice. A microphone may require a higher level of incident sound in order to correctly interpret the sound (e.g., in order to correctly interpret a voice command). A camera may require more incident light in order to capture a quality image or video feed. Various embodiments contemplate that a peripheral may lose sensitivity to inputs in other ways.

In various embodiments, one or more categories of inputs may be blocked or disabled. A mouse motion in one direction (e.g., directly to the “East”) may not register. (However, a user may compensate by moving the mouse first “Northeast” and then “Southeast”). In various embodiments, a sensor may be blocked or disabled. Thus, for example, the teammate of a user may be unable to ascertain the user's heart rate. Voice inputs may be disabled. Arrow keys may be disabled while text keys retain their function. Any other category of inputs may be blocked or disabled, according to some embodiments. In various embodiments, a peripheral device may generate outputs that are uncomfortable, distracting, and/or painful. For example, LED lights on a mouse may shine at full brightness, or may blink very rapidly. A heating element may become uncomfortably hot. A speaker might output a screeching sound. In various embodiments, a peripheral device may be degraded temporarily, for a predetermined amount of time (e.g., for 5 minutes) after which full functionality may be restored. In various embodiments, functionality returns gradually over some period of time. For example, functionality may return in a linear fashion over a period of 5 minutes. In various embodiments, full functionality may not necessarily be restored. In various embodiments, a peripheral device may return asymptotically to full functionality. In various embodiments, functionality is permanently effected (e.g., until the end of a game). In various embodiments, functionality may be improved or restored only upon the occurrence of some other game event (e.g., a positive game event for the player; e.g., the player successfully lands a shot on his opponent; e.g., the player finds a green ruby in the game).

At step 8651 , there is a pause/break in game play, according to some embodiments. In various embodiments, a player desires to stop playing, such as to temporarily stop playing. Perhaps the player needs to get a drink or take a phone call. A player may take one or more actions to indicate he is taking a break. A player may turn over his mouse, flip over his keyboard, place his camera face-down, or otherwise position a peripheral in an orientation or configuration where it would not normally be used or would not normally function. The peripheral may then detect its own orientation, and signal to the central controller 110 that the user is taking a break. In various embodiments, when a user takes a break, the central controller takes note of a lack of input from the user (e.g., from a peripheral device of the user), and infers that the user is taking a break. When a user takes a break, the central controller 110 may pause gameplay, may inform other participants that the player has taken a break, may protect the player's character from attacks, may pause a game clock, or may take any other suitable action.

At step 8654 , the game concludes, according to some embodiments. The central controller 110 may thereupon tally up scores, determine performances, determine winners, determine losers, determine prizes, determine any records achieved, determine any personal records achieved, or take any other action. The central controller 110 may award a prize to a user. A prize may include recognition, free games, game resources, game skins, character skins, avatars, music downloads, access to digital content, cash, sponsor merchandise, merchandise, promotional codes, coupons, promotions, or any other prize. In various embodiments, a peripheral device of the user may assume an altered state or appearance in recognition of a user's achievement in a game. For example, LEDs on a user's mouse may turn purple, a speaker might play a triumphant melody, a mouse may vibrate, or any other change may transpire. In various embodiments, user achievements may be broadcast to others. For example, the central controller 110 may broadcast a message to a user's friends or teammates detailing the achievements of the user.

At step 8657 , a game highlight reel is created, according to some embodiments. The highlight reel may include a condensed or consolidated recording of gameplay that has transpired. The highlight reel may include sequences with high action, battle sequences, sequences where a player neutralized an opponent, sequences where a player sustained damage, sequences where a player scored points, or any other sequences. A highlight reel may include recorded graphics recorded audio, recorded communications from players, or any other recorded aspect of a game. In various embodiments, the highlight reel contains sufficient information to recreate a game, but does not necessarily record a game in full pixel-by-pixel detail. The highlight reel may store game sequences in compressed format. In various embodiments, a highlight reel may include sequences where a peripheral device has recorded sensor inputs meeting certain criteria. For example, a highlight reel may include all sequences where a player's heart rate was above 120. As another example, a highlight reel may include the 1% of the game where the users measured skin conductivity was the highest.

In various embodiments, a highlight reel may incorporate or recreate sensory feedback, such as sensory feedback to mimic what occurred in the game. For example, when a user's friend watches the highlight reel, the user's friend may have the opportunity to feel haptic feedback in his mouse just as the user felt during the actual game play. Thus, in various embodiments, a highlight reel may contain not only visual content, but also tactile content, audio content, and/or content for any other sensory modality, modality, or any combination of modalities. Further details on how haptic feedback may be generated can be found in U.S. Pat. No. 7,808,488, entitled “Method and Apparatus for Providing Tactile Sensations” to Martin, et al. issued Oct. 5, 2010, at columns 3-6, which is hereby incorporated by reference. In various embodiments, the central controller 110 may notify one or more other users about the existence of a highlight reel, e.g., by sending them the file, a link to the file, by sending an alert to their peripheral device, or in any other fashion.

At step 8660 , the central controller 110 generates recommendations for improvement of the user's gameplay, according to some embodiments. In various embodiments, the central controller 110 may analyze the user's gameplay using an artificial intelligence or other computer program. The artificial intelligence may recreate game states that occurred when the user played, and decide what it would have done in such game states. If these decisions diverge from what the user actually decided, then the central controller may inform the player of the recommendations of the artificial intelligence, or otherwise note such game states. If the artificial intelligence agrees with what the user did, then the central controller may indicate approval to the user. In various embodiments, a user may have the opportunity to replay a game, or part of a game, from a point where the user did not perform optimally or did not make a good decision. This may allow the user to practice areas where his skill level might need Improvement. In various embodiments, the central controller 110 may compare a user's decisions in a game to the decisions of other players (e.g., to skillful or professional players; e.g., to all other players) made at a similar juncture, or in a similar situation, in the game. If the users decisions diverge from those of one or more other players, then the central controller may recommend to the user that he should have made a decision more like that of one or more other players, or the central controller may at least make the user aware of what decisions were made by other players.

Storage Devices

Referring to FIG. 71A , FIG. 71B , FIG. 71C , FIG. 71D , and FIG. 71E , perspective diagrams of exemplary data storage devices 7140 a - e according to some embodiments are shown. The data storage devices 7140 a - e may, for example, be utilized to store instructions and/or data such as: data in the data tables of FIGS. 7-29, 31-37, 50-62, 64-66, 70, 73-78, 87-89 ; instructions for AI algorithms; instructions for facilitating a meeting; instructions for facilitating game play; instructions for optimizing emissions of a meeting; and/or any other instructions. In some embodiments, instructions stored on the data storage devices 7140 a - e may, when executed by a processor, cause the implementation of and/or facilitate the methods: 3000 of FIG. 30 ; 7900 of FIGS. 79A-C ; 8400 of FIG. 84 ; 8600 of FIGS. 86A-C ; 9000 of FIG. 90 , and/or portions thereof, and/or any other methods described herein.

According to some embodiments, the first data storage device 7140 a may comprise one or more various types of internal and/or external hard drives. The first data storage device 7140 a may, for example, comprise a data storage medium 7146 that is read, interrogated, and/or otherwise communicatively coupled to and/or via a disk reading device 7148 . In some embodiments, the first data storage device 7140 a and/or the data storage medium 7146 may be configured to store information utilizing one or more magnetic, inductive, and/or optical means (e.g., magnetic, inductive, and/or optical-encoding). The data storage medium 7146 , depicted as a first data storage medium 7146 a for example (e.g., breakout cross-section “A”), may comprise one or more of a polymer layer 7146 a - 1 , a magnetic data storage layer 7146 a - 2 , a non-magnetic layer 7146 a - 3 , a magnetic base layer 7146 a - 4 , a contact layer 7146 a - 5 , and/or a substrate layer 7146 a - 6 . According to some embodiments, a magnetic read head 7148 a may be coupled and/or disposed to read data from the magnetic data storage layer 7146 a - 2 .

In some embodiments, the data storage medium 7146 , depicted as a second data storage medium 7146 b for example (e.g., breakout cross-section “B”), may comprise a plurality of data points 7146 b - 2 disposed with the second data storage medium 7146 b . The data points 7146 b - 2 may, in some embodiments, be read and/or otherwise interfaced with via a laser-enabled read head 7148 b disposed and/or coupled to direct a laser beam through the second data storage medium 7146 b . In some embodiments, the second data storage device 7140 b may comprise a CD, CD-ROM, DVD, Blu-Ray™ Disc, and/or other type of optically-encoded disk and/or other storage medium that is or becomes known or practicable. In some embodiments, the third data storage device 7140 c may comprise a USB keyfob, dongle, and/or other type of flash memory data storage device that is or becomes known or practicable. In some embodiments, the fourth data storage device 7140 d may comprise RAM of any type, quantity, and/or configuration that is or becomes practicable and/or desirable. In some embodiments, the fourth data storage device 7140 d may comprise an off-chip cache such as a Level 2 (L2) cache memory device. According to some embodiments, the fifth data storage device 7140 e may comprise an on-chip memory device such as a Level 1 (L1) cache memory device.

The data storage devices 7140 a - e may generally store program instructions, code, and/or modules that, when executed by a processing device, cause a particular machine to function in accordance with one or more embodiments described herein. The data storage devices 7140 a - e depicted in FIG. 71A , FIG. 71B , FIG. 71C , FIG. 71D , and FIG. 71E are representative of a class and/or subset of computer-readable media that are defined herein as “computer-readable memory” (e.g., non-transitory memory devices as opposed to transmission devices or media).

Turning now to FIG. 72 , a diagram of a person with associated biometric data 7200 according to some embodiments is shown.

The depicted biometric data is intended for illustrative purposes, and does not necessarily depict actual data read from an actual human being.

In FIG. 72 , an individual 7202 has various types of associated biometric data. Further, a given type of biometric data may be associated with a given part of the body. Facial measurements 7204 are associated with the user's face. Electroencephalogram (EEG) data 7206 is associated with the user's head (i.e., with the brain). Iris and/or retinal data 7208 are associated with the user's eye(s). Voice data 7210 and 7212 is associated with the user's mouth. Fingerprint data 7214 are associated with the user's hand. Heart waveforms 7216 , such as electrocardiogram (ECG/EKG), arterial pressure waves, etc. are associated with the user's heart. It will be noted, however, that associations between data and body parts are made for convenience and could be made in any suitable fashion. For example, voice data may just as well be associated with a user's lungs as with his mouth.

In various embodiments, biometric data is used to establish features and/or combinations of features that can be uniquely linked or tied to an individual. The following discussion represents some methods of extracting and using features according to some embodiments. However, it will be appreciated that other methods of extracting and features could be used and are contemplated by various embodiments herein.

With respect to facial measurements 7204 , raw data may include an image of a face, such as an image captured by a video camera. The image may be processed (e.g., using edge detection, peak detection, etc.) to determine the location of “landmarks”, such as the centers of eyes, the corners of lips, the tips of cheekbones, the bridge of a nose, etc. Distances may then be determined between various combinations of landmarks (e.g., between nearby landmarks). At 7204 are depicted various exemplary distances, including a distance between the centers of the eyes 7220 a , a distance from the bridge of the nose to the tip of the nose 7220 b , a distance from a first corner of the nose to a first cheekbone 7220 c , and a distance from a second corner of the nose to a second cheekbone 7220 d . In various embodiments, any suitable landmarks may be used, and any suitable distances may be used.

In various embodiments, to allow for different ranges from the subject at which an image may be captured, distances between landmarks may be normalized, such as by dividing all distances between landmarks by a particular distance (e.g., by the distance between the centers of the eyes 7220 a ). In such cases, all distances are effectively expressed as multiples of the particular distance (e.g., as multiples of distance 7220 a ). Normalized distances may then be used as the “X” input (i.e., a vector of inputs) to a classification algorithm, or other AI algorithm, or other algorithm.

Whereas some biometric markers remain relatively constant (e.g., fingerprints), EEG data can change in response to a user's actions or to stimuli experienced.

Methods for classifying individuals based on EEG data are discussed in the paper “Exploring EEG based Authentication for Imaginary and Nonimaginary tasks using Power Spectral Density Method”, Tze Zhi Chin et al 2019 IOP Conf. Ser.: Mater. Sci. Eng. 557 012031, the entirety of which is incorporated herein for all purposes.

With respect to EEG data 7206 , raw data may be determined from electrodes placed at two or more points on a user's head. In various embodiments, one of the electrodes is placed proximate to the motor cortex. In the “10-20 system”, the electrode may correspond to the “C4” electrode.

A user is asked to imagine performing a task repeatedly, such as opening and closing his hand once every second for sixty seconds, where the seconds are marked with an audible tone (e.g., with a metronome). In various embodiments, any suitable task may be performed. In various embodiments, the task need not be repetitive.

As the user performs the imaginary task, a voltage differential is measured between two electrodes. An amplifier may be used to amplify the voltage differential. The voltage differential may be recorded as a function of time (e.g., using multiple samples; e.g., with a sample rate of 1024 Hz), thereby generating a time series waveform. In fact, voltage differentials may be recorded across multiple pairs of electrodes, thereby generating multiple waveforms (i.e., one waveform for each pair of electrodes). Graphic 7206 shows exemplary waveforms from 16 different pairs of electrodes.

The raw waveform(s) may be filtered to preserve only certain ranges of frequencies. Commonly recognized frequency bands with respect to EEG data include delta, theta, alpha, beta, and gamma frequency bands. In various embodiments, a bandpass filter (e.g., a Butterworth bandpass filter) is used to preserve the beta frequency band (from 13 to 30 Hz).

The spectral density of the filtered waveform is then estimated using Welch's method. Welch's method includes segmenting the filtered time-series into overlapping 1-second segments, applying a windowing function at each segment, transforming the results using a discrete Fourier transform, and computing the squared magnitudes of the transformed results. The squared magnitudes are then averaged across all the results (i.e., all the segments). At the end is a set of frequency “bins” and associated power measurements for each bin, i.e., a power spectral density. In various embodiments, other methods of computing a power spectral density may be used.

Features are then extracted from the power spectral density. In some embodiments, features include each of the: mean (i.e., the mean power magnitude across all the frequency bins), median, mode, variance, standard deviation, minimum and maximum.

In some embodiments, features are the individual power levels for the respective frequency bins.

Once extracted, features then serve as an input to a K-nearest neighbor classification algorithm. In various embodiments where authentication of a user is desired, the feature vector (i.e., the “X” vector) must fall within a predetermined “distance” of the reference vector (i.e., the “Y” vector) for the user in order to make an affirmative authentication. In various embodiments, any other suitable algorithm may be used.

In various embodiments, rather than asking a user to perform a particular task, the headset or central controller 110 may observe a task that the user is performing and/or a stimuli that the user is experiencing. For example, the headset may observe (e.g., via a forward facing camera in the headset) that a user is looking at a particular piece of machinery. A waveform may be determined at the time of the task or stimuli, and this waveform may be compared to a reference waveform generated under similar conditions (e.g., when the user was performing a similar task, or experiencing similar stimuli).

In various embodiments, a classification algorithm (or other algorithm), seeks to determine not whether a subject corresponds to a particular individual, but rather whether a subject's mental state corresponds to a particular mental state (e.g., “alert”, “drowsy”, “drunk”, etc.). For example, it may be desirable to assess whether an individual is in an alert mental state prior to entering a room containing dangerous equipment.

The process for classifying a mental state may proceed along similar lines, but where a reference signal is not necessarily derived from the subject being tested. Rather, a reference signal for an “alert” mental state may come from a different individual, or may represent an “average” signal from various individuals each of whom is known to be in an “alert” mental state.

Various embodiments seek to classify a mental state of “recognition” or “familiarity”, in contrast to such states as “novelty” or “confusion”. In such embodiments, a user may see or be shown a stimulus (such as a piece of lab equipment). After having experienced the stimulus (e.g., seen the object), the user's mental state may be classified as one of “recognition”, or “novelty”. It may thereby be determined whether or not the user has had prior experience with the stimulus (e.g., whether the user has seen the object before). In authentication embodiments, a user may be shown an object which the authentic user will likely recognize, but which an imposter likely will not. Then, based on the user's classified mental state, the users identity may be confirmed, or not.

With respect to iris and/or retinal data 7208 , raw data may include an image of an iris or retina. The captured image may be divided into sectors. These sectors may be of standardized size and shape (e.g., a sector encompasses 45 degrees of arc and one third the radius of the image of interest, e.g., one third the radius of the iris). Exemplary sectors are depicted at 7224 a , 7224 b , and 7224 c . Various embodiments contemplate, however, that more or fewer sectors could be used, and differently shaped sectors could be used.

For each sector, an overall grayscale metric may be determined. For example, a sector that is very light in color receives a metric of 0, while a sector that is very dark in color receives a metric of 1. In various embodiments, the grayscale metric may be determined by averaging the color across the whole sector (e.g., by taking an average value of all the constituent pixels falling within a sector).

In various embodiments, to allow for different illuminations at which an image might be captured, grayscale values for sectors may be normalized. For example, the brightest sector receives a value of 0, the darkest sector receives a value of 1, and grayscale values for other sectors are scaled so that their proportionate distances from the values of the brightest and darkest sectors remain the same.

Once sectors receive grayscale values, such values may then be used as the “X” input to a classification algorithm, etc.

With respect to voice data 7210 , raw data may include pressure data sampled from a microphone (e.g., at 48 kHz), thereby generating the depicted time series waveform. The waveform may be transformed into the frequency domain, such as via a Fourier transform, thereby generating a frequency spectrum 7212 . A peak detection algorithm may then be used to find peak frequencies (i.e., frequencies representing local maxima in the frequency spectrum). A predetermined number of the most strongly represented peak frequencies may be selected. For example, the 10 strongest peak frequencies may be selected. These may be sorted by amplitude, and then used as the “X” input to a classification algorithm, etc.

In various embodiments, when peak frequencies are detected, only fundamental frequencies are considered, and harmonic frequencies are eliminated from consideration. For example, if there are peaks detected at 440 Hz and at 880 Hz, the peak at 880 Hz may be eliminated from consideration.

In various embodiments, rather than detecting peak frequencies, amplitudes a1, a2, a3, etc. may be recorded for a set of predetermined frequencies f1, f2, f3, etc. The amplitudes may then be used as the “X” input to a classification algorithm, etc.

With respect to fingerprint data 7214 , raw data may include an image of a fingerprint. The captured image may be divided into regions. These regions may be of standardized size and shape (e.g., a region is a square 0.5 millimeters on a side). Exemplary regions are depicted at 7240 a , 7240 b , and 7240 c . For each region, an overall grayscale metric may be determined. And analysis may proceed as described above with respect to iris/retinal data 7208 .

With respect to heart waveforms 7216 , raw data may include, for example, an ECG waveform. A typical ECG waveform may include five standard segments, labeled P, Q, R, S, and T. Each has a biological significance (e.g., the P segment corresponds to contraction of the atrium). Each segment may have an associated duration and an associated amplitude. For example, the P segment may last 0.11 seconds and have an amplitude of 0.3 mV. In addition, since not all segments are contiguous, additional segments may be defined with combinations of letters (e.g., where ST represents the interval from the end of S to the beginning of T).

In various embodiments, the durations and amplitudes of the different standard segments may serve as features. Additionally, durations for the additional segments (e.g., for ST) may also serve as features. These features may then be used as the “X” input to a classification algorithm, etc.

Gestures

In various embodiments, it may be desirable to identify someone based on their gestures, such as by their head motions when they are wearing a headset. As such, it may be desirable to extract and/or utilize certain features of detected gestures as input to a machine learning model, algorithm, AI algorithm, and/or as input to any other algorithm. For example, the output of such an algorithm may be an identification of an individual (e.g., from among multiple possible individuals), or the closeness of fit between an input gesture and a reference gesture (e.g., an indication of confidence that a person is who he says he is). In various embodiments, gestures may be recorded and/or detected by means of motion sensors, accelerometers (e.g., accelerometers 4070 a and 4070 b ), or the like.

In various embodiments, features of gestures may include one or more of: the distance moved in one direction (e.g., the distance of a head motion from top to bottom when someone is nodding his head); the number of reversals in direction per unit time (e.g., the speed with which someone shakes their head or nods their head); the maximum upward distance moved when compared to a neutral position (e.g., how far does someone lift their head during a head nod); the maximum downward distance moved when compared to a neutral position; the most commonly assumed position (e.g., how does someone commonly hold their head, whether it be straight, tilted slightly to the right, tilted forward, etc.); the amount of head motion associated with speaking; the amount of head motion associated with drinking; the amount of head motion exhibited when responding to a voice from behind the user (e.g., does the user turn his head to face the other person); and/or any other suitable features.

Mouse Usage

In various embodiments, it may be useful to measure the utilization of a peripheral device. In various embodiments, a peripheral device utilization is measured without reference to any applications (e.g., without reference to user device applications to which the peripheral device utilization is directed, such as to Microsoft® PowerPoint® or to a video game). In various embodiments, it may be determined when a user's effectiveness in utilizing a peripheral device has declined. In various embodiments, it may be determined when a user's utilization of a peripheral device has the potential to be adverse or harmful to a user (e.g., by keeping the user up late at night, by impacting the user's health). In various embodiments, a determination of the effectiveness of the user's utilization of the peripheral device, or the potential for harm to a user may be determined by monitoring or comparing utilization of a peripheral device over time. In various embodiments, utilization of a peripheral device may be monitored for any suitable purpose.

In measuring the utilization of a peripheral device, one or more types of inputs may be measured. The types of inputs may include: presses of a button; releases of a button; clicks of a button; single clicks of a button; double clicks of a button (e.g., two clicks of the button happening in rapid succession); clicks of a right button; clicks of a left button; clicks of a central button; individual interactions with a scroll wheel; degree to which a scroll wheel is turned; direction in which a scroll wheel is turned; movements of the device itself (e.g., movements of the entire mouse); direction of movement of the device; velocity of movement of the device; acceleration of movement of the device; sub-threshold inputs (e.g., pressure placed on a button that was insufficiently strong to register as a click); clicks coupled with motions of the entire device (e.g., drags); or any other types of inputs, or any combination of inputs. In various embodiments, utilization may be measured with passive inputs, such as with inputs detected at one or more sensors but not consciously made by a user. Utilization may measure such inputs as: pressure sensed on a peripheral device (e.g., resting hand pressure); heat sensed at a device (e.g., the heat of a user's hand); a metabolite level of a user; a skin conductivity of a user; a brainwave of a user; an image of a user; an image of part of a user (e.g., of the user's hands; e.g., of the user's face), or any other inputs, or any combination of inputs.

In various embodiments, combinations of inputs may provide a useful measure of utilization. With respect to a presentation remote, a user who is effectively using the presentation remote may direct a presentation remote laser pointer from a first location to a second location using a motion that is substantially a straight line. In contrast, for example, a user who is not effectively using the presentation remote may move the presentation remote laser pointer in the wrong direction (e.g., in a direction that is 10 degrees off from the direction of the second location with respect to the first location), or may overshoot the second location. Because the user is not being economical with his presentation remote motions, changes in direction of the presentation remote motion may be more prevalent with the user. In various embodiments, a metric of utilization may be based on some statistic of inputs measured over some period of time and/or per unit of time. A metric may include the number of inputs measured over some period of time. For example, the number of button clicks measured during a one minute interval. In various embodiments, a metric may include the aggregate of inputs measured over some period of time. For example, the total distance moved by a presentation remote laser pointer in one minute, or the total number of degrees that a scroll wheel has turned in one minute. In various embodiments, a metric may include the proportion of one type of input to another type of input. For example, a metric may measure what proportion of button clicks on a presentation remote were left button clicks versus right button clicks.

In various embodiments, a metric may measure the proportion of time during which a user's hand was in contact with a peripheral. In various embodiments, a metric measures the proportion of sub-threshold clicks to actual clicks. If this metric increases over time, it may suggest, for example, that the user is tiring out and not concentrating on pressing a mouse button hard enough. In various embodiments, a metric measures: (a) the aggregate absolute changes in direction of a mouse's movement divided by (b) the total absolute distance moved by the mouse, all within some unit of time (e.g., one minute). To use a simple example, suppose in one minute a mouse moves 3 inches to a user's right, then 0.5 inches to the user's left, then 2 inches directly away from a user. The mouse has changed directions twice, first by 180 degrees, then by 90 degrees, for an aggregate change in direction of 270 degrees. The mouse has moved a total absolute distance of 5.5 inches (i.e., the absolute value of the distance of each motion is added up). The metric will then take the value of 270 degrees/5.5 inches, or approximately 49 degrees per inch. In various embodiments, this metric may be computed at different time intervals. If the size of the metric is increasing from one time interval to the next, it may be indicative that the user is becoming tired and less efficient with his mouse movements.

In some cases, there may be other explanations for a changing metric. For example, a particular encounter in a video game may require a rapid series of short mouse movements in different directions. However, in various embodiments, by computing a metric over a relatively long time interval (e.g., over 10 minutes), or by computing the metric over many different intervals (e.g., over 20 1-minute intervals), the significance of other explanatory factors can be reduced, smoothed out, or otherwise accounted for. For example, where a metric is computed over many time intervals, values that represent significant outliers can be discarded as probably occurring as a result of other explanatory factors (e.g., not due to the users fatigue).

Adjustable Peripheral Device Parameters

In various embodiments, in response to utilization metrics (e.g., to values of a utilization metric, to changes in the value of a utilization metric over time), one or more parameters of a peripheral may be adjusted. Parameters that may be adjusted include: a sensitivity to clicks, a sensitivity to button presses, a color of a light (e.g., an LED), a brightness of a light, a background color of a display screen, a sensitivity of a touch screen, an image shown on a display screen, a rate at which a light blinks, a volume of audio output, a mapping of detected motion to reported motion (e.g., a mouse may detect 2 inches of mouse displacement but report only 1 inch of displacement, a presentation remote may detect a user hand speed of 6 feet per second, but report a speed of only two feet per second, a headset may detect a 30 degree turn of a user's head, but report only a 10 degree turn of the user's head), or any other parameter.

In various embodiments, a parameter may include whether or not a peripheral device registers an input at all (e.g., whether or not the mouse will register a right click at all). In various embodiments, a parameter may include whether or not a mouse registers any inputs at all. For example, a parameter may, upon assuming a given value, stop the mouse from functioning entirely.

Glass

Various embodiments contemplate the use of glass for such purposes as: coating substrates; display screens; touch screens; sensors; protective covers; glare reducers; fingerprint readers, or fingerprint reducers (such as so-called oleophobic screens and/or coatings); or for any other purpose. In various embodiments the Gorilla® Glass® line of glass products developed by Corning Inc. may be suitable for one or more purposes. The Gorilla® Glass® line includes such products as Gorilla® Glass™ 3, Gorilla® Glass™5, Gorilla® Glass™ 6, and others. Gorilla® Glass™ may provide such advantages as scratch resistance, impact damage resistance, resistance to damage even after drops from high places, resistance to damage after multiple impacts, resistance to damage from sharp objects, retained strength after impacts, high surface quality, optical purity and high light transmission, thinness, and/or lightness. Glass may be used as a flat or 2D panel, or in curved or 3D shapes to embed displays and other functionality in various surfaces and devices. Some exemplary types of glass are described in U.S. Pat. RE47,837, entitled “Crack and scratch resistant glass and enclosures made therefrom” to Barefoot, et al., issued Feb. 4, 2020, the entirety of which is incorporated by reference herein for all purposes. One glass formulation described by the patent includes: “an alkali aluminosilicate glass having the composition: 66.4 mol % SiO.sub.2; 10.3 mol % Al.sub.2O.sub.3; 0.60 mol % B.sub.2O.sub.3; 4.0 mol % Na.sub.2O; 2.10 mol % K.sub.2O; 5.76 mol % MgO; 0.58 mol % CaO; 0.01 mol % ZrO.sub.2; 0.21 mol % SnO.sub.2; and 0.007 mol % Fe.sub.2O.sub.3”. However, it will be appreciated that various embodiments contemplate that other suitable glass formulations could likewise be used. Other glass products that may be used include Dragontrail™ from Asahi™ and Xensation™ from Schott™.

It will be appreciated that various embodiments contemplate the use of other materials besides glass. Such materials may include, for example, plastics, thermoplastics, engineered thermoplastics, thermoset materials, ceramics, polymers, fused silica, sapphire crystal, corundum, quartz, metals, liquid metal, various coatings, or any other suitable material.

Diffusing Fiber Optics

Various embodiments contemplate the use of diffusing fiber optics. These may include optical glass fibers where a light source, such as a laser, LED light, or other source is applied at one end and emitted continuously along the length of the fiber. As a consequence the entire fiber may appear to light up. Optical fibers may be bent and otherwise formed into two or three dimensional configurations. Furthermore, light sources of different or time varying colors may be applied to the end of the optical fiber. As a result, optical fibers present an opportunity to display information such as a current state (e.g., green when someone is available and red when unavailable), or provide diverse and/or visually entertaining lighting configurations.

Diffusing fiber optics are described in U.S. Pat. No. 8,805,141, entitled “Optical fiber illumination systems and methods” to Fewkes, et al., issued Aug. 12, 2014, the entirety of which is incorporated by reference herein for all purposes.

Terms

As used herein, a “meeting” may refer to a gathering of two or more people to achieve a function or purpose.

A “company” may be a for profit or not for profit company. It could also be a small group of people who have a shared purpose, such as a club. The company could have full or part time employees located at one or more physical locations and/or virtual workers.

A “meeting owner” may refer to a person (or persons) responsible for managing the meeting. It could be the speaker, a facilitator, or even a person not present at the meeting (physically or virtually) who is responsible for elements of the meeting. There could also be multiple meeting owners for a given meeting.

A “meeting participant” may refer to an individual or team who attends one or more meetings. In some embodiments, a meeting participant could be a software agent that acts on behalf of the person. In various embodiments, the terms “meeting participant” and “meeting attendee” may be used interchangeably.

An “Admin/Coordinator” may refer to an individual or individuals who play a role in setting up or coordinating a meeting, but may not participate in the meeting itself.

A “baton” may refer to a task, obligation, or other item that may be fulfilled in portions or parts (e.g., in sequential parts). The task may be assigned to a person or a team. Upon fulfilling their portion of the task, the person or team may hand the task over to another person or team, thereby “passing the baton”. Such a task may be handed from one person to another—across meetings, across time, and/or across an organization. The task may ultimately reach completion following contributions from multiple people or teams. In various embodiments, a baton is first created in a meeting (e.g., as a task that results from a decision or direction arrived at in a meeting).

An “intelligent chair” may refer to a chair capable of performing logical operations (e.g., via a built-in processor or electronics), capable of sensing inputs (e.g., gestures of its occupants; e.g., voice commands of its occupants; e.g., pulse or other biometrics of its occupants), capable of sensing its own location, capable of outputting information (e.g., providing messages to its occupant), capable of adjusting its own configuration (e.g., height; e.g., rigidness; e.g., temperature of the backrest), capable of communicating (e.g., with a central controller), and/or capable of any other action or functionality.

As used herein, an “SME” may refer to a subject matter expert such as a person with expertise or specialized knowledge in a particular area (e.g. finance, marketing, operations, legal, technology) or a particular subdomain, such as the European market, server technology, intellectual property, or in any other area.

As used herein, a “Meeting Participant Device” or the like may refer to a device that allows meeting participants to send and receive messages before, during, and after meetings. A Meeting Participant Device may also allow meeting participants to take surveys about meetings, provide feedback for meetings and/or to engage in any other activity related to meetings. A meeting participant device may include: Smartphones (such as an Apple™ iPhone™ 11 Pro or Android™ device such as Google®™ Pixel 4™ and OnePIus™ 7 Pro); IP enabled desk phone; Laptops (MacBook Pro™ MacBook Air™, HP™ Spectre x360™, Google®™ Pixelbook Go™, Dell™ XPS 13™); Desktop computers (Apple™ iMac 5K™, Microsoft®™ Surface Studio 2™, Dell™ Inspiron 5680™); Tablets (Apple™ iPad™ Pro 12.9, Samsung™ Galaxy™ Tab S6, iPad™ Air, Microsoft®™ Surface Pro™); Watches (Samsung™ Galaxy™ Watch, Apple™ Watch 5, Fossil™ Sport™, TicWatch™ E2, Fitbit™ Versa 2™); Eyeglasses (Iristick.Z1 Premium™ Vuzix Blade™, Everysight Raptor™, Solos™, AmaZOn®™ Echo™ Frames); Wearables (watch, headphones, microphone); Digital assistant devices (such as Amazon® ™ Alexa™ enabled devices, Google®™ Assistant™, Apple™ Siri™); and/or any other suitable device.

In various embodiments, a Meeting Participant Device may include a peripheral device, such as a device stored in table 1000 . In various embodiments, a Meeting Participant Device may include a user device, such as a device stored in table 900 .

As used herein, a “Meeting Owner Device” or the like may refer to a device that helps or facilitates a meeting owner in managing meetings. It could include the same or similar technology as described with respect to the Meeting Participant Device above.

As used herein, the terms “presentation controller”, “presentation remote”, “presentation remote controller” and the like shall all be equivalently used to refer to a device that is usable to control presentations, such as slide shows, decks, etc. The presentation remote may be used to perform any other embodiments described herein, such as communication from presentation remote to presentation remote, authentication of a user, assigning tasks, managing supplemental devices, storing information, recording meeting events, connecting to other rooms or people, controlling objects or devices in a room (e.g., lights, air conditioning, heater, projector, window shades, etc.), controlling room access, and/or for anything else.

Central Controllers

In various embodiments, central controller 110 may be one or more servers located at the headquarters of a company, a set of distributed servers at multiple locations throughout the company, or processing/storage capability located in a cloud environment—either on premise or with a third party vendor such as Amazon® ™ Web Services™, Google®™ Cloud Platform™, or Microsoft®™ Azure™.

The central controller 110 may be a central point of processing, taking input from one or more of the devices herein, such as a room controller or participant device. The central controller may have processing and storage capability along with the appropriate management software as described herein. Output from the central controller could go to room controllers, room video screens, participant devices, executive dashboards, etc.

In various embodiments, the central controller may include software, programs, modules, or the like, including: an operating system; communications software, such as software to manage phone calls, video calls, and texting with meeting owners and meeting participants; an artificial intelligence (AI) module; and/or any other software.

In various embodiments, central controller 110 may communicate with one or more devices, peripherals, controllers (e.g., location controller 8305 ( FIG. 83 ), equipment controllers); items of equipment (e.g., AV equipment); items of furniture (e.g., intelligent chairs); resource devices (e.g., weather service providers, mapping service providers); third-party devices; data sources; and/or with any other entity.

In various embodiments, the central controller 110 may communicate with: room controllers; display screens; meeting owner devices/participant devices, which can include processing capability, screens, communication capability, etc.; headsets; keyboards; mice (e.g. Key Connection Battery Free Wireless Optical Mouse & a USB 2′ Wired Pad, Logitech®; Wireless Marathon™ Mouse M705 with 3-Year Battery Life); presentation remotes; chairs; executive dashboards; audio systems; microphones; lighting systems; security systems (e.g. door locks, surveillance cameras, motion sensors); environmental controls (e.g. HVAC, blinds, window opacity); Bluetooth® location beacons or other indoor location systems, or any other entity.

In various embodiments, the central controller 110 may communicate with data sources containing data related to: human resources; presentations; weather; equipment status; calendars; traffic congestion; road conditions; road closures; or to any other area.

In various embodiments, the central controller may communicate with another entity directly, via one or more intermediaries, via a network, and/or or in any other suitable fashion. For example, the central controller may communicate with an item of AV equipment in a given room using a room controller for the room as an intermediary.

Embodiments

Referring to FIG. 50 , a diagram of an example ‘employees’ table 5000 according to some embodiments is shown. Employees table 5000 may store information about one or more employees at a company, organization, or other entity. In various embodiments, table 5000 may store information about employees, contractors, consultants, part-time workers, customers, vendors, and/or about any people of interest. In various embodiments, employees table 5000 may store similar, analogous, supplementary, and/or complementary information to that of users table 700 . In various embodiments, employees table 5000 and users table 700 may be used interchangeably and/or one table may be used in place of the other.

Employee identifier field 5002 may store an identifier (e.g., a unique identifier) for an employee. Name field 5004 may store an employee name. Start date field 5006 may store a start date, such as an employee's first day of work. Employee level field 5008 may store an employee's level within the company, which may correspond to an employee's rank, title, seniority, responsibility level, or any other suitable measure.

Supervisor field 5010 may indicate the ID number of an employee's supervisor, manager, boss, project manager, advisor, mentor, or other overseeing authority. As will be appreciated, an employee may have more than one supervisor.

Office/cube location field 5012 may indicate the location of an employee's place of work. This may be, for example, the place that an employee spends the majority or the plurality of her time. This may be the place where an employee goes when not interacting with others. This may be the place where an employee has a desk, computer, file cabinet, or other furniture or electronics or the like. In various embodiments, an employee may work remotely, and the location 5012 may correspond to an employee's home address, virtual address, online handle, etc. In various embodiments, multiple locations may be listed for an employee, such as if an employee has multiple offices. In various embodiments, a location may indicate a room number, a cube number, a floor in a building, an address, and or any other pertinent item of information.

In various embodiments, knowledge of an employee's location may assist the central controller 110 with planning meetings that are reachable by an employee within a reasonable amount of time. It may also assist the central controller 110 with summoning employees to nearby meetings if their opinion or expertise is needed. Of course, knowledge of an employee's location may be useful in other situations as well.

Subject matter expertise field 5014 may store information about an employee's expertise. For example, an employee may have expertise with a particular area of technology, with a particular legal matter, with legal regulations, with a particular product, with a particular methodology or process, with customer preferences, with a particular market (e.g., with the market conditions of a particular country), with financial methods, with financials for a given project, or in any other area. In various embodiments, multiple areas of expertise may be listed for a given employee. In various embodiments, subject matter expertise field 5014 may assist the central controller 110 with ensuring that a meeting has an attendee with a particular area of expertise. For example, a meeting about launching a product in a particular country may benefit from the presence of someone with expertise about market conditions in that country. As will be appreciated, subject matter expertise field 5014 could be used for other situations as well.

Personality field 5016 may store information about an employee's personality. In various embodiments, information is stored about an employee's personality as exhibited within meetings. In various embodiments, information is stored about an employee's personality as exhibited in other venues or situations. In various embodiments, it may be desirable to form meetings with employees of certain personalities and/or to balance or optimize personalities within a meeting. For example, if one employee tends to be very gregarious, it may be desirable to balance the employee's personality with another employee who is focused and who could be there to keep a meeting on track. In various embodiments, it may be desirable to avoid forming meetings with two or more clashing personality types within them. For example, it may be desirable to avoid forming a meeting with two (or with too many) employees that have a confrontational personality. As will be appreciated, personality field 5016 may be used for other situations as well.

Security level field 5018 may store information about an employee's security level. This may represent, for example, an employee's ability to access sensitive information. An employee's security level may be represented numerically, qualitatively (e.g., “high” or “low”), with titles, with clearance levels, or in any other suitable fashion. In various embodiments, security level field 5018 may assist the central controller 110 in constructing meetings with attendees that have permission to view potentially sensitive information that may arise during such meetings.

Security credentials field 5020 may store information about credentials that an employee may present in order to authenticate themselves (e.g., to verify their identities). For example, field 5020 may store an employee's password. An employee may be required to present this password in order to prove their identity and/or to access secure information. Field 5020 may store other types of information such as biometric information, voiceprint data, fingerprint data, retinal scan data, or any other biometric information, or any other information that may be used to verify an employee's identity and/or access levels.

Temperature preferences field 5021 may store an employee's temperature preferences, such as an employee's preferred room temperature. This preference may be useful in calculating heating energy (or cooling energy), and/or any associated emissions that may be required to maintain a room at an employee's preferred room temperature. Employee temperature preferences may influence the temperature at which an employee's office is kept, the temperature at which a meeting room hosting the employee is kept, or any other applicable temperature.

Preferences

In various embodiments, meeting owners and meeting participants could register their preferences with the central controller relating to the management and execution of meetings. Example preferences of meeting participants may include:

I only want to attend meetings with fewer than ten people. I do not want to attend any alignment meetings. I prefer morning to afternoon meetings. I do not want to attend a meeting if a particular person will be attending (or not attending). I don't like to attend meetings outside of my building or floor. I don't attend meetings that require travel which generates carbon output. Gestures that invoke action can be set as a preference. Tap my watch three times to put me on mute. Nodding during a meeting can indicate that I agree with a statement. Food preference for meetings. I only eat vegetarian meals. My personal mental and physical well-being at a given time.

Example preferences of meeting owners may include:

I don't want to run any meetings in room 7805. I prefer a “U” shaped layout of desks in the room. I prefer to have a five minute break each hour. I prefer the lights to be dimmed 50% while I am presenting. I never want food to be ordered from a particular vendor. I want a maximum of 25 attendees at my Monday meetings. I need to be able to specify camera focus by meeting type. For example, in a meeting at which a decision is being made I want the camera to be on the key decision makers for at least 80% of the time. My personal mental and physical well-being at a given time.

Example preferences or conditions of the central controller may include:

There are certain days on which meetings cannot be scheduled. For a given room, certain levels of management have preferential access to those rooms.

Preferences field 5022 may store an employee's preferences, such as an employee's preferences with respect to meetings. Such preferences may detail an employee's preferred meeting location or locations, preferred amenities at a meeting location (e.g., whiteboards), preferred characteristics of a meeting location (e.g., location has north-facing windows, the location has circular conference tables), room layouts (e.g. U-shaped desk arrangements), etc. Preferences field 5022 may include an employee's preferred meeting times, preferred meeting dates, preferred meeting types (e.g., innovation meetings), preferred meeting sizes (e.g., fewer than ten people), or any other preferences.

Preferred standard device configurations field 5024 may store information about how an employee would like a device configured. The device may be a device that is used in a meeting. The device may include, for example, a smartphone, a laptop, a tablet, a projector, a presentation remote, a coffee maker, or any other device. Exemplary preferences may include a preferred method of showing meeting attendees (e.g., show only the speaker on a screen, show all attendees on screen at once), a preferred method of broadcasting the words spoken in a meeting (e.g., via audio, via a transcript), a preferred method of alerting the employee when his input is required (e.g., via flashing screen, via a tone), a preferred method of alerting the employee when the meeting is starting, a preferred method of alerting the employee when a particular topic arises, a preferred method of showing the results of an in-meeting survey (e.g., via a bar graph, via numerical indicators for each available choice), or any other preferences.

Email field 5026 may store an employee's email address. In various embodiments, a company email address may be stored for an employee. In various embodiments, a personal email address may be stored for an employee. In various embodiments, any other email address or addresses may be stored for an employee.

Phone field 5028 may store an employee's phone number. In various embodiments, a company phone number may be stored for an employee. In various embodiments, a personal phone number may be stored for an employee. In various embodiments, any other phone number or numbers may be stored for an employee.

In various embodiments, any other contact information for an employee may be stored. Such contact information may include a Slack™ handle, a Twitter® handle, a LinkedIn® handle, a Facebook® username, a handle on a social media site, a handle within a messaging app, a postal address, or any other contact information.

In various embodiments, storing an employee's contact information may allow the central controller 110 to send a meeting invite to an employee, to send reminders to an employee of an impending meeting, to check in on an employee who has not appeared for a meeting, to remind employees to submit meeting registration information (e.g., a purpose or agenda), to send rewards to employees (e.g., to send an electronic gift card to an employee), or to communicate with an employee for any other purpose.

Referring to FIG. 51 , a diagram of an example ‘meetings’ table 5100 according to some embodiments is shown. In various embodiments, a meeting may entail a group or gathering of people, who may get together for some period of time. People may gather in person, or via some conferencing or communications technology, such as telephone, video conferencing, telepresence, zoom calls, virtual worlds, or the like. Meetings (e.g., hybrid meetings) may include some people who gather in person, and some people who participate from remote locations (e.g., some people who are not present in the same room), and may therefore participate via a communications technology. Where a person is not physically proximate to other meeting attendees, that person may be referred to as a ‘virtual’ attendee, or the like.

Further details on how meetings may occur via conferencing can be found in U.S. Pat. No. 6,330,022, entitled “DIGITAL PROCESSING APPARATUS AND METHOD TO SUPPORT VIDEO CONFERENCING IN VARIABLE CONTEXTS” to Doree Seligmann, issued Dec. 11, 2011, at columns 3-6, which is hereby incorporated by reference.

A meeting may serve as an opportunity for people to share information, work through problems, provide status updates, provide feedback to one another, share expertise, collaborate on building or developing something, or may serve any other purpose.

In various embodiments, a meeting may refer to a single-event or session, such as a gathering that occurs from 2:00 PM to 3:00 PM on Apr. 5, 2025. In various embodiments, a meeting may refer to a series of events or sessions, such as to a series of ten sessions that occur weekly on Monday at 10:00 AM. The series of sessions may be related (e.g., they may all pertain to the same project, may involve the same people, may all have the same or related topics, etc.). As such, in various embodiments, the series of sessions may be referred to collectively as a meeting. Meetings may also include educational sessions like a Monday 2 PM weekly Physics class offered by a university for a semester.

Meeting identifier field 5102 may store an identifier (e.g., a unique identifier) for a meeting. Meeting name field 5104 may store a name for a meeting. A meeting name may be descriptive of the subject of a meeting, the attendees in the meeting (e.g., a meeting called ‘IT Roundtable’ may comprise members of the IT department), or any other aspect of the meeting, or may have nothing to do with the meeting, in various embodiments.

Meeting owner field 5106 may store an indication of a meeting owner (e.g., an employee ID, an employee name). A meeting owner may be an individual or a group of individuals who run a meeting, create a meeting, organize a meeting, manage a meeting, schedule a meeting, send out invites for a meeting, and/or who play any other role in the meeting, or who have any other relationship to the meeting.

Meeting type field 5108 may store an indication of a meeting type. Exemplary meeting types include learning; innovation; commitment; and alignment meetings. A meeting type may serve as a means of classifying or categorizing meetings. In various embodiments, central controller 110 may analyze characteristics of a meeting of a certain type and determine whether such characteristics are normal for meetings of that type. For example, the central controller may determine that a scheduled innovation meeting has more people invited then would be recommended for innovation meetings in general.

In various embodiments, central controller 110 may analyze the relative frequency of different types of meetings throughout a company. The central controller may recommend more or fewer of certain types of meetings if the number of a given type of meeting is out of proportion to what may be considered healthy for a company. In various embodiments, meeting types may be used for various other purposes.

Level field 5110 may store a level of a meeting. The level may represent the level of the intended attendees for the meeting. For example, the meeting may be an executive-level meeting if it is intended to be a high-level briefing just for executives. In various embodiments, prospective attendees with ranks or titles that do not match the level of the meeting (e.g., a prospective attendee's rank is too low) may be excluded from attending the meeting. In various embodiments, meetings of a first-level may take priority over meetings of a second level (e.g., of a lower level). Thus, for example, meetings of the first level may be granted access to a conference room before meetings of a second level when meeting times overlap. In various embodiments, meeting levels may be used for other purposes as well.

Location field 5112 may store a location of a meeting. The location may include a building designation, a campus designation, an office location, or any other location information. In various embodiments, if a meeting is to be held virtually, then no information may be stored in this field.

Room identifier field 5114 may store an identifier of a room in which a meeting is scheduled to occur. The room may be a physical room, such as a conference room or auditorium. The room may be a virtual room, such as a video chat room, chat room, message board, Zoom® call meeting, WebEx® call meeting, or the like. In some embodiments, a meeting owner or central controller 110 may switch the room location of a meeting, with the record stored in the room identifier field updated to reflect the new room.

Start date field 5116 may store the start date of a meeting. In various embodiments, the start date may simply represent the date of a solitary meeting. In various embodiments, the start date may represent the first in a series of sessions (e.g., where a meeting is recurring).

Time field 5118 may store a time of a meeting, such as a start time. If the meeting comprises multiple sessions, the start time may represent the start time of each session. In embodiments with offices in different time zones, time field 5118 may be expressed in GMT.

Duration field 5119 may store a duration of a meeting, such as a duration specified in minutes, or in any other suitable units or fashion. The duration may represent the duration of a single session (e.g., of a recurring meeting).

Frequency field 5120 may store a frequency of a meeting. The field may indicate, for example, that a meeting occurs daily, weekly, monthly, bi-weekly, annually, every other Thursday, or according to any other pattern.

End date field 5122 may store the end date of a meeting. For meetings with multiple sessions, this may represent the date of the last session. In various embodiments, this may be the same as the start date.

Phone number field 5124 may store a phone number that is used to gain access to a meeting (e.g., to the audio of a meeting; e.g., to the video of a meeting; e.g., to slides of a meeting; e.g., to any other aspect of a meeting). In various embodiments, phone number field 5124 or a similar type field may store a phone number, URL link, weblink, conference identifier, login ID, or any other information that may be pertinent to access a meeting.

Tags field 5126 may store one or more tags associated with a meeting. The tags may be indicative of meeting purpose, meeting content, or any other aspect of the meeting. Tags may allow for prospective attendees to find meetings of interest. Tags may allow for comparison of meetings (e.g., of meetings with similar tags), such as to ascertain relative performance of similar meetings. Tags may serve other purposes in various embodiments.

‘Project number or cost center association’ field 5128 may store an indication of a project and/or cost center with which a meeting is associated. Field 5128 may thereby allow tracking of the overall number of meetings that occur related to a particular project. Field 5128 may allow tallying of costs associated with meetings related to a particular cost center. Field 5128 may allow for various other tracking and/or statistics for related meetings. As will be appreciated, meetings may be associated with other aspects of an organization, such as with a department, team, initiative, goal, or the like.

Ratings field 5130 may store an indication of a meeting's rating. A rating may be expressed in any suitable scale, such as a numerical rating, a qualitative rating, a quantitative rating, a descriptive rating, a rating on a color scale, etc. A rating may represent one or more aspects of a meeting, such as the importance of the meeting, the effectiveness of the meeting, the clarity of the meeting, the efficiency of the meeting, the engagement of a meeting, the purpose of the meeting, the amount of fun to be had in the meeting, or any other aspect of the meeting. A rating may represent an aggregate of ratings or feedback provided by multiple attendees. A rating may represent a rating of a single session, a rating of a group of sessions (e.g., an average rating of a group of sessions), a rating of a most recent session, or any other part of a meeting.

In various embodiments, ratings may be used for various purposes. A rating may allow prospective attendees to decide which meetings to attend. A rating may allow an organization to work to improve meetings (e.g., the way meetings are run). A rating may aid an organization in deciding whether to keep a meeting, cancel a meeting, change the frequency of a meeting, change the attendees of a meeting, or change any other aspect of a meeting. A rating may allow an organization to identify meeting facilitators who run good meetings. A rating may be used for any other purpose, in various embodiments.

Priority field 5132 may store a priority of a meeting. A priority may be represented using any suitable scale, as will be appreciated. The priority of a meeting may serve various purposes, and various embodiments. A company employee who is invited to two conflicting meetings may attend the meeting with higher priority. If two meetings wish to use the same room at the same time, the meeting with higher priority may be granted access to the room. A meeting priority may help determine whether a meeting should be cancelled in certain situations (e.g., if there is inclement weather). Employees may be given less leeway in declining invites to meetings with high priority versus those meetings with low priority. As will be appreciated, the priority of a meeting may be used for various other purposes.

Related meetings field 5134 may store an indication of one or more related meetings. Related meetings may include meetings that relate to the same projects, meetings that are on the same topic, meetings that generate assets used by the present meeting (e.g., meetings that generate ideas to be evaluated in the present meeting; e.g., meetings that generate knowledge used in the present meeting), meetings that have one or more attendees in common, meetings that use assets generated in the present meeting, meetings run by the same meeting owner, meetings that occur in the same location, meetings that occur at the same time, meetings that occur at an approximate time, or meetings with any other relationship to the present meeting. Any given meeting may have no related meetings, one related meeting, or more than one related meeting, in various embodiments.

In various embodiments, table 5100 , or some other table, may store an indication of meeting connection types. This may include an indication of types of devices that may be used to participate in a meeting (e.g., mobile, audio only, video, wearable). This may include an indication of types of connections that may be used to participate in the meeting (e.g., Wi-Fi®, WAN, 3rd party provider).

Referring to FIG. 52 , a diagram of an example ‘Meeting attendees’ table 5200 according to some embodiments is shown. Meeting attendees table 5200 may store information about who attended a meeting (and/or who is expected to attend).

Meeting identifier field 5202 may store an indication of the meeting in question. Date field 5203 may store an indication of the date of the meeting or of a particular session of the meeting. In some cases, an attendee might attend one session of a meeting (e.g., of a recurring meeting) and not attend another session of the meeting.

Attendee identifier field 5204 may store an indication of one particular attendee of a corresponding meeting. As will be appreciated, table 5200 may include multiple records related to the same meeting. Each record may correspond to a different attendee of the meeting.

Role field 5206 may store a role of the attendee at the meeting. Exemplary roles may include meeting owner, facilitator, leader, note keeper, subject matter expert, or any other role or function. In various embodiments, a role may be ‘interested participant’ or the like, which may refer to a non-meeting participant, such as a CEO, CIO, VP/Director of Meetings, or Project Sponsor. In various embodiments, a role may be ‘central controller administrator’, ‘central controller report administrator’, or the like, which may refer to a participant that performs or oversees one or more functions of the central controller as it pertains to the meeting. In various embodiments, a role may be ‘meeting room and equipment administrator’ or the like, which may refer to a participant that oversees operations of the meeting room, such as ensuring that projectors and AV equipment are running properly.

An attendee with no particular role may simply be listed as attendee, or may be designated in any other suitable fashion.

Manner field 5208 may store an indication of the manner in which the attendee participated in the meeting. For example, an attendee may participate in person, via video conference, via web conference, via phone, or via any other manner of participation.

Referring to FIG. 53 , a diagram of an example ‘Meeting engagement’ table 5300 according to some embodiments is shown. Meeting engagement table 5300 may store information about attendees' engagement in a meeting. Storing engagement levels may be useful, in some embodiments, for seeking to alter and improve meetings where engagement levels are not optimal. Engagement may refer to one or more behaviors of an attendee as described herein. Such behaviors may include paying attention, focusing, making contributions to a discussion, performing a role (e.g., keeping notes), staying on topic, building upon the ideas of others, interacting with others in the meeting, or to any other behavior of interest. In some embodiments, headset 4000 may provide data that informs the determining of an engagement level (e.g. detection of head drooping down, eyes closing, snoring sounds).

Meeting identifier field 5302 may store an indication of the meeting for which engagement is tracked. Date field 5304 may store the date of the meeting or of a session of the meeting. This may also be the date for which engagement was recorded.

Time field 5306 may store an indication of the time when the engagement was recorded, measured, noted, observed, reported, and/or any other pertinent time. For example, engagement may be observed over a five minute interval, and time field 5306 may store the time when the interval finishes (or the time when the interval starts, in some embodiments). In various embodiments, time field 5306 may store the entire interval over which the engagement was recorded. In various embodiments, an attendee's engagement may be measured multiple times during the same meeting or session, such as with the use of surveys delivered at various times throughout a meeting. In such cases, it may be useful to look at changes in engagement level over time. For example, if an attendee's engagement has decreased during a meeting, then the attendee may be sent an alert to pay attention, may be provided with a cup of coffee, or may otherwise be encouraged to increase his engagement level. In one embodiment, if engagement levels are low for a particular meeting, central controller 110 may send an instruction to the company catering facilities to send a pot of coffee to the room in which the meeting is occurring.

Attendee identifier field 5308 may store an indication of the attendee for whom engagement is measured. Engagement level field 5310 may store an indication of the attendee's level of engagement. This may be stored in any suitable fashion, such as with a numerical level, a qualitative level, quantitative level, etc. In various embodiments, an engagement level may refer to a quantity of engagement, such as a number of comments made during a discussion. In various embodiments, an engagement level may refer to a quality of behavior, such as the relevance or value of comments made during a discussion. In various embodiments, an engagement level may refer to some combination of quality and quantity of a behavior. An engagement level may refer to any suitable measure or metric of an attendee's behavior in a meeting, in various embodiments.

In various embodiments, an engagement level may be connected to a biometric reading. The biometric may correlate to a person's visible behaviors or emotional state within a meeting. In various embodiments, for example, an engagement level may be a heart rate. A low heart rate may be presumed to correlate to low engagement levels. In various embodiments, field 5310 may store a biometric reading, such as a heart rate, breathing rate, measure of skin conductivity, or any other suitable biometric reading.

Engagement indicator(s) field 5312 may store an indication of one or more indicators used to determine an engagement level. Indicators may include biometrics as described above. Exemplary indicators include signals derived from voice, such as rapid speech, tremors, cadence, volume, etc. Exemplary indicators may include posture. For example, when a person is sitting in their chair or leaning forward, they may be presumed to be engaged with the meeting. Exemplary indicators may be obtained through eye tracking. Such indicators may include eye movement, direction of gaze, eye position, pupil dilation, focus, drooping of eyelids, etc. For example, if someone's eyes are just staring out into space, it may be presumed that they are not engaged with the meeting. As will be appreciated, many other engagement indicators are possible.

Burnout risk field 5314 may store an indication of an attendee's burnout risk. Burnout may refer to a significant or lasting decline in morale, productivity, or other metric on the part of an attendee. It may be desirable to anticipate a burnout before it happens, as it may then be possible to prevent the burnout (e.g., by giving the attendee additional vacation days, by giving the attendee less work, etc.). A burnout risk may be stored in any suitable fashion, such as on a “high”, “medium”, “low” scale, on a numerical scale, or in any other fashion.

A burnout risk may be inferred via one or more indicators. Burnout indicators field 5316 may store one or more indicators used to assess or detect an attendee's burnout risk. Exemplary indicators may include use of a loud voice, which may portend a high burnout risk. Exemplary indicators may include steady engagement, which may portend a low burnout risk. Burnout risk may also be inferred based on how often an attendee declines invites to meetings (e.g., an attendee might decline 67% of meeting invites). A high rate of declining invites might indicate that the attendee is overworked or is simply no longer interested in making productive contributions, and may therefore be burning out. An exemplary indicator might be a degree to which an attendee's calendar is full. For example, an attendee with a calendar that is 95% full may represent a medium risk of burnout. In various embodiments, multiple indicators may be used in combination to form a more holistic picture of an employee's burnout risk. For example, an employee's rate of declining meeting invites may be used in conjunction with the employee's calendar utilization to determine an employee's burnout risk.

Referring to FIGS. 54A and 54B , a diagram of an example ‘Meeting feedback’ table 5400 according to some embodiments is shown. Note that meeting feedback table 5400 extends across FIGS. 54A and 54B . Thus, for example, data in the first record under field 5420 (in FIG. 54B ) is part of the same record as is data in the first record under field 5402 (in FIG. 54A ).

Meeting feedback table 5400 may store feedback provided about a meeting. The feedback may come from meeting attendees, meeting observers, from recipients of a meeting's assets, from contributors to a meeting, from a meeting owner, from management, from facilities management, or from any other parties to a meeting or from anyone else.

Meeting feedback may also be generated via automatic and/or computational means. For example, the central controller 110 may process an audio recording received from microphone 4114 of presentation remote 4100 of the meeting and determine such things as the number of different people who spoke, the degree to which people were talking over one another, or any other suitable metric. In some embodiments, meeting feedback may be provided by a user via headset 4000 , such as by a user providing a verbal message of support for another meeting attendee.

In various embodiments, meeting feedback may be stored in aggregate form, such as the average of the feedback provided by multiple individuals, or such as the aggregate of feedback provided across different sessions of a meeting. In various embodiments, feedback may be stored at a granular level, such as at the level of individuals. Meeting feedback may be useful for making changes and or improvements to meetings, such as by allowing prospective attendees to decide which meetings to attend, or for any other purpose. Meeting feedback can be expressed in any suitable scale, such as a numerical rating, a qualitative rating, a quantitative rating, a descriptive rating, a rating on a color scale, etc.

In various embodiments, feedback may be provided along a number of dimensions, subjects, categories, or the like. Search dimensions may cover different aspects of the meeting. In some embodiments, feedback could be provided regarding room layout, air conditioning noise levels, food and beverage quality, lighting levels, and the like.

Meeting identifier field 5402 may store an indication of the meeting for which feedback is tracked. Effectiveness of facilitation field 5404 may store an indication of effectiveness with which the meeting was facilitated. Other feedback may be stored in such fields as: ‘Meeting Energy Level’ field 5406 ; Did the Meeting Stay on Track?′ field 5408 ; Did the Meeting Start/End on Time?′ field 5410 ; ‘Room Comfort’ field 5412 ; ‘Presentation Quality’ field 5414 ; ‘Food Quality’ field 5418 ; ‘Room lighting’ field 5420 ; ‘Clarity of purpose’ field 5422 ; Projector quality’ field 5424 ; ‘Ambient noise levels’ field 5426 ; ‘Strength of Wi-Fi® Signal’ field 5428 ; ‘Room cleanliness’ field 5430 ; and ‘view from the room’ field 5432 where the field labels themselves may be explanatory of the type of feedback stored in such fields.

‘Overall rating’ field 5416 may store an overall rating for a meeting. The overall rating may be provided directly by a user or by multiple users (e.g. via detachable speaker 4174 of presentation remote 4100 ). The overall rating may be computationally derived from feedback provided along other dimensions described herein (e.g., the overall rating may be an average of feedback metrics for effectiveness of facilitation, meeting energy level, etc.). The overall rating may be determined in any other suitable fashion.

Other feedback may be related to such questions as: Were meeting participants encouraged to provide their opinions?; Was candor encouraged?; Was the speaker's voice loud enough?; Was the speaker understandable?; Did the meeting owner know how to use the technology in the room?

In various embodiments, the central controller 110 may inform the meeting owner during or after the meeting that clarity is low (or may provide some other feedback to the meeting owner or to any other participant). Feedback could be private to the meeting owner (e.g. delivered via display 4146 of presentation remote 4100 ), or it could be made available to everyone in the room, or just to management.

In various embodiments, feedback about the meeting owner goes to the meeting owners boss (or to any other person with authority over the meeting owner, or to any other person).

In various embodiments, feedback about the meeting may be used as a tag for the meeting. The tag may be used in searching, for example.

In various embodiments, other feedback may relate to meeting content (e.g. presentation, presentation slides, agenda, meeting assets, ideas, discussions, graphs, flipchart notes), and may address such questions as: Was the content organized efficiently?; Was the content clear and concise?; Was the content appropriate for the audience? For example, was the presentation too technical for an executive level meeting?

In various embodiments, other feedback may relate to presentation material and slide content, and may address such questions as: How long did the presenter spend on each slide?; Were the slides presented too quickly?; Were some slides skipped?; What type of slides result in short or long durations?; How long did the presenter spend on slides related to the meeting purpose or agenda?; Did the presenter finish the presentation within the allotted time?; Were there too many words on each slide?; Did the presentation include acronyms?; Was there jargon in the presentation?; Were graphs, figures, and technical materials interpretable and readable?; Which slides were provided in advance to meeting participants for review? The answers to these questions could be used to tag low clarity scores to particular material, presentations, or individual slides.

In various embodiments, other feedback may relate to technology, and may address such questions as: Was all room equipment working throughout the meeting?; Did external factors (home Wi-Fi®, ISP provider, energy provider disruption) contribute to poor use of technology?; Was equipment missing from the room (for example chairs, projectors, markers, cables, flip charts, etc.)?

In various embodiments, other feedback may relate to room setup, and may address such questions as: Was the room difficult to locate?; Were participants able to locate bathrooms?; Was the room A/C or heating set appropriately for the meeting?; Was the room clean?; Were all chairs and tables available per the system configuration?; Was the screen visible to all participants?; Were the lights working?; Was the room unlocked?; Was the room occupied?; Was food/beverage delivered on-time and of high quality?

Referring to FIG. 55 , a diagram of an example ‘Meeting participation/Attendance/Ratings’ table 5500 according to some embodiments is shown. Meeting participation/Attendance/Ratings table 5500 may store information about attendees' participation, attendance, ratings received from others, and/or other information pertaining to a person's attendance at a meeting. Information stored in table 5500 may be useful for trying to improve individual attendees' performances in meetings. For example, if an attendee is habitually late for meetings, then the attendee may be provided with extra reminders prior to meetings. Information stored in table 5500 may also be useful for planning or configuring meetings. For example, if it is known that many attendees had to travel far to get to a meeting, then similar meetings in the future may be held in a more convenient location. Information stored in table 5500 may be used for any other suitable purpose.

Meeting identifier field 5502 may store an indication of the meeting in question. Date field 5504 may store an indication of the date of the meeting or of a particular session of the meeting. In some cases, an attendee might attend one session of a meeting (e.g., of a recurring meeting) and not attend another session of the meeting.

Employee identifier field 5506 may store an indication of one particular employee or attendee of a corresponding meeting. Role field 5508 may store a role of the attendee at the meeting as described above with respect to field 5206 . ‘Confirmed/Declined meeting’ field 5510 may store an indication of whether the employee confirmed his or her participation in the meeting or declined to participate in the meeting. In various embodiments, field 5510 may indicate that the employee actually attended the meeting, or did not actually attend the meeting.

‘Time arrived’ field 5512 may indicate when an employee arrived at a meeting. This may represent a physical arrival time, or a time when the employee signed into a meeting being held via conferencing technology, and/or this may represent any other suitable time. In some embodiments, time arrived data is received from presentation remote 4100 such as by a presenter who taps on the name of a meeting attendee on display 4146 when that attendee enters the meeting room.

‘Time departed’ field 5514 may indicate when an employee departed from a meeting (e.g., physically departed; e.g., signed out of a virtual meeting; etc.).

‘Travel time to meeting location’ field 5516 may indicate an amount of time that was required for the employee to travel to a meeting. The travel time may be the time it actually took the employee to reach the meeting. The travel time may be a time that would generally be expected (e.g., a travel time of the average person at an average walking pace, a travel time of the average driver at an average driving speed). In various embodiments, the travel time may assume the employee started at his office or his usual location. In various embodiments, the travel time may account for the employee's actual location prior to the meeting, even if this was not his usual location. For example, the travel time may account for the fact that the employee was just attending another meeting and was coming from the location of the other meeting.

‘Travel time from meeting location’ field 5518 may indicate an amount of time that was required for the employee to travel from a meeting to his next destination. Similar considerations may come into play with field 5518 as do with field 5516 . Namely, for example, travel times may represent actual or average travel times, destinations may represent actual or typical destinations, etc.

‘Employee rating by others’ field 5520 may represent a rating that was given to an employee by others (e.g., by other attendees of the meeting). The rating may reflect an employee's participation level, an employee's contribution to the meeting, an employee's value to the meeting, and/or any other suitable metric.

Referring to FIG. 56 , a diagram of an example ‘Employee calendars’ table 5600 according to some embodiments is shown. Table 5600 may store information about employees' scheduled appointments, meetings, lunches, training sessions, or any other time that an employee has blocked off. In various embodiments, table 5600 may store work-related appointments. In various embodiments, table 5600 may store other appointments, such as an employee's personal appointments. Table 5600 may be useful for determining who should attend meetings. For example, given two possible attendees, the central controller may invite the employee with more free time available on his calendar. Table 5600 may also be used to determine whether an employee's time is being used efficiently, to determine an employee's transit time from one appointment to another, in the nature of meetings with which employees are involved, or in any other fashion.

Employee identifier field 5602 may store an indication of an employee. Meeting identifier field 5604 may store an indication of a meeting. If the appointment is not a meeting, there may be no identifier listed. Subject field 5606 may store a subject, summary, explanation, or other description of the appointment. For example, field 5606 may store the subject of a meeting if the appointment is for a meeting, or it may describe a ‘Doctor call’ if the appointment is for the employee to speak to his doctor.

Category field 5608 may store a category of the appointment. Exemplary categories may include ‘Meeting’ for appointments that are meetings, ‘Personal’ for appointments that are not work related (e.g., for an appointment to attend a child's soccer game), ‘Individual’ for appointments to spend time working alone, or any other category of appointment. In various embodiments, categories are input by employees (e.g., by employees who create appointments, by meeting organizers, by employees conducting a manual review of calendars). In various embodiments, a category is determined programmatically, such as by classifying the subject of an appointment into the most closely fitting category.

Date field 5610 may store the date of the appointment. Start time field 5612 may store the start time of the appointment. Duration field 5614 may store the duration of the appointment. In various embodiments, a separate or alternate field may store an end time of the appointment.

‘Company/personal’ field 5616 may store another means of classifying the appointment. In this case, the appointment may be classified as either company (e.g., work-related), or personal (not work-related).

Referring to FIG. 57 , a diagram of an example ‘Projects’ table 5700 according to some embodiments is shown. Table 5700 may store information about projects, initiatives, or other endeavors being undertaken by an organization. Tracking projects at an organization may be useful for various reasons. An organization may wish to see how many meetings are linked to a particular project. The organization may then, for example, decide whether there are too few or too many meetings associated with the project. The organization may also allocate a cost or a charge to the project associated with running the meeting. The organization may thereby, for example, see whether a project is overstepping its budget in light of the number of meetings it is requiring.

Project ID field 5702 may store an identifier (e.g., a unique identifier) for a project. Name field 5704 may store a name associated with a project. ‘Summary’ field 5706 may store a summary description of the project.

Exemplary projects may include a project to switch all employees' desktop computers to using the Linux™ operating system; a project to allow employees to work remotely from the office in a manner that maximizes data security; a project to launch a new app; a project to obtain up-to-date bids from suppliers of the organization. As will be appreciated, any other suitable project is contemplated.

Start date field 5708 may store a start date of the project. Priority field 5710 may store a priority of the project. Expected duration field 5712 may store an expected duration of the project.

Percent completion field 5714 may store the percentage of a project that has been completed. Various embodiments contemplate that other metrics of a project completion may be used, such as number of milestones met, percent of budget spent, quantity of resources used, or any other metric of project completion. Budget field 5716 may store a budget of the project.

Personnel requirements field 5718 may store personnel requirements of the project. In various embodiments, personnel requirements may be expressed in terms of the number of people required and/or in terms of the percentage of a given person's time (e.g., of a given workday) which would be devoted to a project. For example, a personnel requirement of ‘10 people at 75% time’ may indicate that the project will require 10 people, and that each of the 10 people will be utilizing 75% of their time on the project. In various embodiments, personnel requirements may be specified in additional terms. For example, personnel requirements may indicate the departments from which personnel may be drawn, the number of personnel with a given expertise that will be required (e.g., the number of personnel with java expertise), the number of personnel with a given title that will be required (e.g., the number of project managers), or any other requirements for personnel.

Referring to FIG. 58 , table 5800 may store information about employees or other people involved in projects. In various embodiments, table 5800 may store information about key personnel involved in projects. In some embodiments, table 5800 may include information beyond employees, such as contractors, vendors, trainers, safety inspectors, or regulators who may be involved in the project (e.g. a laser safety trainer).

Project ID field 5802 may store an identifier of a project. Employee ID field 5804 may store an indication of an employee who is somehow involved or associated with the project. Role field 5806 may store an indication of an employee's role within a project. Exemplary roles may include: project manager; lead developer; communications strategist; procurement specialist; or any other role, or any other function, or any other association to a project.

Referring to FIG. 59 , a diagram of an example ‘Projects milestones’ table 5900 according to some embodiments is shown. Table 5900 may store information about project milestones, phases, goals, segments, accomplishments or other components of a project.

Project ID field 5902 may store an identifier of a project. Milestone ID field 5904 may store an identifier (e.g., a unique identifier) of a milestone.

Sequence number field 5906 may store a sequence number representing where the present milestone falls in relation to other milestones within the project. For example, the first milestone to be accomplished in a project may receive a sequence number of 1, the second milestone to be accomplished in a project may receive a sequence number of 2, and so on. As will be appreciated, sequence numbers may be designated in any other suitable fashion, such as with roman numerals, with letters of the alphabet, by counting up, by counting down, or in any other manner. In various embodiments, field 5906 (or another field) may also store an indication of the total number of milestones in a project, or of the highest sequence number in the projects. For example, a sequence number may be stored as “3 of 8”, indicating that the milestone is the third milestone out of eight milestones in the project. In various embodiments, it may be intended that some milestones be completed in parallel. Exemplary milestones to be completed in parallel may be designated “3A”, “3B”, etc., or may use any other suitable designation.

Summary field 5908 may store a summary or other description of the milestone. Exemplary summaries include: draft request for proposal; implement pilot with legal group; stress test; review all vendor proposals; or any other summary or description.

Due date field 5910 may store a date when the milestone is due for completion. Percent complete field 5912 may store an indication of what percentage (or fraction) of a milestone has been completed.

Approver(s) field 5914 may store an indication of one or more people who have the authority or ability to approve that a milestone has been completed. For example, an approver might be a project manager, a vice president of a division overseeing a project, a person with expertise in the technology used to accomplish the milestone, or any other suitable approver. Violations field 5916 may store an indication of one or more violations that have occurred on a project.

Referring to FIG. 60 , a diagram of an example ‘Assets’ table 6000 according to some embodiments is shown. Assets may include encapsulated or distilled knowledge, roadmaps, decisions, ideas, explanations, plans, processing fees, recipes, or any other information. Assets may be generated within meetings (e.g., a meeting may result in decisions). Assets may be generated for meetings (e.g., included in presentation decks). Assets may be generated in any other fashion or for any other purpose.

In various embodiments, an asset may include information for improving company operations, or improving meetings themselves. In various embodiments, an asset may include a map, an office map, a campus map, or the like. An exemplary map 6800 is depicted in FIG. 68 . For example, a map may assist in planning for meetings by allowing for selection of meeting locations that minimize participant travel times to the meeting, or match the meeting to the nearest available location with the appropriate capacity or necessary technology.

Table 6000 may store information about assets. Table 6000 may be useful for a number of reasons, such as allowing an employee to search for an educational deck, allowing an employee to find a summary of a meeting that he missed, allowing employees to act in accordance with decisions that have been made, allowing employees to review what had been written on a whiteboard, etc. In various embodiments, table 6000 may be used in addition to, instead of, and/or in combination with asset library table 1900 .

Asset ID field 6002 may store an identifier (e.g., a unique identifier) of an asset. Asset type field 6004 may store an indication of an asset type. Exemplary asset types may be: a presentation deck; notes; meeting minutes; decisions made; meeting summary; action items; photo of whiteboard, or any other asset type. Exemplary asset types may include drawings, renderings, illustrations, mock-ups, etc. For example, an asset might include a draft of a new company logo, a brand image, a mock-up of a user interface for a new product, plans for a new office layout, etc. Exemplary asset types may include videos, such as training videos, promotional videos, etc.

In various embodiments, an asset may include a presentation or presentation template formatted for a particular meeting type or audience (e.g., formatted for executives, members of the board of directors, a project sponsor, a team meeting, a one-on-one).

In various embodiments, an asset may include a progress report, progress tracker, indication of accomplishments, indication of milestones, etc. For example, an asset may include a Scrum Board, Kanban Board, etc.

In various embodiments, assets may be divided or classified into other types or categories. In various embodiments, an asset may have multiple classifications, types, categories, etc.

Meeting ID field 6006 may store an identifier of a meeting with which an asset is associated. For example, if the asset is a deck, the meeting may be the meeting where the deck was used. If the asset is a decision, the meeting may be the meeting where the decision was made.

Creation date field 6008 may store a date when an asset was created. In various embodiments, one or more dates when the asset was modified (e.g., the date of the most recent modification) may also be stored.

Author field 6010 may store the author or authors of an asset. In various embodiments, authors may include contributors to an asset. For example, if an asset is a photo of a whiteboard, then the authors may include everyone who was at the meeting where the whiteboard was populated.

Version field 6012 may store the version of an asset. In various embodiments, an asset may undergo one or more updates, revisions, or other modifications. Thus, for example, the version number may represent the version or iteration of the asset following some number of modifications. At times, it may be useful for an employee to search through older versions of an asset, perhaps to see what the original thinking behind an idea was before it got removed or changed.

Tags field 6014 may store one or more tags associated with an asset. Tags may provide explanatory information about the asset, indicate an author of an asset, indicate the reliability of the asset, indicate the finality of the asset, indicate the state of the asset, indicate the manner in which the asset was generated, indicate feedback about an asset, or provide any other information pertinent to an asset. Illustrative tags include: rated 8/10; author eid204920; computer transcription; needs VP confirmation; short-term items; all items approved by legal; medium quality, etc.

Keywords field 6016 may store one or more keywords or other words, numbers, phrases, or symbols associated with an asset. Keywords may be excerpted from an asset. For example, keywords may be taken from the title of the asset. Keywords may be words that describe the subject or the nature of the asset but are not necessarily literally in the asset. Keywords may be any other suitable words. In various embodiments, keywords may serve as a means by which an employee can locate an asset of interest. For example, if an employee wants to learn more about a certain topic, then the employee may search for assets where the keywords describe the topic. In some embodiments, sets of keywords may include: mission statement, vision, market impact, value prop, customer segments, breakeven, technology roadmap, fiber cables, cloud, personnel, resources, European market, SWOT analysis.

Rating field 6018 may store one or more ratings for the asset. Ratings may represent the utility of the asset, the quality of the asset, the importance of the asset, and/or any other aspect of the asset, and/or any combination of aspects of the asset.

Asset data field 6020 may represent the data comprising the asset itself. For example, if the asset is a deck, then data field 6020 may store the actual Microsoft® PowerPoint™ file data for the deck. If the asset is a photograph, then data field 6020 may store an actual JPEG file of the photograph. In various embodiments, table 6000 may store a link or reference to an asset, rather than the asset data itself (e.g., the asset may be stored in a separate location and table 6000 may store a link or reference to such location).

Presentation Materials

Many company presentations include a deck such as a Microsoft® PowerPoint™ presentation that is emailed to participants and projected for meeting participants to view and discuss during a meeting. Presentation materials can also include videos, white papers, technical documents, instruction manuals, checklists, etc. These presentation materials, however, are often stored on local computers that are not searchable by other individuals.

Various embodiments bring the content of all presentation materials into the central controller 110 (or stored in a cloud provider in a way that is accessible by the central controller) so that they are available to any meeting owner, participant, or employee of the company. A central store of all presentations could include access to historical presentations.

Referring to FIG. 61 , a diagram of an example ‘Presentations’ table 6100 according to some embodiments is shown. Presentations may include decks (e.g., PowerPoint™ decks, Apple® keynote decks, Google® slide decks, etc.). Presentations may include other types of files, such as PDF files, Microsoft® Word™ documents, multimedia files, or any other type of file or any other type of information.

Table 6100 may store information about presentations. Table 6100 may be useful for a number of reasons, such as allowing an employee to search for a particular presentation, a presentation on a topic of interest, the latest in a series of presentations, highly rated presentations, etc. Table 6100 may also allow, for example, comparison of different attributes of a presentation (e.g., number of slides, number of tables), in order to ascertain what attributes of a presentation improve the presentation's effectiveness. Table 6100 may also allow a user to search through presentation decks on a particular topic so that he or she can use material from those decks to aid in the creation of a new presentation deck. Table 6100 may be used for various other purposes as well.

In various embodiments, table 6100 may be used in addition to, instead of, and/or in combination with meeting assets table 6000 . In various embodiments, a presentation is a type of asset.

Asset ID field 6102 may store an identifier of an asset, where, in this case, the asset is a presentation. Number of slides field 6104 may store the number of slides. Number of words field 6106 may store the number of words in the presentation. In various embodiments, a density of words per slide may be computed from fields 6104 and 6106 (e.g., by dividing the number of words described in 6106 by the number of slides described in 6104 ).

Size of the file field 6108 may store the size of a file that represents the presentation (e.g., the size of a PowerPoint file comprising the presentation). Presentation software version field 6110 may store the software, software version, application, program, or the like used for a presentation (e.g., Microsoft® PowerPoint™ for Mac® version 16.35; Keynote™ 11.0; Google® slides).

Number of graphics field 6112 may store the number of graphics used in the presentation. Graphics may include pictures, charts, graphs, tables, maps, animations, illustrations, word clouds, or any other graphic, or any other information.

Number and type of tags field 6114 may store an indication of the number and/or types of tags associated with a presentation. Tags may include descriptive tags, which may describe the nature, subject matter or content of the presentation (e.g., to aid in searching for the presentation), or a portion thereof. Tags may include ratings tags, which may evaluate the presentation, or a portion thereof, along one or more dimensions (e.g., quality, clarity, relevance, reliability, currency, etc.). In various embodiments, a tag may apply to the presentation as a whole. In various embodiments, a tag may apply to a portion of the presentation, such as to an individual slide, an individual graphic, a group of slides, a group of graphics, a section of the presentation, or to any other portion of the presentation. With tags, an employee may be able to search for the ‘financials’ portion of a presentation on the ‘Mainframe architecture’ project, for example. In some embodiments, a user may apply a tag to a slide (e.g. ‘project milestone slide’, ‘Q1 sales chart’, ‘team members’) so that a presenter using presentation remote 4100 can enter a tag via presentation remote 4100 in order to jump directly to that slide during a presentation.

Number of times presented field 6116 may store an indication of the number of times the presentation has been presented (e.g., the number of meetings in which the deck has been featured).

Template used field 6118 may store an indication of a template that was used in creating the presentation. In various embodiments, it may be desirable that presentations on certain topics or for certain purposes follow a specific format. This format may be dictated by a template. For example, a project evaluation committee may wish that all proposals for new projects follow a set format that is dictated by a ‘Project proposal’ template. As another example, it may be desirable that all presentations that are seeking to educate the audience follow a particular format that has been found conducive to learning. Such presentations may follow a ‘Learning template’. The presence of templates may also assist the creator of a presentation in creating the presentation more rapidly.

In various embodiments, there may be multiple templates available for creating a certain type of presentation. For example, there may be multiple types of business plan templates. Those specific template children may depend on the nature of the business plan, the preferences of the presentation creator, or on any other factor. Example templates depicted for field 6118 include: learning template #3; business plan template #8; financials template #3.

Time to create presentation field 6120 may store an indication of the time it took to create the presentation. In various embodiments, this may be an indicator of the quality of a presentation. In various embodiments, a company may wish to make it easier or more efficient to create presentations, and therefore may wish to track how long it took to make every presentation and watch for decreases in creation time over time.

Key points field 6122 may store key points that are in the presentation. These may represent key insights, takeaways, summaries, topics, decisions made, or any other key points, or any other points. Field 6122 may allow employees to search for presentations covering points of interest to them.

Take away summary included field 6124 may indicate whether or not the presentation includes a take away summary. In various embodiments, it may be desirable to encourage presenters to include a take away summary, so the presence of such a summary may be tracked. In various embodiments, an employee with limited time may wish to search for presentations with takeaway summaries and read such summaries rather than reading the entire presentation. A takeaway summary may be used in other embodiments as well.

Security level field 6126 may indicate a security level of the presentation. The level may be expressed in terms of a minimum title or rank an employee must have in order to access the presentation. Example security levels include: general; manager+; VP+. Security levels may be expressed in other terms or scales as well. For example, security levels may be specified in terms such as ‘general’, ‘sensitive’, ‘secret’, ‘top secret’, or using any other scale or terminology.

In various embodiments, portions of a presentation may have their own security levels. For example, the first slide in a presentation may be available for general consumption at the company, whereas another slide may have a higher security level and be accessible only to managers and above. In various embodiments, security levels may apply to individual slides, groups of slides, sections of a presentation, individual graphics, groups of graphics, and/or any other portion or subset of a presentation.

Presentation creation date field 6130 may store the date the presentation was created. In various embodiments, this or another field may store the date of the last revision of the presentation.

Presentation rating field 6132 may store an indication of a rating given to the presentation. A rating may be expressed in any suitable scale (e.g., quantitative, qualitative, etc.). A rating may represent one or more aspects of a presentation, such as the importance of the presentation, the effectiveness of the presentation, the clarity of the presentation, or any other aspect of the presentation. A rating may represent an aggregate of ratings or feedback provided by multiple people. A rating may represent any other suitable statistic.

Acronyms field 6134 may store an indication of acronyms used in the presentation. The field may include an explanation or expansion of the acronym(s). In various embodiments, this may provide a convenient means for uninitiated readers to see what the acronyms mean. In various embodiments, acronyms may be tracked by a company with the desire to reduce the use of acronyms within presentations. Example acronyms include: DCE—data communications equipment; IMAP—internet message access protocol, FCE—frame check sequence.

Tags field 6136 may store one or more tags associated with a presentation. Tags may provide explanatory information about the presentation, indicate an author of the presentation, indicate the reliability of the presentation, indicate the finality of the presentation, indicate the state of the presentation, indicate the manner in which the presentation was generated, indicate feedback about an presentation, or provide any other information pertinent to an presentation. Illustrative tags include: pr75660791, pr71427249 (i.e., this presentation is associated with project IDs pr75660791 and pr71427249), DCE, learning; business plan, market assessment; Projections, financials, pr96358600.

Referring to FIG. 62 , a diagram of an example ‘Presentation Components’ table 6200 according to some embodiments is shown. Presentations may include decks (e.g., PowerPoint decks, Apple Keynote decks, Google® slide decks). Presentations may include other types of files, such as PDF files, Microsoft® Word documents, multimedia files, or any other type of file or any other type of information. A component of a presentation could be a subset of the content of the presentation.

Table 6200 may store information about components of presentations, such as a particular page of a PowerPoint™ presentation or a chart from a pdf document. Presentation components could also include portions of a video or audio file. Table 6200 may be useful for a number of reasons, such as allowing meeting participants to rate particular components of a presentation, such as by providing a numeric rating (e.g. via headset 4000 , via presentation remote 4100 ) for each of three important slides from a presentation as opposed to an overall rating for the presentation. Table 6200 may also allow a user to identify the highest rated sales chart from a large library of presentations, and to use that sales chart at a sales team Town hall presentation. Table 6200 may be used for various other purposes as well.

In various embodiments, table 6200 may be used in addition to, instead of, and/or in combination with meeting presentation table 6100 . In various embodiments, a presentation component is a type of asset.

Asset ID field 6202 may store an identifier of an asset, where, in one embodiment, the asset is a presentation. Component ID field 6204 identifies a component of an asset, such as a single slide page from a presentation. In this example, the presentation is the asset and the component is the slide page. Each identified asset may contain many components identified by component ID 6204 .

Component type field 6206 may store an indication of the component being identified. For example, a component type might be PowerPoint™ slide 7, a graphic file from a Keynote™ presentation, a section of a presentation that discusses benefits of a new software package for the finance department, a two-minute audio clip from a 30-minute CEO all hands presentation, etc.

Average rating field 6208 may store one or more ratings for the component ID. Ratings may represent the utility of the component, the quality of the component, the importance of the component, and/or any other aspect of the component, and/or any combination of aspects of the component. Ratings could be aggregated numerical ratings one a scale of one to ten, such as ratings of 7.5 or 8.2. Ratings could be provided by meeting attendees (e.g. by using a smartphone to send ratings to presentation remote 4100 ) who attended one or more meetings in which the component was presented, providing a rating after review of the component via a user device in communication with central controller 110 .

Ratings associated with presentation components could be useful in identifying employees who produce high quality assets. For example, a component with a high rating can be traced through component ID field 6204 to the corresponding meeting asset ID field 6202 and then, through presentation assets table 6000 , to author field 6010 to determine the identity of the author or the presentation from which the component was a part.

Turning now to FIG. 63 , a block diagram of a system 6300 , including devices with software modules, is shown according to some embodiments. System 6300 includes a first user device 6302 (e.g., a personal computer; e.g., a laptop computer), a first peripheral device 6304 (e.g., mouse, keyboard, camera, presentation remote, headset), a second user device 6306 , and a second peripheral device 6308 (e.g., mouse, keyboard, camera, presentation remote, headset). One or more of devices 6302 , 6304 , and 6306 may be connected to a network (e.g., network 6310 ). Also, the first peripheral device 6304 may be in communication with the first user device 6302 (e.g., via a cable, via Wi-Fi® connection), and the second peripheral device 6308 may be in communication with the second user device 6302 . Also, the first peripheral device 6304 may be in communication with the second peripheral device 6308 as will be appreciated, the depicted devices represent some exemplary devices, and system 6300 may include more or fewer devices, in various embodiments. Also, various embodiments contemplate that any combination of devices may be in communication with one another.

In various embodiments, a message is sent from the first peripheral device 6304 to the second peripheral device 6308 . For example, the message may be a congratulatory message being sent from the owner of peripheral device 6304 to the owner of peripheral device 6308 . The message may have any other form or purpose, and various embodiments.

The message originating from peripheral device 6304 may be transmitted via user device 6302 , network 6310 , and user device 6306 before reaching peripheral device 6308 . At peripheral device 6308 , the message may be output to a user in some fashion (e.g., a text message may be displayed on a screen of peripheral device 6308 ; e.g., an audible message may be broadcast from a speaker of a headset). In various embodiments, the message originating from peripheral device 6304 may be transmitted via network 6310 , and via user device 6306 before reaching peripheral device 6308 . In various embodiments, the message originating from peripheral device 6304 may be transmitted directly to peripheral device 6308 (e.g., if peripheral device 6304 and peripheral device 6308 are in direct communication).

In various embodiments, as a message is conveyed, the form of the message may change at different points along its trajectory. The message may be represented in different ways, using different technologies, using different compression algorithms, using different coding mechanisms, using different levels of encryption, etc. For example, when originally created, the message may have the form of electrical impulses read from a mouse button (e.g., impulses representing the pressing of the button). However, within the peripheral device 6304 , the electrical impulses may be interpreted as discrete bits, and these bits, in turn, interpreted as alphanumeric messages. Later, when the message is transmitted from the user device 6302 to the network, the messages may be modulated into an electromagnetic wave and transmitted wirelessly.

Various embodiments include one or more modules (e.g., software modules) within devices 6304 , 6302 , 6306 , and 6308 . In various embodiments, such modules may contribute to the operation of the respective devices. In various embodiments, such modules may also interpret, encode, decode, or otherwise transform a message. The message may then be passed along to another module.

Modules may include programs (e.g., program 9455 ), logic, computer instructions, bit-code, or the like that may be stored in memory (e.g., in storage device 9445 ) and executed by a device component (e.g., by processor 9405 ). Separate modules may represent separate programs that can be run more or less independently of one another and/or with some well-defined interface (e.g., API) between the programs.

Operating system 6326 may be a module that is capable of interfacing with other modules and/or with hardware on the peripheral device 6304 . Thus, in various embodiments, operating system 6326 may serve as a bridge through which a first module may communicate with a second module. Further, operating system 6326 may coordinate the operation of other modules (e.g., by allocating time slices to other modules on a processor, such as processor 9405 ). Further, operating system 6326 may provide and/or coordinate access to common resources used by various modules. For example, operating system 6326 may coordinate access to memory (e.g., random access memory) shared by other modules. Exemplary operating systems may include Embedded Linux™, Windows® Mobile Operating System, RTLinux™, Windows® CE, FreeRTOS, etc.

Component driver 6312 may serve as an interface between the operating system and an individual hardware component. As depicted, peripheral device 6304 includes one component driver 6312 , but various embodiments contemplate that there may be multiple component drivers (e.g., one component driver for each component of the device). A component driver may translate higher level instructions provided by the operating system 6326 into lower-level instructions that can be understood by hardware components (e.g., into instructions that specify hardware addresses, pin numbers on chips, voltage levels for each pin, etc.). A component driver may also translate low level signals provided by the component driver into higher level signals or instructions understandable to the operating system.

Frame buffer 6314 may store a bitmap that drives a display (e.g., screen 9435 ). When another module (e.g., application 6318 ) wishes to output an image to a user, the module may generate a bitmap representative of the image. The bitmap may then be transmitted to the frame buffer (e.g., via the operating system 6326 ). The corresponding image may then appear on the display. If another module (e.g., application 6318 ) wishes to output a video to a user, the module may generate a sequence of bitmaps representative of sequential frames of the video. These may then be transmitted to the frame buffer for display one after the other. In various embodiments, the frame buffer may be capable of storing multiple images at once (e.g., multiple frames of a video), and may thereby ensure that video playback is smooth even if there are irregularities in transmitting the video bitmaps to the frame buffer.

User input/output controller 6316 may serve as an interface between the operation system 6326 and various input and output devices on the peripheral. As depicted, peripheral device 6304 includes one user input/output controller 6316 , but various embodiments contemplate that there may be multiple user input/output controllers (e.g., one controller for each input device and output device on the peripheral). A user input/output controller provides an interface that allows other modules (e.g. application 6318 ) to retrieve data or messages from an input device (e.g. the left button was clicked). The user input/output controller also provides an interface that allows other modules (e.g. application 6318 ) to send data or commands to an output device (e.g. vibrate the peripheral). The data or messages sent via this controller may be modified so as to translate module level data and commands into ones compatible with the input and output devices.

Application 6318 may be any computer code run in the operating system 6326 that runs algorithms, processes data, communicates with various components, and/or sends messages. As depicted, peripheral device 6304 includes one application 6318 , but various embodiments contemplate that there may be multiple applications (e.g. one application to send messages to peripheral device 6308 and another that plays a video on screen 9435 ). Applications may be run independently but may share resources (e.g. two applications running may both use database 6322 to read and store data).

AI Module 6320 may process various data input sources (e.g. input device 9420 ) to learn and predict user behavior. The AI Module may apply various heuristics and algorithms to parse the input data to construct and update models that can predict future input (e.g. predict when the next mouse click will come) or prepare a custom output (e.g., display a congratulatory message on screen 9435 when a user completes a new level in a game). The module may use database 6322 to read saved models, create new models, and update existing ones that are stored on storage device 9445 .

Database 6322 may serve as an interface to structured data on storage device 9445 . The database module provides an abstraction to other modules to allow high level read and write requests for data without knowledge of how the data is formatted on disk. As depicted, peripheral device 6304 includes one database 6322 , but various embodiments contemplate that there may be multiple databases (e.g., one storing click history and another an AI model). The database may store data in any format (e.g. relational database) and may be stored in multiple files and locations on storage device 9445 . A database may also access remote data, either on user device 6302 or in the cloud via network 6310 . The database may restrict access to data to certain modules or users and not allow unauthorized access.

Computer data interface controller 6324 may serve as an interface between the peripheral 6304 and the attached user device 6302 or peripheral device 6308 . The interface controller allows messages and data packets to be sent in both directions. When another module (e.g., application 6318 ) wishes to send a message to a remote device, the module would use the API provided by the computer data interface controller 6324 to do so. The interface controller collects messages and data packets received by the peripheral and transmits them via operating system 6326 to the module that made the request or that is necessary to process them.

User device 6302 may include one or more modules, e.g., operating system 6340 , computer data interface controller 6328 , peripheral device driver 6330 , application 6333 , AI module 6334 , database 6336 , and network interface controller 6338 . In various embodiments, user device 6302 may contain more or fewer modules, and may contain more or fewer instances of a given module (e.g., the user device may contain multiple application modules).

Operating system 6340 may have an analogous function on user device 6302 as does operating system 6326 on peripheral device 6304 . Exemplary operating systems include Apple® macOS, Microsoft® Windows™, and Linux™.

Computer data interface controller 6328 may serve as an interface between the user device 6302 and the peripheral device 6304 . Computer data interface controller 6328 may have an analogous function to computer data interface controller 6324 in the peripheral device 6304 .

Peripheral device driver 6330 may translate unique or proprietary signals from the peripheral device 6304 into standard commands or instructions understood by the operating system 6340 . The peripheral device driver may also store a current state of the peripheral device (e.g., a mouse position). Peripheral states or instructions may be passed to operating system 6340 as needed, e.g., to direct progress in application 6332 .

In various embodiments, peripheral device driver 6330 may translate messages from an application or other module into commands or signals intended for the peripheral device 6304 . Such signals may direct the peripheral device to take some action, such as displaying text, displaying an image, activating an LED light, turning off an LED light, disabling a component of the peripheral device (e.g., disabling the left mouse button), enabling a component of the peripheral device, altering the function of the peripheral device, and/or any other action.

Application 6332 may include any program, application, or the like. Application 6332 may have an analogous function to application 6318 on the peripheral device 6304 . In various embodiments, application 6332 may include a user-facing application, such as a spreadsheet program, a video game, a word processing application, a slide program, a music player, a web browser, or any other application.

AI module 6334 and database 6336 may have analogous functions to AI module 6320 and database 6322 , respectively, on the peripheral device 6304 .

Network interface controller 6338 may serve as an interface between the user device 6302 and the network 6310 . In various embodiments, network interface controller 6338 may serve as an interface to one or more external devices. The interface controller 6338 may allow messages and data packets to be sent in both directions (e.g., both to and from user device 6302 ). When another module (e.g., application 6332 ) wishes to send a message over network 6310 and/or to a remote device, the module may use an API provided by the network data interface controller 6338 to do so. The interface controller 6338 may collect messages and data packets received by the user device and transmit them via operating system 6340 to the module that made the request or that is necessary to process them.

Although not shown explicitly, user device 6302 , peripheral device 6304 , central controller 110 , and/or any other device may include such modules as: a text to speech translation module; a language translation module; a face recognition module; and/or any suitable module.

Although not shown explicitly, user device 6306 may have a similar set of modules as does user device 6302 . Although not shown explicitly, peripheral device 6308 may have a similar set of modules as does peripheral device 6304 .

Referring to FIGS. 73A-C , a diagram of an example ‘Presentation underlying data’ table 7300 according to some embodiments is shown. It will be noted that table 7300 , and each row thereof, spans across all of FIGS. 73A-C . Table 7300 may store presentation information, including literal text, graphics, images, animations, etc. Table 7300 may also store other information that may be helpful in identifying or recognizing the presentation information, such as in the context of image recognition. A presentation remote 4100 may capture an image of a display screen where a presentation is rendered. If the presentation remote 4100 recognizes a region of the display screen that is of interest (e.g., an audience member wants a copy of the contents of the upper right text box), then the presentation remote 4100 may utilize the location information, together with table 7300 , in order to more readily retrieve the presentation information of interest.

Information identifier field 7302 may include an identifier (e.g., a unique identifier) for an item of information in the presentation.

Asset Identifier field 7304 may include an identifier of a presentation or other asset where the item of information is contained. Page Identifier field 7306 may include an indication of a page within the presentation where the item of information is located. Region identifier field 7308 may include an indication of a region within a page where the item of information is located. A region may represent a box, square, section, and/or some other subdivision of a page. As will be appreciated, depending on the nature of the presentation (e.g., deck versus video, etc.), various other and/or alternative indications of location may be used (e.g., a number of minutes or frames into a video, etc.).

The fields ‘X Location’ 7310 and ‘Y Location’ 7312 may include an indication of a region's location within a page. Location may be represented as a percentage of the page (e.g., a region starts 5% of the way from an edge of the page). Location may be represented as pixels (e.g., a region starts one hundred pixels from an edge of the page). Location may be represented in any other suitable fashion. In various embodiments, where location is represented as a percentage of the page, locating a