WO2016033523A1

WO2016033523A1 - Compact multi-function dvr with multiple integrated wireless data communication devices

Info

Publication number: WO2016033523A1
Application number: PCT/US2015/047532
Authority: WO
Inventors: Hung C. CHANG; Terry Wayne BOYKIN; Allan Chen; Yun Long TAN
Original assignee: Coban Technologies, Inc.
Priority date: 2014-08-29
Filing date: 2015-08-28
Publication date: 2016-03-03

Abstract

A device for mobile video surveillance recording, methods for using the device, and methods for managing information obtained (e.g., recorded) by the device is disclosed. This disclosure also relates to a surveillance device configured for use by a law enforcement agency and methods of use that satisfy evidentiary requirements. Evidentiary requirements may include maintaining strict integrity of information collected by the surveillance device and comprehensive audit tracking regarding access to, or modification of, the collected information. The device of this disclosure may comprise multiple functional modules incorporated into a single comprehensive form factor (e.g., enclosure, casing) with minimal external cabling and installation requirements. The single comprehensive form factor may facilitate maintenance and/or replacement, as needed.

Description

COMPACT MULTI-FUNCTION PVR WITH MULTIPLE INTEGRATED WIRELESS

DATA COMMUNICATION DEVICES

Inventors: Hung C. Chang, Terry Wayne Boykin, Allan Chen, and Yun Long Tan

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of the filing date of U.S. provisional patent application number 62/044,139 filed on August 29, 2014, U.S. patent application number 14/588,139, filed on December 31, 2014, U.S. patent application number 14/593,722, filed on January 9, 2015, U.S. patent application number 14/686,192, filed on April 14, 2015, U.S. patent application number 14/715,742, filed on May 19, 2015, U.S. patent application number 14/593,853, filed on January 9, 2015, and U.S. patent application number 14/593,956, filed on January 9, 2015, by the same inventors of this application, and all incorporated herein by reference.

FIELD OF THE INVENTION

[0002] This disclosure relates generally to a device for mobile video surveillance recording, methods for using the device, and methods for managing information obtained (e.g., recorded) by the device. More particularly, but not by way of limitation, this disclosure relates to a surveillance device configured for use by a law enforcement agency. This disclosure also pertains to methods of use that satisfy evidentiary requirements. Evidentiary requirements include maintaining strict integrity of any information collected by the surveillance device and comprehensive audit tracking regarding access to and/or modification of the collected information.

BACKGROUND

[0003] Today's law enforcement agencies are increasing their use of digital data to collect surveillance information and other forms of data to be used as evidence in legal proceedings. Devices and methods for managing multi-media files collected as part of this surveillance and evidence collection are increasing over time. Multi-media files may be large. For example, a video or audio file may easily be megabytes in size depending on the length of the recording. Video files are typically larger than audio files and they become larger based on the resolution of the video recording. That is, higher resolution video files typically require larger file sizes than either audio or lower resolution video because of current audio and video compression techniques. Video files are also typically larger than corresponding audio files because they include more data than an audio recording. . As used in law enforcement and other industries that require secure access, multi -media files have traditionally been burned onto Digital Versatile Disks (DVDs) or other high capacity storage medium such that the physical media may be transported to another location in a secure manner.

[0004] Metadata associated with either audio recordings or video recordings is a relatively small amount of data compared to the audio or video data. However, today's systems typically embed the metadata as part of the audio or video data file such that access to the metadata requires access to the potentially large multi-media file. Also, most access programs require an entire file to understand the structure and content of the file itself. Accordingly, to access any metadata associated with a typical multi-media file, one must have complete access to the entire multi-media file.

[0005] Traditional law-enforcement video solutions typically offer a way to export videos onto optical media such as DVDs and distribute the recorded media to third parties. Third parties typically include other parties to a particular legal proceeding or investigation. Third parties may include the district attorney, defendants, other attorneys, other law enforcement agencies, and so on. For a large agency, creation of optical media may involve expensive equipment (e.g., disc burning and duplication machines) as well as material costs. Technical personnel may also be required to maintain and operate that equipment. Further, once a media is burned into a physical copy, security pertaining to access to that physical copy may be a labor intensive undertaking for law-enforcement employees.

[0006] Accordingly, systems and methods for hidden storage drives, self-contained storage devices for self-contained application execution, shared server, hybrid, and cloud-based storage, access and security, portable recording apparatuses (e.g., camera, wireless programmable microphone) which may be integrated with a surveillance system, and the like systems and methods, as disclosed herein, may provide alternatives to previously known systems and methods of managing, storing, securing, and providing access to evidentiary information while conforming to special requirements associated with such information, and the like tasks. It will be understood by one of ordinary skill in the art upon reading this disclosure that systems and methods disclosed herein may also address additional issues other than those mentioned above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] It being understood that the figures presented herein should not be deemed to limit or define the subject matter claimed herein, the applicants' disclosure may be understood by reference to the following description taken in conjunction with the accompanying drawings, in which like reference numerals identify like elements.

[0008] Figures 1A-B illustrate a rear view and a front view, respectively, of a device according to some disclosed embodiments.

[0009] Figures 2A-C illustrates block diagrams of a processing system and two example removable storage devices that may be used for the disclosed integrated mobile surveillance system and to practice the disclosed process of multiply recording selected information according to some disclosed embodiments.

[0010] Figure 3 illustrates a block system diagram showing some additional internal components for the device of Figures 1A-B, according to some disclosed embodiments.

[0011] Figure 4 illustrates a method of recording information from a plurality of cameras to a buffer memory simultaneously according to some disclosed embodiments. The method further comprises, storing all captured data to a continuous loop storage area while selectively storing segments of captured data to an event recording storage area.

[0012] Figure 5 illustrates a flow chart for secure access to a removable secure storage drive according to some disclosed embodiments.

[0013] Figure 6 illustrates a flow chart for one possible implementation of dual factor authentication, according to some disclosed embodiments.

[0014] Figure 7 illustrates a block hardware diagram illustrating additional/alternative internal components for (and additional external devices configured to communicate with) the device of Figures 1 A-B, according to some disclosed embodiments. [0015] Figures 8-9 each illustrate a block diagram for alternative embodiments of the device of Figures 1A-B, according to some disclosed embodiments.

[0016] Figure 10 illustrates possible data flow and software as a service (SAAS) components according to some disclosed embodiments.

[0017] Figure 11 illustrates a flow chart depicting one possible process for data mining of information collected by a plurality of surveillance systems according to some disclosed embodiments.

[0018] Figures 12A-F illustrate excerpts of metadata files using extensible Markup Language (XML) for the data format, according to some disclosed embodiments.

[0019] Figure 13 illustrates, in diagram 1300, one possible embodiment to have a plurality of devices using cross connectivity amongst each end device and to an integrated system to perform some of the disclosed embodiments.

[0020] Figures 14A-B illustrate examples of removable plug-in storage drives which may be adapted for data integrity according to some disclosed embodiments.

[0021] Figures 15A-B illustrate examples of removable plug-in storage drives including enhanced firmware for data security and integrity according to some disclosed embodiments.

[0022] Figure 16 illustrates a block diagram depicting a representation of a computer device using a layered model according to some disclosed embodiments.

[0023] Figure 17 illustrates a possible process flow to configure a computer device and a removable secure storage drive according to some disclosed embodiments.

[0024] Figure 18 illustrates a possible process flow to pre-configure a suite of applications for "self-contained" execution from a storage device according to some disclosed embodiments.

[0025] Figure 19A illustrates one possible process flow for installation of one or more computer applications for execution on a computer system

[0026] Figure 19B illustrates an alternative process flow illustrating that installation of applications may be bypassed using a self-contained storage device according to some disclosed embodiments.

[0027] Figure 20 illustrates a possible process flow for automatically updating firmware and/or software portions of a computer device prior to execution of applications from a "self- contained" removable storage device according to some disclosed embodiments. [0028] Figures 21A-C illustrate different views of one possible embodiment for a portable body worn camera according to some disclosed embodiments.

[0029] Figure 22 illustrates an intelligent docking, upload, and charging station for battery packs and portable body worn cameras according to some disclosed embodiments.

[0030] Figure 23 illustrates a possible process flow to "checkout" a portable device (e.g., body worn camera) including a storage device (possibly a secure storage drive), where the portable device may be used by specific law enforcement personnel for the duration of checkout and assist in chain of custody procedures according to some disclosed embodiments.

[0031] Figures 24A-B illustrate different views of one possible embodiment for a portable wireless programmable microphone including internal storage according to some disclosed embodiments.

[0032] Figures 25 A-B illustrate a possible process flow to upload and manage information via a cloud-based storage area as may be used between law enforcement personnel and other related third parties. The illustrated process flow may assist in audit tracking and security requirements of the uploaded information according to some disclosed embodiments.

NOTATION AND NOMENCLATURE

[0033] Certain terms are used throughout the following description and claims to refer to particular system components and configurations. As one skilled in the art will appreciate, the same component may be referred to by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms "including" (and the like) and "comprising" (and the like) are used in an open-ended fashion, and thus should be interpreted to mean "including, but not limited to...." Also, the term "couple," "coupled," or "couples" is intended to mean either an indirect or direct electrical or mechanical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical or mechanical connection, or through an indirect electrical or mechanical connection via other devices and connections, or through inductive or capacitive coupling.

[0034] As used throughout this disclosure the terms "computer device" and "computer system" will both be used to refer to an apparatus that may be used in conjunction with disclosed embodiments. As used herein, a computer device may be thought of as having a subset of functionalities as compared to a computer system. That is, a computer device may refer to a special purpose processor-based device such as a digital video surveillance system primarily configured for executing a limited number of applications. A computer system may more generally refer to a general purpose computer such as a laptop, workstation, or server which may be configured by a user to run any number of off the shelf or specially designed software applications. Computer systems and computer devices will generally interact with elements and aspects of disclosed embodiments in the same or similar ways. It should be noted that a computer device may be configured with hardware that would only support a subset of all possible self-contained storage devices but would function properly in conjunction with a self- contained storage device that only utilized hardware available on that computer device.

[0035] This disclosure also refers to storage devices and storage drives interchangeably. In general, a storage device/drive represents a medium accessible by a computer to store data and executable instructions. Also, throughout this disclosure reference will be made to "plugging in" a storage drive. It is noted that "plugging in" a storage drive is just one way to connect a storage drive to a computer device/system. This disclosure is not intended to be limited to drives that physically "plug in," and disclosed embodiments are also applicable to devices that are "connected" to a computer device or computer system. For example, devices may be connected by using a cable or by connecting using a computer bus. Additionally, references to "removable" storage are analogous to plugging-in/unplugging a device, connecting/disconnecting cabled access to a device, and/or establishing/disconnecting networked access to a device or storage area on a network (either wired or wireless).

[0036] The terms "hidden" and "unhidden," when referring to a storage device, are used to describe accessibility of the storage device from a connected computer device or computer system. Hidden means that the operating system of the computer system cannot access, alter, or erase any data on the storage device, at least in part, because the operating system will be unaware of the existence of the storage device. Unhidden refers to a situation where a secure storage drive configured according to embodiments of this disclosure has been properly authenticated after connection to a computer system and is visible to the operating system of the computer system. Once "unhidden" the secure storage drive may interact with the operating system of the computer system in a standard manner until such time as the secure storage drive is disconnected. Upon being disconnected the secure storage drive may return to its default "hidden" state and remain inaccessible until it is again connected and "unhidden" via proper authentication.

[0037] This disclosure also refers to a "self-contained" storage device that is pre-configured with one or more applications such that the one or more applications may execute and interact with each other without requiring "installation" on a computer system. That is, the one or more applications are pre-configured for "self-contained" execution and do not require updates to a computer registry or installation of files prior to execution. Applications on a "self-contained" storage device may be pre-configured with referential pointers that are resolved at run-time to obtain access to required components or other applications for coordinated execution.

[0038] The disclosed "self-contained" storage device may be integrated or attached to a portable recording device/apparatus such as a body worn camera and/or programmable wireless microphone, and may allow for storage of data captured by the portable recording apparatus. Also, when connected to a computer device or computer system, program information stored on the storage device may be used to execute applications on the computer device or system via self-contained execution as described throughout this Specification. The terms "device" and "apparatus" are used interchangeably throughout this disclosure when referring to a device or apparatus incorporating the disclosed self-contained storage device.

[0039] The term "hybrid storage" is used in this disclosure to describe that data associated with accessing and managing multi-media files may be stored in a plurality of locations as opposed to a single location and not embedded within the multi-media file itself. For example, metadata files containing attributes of associated multi-media files, and/or data collected or maintained in association with multi-media files, may be stored remotely from the multi-media files themselves. Metadata files are typically considerably smaller in size than multi-media files. Thus, metadata files are more easily transferred across data links that may have limited bandwidth. As explained further below, hybrid storage may allow for searching and indexing of numerous multi-media files without requiring unnecessary transfer of the potentially large multimedia files (e.g., video/audio recordings). For simplicity the term "multi-media" will be used throughout this disclosure to refer to files collected (e.g., recorded) by an audio or audio/video recorder. Multi-media files may include only audio, only video, or audio and video together and the information may be compressed using an industry standard compression technology (e.g., Motion Picture Expert Group (MPEG) standards, Audio Video Interleave (AVI), etc.) or another proprietary compression or storage format. Multi-media files may have associated data files, including metadata files that may be configured in a structured text format such as extensible Markup Language (XML).

[0040] The term "recording circumstances" is used herein to describe that metadata information associated with an instance of a multi-media recording may contain information describing attributes associated with the act of actual recording of that multi-media file. That is, the metadata may describe who (e.g., Officer ID) or what (e.g., automatic trigger) initiated the recording. The metadata may also describe where the recording was made. For example, location may be obtained using global positioning system (GPS) information. The metadata may also describe why (e.g., event tag) the multi-media recording was made. In addition, the metadata may also describe when the recording was made using timestamp information obtained in association with GPS information or from an internal clock, for example. From these types of metadata, circumstances that caused the multi-media recording may provide more information about the multi-media recording. This metadata may include useful information to correlate multi-media recordings from multiple distinct surveillance systems. This type of correlation information, as described further below, may assist in many different functions (e.g., query, data retention, chain of custody, and so on).

[0041] The terms "cloud storage" or "cloud based storage" are used interchangeably in this disclosure to describe that data is stored in an area generally accessible across a network (which may or may not be the Internet). A "cloud" may refer to a public cloud, private cloud, or combination of a public and private cloud (e.g., hybrid cloud). The term "public cloud" generally refers to a cloud storage area that is maintained by an unrelated third party but still has certain security measures in place to ensure that access is only allowed to authorized users. The term "private cloud" generally refers to a cloud storage area that is maintained by a related entity or that is maintained on separate physical computer resources from any unrelated users.

[0042] As used herein, the term "evidentiary requirements" refers to one or more requirements required for data collected that may later be used as evidence in a legal proceeding. These requirements are discussed throughout this disclosure and include: chain of custody of evidence, access controls, audit functions, retention policies, and the like. The term "evidentiary controls" refers to controlling at least some of the discussed evidentiary requirements.

DETAILED DESCRIPTION OF DISCLOSED EMBODIMENTS

[0043] The foregoing description of the figures is provided for the convenience of the reader. It should be understood, however, that the embodiments are not limited to the precise arrangements and configurations shown in the figures. Also, the figures are not necessarily drawn to scale, and certain features may be shown exaggerated in scale or in generalized or schematic form, in the interest of clarity and conciseness. The same or similar parts may be marked with the same or similar reference numerals.

[0044] While various embodiments are described herein, it should be appreciated that the present disclosure encompasses many inventive concepts that may be embodied in a wide variety of contexts. The following detailed description of exemplary embodiments, read in conjunction with the accompanying drawings, is merely illustrative and is not to be taken as limiting the scope of the invention, as it would be impossible or impractical to include all of the possible embodiments and contexts of the invention in this disclosure. Upon reading this disclosure, many alternative embodiments of the present invention will be apparent to persons of ordinary skill in the art. The scope of the invention is defined by the appended claims and equivalents thereof.

[0045] Illustrative embodiments of the invention are described below. In the interest of clarity, not all features of an actual implementation for all disclosed embodiments are necessarily described in this specification. In the development of any such actual embodiment, numerous implementation-specific decisions may need to be made to achieve the design-specific goals, which may vary from one implementation to another. It will be appreciated that such a development effort, while possibly complex and time-consuming, would nevertheless be a routine undertaking for persons of ordinary skill in the art having the benefit of this disclosure.

[0046] Embodiments of the present disclosure provide for an integrated mobile surveillance system. The system may be configured to capture video, audio, and data parameters pertaining to activity in the vicinity of a police vehicle, for example. Other type of vehicles and other situations requiring a mobile surveillance unit are also within the scope of this disclosure. For example, if surveillance is required at a "temporary" venue such as a trade show, circus, concert tour stop, etc., the disclosed system may provide a convenience and capability not available from a fixed/permanent surveillance system. Further, in addition to police vehicles, other types of transports may benefit from the disclosed surveillance system. Other types of vehicles may include, but are not limited to, any transportation means that aid in law enforcement such as busses, ambulances, police motorcycles or bicycles, fire trucks, airplanes, boats, military vehicles, etc.

