Patent Description:
An auditable camera is provided according to claim <NUM>.

In some embodiments, a coordinator computing device is provided. The coordinator computing device comprises a short range wireless interface, a long range wireless interface, an auditable device communication engine, and a system communication engine. The auditable device communication engine is configured to establish a short range communication channel between the coordinator computing device and an auditable device via the short range wireless interface; and to receive an auditable event entry from the auditable device via the short range communication channel. The system communication engine is configured to establish a long range communication channel between the coordinator computing device and an evidence management system via the long range wireless interface; and to transmit the auditable event entry to the evidence management system via the long range communication channel.

In some embodiments, an evidence management system is provided. The evidence management system comprises a video data store, an audit trail data store, and at least one computing device configured to provide a data gathering engine. The video data store is configured to store video data received from a plurality of wearable cameras. The audit trail data store is configured to store a plurality of auditable event entries generated by the plurality of wearable cameras. The data gathering engine is configured to receive video data from a plurality of wearable cameras and store the video data in the video data store; and to receive auditable event entries generated by the plurality of wearable cameras and store the auditable event entries in the audit trail data store.

Embodiments of the present disclosure solve the technical problems introduced above, as well as others. In some embodiments, auditable devices such as auditable cameras are provided. The auditable devices maintain audit trail data that is digitally signed and stored on the devices until it can be uploaded to an evidence management system. When an intermittent data connection to the evidence management system is available, the auditable devices transmit records of urgent events to the evidence management system, so that the evidence management system is notified to expect further data associated with the events despite the lack of persistent data connectivity to the device. By using these and other techniques, the technical problems introduced above and others can be overcome.

<FIG> is a high-level schematic diagram that illustrates communication between various components of an exemplary embodiment of a system according to various aspects of the present disclosure. In some embodiments, the system <NUM> is configured to allow for collection of auditing information from a plurality of auditable devices. The auditing information is generated by the auditable devices while they are being operated, and is gathered by an evidence management system <NUM>.

In general, a user <NUM>, such as a law enforcement officer, may carry one or more auditable devices. The devices may include, but are not limited to, an auditable camera <NUM>, an auditable weapon <NUM>, and a light bar sensor <NUM>. The auditable camera <NUM> may be, for example, a wearable camera that records video and/or audio data when activated, and stores a record of auditable events that occur (such as the start of recording, the end of recording, various device faults, and/or the like and as described further below). The auditable weapon <NUM> may be, for example, a conducted energy weapon (CEW) that records firing events, cartridge loading, holster removal, and/or the like. The light bar sensor <NUM> may detect activation of the light bar on the vehicle <NUM>, which is usually associated with an emergency situation. Other auditable devices, such as a dashboard camera, a heart rate sensor, may also be included in the system <NUM> but are not illustrated in <FIG>.

In some embodiments, the auditable devices may have limited communication functionality. For example, auditable devices may only be able to transmit information to the evidence management system <NUM> when physically connected to an evidence collection dock <NUM> that communicates with the evidence management system <NUM> via a broadband network <NUM> such as a LAN, a WAN, and/or the Internet. Accordingly, technical problems arise when attempting to obtain verifiably complete auditing information in that there is no reliable, always-on communication path between the evidence management system <NUM> and the auditable devices.

In some embodiments, an ad-hoc communication path may be created between the auditable device and the evidence management system <NUM> via a coordinator computing device <NUM>. The coordinator computing device <NUM> is illustrated as a smartphone computing device, but in some embodiments may be a laptop computing device, a tablet computing device, or any other suitable computing device capable of being carried by the user <NUM> or a vehicle <NUM> associated with the user <NUM> and capable of performing the actions described herein. The coordinator computing device <NUM> communicates with the auditable devices, and may also communicate with other devices such as a light bar sensor <NUM> of a vehicle <NUM> associated with the user <NUM>, using a short-range wireless communication technology such as Bluetooth, Zigbee, IrDA, ANT, ANT+, <NUM>. <NUM>, near-field communication (NFC), a radio frequency identifier (RFID) tag, and/or the like. In some embodiments, the auditable camera <NUM> may receive data directly from other auditable devices such as an auditable weapon <NUM> or a light bar sensor <NUM> in order to enhance the auditable event entries collected by the auditable camera <NUM>.

The coordinator computing device <NUM> is capable of communicating with the evidence management system <NUM>, though the communication path between the coordinator computing device <NUM> may be unreliable, may drain battery performance too greatly to be constantly enabled, or may be of relatively low bandwidth. As such, the communication of information from the coordinator computing device <NUM> to the evidence management system <NUM> may be sporadic and may transmit only a subset of information gathered by or audited on the auditable devices. Further aspects of these devices and their capabilities will be discussed below.

<FIG> is a block diagram that illustrates components of an exemplary embodiment of an auditable camera according to various aspects of the present disclosure. In some embodiments, the auditable camera <NUM> is a wearable camera that provides a point of view associated with the user <NUM>. In some embodiments, the auditable camera <NUM> may be attached to another device carried by the user <NUM>, such as a weapon.

