Method and device for uploading data

Abstract

Method for uploading data destined for a central repository, wherein the data is uploaded to an intermediary upload device before being uploaded to the central repository, the method comprising the following step: - Determining mobile / intermediary uploading devices on site; the procedure being characterized by the following steps: - Determining the probability that the mobile / intermediary upload devices will return to a connected upload point; - Identifying those mobile / intermediary upload devices with a higher probability of returning to the connected upload point; and - Uploading the data to those mobile / intermediary upload devices with the higher probability of returning to the connected upload point.

Description

Field of invention

[0001] The invention relates generally to the uploading of data and in particular to a method and a device for uploading data to an intermediary device.

[0002] From US patent 2004 / 0008255 A1, methods according to the preambles of claims 1 and 7 and a device according to the preamble of claim 19 are known.

[0003] Other publications directly or indirectly relating to the field of the invention are US 2004 / 0177253 A1, US 2007 / 0132773 A1 and US 2009 / 0170537 A1. Background of the invention

[0004] Vehicles such as buses, fire engines, police cars, etc., often contain in-vehicle mobile digital video recording systems (mDVRs). These mDVRs record the scene from the front window of the vehicle as well as other perspectives (e.g., from the rear window, passengers in the back seat, etc.). In addition to video, the mDVR also records audio and telemetry information, such as the vehicle's speed, its geographical location, etc. The content recorded by the mDVR is collectively referred to as digital multimedia evidence (DME) and is stored digitally in in-vehicle storage (such as a traditional spinning hard drive or a solid-state drive).

[0005] Depending on the resolution and quality of the recorded video, the video portion of the DME can consume up to 5 Mbps of storage space per camera, ranging from 1.5 Mbps per second (Mbps) (audio and telemetry data storage space is negligible in comparison). For a two-camera system, a recording can therefore consume between 1 GB and 4 GB of storage space per hour. Consequently, the mDVR storage can easily contain 10 GB or more of evidence data by the end of a shift.

[0006] Public safety agencies typically upload all recordings from all vehicles to a long-term digital back-end system for managing evidence (central repository). These back-end systems allow users to review the DME, link it to a court case, and manage the long-term retention of the DME to meet state or local requirements. One or more mobile / intermediate upload points are used to upload the DME from the vehicle's storage device to the back-end system. The transfer of the DME to the central repository typically occurs via one of three methods: physically removing the storage device from the vehicle followed by connecting the storage device to the back-end; a wired connection to the vehicle; or a wireless upload.Once the upload is complete, the DME is typically deleted by the vehicle's internal system or marked so that it can be overwritten when space is needed in the memory for new recordings.

[0007] Physically removing the storage medium from the mDVR is an efficient way to quickly get the vehicle back on the road (by immediately replacing the storage device with a blank one), but it has many evidentiary and procedural drawbacks. To protect the evidence from a malicious employee, the storage medium is typically physically enclosed within the recording device. To remove it, an authorized employee—typically a supervisor—must disengage the device and take out the storage medium, resulting in a supervisor spending a significant amount of time going from car to car collecting storage media. This technique also requires the supervisor to formally record that they took possession of the storage medium and when they submitted it to the evidence management system for acceptance, in order to maintain the chain of evidence.While it allows for a rapid turnover of vehicles, manual transfer is very expensive for the department from a personnel efficiency standpoint and is therefore not the preferred uploading method in the industry.

[0008] Wired uploading involves connecting a physical cable to the vehicle, which incurs additional costs for the agency, as it must run physical cables to multiple bays at the station. Besides the inconvenience of connecting and disconnecting the cable to the vehicle, this method also carries the risk of damaging the uploading equipment if employees accidentally drive off without first disconnecting. Furthermore, there are security concerns with cables connected to the agency's network in an unsecured outdoor environment. While more agencies are using wired uploading compared to manual transfer, it is not the preferred uploading method in the industry due to the aforementioned disadvantages.

