Patent Description:
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, which together with the detailed description below, are incorporated in and form part of the specification and serve to further illustrate various embodiments of concepts that include the claimed invention, and to explain various principles and advantages of those embodiments.

The invention is defined by the attached independent claims. Several embodiments are given by the dependent claims. Prior Art: <CIT>) discloses a wearable camera capturing videos which are uploaded to an evidence management server for storage. The camera also gets events from the nearby devices (weapon, car lights) and may be connected to the officer cellphone or car mobile computer (coordinator or evidence collection dock) to store (sporadic communication) and report evidences to a server. The events and a content hash are recorded in metadata which are signed before upload by the camera storage. The video are erased on upload acknowledge from the server.

<CIT>) discloses a microphone (or body worn camera) collecting evidences for law enforcement which are are streamed with metadata (timestamps and GPS coordinates, camera orientation with accelerometers) to a mobile surveillance system (e. g in a police car). Both the storage device (camera) and the user (officer) have to be authenticated to maintain chain of custody evidence. Until authentication, the storage is hidden to avoid deletion. A charging docking station assists in uploading evidences, including storage and officer ID, password or recording parameters.

<CIT>) discloses body-worn microphones or cameras for police officers uploading the data to their car and then a central storage. The integrity of the transferred file is verified before deleting the source. An evidence key is then used for download of evidences for lawyers, court. A two-factor authentication using a unique smart phone identification number or inserted memory device (something you have) combined with a user ID and password (something you know) regulates access to the evidence key. All accesses (download, delete) are logged. After a threshold of failed authentication attempts, the data are wiped.

As mentioned above, preserving the chain of custody for recorded data even after the data is transferred from a source device (e.g., a camera) to another device (e.g., a data storage server) is an important requirement for admitting the recorded data into evidence. Preserving the chain of custody means that the data is only transferred to and/or stored at devices authorized and trusted for such purposes. It is also important to ensure that the data is not tampered with or modified by intermediaries during the transfer of the data from one device to another device.