As with any camera, the auditable camera <NUM> includes at least a video sensor <NUM>, and may also include an audio sensor <NUM>. Data collected by the video sensor <NUM> and the audio sensor <NUM> may be stored in a video data store <NUM> and an audio data store <NUM>, respectively, though in some embodiments the audio and video information is stored together in a single data store and/or in a combined data file. One example of an appropriate video sensor is a charge-coupled device (CCD), though any other digital image sensor, such as a complementary metal-oxide-semiconductor (CMOS) sensor, an active pixel sensor, or any other type of digital image sensor could be used instead. Any type of microphone may be used as an audio sensor <NUM>.

As understood by one of ordinary skill in the art, a "data store" as described herein may be any suitable device configured to store data for access by a computing device. One example of a data store suitable for use with the high capacity needs of the evidence management system <NUM> is a highly reliable, high-speed relational database management system (RDBMS) executing on one or more computing devices and accessible over a high-speed network. However, any other suitable storage technique and/or device capable of quickly and reliably providing the stored data in response to queries may be used, such as a key-value store, an object database, and/or the like. Further, for the evidence management system <NUM>, the computing device providing the data store may be accessible locally instead of over a network, or may be provided as a cloud-based service. A data store may also include data stored in an organized manner on a computer-readable storage medium, as described further below. One example of a data store suitable for use with the needs of the auditable camera <NUM> and the coordinator computing device <NUM>, which includes reliable storage but also low overhead, is a file system or database management system that stores data in files (or records) on a computer readable medium such as flash memory, random access memory (RAM), hard disk drives, and/or the like. One of ordinary skill in the art will recognize that separate data stores described herein may be combined into a single data store, and/or a single data store described herein may be separated into multiple data stores, without departing from the scope of the present disclosure.

The auditable camera <NUM> includes a set of engines, including a camera control engine <NUM>, an audit trail signing engine <NUM>, an audit trail gathering engine <NUM>, and an audit trail reporting engine <NUM>. In general, the term "engine" as used herein refers to logic embodied in hardware or software instructions, which can be written in a programming language, such as C, C++, COBOL, JAVA™, PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, Microsoft. NET™ languages such as C#, and/or the like. An engine may be compiled into executable programs or written in interpreted programming languages. Engines may be callable from other engines or from themselves. Generally, the engines described herein refer to logical modules that can be merged with other engines or applications, or can be divided into sub-engines. The engines can be stored in any type of computer readable medium or computer storage device and be stored on and executed by one or more general purpose computers, thus creating a special purpose computer configured to provide the engine. Accordingly, the devices and systems illustrated herein include one or more computing devices configured to provide the illustrated engines, though the computing devices themselves have not been illustrated in every case for the sake of clarity.

The camera control engine <NUM> is configured to cause the auditable camera <NUM> to perform camera functions. For example, the camera control engine <NUM> may cause the video sensor <NUM> and audio sensor <NUM> to begin obtaining data, and may save the video and/or audio data in a video data store <NUM> and/or audio data store <NUM> after receiving it from the sensor. The camera control engine <NUM> may receive commands to start, pause, or stop the video recording from a physical user interface device <NUM>, or may automatically start, pause, or stop the video recording in response to a signal received from some other component of the auditable camera <NUM> (such as the battery sensor <NUM>, the clock <NUM>, the motion sensor <NUM>, the short-range wireless interface <NUM>, and/or the like). The camera control engine <NUM> may also change settings on the video sensor <NUM> and/or audio sensor <NUM>, such as an image quality, a white balance setting, a gain, and/or any other common video or audio recording setting, based on configuration settings received via a physical user interface device <NUM>, via the short-range wireless interface <NUM>, via the physical dock interface <NUM>, or by any other suitable technique. Any type of physical user interface device <NUM> that can transmit commands to the camera control engine <NUM> may be used, including but not limited to push button switches, toggle switches, slide switches, touch switches, and/or the like.

In some embodiments, the camera control engine <NUM> may report starting, pausing, or stopping the video recording, as well as the settings for the video sensor <NUM> and audio sensor <NUM>, as auditable events to the audit trail gathering engine <NUM>. In some embodiments, the camera control engine <NUM> may embed the sensor configuration information in the data stored in the video data store <NUM> and/or audio data store <NUM>, along with other information about the state of the auditable camera <NUM> or other information received via the short-range wireless interface about other auditable devices, to prevent the additional information from being disassociated with the video and/or audio data.

The auditable camera <NUM> also includes an audit trail data store <NUM> for storing records of auditable events and a certificate data store <NUM> for storing data usable for digital signing. The audit trail gathering engine <NUM> is configured to receive reports of auditable events from the other components of the auditable camera <NUM>, and to record auditable event records that represent the events in the audit trail data store <NUM>. The audit trail signing engine <NUM> is configured to use one or more signing certificates from the certificate data store <NUM> to apply a digital signature to the auditable event records in the audit trail data store <NUM>. The audit trail reporting engine <NUM> is configured to transmit the audit trail information from the audit trail data store <NUM> to the evidence management system <NUM>, either directly via the long-range wireless interface <NUM> or physical dock interface <NUM>, or via the short-range wireless interface <NUM> and the coordinator computing device <NUM>. Further details of the functionality of these components are provided below.