[0047] Mobile surveillance systems have been in use by police departments for the past few decades. Over that period of time, several advances have been introduced in the technology used to provide video/audio and data regarding specific police events. In the late 1990s through the early 2000s, digital technologies became prevalent in the industry, replacing existing analog technologies. With the use of digital technologies, law enforcement agencies obtained several advances over previous technologies and may further benefit from additional advances (e.g., as described in this disclosure). In general, digital technologies are more adaptable and offer more opportunities for improvement than corresponding analog technologies. This is largely because digital video/audio files can be processed in a multitude of ways by specifically configured computer devices. This disclosure elaborates on several novel techniques to enhance the capability, reliability, ease of use, security, integrity, and other aspects of mobile surveillance systems and the information they collect.

[0048] Prior art mobile video surveillance systems for law enforcement consist of a plurality of discrete components cabled together using wired connections throughout the police vehicle. These systems typically consist of cameras mounted at different locations on the exterior and interior of the vehicle. Installation of each camera requires running one or more cables to and from the camera to carry power to the camera and receive video signals from the camera. Similarly, microphones may be placed throughout the vehicle and require power and/or data connectivity. Installation of the multiple components can be time consuming and complicated. Accordingly, there is a need for a simplified integrated system that provides comprehensive capabilities but reduces installation and maintenance costs (both time and expense). [0049] Additionally, there is a need to improve data access and distribution, integrity, reliability, and security throughout the lifecycle of that data. Legal requirements for data collected by a remote/mobile surveillance system include conformance to judiciary requirements such as "chain of custody/evidence," and "preservation of evidence." Chain of custody (CoC), in legal contexts, refers to the chronological documentation or paper trail audit, showing the seizure, custody, control, transfer, analysis, and disposition of physical or electronic evidence. Preservation of evidence is a closely related concept that refers to maintaining and securing evidence from a particular crime scene before it ultimately appears in a courtroom. For example, the evidence may go to a forensic laboratory prior to arriving at the courtroom. Evidence admissibility in court is predicated upon an unbroken chain of custody. It is important to demonstrate that the evidence introduced at trial is the same evidence collected at the crime scene [e.g. that is, all access to the evidence (e.g., electronic files) was controlled and documented], and that the evidence was not altered in any way. Requirements for law enforcement are further described in "Criminal Justice Information Services (CJIS) Security Policy," version 5.3 published 8/4/2014 referenced as "CJISD-ITS-DOC-08140-5.3" which is hereby incorporated by reference in its entirety.

[0050] Disclosed embodiments include a compact, high definition in-car video solution for law enforcement and other mobile surveillance needs. In one embodiment, the system features a 4.3" touch screen monitor, built-in global positioning system (GPS), crash sensor, and dual 64GB solid-state drives. Some embodiments of the disclosed system deliver, for example, 720p, 1080p, 4K or higher resolutions of high definition full motion video recording and still shot photographs. The recordings and images may each be associated with additional meta-data metrics captured or calculated by the disclosed system. One aspect of the disclosed integrated system that differentiates it over the prior art systems is that the disclosed integrated system facilitates minimal installation or setup in the vehicles. Disclosed embodiments are portable, giving agencies the option to easily move a unit from vehicle to vehicle as needed. Police departments also have the option to hardwire the system into the vehicle for automatic activation due to event triggers such as turning on the ignition or turning on the police lights.

[0051] Disclosed embodiments may include a built-in snapshot camera and other high resolution video recording camera(s). In some disclosed embodiments when the video camera is capturing at 30 frames per second (fps), the video camera has approximately an 86 degree horizontal and 70 degree vertical field of view. Other embodiments may include lenses of various types that help to reduce distortion, and digital imaging chips with integrated (or software assisted) distortion correction. Most systems on the market today require officers to select their video quality at export. In contrast, disclosed embodiments allow more flexibility with respect to video upload, offering an availability of increased quality with every second of video captured. Law enforcement agencies have the option to store all high definition (HD), all the time. The snapshot camera may be configured to provide additional digital evidence capture, for example, with an approximate 54 degree horizontal field of view, and 640 x 480 resolution. Some disclosed embodiments of the integrated system may be further configured to support an additional backseat or rear compartment camera and microphone.

[0052] The disclosed dual drive architecture may include at least two solid-state drives (SSDs) to reduce moving parts (e.g., conventional spinning disk(s)). One drive may be an "installed" internal drive and the second may be a removable drive. Because of security requirements with respect to law enforcement data, any removable storage medium may be secured with a physical (i.e., mechanical) locking mechanism in addition to using technological means, such as, encrypting of or otherwise preventing access to stored data. The disclosed dual SSD configuration may provide for video recording that will never skip due to bumps in the road or vehicle vibrations. The internal SSD may also serve as a backup (e.g., failsafe) to a removable SSD (and vice versa). One of the drives (e.g., internal SSD) may be configured to continuously capture footage whenever the system is turned on. That is, the system will capture footage once an officer has authenticated to the system with no requirement that a "record" process is initiated manually. In one embodiment, the system may be configured to automatically record data and associate the recorded data with a default account even if the officer has not yet authenticated to the system. The removable SSD may be used to maintain video/audio and event data whenever an officer has identified (e.g., tagged and/or manually indicated to "record") an event as pertinent. The continuous automatic feature may allow video to be optionally retrieved up to several days later, even if the system was not in record mode at the time of an event. The removable SSD may also be useful to ensure that pertinent (e.g., tagged) video is safely stored in the event of physical damage to the integrated system or drive. As described herein, the continuous automatic record feature may be implemented as "continuous-loop" recording. Continuous-loop recording may, for example, record in a circular queue to any available space in a designated storage area of an SSD by overwriting oldest data with new data only when there is no longer available space in the circular queue. Alternatively, there are various techniques that may be used to prioritize a continuous-loop storage area in a persistent storage device so as to prevent overwriting of data. For example, tagged data may require a significantly higher priority with respect to untagged "fail-safe" data. Recall, fail-safe refers to data that is automatically captured without any specific associated tag. In some embodiments thresholds including: a begin of shift threshold, a shift running out of buffer, or even an end of shift threshold may be utilized to optimize pertinent available evidence information may be implemented. Each of these thresholds, working independently or cooperatively, may be used to provide maximum retention of recording in a surveillance system configured according to some disclosed embodiments. For example, a beginning of personnel shift threshold may be used to confirm that there is sufficient free space to record a shift's audio/video data prior to a police vehicle starting patrol.

[0053] Some disclosed embodiments of the integrated surveillance system feature one or more built-in wireless microphone receivers, to support one or more wireless microphones. In some embodiments, a novel digital sequence spread spectrum body-worn wireless microphone includes two custom programmable buttons that allow the microphone to serve as a remote control for the mobile surveillance system. The programmable buttons may be configured to be associated with functions ranging from stop video recording, to initiate (optional) backseat camera in covert record mode. With over a 1,000ft range and a polymer lithium-ion battery, the disclosed microphone may continuously record approximately 12 hours of audio on a single charge.

[0054] The system's hardware may be certified against a military standard with respect to operating environment (e.g., MIL-SPEC-810G) and may be capable of withstanding extreme temperatures, rain, dirt, shock, vibration and other harsh conditions. The rugged, compact mobile surveillance system may be mounted discretely and securely near the front passenger seat visor (just to the right of the internal rear- view mirror), without impairing the driver's line of sight and airbag deployment with respect to vehicle operation. Other mounting locations are also possible. The disclosed embodiment of an all-in-one camera, monitor and audio system may weigh less than 21bs and feature multiple installation options. Depending on portability needs, a single cigarette lighter power cable may be used as the sole external cable. Alternatively, the system may be hardwired into the vehicle for power and optional automatic recording triggers. Both of these options require minimal installation as compared to prior art systems, and may be performed by the individual agency (e.g., consumer) in minutes per vehicle. Other prior art systems have required specially trained installation personnel at an increased installation cost both in terms of time and money.

[0055] As will be recognized, disclosed embodiments may provide a turnkey solution for agencies and allow for vehicles to be self maintained. In addition to capabilities of the mobile surveillance system with respect to field use, disclosed embodiments may also allow for comprehensive back-office video management software, giving each agency the tools they need to capture, transfer, store and manage their digital video evidence from car to court. That is, the disclosed system and back-office management techniques meet the preservation of evidence requirements outlined above with respect to management of digital evidence for law enforcement. All activity with respect to digital evidence in the back-office system may be logged to ensure proper documentation of evidence handling. The disclosed system may also include integrated DVD burning software for easy and accurate evidence transfer.

[0056] Another benefit, which may be realized by some disclosed embodiments, is an increased flexibility in service and maintenance. A "Rapid Exchange" program may be implemented to minimize down time for vehicles in the event of a mobile surveillance system error. For example, if the system signals a problem that requires special hands-on technical support (i.e., cannot be diagnosed/resolved remotely), on-site administrators can simply remove the system from the vehicle, ship the defective system to a service factory, and install a single integrated replacement unit. The system includes a pre-emptive maintenance software application program running in the background that can predict imminent system fails. For example, the system provides a warning to the user that the SSD is reaching its end-of-life when reserved bad blocks replacement is exhausted.

[0057] Embodiments of the present disclosure provide for management and "virtual" sending of multi-media files and/or associated data files stored in cloud based storage. Virtual sending refers to sending of a link, such as a hyperlink, to assist in accessing the remotely stored information rather than sending actual files themselves. In some embodiments, the data shared relates to data that might be collected by one or more, mobile surveillance systems, portable video recording devices, and other types of data recorders. The mobile (and possibly stationary) surveillance system devices may be configured to capture video, audio, and data parameters pertaining to activity in the vicinity of the surveillance system, for example a police vehicle. Other types of vehicles and other situations requiring a surveillance unit are also within the scope of this disclosure. Other types of vehicles may include, but are not limited to, any transportation means equipped with a mobile surveillance system (e.g., civilian transport trucks). Disclosed embodiments are explained in the context of mobile surveillance systems that aid in law enforcement such as busses, ambulances, police motorcycles or bicycles, fire trucks, airplanes, boats, military vehicles, and so on. However, in some embodiments, data collected from other types of vehicles including non-law-enforcement vehicles may be collected and managed in cloud based storage as required by that different industry.

[0058] As will be recognized, disclosed embodiments may allow for comprehensive back- office video management software to be provided using a software as a service (SAAS) architecture, giving each agency (even small remote agencies) the tools they need to capture, transfer, store and manage their digital video evidence from car to court. That is, disclosed systems and back-office management techniques meet the preservation of evidence requirements outlined above with respect to management of digital evidence for law enforcement. All activity with respect to digital evidence in the back-office system may be logged to ensure proper documentation of evidence handling. Disclosed systems may include electronic transfer of evidence in a controlled manner and may provide comprehensive coordination of potential evidence captured from a plurality of surveillance systems. While this disclosure teaches, inter alia, cloud based maintenance and access to collected data, disclosed systems may also include integrated DVD burning software at different points in the evidence maintenance lifecycle as a means of evidence transfer to work in conjunction with cloud based maintenance and "virtual" transfer.

[0059] Illustrative embodiments are described below in the context of a surveillance system for a police car and other computer devices that support collection and maintenance of video and audio evidence for law enforcement. Examples of such computer devices include, but are not limited to, portable digital cameras, self-contained application storage drives, digital video cameras, and digital audio microphones. Uses of the disclosed pre-configured storage device (e.g., a self-contained storage drive or secure self-contained storage drive included in a body worn camera or programmable wireless microphone) for securing data and maintaining data integrity exist beyond the field of law enforcement and this context is illustrative and not intended to be limiting in any manner. Implementations relating to both a "secure" self-contained storage drive/device and a self-contained standard (as opposed to secure) storage drive are further discussed below.

[0060] Referring now to Figures 1A-B, disclosed embodiments of an integrated mobile surveillance system 100 are intended to incorporate a plurality of functions as being "built-in" to mobile surveillance system 100. Additionally, aspects of integrated mobile surveillance system 100 have been designed with consideration for future expansion as new technologies and capabilities become available. Aspects of integrated system 100 include, but are not limited to, the following integrated functional units. Integrated system 100 may be configured to have one or more than one of each of these functional units, as appropriate. Integrated wireless microphone receivers 105 to allow capture of audio from a remote wireless microphone located within proximity of integrated system 100. An external multi-conductor interface cable 110 to allow a wired connection to one or more internal interfaces of integrated system 100. Universal serial bus (USB) port(s) 140 for general peripheral connectivity and expansion. An integrated GPS module 120 with optional external antenna or connector 115 to be used in part for capturing location data, time sync, speed logging. The GPS information may also be used for time synchronization and to coordinate data, ultimately facilitating map based search and synchronization (e.g., locate recorded information from a time and/or location across a plurality of recording devices). Dual front facing cameras 125 may include both a wide angle video camera and a tight field of view camera for optical zoom effect snap shots. A record indicator 130 provides an indication of a current operating mode for integrated system 100. A wired Ethernet adapter (e.g., Gigabit, 10/100 BASE-T, etc.) 135 (or a wireless network adapter, not shown) for data upload, computer interface, remote display and configuration. Additionally, multiple wireless data communication devices (not shown) may be integrated for flexibility and expansion. For example, the system may include adapters conforming to wireless communication specifications and technologies such as, 802.11, Bluetooth, radio-frequency identification (RFID), and near field communication (NFC). Each of these interfaces may be used, at least in part, for data exchange, device authentication, and device control. A serial port (not shown) may be used to interface with radar/laser speed detection devices and other devices as needed. A G-Sensor/Accelerometer (not shown) may be used for impact detection and to automatically initiate record mode. The G-Sensor/Accelerometer may also provide data logging for impact statistics and road condition data. A DIO (Digital Input /Output) (not shown) that may be used for external triggers to activate record mode and/or provide metadata to the system. The DIO can also be used to control external relays or other devices as appropriate. The DIO can also be used to detect brake, light bar, car door, and gun lock so that the video recording can be automatically triggered. A combination power button and brightness control 145 can be used to turn on the system and control the brightness of the monitor after the system is turned on. Programmable function button 150 provides a user definable external button for easy access to instigate any function provided by integrated system 100. For example, rather than traversing through a set of menus on articulating touch screen 165, a user could define function button 150 to perform an action with one touch (e.g., instant replay, event tagging of a particular type, etc.). An articulating touch screen 165 that may be used to view video in real-time, or in one or more play back modes. Touch screen 165 may also serve as an input mechanism, providing a user interface to integrated system 100. An integrated speaker (not shown) may be used for in-car audio monitoring and in-car video/audio file playback. An integrated internal battery 155 for proper shutdown in the event of sudden power loss from the vehicle that might occur as a result of a crash, for example, is shown. Also depicted is a removable SSD Flash drive 170 (e.g., secure digital (SD) or universal serial bus (USB) type), including any type of storage that may be inserted or attached to the system via a storage interface (e.g., SCSI, SATA, etc.). For security of access to data, removable SSD flash drive 170 may be secured via a mechanical removable media key lock 160. In some embodiments, event based data is recorded and written to the removable drive to be transferred to a back office server for storage and management. Wireless microphone sync contacts 175 may be configured to synchronize a wireless microphone/camera, such as a body worn camera and microphone, for communication with integrated system 100. In addition to actual sync contacts, that require physical contact, other synchronization methods for wireless microphone/cameras include utilizing NFC or RFID capability between the wireless device and integrated system 100.

[0061] In addition to the components mentioned above, disclosed embodiments of integrated mobile surveillance system 100 may be configured to include functional components to provide operational characteristics that may include the following. A pre-event playback function which may be used to tag historical events. Recall, normal operation may be to record continuously to internal storage and to store tagged information (e.g., marked for export) to removable storage. However, in order to cover the case in which an incident occurred without a timely event trigger, the operator may instruct the system to navigate back to an earlier time captured in the internal storage and play back that video/audio information. The selected historical video, at any available point in time, may be marked, tagged for extraction, and stored to removable storage, as if the event had been tagged at that historical time. Another functional component could provide an instant replay function configured to playback the last predetermined amount of time with one button press. Note that both the instant replay and pre-event playback (along with general system operation) allow for simultaneous playback while the system is concurrently recording information. Pre-defined event tags and a pre-defined event tagging functions may also be provided. For example, tags may include DWI, felony, speeding, stop sign, chase, etc. The tagging action may be used to catalog portions of recorded data. For example, after an event is cleared, such as stop recording, an option to select a predefined event may be displayed. Upon selection the system may allow an associated portion of collected information to be marked in a text file for current and future identification and storage. Further, when the tagged information is transferred to the data management software, the tagged information may be searched by event type and maintained on the server with the proper retention period as appropriate - based on the defined event type. A streaming function may also be provided to stream live view and recorded video, audio, and/or data over available wireless and wired networks. The integrated system 100 may also integrate "hotspot" capabilities which allow the system to serve as an agency accessible, mobile wireless local area network (WLAN). As will be recognized based on this disclosure, the integrated mobile surveillance system has many benefits over other mobile surveillance systems of the prior art. For example, by being compact and HD (with dual cameras 125) and having integrated wireless microphone receivers 105, GPS 120, an internal battery 155 and articulating touch screen monitor 165, this unit is a) easier to install and replace for service; b) takes up less room in the vehicle; and c) requires less cabling compared to typical systems.