[0009] Due to the costs, inefficiencies, evidentiary issues, and security concerns of the other two approaches, the preferred method for uploading DME data from the vehicle is to automatically perform a wireless transfer of the content as soon as the vehicle approaches an upload point near the central repository (e.g., the police station parking lot or nearby public buildings). The major challenge with this approach is that wirelessly transferring 10 GB or more of DME data from multiple vehicles in a parking lot is a massive undertaking from a data transfer perspective. Even with only one vehicle in the parking lot, transferring 10 GB+ of data using current 802.11n technology (assuming a very optimistic data rate of 150 Mbps) takes approximately 10 minutes.A parking lot full of vehicles for shift changes, all attempting to upload simultaneously, will result in significantly longer transmission times, meaning the DME upload is unlikely to be complete before a new officer needs the vehicle to begin their next shift. If a department mandates that all DME data must be uploaded before the vehicle is used again, this will delay dispatching the vehicle and officer to the road.

[0010] The upload problem is exacerbated when considering vehicles that don't return to the station's parking lot (or other upload zone) at the end of a shift. For example, it's typical for county or state police departments to permanently assign a vehicle to an officer who takes it home at the end of the workday and returns to a station / central depot only rarely (such as once a month). This means that on the rare occasions when the vehicle does return to the station, it's quite possible that 100 GB+ of DME (Digital Mechanism of Investigation) data will need to be downloaded. Not only does it take a very long time to upload this amount of content, but there may also be recordings on the mDVR (mobile DVR) that are needed for evidentiary purposes but are unavailable in the digital evidence management system until the upload occurs.Furthermore, when the storage medium in the device becomes full, the mDVR is no longer able to record new incidents and forces the employee to make a special trip to an upload point at the central storage facility in order to make additional recordings.

[0011] Therefore, there is a need for a method and device for uploading data that reduces the time a vehicle spends uploading DME. It would be beneficial if the method and device also allowed for more timely DME uploading for vehicles that do not regularly return to a station or upload area (e.g., state or county employees who take their vehicles home). Brief description of the drawings

[0012] The accompanying drawings, in which the same reference numerals denote identical or functionally similar elements across the individual views, and which together with the following detailed description form part of the application, serve to further illustrate different embodiments and to explain various principles and advantages, all in accordance with the invention. Fig. Figure 1 shows a system for collecting, storing, and uploading data. Fig. 2 is a block diagram of the computer from Fig. 1. Fig. 3 is a flowchart that illustrates the operation of the computer from Fig. 1 indicates when it uploads data to another computer. Fig. 4 is a flowchart that illustrates the operation of the computer from Fig. 1 shows the action while receiving data from another computer.

[0013] The person skilled in the art will recognize that the elements in the drawings are presented for the sake of simplicity and clarity and are not necessarily drawn to scale. For example, the dimensions and / or relative positions of some elements in the drawings may be exaggerated compared to others to improve the understanding of different embodiments of the invention. Likewise, common but well-understood elements that are useful or necessary in an industrially feasible embodiment are often omitted to facilitate a less obscured view of these different embodiments of the invention. Furthermore, it will be recognized that certain actions and / or steps may be described or illustrated in a particular sequence, whereas the person skilled in the art will understand that such a specific sequence is not actually required. Detailed description

[0014] To address the aforementioned need, a method and device for uploading data are hereby provided. During operation, such as during an incident response, vehicles in the field will upload their digital multimedia evidence (DME) to one or more mobile / intermediary upload points. These mobile / intermediary upload points preferably comprise computers located in other vehicles that are not currently connected to a central repository.A mobile recording device (mDVR) will select one or more specific mobile / intermediary upload points based on a probability that the one or more mobile upload points will return to a connected upload point (a connected upload point is defined herein as an upload point that has a direct connection to the central repository) to upload the transmitted DME.

[0015] The above technique provides a system that "cross-transmits" the DME from the original mDVR to one or more intermediary / mobile upload points, preferably before the original mDVR returns to the connected upload point. A mobile / intermediary upload point is any device that can contain DME but is not connected to the central back-end storage. Examples of a mobile / intermediary upload point could be another mDVR unit in a different public safety vehicle, a dedicated mDVR unit with a particularly large storage medium installed, for example, in a fire engine, or a handheld device (smartphone, two-way radio, etc.) carried by the operator. Once the DME has been cross-transmitted to a mobile / intermediary upload point, each device will have a copy of the DME.The same DME can be transferred across multiple mobile / intermediary upload points. Whenever one of the devices containing a copy of the DME reaches a connected upload point (e.g., when the fire engine returns to the fire station), this DME is uploaded to the central repository (e.g., a back-end evidence management system). Once the DME upload is complete, a notification message is sent to all devices that have the DME on their internal storage, and the DME can either be deleted from the vehicle's internal system or marked so that it will not be uploaded again and can be overwritten if space is needed on the disk for new recordings. This upload-complete notification can be sent immediately over a wide-area network (WAN) connection or at a later time (e.g., after a certain period of time).(the next time the vehicle's internal system connects to a connected charging point).