The auditable camera <NUM> also includes a number of general components, including a clock <NUM>, a motion sensor <NUM>, a physical dock interface <NUM>, a battery sensor <NUM>, a battery <NUM>. The clock <NUM> may be used by the audit trail gathering engine <NUM>, the audit trail reporting engine <NUM>, the camera control engine <NUM>, or any other component of the auditable camera <NUM> to include timestamp information in generated data. The motion sensor <NUM>, such as a multi-axis accelerometer, also produces information that may be used by other components. For example, the audit trail gathering engine <NUM> may use the motion sensor <NUM> to detect a certain type of motion, such as running, falling, and/or the like, and to treat the detected motion as an auditable event.

The physical dock interface <NUM> is configured to mate with a physical connector on the evidence collection dock <NUM>. In some embodiments, the physical dock interface <NUM> may include a female <NUM> socket, which mates with a male <NUM> plug of the evidence collection dock <NUM>. Once docked, the auditable camera <NUM> may then transfer data to the evidence management system <NUM> via the connection using any suitable data transmission protocol. In some embodiments, power may be transferred to the auditable camera <NUM> via the physical dock interface <NUM> instead of or in addition to the data transfer. In some embodiments, other connection hardware that can provide both power and data connectivity may be used, such as a USB connector, a Firewire connector, and/or the like.

The battery sensor <NUM> and the battery <NUM> are an example of an internal system that may generate auditable events that are captured by the audit trail gathering engine <NUM> without user intervention. For example, the battery sensor <NUM> may detect a low battery state, a battery overheating state, and/or the like, and may generate alerts to be logged as auditable events by the audit trail gathering engine. Other well-known internal device systems, such as a file system controller, a free-fall sensor, and/or the like, may similarly generate alerts to be logged as auditable events, but are not illustrated here.

The auditable camera <NUM> also includes an optional long-range wireless interface <NUM> and an optional short-range wireless interface <NUM>. The long-range wireless interface <NUM> may use any suitable networking technology capable of establishing a wireless data connection to the evidence management system <NUM> from the auditable camera <NUM> from any geographical area, including but not limited to <NUM>, <NUM>, LTE, and/or the like. The short-range wireless interface <NUM> may use any suitable wireless networking technology capable of establishing a wireless data connection to the coordinator computing device <NUM> when within range of the coordinator computing device <NUM>, including but not limited to Bluetooth, ZigBee, NFC, and/or the like. These wireless interfaces are illustrated as optional, because some embodiments may be missing one or both interfaces. For example, in some embodiments, the only communication performed by the auditable camera <NUM> may be through the physical dock interface <NUM>. As another example, in some embodiments only the short-range wireless interface <NUM> may be present, and so the auditable camera <NUM> may only be able to communicate with the evidence management system <NUM> via the physical dock interface <NUM> or via the short-range wireless interface <NUM> through the coordinator computing device <NUM>.

Though <FIG> illustrates components of a camera, one of ordinary skill in the art will recognize that, other than the components that make the device a camera such as the video sensor <NUM>, audio sensor <NUM>, and the associated data stores, similar components may be included in an auditable weapon <NUM> or an auditable device of some other type.

<FIG> is a block diagram that illustrates an exemplary embodiment of a coordinator computing device according to various aspects of the present disclosure. As illustrated, the coordinator computing device <NUM>, which as stated above may be a smart phone or any other suitable computing device, includes a short-range wireless interface <NUM>, a long-range wireless interface <NUM>, and a GPS sensor <NUM>. The short-range wireless interface <NUM> is configured to allow the components of the coordinator computing device <NUM> to communicate with the other nearby components of the system <NUM> when they are within range, including auditable devices such as the auditable camera <NUM> and the auditable weapon <NUM> and the light bar sensor <NUM> of the vehicle <NUM>. The short-range wireless interface <NUM> may use one or more short-range wireless networking technologies such as those discussed above with respect to the auditable camera <NUM> in order to provide these communication paths. The long-range wireless interface <NUM> is configured to allow the coordinator computing device <NUM> to communicate data with the evidence management system <NUM> as long as the coordinator computing device <NUM> is within a service area of a corresponding long-range wireless data service, such as <NUM>, <NUM>, LTE, and/or the like. The GPS sensor <NUM> is configured to obtain a geographic position of the coordinator computing device <NUM> using satellite signals, triangulation of cellular phone towers, or any other technique known to one of ordinary skill in the art.

The coordinator computing device <NUM> also includes one or more user interface devices <NUM>, a user interface engine <NUM>, an auditable device communication engine <NUM>, and a system communication engine <NUM>. The one or more user interface devices <NUM> may include, but are not limited to, physical buttons, status lights, a display, a touch-screen display, a loudspeaker, and/or the like. The user interface engine <NUM> is configured to present an interactive interface to the user <NUM> and receive input from the user <NUM> via the user interface devices <NUM>. The interactive interface may allow the user <NUM> to control the auditable devices, add information to auditable events, generate auditable events, manually initiate an upload of urgent auditable events to the evidence management system <NUM>, and/or take other actions within the system <NUM>. The auditable device communication engine <NUM> manages communication with the auditable devices via the short-range wireless interface <NUM>, and the system communication engine <NUM> manages communication with the evidence management system <NUM>. Further details of the functionality of the components of the coordinator computing device <NUM> are provided below.

<FIG> is a block diagram that illustrates an exemplary embodiment of an evidence management system according to various aspects of the present disclosure. In some embodiments, the evidence management system <NUM> comprises a plurality of computing devices configured to provide the illustrated components, though they are described as a single system for clarity. One of ordinary skill in the art will recognize that any suitable server system, such as a single server, a server farm, a cloud service, and/or the like, may be used to provide the functionality of the evidence management system <NUM>.