[0062] Referring now to Figures 2A-C, possible internals and peripheral components of an example device 200, which may be used to practice the disclosed functional capabilities of an integrated surveillance system such as system 100, are shown. Example device 200 comprises a programmable control device 210 which may be optionally connected to input device 260 (e.g., keyboard, mouse, touch screen, etc.), display 270 or program storage device 280. Also, included with programmable control device 210 is a network interface 240 for communication via a network with other computers and infrastructure devices (not shown). Note network interface 240 may be included within programmable control device 210 or be external to programmable control device 210. In either case, programmable control device 210 may be communicatively coupled to network interface 240. Also, note Program Storage Device (PSD) 280 represents any form of non-volatile storage including, but not limited to, all forms of optical and magnetic storage elements including solid-state storage.

[0063] Program control device 210 may be included in a device 200 and be programmed to perform methods in accordance with this disclosure. Program control device 210 comprises a processor unit (PU) 220, input-output (I/O) interface 250 and memory 230. Processing unit (PU) 220 may include any programmable controller device including, for example, the Intel Core^®, Pentium^® and Celeron^® processor families from Intel and the Cortex ARM processor families from ARM^® (INTEL^® CORE^®, PENTIUM^® and CELERON^® are registered trademarks of the Intel Corporation. CORTEX^® is a registered trademark of the ARM Limited Corporation. ARM^® is a registered trademark of the ARM Limited Company). Memory 230 may include one or more memory modules and comprise random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), programmable read-write memory, and solid state memory. One of ordinary skill in the art will also recognize that PU 220 may also include some internal memory including, for example, cache memory.

[0064] Various changes in the materials, components, circuit elements, as well as in the details of the illustrated systems, devices and below described operational methods are possible without departing from the scope of the claims herein. For instance, acts in accordance with disclosed functional capabilities may be performed by a programmable control device executing instructions organized into one or more modules (comprised of computer program code or instructions). A programmable control device may be a single computer processor (e.g., PU 220), a plurality of computer processors coupled by a communications link or one or more special purpose processors (e.g., a digital signal processor or DSP). Such a programmable control device may be one element in a larger data processing system such as a general purpose computer system. Storage media, as embodied in storage devices such as PSD 280, memory internal to program control device 210, or storage media connected via an expansion port (not shown) are suitable for tangibly embodying computer program instructions. Storage media may include, but not be limited to: magnetic disks (fixed, floppy, and removable) and tape; optical media such as CD-ROMs and digital video disks (DVDs); and semiconductor memory devices such as Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Programmable Gate Arrays and flash devices. These types of storage media are also sometimes referred to as computer readable medium or program storage devices. Program control device 210 and/or device 200 may also include an expansion port (not shown) for connecting additional devices or storage media (e.g., plug-in storage drives 285 and 286 of Figures 2B and 2C). In one example, the expansion port may be a Universal Serial Bus (USB) port and allow for plug-in and removal of drives (e.g., 285 and 286) while device 200 is operational. Further details regarding plug-in or connectable storage drives that are "hot pluggable" will be discussed next with reference to Figures 14A, 14B, 15A and 15B.

[0065] Figure 2B illustrates a secure digital (SD) card that may be configured as the removable storage device described above. An SD card is a nonvolatile memory card format for use in portable devices, such as mobile phones, digital cameras, handheld consoles, and tablet computers, etc. An SD card may be inserted into a receptacle on the device conforming to the SD specification or may alternately be configured with an interface to allow plugging into a standard USB port (or other port). An example of the adapter for USB compatibility is illustrated in Figure 2C. Modern computer operating systems are typically configured to automatically permit access to an SD card when it is plugged into an active computer system (sometimes referred to as plug-n-play). In computing, a plug and play device or computer bus is one with a specification that provides for or facilitates the discovery of a hardware component in a system without the need for physical device configuration or user intervention in resolving resource conflicts. Because of additional security requirements regarding data access with respect to the law enforcement field, disclosed systems may incorporate a specifically modified interface to the removable storage drive utilized in device 100 (i.e., removable media 170). Modifications permitting specialized access to removable media, according to some disclosed embodiments, are described more fully below with reference to Figure 5.

[0066] Referring now to Figure 3, block diagram 300 illustrates one embodiment of an integrated audio-video-data surveillance system. Note that each of the components shown in block diagram 300 may be communicatively coupled to other components via communication channels (e.g., bus) not shown in the block diagram. The flow arrows of block diagram 300 are very general in nature. In use, video and audio may be captured by camera 305 and microphone 306 respectively. Captured data may be provided initially to video/audio encoder 310 to encode and optionally compress the raw audio and/or video data, and the encoded data may be stored in a memory area (not shown) for access by CPU 315. Encoded data may also be selectively stored to either hard drive 320 or removable hard drive 325 individually or to both simultaneously. Data may also be transferred, for example at the direction of a user, from hard drive 320 to removable hard drive 325. Data capture devices such as general purpose input output (GPIO) 330 and GPS 331 may be used to capture metadata to associate with captured surveillance information. All pertinent captured metadata may be associated with captured video/audio recordings using structured text files such as, for example, extensible Markup Language (XML) files. An example of such structured text files is explained in more detail below with reference to Figures 12A-F. In addition to captured metrics provided by real-time capture inputs, XML files may be utilized to store many different types of metadata associated with captured video and data, including but not limited to timestamps of capture, [internal clock (not shown) of system 100 may be synchronized using GPS data] event tags, GPS coordinates, GPS and RADAR/LIDAPv measurement from a target vehicle, analytical information etc. Analytical information will be discussed in more detail below with reference to Figure 11. Wireless interface 330 (or a wired interface (not shown) when available) may be used to upload information from one or more surveillance systems to back office servers located, for example, at a police station or to cloud based resources. Back office servers and cloud based resources will be discussed in more detail below with reference to Figures 10 and 11. The disclosed secure removable storage device (e.g., 285, 286, or variants thereof discussed below with reference to Figures 14A, 14B, 15A and 15B) may be used to protect and restrict access to the captured audio, video, and metadata as required by evidentiary rules followed by law enforcement.

[0067] Referring now to Figure 4, block diagram 400 illustrates one possible data flow with respect to buffering of captured video and audio for simultaneous capture from multiple cameras according to some disclosed embodiments. Real-time data may be captured from a first camera 410 and a second camera 420. For simplicity only two cameras are discussed here, however, these concepts may be extended to any number of cameras. Data captured by each camera can be initially encoded by a processing device integrated to or communicatively coupled to the respective camera. The initially encoded data may then be stored for each camera into RAM buffer 430. Line 435 represents one or more processing tasks (e.g., processes) executing on a processing device such as PU 220 to transfer data from RAM buffer 430 to internal continuous loop storage 440. These processing tasks may be configured to re-encode the data from RAM buffer 430 into a different encoding format. The different encoding format may be an industry standard format such as H.264, an MPEG format, etc., selected based on efficiency of storage or for other reasons desirable for continuous loop storage. Line 445 represents one or more processing tasks (e.g., processes) executing on a processing device such as PU 220 to transfer data from RAM buffer 430 to event recording storage area 450. Processing tasks represented by line 445 may also be configured to re-encode the data from RAM buffer 430 to a different encoding format. Because data in event recording storage 450 has already been indicated as associated with an event, re-encoding may result in a different format than that selected with respect to line 435. In any case, data stored in event recording storage 450 may also be encoded in an appropriate industry standard format. Line 455 represents a processing task (e.g., process) where information from internal continuous loop storage 440 may be transferred to event recording storage 450. This transfer may be in response to a user indicating that previously recorded data should now be associated with a particular event type, for example. During the transfer represented by line 455 an appropriate re-encoding may take place as necessary, for example if data in internal continuous loop storage 440 and event recording storage 450 utilize different encoding techniques. [0068] Referring now to Figure 5, flow chart 500 illustrates a possible method for determining if any computer access should be permitted to a secure storage drive (e.g., 250, 255). If allowed, access may use typical industry standard "plug-n-play" storage device protocols. Disclosed industry standard storage devices may include SD drives, SATA devices, SCSI devices, or any other type of device suitable for the many disclosed embodiments. By disabling access to a "secured" but otherwise industry standard plug-n-play storage device, protection may be extended beyond typical encryption of data or read-only access to data. For example, on a standard plug-n-play storage device, even if data on the device is encrypted and the content is not accessible, a "FORMAT" command may be able to erase the stored data. As explained above, such destruction of data may not be acceptable for law enforcement type data. The architecture of the apparatus, methods, and systems disclosed herein makes such unauthorized attempts to format a device impossible because the device remains hidden and not accessible. Accordingly, prevention of the ability to format a storage device and to destroy data on a storage device may be an advantage for disclosed embodiments of the secure storage drive used in conjunction with other systems such as the audio/video surveillance system for collecting legal evidence as described herein, as well as other applicable fields. Beginning at block 505, a plug in storage device is inserted into a port on a computer device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3) or connected via another means such as a bus. In typical operation, the device driver of the computer device would query the storage device and the storage device would respond with appropriate access protocols (see enumeration discussion above). However, a removable storage device configured in accordance with some embodiments of this disclosure may have specially configured firmware to prevent standard "hand shake" protocols (e.g., enumeration processes) from allowing access to the storage area of a secure storage drive (e.g., 1550, 1555 of Figures 15A and 15B). At decision 510, it is determined by the specially configured firmware of the storage device if an unhidden key from the device driver of the computer device has been received by the storage device. The unhidden key and optionally proper additional authentication information is required to allow access to the storage area of the secure storage drive (e.g., 1550, 1555) or to allow access from the operating system of the computer device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3). If no unhidden key has been received at the secure storage drive, the NO prong of decision 510, then the secure storage drive (e.g., 1550, 1555) does not respond in such a way as to complete a proper enumeration. Thus, the operating system of the computer device (e.g., device 200 of Figure 2 A, or the computer device shown in Figure 3) will not recognize the secure storage drive. Optimally, the operating system will not even inform a user via the user interface of the computer device that any type of device was plugged in. In any event, even rudimentary access to the secure storage drive will be prevented as shown at block 530. That is, even rudimentary access to information about the secure storage drive will not be allowed. Flow will return to block 505 as if no plug-n-play device was inserted into the port of the computer device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3). Alternatively, an unhidden key may have been issued by the device driver of the computer device to allow initial access to the storage device (the YES prong of decision 510) and then allow access by the operating system of the computer device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3). At block 515, the specially configured secure storage drive will respond to the operating system in a "normal" fashion with access information as required to complete the enumeration process and permit access, as allowed by other security measures, to data on the removable storage device (shown at block 520). At decision 525 it is determined if the removable storage device has been unplugged. If the storage device has been unplugged (YES prong of decision 525), flow may continue in such a manner that the secure storage drive may revert to its default hidden state (not shown). Flow then returns to the initial condition of block 505. Otherwise (NO prong of decision 525), flow returns to block 520 and continued access is permitted as long as the device remains plugged in. Note that data on the storage device may be further encrypted or otherwise protected by additional methods including simple password protection, biometric access control, and so on. Additionally, in an "open" embodiment, if a typical removable storage device were plugged into the computer device, the computer device would simply ignore (and not require) the unhidden key and therefore be accessible to the computer device in the normal fashion. In a different "closed" embodiment, the computer device and its device driver may not allow access to any removable storage that is not secure. That is, rather than allowing standard access as in the "open" embodiment, the "closed" embodiment would restrict access to only specially configured secure storage drives. The "closed" embodiment may be useful, for example, to deter transfer of data from the computer device to a non-secure storage device because data on the computer device is access restricted.

[0069] According to some disclosed embodiments, the secure storage drive remains hidden unless the computer system issues a special unhide key (via a device driver) to unhide the storage volume. For example, to unhide the portion of the storage device containing data readable by an operating system of the computer device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3). The special unhide key may be issued from a modified device driver incorporated into the computer device or may be an additional hardware feature of the plug-in port (e.g., the expansion port described with reference to but not shown in Figure 2A) for industry standard devices. If the computer device does not have the ability to issue the unhidden key, the secure storage device will not respond to any queries from the operating system of the computer device - the secure storage device may be treated as if it does not exist. Thus, the files in storage device are not visible in any way to the computer device. In addition to the disclosed aspect of hiding the plug-in storage itself, the data files on the plug-in storage can be encrypted for further security file protection. As noted above, commonly used encryption methods are unable to prevent computer systems from accessing and deleting the files (e.g., through a system "FORMAT"). However, unlike traditional data encryption, the hidden volume method described herein not only protects data integrity but also eliminates any possibility of computers accessing the data without the unhidden key.

[0070] The hidden secure removable storage device and associated methods of operation described above with reference to Figure 5 may be used as discussed for law enforcement information or to secure any sensitive information in any field, including, but not limited to, medical, financial, Social Security, Protected Health Information (PHI), and so on. Similarly, disclosed embodiments of self-contained storage drives, either standard drives or embodiments of the disclosed secure storage drive, may be utilized for law enforcement purposes or any field of use that may benefit from the advantages discussed with regard to self-contained storage drives (e.g., ease of use, ease of upgrade, etc.).

[0071] Referring now to Figure 6, flow chart 600 illustrates a possible authentication method for an integrated surveillance system according to some disclosed embodiments. Recall that the criminal justice system requires strict access/modification controls over any data collected for evidentiary purposes. Accordingly, access to any device configured to capture such data must be tightly controlled. The CJIS (Criminal Justice Information System) Security policy requires AA (Advanced Authentication) under almost all conditions. If the technical security controls allow any user to conduct transactional activities on state and national repositories, applications, or services (i.e. indirect access) these conditions have not been met. One of the intentions of AA is to meet the standards of two-factor authentication. In one example, two-factor authentication employs the use of two of the following three factors of authentication: something someone knows (e.g. password), something someone physically possesses (e.g. hardware token), something someone physically is (e.g., biometric as in fingerprint, facial print, or voice print, etc.). To satisfy requirements of two-factor authentication, each of the two factors shall be unique (e.g., combinations of password/token or biometric/password may be acceptable, but not password/password or token/token). One possible embodiment of a system authentication implementation may utilize integration of NFC, RFID and/or biometric data to associate recorded surveillance system data with a particular officer, at a particular location, at a specific date/time, and with regard to a particular incident (e.g., event tag). Although two-factor authentication is shown in the example of flow chart 600 any number of levels (e.g., multi-factor authentication) may be utilized.

[0072] Authentication of a person recording any incident, for example, using fingerprint, facial recognition, or other biometric authentication to uniquely identify the person recording the incident may be designed to meet the federal requirements for data security, integrity, and adhere to requirements for chain of custody of evidence. Additionally, access controls may be implemented to ensure that proper audit trails regarding access/modification of any recorded data also conform to these requirements. In addition, peripheral devices, such as wearable wireless microphones and camera systems may also be authenticated via the disclosed integrated mobile surveillance and video/computing system, and authentication of one device may be automatically passed on to other connected devices assigned to a particular user (e.g., officer). This may allow an officer to have a single sign-on capability to multiple devices within a patrol vehicle. For example, the officer may enter the vehicle carrying a uniquely assigned RFID/NFC hardware token. Upon presenting either the hardware token or a password, the system could prompt for the second authentication factor. Upon receipt of both aspects of the two-factor authentication the device could properly authenticate the officer and propagate authentication information to any other devices within the vehicle. Accordingly, the officer would be able to simply supply a single "two-factor" authentication to one single device and all other properly equipped devices would be authenticated. Each of these other peripherals may be configured with NFC/RFID communication capability to allow for passing of authentication credentials and thereby allow the disclosed single sign-on capability in conformance with CJIS requirements.