[0016] The system described above ensures that for vehicles that do not regularly return to a station / uploading zone, the DME is uploaded in a more timely manner, and it reduces the time a vehicle spends uploading DME.

[0017] Note that the above-described technique for uploading video to an intermediary device achieves the best results when a suitable intermediary device is selected. To choose the best intermediary device, the mDVR should select one that has a higher probability than the mDVR of returning to a connected upload point. Ideally, if multiple mobile / intermediary upload points are available, the selected mobile / intermediary upload points should all have a higher probability of returning to a central storage upload point sooner than the mDVR. To achieve this, each intermediary device can broadcast a calendar indicating when it will be near a central storage upload point and / or how long the intermediary device will remain at a particular location.This information can be used when selecting an intermediary device. Alternatively, the system administrator can pre-assign a relative priority value to each mobile / intermediary upload point at setup time. For example, the system administrator can define that fire trucks always have a higher priority value than police vehicles, since fire trucks typically return to the fire station immediately after an incident. Police command vehicles can be assigned a higher priority than regular police patrol cars but a lower priority than fire trucks. mDVR units would then evaluate the relative priority values ​​of all available mobile / intermediary upload points and select the one with the highest priority.

[0018] Other factors can be considered when choosing an intermediary device. For example, the following can be taken into account when choosing an intermediary device: • A transmission speed between a donor device and an intermediary device can be taken into account, so that connections with a higher transmission speed are preferred. • The transmission speed from the mediating device to the final connected upload point can be taken into account, so connections with a higher transmission speed are preferred. The available transferable capacity of the mediating device can also be considered, so devices with a higher storage capacity are preferred. • A time until arrival at the upload location (guard station, court, prison, toll plaza, etc.) can be taken into account, so that devices with a greater probability of an earlier return to a connected upload point are preferred. • An estimated backlog at the intermediary device during uploads to the central repository can be taken into account. For example, if a vehicle at the courthouse uploads to the central repository in an hour when few other uploads are expected, it would be given priority over a vehicle driving to the police station in an hour when several vehicles will be uploading to the repository during shift changes. • A department can be taken into account, so that an internal transfer is preferred (e.g., a police-to-police transfer is preferred over a transfer, for example, from the police to the fire department).

[0019] Turning now to the drawings in which the same reference symbols denote the same components, it shows Fig. 1. A system for collecting, storing, and uploading data. As shown, the system 100 comprises several cameras 101 (only one of which is designated with a reference numeral). In one embodiment, one or more of the cameras are mounted on a fixed or movable / remotely positionable camera mount 105. In another embodiment, at least one environmental sensor 102 is provided to separately record external stimuli such as speed, weather conditions, location, etc. A logic circuit and storage unit 103 comprises a simple computer that serves to control the camera mounts 105 and to record data from the sensor(s) 102 and from the cameras 101. Communication between elements of the system 100 takes place via one or more buses 104 and / or wirelessly.Although not shown, additional lines may be present, for example, between the computer 103 and the camera mounts 105, to remotely control the positioning of the camera mount. In a preferred embodiment, the system 100 is mounted on and / or partially inside a vehicle such as a bus, a fire engine, or a police car, but can alternatively be worn by a person such as a police officer.

[0020] Fig. Figure 2 is a block diagram of a computer 103 that functions as an mDVR. The computer 103 can act as an mDVR that wants to offload DME to intermediary devices, or alternatively, it can act as an intermediary device that receives DME from another mDVR 103. As shown, the computer 103 comprises a logic circuit 203, a receive circuit 202, and a transmit circuit 201. The logic circuit 203 comprises a digital signal processor (DSP), a general-purpose microprocessor, a programmable logic device, or an application-specific integrated circuit (ASIC) and is used to store DME received from cameras and sensors. The logic circuit 203 can determine a priority for an intermediary device and transfer stored data to intermediary devices that have a higher priority than other intermediary devices.Additionally, the receiving and transmitting circuits are ordinary circuits known to those skilled in the art for communication using a generally known communication protocol and serve as means for sending and receiving messages and for uploading DME to a central repository or downloading DME from another mDVR. For example, the receiver 202 and the transmitter 201 are generally known transmitters that use the IEEE 802.11 communication system protocol. The memory 205 comprises ordinary random access memory (RAM) and is used to store DME.