Public safety agencies assign portable devices such as cameras to officers for capturing digital evidence such as image and/or video data. The captured digital evidence is transferred to a central evidentiary repository (e.g., a data storage server) for further processing so that the cameras can be reused for recording another evidence and/or re-assigned to another user (e.g., after the current officer's work shift). However, portable devices may only have limited storage capacity compared to a storage capacity of the data storage server. Also, some portable devices may not have network capability or may have only limited network capability to stream/transfer the captured data to the server. Further, some portable devices may not have enough battery capacity to fully support the transfer of the digital evidence to the server. To address the above issues, intermediary storage devices, that have larger storage capacity, larger battery capacity, or better network capability relative to portable devices, are used to assist the portable devices in successfully transferring the recorded data to the repository. Some intermediary storage devices such as multi-unit chargers are also capable of charging (e.g., via wired or wireless charging means) the portable devices during the transfer of the digital evidence.

In such situations when intermediary storage devices are employed for data transfer, it is also important to ensure that the chain of custody for the digital evidence is not violated. Additionally, it is important that the authenticity of the intermediary storage devices is validated to ensure that the digital evidence is not transferred to an un-trusted malicious entity. Further, portable devices are often shared among the users in organizations such as public safety. Such organizations may prefer that the digital evidence is transferred to the evidentiary repository prior to device being made available for a new user, for example, where there is a need to redeploy the device for re-assignment to a new user at the end of work shift of the previous user. During the re-assignment process, there is a possibility of the chain of custody for digital evidence being violated when the new user attempts to access the digital evidence previously stored at the device or when the device is placed for re-assignment, for example, on a shared shelf where there is a chance for the device to be lost or stolen, or the digital evidence to be modified or tampered with by a malicious person. So, it is also important to ensure that the digital evidence is fully transferred to the evidentiary repository prior to the device re-assignment to prevent violation of chain of custody during re-assignment of the device from one user to another user. This also requires that the digital evidence is not erased from the source portable device before the digital evidence is completely transferred to the server and acknowledged as such. Disclosed is an improved process that addresses the above presented technical issues and requirement in preserving the chain of custody for digital evidence captured at portable devices.

One exemplary embodiment provides a method for preserving chain of custody for digital evidence captured at a portable device. The method comprises transmitting, at the portable device, to a cloud server, a request for approval to upload the digital evidence to the cloud server via an intermediary storage device, the request comprising a digitally signed metadata associated with the digital evidence, a first authentication credential associated with the intermediary storage device, and a second authentication credential associated with the portable device, wherein the digitally signed metadata includes a data integrity code that is generated as a function of the content of the digital evidence to be uploaded; receiving, at the portable device, a first response to the request for approval from the cloud server, the first response indicating approval to upload the digital evidence to the cloud server via the intermediary storage device; responsive to receiving the first response, transmitting, at the portable device, the digital evidence to the intermediary storage device for uploading to the cloud server; transmitting, at the portable device, to the cloud server, a request for approval to delete the digital evidence from the portable device; receiving, at the portable device, a second response from the cloud server, the second response indicating an approval to delete the digital evidence from the portable device; and responsive to receiving the second response, deleting, at the portable device, the digital evidence from the portable device.

Another exemplary embodiment provides a method for preserving chain of custody for digital evidence captured at a portable device. The method comprises: receiving, at a cloud server, from the portable device, a request for approval to upload the digital evidence to the cloud server via an intermediary storage device, the request comprising digitally signed metadata associated with the digital evidence, a first authentication credential associated with the portable device, and a second authentication credential associated with the intermediary storage device, wherein the digitally signed metadata includes a data integrity code that is generated as a function of the digital evidence to be uploaded; verifying, at the cloud server, whether the request is valid based on the information included in the digitally signed metadata, first authentication credential, and second authentication credential; responsive to verifying that the request is valid, transmitting, at the cloud server, to the portable device, a first response indicating approval to upload the digital evidence to the cloud server via the intermediary storage device; receiving, at the cloud server, in response to transmitting the first response, the digital evidence from the portable device via the intermediary storage device; validating, at the cloud server, the data integrity of received digital evidence using the data integrity code; storing the received digital evidence at a cloud storage component associated with the cloud server when the data integrity of the received digital evidence is valid; receiving, at the cloud server, a request for approval to delete the digital evidence from the portable device; and transmitting, at the cloud server, a second response indicating an approval to delete the digital evidence from the portable device.

A further exemplary embodiment provides a portable device, comprising: a memory for storing a captured digital evidence; a communications unit configured to be coupled with an intermediary storage device for transferring the digital evidence to a cloud server via the intermediary storage device; and an electronic processor communicatively coupled with the memory and communications unit, the electronic processor configured to: transmit, via the communications unit, to a cloud server, a request for approval to upload the digital evidence to the cloud server via the intermediary storage device, the request comprising a digitally signed metadata associated with the digital evidence, a first authentication credential associated with the intermediary storage device, and a second authentication credential associated with the portable device, wherein the digitally signed metadata includes a data integrity code that is generated as a function of the digital evidence to be uploaded; receive, via the communications unit, a first response to the request for approval from the cloud server, the first response indicating approval to upload the digital evidence to the cloud server via the intermediary storage device; responsive to receiving the first response, transmit, via the communications unit, the digital evidence to the intermediary storage device for uploading to the cloud server; transmit, via the communications unit, to the cloud server, a request for approval to delete the digital evidence from the memory; receive, via the communications unit, a second response from the cloud server, the second response indicating an approval to delete the digital evidence from the portable device; and responsive to receiving the second response, delete the digital evidence from the memory.

Each of the above-mentioned embodiments will be discussed in more detail below, starting with an example system including a portable device, an intermediary storage device, and a cloud server in which the embodiments may be practiced, followed by an illustration of processing steps for achieving the method of operating the portable device and cloud server. Further advantages and features consistent with this disclosure will be set forth in the following detailed description, with reference to the figures.

Referring now to drawings and in particular to <FIG>, a communication system diagram illustrates a system <NUM> including a portable device <NUM>, an intermediary storage device <NUM>, and a cloud server <NUM>. The portable device <NUM> may be any computing device that is capable of capturing and/or storing digital evidence <NUM> that may take form of an audio, image, video, text, and the like. In accordance with some embodiments, the portable device <NUM> may be operated or associated with a public safety agency officer, who may carry or wear the portable device <NUM>. In one embodiment, the portable device <NUM> is a body wearable camera that is used to capture digital evidence <NUM> in the form of image and/or video data. An example portable device <NUM> in the form of a body wearable camera is shown in <FIG> with a display presenting a thumbnail of a video evidence that is captured corresponding to a burglary incident. In accordance with some embodiments, the portable device <NUM> has one or more of limited storage capacity, limited battery capacity, and limited or no network capability in comparison to the intermediary storage device <NUM> (for example, that has one or more of larger storage capacity, larger battery capacity (or unlimited power supply), or better network capability), and therefore establishes a connection with the intermediary storage device <NUM> for uploading the captured digital evidence <NUM> to the cloud server <NUM>.

The intermediary storage device <NUM> may be any data storage device that is capable of being communicatively coupled to the portable device <NUM> via a first communication link <NUM> at one end and further capable of being communicatively coupled to the cloud server <NUM> via a second communication link <NUM> at other end to facilitate the transfer of the digital evidence <NUM> captured at the portable device <NUM> to the cloud server <NUM>. In one embodiment, the communication link <NUM> corresponds to a short range wireless connection that is established, for example, in accordance with one or more communication protocols/standards such as Bluetooth, Wi-Fi, Zigbee, Z-Wave, or infrared wireless connection, that enables the intermediary storage device <NUM> to wirelessly receive the digital evidence <NUM> from the portable device <NUM> for further uploading the digital evidence <NUM> to the cloud server <NUM>. In another embodiment, the first communication link <NUM> corresponds to a wired connection (e.g., established using a data cable) to the portable device <NUM> to enable the transfer of the digital evidence <NUM>. In yet another embodiment, the first communication link <NUM> can be established via physical coupling of the portable device <NUM> to the intermediary storage device <NUM>, which can be achieved when one or more contacts (e.g., battery/data contacts) of the intermediary storage device <NUM> are aligned and mated with the corresponding one or more contacts of the portable device <NUM>. This embodiment is further illustrated in <FIG>, where an intermediary storage device <NUM> functioning as a multi-unit charger <NUM> is shown.

Briefly referring to <FIG>, a multi-unit charger <NUM> employed as an intermediary storage device <NUM> for transferring the digital evidence <NUM> to the cloud server <NUM> is shown. The multi-unit charger <NUM> is capable of charging multiple portable devices <NUM> simultaneously when the portable devices <NUM> (e.g., cameras) are coupled to the charger <NUM>. In addition to the charging function, the multi-unit charger shown in <FIG> also includes a communications module <NUM> that includes necessary hardware and firmware components for enabling the multi-unit charger <NUM> to communicate with remote devices such as the cloud server <NUM> for transferring the digital evidence <NUM> from the portable device <NUM> to the cloud server <NUM>, via the second communication link <NUM>. For example, as shown in <FIG>, the communications module <NUM> includes a local area network (LAN) interface and/or a wide area network (WAN) interface <NUM>, that can be used to establish the second communication link <NUM> to transfer digital evidence <NUM> such as video that requires high bandwidth connection for data transfer. In other embodiments, the second communication link <NUM> is established using one or more wireless air-interface standards (e.g., long term evolution (LTE) standard) that support transfer of high bandwidth data such as video. The multi-unit charger <NUM> can be employed for use in public safety agencies such as police departments, where there is often a need, between the work shifts, to simultaneously charge the portable device <NUM> as well as offload the data (such as digital evidence <NUM> recorded during the shift) to a storage server (e.g., cloud server <NUM>) to enable the portable device <NUM> to be available for reassignment before the next shift.

Returning to <FIG>, the cloud server <NUM> includes one or more of physical or logical servers that are hosted through a cloud computing platform via a network, and are further capable of providing application services including storing and preserving chain of custody for digital evidence <NUM> transferred from the portable device <NUM> via the intermediary storage device <NUM>. The cloud server <NUM> includes or is connected to one or more cloud storage devices/components at which the digital evidence <NUM> transferred from the portable device <NUM> is stored. The network may be a local area network, metropolitan area network, a wide area network, such as the internet or intranet, or a combination thereof. In accordance with some embodiments, the cloud server <NUM> verifies the authenticity of the portable device <NUM> (for example, via an authentication server associated with the cloud server <NUM>) and intermediary storage device <NUM> before the digital evidence <NUM> can be transferred from the portable device <NUM> to the cloud server <NUM> via the intermediary storage device <NUM>.

<FIG> is a block diagram of an example portable device <NUM>. The portable device <NUM> is an electronic device including a processing unit <NUM>, a static memory <NUM>, a camera <NUM>, a user interface unit <NUM>, an electronic display <NUM>, a communications unit <NUM>, a microphone <NUM>, and a speaker <NUM>. The portable device <NUM> is presented as an example device that may be programmed and configured to carry out the functions described herein, for example, for preserving the chain of custody for digital evidence <NUM> captured at the portable device <NUM>. In some embodiments, depending on the type of the portable device <NUM>, the portable device <NUM> may include fewer or additional components in configurations different from that illustrated in <FIG>. For example, when the portable device <NUM> is implemented as a standalone camera, the portable device <NUM> may include limited or no network capability, and therefore one or more components associated with the communications unit <NUM> are not implemented at the portable device <NUM>. In other embodiments, the components associated with the portable device <NUM> are implemented in a distributed manner in multiple electronic devices that interface and/or communicate with each other to perform the functions described herein. Other combinations are possible as well.

The processing unit <NUM> includes a code Read Only Memory (ROM) <NUM> coupled to a common data and address bus <NUM> for storing data for initializing system components. The use of control and data buses <NUM> for the interconnection between and exchange of information among the various modules and components would be apparent to a person skilled in the art in view of the description provided herein. The processing unit <NUM> further includes an electronic processor <NUM> coupled by the common data and address bus <NUM>, to a Random Access Memory (RAM) <NUM> and the static memory <NUM>. The electronic processor <NUM> may include hardware ports for coupling to different components of the portable device <NUM>. The electronic processor <NUM> includes one or more logic circuits, one or more processors, one or more microprocessors, one or more ASIC (application-specific integrated circuits) and one or more FPGA (field-programmable gate arrays), and/or another electronic device. In some embodiments, the electronic processor <NUM> is not a generic controller and/or a generic device, but a device specifically configured to implement a functionality for transferring digital evidence <NUM> (stored in static memory <NUM>) to the cloud server <NUM> via the intermediary storage device <NUM> while preserving the chain of custody for the digital evidence <NUM>. In some embodiments, the electronic processor <NUM> specifically comprises a computer executable engine configured to implement specific functionality for transferring the digital evidence <NUM> to the cloud server <NUM> via the intermediary storage device <NUM>.

The static memory <NUM> may store operating code <NUM> for the electronic processor <NUM> that, when executed, performs one or more of the operations set forth in the accompanying figures and text. The static memory <NUM> may comprise non-transitory computer-readable media components, for example hard-disk drive (HDD), an optical disk drive such as a compact disk (CD) drive or digital versatile disk (DVD) drive, a solid state drive (SSD), a tape drive, a flash memory drive, or a tape drive, and the like.

The static memory <NUM> further stores digital evidence <NUM> that corresponds to one or more of: a video or image data captured via the camera <NUM>, an audio data captured via the microphone <NUM>, or text data entered by user via the user interface unit <NUM>. In other embodiments, the digital evidence <NUM> additionally includes sensor data captured by one or more sensors (not shown) (e.g., biometric sensor, motion sensor, sonar sensor, etc.,) associated with the portable device <NUM>. In addition to storing the digital evidence <NUM>, the static memory <NUM> is further configured to store digital evidence metadata <NUM> associated with the digital evidence <NUM>. The digital evidence metadata <NUM> includes information corresponding to one or more of: an identifier (e.g., name of a video file corresponding to the digital evidence <NUM>) uniquely identifying the digital evidence <NUM>; a user profile or identifier of the owner of the portable device <NUM> or of the user operating the portable device <NUM> at the time the digital evidence <NUM> was captured/stored; a data type/format (e.g., video, audio, text etc.,) of digital evidence <NUM>; a time stamp of capturing/storing the digital evidence <NUM>; a data size of the digital evidence <NUM>; location data identifying locations at which the digital evidence <NUM> was captured; an incident identifier (e.g., computer aided dispatch (CAD) identifier associated with the burglary incident) corresponding to an incident assigned to the user of the portable device <NUM>; one or more data tags, for example, identifying person, object, or entity of interest associated with the digital evidence <NUM>; and one or more environmental data (e.g., sensor data such as temperature, ambient noise etc.,) corresponding to a location at which the digital evidence <NUM> was captured.

In accordance with the embodiments, the digital evidence metadata <NUM> further includes a data integrity code that is generated as a function of the digital evidence <NUM>. The data integrity code allows a receiver (e.g., intermediary storage device <NUM> or cloud server <NUM>) of the digital evidence <NUM> to validate the data integrity of the digital evidence <NUM>. The data integrity code is generated and the corresponding data integrity validation process is implemented using error detection algorithms, including, but not limited to, checksums, hash functions, cyclic redundancy checks, and message authentication codes (MACs).

The camera <NUM> includes imaging components such as image sensors and optical components (e.g., lenses) that are controlled by the electronic processor <NUM> to capture images by sensing light in at least the visible spectrum. The images refer to one or more digital images or sequence of images such as a video of a target object captured by the camera <NUM>. In accordance with some embodiments, the images captured by the camera <NUM> are stored and marked as digital evidence <NUM>.

The user interface unit <NUM> operates to receive input from, for example, a user of the portable device <NUM>, to provide system output, or a combination of both. The user interface unit <NUM> obtains information and signals from, and provides information and signals to, devices both internal and external to the portable device <NUM> (for example, over one or more wired and/or wireless connections). Input may be provided via different hardware and software elements, for example, a keypad, mouse, microphone, soft keys, icons, or soft buttons on the electronic display <NUM>, a scroll ball, physical buttons, control knobs and the like. In accordance with some embodiments, the user of the portable device <NUM> may manually input data (e.g., notes from interviewing the witnesses) associated with the digital evidence <NUM> via the user interface unit <NUM>. The user interface unit <NUM> also allows the user of the portable device <NUM> to mark particular stored data, for example, of an image, or a video, or text, as digital evidence <NUM>. In other embodiments, the electronic processor <NUM> of the portable device <NUM> marks all data captured at the portable device, by default, as digital evidence <NUM>. The portable device <NUM> may automatically or based on input received from the user via the user interface unit <NUM>, links the captured evidence to a particular incident (e.g., burglary incident) assigned to the user for investigation. In these embodiments, the user of the portable device <NUM> may not be authorized to erase any data captured and stored at the memory <NUM> unless a permission is received from the cloud server <NUM> after the digital evidence <NUM> is successfully transferred and validated for data integrity at the cloud server <NUM>.

The electronic display <NUM> may be provided for displaying digital evidence <NUM> including images, video, and/or text to the user of the portable device <NUM>. The electronic display <NUM> may be, for example, a liquid crystal display (LCD) screen or an organic light emitting display (OLED) display screen. In some embodiments, a touch sensitive input interface may be incorporated into the electronic display <NUM> as well, allowing the user of the portable device <NUM> to interact with content provided on the electronic display <NUM>.

The communications unit <NUM> may include one or more wired and/or wireless input/output (I/O) interfaces <NUM> that are configurable to enable the portable device <NUM> to communicate with other devices, such as the intermediary storage device <NUM> and the cloud server <NUM>. In one embodiment, the portable device <NUM> may obtain the digital evidence <NUM> and/or digital evidence metadata <NUM> from other devices or systems via the communications unit <NUM>. The communications unit <NUM> may include a short-range transmitter such as a Bluetooth™, Zigbee™, or NFC (near field communication) transmitter) with other communication devices and/or an infrastructure RAN (e.g. a wireless communications tower, a cellphone tower, and the like). One or more wireless transceivers <NUM> may include a long-range transmitter which may implement a direct-mode, conventional, or trunked land mobile radio (LMR) standard, Terrestrial Trunked Radio (TETRA), or other radio protocols or standards (e.g., LTE standard). The communications unit <NUM> may additionally or alternatively include one or more wireline transceivers <NUM>, such as an Ethernet transceiver, a universal serial bus (USB) transceiver, or similar transceiver configurable to communicate via a twisted pair wire, a coaxial cable, a fiber-optic link, or a similar physical connection to a wireline network. The transceiver <NUM> is also coupled to a combined modulator/demodulator <NUM>. In some embodiments, the network capability of the portable device <NUM> may be limited in terms of bandwidth, transmission data rate, or transmission range, and therefore the intermediary storage device <NUM> with better network capability may be employed by the portable device <NUM> for transferring the digital evidence <NUM> to the cloud server <NUM>.