[0073] With that background, we can return to flow 600 that illustrates an authentication method starting at block 605. At block 610, a fail counter is initially set at zero. Flow continues to block 615 where a first authentication input is received. If authentication of the "first-factor" is not successful (the NO prong of decision 615) then an increment of a failed authentication attempt will be performed at block 620. At decision 625, if the failed attempt counter exceeds five (5) attempts then the authentication system may lock the device and require advanced authentication privileges to unlock the device prior to allowing further access (block 630). Upon successful completion of a first factor authentication, flow continues to decision 635 where a second authentication input may be evaluated. If the second "factor" authentication is accepted, flow continues to decision 640 where a check on idle system time may still yet prevent access to the system. Similarly to decision 615, a "NO" for decision 635 proceeds to block 620 to increment a fail counter. If all access parameters have been satisfied by the disclosed authentication method, then flow continues in parallel to both block 645 and decision 650. At block 645, access to system applications is allowed. At decision 650, it is determined if other peripheral devices require authentication. Peripheral device authentication may be performed with a broadcast/response mechanism, with no prior knowledge of additional peripheral devices, or may be targeted at specific additional devices. If other peripheral devices require login information, then flow continues to block 655 where additional credentials may be supplied through RFID/NFC or other known mechanisms. These devices, having been authenticated, may wait for a further indication as indicated by the flow from 655 to 660. At decision 660, it is determined if a user has either shutdown or logged-off, or if a check for excessive idle time of the system is required. In the case of a shutdown, the flow continues to block 665 where no further access is permitted. At block 665, the system may be completely disabled, until a hard re-boot and an authentication start (i.e., block 605) is performed. Alternatively, in the case of a logoff at 660, a logoff procedure may be commenced, and a return to an initial condition (e.g., waiting for authentication block 605) may be performed. In another alternative, a system idle time may have been exceeded (e.g., LOOP of decision 660). Loop alternative may require another authentication start procedure be initiated from block 605 without completely restarting the system. It is possible that multiple devices may be authenticated at once via either RFID or NFC or a combination of both. Accordingly, various combinations of communication technologies could be used to allow access to the main system, individual components, or even specific components that are in an allowed equipment list for a designated user.

[0074] Referring now to Figures 7-9, block diagram 700 illustrates additional components that may be integrated into an integrated surveillance system according to some disclosed embodiments. Ethernet ports 710 may include Power over Ethernet (PoE) capabilities for providing power along a network cable. The IEEE PoE standards provide for signaling between the power source equipment (PSE) and powered device (PD). This signaling allows the presence of a conformant device to be detected by the power source, and allows the device and source to negotiate the amount of power required or available. Accordingly, different devices (not shown) could optionally be plugged into and receive power from an integrated surveillance system. Watch 705 illustrates a combination watch and heart rate monitor as an example of one of many different types of devices that could be configured to interact and communicate with an integrated surveillance system configured according to some disclosed embodiments. Watch 705 may be configured for communication using NFC, RFID, Bluetooth, or Ethernet and may provide useful information to an integrated surveillance system 100 (FIGS. 1A and IB). In one example, the heart rate of a police officer could be monitored and used to initiate an event recording if the heart rate of the police officer increases above a threshold. The threshold could be pre-set or determined based on monitoring the police officer over time to determine that officer's "normal" heart rate. The threshold could alternatively be a percentage change in heart rate. Other types of monitors in addition to biometric monitors could be configured to integrate with an integrated surveillance system and initiate event recordings. As another example besides watch/heart rate monitor 705, a tablet, or the like, could be configured and authenticated via NFC, RFID, Bluetooth or wireless network. The police officer could input driver license information, event descriptions, photos of the scene outside of the vehicle, etc. into the tablet. The information would then be wirelessly transferred to the system as recording metadata. The officer may also, for example, use Bluetooth equipped radar speed measurement devices or breath analyzers outside the car to collect data. The data may then be wirelessly transmitted back to the system as recorded video metadata via Bluetooth communication.

[0075] Figure 8 illustrates block diagram 800 without an integrated touch screen monitor. Instead of an integrated monitor, tablet/laptop computer 805 provides an interface to an integrated surveillance system via one of Ethernet connections 710. Figure 9 illustrates block diagram 900 in an alternate configuration where wireless dock 905 is utilized to provide connectivity to an integrated surveillance system. Although not shown explicitly in the figures, the disclosed integrated surveillance system may also be configured to act as a wireless "hot- spot" to allow a plurality of devices to bridge through the system and obtain access to other external networks (e.g., Internet, Police network, etc.). Figure 13, discussed further below, provides additional examples of the wireless client connectivity and control concepts disclosed herein.

[0076] Law-enforcement agencies with limited staffing and resources may find it difficult to adopt in-car or wearable video system technologies that involve complex, expensive and cumbersome components. For example, an in-house server based solution may require experienced computer technicians/specialists to maintain proper hardware operations. A non- server based solution may also be challenging because it may require system configuration, video search and storage capability, and evidence life-cycle maintenance. It is contemplated that a cloud based SAAS solution may offer the proper flexibility and convenience required for such law enforcement agencies.

[0077] In one disclosed embodiment, a remote application and database server may be hosted by a software as a service (SAAS) cloud application to reduce (or eliminate) the need to hire additional computer technicians. Some disclosed embodiments may be implemented in a hybrid cloud and provide local (on site) data storage for portions of data that require high bandwidth across a network (e.g., Internet, police network) while maintaining metadata in the cloud. This configuration may help ensure security and integrity of digital evidentiary data by maintaining a single global copy of metadata in the cloud (for storage) while still allowing fast local access speeds for review of potentially large video/audio files. Also, optionally, data on a shared server may be downloaded to the local data storage site as backup data and then re -uploaded to a remote (or cloud based) site if there is a systems failure or "intrusion" attack at the remote (or cloud based site).

[0078] To eliminate the need for (or to augment) a conventional DVD burner based system, the user may auto upload all data and metadata to the cloud. Optionally, a user may provide (or user event tags may be used as) identification criteria for certain types of videos (and their metadata) to be sent to the cloud automatically as soon as the videos are uploaded to a server with certain "event type" metadata. For example, an administrator may define: all DUI videos are sent to cloud based storage and two DVD copies are burned. When an officer tags a video as a DUI event type, as soon as the video is uploaded to the cloud, the video may also be sent to a DVD burner for two copies automatically. Alternatively, rather than burning DVD copies, an email may be automatically generated and sent or instructions may be provided to an employee to create and send an email with a time limited access link to personnel or third parties who may have an interest in a DUI event. Based on the tag type assigned, a wide number of triggers and follow-on responses may be generated automatically. Furthermore, actions relating to compliance with record retention policies may be automatically generated so that as specific retention periods pass, records are automatically deleted. Thus, the user may readily and easily take advantage of cloud-based storage for an almost limitless cataloguing and archiving device.

[0079] Referring now to Figure 10, data flow in a content management system that may utilize the disclosed SAAS functionality and cloud storage is illustrated in block diagram 1000. The SAAS component (including SAAS functions 1020) may be a system which typically includes a web-based portal that is the entry point to the software services for all users requiring data access. As with other data access points, access may be controlled by authentication means such as, but not limited to, passwords, fingerprints, encryption, and so on. Authorized users may search media catalogues which may be generated from metadata obtained from a single agency or from multiple jurisdictional agencies. Users may also manage all the configuration settings of mobile/portable video/audio recording devices via a cloud based control portal. Having metadata in the cloud facilitates many different functions, such as, query search of metadata associated with audio, video or print media. The metadata in the cloud and an associated interface portal may allow access to any evidentiary logs associated with the data (local or cloud based) and access a user's local hardware/software storage to review media that may not have been uploaded to cloud storage (e.g., because of bandwidth/storage constraints). Authorized users may access specific content utilizing a "link" as described above in the discussion of Figure 5B. In most cases a user will interact with a cloud based copy of the multi-media files they are allowed to access via their supplied link. However, the cloud based system may include enough information to allow secure access back to local storage and backend servers (e.g., 1044 and 1042) so that a user at police station 1040 may efficiently view locally stored multi -media files. That is, interact with a locally available copy of the cloud based copy pointed to by the link while maintaining audit trail information in the cloud. Alternatively, a user located remotely from police station 1040 may obtain access (e.g., secure access via virtual private network (VPN)) to network and storage infrastructure at police station 1040 and perform desired actions on multi-media files. That is, if required, a remote user may be redirected from the cloud to an alternative identical copy of a multi-media file while again maintaining audit trail information in the cloud. Of course, bandwidth constraints of the obtained remote access (e.g., VPN) may have an effect on what actions a remote user decides to perform.

[0080] Local hardware/software storage 1044 at police station 1040 may be any storage device, such as local hard drives, removable drives, network drives, and so on. As shown in Figure 10, the SAAS functions 1020 may incorporate cloud storage (1030) which is not typically as limited in storage capacity as local hardware/software storage. However, remote access to large files may have associated communication bandwidth concerns. Such a SAAS content management system may limit data handling (and thus the potential for breaking the evidentiary chain of custody) because copies are not directly controlled by users. Data handling may also be limited by initiating data transfer from the local collection point via an upload of data to the cloud storage using the web-based portal. The user may determine which data will remain on local storage and which data resides in the cloud. For example, in such a hybrid storage solution, metadata relating to GPS information and applications for performing data analysis may reside in the cloud, while the related audio/video files remain at the user's facility. This is largely based on the size of the files and recognition that bandwidth to cloud storage may affect access to large files. However, in some situations bandwidth concerns are not a determining factor and other segmentation of data may be desired. [0081] As disclosed, a cloud-based video export and access system may reduce the hardware and ongoing maintenance costs of optical media based systems by providing users a secure, controlled, reliable and cost-effective method for sending video and data to third parties. Video and data may be uploaded to the cloud for storage, one or more third party recipients may be assigned access rights, and a defined expiration date for third party access may also be provided. Additionally, use of the cloud may permit real-time data upload and storage which provides nearly limitless data storage capacity for a mobile surveillance system. Hybrid storage models may be implemented to define pre -requisites as to what actual multi -media files are stored in the cloud. For example, only multi-media files requiring access by third parties are uploaded to the cloud. Another example may be that only multi-media files that have been tagged with a particular event tag (e.g., based on event type) are uploaded to the cloud. In either or both of these examples, other multi-media files that may be less important or have not yet been fully analyzed may be maintained on local storage for future consideration. Note that even though multi-media files may be maintained on local storage, it may be desirable to upload associated metadata to the cloud based system to provide more comprehensive indexing and searching functionality across all recorded data.

[0082] Exported data may be stored in cloud-based storage that is remotely accessible through a secured means (for example, but not limited to, a password, finger print reader, etc). As explained below in the discussion of Figures 25A-B, the system may be configured to send one or more recipients an access link through automated communication methods such as email, text, and Multimeida Messaging Service (MMS), etc. The link sent to each recipient may include an expiration date for accessing the associated data. The system may also allow a recipient of the link to review the data stored in the cloud using a remote access point (not shown) communicatively coupled through a communication channel (not shown). The communication channel may be a VPN or simply some other communication facilitated via the Internet (e.g., encrypted HTTPS). Once a third party (remote user) obtains access to selected files on cloud storage they may also be able to download a local copy of the data for future use, and delete the data after review or download. Downloading of data may of course have negative implications as described above (see Figure 25B) regarding "loss" of control of content. The link sent to each recipient may also limit access rights of recipients (e.g. read only, data editing, deletion, etc.) and may actually prevent downloading of data.

[0083] In order to comply with laws, court orders or record-retention policies relating to data access, the system may be configured to remove the accessible data after a predetermined expiration date. A cloud-based system thus allows users to retain the original data while limiting third party access to such data. For example, a first remote access point may allow a first group of users to access content via a first communication channel. Similarly, a second remote access point may allow additional groups of people to access content via a second communication channel. Any number of remote user groups and links may be provided for by any number of remote access points and associated communication channels. Once an access link has expired, no third party may access the expired data. The disclosed SAAS system may also provide bookkeeping functions to track content access, bandwidth usage, and subscription expiration, etc. This bookkeeping function may be capable of statistical analysis, billing, and may generate reports and invoices as needed.

[0084] Figure 10 also graphically illustrates an example data exchange flow in block diagram 1000, thorough which video, audio, and related data may be shared. Numerous users, computer- based functionalities, storage options, and associated lines of communication may be involved in data uploading and downloading. For example, one or several police vehicles 1010 may transmit video and audio data and associated metadata via wireless communication means 1005 to a cloud storage system 1030. This wireless communication may occur, for example, while police vehicles 1010 are on patrol (e.g., in transit) via a wireless communication path (e.g., satellite, cellular data, or the like). Concurrently with receipt in the cloud (or as needed), this data or a subset of this data may be made accessible to software applications, for example SAAS functions 1020, via communication link 1006. Police vehicle(s) 1010 may also manually transfer data and metadata to local storage 1044 upon arrival at police station 1040 using data transmission channel 1060. Data transmission channel 1060 may be a wired connection or a wireless connection. In an alternative, a classical "sneakernet" may be used by connecting a portable recording device to another device (e.g., docking station 2200, Figure 22). After connection, data may be uploaded to local storage 1044, which is located at the police station, and then optionally (based on a number of different criteria, one criterion including event tags) to the cloud 1030.

[0085] In the example of block diagram 1000, a surveillance system vendor 1070 oversees and maintains SAAS functions 1020 utilizing communication channel 1065. The vendor may also optionally maintain the security and integrity of any cloud based storage system 1030 utilizing communication channel 1066. Vendor 1070 may also provide all necessary technical support through its software 1020 and communication channel 1045 to assist police station 1040 in implementing best practices in the preservation of data evidence. Police station 1040, depending on available resources, may have "in-house" routers (not shown) and surveillance system backend server(s) 1042 which provide redundant data storage systems. Police station 1040, in order to avoid expensive data storage solutions, may optionally utilize cloud storage 1030 via communication channel 1050. Cloud storage system 1030 may also communicate directly with SAAS functions through communications channel 1055. Having multiple channels of secured communications may provide rapid and efficient data exchange. Use of various storage means, (locally or cloud-based) allows an inexpensive and flexible alternative to resource -limited users.

[0086] In another aspect of the disclosure, an optional self-contained removable storage device may be used to rapidly and efficiently review recorded data. The removable storage device includes one or more of the following: a software application, a media player, configuration information (e.g. user logon information, system identity, system behavior definitions, etc.) for the integrated mobile surveillance system 100 (FIGS. 1A and IB), firmware/software updates for the integrated mobile surveillance system 100, and recorded data (audio, video, snapshot images, metadata or evidentiary logs) for the integrated mobile surveillance system 100. The software application stored on the removable storage device is self- contained which eliminates the need for additional installation to an operating software on any computer to which the removable storage device is attached. Optionally, cataloguing and searching functionality via software may be integrated into the self-contained storage device (SSD) or any SSD associated with integrated system 100. The software is capable of building a catalogue for searching stored video, audio, image and other data files. This searching functionality may be further enhanced by integrating searching of data on any computer, network or the cloud (as noted above) to which the removable storage device may have access. Additionally, selected audio, video or image data and metadata may be uploaded to the cloud for further exporting or archiving.

[0087] In a manner similar to the concepts described with reference to Figure 5, the self- contained removable storage device may be hidden unless the computer system issues a special command to unhide the storage volume internal to the storage device. If the computer system does not have the ability to issue the unhidden command, the removable storage device will not respond to any queries from the computer system - the removable storage is treated as if it does not exist. Thus, the files in the storage device (e.g. on a storage volume of the storage device) are not visible to the computer system. In addition to the hidden volume, the data files on the storage device may be encrypted for further security file protection. Commonly used encryption methods are unable to prevent computer systems from accessing, and therefore from deleting the contents of a removable storage device (e.g., by using a FORMAT command). However, unlike traditional data encryption, the hidden volume method described herein not only protects data integrity but also eliminates any possibility of computers accessing or using operating system commands to delete the data without the unhidden command. At an extreme, physical destruction of the specially configured removable storage device may be needed to destroy the data on such a storage device.

[0088] Referring now to Figure 11, flow chart 1100 illustrates a potential data mining strategy for captured data. The disclosed data mining strategy may benefit from the above discussed hybrid storage model in a number of ways. Example benefits across a single agency or multiple jurisdictionally distinct entities may include sharing of information without violating privacy or other data access concerns. Sample use cases are described following this overview of flow chart 1100. Beginning at block 1105, at least one surveillance system automatically captures video and audio data and associates that captured data with GPS positioning, timestamp, and other information captured as metadata while the vehicle containing the surveillance system is "on-patrol". All such video and audio data (including metadata) from a single or multiple "on- patrol" vehicles at block 1110 may be uploaded to a central storage area (e.g., a cloud) at the end of a law enforcement personnel shift. At decision 1115, it is determined by specially configured software/firmware if a captured data segment has an associated tag (e.g., event type). If not (NO prong of decision 1115) then a default tag and associated data retention policy may be applied to the captured data as shown at block 1125. The captured data segment for untagged capture may be stored in an area of a computer hard drive with continuous loop function such that oldest data is overwritten by newer data. Alternatively, if a data segment has an associated tag (the YES prong of decision 1115), a retention criteria based on the tag type may be applied and the appropriate data stored with other tagged data as illustrated by block 1120. As required, any necessary evidentiary access controls as illustrated by block 1120 may be considered. At block 1130, data mining is performed. Information gathered from the data mining function may be used to provide a global index of data (e.g., index of data across all available metadata). Indexed data remains available until the time limit for data retention is reached and then data (and its associated index information) may be expunged. However, if as in block 1135, an unpredicted event occurs, for example, a bombing, terrorist activity, report of previous criminal activity etc., then, at block 1140, the data mined in block 1130 (for a particular location, date and time) may be retrieved to assist with investigation and evidence gathering. Optionally, as shown in block 1145, the overall system may be configured to proactively apply analytics to the captured metadata to identify possible criminal activity or potential threats to public health and safety (e.g., face or pattern recognition analysis to identify a known criminal or threat). Such analysis may then be used to produce an analytics report as is shown at block 1150. The analytics report, for example, may then be reviewed by law enforcement personnel to assist with an investigation or determine if further investigation is required.