[0021] Optionally, a calendar 207 can be provided. Calendar 207 can exist in a separate memory location or be included in memory 205. Calendar 207 preferably contains information such as, but not limited to: • A period of time during which Computer 103 will remain in a specific location; • A time at which Computer 103 will leave a specific location; • A time when computer 103 will return to an upload point of the central storage; • A period of time during which computer 103 will remain at an upload point of the central storage.

[0022] Finally, a priority of 209 can be provided. The priority can simply be a number indicating the priority of the computer when acting as an intermediary device.

[0023] As an example of the system described above in operation, let's assume there is a district police vehicle that does not regularly return to a connected upload point because the officer takes his car home every evening. Over the past week, a large amount of DME data has been collected on its mDVR unit.

[0024] One day, the officer responds to an incident large enough to require multiple vehicles at the scene. For example, a fire truck, an ambulance, and other police vehicles might be present. While at the scene, the officer's mDVR unit automatically begins using a vehicle-area wireless network (such as 802.11n) to analyze calendars, data rates, and available storage space for potential mobile / intermediary upload points (i.e., other computers in the other vehicles at the scene). A determination of the best upload candidate(s) (described in detail below) will be performed, and the DME will be transmitted (uploaded) to the best candidate(s).

[0025] For example, let's assume that a fire truck equipped with a computer 103 has been identified as the best candidate for uploading data. The DME transmission to the fire truck will then take place. It is acceptable that this transmission takes several tens of minutes because the vehicles are at the scene and responding to the incident.

[0026] The procedure for locating mobile / intermediary upload points could be performed using any number of known service discovery protocols, so that the mDVR unit does not need to be pre-configured with the IP addresses of all mobile / intermediary upload points. Known techniques can also be used to ensure that a mobile / intermediary upload point is part of the same agency's fleet and should be entrusted with a copy of the DME.

[0027] When the incident ends, several vehicles leave the scene, each carrying a copy of part or all of the DME from the officer's vehicle.

[0028] Typically, the fire truck returns directly to the fire station after an incident. Immediately upon returning, the fire truck connects to the central storage system and uploads its pagers (both the fire truck's pager and the officer's pager). This upload process is not as time-sensitive as a typical upload at the police station because the fire truck remains in the garage for a considerable amount of time between incidents. Furthermore, the fire truck always parks in the same spot in the garage, making it much easier to use directional, high-speed wireless technology such as 60 GHz or even wired Ethernet (since the vehicle is in a secure garage and the setup is significantly more cost-effective).

[0029] Once the upload process is complete, a message can be sent to all vehicles that have a copy of the DME (i.e., all Computer 103s that were at the scene), notifying them that the DME has been uploaded. Alternatively, the message can be sent when the vehicles that have a copy of the DME eventually connect to the upload point. This message can originate from the Computer 103 located within the fire engine or, alternatively, from the central repository. The Computer 103s that have a copy of the DME can delete or flag the DME so that it is not uploaded again and can be overwritten when space is needed on the disk for new records.

[0030] To ensure that the DME is not altered during cross-transmission and uploading, established techniques can be used (such as the use of a digital signature), or it is also reasonable to use simpler techniques, for example, configuring the central repository to communicate with the original mDVR via the wide-area network (such as 3G / 4G data networks) to obtain the cryptographic hash (such as SHA1) of the original DME in order to compare it with the hash of the uploaded DME. In one embodiment, the transmission and reception of DME can be carried out securely, for example, as described in US Publication No. 2004 / 0177253 entitled "AUTOMATED AND SECURE DIGITAL MOBILE VIDEO MONITORING AND RECORDING".

[0031] Fig. Figure 3 is a flowchart showing computer 103 (acting as an mDVR) in operation as it transmits DME to another computer 103. Fig. Figure 3 thus shows the steps (some of which may be optional) for uploading data destined for a central storage location, wherein the data is uploaded to an intermediary upload device 103 before being uploaded to the central storage location. In this specific logic flow, it is assumed that data from cameras 101 and sensor 102 have been received by the microprocessor 203 and stored in memory 205 as DME.