As illustrated, the evidence management system <NUM> includes a computer aided dispatch system interface <NUM>, a records management system interface <NUM>, and a network interface <NUM>. The computer-aided dispatch system interface <NUM> enables the evidence management system <NUM> to communicate with one or more computer aided dispatch (CAD) systems <NUM> operated by other parties. This communication allows the evidence management system <NUM> to automatically import information from the CAD systems <NUM>, such as incident codes, user <NUM> or vehicle <NUM> locations at given times, and/or the like. This information may then be correlated with or otherwise used to enhance information received from auditable devices. The records management system interface <NUM> enables the evidence management system <NUM> to communicate with one or more records management systems <NUM> operated by other parties. This communication likewise allows the evidence management system <NUM> to automatically import information such as case numbers and/or the like. The records management system interface <NUM> may also provide information from the evidence management system <NUM> back to the records management systems <NUM>, including but not limited to links to data stored in the video data store <NUM>, the audio data store <NUM>, and/or the audit trail data store <NUM>; copies of audit trail information stored in the audit trail data store <NUM>; and/or the like.

The evidence management system <NUM> also includes an auditable device data store <NUM>, a video data store <NUM>, an audio data store <NUM>, and an audit trail data store <NUM>. The auditable device data store <NUM> may be configured to store information associated with each of the auditable devices of the system <NUM>. For example, for a given auditable camera <NUM>, the auditable device data store <NUM> may store information such as a unique device identifier, an identifier (such as a badge number or the like) of a user <NUM> associated with the auditable camera <NUM> at a given time or date, capabilities of the auditable camera <NUM>, and/or the like. The video data store <NUM> and audio data store <NUM> are configured to store data captured by one or more auditable cameras <NUM> or other devices that can capture audio and/or video data and are enrolled with the system <NUM>. In some embodiments, the video data store <NUM> and audio data store <NUM> are merged into a single data store, and audio and video data that are recorded contemporaneously may be stored together in a single file. The audit trail data store <NUM> stores records of auditable events detected by the auditable devices of the system <NUM>, as described further below.

The evidence management system <NUM> also includes a data gathering engine <NUM> and a user interface engine <NUM>. The data gathering engine <NUM> is configured to receive audit trail information, video data, and audio data from the auditable devices via the evidence collection dock <NUM> and the coordinator computing device <NUM>. The user interface engine <NUM> is configured to generate and present user interfaces for displaying and interacting with the data collected by the evidence management system <NUM> via web pages, application programming interfaces, or any other suitable technology. Each of the interfaces and engines of the evidence management system <NUM> is configured to use a network interface <NUM> for communication with other components of the system <NUM> via the Internet. Further description of the actions taken by the components of the evidence management system <NUM> is provided below.

<FIG> are a flowchart that illustrates an exemplary embodiment of a method of auditing camera activity according to various aspects of the present disclosure. One of ordinary skill in the art will recognize that, although a method of auditing camera activity is illustrated and described, other devices that detect events (such as the auditable weapon <NUM>, the light bar sensor <NUM>, and/or the like) could also be audited using a similar method, though for such devices the actions relating to transfer of video and/or audio data may not be performed.

From a start block, the method <NUM> proceeds to block <NUM>, where an audit trail gathering engine <NUM> of an auditable camera <NUM> detects a disconnection of the auditable camera <NUM> from a physical dock interface <NUM>. In some embodiments, when the physical dock interface <NUM> is electrically disconnected from the evidence collection dock <NUM>, the physical dock interface <NUM> transmits a signal to the audit trail gathering engine <NUM> to notify it of the disconnection event. Next, at block <NUM>, the audit trail gathering engine <NUM> creates an auditable event entry in an audit trail data store <NUM> of the auditable camera <NUM> indicating that the auditable camera <NUM> has been undocked.

In some embodiments, particularly where the user <NUM> is a law enforcement official, the undocking auditable event entry may indicate the start of a shift and the related start of auditing activities related to that shift. In some embodiments, the audit trail data store <NUM> may have been emptied after the previously recorded information was transmitted to the evidence management system <NUM> (as described further below), so at this point, the auditable event entry indicating the start of shift may be the only auditable event entry in the audit trail data store <NUM>.