The microphone <NUM> may be present for capturing audio from a user and/or other environmental or background audio that is further processed by the processing unit <NUM> and/or is stored/transmitted as digital evidence <NUM>.

The portable device <NUM> may further include a speaker <NUM> for reproducing audio from voice data during playback of the digital evidence <NUM>, or may playback alert tones or other types of pre-recorded audio, for example, to indicate that the device <NUM> is available for reassignment.

In accordance with embodiments, the cloud server <NUM> includes one or more similar components as illustrated in <FIG>. In one embodiment, the cloud server <NUM> similarly includes a processing unit, a communications unit, and a memory to perform the functions described herein. In some embodiments, the components associated with the cloud server <NUM> are implemented in a distributed manner in multiple electronic devices that interface and/or communicate with each other to perform the functions described herein. Other combinations are possible as well.

<FIG> illustrates a flow chart diagram of a method <NUM> of operating a portable device <NUM> to preserve chain of custody for digital evidence <NUM> captured at the portable device <NUM> in accordance with some embodiments. While a particular order of processing steps is indicated in <FIG> as an example, timing and ordering of such steps may vary where appropriate without negating the purpose and advantages of the examples set forth in detail throughout the remainder of this disclosure. As an example, the method <NUM> is performed by the electronic processor <NUM> of the portable device <NUM>. Other embodiments of the method <NUM> may be performed on multiple processors within the same device or on multiple devices.

