GB2526544A - Schema-defined remote device component control and manipulation for data capture, transmission and storage - Google Patents

Abstract

A device may comprise a series of circuit boards, figures 1- 4 comprising a power source, network connections, audio visual facilities, data storage means, a gps / global positioning means , an rfid module and a near field communications device. The device may automatically gather metadata via onboard or remote sensing means such as light/motion sensors or fingerprint scanner and may download said information to a remote server, copies of said metadata may be saved on the server and on the device. As information is stored on the device it may be compared against previously entered datasets to determine changes in the data. The user may be alerted to any such trends/ changes. The device may be able to create/upload survey forms /questionnaires.

Description

Background:

To derive information, most organizations and individuals collect data. Data collection is the process of gathering and measuring information on variables of interest, in an established systematic fashion which enables one to answer questions, test hypotheses and evaluate outcomes.

Data can be collected in one of many ways, for example web-based forms, paper, recording devices etc. The data collected, its type and the adopted process are influenced by the intended usage or purpose of collecting data. E.g. A population census would require a collection of demographic data while sales forecasting would require a collection of retail data.

The data collection process can be quantitative or qualitative in nature.

Quantitative data collection methods (e.g. experimental / clinical trials, observing and recording well-defined events, obtaining relevant data from management information systems, or administering surveys with closed-ended questions) rely on structured data collection instruments that fit diverse experiences into pre-determined response categories; usually producing results that are easy to summarize, compare, and generalize.

Collection of quantitative field data tends to be project specific and expensive because custom devices might have to be designed for the data collection process which will prove useless on completion of the exercise.

Qualitative data is usually gathered through interviews, questionnaires and observations. As qualitative data gathering involves a structured process, changes to the research question or hypothesis usually involves a redesign of the data collection instruments which comes with associated costs in terms of time, finance and effort. For example, during the course of a 3-month data collection campaign involving filling of questionnaires by members of a sample population, a researcher observes that a previously unnoticed variable might have significant impact on the result of the evaluation, the researcher will be faced with the option of discarding previously collected data since the new requirement would be inconsistent with the current forms used in data collection.

The previously stated issues make accurate collection of quantitative data a tasking, potentially inaccurate and expensive process.

Detailed description:

Overview -A data collection campaign is set up on a remote central server by specifying the type of data (text) number) date, time, boolean, location data) binary data -documents and images, or raw data -sensor, biometric, and unique identification data) required.

Based on the expected type of data, a schema describing the dataset is generated and stored on the server. This schema is required to identify the dataset a collection of data belongs and render forms or activate components on a remotely located hardware device for data collection.

A change of the schema automatically triggers a corresponding change in associated data collection methods as well.

A remote data-collection device can be located by its global positioning satellite (GPS) coordinates, its components can be remotely enabled or disabled, and preferences applied as specified in the dataset schema.

Technical details -Figures 1) 2, 3 and 4 illustrate a sample multi-layered view of component modules on the device circuit board) showing the layout for a remotely accessible data capture and storage device (hereafter referred to as a data beacon).

Figure 1 shows a sketch of a circuit board 1 with the outline of an alternate power source 2 beneath, Figure 2 shows a basic component layout of the beacon circuit board displaying network 1) audio 2) video 3, power 4, and storage 5 components, Figure 3 shows global positioning satellite module 1, near-field communication and radio-frequency identification module 2 components on the beacon circuit board, Figure 4 depicts additional camera 1, sensor 2, LED lights 3, and fingerprint scanner 4 modules.

The data beacon consists of input/output ports i.e. universal serial bus (USB), audio, video, and network connectivity; a central processing unit (CPU), a graphical processing unit (GPU), light emitting diode (LED) notification lights) a global positioning satellite (GPS) module, a camera module, light and/or motion sensor, fingerprint scanner, a near field communication (NFC) device) a radio-frequency identification device (RFID), and a removable storage device (for example flash memory).

The data beacon can be powered externally or internally by connecting to a power source or through internal batteries.

The data beacon is associated with a remotely defined dataset.