[0089] Collecting metadata from multiple surveillance systems to create a comprehensive index may allow a law-enforcement agency to correlate information from different systems. For example, if a set of recordings from different patrol cars at a given geographical location is of interest, then the metadata containing GPS information may identify a subset of multi-media files that may be of interest. If multiple agencies use a common global index, they may be made aware of recordings that other agencies have obtained that would otherwise be unknown to them. After following appropriate legal procedures, they may obtain access to recordings from other agencies to assist in gathering evidence. Note that access to actual multi-media recordings may not be made available because of privacy concerns, for example, but the global index informs of the existence of potentially relevant information. In this manner, coordinated inter-agency information sharing may be enhanced. The hybrid storage model facilitates creation of a global index because the overall size of actual multi-media recordings across numerous surveillance devices may quickly become unmanageable. Additionally, chain of custody of evidence and access controls to actual multi-media files may be maintained.

[0090] Each agency may implement the hybrid storage model as necessary based on its size and infrastructure capabilities. Hybrid techniques may also be implemented as a sliding scale. That is, at one extreme a maximal hybrid technique uploads all (or nearly all) captured metadata and associated multi-media files. For example, a large police station with a big cloud presence and high bandwidth might use the maximal hybrid model. In another extreme, a minimal hybrid technique would upload only enough metadata for indexing and very few (if any) multi-media files. The minimal amount of metadata may allow for global indexing as necessary so that, when required, additional upload of data may be requested from the agency implementing the minimal hybrid model.

[0091] Referring now to Figures 12A-F, examples of the metadata referenced throughout this disclosure are shown in an example XML file format. Note that because of the structure provided by XML each of the metadata portions of Figures 12A-F may be stored in a single file, multiple files or any other appropriate segregation. Each element of an XML file is partitioned by tags (i.e., <row> followed by </row> as shown in Figures 12A-F). For example, a start tag (i.e., <row>) as shown at the beginning of element 1205 and an end tag (i.e., </row>) as shown at the end of element 1205. According to some disclosed embodiments, the actual root name of the file (e.g. filename with no extension) is uses as a key for associating the recorded audio/video with the appropriate metadata file. Inside the example element 1205 of Figure 12A there are attribute/value pairs to provide a metadata parameter name and its associated value for that element. Metadata attributes have self-evident names and therefore are not discussed individually here. The examples provided are simply to illustrate that a multitude of different types of data may be captured and used to index or further maintain associated captured surveillance data. In these examples, Figure 12A illustrates a video metadata file for a captured video segment while Figure 12F illustrates an XML segment that contains the VX-Sync data. In this embodiment, the "V" of "VX" is used to reference the particular video and the "X" to reference any event variable associated with the particular video. For example, during the recording, any action taken by a user, such as an action that triggered the recording, e.g. pushing a wireless microphone, or activation of a light bar, or the taking of a snapshot, will be recorded in this metadata file and associated with the variable X for future connection with the video V. Figure 12B illustrates a sample metadata file with attributes and values relating to in-car activity logs based on personnel shifts, while Figure 12C illustrates a file portion that relates to GPS location metadata based on personnel shifts, and Figure 12D illustrates in-car error logs per personnel shift. In the example shown in Figure 12D, there are no errors to report. Figure 12E illustrates an example metadata file that may be used to establish an audit trail for the associated video to satisfy evidentiary requirements relating to chain of custody.

[0092] Figure 12C illustrates a series of "collected" metadata elements where several attributes have been assigned values based on data collection. For example, the attribute "patrol unit" has a value to identify a particular police vehicle and the officerlD attribute has a value corresponding to the identification of a specific officer. Note that officerlD may be initially blank as in elements 1220 and 1225, and then be assigned an ID number as an officer logs onto (e.g., successfully authenticates to) the integrated system 100 (FIGS. 1A and IB) as in shown in element 1230. Another attribute may be "log time" (element 1235, FIG. 12E) which is the date and time that a data record is captured. Yet other attributes which are self explanatory based on their name may be changes in longitude and latitude indicating that the vehicle is in motion and the speed at which the vehicle is in motion.

[0093] Referring now to Figure 13, diagram 1300, illustrates a possible embodiment of a plurality of multiple user devices communicating with integrated mobile surveillance system 100. For example, smart watch device may communicate with Bluetooth connectivity to system 100. Additionally, each peripheral device may communicate with each other peripheral device and ultimately provide information to integrated surveillance system 100 for storage on previously described storage devices. The Body cam or smart watch may also be used as wireless microphone alternative or in addition to wireless microphones. Each peripheral device may also be configured to store audio or audio/video and a metadata locally as well as transmit or stream to another device while simultaneously storing locally. Locally recorded information from any peripheral device may also be uploaded to and synchronized with other devices that may have been triggered and activated to record. These functions may also be synchronized with any of the devices in the total system as well as a cloud based data management/synchronization server. [0094] Figures 14A, 14B, 15A and 15B illustrate further detail and variations of removable storage devices 285 and 286 of Figures 2A and 2B, according to some disclosed embodiments. Turning first to Figures 14A and 14B, plug-in storage drive 1450 illustrates an SD (Secure Digital) card. SD cards (e.g., 1450) may have a lock switch 1456 which, when in the lock position, puts the SD card 1450 into a read-only state such that no data in the memory of the SD card 1450 may be changed in any way (including protection against formatting). In addition to one or more internal mass storage specific flash memory chips (not shown), the SD card 1450 may also include an on-card intelligent controller (block 1457) having functionality that may be implemented using firmware instructions. The controller 1457 typically manages interface protocols to allow access to the flash memory of SD card 1450 and may also be used to implement, among other things, security algorithms for copyright protection, data storage and retrieval, as well as Error Correction Code (ECC) algorithms, defect handling and diagnostics, power management, and clock control.

[0095] Figure 14B illustrates plug-in storage drive 1455 in the form of a USB flash drive (also referred to as a flash drive, pen drive, thumb drive, or simply USB drive). A USB flash drive is a data storage device that includes flash memory (e.g., SD card 1450) with an integrated Universal Serial Bus (USB) interface (e.g., 1460) and its associated control logic 1458 (e.g., firmware instructions). It will be noted that control logic 1457 and 1458 provide similar functionality for each of plug -in storage drives 1450 and 1455 respectively but are not necessarily (and likely not) the same set of instructions for different types of storage devices. USB flash drives (e.g., 1455) are typically removable and rewritable, and physically much smaller than an optical disc (not shown). When a USB drive (e.g., 1455) is plugged into a computer device (e.g., device 200) a process referred to as "enumeration" is typically initiated. Enumeration refers to an end-to-end process of making a USB drive (e.g., 1455) accessible to a computer device and its operating system. The enumeration process includes identifying and assigning unique addresses to a plugged-in device and supports making USB drives "hot pluggable" (e.g., the drive may be plugged in without restarting of the computer device or computer system). A computer device (e.g., device 200) typically cannot fully communicate with or access the functionality of a USB drive (e.g., 1455) until that device has been properly enumerated. [0096] Referring now to Figures 15A-B, storage devices 1550 and 1555 are similar in functionality to storage drives 1450 and 1455. However, they are depicted as having added security modules 1570 and 1571. Security modules 1570 and 1571 may be incorporated into pre-existing control logic (e.g., 1457 and 1458) or may be implemented as an additional layer of instructions. In either case, security modules 1570 and 1571 represent a modification to standard interface protocols for access to memory modules on their respective protected storage devices 1550 and 1555. Security modules 1570 and 1571, according to some disclosed embodiments, further protect the integrity of data access to memory modules of the disclosed protected storage devices 1550 and 1555 by implementing the disclosed additional level(s) of authentication required for access by an operating system of a computer system (e.g., device 200) as discussed further below. It will be noted that when lock switch 1456 is in the locked position for protected storage devices 1550 and 1555, lock switch 1456 performs its normal function of making the storage device read-only, however, security modules 1570 and 1571 may further prevent any access to data by keeping the storage device (e.g., 1550, 1555) "hidden" as explained further below.

[0097] Figure 16 illustrates a block diagram 1600 depicting a representation of a simplified layered model with functional units at each level of a computer device to assist in describing aspects of embodiments of secure storage drives in accordance with this disclosure. Each of the functional units in a level typically interfaces only with the next adjoining level such that levels are not bypassed. Bypassing of levels may pose security risks and therefore designers of computer systems adhere to a model as shown in block diagram 1600 (or a similar model). User 1605 (e.g., a human user of a computer device) is positioned at the highest level (level 5) of this model. At the lowest level (level 1), the physical hardware 1630 is represented. From the bottom up, starting at physical hardware 1630, hardware components of a computer system (e.g., device 200 of Figure 2A) communicate with device drivers 1625. Device drivers 1625 are configured to understand how to communicate with each piece of physical hardware and provide an interface to the operating system 1620 (level 3). Without a device driver (e.g., 1625), an operating system 1620 would have to incorporate device specific code to be able to interact with a particular hardware device. For the purposes of this disclosure, device drivers 1625 at level 2 are not considered part of the operating system 1620 at level 3. That is, even if a device driver 1625 has awareness of a particular piece of physical hardware (1630 at level 1) and has not allowed access to the operating system 1620 at level 3, it is considered that the particular piece of hardware is not accessible to the operating system 1620 or any of its commands. In other words, a particular piece of physical hardware at level 1 that has not been made accessible to operating system 1620 at level 3 would remain "hidden" to the operating system 1620. To complete the model discussion, command shell 1610 and applications 1615 provide an interface between a user 1605 of the computer system and the operating system level 1620. In general, command shell 1610 and applications 1615 provide user 1605 with access to functionality being provided by a computer device (e.g., device 200).

[0098] Referring now to Figure 17, process flow 1700 illustrates one possible method of configuring a computer system (e.g., computer device 100) and a secure removable storage device (e.g., 1550 and 1555) according to some disclosed embodiments. Because of requirements of law enforcement policies and procedures, access to and modification of data collected in the line of duty must be strictly controlled. One example requirement is that a "chain of custody of evidence" must be maintained. Chain of custody, in legal contexts, refers to chronological documentation or audit trails, showing the seizure (e.g., recording), custody, control, transfer, analysis, and disposition of physical or electronic (e.g., digital video/audio data) evidence. When evidence may be used in court to convict persons of crimes, it must be handled in a careful manner to avoid later allegations of tampering or misconduct which may compromise the case. Audit logs may, for example, contain an itemized list documenting access and/or alteration of any recorded potential evidence information whether by a user or additional computer system. The disclosed secure removable storage devices (e.g., 1550 and 1555), in conjunction with other aspects of law enforcement computer systems, may be used to assist in maintaining a proper chain of custody. Beginning at block 1705, a storage device such as storage devices 1550 and 1555 may have its firmware updated or receive additional firmware instructions such as being programmed with an "unhidden key" and optionally decryption information. The decryption information mentioned here relates to the function of decrypting the "unhidden key" and may or may not relate to encryption of any other data on the secure storage drive or possibly a self-contained secure storage drive. At block 1710, a computer device (e.g., device 200 of Figure 2A) may have its device driver augmented or replaced such that the device driver may supply one or more defined "unhidden key(s)" upon detection of a storage device. In one example embodiment, the device driver supplies the "unhide" information in encrypted form to further enhance security of the unhide information itself. At block 1715, the unhide instructions (or the updated device driver itself) may be "locked" to a specific computer device. Locking this information to a specific computer device may further protect against copying of the device driver and unhide information to a different computer device than the one that has initially been configured for access to a corresponding storage device. Locking of the device driver and/or unhide information to a particular computer device may be performed by ensuring that the command associated with providing the unhide information (e.g., unhide key) only functions properly after having verified an attribute of the computer system at execution time. For example, the command(s) to provide the unhide key may check one or more of: a Central Processing Unit Identifier (CPUID), a media access control (MAC) address of a network card associated with a computer system, or some other unique or predetermined attribute of the computer system. At block 1720, the unhide information may be further configured to optionally include additional authentication information prior to allowing access to a secure storage drive (e.g., 1550 and 1555). The additional information may include user identification (UID), user group identification (GID), or the like. In this example embodiment, a secure storage drive will only become unhidden when plugged into (e.g., connected to) a computer device that has the proper unhide information and only while a proper user is authenticated to the computer device. This may prevent, for example, access to information on a secure storage drive from a properly configured computer device by an improper user. Such two-factor authentication thus requires that both the storage device and the officer pass authentication (i.e. the officer is a proper user) prior to the secure storage drive becoming "unhidden" and accessible.

[0099] As explained above, a device driver on a computer device such as device 200 may be augmented or replaced to include additional or altered instructions to provide the disclosed unhide information. The device driver may be altered by changing instructions internal to the original device driver, by providing an altered dynamic load library (DLL), by installing a new device driver, or by many other implementation specific methods. This disclosure does not confine itself to any one method of implementation for updating a computer system to have a device driver enabled to provide the appropriate unhide information. Additionally, augmentation of a device driver on a computer device may include providing multiple different combinations and permutations of unhide information for a single computer device. That is, a single computer device may be configured to be able to access and unhide a plurality of different secure storage drives based on properly providing any required secondary authentication information (e.g., UID, GID).

[00100] Referring now to Figure 18, process flow 1800 illustrates one possible method for configuring a self-contained storage device according to some disclosed embodiments. Beginning at block 1805, one or more applications to pre-configure for self-contained execution may be identified. This identification may be in response to user defined requirements or based on a definition provided by a software architect, for example. The identified application or set of applications (e.g., application suite) may be identified to satisfy functional requirements, business need, etc. Next at block 1810, a storage drive or a secure storage drive may be selected to contain the pre-configured application(s). This decision may be based on security requirements for access to the pre-configured applications or the data the pre-configured applications may have access to. For example, evidence information used in law enforcement may have stringent access requirements as discussed above. At block 1815, a main launch application may be selected. For example, if the self-contained storage device has an application suite pre-configured there may be a single main application that a user would launch to gain access to functionality of the entire suite. Flow continues to block 1820 where run-time references to secondary applications and configuration information may be defined to facilitate self-contained execution. Run-time references may be defined in a number of ways, for example, they may be defined using Uniform Resource Identifiers (URIs), Uniform resource locators (URLs), Uniform Resource Names (URNs), or other information. A URI can be a URL or a URN or a combination of both. In a simple example, a URN functions like a person's name while a URL resembles that person's street address. That is, the URN defines an item's identity, while the URL provides a method for finding that identity. At block 1825, a software engineer, for example, may embed run-time references to resources (e.g., other applications, etc.) into selected applications and/or configuration files to allow for dynamic (e.g., run-time and/or realtime) resolution of an actual location for those resources. At block 1830, a set of applications and/or configuration files that have been altered (i.e., pre-configured) to include run-time references as appropriate may be copied onto the selected storage drive. At block 1835 the storage drive with all information required to be self-contained may function as a "plug-n-play" application suite. A plug-n-play application suite is another way of saying that a suite of applications are "self-contained" on a storage device in that they may be executed upon plugging in the storage device without requiring any kind of software application installation process on the part of the user. Clearly, this approach has advantages over prior art techniques because upgrading an application suite may be accomplished simply by plugging in a different storage drive.

[00101] Referring now to Figure 19A, process 1900 illustrates one possible flow for installation of one or more computer software applications for execution on a computer system. Beginning at block 1905, one or more applications are identified for installation on a computer system/device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3). Identification of applications in this example may be performed by a user, software architect, or technical support person, for example. At block 1910 each identified application may be installed individually on an appropriate computer device. Block 1915 indicates that the installation process of each application will likely check for compliance with other installed applications and capabilities of the computer device itself. That is, each installation process will attempt to prevent conflicts with other installed applications (as further discussed below) and make sure that hardware capabilities of the computer device support the application being installed. Conflicts between applications may occur because different applications may expect different versions of dynamic load libraries (DLLs) for proper execution. When multiple applications that are destined to be installed on a single computer device require different versions of a particular DLL a "catch 22" situation may exist because a computer device may be able to support only a single version of that specific DLL at one time. Thus, the application that is later installed will "win" and an earlier installed application may not function properly. This situation is sometimes referred to as "DLL Hell" because it is difficult, if not impossible, for a technical support person to resolve. "DLL Hell" is thus avoided through use of the self- contained storage device disclosed herein.

[00102] At block 1920 each installation process may update the registry and storage drive (e.g., internal storage device) associated with the computer device. Block 1925 indicates that after all identified applications have been installed on the computer device a user may attempt to initiate application execution. If all applications and application components properly completed their installation process without detecting or causing conflicts then the applications may function properly (the one or more applications execute correctly) using the installed components and registry for additional run-time information as indicated at block 1930.