At block <NUM>, the portable device <NUM> initiates a process of transferring the digital evidence <NUM> captured at the portable device <NUM> by transmitting a request for approval to the cloud server <NUM> to upload digital evidence <NUM> to the cloud server <NUM> via an intermediary storage device <NUM>.

In accordance with some embodiments, the portable device <NUM> initiates the process of transferring the digital evidence <NUM> automatically in response to one or more triggering events. For example, as shown in <FIG>, the triggering event may be caused when the portable device <NUM> is placed in a multi-unit charger <NUM>, for instance, for charging the portable device <NUM> at the end of a work shift of the user associated with the portable device <NUM>. As another example, the triggering event may be caused when the portable device <NUM> receives an input from a user (e.g., user of the portable device <NUM>) or another device (e.g., from CAD console). The input may be a request to re-assign the portable device <NUM> from the currently assigned user to another user, or alternatively a request to transfer one or more selected digital evidences <NUM> stored at the portable device <NUM> to the cloud server <NUM>. As a further example, the triggering event may correspond to a repeated event that is triggered periodically (e.g., every <NUM> hours or every day of the week at <NUM> PM). Other variations of triggering events are possible as well.

The request for approval, as transmitted at block <NUM>, includes digitally signed metadata <NUM> and also a first authentication credential associated with the intermediary storage device <NUM> and a second authentication credential associated with the portable device <NUM>. The digital evidence <NUM> may correspond to one or more of: video data, audio data, text data, or combination thereof, that are captured at the portable device <NUM>. The first and second authentication credentials include one or more of a device/user identifier, username-password, digital certificate, encrypted key, biometric key, and the like. The digitally signed metadata <NUM> includes a data integrity code that is generated as a function of the digital evidence <NUM> to be uploaded, and further optionally includes information related to one or more of: identifier (e.g., name of a video file corresponding to the digital evidence <NUM>) uniquely identifying the digital evidence <NUM>; a user profile or identifier of the owner of the portable device <NUM> or of the user operating the portable device <NUM> at the time the digital evidence <NUM> was captured/stored; the evidence a data type/format (e.g., video, audio, text etc.,) of digital evidence <NUM>; a time stamp of capturing/storing the digital evidence <NUM>; a data size of the digital evidence <NUM>; location data identifying locations at which the digital evidence <NUM> was captured; an incident identifier (e.g., computer aided dispatch (CAD) identifier) corresponding to an incident assigned to the user of the portable device <NUM>; one or more data tags, for example, identifying person, object, or entity of interest associated with the digital evidence <NUM>; and one or more environmental data (e.g., sensor data such as temperature, ambient noise etc.,) corresponding to a location at which the digital evidence <NUM> was captured.

The digital evidence metadata <NUM> including the data integrity code is digitally signed using a digital signature that may be created, for example, by encrypting a hash value of the digital evidence metadata <NUM> to be transmitted using a private key of the portable device <NUM>. The receiver, for example, the cloud server <NUM> can verify the sender (i.e., identity of the portable device <NUM>) of the digital evidence metadata <NUM> by comparing a hash value of the received digital evidence metadata <NUM> with the hash value decoded using the sender's public key. The cloud server <NUM> can verify that the sender is the portable device <NUM> when the two hash values match. While the above example is provided as an example to illustrate how the digital evidence metadata <NUM> is digitally signed for verifying the sender, variations of the above example and/or other types of digital signature algorithms can also be used to digitally sign the digital evidence metadata <NUM>.