The definition of the dataset structure) hereby referred to as the schema or metadata, is located on the remote server and an identical copy is saved on the data beacon.

Various data collection modes are applicable to the data beacon. Data can be collected through the light and/or motion sensors, fingerprint scanner) NFC & RFID modules when the beacon is brought in contact with a smart card, an REID tag) or a device with an embedded NEC chip.

The data beacon can be connected to a visual display unit (VDU) i.e. a computer monitor, to oversee the data collection process or to collect data using dynamically created forms, for example in cases where data is specified in the schema to be collected using computer-based forms.

Figure 5 illustrates the beacon-server communication showing the data capture, validation and storage process work flow which is detailed as follows: When the data beacon is powered on, a connection attempt is made to the remote server.

If a connection is established, the data beacon connection is authenticated and the dataset schema/metadata is provided to the data beacon.

If the schema is different from the local copy, the local copy is replaced with the new schema.

If a connection could not be established, the local schema is selected instead.

A looping check for an update to the dataset schema is optionally initialized at this point in the process life cycle.

The check specified in the previous step could be delayed till a later point in the flow chart and may be performed linearly during the data collection workflow, rather than cyclically as a constant running loop.

The data collection requirements are set up based on the dataset schema i.e. For example if form widgets are required, a form is dynamically generated to be filled for submission of an entry; if biometric data is required the biometric scanner is activated and the beacon starts listening for interaction or contact with the sensor.

For form-based data collection, a visual display unit is required to be connected to the data beacon to complete entry submission.

On provision of an entry, the type of data collected and rules applicable to the data are checked against the expected type and rules specified in the schema to ascertain that the data submitted matches the data expected. If there is a mismatch, the user is notified through an attached visual display unit or the beacon's LED indicator lights, otherwise the data is passed and ready for submission as an entry to a dataset in a remotely located central data store.

The validation in the previous step may also be carried out by making a connection to a remote server and providing details about the entry and the dataset. For example, to check if the data entered is unique (as specified in the dataset schema) a connection with a remote server would have to be established to ensure the provided entry is unique amongst stored entries in the dataset.

On validation of the provided entry, a connection to the remote server is attempted. If a connection is established and authenticated, the entry is submitted and stored against the dataset. If the connection failed, the entry is securely saved in the embedded data store on the beacon to be pushed to the remote dataset at a later moment when a connection to the remote data store can be re-established. The beacon then goes back to listening for entry submissions.

While various embodiments are described herein, these embodiments have been presented by way of example only and not intended to limit the scope of the claimed subject matter. Many variations are possible which remain within the scope of the following claims. Such variations are clear after inspection of the specification, drawings, and claims herein. Accordingly the breadth and scope of the claimed subject matter is not to the restricted excerpt as defined with the following claims and their equivalents.

The words example and or exemplary are used herein to mean serving as an example instance or illustration. Any aspect, design, etc. described herein as "example" and/or "exemplary" is not necessarily to be construed as advantageous over other aspects, designs etc. Rather, use of these terms is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is) unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing instances. In addition, the articles "a" and "an" as used in this application and the appended claims may generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Also, at least one of A and B or the like generally, means A or B or both A and B. Although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The disclosure includes all such modifications and alterations and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated example implementations of the disclosure. Similarly, illustrated ordering(s) of acts is not meant to be limiting, such that different orderings comprising the same of different (e.g., numbers) of acts are intended to fall within the scope of the instant disclosure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.

Furthermore, to the extent that the terms "includes", "having", "has", "with", or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising."

Claims (4)

1. Claims: 1. A device to collect real-world/on-field/physical data by dynamically creating data capture processes on-demand, based on a remotely defined and/or locally stored metadata schema.
2. 2. A device according to claim 1, which reliably transmits data to a remote server for storage or processing by guaranteeing accuracy of transmitted data.
3. 3. A device according to claim 1, which activates or deactivates or allows access to or denies access from its component parts based on specifications defined on a remote server.
4. 4. A device according to claim 1, which may be located by global positioning satellite coordinates.