[00103] Referring now to Figure 19B process 1950 illustrates that installation of applications (as in process 1900) may be bypassed by using a self-contained storage device according to some disclosed embodiments. Bypassing the installation process may prevent some of the above mentioned issues and in general simplify use of an application or application suite for a user. Beginning at block 1955 a user plugs in a removable self-contained storage device configured in a manner identical to or similar to process 1800 discussed above. At block 1960 the computer device that is now connected to the removable self-contained storage device may optionally authenticate and allow access to (i.e., unhide) the storage device if the plugged in storage device is a secure storage drive. At block 1965 the computer device has access to the standard or secure self-contained storage drive and a user may initiate execution of an application or application suite by simply causing the main launch application to execute. Note that it is possible to have more than one application that can perform as a main launch application on a single self- contained storage device. At block 1970 the application or application suite executes from the self-contained storage device using its own pre-configured run-time resolution of reference pointers (as described for Figure 18) and may not require any additional execution from applications previously installed on a different storage medium associated with the computer device. Additionally, applications on a self-contained storage device may not require access to or updating of a registry on the computer device for their proper execution.

[00104] Referring now to Figure 20, process 2000 illustrates one method of automatically updating firmware and/or software portions of a computer device prior to execution of applications from a self-contained removable storage device according to some disclosed embodiments. Beginning at block 2005, a self-contained storage device, for example configured in accordance with process 1800, is plugged into a computer device (e.g., device 200 of Figure 2A, or the computer device shown in Figure 3). At block 2010, the computer device that is now connected to the self-contained removable storage device may optionally authenticate and allow access to (i.e., unhide) the storage drive if the plugged in storage drive is a secure storage drive. At block 2015, the computer device automatically scans the storage device (e.g., storage device or secure storage drive) for possible updates. Note the computer device may be configured to scan any storage device that is plugged in to determine if there are available updates or may be configured to only scan for updates if a secure storage drive is plugged in. At block 2020, the computer device may automatically apply updates to software and/or firmware of the computer device if updates are found during the scan. In this manner a computer device may be updated and kept more current (or consistent with any updates available on a self-contained storage device) without the user of the computer device having to install updates to the computer device. In one example, if the application suite on a self-contained storage device requires a specific version of firmware code (either older or newer) then that version of firmware code would be automatically installed on the computer device upon plugging in the self-contained storage device to ensure proper execution of applications from that self-contained storage device. Alternatively, scanning code can be designed to ignore any software and/or firmware updates on the storage device that are older than the software and/or firmware already installed on the computer device. These different implementation strategies are a design choice and may differ for different computer devices/systems.

[00105] With the above understanding of different embodiments of secure storage drives and self-contained application storage devices, we now discuss embodiments of portable cameras (e.g., body worn cameras 2150, Figures 21A-C) to assist in comprehensive surveillance capabilities for companies or agencies, such as law enforcement. Note that disclosed embodiments of portable cameras are not limited to law enforcement and may be utilized by anyone desiring a portable surveillance system. For example, assistance personal at a retail outlet may be equipped with a portable camera to capture potential shop lifting evidence, or to record information for potential liability cases such as work related accidents, and so on. Many different uses of portable cameras configured according to the disclosed embodiments are envisioned.

[00106] A portable body worn camera (e.g., 2150) may have different requirements than an in car surveillance system for many reasons. For example, body worn camera 2150 will not always have access to an additional power source (e.g., car battery) and will likely be substantially powered by a battery pack (or any self-contained, portable power source). In some embodiments, the disclosed portable camera 2150 may include a removable battery pack as the primary power source and an internal secondary "back-up" power source. The internal power source will likely not be able to maintain functionality for a long time period and may provide enough time to allow the portable camera (e.g., 2150) to maintain operation (and data integrity) while a battery pack is exchanged for another battery pack, for example. Additionally, a body worn camera 2150 may have different size and weight constraints as compared to an in car surveillance system. These are just two examples of the many design choices that may be considered when distinguishing body worn cameras 2150 from other types of surveillance equipment and systems.

[00107] Referring now to Figures 21A-C, views 2100, 2120, and 2125 in Figures 21A, 21B, and 21C, respectively, depict different aspects of disclosed embodiments of a body worn camera 2150. View 2100 illustrates that the camera portion (2110) may be mounted on a swivel bracket 2105 that may also act as a "hinge" as shown in view 2125. A directional microphone 2115 may, optionally, also be included to capture sounds from a direction consistent with the orientation of body worn camera 2150. Microphone 2115 may be an Omni-directional microphone with noise cancelling technology. Microphone 2115 may be utilized as a wireless microphone link communicating over any of the wireless communication technologies discussed herein or known in the art and potentially replace functionality that may be provided by remote microphones. Integrating this functionality into body worn camera 2150 may reduce the amount of equipment an officer must wear/carry. Accordingly, body worn camera 2150 may be configured to act in different modes as required, such as, audio only, video only, metadata only, control link only, or any combination thereof. Body worn camera 2150 also may include programmable hard keys as shown in Figure 22 element 2205 and described below.

[00108] Disclosed embodiments of a body worn camera 2150 may include one or more of the following additional features. A High Definition (HD) camera supporting different resolution recording modes (e.g., 4K, 1080P, 720P, etc.). A Liquid Crystal Display (LCD) or a Light Emitting Diode (LED) display along with or in addition to LED light indicators to indicate operational status of body worn camera 2150. An internal storage drive optionally configured as the above discussed self-contained storage device and/or secure storage drive (e.g., 1550, 1555 of Figure 15). Functionality of a self-contained storage device internal to embodiments of the body worn camera 2150 may provide the body worn camera with the same or similar functionality of the above discussed in car video system (see Figure 3). Advanced functions may also include license plate recognition and/or facial recognition capability. Body worn camera 2150 may include multiple cameras of the same or different resolutions and may optionally connect to external cameras instead of or in addition to an integrated camera. For example, body worn camera 2150 may connect using wired or wireless technologies to a camera integrated or attached to a vest worn by a police officer. If configured with multiple cameras, body worn camera 2150 may simultaneously record multiple video streams (e.g., concurrently record and associate metadata with multiple video inputs). As with conventional video cameras, body worn camera 2150 may optionally operate in still photo mode, take still photos in rapid succession, or operate in other modes such as panorama.

[00109] Authentication of body worn camera 2150 and access to any internal recordings may require authentication of a secure storage drive (e.g., 1550, 1555 if so configured) and/or authentication of a user to the body worn camera 2150 device itself. Authentication of body worn camera 2150 may be accomplished using wireless communication interfaces or by physical contact with (e.g., cable connection, pogo pins, sync contacts, etc.) another previously authenticated device (e.g., the device shown in Figure 3). Authentication to body worn camera 2150 may also be assisted via, or be part of, a single sign-on process. The single sign-on process may be initiated on a different device and communicated to body worn camera 2150 via one if its communication interfaces (wired or wireless). Alternatively, a previously authenticated body worn camera 2150 may assist in authenticating a user to another device using a similar single sign-on process. That is, body worn camera 2150 may be an initiator or a recipient device in a single sign-on process. Communication interfaces for the disclosed body worn camera 2150 may include one or more of integrated broadband 3G/4G, Wi-Fi, Bluetooth, and RFID/NFC. Note that each of these interfaces, in particular, (radio frequency identification) RFID and (near field communication) NFC interfaces may be used for data exchange, device authentication, and/or device control. One or more of video, audio, metadata, control communication, and/or streaming, may be configured to function over any available and compatible wireless communication interface in a bidirectional manner. That is, body worn camera 2150 may be remote controlled from another device or act as a remote control for another device (e.g., mobile surveillance system shown in Figure 3). As discussed in more detail below, disclosed embodiments of a body worn camera 2150 may include docking ports (see Figure 22), USB ports, and record triggers that may initiate recording automatically based on events, signals, timers, etc. Record triggers may include signals from a wireless heart rate monitor (possibly embedded in a watch worn by the user of the body worn camera 2150) or monitors to detect removal of a gun/taser/club from its holster, for example. These sensors and/or triggers may communicate with body worn camera 2150 using any of the above discussed wireless communication protocols, for example.

[00110] Other ports on a body worn camera 2150 may include charging ports/plugs and vehicle or office docking ports to plug into a docking station (e.g., docking station 2200 of Figure 22) or provide system expansion, for example. Disclosed embodiments of a body worn camera 2150 may also include a GPS for providing location and time synchronization information as well as an accelerometer to determine camera orientation. The integrated GPS may be used to coordinate data for map trace functions as well as officer position data by sending a periodic beacon or other types of data transmissions directly to a remote location via the integrated broadband or relay through a vehicle radio, Wi-Fi or broadband data link. These and other sensors may also be used to detect gunshots, abrupt motion of the camera that may be caused by an accident (e.g., car accident) or fall of the person wearing camera 2150, and other indications of possible distress. In these instances, recording may be initiated, or if already initiated (or after automatic initiation) a recording may be automatically tagged with an incident tag indicative of the type of incident detected. Body worn camera 2150 may maintain a Bluetooth or other wireless connection with an in car system while the body worn camera 2150 is in use to facilitate streaming of captured information to another location or to automate upload of recorded data to a secondary device, for example. Programmable hard key buttons (e.g., 2205 of Figure 22) and soft buttons on a touch screen (not shown) of body worn camera 2150 may be incorporated to allow users to define one button operational modes for body worn camera 2150. Some embodiments of the disclosed body worn camera 2150 may also be configured to monitor for and accept voice commands. The voice commands may be used for authentication using voice recognition prior to accepting other commands. Voice recognition may also be required prior to (or in conjunction with) allowing additional authentication of body worn camera 2150.

[00111] Referring now to Figure 22, advanced docking station 2200 may provide additional benefits for users that maintain a plurality of portable body worn cameras (2150) and may assist in data upload, device checkout, device upgrade (e.g., firmware/software update), recharging of battery packs and other maintenance type functions that may be performed, for example, at a police station. For clarity, not all repeated elements in Figure 22 have an associated reference number. Embodiments of the disclosed docking station may support maintenance functions for multiple body worn cameras (2150) concurrently. Note that Figure 22 illustrates two hard key programmable function keys 2205 for body worn camera 2150 that were not visible in the views of Figures 21A-C. The disclosed docking station 2200 may be multifunctional for uploading and/or downloading of video/audio and associated metadata. Configuration data such as unit ID, user ID, operational modes, updates, and so on, may be maintained and versions of such configuration information may be presented on display screen 2210 (which may also be a touch screen interface to docking station 2200).

[00112] Docking station 2200 may have integrated interfaces to portable camera 2150 such as, USB, wired Ethernet or wireless network, as well as interface ports for battery charging. Docking station 2200 may also contain: a CPU and be configured as a computer device (see Figure 1) optional integrated touch screen display 2210, output connectors (not shown) for an optional external display/mouse or device expansion. Docking station 2200 may have an option for a wireless display (not shown) to be used for status indication as well as for an interface for checkout/assignment of the smart wearable device to a user or group of users. Docking station 2200 may include wireless communications such as Bluetooth and/or 802.11AC/AD. Docking station 2200 may be configured to work as an Access Point for a wireless network or may be configured to act as a bridge to allow portable client devices to access functionality of docking station 2200 and possibly connect to other system components including local or cloud based servers.

[00113] Embodiments of docking station 2200 may be configured to interface with tablets or smart phones as a user interface to provide for full remote functionality. As shown in Figure 22, docking station 2200 may have multiple ports/cradles (2215). As an example, docking station 2200 may have a "5 bank" or "10 bank" of ports/cradles (2215). Multiple docking stations such as docking station 2200 may be stacked or daisy chained together as one possible expansion mechanism.

[00114] Docking station 2200 may also have an internal storage device to facilitate fast off-load storage to facilitate a download/forward process for audio/video and data captured on the portable device (e.g. the body worn camera 2150). For example, the user may place the body worn camera 2150 into docking station 2200 and docking station 2200 offloads the data to the local onboard storage drive (not shown) which can immediately (or based on a timer) upload that information to a server (e.g., back office server or cloud storage). Uploads could be prioritized based on many different attributes such as time, size, event type priority, and so on. Docking station 2200 may also have an integrated locking mechanism for one or more of the uploading/charging ports/cradles (2215). The docking station 2200 may be configured to control the locking mechanism to hold or release the wearable device in order to prevent the user from taking it out during uploading/downloading, or to make sure that only the recently "checked out" device is removed, for example.

[00115] The touch screen display 2210 of Figure 22 illustrates one possible graphical user interface (GUI) layout as an example only. Actual layouts may contain more information and features and may be configurable based on requirements of different end users. In Figure 22, the GUI shows examples of upload status and battery charging progress. Other screens may be available on the GUI display 2210 to provide other status information such as unit ID, user ID, and/or to assist with user checkout and assignment of devices to different mobile surveillance systems. Recall, that a secure storage device (e.g., 1550 or 1555 of Figure 15) that may be integrated into portable camera device 2150 may only become "unhidden" when they are "connected" to an appropriate computer device such as a specific patrol unit having an associated mobile surveillance system such as that shown in Figure 3. As explained above, these types of controls may be necessary to facilitate compliance with chain of custody of evidence requirements.

[00116] Referring now to Figure 23, process flow 2300 illustrates a possible method for assisting law enforcement personnel with compliance of chain of custody of evidence requirements for legal evidence. Chain of custody of evidence requirements may be implemented with the assistance of docking station 2200. In this example, the computer device at the police station is considered to be docking station 2200 (but could be another workstation type device for example) and a computer device in a police car, for example, will be referred to as a "mobile surveillance system." Both docking station 2200 and the mobile surveillance system are examples embodiments of device 200 of Figure 2A described above. Also, in this example the storage device may be referred to as a secure storage drive in certain situations, but aspects of this example are clearly applicable to a standard storage device and may be beneficial independently of a specially configured secure storage drive. In addition, while this example refers to a portable recording apparatus including a storage device, it is also applicable to a storage device on its own, independent of a portable recording or other apparatus. Beginning at block 2305 a portable recording apparatus (e.g., body worn camera 2150) including a storage device (e.g., secure storage drive 1550, 1555) is "checked in" at a police station, for example. In the "checked in" state the portable recording device (e.g., body worn camera 2150) may be connected to docking station 2200 that is configured to interact with the storage device in an "unhidden" manner. That is, docking station 2200 may be configured with the required information explained above to allow access by the operating system to a secure storage drive integrated into one or more portable recording devices (e.g., body worn camera 2150). At block 2310, docking station 2200 receives a request to assign a portable recording device (e.g., body worn camera 2150) to an officer (e.g., Officer "Joe Smith") for use in a patrol "shift." The request may, for example, come from a GUI presented on touch screen 2210. Optionally, the request may also include information to assign the storage device and associated portable recording device (e.g., body worn camera 2150) to a particular mobile surveillance system for that shift (e.g., surveillance system of "patrol car 54"). At block 2315, docking station 2200 writes control information to the storage device of portable recording device (e.g., body worn camera 2150) to identify an appropriate mobile device (e.g., a device shown in Figure 3). The control information may include storage serial number, officer's ID (e.g., "Joe"), patrol car (e.g., "54"), officer's password (likely encrypted), recording parameter settings, or other information useful in assisting in audit tracking of the portable recording device (e.g., body worn camera 2150) and any information collected on the storage device of the portable recording device (e.g., body worn camera 2150) during the shift. At block 2320, the portable recording device (e.g., body worn camera 2150) is removed from docking station 2200 for association with a mobile surveillance system (e.g., a device shown in Figure 3). The portable device (e.g., 2150) is now in a "checked out" state.

[00117] At block 2325, the officer authenticates to a mobile surveillance system. The storage device is plugged in (e.g., connected by connecting the portable device (e.g., 2150)) to the mobile surveillance system at block 2330. Flow continues to block 2335 where the storage device of the portable device (e.g., 2150), if a secure storage device (e.g., 1550, 1555), is unhidden. Clearly, a secure storage drive will only become unhidden if the mobile surveillance system is configured to properly authenticate to the secure storage drive of the portable device (e.g., 2150). Authentication requires the mobile surveillance system be pre-configured to access this particular secure storage drive using "unhide information" as described above and may optionally only unhide after a second check that a proper officer has authenticated to the mobile surveillance system. That is, both the secure storage drive in the portable recording device (e.g. body worn camera 2150) is associated with a proper surveillance system (e.g., a device shown in Figure 3), and the authenticated user will be validated as a proper user. In other words, Officer "Joe Smith" is authenticated to the mobile surveillance system and the mobile surveillance system is the one in patrol car 54, which Officer Smith should be using for his shift prior to allowing any access to the secure storage drive of the portable device (e.g., 2150) from the mobile surveillance system. Such increased authentication methods may assist in compliance with chain of custody of evidence requirements for gathering and maintenance of evidence.