In accordance with some embodiments, the portable device <NUM> establishes a secure communication channel to directly communicate (i.e., by bypassing the intermediary storage server) with the cloud server <NUM> to transmit the request for approval to upload the digital evidence <NUM>. For example, the portable device <NUM> may have network capability (e.g., with a narrowband/broadband connection) to support transmission of data (such as digital evidence metadata <NUM>) with limited data size (e.g., in the order of kilobytes to few megabytes). In this example, the portable device <NUM> may bypass intermediary storage device <NUM> to transmit the request for approval to the cloud server <NUM>, but may require intermediary storage device <NUM> that has better network capability (e.g., with a broadband connection) to route the digital evidence <NUM> for uploading to the cloud server <NUM>. In other embodiments, the request for approval may be routed to the cloud server <NUM> via the intermediary storage device <NUM> or via another device in the system <NUM>.

In some embodiments, prior to transmitting the request for approval to upload the digital evidence <NUM>, the portable device <NUM> verifies the authenticity of the intermediary storage device <NUM>. In these embodiments, the portable device <NUM>, after identifying and/or coupling to the intermediary storage device <NUM> to be used for uploading the digital evidence <NUM>, transmits an authentication challenge to the intermediary storage device <NUM> via the first communication link <NUM>. In response, the portable device <NUM> receives an authentication challenge response including the first authentication credential from the intermediary storage device <NUM> via the first communication link <NUM>. The portable device <NUM> then forwards the authentication challenge request and response to the cloud server <NUM>, which may act as an authentication server or as a proxy for authentication server to authenticate the intermediary storage device <NUM> using the first authentication credential associated with the intermediary storage device <NUM>. The portable device <NUM> verifies that the intermediary storage device <NUM> is a trusted device and then performs the function recited at block <NUM> when it receives a response from the cloud server <NUM> indicating that the intermediary storage device is a trusted device based on the authentication challenge response received from the intermediary storage device <NUM>. On the other hand, when the portable device <NUM> receives a response from the cloud server <NUM> indicating that the intermediary storage device <NUM> is not a trusted device based on the authentication challenge response received from the intermediary storage device <NUM>, the portable device <NUM> does not perform the function recited at block and may alternatively identify and/or couple to a different intermediary storage device <NUM> for uploading the digital evidence to the cloud server <NUM>.

At block <NUM>, the portable device <NUM>, after transmitting the request for approval to the cloud server <NUM>, checks if an approval from the cloud server <NUM> has been received. If no response to the request has been received from the cloud server <NUM> or if a response received from the cloud server <NUM> indicates that the request is rejected, the portable device <NUM>, as shown in block <NUM>, refrains from transmitting the digital evidence <NUM> to the intermediary storage device <NUM> for uploading to the cloud server <NUM>. In one embodiment, the received response may provide additional information identifying the reason for rejecting the request to upload the digital evidence <NUM>. For example, the response may indicate that the request is not valid because the portable device <NUM> and/or the intermediary storage device <NUM> are not identified as trusted devices by the cloud server <NUM> based on the received authentication credentials. As another example, the response may indicate that the intermediary storage device <NUM> is not capable of or available for supporting the transfer of the digital evidence <NUM> to the cloud server <NUM>. The intermediary storage device <NUM> may be determined to be not capable of supporting the transfer of the digital evidence when the data size of the digital evidence <NUM> is larger than available storage size of the intermediary storage device <NUM> or when the intermediary storage device <NUM> has limited network capability to support the transfer of the digital evidence <NUM>. In such cases, the portable device <NUM> refrains from transmitting the digital evidence <NUM> to the intermediary storage device <NUM> and may further take one or more additional actions such as: deactivating a data connection established with the intermediary storage device <NUM>; providing an alert to the user (e.g., via the electronic display <NUM>) that the intermediary storage device <NUM> is not capable of or not available for uploading the digital evidence <NUM> to the cloud server <NUM>; identifying another intermediary storage device <NUM>, for example, by presenting, via the electronic display <NUM>, an identifier and/or a location of another multi-unit charger <NUM> that may be used for uploading the digital evidence <NUM>.

On the other hand, when a response indicating approval to upload the digital evidence <NUM> via the intermediary storage device <NUM> is received from the cloud server <NUM>, the portable device <NUM>, at block <NUM>, transmits the digital evidence <NUM> to the intermediary storage device <NUM> via the first communication link <NUM>. In one embodiment, the response indicating the approval as received from the cloud server <NUM> further identifies a resource identifier (e.g., a network address or a uniform resource locator (URL) link) corresponding to a cloud storage component associated with the cloud server <NUM> at which the digital evidence <NUM> is to be uploaded. In this embodiment, the portable device <NUM> transmits the resource identifier along with the digital evidence to the intermediary storage device <NUM> to enable the intermediary storage device <NUM> to upload the digital evidence <NUM> to the cloud storage component as identified by the resource identifier.

In one embodiment, the portable device <NUM> further transmits digital evidence metadata <NUM> including data integrity code to the intermediary storage device <NUM> to enable the intermediary storage device <NUM> to validate the data integrity of the digital evidence prior to uploading the digital evidence <NUM> to the cloud storage component of the cloud server <NUM>. The digital evidence <NUM> may be transmitted to the intermediary storage device <NUM> in real-time, for example, as a video stream. The intermediary storage device <NUM>, may in turn, uploads the digital evidence <NUM> to the cloud server <NUM>, either in real time or after receiving the entire stream from the portable device <NUM>.

Next, at block <NUM>, the portable device <NUM> transmits a request for approval to delete the digital evidence <NUM> stored at the memory <NUM> of the portable device <NUM>. In accordance with some embodiments, the portable device <NUM> is not enabled to delete the digital evidence <NUM> stored at the memory <NUM> of the portable device <NUM> unless an approval is received from the cloud server <NUM> which authorizes or causes the removal of the digital evidence <NUM> from the memory <NUM> of the portable device <NUM>. This approval is provided by the cloud server <NUM> only after the digital evidence <NUM> as identified by the digital evidence metadata <NUM> is validated for data integrity and successfully stored at the cloud storage component of the cloud server <NUM>. This process of removing the digital evidence after receiving an explicit approval from the cloud server <NUM> ensures that the chain of custody of digital evidence <NUM> is not violated. In addition, this process ensures that the digital evidence captured at the portable device <NUM> is always linked to the correct user (i.e., user of the portable device <NUM> at the time of capturing the digital evidence) since, otherwise it is possible that the portable device <NUM> is re-assigned to another user while the digital evidence captured by the previous user is still stored in the memory <NUM>. In accordance with some embodiments, the portable device <NUM> is re-assigned to another user only after removing the digital evidence <NUM> from the memory <NUM> in accordance with the approval received from the cloud server <NUM>.