[0032] The logical flow begins with step 301, where the microprocessor 203 detects that other computers (mobile / intermediary upload devices) 103 are at (near) the deployment site. This detection can be as simple as recognizing a system identifier (System ID) via receiver 202, broadcast by other computers 103. A standard link with the other computers is established using the microprocessor 203, sender 201, and receiver 202 (step 303).

[0033] In step 305, a best candidate for uploading DME is determined, or alternatively, several best candidates are determined by the microprocessor 203. In one example, the best candidate computer or computers 103 are determined based on a priority. This priority can simply be a probability that they will return to a connected upload point in the near future (e.g., within the next few hours). This priority determination can be performed by the microprocessor 203, which receives multiple calendars 207 from each potential mobile / intermediary upload device 103 via the receiver 202.These received calendars can be analyzed (along with other information such as transfer rates) to determine the best candidate computer or computers by identifying those mobile / intermediary upload devices that are more likely to return to the connected upload point. Those devices with a higher probability of returning to the connected upload point are given higher priority.

[0034] In another example, the best candidate computer(s) 103 are determined based on a relative priority value 209 assigned in advance by an administrator and wirelessly transmitted from each intermediary / mobile device. Using such a stored priority, the microprocessor 203 will receive multiple priorities 209 from multiple computers 103 via the receiver 202. These received priorities can then be analyzed, and a transmission will be made to the computer 103 with the highest priority.

[0035] In step 307, the upload to the identified candidate computers 103 begins, whereby the microprocessor 203 transmits data from the memory 205 via the transmitter 201 to the candidate computer 103.

[0036] At a later time, the receiver 202 can receive information from a central storage location (e.g., a back-end system) indicating that the uploaded DME has been transferred to it from the candidate computer(s), and the uploaded DME can then be deleted from memory 205 or marked as already uploaded, so that it can be deleted from memory 205 at a later time (e.g., when space is needed).

[0037] Note that in Fig. 3. The selected mobile / intermediary upload devices are not connected to the central repository during the data upload process. Furthermore, the selected devices may serve as mobile digital video recording devices (mDVRs) within vehicles. Additionally, the data uploaded to the mobile / intermediary upload devices includes digital multimedia evidence (DME).

[0038] While in the above description of Fig. 3. Where the device 103 determines a priority based on a received calendar or simply on the basis of a priority received from other devices 103, the priority in other embodiments of the invention can be determined on the basis of: • a probability that a mobile / intermediary upload device will return to an upload point within a given time period; • of available disk space of a mobile / intermediary upload device; • a period of time during which the mobile / intermediary uploading device(s) will remain at the deployment site; • a time at which the mobile / intermediary uploading device(s) will leave the deployment site; • a time when the mobile / intermediary device will return to an upload point of a central storage location; • a time during which the mobile / intermediary device will remain at the central storage location; • a transmission speed of the mediating / mobile device, so that connections with a higher transmission speed are preferred; • an available transferable capacity of the mediating / mobile device(s), so that devices with a higher storage capacity are preferred; • an estimated traffic jam of the intermediary / mobile device(s) during upload to the central repository; or • a department, so that a transfer within the department is preferred;

[0039] Fig. 4 is a flowchart that illustrates the operation of the computer from Fig.1 indicates when it receives data from another computer. The logical flow begins in step 401, where the microprocessor 203 determines that other computers 103 are in the area (nearby). This determination can simply consist of a receiver 202 detecting a system ID broadcast by other computers 103. A standard connection with the other computers is established using the microprocessor 203, the sender 201, and the receiver 202 (step 403).

[0040] In step 405, the calendar 207 or the priority 209 is sent to all linked computers via sender 201. In response, another computer 103 receives and acknowledges a request to receive DME (step 407). Receiver 202 then begins receiving uploaded DME, which is stored by microprocessor 203 in memory 205 (step 409). At a later time, receiver 202 may receive a notification that it is near a connected upload point (step 411). This notification may be in the form of a simple system identifier sent by an access point connected to the central repository. In step 413, the uploaded DME is transferred to the central repository and deleted from memory 205.

[0041] As discussed above, many techniques exist for determining candidate computers for transmitting DME. These techniques can be designed as described above, based on a received calendar, a priority, and a determined probability of returning to a connected upload point. However, additional factors can be useful in determining the best candidate computer. Considering the general case of multiple vehicles at a single location, it would be ideal to transmit as much DME as possible. Also note the fact that multiple simultaneous transmissions may occur.A candidate computer 103 (or more) can be determined based on a minimum transfer time (instead of or in addition to a probability of returning to the connected upload point), where minimum transfer time = (DME size / transfer time), where the transfer speed is Min(upload speed of donor vehicle, download speed of receiver vehicle). This avoids the situation where a receiver with very high capacity is hampered by a slow transfer from a slow donor.