[00118] At block 2340, as the officer performs his shift duties (e.g., goes on patrol, etc.) and the mobile surveillance system records and stores evidence and surveillance data onto the storage device of the portable device (e.g., 2150). During the shift, all data recorded on the storage device may be associated with the officer for audit tracking purposes as indicated at block 2345. For example, a metadata file may be used to "mark" any recorded data with officer's ID, event type, date/time, GPS location, etc. Block 2350 represents actions that may take place at the end of a shift, for example. After a shift is completed and the officer and mobile surveillance system return to the police station, recorded data may be securely (for example, but not limited to, by data encryption) uploaded wirelessly to a back office system at the police station. Securely uploaded, as used here, indicates that the recorded data will be uploaded in a manner as to maintain its association with the officer and maintain chain of custody of evidence requirements as well as any other type of security regarding the wireless network, etc. As an alternative to wireless upload, the officer may remove (e.g., disconnect) the portable device (e.g., 2150) and relocate the storage device to the same or a different docking station 2200 for upload at the police station. Clearly, a different docking station 2200 would also need to be properly configured to access the storage device of a portable device (e.g., 2150) if it is a secure storage device (e.g., 1550, 1555). At block 2355, the officer may "check in" the storage device so as to allow a different officer to use it on a subsequent shift, for example by using a GUI interface to docking station 2200. Note that some law enforcement agencies require a two-factor authentication for access to data. Validating "unhidden information" regarding both the storage device and the authenticated officer (e.g., both the association with the surveillance system of patrol car 54 and confirming Officer Smith is logged into that system) is one example of two- factor authentication.

[00119] Referring now to Figures 24A-B, Figure 24A illustrates view 2400 depicting a programmable wireless microphone 2450 and an associated single bay charging station 2410. Charging station 2410 includes a single locking clip 2415 (although, it is contemplated that multiple locking clips or other securing means may be used) to securely hold programmable wireless microphone 2450. Clearly, docking station 2200 described above may be configured with bays (not shown) configured to accept one or more programmable wireless microphones 2450 instead of or in addition to bays configured to accept body worn camera 2150. These bays for programmable wireless microphone 2450 may provide similar charging, upload, locking, etc. functions as those described above for body worn camera 2150. Figure 24B illustrates programmable wireless microphone 2450 from a different perspective view. Programmable wireless microphone 2450 may include an internal microphone 2435. Additionally, programmable wireless microphone 2450 may include a plug-in directional microphone (not shown) that has the ability to capture sounds from a direction consistent with the orientation of the directional microphone. Alternatively a microphone (e.g., 2435) may be an Omni-directional microphone with noise cancelling technology. In an additional embodiment, programmable wireless microphone 2450 may include a plug -in lapel microphone with inline control functions (e.g., buttons on cable) to allow easy access when programmable wireless microphone 2450 is worn under a jacket, bullet-proof vest, or other clothing, for example. As seen in figures 24A-B, wireless programmable microphone 2450 includes programmable buttons 2420, 2425, and 2430. These buttons may optionally include LED illumination to indicate "status" while in operation. For example, the LED illumination may change color when out of range versus when streaming to an associated base device. The LED illumination may also indicate if local recording is taking place, power status (e.g., on/off), battery status (e.g., fully charged, half charge, etc.), or other information. Of course, LED indicators (or something comparable) may be included that are not included in a button and the number and size of any indicators may vary based on need. Programmable wireless microphone 2450 may also have an integrated display (e.g., Liquid Crystal Diode (LCD) display) (not shown) to provide operational status and other information. Clip receptacle 2440 is shown in Figure 24B. Antenna 2445 may be included to support one or more of the integrated wireless communication interfaces (e.g., Bluetooth, NFC, RFID, 802.11, other radio frequency (RF) transmission).

[00120] In some embodiments, programmable buttons (e.g., 2420, 2425, and 2430) may be configured to control functional characteristics of programmable wireless microphone 2450. Programmable buttons (e.g., 2420, 2425, and 2430) may optionally initiate sending control information via one or more wireless communication interfaces to one or more associated surveillance system devices (e.g., mobile surveillance system shown in Figure 3). Additionally the multiple programmable buttons (e.g., 2420, 2425, and 2430) may be configured to support features such as mute, trigger recording on the backseat camera, blackout the display, lock the system, trigger emergency alert, voice recorder, etc. Programmable wireless microphone 2450 may also be configured to receive control commands via its wireless communication interfaces. Thus, a bi-directional communication link may be established between programmable wireless microphone 2450 and other surveillance system devices. Of course, bi-directional communication links may be established to allow communication between programmable wireless microphone 2450 and headquarters, command centers, other vehicles etc. Communications to distant locations may be facilitated by using another device (e.g., in-car system shown in Figure 3, cell tower, etc.) as an intermediary for relaying the transmissions.

[00121] Authentication of programmable wireless microphone 2450 and access to any internal recordings may require authentication of a secure storage drive (e.g., 1550, 1555 if so configured) and/or authentication of a user to programmable wireless microphone 2450 itself. Authentication of programmable wireless microphone 2450 may be accomplished using wireless communication interfaces or by physical contact with (e.g., cable connection, pogo pins, sync contacts, etc.) another previously authenticated device (e.g., a device shown in Figure 3). Authentication to programmable wireless microphone 2450 may also be assisted via, or be part of, a single sign-on process. The single sign-on process may be initiated on a different device and communicated to programmable wireless microphone 2450 via one if its communication interfaces (wired or wireless). Alternatively, a previously authenticated programmable wireless microphone 2450 may assist in authenticating a user to another device using a similar single sign-on process. That is, programmable wireless microphone 2450 may be an initiator or a recipient device in a single sign-on process. Communication interfaces for programmable wireless microphone 2450 may include one or more of integrated broadband 3G/4G, Wi-Fi, Bluetooth, and RFID/NFC. Note that each of these interfaces, in particular, (radio frequency identification) RFID and (near field communication) NFC interfaces may be used for data exchange, device authentication, and/or device control. One or more of audio, metadata, control communication, and/or streaming, may be configured to function over any available and compatible wireless communication interface in a bidirectional manner. That is, programmable wireless microphone 2450 may be remote controlled from another device or act as a remote control for another device (e.g., mobile surveillance system shown in Figure 3). As discussed in more detail above, disclosed embodiments of programmable wireless microphone 2450 may include docking ports (see Figure 22), USB ports, and record triggers that may initiate recording automatically based on events, signals, timers, etc. Record triggers may include signals from a wireless heart rate monitor (possibly embedded in a watch worn by the user of programmable wireless microphone 2450) or monitors to detect removal of a gun/taser/club from its holster, for example. These sensors and/or triggers may communicate with programmable wireless microphone 2450 using any of the above discussed wireless communication protocols, for example.

[00122] As briefly mentioned above, programmable wireless microphone 2450 may include an internal (or plugged in) storage drive (possibly secure storage drive e.g., 1550, 1555) to store captured audio information. Programmable wireless microphone 2450 may be configured to automatically stream captured audio information and associated metadata to another device (e.g., mobile surveillance system shown in Figure 3) using any of its configured wireless interfaces and may simultaneously record and stream. Alternatively, programmable wireless microphone 2450 may only store collected information locally when streaming capability is not available or determined to be unreliable (e.g., out of range, bad connection, etc.). Data stored locally may be time stamped using an internal clock or information from a GPS and later synchronized with other recording devices. GPS may also provide location data that may be used to coordinate data and map based search in addition to the aforementioned time synchronization. Programmable wireless microphone 2450 may be configured to have an internal pre -record buffer either stored on an associated storage drive or stored in additional internal memory. A user or administrator may define a record duration for the pre -record buffer and information in the memory associated with the pre -record buffer may be utilized using a circular queue mechanism. Programmable wireless microphone 2450 may also have an option to store audio only local recordings such as voice memos initiated by a user. Local recordings may also be reviewed using an ear phone port (not shown) for example. It is noted that capabilities of programmable wireless microphone 2450 and body worn camera 2150 may be integrated into a single comprehensive device configured to perform some or all of the functions described for each device above.

[00123] With the above understanding of different disclosed embodiments, an example scenario of use is presented here. This example is not intended to be limiting in any manner and is provided to describe a context for using and benefiting from the many different possible aspects of a self-contained storage drive integrated into a portable camera (e.g., 2150) or a wireless programmable microphone (e.g., 2450) according to disclosed embodiments.

[00124] It is a common dilemma for small law enforcement agencies adopting in-car video systems and/or portable camera surveillance systems to have to choose between manageability and technology complexity. A server based solution may require experienced computer technicians to maintain proper operation. In contrast, a non-server based solution may become challenging for maintaining system configuration, video search capabilities, and evidence life- cycle maintenance. A self-contained, removable storage device which stores a software application (or application suite), a media player, firmware/software updates for the mobile audio and/or video recording systems, and actual recorded audio and/or video or related metadata from the mobile audio and/or video recording systems (e.g., mobile surveillance system, body worn camera (e.g., 2150), remote audio recording radio/microphone (e.g., 2450)) is disclosed herein. This self-contained removable device may allow small police departments to utilize current technologies at a reduced overall cost. For example, a small police department utilizing self- contained storage devices may have benefits previously available only from server based solutions without the need to implement a server based solution or employ trained computer technicians. The software application(s) stored on the removable storage device may have any number of the following attributes: a) self-contained such that nothing is required to be installed on the computer device to run applications from the removable storage device; b) ability to manage configuration information of mobile video and/or audio recording devices used to store recorded media, related metadata, and audit logs; c) capable of moving recorded audio and/or video and snapshot images (e.g. digital photographs) to other storage areas securely; and d) capable of building catalogues for searching and indexing stored recordings (the recordings stored on the computer device or accessible via a network available to the computer device). The media player of the self-contained storage device allows for playing of available stored evidence. The disclosed firmware and/or software process allows for automatic maintenance of mobile surveillance devices, for example. The configuration information of the self-contained storage device may assist in chain of custody of evidence and authentication mechanisms including user logon information, device identity, and device configuration. All of the above capabilities of a self-contained storage device may be utilized by small and large police departments to streamline maintenance and upgrades for their fleet of vehicles containing mobile surveillance systems. Furthermore, while examples herein refer to police departments, it should be understood that the disclosure envisions broad applicability to any entity (e.g. FBI, CIA, DEA, Interpol, Scotland Yard etc.) involved in law enforcement activities which include, but are not limited to, functions that require maintenance of chain of custody of evidence.

[00125] We now turn to a further discussion of a cloud-based storage model for securing and auditing access to recorded information. The cloud-based storage model may be beneficial for both small and large law enforcement agencies as well as other industries.

[00126] Referring now to Figures 25A-B, process flow 2500 and its continuation process flow 2560 illustrate a possible method for uploading information to cloud based storage for access or distribution to interested third parties. The process flows 2500, 2560 may also assist law enforcement personnel with compliance to chain of custody of evidence requirements for legal evidence and other required maintenance functions as explained further below. In this example overall process flow, the recording device may for example be a mobile surveillance system or body worn camera 2150, the docking station may be docking station 2200 described above, and the back office servers may be the back office servers 1042 of Figure 10 described below. For clarity of reading, these specific examples and their reference numbers will not be repeated throughout the discussion. Also note that docking station 2200 is an example embodiment of computer device including a programmable control device (see Figure 2A) described above while back office servers 1042 may be more accurately thought of as computer systems (a superset of computer devices as used herein).

[00127] Beginning at block 2505, video recorded and its associated metadata are identified. This may happen during a patrol shift, or may happen at the end of a patrol shift. For example, as the officer performs his shift duties (e.g., goes on patrol, etc.), a recording device may record and store evidence and surveillance data onto the storage device of the recording device. During the shift, all data recorded on the storage device may be associated with the officer for audit tracking purposes and a metadata file may be used to "tag" or "mark" any recorded data with any number of pertinent attributes such as, officer's ID, event type, date/time, GPS location, etc. This "tagging" may happen automatically or manually as discussed above and shown at block 2510. Next, at block 2515 the recording device may connect to a network using one of many different connection types. Different types of connections may be available during a patrol shift (e.g., broadband, satellite link, and so on) or at the end of a patrol shift (e.g., WiFi, Bluetooth, broadband, satellite link, Ethernet, and so on). For simplicity, only a few specific examples are described here, but others would be apparent to those of ordinary skill in the art, given the benefit of this disclosure. At block 2520, based on a) the connection type and b) what other system/device the recording device has established a connection to, different process flow options are shown in Figure 25A as a non-exhaustive set of examples. Block 2525 represents that the recording device has connected to a back office server. Block 2530 represents that the recording device or possibly only its removable storage media has connected to a docking station. Also, as illustrated, it is possible to have a direct connection type from the recording device directly to SAAS and/or cloud storage as illustrated by block 2540. As illustrated in Figure 25A, the communication flows between the back office server and SAAS and/or cloud storage (i.e., block 2525 and block 2540) may be bidirectional. The communication flow between the back office server and the data offload and staging area (i.e., block 2525 and block 2535) may be bidirectional. The communication flow between docking station and SAAS and/or cloud storage may be bidirectional (i.e., block 2530 and block 2540). Each of these bidirectional links may be used to facilitate coordinated decision making regarding what information to u load/download/delete based on a) status of completion of transfer or b) retention criteria information (among other possibilities). Thus, coordinated decision making may take place across the different processing systems utilized to implement the overall methods of this disclosure.

[00128] After a connection is established (as shown at block 2525) between the recording device and one or more back office servers, the functionality of the one or more back office servers may interact with the recording device and either perform data offload and staging functions (block 2535) and/or communicate directly with SAAS functionality and/or cloud storage (block 2540). Of course, the back office servers may perform different offload functions based on the attributes of the multi-media files (e.g., metadata tags). For example, the back office servers may transmit some multi-media files with their associated metadata directly to the cloud storage while offloading others to a local offload storage area. Some multi-media files and their associated metadata files may be both staged locally and sent to the cloud concurrently. Many different options are available. Options discussed here are only to be considered non- limiting examples. Similarly, block 2530 indicates a connection has been established with a docking station such as docking station 2200. As explained above, some embodiments of a docking station may include functionality to automatically offload and stage data via the docking station itself and upload to cloud storage (block 2540). Additionally, like the back office servers, a docking station may, in some embodiments, communicate directly with SAAS and/or cloud storage (block 2540). Although not explicitly shown in Figure 25A, data offload and staging area may be internal to either or both of a docking station or back office servers and they may each be configured to access the other's internal area either directly or indirectly (e.g., via proxy connection). In any case, multi -media files and their associated data files are processed to determine which multi-media files and data to upload as shown at block 2545. The determination may be unilaterally made by any one of the above mentioned functional units (e.g., recording device, back office server, docking station, and SAAS functionality) or may be made in a coordinated fashion by one or more of the above mentioned functional units working together. As shown at block 2550, after a determination is made, the multi-media files and associate metadata may be uploaded. Additional multi-media files and associated metadata may also be uploaded based on manual selection. Finally, block 2555 indicates that recordings, associated data (e.g., metadata), and possibly additional control information is available in cloud storage.

[00129] Continuing on with Figure 25B, process flow 2560 begins at block 2555 when the multi-media recordings and associated information is available in cloud storage. At block 2565, interested third parties may be identified based on criteria associated with one or more of the uploaded multi-media recordings. After identification a method of "delivery" to the identified third party may be determined at block 2567. In this example, "delivery" may be either physical delivery or virtual delivery (e.g., via a network link). Block 2569 represents a physical delivery method where a copy of data uploaded to the cloud storage and accessible to the SAAS functionality may be put onto a media, such as Compact Disk (CD) or Digital Versatile Disk (DVD), for physical transfer to the interested third party. As indicated in block 2580, once a physical copy has been extracted from a cloud storage area, the SAAS and other control over the multi-media recordings is "lost." That is, the cloud functionality will no longer have control because the multi-media recordings have been extracted from it. Techniques to prevent and/or control access to the content of the physical media may be implemented through encryption or other types of Digital Rights Management (DRM) capabilities. An alternative to physical delivery and the "loss" of control would be to maintain control of the multi-media files in the cloud and send electronic notification and access information as illustrated in block 2571. Flow would then continue to block 2573 where a notification may be prepared containing a link (e.g., hyperlink, URL, URI, etc.) to the appropriate multi-media recording(s) for the identified third party. The link may further be embedded with information to convey to the interested third party information about the multi -media recording and/or its access restrictions. For example, the link may indicate that password security or possibly biometric security may be required to access the content pointed to by the link. The link may further inform the recipient of the type of access they have (e.g., review only, download, delete, etc.) and/or provide an indication of expiration date by which to access the content of the link. At block 2575, the third party may access the cloud based copy of the multi-media while it is still under the control of the cloud based functionality (e.g., SAAS and cloud storage). Block 2577 indicates that some users may be permitted to download a copy of the information. As indicated by the flow to 2580 for this case, once downloaded, some control capability may be lost as explained above. Block 2585 indicates that third parties may be optionally monitored for compliance with subscription criteria enforced by the SAAS or cloud based functionality. For example, a third party may be monitored for access attempts, bandwidth usage, storage usage, or other criteria that may be set out based on a level of subscription they are paying for with regards to the service. Finally, block 2590 indicates that while data is maintained on the cloud storage, the SAAS or cloud functionality may continue to enforce and monitor data retention policies, audit controls, and so on.