The request for approval transmitted at block <NUM> may include information included in the digitally signed metadata <NUM>, for example, identifier of the digital evidence <NUM>, to enable the cloud server <NUM> to identify the digital evidence <NUM> and further check whether the digital evidence <NUM> is validated for data integrity and uploaded to the cloud storage component of the cloud server <NUM>. In one embodiment, the portable device <NUM> may receive an acknowledgment from the cloud server <NUM> indicating that the digital evidence <NUM> is uploaded to the cloud server <NUM> when the digital evidence <NUM> received from the intermediary storage device <NUM> is validated for data integrity and stored at the cloud storage component of the cloud server <NUM>.

Next, at block <NUM>, the portable device <NUM> checks whether it has received an approval from the cloud server <NUM> to delete the digital evidence <NUM> stored at the memory <NUM> of the portable device <NUM>. When the portable device <NUM> receives the approval from the cloud server <NUM>, the portable device <NUM> deletes the digital evidence <NUM> from the static memory <NUM> of the portable device <NUM> as shown in block <NUM>. The portable device <NUM> may present, via the electronic display <NUM>, a notification to the user of the portable device <NUM> indicating that the digital evidence <NUM> is deleted from the portable device <NUM>. In one embodiment, after deleting the digital evidence <NUM>, the portable device <NUM> may also present, via the electronic display <NUM>, a notification indicating that the portable device <NUM> is available for reassignment when it is determined that the portable device <NUM> has been returned by the user (e.g., placed on the multi-unit charger <NUM> at the end of work-shift) for reassignment.

Alternatively, when no approval is received, for example, before expiry of a set timer, or when a response received from the cloud server <NUM> indicates that the request for approval to delete the digital evidence <NUM> is rejected, the portable device <NUM>, at block <NUM>, refrains from deleting the digital evidence <NUM> from the memory <NUM> of the portable device <NUM>. In this case, the response indicating the rejection may further include information identifying a reason for rejecting the request to delete the digital evidence <NUM>. The cloud server <NUM> may reject the approval to delete the digital evidence <NUM> for reasons such as the digital evidence <NUM> as not being completely received from the intermediary storage device <NUM>, or the digital evidence <NUM> as not being completely uploaded to the cloud storage component, or the data integrity of the digital evidence <NUM> as not being valid.

The portable device <NUM> may repeat the same process as described in the method <NUM> for all digital evidences stored at the portable device <NUM>. In accordance with some embodiments, the portable device <NUM> presents, via the electronic display <NUM>, an indication that the device is available for re-assignment only when all digital evidences <NUM> stored at the memory <NUM> is successfully transferred to the cloud server <NUM>.

<FIG> illustrates a flow chart diagram of a method <NUM> of operating a cloud server <NUM> to preserve the chain of custody for digital evidence <NUM> captured at the portable device <NUM> in accordance with some embodiments. While a particular order of processing steps is indicated in <FIG> as an example, timing and ordering of such steps may vary where appropriate without negating the purpose and advantages of the examples set forth in detail throughout the remainder of this disclosure. As an example, the method <NUM> is performed by the electronic processor (not shown) of the cloud server <NUM>. Other embodiments of the method <NUM> may be performed on multiple processors within the same device or on multiple devices.

At block <NUM>, the cloud server <NUM> receives a request for approval from the portable device <NUM> to upload digital evidence <NUM> to the cloud server <NUM> via an intermediary storage device <NUM>. The request for approval includes a digitally signed digital evidence metadata <NUM> and also a first authentication credential associated with the intermediary storage device <NUM> and a second authentication credential associated with the portable device <NUM>. The digital evidence <NUM> may correspond to one or more of: video data, audio data, text data, or combination thereof, that are captured at the portable device <NUM>. The first and second authentication credentials include one or more of a device/user identifier, username-password, digital certificate, encrypted key, biometric key, and the like. The digital evidence metadata <NUM> includes a data integrity code that is generated as a function of the digital evidence <NUM> to be uploaded, and further optionally includes information related to one or more of: identifier (e.g., name of a video file corresponding to the digital evidence <NUM>) uniquely identifying the digital evidence <NUM>; a user profile or identifier of the owner of the portable device <NUM> or of the user operating the portable device <NUM> at the time the digital evidence <NUM> was captured/stored; the evidence a data type/format (e.g., video, audio, text etc.,) of digital evidence <NUM>; a time stamp of capturing/storing the digital evidence <NUM>; a data size of the digital evidence <NUM>; location data identifying locations at which the digital evidence <NUM> was captured; an incident identifier (e.g., computer aided dispatch (CAD) identifier) corresponding to an incident assigned to the user of the portable device <NUM>; one or more data tags, for example, identifying person, object, or entity of interest associated with the digital evidence <NUM>; and one or more environmental data (e.g., sensor data such as temperature, ambient noise etc.,) corresponding to a location at which the digital evidence <NUM> was captured.

In one embodiment, the cloud server <NUM> receives the request for approval via a secure communication channel, for example, a narrowband communication channel, that is directly established (i.e., by bypassing the intermediary storage device <NUM>) between the cloud server <NUM> and the portable device <NUM>. In another embodiment, the cloud server <NUM> may receive the request for approval through the intermediary storage device <NUM>, via the second communication link <NUM>.

In accordance with some embodiments, the cloud server <NUM> may authenticate the use of intermediary storage device <NUM> for transferring the digital evidence <NUM> to the cloud server <NUM> prior to receiving this request for approval from the portable device <NUM>. In these embodiments, the cloud server <NUM> receives, from the portable device <NUM>, an authentication challenge response including the first authentication credential associated with the intermediary storage device <NUM>. The cloud server <NUM> then transmits a response indicating whether the intermediary storage device <NUM> is a trusted device or not.