[0042] With the above in mind, the microprocessor 203 could calculate a priority for all computers 103 at the location (for example, based on the highest value of a video clip the vehicle is carrying). A transfer time could be calculated for each computer 103, and if the transfer time is shorter than the estimated time at the location, the computer in question would be added to a list of potential computers 103. The list of potential computers would then be sorted by storage capacity (fully available before transferable, transferable after the priority of the transferred video). Thus, those computers 103 with more storage capacity would be given priority over those computers 103 with less storage capacity.

[0043] The technique described above results in a group of computers with: • Candidate computers that are capable of receiving the entire DME transfer within a given timeframe and have a higher priority than those that are unable to do so; and • those computers 103 with sufficient available disk space, which are given priority over those that do not.

[0044] Once the group of candidate computers (103) has been determined, their calendars can be analyzed to determine the probability of returning to a connected upload point. Those with a higher probability of return will be given priority.

[0045] Specific embodiments were described in the preceding description. However, those skilled in the art will recognize that various modifications can be made without departing from the scope of the invention as defined in the claims below. Accordingly, the description and the drawings are not to be understood in a limiting but rather in an illustrative sense, and it is intended that all such modifications should remain within the scope of the present teachings.

[0046] It is furthermore clear to those skilled in the art that reference to specific implementation forms, such as "circuit," can be achieved via either a general-purpose computing device (e.g., CPU) or a specialized processing device (e.g., DSP) that executes software instructions stored in non-volatile, computer-readable memory. It is also clear that the terms and expressions used herein have the ordinary technical meanings attributed to such terms and expressions by those skilled in the art, as set forth above, except where otherwise different specific meanings have been set forth herein.

[0047] The benefits, advantages, problem solutions, and any conceivable element that leads to or enhances any benefit, advantage, or solution shall not be construed as critical, necessary, or essential features or elements of any claim or all claims. The invention is defined exclusively by the attached claims, including any amendment made during the pendency of the present application and all equivalents of such claims as published.

[0048] Furthermore, in this document, relational expressions such as first and second, above and below, and the like are to be used solely to distinguish one entity or action from another, without necessarily requiring or implying any actual relationship or order between such entities or actions. The expressions "includes," "comprising," "has," "having," "include," "containing," "containing," or any variation thereof are to cover non-exclusive inclusion, such that a process, procedure, article, or device that includes, has, includes, or contains a list of elements may not only include such elements but may also include other elements not expressly listed or inherent in such processes, procedures, articles, or devices. An element that continues with "includes... a," "has..."The terms "one," "includes... one," and "contains... one" do not, without further stipulations, exclude the existence of additional identical elements in the process, method, article, or apparatus that comprise, have, include, or contain the element. The terms "one" and "a" are defined as one or more unless explicitly stated otherwise herein. The terms "essentially," "essentially," "approximately," "about," or any other version thereof are defined as "being close to" as is clear to those skilled in the art, and in one non-limiting embodiment, the term is defined as being within 10%, in another embodiment within 5%, in another embodiment within 1%, and in yet another embodiment within 0.5%. 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 at least in that way, but may also be configured in at least one other way not listed.

[0049] It is desired that some embodiments include one or more generic or specialized processors (or “processing devices”), such as microprocessors, digital signal processors, custom processors and freely programmable field-gate arrays (FPGAs) and unique stored program instructions (comprising both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuitry, some, most or all of the functions of the method and / or device described herein.Alternatively, some or all functions can be implemented by a state machine that has no stored program instructions, or in one or more application-specific integrated circuits (ASICs) where each function, or some combinations of certain functions, are implemented as custom logic. Naturally, a combination of the two approaches can be used.

[0050] Furthermore, an embodiment can be implemented as a computer-readable storage medium containing computer-readable code stored thereon for programming a computer (which, for example, includes a processor) to perform a method described and claimed herein. Examples of such computer-readable storage media 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 memory), an EPROM (erasable programmable read memory), an EEPROM (electrically erasable programmable read memory), and flash memory.Furthermore, it can be expected that a person skilled in the art, regardless of possible considerable effort and a large selection of designs, which is justified, for example, by available time, current technology and economic considerations, guided by the concepts and principles disclosed herein, will be able to produce such software instructions, programs and ICs with minimal experimental effort.