[00130] In light of the principles and example embodiments described and illustrated herein, it will be recognized that the example embodiments can be modified in arrangement and detail without departing from such principles. Also, the foregoing discussion has focused on particular embodiments, but other configurations are also contemplated. In particular, even though expressions such as "in one embodiment," "in another embodiment," or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments. As a rule, any embodiment referenced herein is freely combinable with any one or more of the other embodiments referenced herein, and any number of features of different embodiments are combinable with one another, unless indicated otherwise.

[00131] Similarly, although example processes have been described with regard to particular operations performed in a particular sequence, numerous modifications could be applied to those processes to derive numerous alternative embodiments of the present invention. For example, alternative embodiments may include processes that use fewer than all of the disclosed operations, processes that use additional operations, and processes in which the individual operations disclosed herein are combined, subdivided, rearranged, or otherwise altered. [00132] This disclosure may include descriptions of various benefits and advantages that may be provided by various embodiments. One, some, all, or different benefits or advantages may be provided by different embodiments.

[00133] In view of the wide variety of useful permutations that may be readily derived from the example embodiments described herein, this detailed description is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, are all implementations that come within the scope of the following claims, and all equivalents to such implementations.

Claims

CLAIMS What is claimed is:

1. A storage device for storing data, the storage device comprising:

a secure storage drive including a flash memory storage area;

a first portion of firmware instructions pertaining to access to the secure storage drive, the first portion of firmware instructions having access to unhide information stored on the secure storage drive, the unhide information pertaining to unhiding the secure storage drive;

a second portion of firmware instructions pertaining to access to the flash memory storage area; and

a data access controller configured to utilize the first and second portions of firmware instructions to control access to the secure storage drive and the flash memory storage area; wherein the first portion of firmware instructions comprise instructions that initiate execution upon connection of the secure storage drive to a computer device, and prevent completion of an enumeration process of the secure storage drive with the computer device unless the computer device provides proper authentication information upon a start of the enumeration process of the secure storage drive with the computer device, the proper

authentication information corresponding to the unhide information, and

wherein upon receipt of the proper authentication information, the first portion of firmware instructions allows completion of the enumeration process of the secure storage drive with the computer device and allow the second portion of firmware instructions to control access requests from the computer device to the flash memory storage area.

2. The storage device of claim 1, further comprising a USB interface for connection to the computer device.

3. The storage device of claim 1, wherein the first portion of firmware instructions execute prior to the second portion of firmware instructions.

4. The storage device of claim 1, wherein the first portion of firmware instructions execute prior to the second portion of firmware instructions, the first portion of firmware instructions comprising instructions to decrypt at least a portion of authentication information provided by the computer device.

5. The storage device of claim 1, wherein the storage device comprises a removable storage device that is capable of being plugged in to the computer device.

6. The storage device of claim 1, wherein the authentication information comprises two-factor authentication information, and the two-factor authentication information comprises information identifying a user previously authenticated to the computer device.

7. The storage device of claim 1, wherein the authentication information comprises information including biometric access control to identify a user.

8. The storage device of claim 1, wherein the first portion of firmware instructions and the second portion of firmware instructions are (i) integrated as a single set of firmware instructions, and/or (ii) integrated with other firmware instructions executed by the data access controller.

9. The storage device of claim 1, wherein the preventing of completion of the enumeration process is not contingent upon one or more previous attempts to authenticate.

10. The storage device of claim 1, wherein the flash memory storage area comprises an area of memory on a secure digital card.

11. The storage device of claim 1, wherein data in at least a portion of the flash memory storage area is encrypted.

12. The storage device of claim 1, wherein the first portion of firmware instructions execute prior to the second portion of firmware instructions, the first portion of firmware instructions comprising instructions to decrypt at least a portion of authentication information provided by the computer device using a first decryption key; and

wherein data in at least a portion of the flash memory storage area is encrypted using a different decryption key than the first decryption key.

13. A computer system configured to access a secure storage drive, the computer system comprising:

an operating system;

a memory for loading the operating system thereto;

a processor for executing the operating system; and

one or more device drivers, the one or more device drivers providing an interface between physical hardware and the operating system;

wherein a first of the one or more device drivers comprises instructions to interface with a secure storage drive, the instructions to interface comprising instructions to cause the first device driver to:

initiate execution on the processor upon detection of connection of a device that may later be determined to be the secure storage drive;

determine whether or not the device is the secure storage drive;

provide, upon a start of an enumeration process of the secure storage drive with the computer system, unhide information to the secure storage drive based on a determination that the device is the secure storage drive;

receive a response at the processor from the secure storage drive after providing the unhide information; and

provide an interface between the operating system and the secure storage drive if the received response passes one or more authentication criteria, the interface allowing access to a data storage area on the secure storage drive, wherein completion of the enumeration process of the secure storage drive with the computer system is prevented unless the received response passes the one or more authentication criteria.

14. The computer system of claim 13, wherein the computer system comprises a special purpose computer device configured as a mobile surveillance system.

15. The computer system of claim 13, wherein the instructions to interface with the secure storage drive comprise instructions locked for execution on a specified computer system.

16. The computer system of claim 15, wherein the instructions locked for execution on the specified computer system comprise instructions locked for execution using a central processing unit identification (CPUID) or a media access control (MAC) address.

17. The computer system of claim 13, wherein the instructions to interface with the secure storage drive further comprise instructions to prevent access to the device based on a determination that the device is not the secure storage drive.

18. The computer system of claim 13, wherein the instructions to interface with the secure storage drive further comprise instructions to prevent all access by the operating system to the secure storage drive if the received response fails one or more of the authentication criteria.

19. The computer system of claim 13, wherein the instructions to cause the first device driver to provide unhide information comprise instructions to cause the first device driver to provide at least a portion of the unhide information as encrypted information.

20. The computer system of claim 13, wherein the computer system is configured to transmit metadata to the secure storage drive, assuming the received response has passed the one or more authentication criteria and the interface between the operating system and the secure storage drive has been provided, the metadata comprising information associating audio and/or video data with either a user and/or a device, the audio and/or video data having been stored or to be stored on the secure storage drive, and the user and/or device having been assigned to the secure storage drive and having been authenticated by the computer system and/or the secure storage drive.

21. The computer system of claim 13, wherein the preventing of completion of the enumeration process is not contingent upon one or more previous attempts to authenticate.

22. A non-transitory computer readable medium comprising instructions stored thereon that when executed by a processor cause the processor to configure one or more device drivers on a computer system or computer device, the one or more device drivers providing an interface between physical hardware and an operating system;

initiate execution upon detection of connection of a device that may later be determined to be the secure storage drive;

determine whether or not the device is the secure storage drive;

provide, upon a start of an enumeration process of the secure storage drive with the operating system, unhide information to the secure storage drive based on a determination that the device is the secure storage drive;

receive a response from the secure storage drive after providing the unhide information; and

provide an interface between the operating system and the secure storage drive if the received response passes one or more authentication criteria, the interface allowing access to a data storage area on the secure storage drive, wherein completion of the enumeration process of the secure storage drive with the operating system is prevented unless the received response passes the one or more authentication criteria.

23. The non-transitory computer readable medium of claim 20, wherein the preventing of completion of the enumeration process is not contingent upon one or more previous attempts to authenticate.

24. A computer system, comprising:

one or more processors; and one or more network communication interfaces communicatively coupled to the one or more processors,

wherein the one or more processors are configured to execute instructions to cause the one or more processors to:

receive, via the one or more network communication interfaces, first metadata information pertaining to a multi -media recording, the first metadata information comprising information regarding attributes describing recording circumstances of the multi -media recording and an access location of the multi-media recording;

initiate transmission of at least a portion of the first metadata information to a first storage location; and

categorize the multi-media recording using the first metadata information independently of the multi-media recording.

25. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

process the first metadata information pertaining to the multi -media recording; and incorporate the processed first metadata information in an index containing information pertaining to additional multi-media recordings obtained from multiple distinct portable recording devices.

26. The computer system of claim 25, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

receive a query request to identify potentially applicable multi -media recordings; and utilize the index to provide a response to the query request, wherein the response to the query request comprises metadata information pertaining to one or more potentially applicable multi-media recordings or information identifying a storage location of one or more potentially applicable multi-media recordings.

27. The computer system of claim 24, wherein the information regarding attributes describing recording circumstances comprises information pertaining to items selected from the group consisting of: recording location, recording time, recording initiation, recording termination, recording duration, event type/tag, and a user who performed the multi-media recording.

28. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

apply audit controls regarding access to and/or alteration of the first metadata information and/or the multi-media recording.

29. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

receive an indication identifying one or more potentially applicable multi -media recordings, the indication responsive to a query request; and

request initiation of transmission of at least one of the one or more potentially applicable multi-media recordings from a remote storage location to a storage location accessible to the computer system.

30. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

apply a data retention policy to the multi -media recording, wherein the data retention policy indicates a data retention period for the multi -media recording based on the first metadata information.

31. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

initiate transmission of the multi-media recording to a second storage location different from the first storage location.

32. The computer system of claim 31, wherein the first storage location is a local network accessible storage location and the second storage location is a remote storage location.

33. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

copy the first metadata information and/or the multi-media recording to a local storage area distinct from the first storage location.

34. The computer system of claim 24, further comprising:

a local storage area communicatively coupled to the one or more processors; and a plug-in port communicatively coupled to the one or more processors and configured to interface with a portable recording device,

wherein the initiation of transmission of the first metadata information to the first storage location and/or initiation of transmission of the multi-media recording to a second storage location occurs automatically upon connection of a portable recording device to the plug-in port, the portable recording device storing the first metadata information and/or the multimedia recording, respectively.

35. The computer system of claim 24, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

correlate the first metadata information with additional metadata information to produce correlated metadata information, the additional metadata information comprising information regarding attributes describing recording circumstances of one or more additional multi-media recordings.

36. The computer system of claim 35, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

provide an interface to access the correlated information, wherein the interface provides information to assist in audit control of the first and additional metadata information and the first and the one or more additional multi-media recordings.

37. The computer system of claim 35, wherein the correlating of the first metadata information with the additional metadata information to produce correlated metadata information comprises correlating the first and the one or more additional multi -media recordings based on an event type associated with each of the first and the one or more multi-media recordings, respectively, a recording location of each of the first and the one or more multi -media recordings, respectively, and/or a recording time of each of the first and the one or more multi-media recordings, respectively.

38. A method comprising:

receiving at a computer system, via one or more network communication interfaces, first metadata information pertaining to a first multi -media recording, the first metadata information comprising information regarding attributes describing recording circumstances of the first multi-media recording and an access location of the first multi -media recording;

initiating transmission of at least a portion of the first metadata information to a first storage location, the first storage location comprising a storage area configured for storing at least metadata; and

categorizing the first multi-media recording using the first metadata information independently of the first multi-media recording.

39. The method of claim 38, further comprising:

receiving a query request to identify potentially applicable multi-media recordings; and utilizing an index to provide a response to the query request,

wherein the response to the query request comprises metadata information pertaining to one or more potentially applicable multi-media recordings or information identifying a storage location of one or more potentially applicable multi -media recordings, and

wherein the index contains metadata information pertaining to multi-media recordings obtained from one or more portable recording devices.

40. The method of claim 38, further comprising:

applying audit controls regarding access to and/or alteration of the first metadata information and/or the first multi-media recording.

41. The method of claim 38, further comprising:

receiving an indication identifying one or more potentially applicable multi -media recordings, the indication responsive to a query request; and

requesting initiation of transmission of at least one of the one or more potentially applicable multi -media recordings from a remote storage location to a storage location accessible to the computer system.

42. The method of claim 38, further comprising:

applying a data retention policy to the first multi -media recording, wherein the data retention policy indicates a data retention period for the first multi -media recording based on the first metadata information.

43. The method of claim 38, further comprising:

initiating transmission of the first multi-media recording to a second storage location different from the first storage location, the second storage location comprising a storage area configured for storing at least multi-media recordings.

44. The method of claim 43, wherein the first storage location is a local network accessible storage location and the second storage location is a remote storage location.

45. The method of claim 38, further comprising:

correlating the first metadata information with additional metadata information to produce correlated metadata information, the additional metadata information comprising information regarding attributes describing recording circumstances of one or more additional multi-media recordings; and

generating an index based on the correlated metadata information, the index containing information pertaining to the first and the one or more additional multi-media recordings.

46. A computer system configured to receive and manage multi -media recordings, the computer system comprising: one or more processors;

one or more network communication interfaces communicatively coupled to the one or more processors; and

a storage area accessible to the one or more processors,

receive, via the one or more network communication interfaces, at least one multimedia file and one or more metadata files containing attributes of the at least one multi -media file, the attributes including at least an event tag;

categorize the at least one multi-media file using the event tag;

provide a set of evidentiary controls for the at least one multi -media file;

determine a third party recipient of information pertaining to the at least one multi-media file based on the at least one multi-media file categorization; and

initiate transmission of an indication of the at least one multi-media file to the third party recipient, the indication including information pertaining to accessing the at least one multi-media file.

47. The computer system of claim 46, wherein the indication including information pertaining to accessing the at least one multi-media file comprises a link for accessing the at least one multimedia file in a secure manner, the link providing an indication of security restrictions associated with the at least one multi-media file.

48. The computer system of claim 46, wherein the indication including information pertaining to accessing the at least one multi-media file comprises a link for accessing the at least one multimedia file in a secure manner, the link providing an indication of duration of availability of the at least one multi-media file via the link.

49. The computer system of claim 46, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to: automatically create a copy of the at least one multi -media file on a physical storage medium for transport to the interested third party.

50. The computer system of claim 46, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

provide data retention policies regarding access to the at least one multi-media file while taking into consideration the set of evidentiary controls.

51. The computer system of claim 46, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

monitor access to the at least one multi-media file while taking into consideration the set of evidentiary controls.

52. The computer system of claim 46, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

control access to the at least one multi-media file while taking into consideration the set of evidentiary controls.

53. The computer system of claim 46, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

monitor subscription parameters regarding access to the at least one multi-media file while taking into consideration the set of evidentiary controls.

54. The computer system of claim 46, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to:

provide billing information and audit controls regarding access to the at least one multimedia file.

55. The computer system of claim 46, where the indication of the at least one multi-media file transmitted to the third party recipient includes an indication for a redirect via a secure network to local storage for the at least one multi-media file.

56. A computer system configured to receive and manage multi-media recordings, the computer system comprising:

one or more processors;

a storage area accessible to the one or more processors,

categorize the at least one multi -media file using the event tag;

provide a set of evidentiary controls for the at least one multi -media file; and automatically initiate upload of at least a portion of the one or more metadata files and the at least one multi-media file to a cloud based server, the automatic upload initiated based on the at least one multi-media file categorization.

57. The computer system of claim 56, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to interface with a software as a service (SAAS) cloud based infrastructure to make a determination regarding the automatic upload initiation.

58. The computer system of claim 57, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to interface with the SAAS cloud based infrastructure regarding data retention policies and the set of evidentiary controls for the at least one multi-media file.

59. The computer system of claim 57, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to interface with the SAAS cloud based infrastructure regarding auditing controls with respect to the set of evidentiary controls for the at least one multi-media file.

60. The computer system of claim 57, wherein the one or more processors are further configured to execute instructions to cause the one or more processors to interface with both the SAAS cloud based infrastructure and a docking station to initiate a second upload of at least a portion of a second set of metadata files and a second multi-media file from the docking station to the cloud based server, the second upload independent of the computer system after initiation.

61. A computer system configured to capture and manage multi -media recordings, the computer system comprising:

one or more processors;

one or more audio capture devices communicatively coupled to the one or more processors;

one or more video capture devices communicatively coupled to the one or more processors;

a storage area accessible to the one or more processors,

receive information from the one or more audio capture devices and the one or more video capture devices, the information used to create one or more metadata files and at least one multi -media file associated with the one or more metadata files;

determine an event tag for use in categorizing the at least one multi -media file; and

automatically initiate upload of at least a portion of the one or more metadata files and the at least one multi-media file to a cloud based server, the automatic upload initiated based on the event tag.

62. The computer system of claim 61, wherein the computer system is configured as a mobile surveillance system.

63. The computer system of claim 62, wherein at least one of the one or more network communication interfaces comprises a wireless communication interface and the automatic upload is initiated via the wireless communication interface while the mobile surveillance system is in transit.

64. The computer system of claim 63, wherein the automatic upload is performed at the same time as the one or more processors are receiving information from the one or more audio capture devices and the one or more video capture devices,

65. The computer system of claim 61, wherein the automatic upload comprises:

uploading the at least a portion of the one or more metadata files and the at least one multi-media file to a docking station; and

initiating a second upload of the at least a portion of the one or more metadata files and the at least one multi -media file from the docking station to the cloud based server, the second upload independent of the computer system after initiation.