Next, at block <NUM>, the cloud server <NUM> verifies whether the received request for approval is valid based on the information included in the digitally signed metadata <NUM>, first authentication credential associated with the intermediary storage device <NUM>, and second authentication credential associated with the portable device <NUM>. In one embodiment, the cloud server <NUM> verifies that the received request for approval is valid when one or more of the following conditions are satisfied: a) the intermediary storage device <NUM> and portable device <NUM> are respectively determined as trusted devices based on the first and second authentication credentials received from the portable device <NUM>; and b) the intermediary storage device <NUM> is capable of supporting (e.g., in terms of storage capacity, network capability, or availability) the transfer of the digital evidence <NUM> to the cloud server <NUM>. For example, the cloud server <NUM> determines that the intermediary storage device <NUM> is capable of supporting the transfer of the digital evidence <NUM> when the intermediary storage device <NUM> has storage capacity for storing an amount of data corresponding to the data size of the digital evidence <NUM> as identified in the received digitally signed evidence metadata <NUM>. On the other hand, when the portable device <NUM> or intermediary storage device <NUM> is determined to be not a trusted device or when the intermediary storage device <NUM> is determined to be not capable of supporting the transfer of digital evidence <NUM> to the cloud server <NUM>, the cloud server <NUM> verifies that the received request for approval is not valid.

Accordingly, when the cloud server <NUM> determines that the received request is not valid, the cloud server <NUM>, at block <NUM>, transmits a response, via the secure communication channel, indicating that the request for approval to upload the digital evidence <NUM> is rejected. In one embodiment, the response also includes additional information identifying the reason (e.g., intermediary storage device <NUM> does not have sufficient storage) for rejecting the request. Alternatively, when the cloud server <NUM> determines that the received request is valid, the cloud server <NUM>, at block <NUM>, transmits a response indicating approval to upload the digital evidence <NUM> via the intermediary storage device <NUM>. In one embodiment, the cloud server <NUM> includes in the response, a resource identifier (e.g., a network address or a URL link) corresponding to a cloud storage component of the cloud server <NUM> at which the digital evidence <NUM> is to be uploaded.

Next, at block <NUM>, the cloud server <NUM> receives the digital evidence <NUM> from the intermediary storage device <NUM>, via the second communication link <NUM> (for example, via a broadband communication channel). In one embodiment, the intermediary storage device <NUM> receives the digital evidence <NUM> and forwards the digital evidence <NUM> to a cloud storage component of the cloud server <NUM> as identified by the resource identifier.

Next, at block <NUM>, the cloud server <NUM> validates the data integrity of the received digital evidence <NUM> using the data integrity code included in the digitally signed evidence metadata <NUM>. For example, when the data integrity code includes a checksum value corresponding to the digital evidence <NUM>, the cloud server <NUM> calculates checksum value on the received digital evidence <NUM> and further compares the calculated checksum value with the received checksum value. If the two checksum values match, the data integrity of the received digital evidence <NUM> is ensured and the cloud server <NUM> marks the validity of the data integrity to be valid. Otherwise, if the two checksum values do not match, the cloud server <NUM> marks the data integrity of the digital evidence <NUM> to be invalid. While checksum values are used herein to describe the data integrity validation process, other types of functions, such as hash values can be used to validate the data integrity as well.

At block <NUM>, the cloud server <NUM> determines whether the data integrity of the received digital evidence <NUM> is marked as valid. When the data integrity of the digital evidence <NUM> is marked as valid, the cloud server <NUM>, at block <NUM>, stores the digital evidence <NUM> at a cloud storage component associated with the cloud server <NUM>. The cloud server <NUM> may also send an acknowledgment indicating that the digital evidence <NUM> is (i.e., after successfully validating the data integrity) uploaded to the cloud server <NUM>. In one embodiment, after validating the data integrity, the cloud server <NUM> may further provide permission to the portable device <NUM> to delete the digital evidence <NUM>, prior to receiving a request for approval to delete the digital evidence <NUM> from the portable device <NUM>. In accordance with some embodiments, the cloud server <NUM> associates the digital evidence <NUM> stored at the cloud storage component to various devices (and corresponding users) including a source device (e.g., portable device <NUM>) and intermediate devices (intermediary storage device <NUM>) at which the digital evidence <NUM> was captured/stored prior to uploading the digital evidence <NUM> to the cloud server <NUM>. This association or linking of the digital evidence <NUM> to the devices/users allows for tracing the chain of custody for digital evidence <NUM> uploaded to the cloud server <NUM>. In accordance with some embodiments, the entire digital evidence <NUM> along with the above association information is encrypted prior to being stored at the cloud storage component of the cloud server <NUM>.

At block <NUM>, the cloud server <NUM> receives a request for approval, for example, via the secure communication channel, to delete the digital evidence <NUM> stored at the memory <NUM> of the portable device <NUM>. This approval is provided by the cloud server <NUM> only after the digital evidence <NUM> as identified by the digital evidence metadata <NUM> is validated for data integrity and successfully stored at the cloud storage component of the cloud server <NUM>. The request for approval transmitted at block <NUM> may include information included in the digitally signed evidence metadata <NUM>, for example, identifier of the digital evidence <NUM>, to enable the cloud server <NUM> to identify the digital evidence <NUM> and further check whether the digital evidence <NUM> is validated for data integrity and uploaded to the cloud storage component of the cloud server <NUM>. In accordance with some embodiments, the portable device <NUM> is not enabled to delete the digital evidence <NUM> stored at the memory <NUM> of the portable device <NUM> unless an approval is received from the cloud server <NUM> which authorizes or causes the removal of the digital evidence <NUM> from the memory <NUM> of the portable device <NUM>.

At block <NUM>, the cloud server <NUM> transmits, for example, via the secure communication channel, a response indicating an approval to delete the digital evidence <NUM> since the cloud server <NUM>, in this case, has already marked the data integrity of the digital evidence <NUM> to be valid and stored the digital evidence <NUM> at the cloud storage component as shown in block <NUM>. In accordance with some embodiments, the cloud server <NUM> receives a confirmation from the portable device <NUM> indicating that the digital evidence <NUM> is deleted from the portable device <NUM>. In these embodiments, the cloud server <NUM>, after receiving the confirmation, may transmit an instruction to the portable device to provide an indication that the portable device is available for reassignment when a reassignment request is received from the portable device and/or another user/device in the system <NUM>.

Returning to block <NUM>, when the cloud server <NUM> determines that the data integrity of the digital evidence <NUM> is marked as invalid, the cloud server <NUM>, as shown in block <NUM>, refrains from storing the digital evidence <NUM> at the cloud storage component of the cloud server <NUM>. Alternatively, the cloud server <NUM> may store the digital evidence <NUM> at the cloud storage component, but does not link or associate the various devices/users associated with the digital evidence <NUM> to the stored digital evidence <NUM>.