The method <NUM> then proceeds to block <NUM>, where the audit trail gathering engine <NUM> receives a signal indicating an auditable event. The signal may be received from another component of the auditable camera <NUM>, such as the camera control engine <NUM>, the battery sensor <NUM>, a physical user interface device <NUM>, the physical dock interface <NUM>, or any other component. The signal may indicate any of a wide variety of auditable events. These events include, but are not limited to: a start recording event, a stop recording event, a pause recording event, a button press event, a battery or other hardware fault, a battery charge status threshold event, a storage error, a free storage threshold event, an interaction or connection status change via a wireless interface, an interaction or connection status change via the physical dock interface <NUM>, a physical motion event, a lack-of-physical motion event (i.e., the auditable camera <NUM> has remained stationary for a given amount of time, an environmental event such as a change in environmental temperature or humidity past a threshold value, a geofence event, a drop event, and a debug event.

At block <NUM>, the audit trail gathering engine <NUM> creates an auditable event entry in the audit trail data store <NUM>. In some embodiments, the auditable event entry includes information that identifies the type of the event (such as a numeric event type identifier, an event type string, and/or the like), and may include further information associated with the event. As several non-limiting examples, a hardware fault auditable event entry may include a fault type and a fault code; a start recording event may include camera settings such as exposure, F-stop, frame rate, and/or the like; a battery fault event may also indicate the type of battery fault; and so on. In some embodiments, the audit trail gathering engine <NUM> may actively obtain other information to include in the auditable event entry that cannot be derived solely from information included in the signal. As several non-limiting examples, the audit trail gathering engine <NUM> may itself obtain a timestamp from the clock <NUM> to be included in the auditable event entry; the audit trail gathering engine <NUM> may use the short-range wireless interface <NUM> to obtain GPS information or user-entered metadata from the coordinator computing device <NUM> to be included in the auditable event entry; and so on.

At optional block <NUM>, data associated with the event obtained by one or more sensors of the auditable camera <NUM> is stored in one or more data stores <NUM>, <NUM> of the auditable camera <NUM> and is associated with the auditable event entry. For example, if the event is a start recording event, then data obtained by the camera control engine <NUM> from the video sensor <NUM> may be stored in the video data store <NUM>, and/or data obtained by the camera control engine <NUM> from the audio sensor <NUM> may be stored in the audio data store <NUM>. To associate the stored data with the auditable event entry, a unique identifier of the auditable event entry may be stored along with the video or audio data, and/or a unique identifier of the video and/or audio data may be stored in the auditable event entry. The actions described with respect to block <NUM> are optional because some events, like battery faults, may not be related to the recording of data to be stored in one of the data stores <NUM>, <NUM>.

At block <NUM>, an audit trail signing engine <NUM> of the auditable camera <NUM> applies a digital signature to the auditable event entry. In some embodiments, applying the digital signature uses a cryptographic hash to guarantee that the auditable event entry has not been altered or corrupted since being signed. For example, in one non-limiting embodiment, the evidence management system <NUM> may assign a private key to the auditable camera <NUM>, which is stored in the certificate data store <NUM> when the auditable camera <NUM> is connected via the physical dock interface <NUM>. The private key is used by the audit trail signing engine <NUM> to create a cryptographic hash of the auditable event entry, which is then added to the auditable event entry to sign it. Subsequently, a public key made available by the evidence management system <NUM> may be used to verify that the auditable event entry has not been tampered with since it was signed. In some embodiments, the cryptographic hash may be stored elsewhere, such as in the certificate data store <NUM>, and may simply be associated with the auditable event entry instead of being added to it. In some embodiments, the audit trail signing engine <NUM> may sign the data stored in the video data store <NUM> and the audio data store <NUM> using a similar technique. In some embodiments, the signatures generated for the video and/or audio data may be added to the auditable event entry before the auditable event entry is signed. In some embodiments, some other suitable technique for applying digital signatures that ensure that data has not been altered or corrupted is used instead of the technique described above.

In some embodiments, the actions described with respect to block <NUM> may be performed in response to the creation of the auditable event entry as is illustrated. In some embodiments, the actions described with respect to block <NUM> may instead be performed later, such as in response to a request to transmit the auditable event entry to the evidence management system <NUM>. Waiting to apply the signature until shortly before upload may help to conserve battery life, as the signature processing for much of the information could be deferred until the auditable camera <NUM> is coupled to the evidence collection dock <NUM> and is therefore receiving power.

One will note that, if the identifier or signature of the video data and/or audio data is stored in the auditable event entry before the signature is applied to the auditable event entry, then the signatures ensure that the auditable event entry cannot be tampered with to refer to a different video and the video/audio data cannot be replaced without invalidating the signatures. Accordingly, the technical problem of how to irrefutably associate recorded videos with a lightweight log of actions performed by an auditable camera <NUM> despite intermittent connectivity can be overcome.

At this point in the method <NUM>, the storage of the auditable event entry in the audit trail data store <NUM> is complete. In most cases, the method <NUM> would then loop back and wait for a subsequent auditable event, though there are two special cases where the method <NUM> would either perform additional processing or exit the loop instead of simply looping back. Accordingly, the method <NUM> proceeds to a decision block <NUM>, where a determination is made regarding whether the auditable event indicated that the auditable camera <NUM> was placed in an evidence collection dock <NUM>. As with the disconnection event described above with respect to block <NUM>, this may be detected by an electrical connection being made via the physical dock interface <NUM>, and a signal being provided by the physical dock interface <NUM> to the audit trail gathering engine <NUM> accordingly. If the result of the determination at decision block <NUM> is YES, then the method <NUM> proceeds to a continuation terminal ("terminal B").

From terminal B (<FIG>), the method <NUM> proceeds to block <NUM>, where the audit trail reporting engine <NUM> transmits contents of the audit trail data store <NUM> to the data gathering engine <NUM> of the evidence management system <NUM> via the physical dock interface <NUM> and the evidence collection dock <NUM>. In some embodiments, the evidence collection dock <NUM> may include a memory, a processor, and networking hardware that are configured to enable the evidence collection dock <NUM> to download the contents of the audit trail data store <NUM> from the auditable camera <NUM> and to subsequently upload the contents to the data gathering engine <NUM> via the network <NUM> using any suitable data transmission technique.

At block <NUM>, in response to receiving an acknowledgement receipt from the evidence management system <NUM>, the audit trail gathering engine <NUM> clears the contents of the audit trail data store <NUM>. Waiting for the acknowledgement receipt ensures that the audit trail data was received by the evidence management system <NUM> and was stored successfully before it is cleared from the auditable camera <NUM>. In some embodiments, the evidence management system <NUM> may provide one acknowledgement receipt for the entire contents of the audit trail data store <NUM>. In some embodiments, the evidence management system <NUM> may provide acknowledgement receipts for subsets of the uploaded data. For example, data may be uploaded in chronological order from the audit trail data store <NUM>, and the evidence management system <NUM> transmits an acknowledgement receipt for each individual piece of content. Subsequently, each piece of content would be deleted from the auditable camera <NUM> once its corresponding acknowledgement receipt is received. Such an embodiment would allow an upload to be interrupted and the auditable camera <NUM> to be reused without losing any of the data already stored on the auditable camera <NUM>.

At optional block <NUM>, the auditable camera <NUM> transmits contents of other data stores of the auditable camera <NUM> to the evidence management system <NUM> via the physical dock interface <NUM>. For example, the auditable camera <NUM> may transmit the data from the video data store <NUM> and/or the audio data store <NUM>, if any, to the evidence management system <NUM>. The actions associated with block <NUM> are described as optional, because in some embodiments, there might not be any such data, particularly if the method <NUM> is being used with an auditable device other than an auditable camera <NUM>, such as an auditable weapon <NUM>. In some embodiments, the actions of block <NUM> may happen before (or contemporaneously with) the actions of block <NUM>. In some embodiments, an acknowledgement receipt may be generated by the evidence management system <NUM> for the video/audio data as well, and receiving the acknowledgement receipt may cause the auditable camera <NUM> to delete its copy of the transferred audio/video data. The method <NUM> then proceeds to an end block and terminates.

Returning to decision block <NUM> (<FIG>), if the result of the determination regarding whether the event indicates that the auditable camera <NUM> has been connected to a physical dock is NO, then the method <NUM> proceeds to another decision block <NUM>, where a determination is made regarding whether the auditable event is an urgent event. An urgent event is an auditable event for which the system <NUM> is configured to ensure that the evidence management system <NUM> is made aware of as soon as possible, even before the auditable device is returned to the evidence collection dock <NUM>. This functionality is useful to ensure that, for urgent events, the associated data is eventually uploaded to the evidence management system <NUM> and is not instead forgotten. One example of an urgent event may be a start recording event, and an example of a non-urgent event may be a battery fault event. If the system <NUM> is configured to consider a start recording event to be an urgent event, then the evidence management system <NUM> will be notified each time a recording is started with an auditable camera <NUM>, even if the associated video and/or audio is not uploaded to the evidence management system <NUM>. This information can be used in many ways, including prompting the user <NUM> to dock the auditable camera <NUM> in order to upload the missing video, providing a data trail indicating that all relevant videos for an incident or during a given time period were uploaded, and/or the like.

If the result of the determination at decision block <NUM> is NO and the auditable event is not an urgent event, then the method <NUM> proceeds to a continuation terminal ("terminal A"), and from terminal A returns to block <NUM> upon the receipt of a subsequent signal indicating an auditable event. Otherwise, if the result of the determination at decision block <NUM> is YES and the auditable event is an urgent event, then the method <NUM> proceeds to another continuation terminal ("terminal C").

From terminal C (<FIG>), the method <NUM> proceeds to block <NUM>, where an audit trail reporting engine <NUM> of the auditable camera <NUM> initiates a connection to a coordinator computing device <NUM> via a short-range wireless interface <NUM> of the auditable camera <NUM>. In some embodiments, the audit trail reporting engine <NUM> uses the short-range wireless interface <NUM> to establish a wireless connection to the coordinator computing device <NUM>. In some embodiments, the wireless connection to the coordinator computing device <NUM> may already be available, and the audit trail reporting engine <NUM> just uses the existing connection.

At block <NUM>, the audit trail reporting engine <NUM> transmits the auditable event entry to the coordinator computing device <NUM> via the short-range wireless interface <NUM>. Next, at block <NUM>, the coordinator computing device <NUM> transmits the auditable event entry to a data gathering engine <NUM> of an evidence management system <NUM> via a long-range wireless interface <NUM> of the coordinator computing device <NUM>.

In some embodiments, one or more of the actions described in blocks <NUM>-<NUM> may be performed when an opportunity arises to do so, if the actions cannot be performed immediately. For example, upon detecting the urgent event, the auditable camera <NUM> may not be within short-range wireless communication range of the coordinator computing device <NUM>. In such a case, the audit trail reporting engine <NUM> may wait for a notification from the short-range wireless interface <NUM> that it has returned within range before proceeding. An example of this case would be if the user <NUM> leaves the vehicle <NUM>, and the coordinator computing device <NUM> is left within the vehicle <NUM>. The communication channel to the coordinator computing device <NUM> would be opened once the user <NUM> returned to the vehicle <NUM>, or to a location near enough to the vehicle <NUM> to be within short-range wireless communication range. As another example, in some embodiments, the long-range wireless interface <NUM> of the coordinator computing device <NUM> could be <NUM>, <NUM>, LTE, or another wireless network with broad geographic coverage such that the coordinator computing device <NUM> would usually remain connected to the evidence management system <NUM>. However, even with road geographic coverage, the user <NUM> may take the coordinator computing device <NUM> through an area without wireless data coverage (such as a tunnel, a valley, a parking garage, and/or the like), or may use a long-range wireless technology with more limited connection range or geographic coverage (such as WiFi). In such limited connectivity environments, the coordinator computing device <NUM> may receive and store the auditable event entry from the auditable camera <NUM>, and transmit it to the evidence management system <NUM> once a data connection becomes available via the long-range wireless interface <NUM>.

The method <NUM> then proceeds to terminal A. One of ordinary skill in the art will recognize that the actions described in blocks <NUM>-<NUM> are not blocking steps. Instead, the method <NUM> may return to terminal A upon receiving a signal indicating an auditable event (as described in block <NUM>) even while the actions described in blocks <NUM>-<NUM> are being executed (or are awaiting execution).

<FIG> is a flowchart that illustrates an exemplary embodiment of a method of managing collected audit trail data according to various aspects of the present disclosure. From a start block, the method <NUM> proceeds to block <NUM>, where a data gathering engine <NUM> of an evidence management system <NUM> receives one or more auditable event entries generated by an auditable device such as an auditable camera <NUM>, an auditable weapon <NUM>, and/or the like. The auditable event entries may be received via the evidence collection dock <NUM> as described in blocks <NUM><NUM> of the method <NUM>, or could be received via the coordinator computing device <NUM> as described in blocks <NUM>-<NUM> of the method <NUM>.

At block <NUM>, the data gathering engine <NUM> stores the auditable event entries in an audit trail data store <NUM> of the evidence management system <NUM>. At block <NUM>, the data gathering engine <NUM> receives one or more device data files generated by the auditable device, and stores them in one or more device data stores of the evidence management system <NUM>. For example, video data may be stored in a video data store <NUM>, and audio data may be stored in an audio data store <NUM>. In some embodiments, the video data and audio data may be stored in the same data store. In some embodiments, data in the video data store <NUM> and in the audio data store <NUM> may be stored separately, but may include links or other associations to each other so that may be treated as a single unit. The device data files may be received using actions such as those described in block <NUM> of the method <NUM>.

At block <NUM>, the data gathering engine <NUM> determines one or more auditable event entries from the audit trail data store <NUM> that should have matching device data files in the device data stores but do not. For example, an urgent event may have been received and stored in the audit trail data store <NUM> indicating a start recording event, but no video file associated with the event is found in the video data store <NUM>. This determination can help find situations where vital evidence is missing but could still be uploaded. This determination can also provide proof that all existing videos associated with an auditable camera <NUM> are present within the evidence management system <NUM>. At block <NUM>, a user interface engine <NUM> of the evidence management system <NUM> generates alerts based on auditable event entries having missing matching device data files. These auditable event entries are those found in the block <NUM>. In some embodiments, the alerts may include email or text message upload reminders sent to the user <NUM> associated with the appropriate auditable device, or to the user's supervisor. In some embodiments, the alerts may include a report presented as a web page (or in another format) of all missing device data files for a group of devices or for a period of time.

At block <NUM>, the user interface engine <NUM> retrieves information from a records management system <NUM> describing an incident and generates a timeline presentation of auditable events associated with the incident. The information about the incident may include, but is not limited to: a start time and an end time of the incident; one or more geographic locations associated with the incident; one or more users <NUM> associated with the incident; and one or more auditable devices associated with said users <NUM>. The information about the incident may be used to find relevant auditable event entries in the audit trail data store <NUM>. The user interface engine <NUM> queries the audit trail data store <NUM> to find the relevant auditable event entries, and places indications of the auditable events on the timeline. In the timeline presentation, interacting with an auditable event indication or a portion of the timeline (such as clicking or tapping on the indication or a portion of the timeline) may cause data associated with the auditable event, such as event detail information, and/or associated data stored in the video data store <NUM> and/or the audio data store <NUM> to be presented.

At block <NUM>, the user interface engine <NUM> generates one or more alerts based on auditable event entries from the audit trail data store <NUM> that indicate errors with an auditable device. In some embodiments, the alerts could be an email or SMS message transmitted to the user <NUM> associated with the auditable device. In some embodiments, the alerts could be displayed in a summary list of errors from all devices managed by a given technical support professional or a given agency. In some embodiments, the auditable device data store <NUM> may be queried to determine a location or contact information of the associated user <NUM> in order to deliver the alert.

At block <NUM>, the user interface engine <NUM> generates a summary presentation of auditable events that indicate errors across multiple auditable devices of a matching type. For example, a summary presentation may present all battery faults for all auditable cameras, regardless of user. This summary presentation may be presented to information technology management at the agency operating the auditable devices, or may be aggregated for multiple agencies and viewed by the proprietor of the evidence management system <NUM> and/or the developer of the auditable devices to improve engineering processes or to update future versions of the auditable devices.

The method <NUM> then proceeds to an end block and terminates. One of ordinary skill in the art will recognize that the steps of method <NUM> are presented as ordered for sake of discussion only. In some embodiments, the steps may be performed in any order, repeatedly, in parallel, and/or the like. Though it is clear that the data gathering steps would happen at some point before the presentation steps happen for the first time, it is still possible that the presentation steps could happen multiple times for a single execution of the data gathering step, or that the data gathering steps could happen without the presentation steps occurring.

<FIG> is a block diagram that illustrates aspects of an exemplary computing device <NUM> appropriate for use as a computing device of the present disclosure. While multiple different types of computing devices were discussed above, the exemplary computing device <NUM> describes various elements that are common to many different types of computing devices. While <FIG> is described with reference to a computing device that is implemented as a device on a network, the description below is applicable to servers, personal computers, mobile phones, smart phones, tablet computers, embedded computing devices, and other devices that may be used to implement portions of embodiments of the present disclosure. Moreover, those of ordinary skill in the art and others will recognize that the computing device <NUM> may be any one of any number of currently available or yet to be developed devices.

In its most basic configuration, the computing device <NUM> includes at least one processor <NUM> and a system memory <NUM> connected by a communication bus <NUM>. Depending on the exact configuration and type of device, the system memory <NUM> may be volatile or nonvolatile memory, such as read only memory ("ROM"), random access memory ("RAM"), EEPROM, flash memory, or similar memory technology. Those of ordinary skill in the art and others will recognize that system memory <NUM> typically stores data and/or program modules that are immediately accessible to and/or currently being operated on by the processor <NUM>. In this regard, the processor <NUM> may serve as a computational center of the computing device <NUM> by supporting the execution of instructions.

As further illustrated in <FIG>, the computing device <NUM> may include a network interface <NUM> comprising one or more components for communicating with other devices over a network. Embodiments of the present disclosure may access basic services that utilize the network interface <NUM> to perform communications using common network protocols. The network interface <NUM> may also include a wireless network interface configured to communicate via one or more wireless communication protocols, such as WiFi, <NUM>, <NUM>, LTE, WiMAX, Bluetooth, and/or the like. As will be appreciated by one of ordinary skill in the art, the network interface <NUM> illustrated in <FIG> may represent one or more wireless interfaces or physical communication interfaces described and illustrated above with respect to particular components of the system <NUM>.

In the exemplary embodiment depicted in <FIG>, the computing device <NUM> also includes a storage medium <NUM>. However, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Therefore, the storage medium <NUM> depicted in <FIG> is represented with a dashed line to indicate that the storage medium <NUM> is optional. In any event, the storage medium <NUM> may be volatile or nonvolatile, removable or nonremovable, implemented using any technology capable of storing information such as, but not limited to, a hard drive, solid state drive, CD ROM, DVD, or other disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, and/or the like.

As used herein, the term "computer readable medium" includes volatile and non volatile and removable and non removable media implemented in any method or technology capable of storing information, such as computer readable instructions, data structures, program modules, or other data. In this regard, the system memory <NUM> and storage medium <NUM> depicted in <FIG> are merely examples of computer readable media.

Suitable implementations of computing devices that include a processor <NUM>, system memory <NUM>, communication bus <NUM>, storage medium <NUM>, and network interface <NUM> are known and commercially available. For ease of illustration and because it is not important for an understanding of the claimed subject matter, <FIG> does not show some of the typical components of many computing devices. In this regard, the computing device <NUM> may include input devices, such as a keyboard, keypad, mouse, microphone, touch input device, touch screen, tablet, and/or the like. Such input devices may be coupled to the computing device <NUM> by wired or wireless connections including RF, infrared, serial, parallel, Bluetooth, USB, or other suitable connections protocols using wireless or physical connections. Similarly, the computing device <NUM> may also include output devices such as a display, speakers, printer, etc. Since these devices are well known in the art, they are not illustrated or described further herein.

While illustrative embodiments have been illustrated and described, it will be appreciated that various changes can be made therein without departing from the scope of the invention, which is defined in the appended claims.

Claim 1:
An auditable camera (<NUM>), comprising:
a video sensor (<NUM>);
a video data store (<NUM>) configured to store video data generated by the video sensor (<NUM>);
an audit trail signing engine (<NUM>), an audit trail gathering engine (<NUM>), an audit trail reporting engine (<NUM>), an audit trail data store (<NUM>) configured to store records of auditable events as a set of auditable event entries; and a certificate data store (<NUM>) configured to store one or more digital signing certificates; the audit trail gathering engine (<NUM>) configured to receive reports of the auditable events from other components of the auditable camera (<NUM>) and to record the auditable event entries in the audit trail data store (<NUM>), wherein the auditable events include at least one of a battery or other hardware fault, a battery charge status threshold event, a storage error, a free storage threshold event, an interaction or connection status change via a wireless interface (<NUM>), an interaction or connection status change via a physical dock interface (<NUM>); a lack-of-physical motion event, a drop event, or a debug event; the auditable event entries represent the auditable events and are recorded by the audit trail gathering engine (<NUM>) in response to receiving the reports of the auditable events; the auditable event entries include information that identifies a type of the event; the audit trail signing engine (<NUM>) configured to apply digital signatures using the digital signing certificates in the certificate data store (<NUM>) to auditable event entries in the audit trail data store (<NUM>), and
the audit trail reporting engine (<NUM>) configured to:
transmit one or more auditable event entries from the audit trail data store (<NUM>) to an evidence management system (<NUM>).