[0051] The summary of the disclosure is provided to allow the reader to quickly grasp the nature of the technical disclosure. It is submitted with the understanding that it is not intended to interpret or limit the spirit or meaning of the claims. Furthermore, it is clear from the preceding detailed description that various features in different embodiments are grouped together to streamline the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly stated in each claim. Rather, as is evident from the following claims, an inventive subject matter is present in fewer than all the features of any single disclosed embodiment.Thus, the following claims are integrated into the detailed description, with each claim standing alone as a separately claimed subject matter.

Claims

[1] A method for uploading data destined for a central repository, wherein the data is uploaded to an intermediary uploading device before being uploaded to the central repository, the method comprising the following step: - Determining mobile / intermediary uploading devices on site; the procedure being characterized by the following steps: - Determining the probability that the mobile / intermediary upload devices will return to a connected upload point; - Identifying those mobile / intermediary upload devices with a higher probability of returning to the connected upload point; and - Uploading the data to those mobile / intermediary upload devices with the higher probability of returning to the connected upload point. [2] Method according to claim 1, wherein the mobile / intermediary uploading device is not connected to the central storage when uploading the data. [3] Method according to claim 1, wherein the mobile / intermediary upload devices serve as mobile digital video recorders (mDVRs) in vehicles. [4] Method according to claim 1, wherein the data comprise digital multimedia evidence (DME). [5] Method according to claim 1, wherein the step of determining the probability of the mobile mediating upload devices returning to the connected upload point comprises the following steps: - Receiving a calendar from any potential mobile intermediary uploading device; and - Analyzing the calendar or calendars to determine the probability. [6] Method according to claim 1, wherein the step of determining the probability that the mobile mediating upload devices return to the connected upload point comprises the following step: Determining a priority transmitted by each mobile mediating upload device. [7] Method for uploading data intended for a central storage location, wherein the data is uploaded to a mobile / intermediary uploading device before being uploaded to the central storage location, the method comprising the following steps: - Determining one or more mobile / intermediary upload devices on site, wherein the one or more mobile / intermediary upload devices on site are not connected to the central storage facility; and - Uploading the data to at least one of the one or more mobile intermediary uploading devices on site; wherein the method is characterized by the following steps: - Determining which mobile / intermediary upload devices have a higher priority; and - where the upload step includes uploading the data to the one or more devices with the higher priority. [8] Method according to claim 7, wherein the priority is based on a probability that a mobile / intermediary uploading device will return to an uploading point within a given time period. [9] Method according to claim 7, wherein the priority is based on an available storage disk space. [10] Method according to claim 7, wherein the priority is based on a time period in which the one or more mobile / intermediary upload devices will remain at the location. [11] Method according to claim 7, wherein the priority is based on a time at which the one or more mobile / intermediary upload devices will leave the site. [12] Method according to claim 7, wherein the priority is based on a time at which the one or more mobile / intermediary devices will return to an upload point of the central storage. [13] Method according to claim 7, wherein the priority is based on a time during which the mobile / intermediary device will remain at the central storage location. [14] Method according to claim 7, wherein the priority is based on a transmission speed of the mediating / mobile device, such that connections with a higher transmission speed are preferred. [15] Method according to claim 7, wherein the priority is based on an available transferable capacity of one or more mediating / mobile devices, such that devices with a higher storage capacity are preferred. [16] Method according to claim 7, wherein the priority is based on an estimated queue of one or more mediating / mobile devices during uploading to the central storage. [17] Method according to claim 7, wherein the priority is based on a department, so that a transfer within the department is preferred. [18] Method according to claim 7, wherein the priority is based on a relative priority value provided in advance by an administrator, which is transmitted wirelessly from each mediating / mobile device. [19] Device for uploading data intended for a central storage location, wherein the data is uploaded to a mobile / intermediary uploading device before being uploaded to the central storage location, the device comprising: - a processor that detects one or more mobile / intermediary upload devices located on-site, wherein the one or more mobile / intermediary upload devices are not connected to the central repository; and - a transmitter that uploads the data to at least one of the one or more mobile / intermediary upload devices on site; characterized by , that those mobile / intermediary upload devices are determined that have a higher priority; and - that the data is uploaded to the one or more devices with the higher priority.

Images