It is envisioned that there would be a series of different generic Utility and Gateway devices that can provide inexpensive capabilities that can be used throughout a house or other institution. They would be built off of modular and inheritable HW and SW libraries, SDKs, and methods that can be incorporated into a wide variety of different System compatible devices for new, utility, and gateway devices. This also helps bring down the costs for components, design, development, test, documentation, production, and support, while providing additional features.

 

Some of those HW and/or Software Capabilities would include:

• Memory and Processing

• Network connectivity (Wi-Fi, Bluetooth, Ethernet Over Power, IR) as well as being able to repeat signals from other devices

• RFID to identify specific individuals/objects or collect data from an RFID interfaced device

• Speaker, Microphone, Camera, Light

• Motion and Light Detector

• Smoke, CO2, Oxygen, Temperature sensors

• AC and DC plugs

• Battery and Battery Backup/Charger

• Direct connect interfaces for RS232, RJ11, RJ422, USB, Contact Switch, etc.

• A wide variety of SW to be able to configure and use the capabilities in different ways

 

Since the components and their incorporation into devices are common and modular, the HW and SW components required for a new, utility, and/or gateway devices could be mainly created, from a menu of modules or components (with their associated common interfaces and methods) and be fully compliant.

Since individual devices and their components are compliant and have supported generic interfaces, they can be modified or used as is to support additional functions as needed. For example, a single generic or custom Gateway and/or Utility Device, could be used to support more than one purpose.

 

In addition to using the wide range of specialized devices (built from the configurable components) built by individual companies to provide monitoring and services for individuals… just using simple Gateway/Utility devices (or adding additional features to a specialized device) the devices could additionally support for:

• Providing night and emergency lighting

• Making sure the individual is getting up, getting certain things (food/medicine) at certain times, and having expected activity (including analysis on any trends)

• Providing whole home intercom for door bells, automated checking and escalation for response, request for help, eternally initiated communication, and monitoring for alarms and processing them  as needed

• Processing any events associated with doors or windows that might open or close (break-ins, electronic fences, visitors)

• Providing Visual health checks to examine for pain (facial pain recognition, mobility/agility analysis), remote check for person being OK (when enabled)

• Providing interfaces and/or network extension for a wide range of System compatible and non-compatible devices

 

Some people may be concerned about Privacy when there is a potential of having active cameras and microphones. There are several different techniques that can be deployed to provide the required general privacy, and overrides when needed for the individual’s safety.

• Distinctive LED lights on devices when the cameras or microphones are active

• Define access and alerts by individual camera and microphone

• Define times when specific cameras and microphones are active

• Restrict standard microphone and camera monitoring to analysis and reporting by the System not readily accessible to humans

• Event logging for any access of live or recorded audio or visual data

• Automatic obstruction of certain parts of the body without overriding and creating an alert

 

Gateways/Utility Devices can provide compatibility as well as additional features to non-compliant devices that a person may need or already have. This is done through machine-to-machine communication either through wireless or direct HW connects. Note: Wireless can be wireless networks, sound, IR, visual, etc. HW devices are typically required if the legacy device needs a physical HW connection to access its features. The machine-to-machine communication interfaces and methods can be on a gateway/utility device, or further out in the System (cellphones, tablets, PCs, local servers, cloud servers, etc.).

 

Some of the examples of the features that can be provided to incorporate a legacy device into the System include:

• Providing a common and simple user interface

• Instructions and/or automation for the device

• Reminders for calibration, maintenance, service renewal

• Storage and access for support and warranty contact information

• Turning on and off the device based on a schedule

• Running and analyzing diagnostics and verification it is operating

• Collecting and reporting errors for support companies

• Remote access for support

• Checking for available upgrades and fixes

• Remote and automatic upgrades

• Automatic data collection, sanity checks, analysis, and alerts

• Cross correlation with other information or collected data

 

Some of the interfaces to legacy devices can be pretty interesting. In addition to standard wireless digital networks, standard component sensors can provide additional interfaces to devices.

• Using a camera…

  • You could tell if a device had a power-on or error indicator on

  • Read the value that is displayed and then collect, sanity check, analyze, and alerts/escalate as needed

  • Read an analog scale, or graph and store it

  • Detect movement or something being open or closed

  • Tell if a person had physically gone and accessed the device

  • Read a printout from a device

  • Localization and Language Translation for output

• Using a Microphone

  • Capturing and interpreting any verbal communication from the device

  • Capturing and interpreting any beeps or sounds from the device

  • Relaying sound or information from the device to the System

  • Localization and Language Translation

• Using a Speaker

  • Providing any verbal communication to the device

  • Capturing and interpreting any beeps or sounds from the device

  • Provide interpret and provide information to the individual that is not visible to them (visually impaired, wouldn’t necessarily understand the information, or an internal error code or status)

  • Localization and Language Translation

• Using an RX/TX IR (infrared)

  • Provide IR input/output control to a device

• Using an RFID capability

  • Further verification of a Person’s or objects presence in an area for correlation with other data

  • Reading “on body” or standalone sensor data that is triggered or collected through RFID Power (diabetes, heart, temperature, O2 content, etc.)

  • Electronic Fence

  • Notes:

    • The device or GW could conserve on power by using optical and motion sensors to determine when RFID would be enables

    • Some Smart Phones already support some of this feature

• Using a Power Connection

  • Turn on and off a device

  • Provide clean and backup power

• Using a Contact Switch

  • Determine different device states

  • Control different device states

• Using a Data Connection (e.g. RS232, RJ11, USB, etc.)

  • Communication to and from the device through a number of different scripted commands

 

<Read more about Visual Services>

 

<Read more about Audio Services>

 

<Read more about Device Services>