Next, at block <NUM>, the cloud server <NUM> receives a request for approval, for example, via the secure communication channel, to delete the digital evidence <NUM> stored at the memory <NUM> of the portable device <NUM>. This approval is provided by the cloud server <NUM> only after the digital evidence <NUM> as identified by the digital evidence metadata <NUM> is validated for data integrity and successfully stored at the cloud storage component of the cloud server <NUM>. The request for approval transmitted at block <NUM> may include information included in the digitally signed evidence metadata <NUM>, for example, identifier of the digital evidence <NUM>, to enable the cloud server to identify the digital evidence <NUM> and further check whether the digital evidence <NUM> is validated for data integrity and uploaded to the cloud storage component associated with the cloud server <NUM>.

At block <NUM>, the cloud server <NUM> transmits, for example, via the secure communication channel, a response indicating that the request for approval to delete digital evidence <NUM> is rejected since the cloud server <NUM>, in this case, has marked the data integrity of the received digital evidence <NUM> to be invalid and further refrained from storing the digital evidence <NUM> at the cloud storage component at block <NUM>. In this case, the response indicating the rejection may further include information identifying a reason (e.g., data integrity is not valid) for rejecting the request to delete the digital evidence <NUM>.

In accordance with some embodiments, the cloud server <NUM> stores a full audit log of the above described process for traceability of the chain of custody for digital evidence <NUM>. The audit log may include information related to the type of messages transmitted and/or received (e.g., request message received or corresponding response message transmitted to approve the uploading or deletion of the digital evidence <NUM> or to verify the authenticity of the intermediary storage device) at the cloud server <NUM>, type of actions performed at the cloud server <NUM> (e.g., providing approval to upload or delete digital evidence <NUM>, verifying data integrity, etc.,), identifiers of the devices (e.g., portable device <NUM> and intermediary storage device <NUM>) from which the messages were transmitted; user identifiers corresponding to the users (e.g., user of the portable device <NUM>) operating the device that captured the digital evidence <NUM>; time stamp associated with such message transmission/reception or such actions; and the like. The audit log allows the cloud server <NUM> and/or another device to trace the chain of custody for digital evidence <NUM>, for example, to identify a device at which the digital evidence <NUM> was captured, or identify an intermediary storage device through which the digital evidence <NUM> was transmitted before being stored at the cloud storage component, or identify a user who was operating the device at the time of capturing the digital evidence <NUM>.

The chain of custody for digital evidence <NUM> captured at the portable device <NUM> is thereby preserved using the methods <NUM>, <NUM> by: a) copying the digital evidence <NUM> from the portable device <NUM> to a more stable and redundant cloud storage component; b) ensuring that the intermediary storage device <NUM> is a trusted device prior to transmitting the digital evidence <NUM>; c) digitally signing the evidence metadata <NUM> including the data integrity code; d) enabling the cloud server <NUM> to validate the digital evidence <NUM> using the data integrity code included in the digitally signed metadata <NUM>; e) associating or linking the uploaded digital evidence <NUM> to correct identity of the user (e.g., officer) who captured the digital evidence <NUM> using the portable device <NUM>; and f) deleting the digital evidence <NUM> from the memory <NUM> of the portable device <NUM> only after receiving an approval to delete the digital evidence <NUM> from the cloud server <NUM>. In accordance with some embodiments, the same process as described with reference to the methods <NUM>, <NUM> are applied for transferring all digital evidences <NUM> stored at the portable device <NUM> to the cloud server <NUM>.

While the above embodiments are directed towards transferring the digital evidence <NUM> via the intermediary storage device <NUM>, in some embodiments, the portable device <NUM> is configured to directly transfer the digital evidence <NUM> to a cloud storage component of the cloud server <NUM>. In these embodiments, the portable device <NUM> may have sufficient network capability (e.g., with LTE connection) to transfer digital evidence <NUM> including video data to the cloud server <NUM>. In some of these embodiments, the portable device <NUM> is configured to transfer digital evidence <NUM> directly to cloud server <NUM> based on an instruction received from the cloud server <NUM>. The cloud server <NUM> may send instruction to portable device <NUM> to directly transfer the digital evidence <NUM>, for example, when it is determined that the intermediary storage device <NUM> identified by the portable device <NUM> is not a trusted device or alternatively not capable of or available to transfer the digital evidence <NUM>.

Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," "has," "having," "includes," "including," "contains," "containing" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises. a," "includes. a," or "contains. a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms "a" and "an" are defined as one or more unless explicitly stated otherwise herein. The terms "substantially," "essentially," "approximately," "about" or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art, and in one non-limiting embodiment the term is defined to be within <NUM>%, in another embodiment within <NUM>%, in another embodiment within <NUM>% and in another embodiment within <NUM>%. The term "coupled" as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

Moreover, an embodiment may be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (for example, comprising a processor) to perform a method as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

Claim 1:
A method for preserving chain of custody for digital evidence (<NUM>) captured at a portable device (<NUM>), the method comprising:
transmitting, at the portable device (<NUM>), to a cloud server (<NUM>), a request for approval to upload the digital evidence (<NUM>) to the cloud server (<NUM>) via an intermediary storage device (<NUM>), the request comprising a digitally signed metadata associated with the digital evidence (<NUM>), a first authentication credential associated with the intermediary storage device (<NUM>), and a second authentication credential associated with the portable device (<NUM>), wherein the digitally signed metadata includes a data integrity code that is generated as a function of the digital evidence (<NUM>) to be uploaded in response to receiving an approval from the cloud server (<NUM>);
receiving, at the portable device (<NUM>), a first response to the request for approval from the cloud server (<NUM>), the first response indicating approval provided by the cloud server (<NUM>) to upload the digital evidence (<NUM>) to the cloud server (<NUM>) via the intermediary storage device (<NUM>), wherein the approval is provided by the cloud server (<NUM>) after verifying that the intermediary storage device (<NUM>) is a trusted device and that the intermediary storage device (<NUM>) is capable of supporting the transfer of the digital evidence (<NUM>) from the portable device (<NUM>) to the cloud server (<NUM>);
responsive to receiving the first response, transmitting, at the portable device (<NUM>), the digital evidence (<NUM>) to the intermediary storage device (<NUM>) for uploading to the cloud server (<NUM>);
transmitting, at the portable device (<NUM>), to the cloud server (<NUM>), a request for approval to delete the digital evidence (<NUM>) from the portable device (<NUM>);
receiving, at the portable device (<NUM>), a second response from the cloud server (<NUM>), the second response indicating an approval to delete the digital evidence (<NUM>) from the portable device (<NUM>); and
responsive to receiving the second response, deleting, at the portable device (<NUM>), the digital evidence (<NUM>) from the portable device (<NUM>).