Systems and Methods for Distributing Updates to Devices

Abstract

Users may carry multiple electronic devices that can communicate between each other wirelessly. For example, law enforcement officers may carry several wirelessly connected electronic devices. However, some of these devices may have limited battery power, bandwidth, and/or ranges, restricting their ability to receive software updates. To compensate for these limitations, devices may be updated through associated intermediate devices. The intermediate devices may further provide a conduit for updating devices with restricted communications ability.

Description

FIELD OF THE INVENTION

Embodiments of the present invention relate to distributing software and/or firmware to devices.

BRIEF DESCRIPTION OF THE DRAWING

Embodiments of the present invention will be described with reference to the drawing, wherein like designations denote like elements, and:

FIG. 1 depicts a system that creates an environment (e.g., ecosystem) for devices to cooperate in distributing software and/or firmware updates according to various aspects of the present disclosure;

FIG. 2 is a functional block diagram of an implementation of the system of FIG. 1;

FIG. 3 is a diagram of a software data store for tracking devices types and software/firmware versions in the system of FIG. 2;

FIG. 4 is a diagram of a device data store for tracking software versions by device identifiers in the system of FIG. 2;

FIG. 5 is a diagram of an associations data store for tracking devices and intermediate devices in the system of FIG. 2;

FIG. 6 is a flow of a method performed by a server for direct updates of devices of the system of FIG. 2;

FIG. 7 is a flow chart of a method performed by a server for indirect updates of peripheral devices of the system of FIG. 2;

FIG. 8 is a flow chart of a method performed by an intermediate device for indirect updates of peripheral devices of the system of FIG. 2; and

FIGS. 9A and 9B are a flow chart of a method performed by an intermediate device for distributing version notices from a server to the devices of the system of FIG. 2.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Users may carry (e.g., wear, worn, attached to, or carried on, a user's body) multiple electronic devices (e.g., portable devices) that can communicate (e.g., transmit and/or receive information) between each other wirelessly. For example, law enforcement officers may carry several wirelessly connected electronic devices. The devices may also wirelessly communicate with electronic devices in police vehicles as well as between each other. The devices may exchange information with remote servers. Wireless or wired connectivity provides a pathway for the exchange of information and instructions.

One or more processing circuit of an electronic device, whether portable or in-vehicle, may execute software and/or firmware to perform one or more functions of the electronic device. The software and/or firmware executed and/or stored in a device can be updated from time to time. Hereinafter, the terms software and firmware are used interchangeably and refer to the instructions (e.g., programming, code, executable) executed by a processing circuit of an electronic device to perform the functions of the electronic device.

Systems and methods for distributing updates to devices are described in U.S. Provisional Application No. 62/350,904, filed Jun. 16, 2016, is hereby incorporated by reference in its entirety for all purposes.

Software may be identified by a version identifier (e.g., number, information). A version identifier may indicate the version (e.g., variant, development number, release number, software build or compilation number, sequence number, iteration) of the software. Version information may be in the form of a number. Version information may be a characteristic (e.g., trait) of the software. For example, version information may be based on a hash of the software. Portable and in-vehicle electronic devices may have one or more instances of software installed. Version information may be in the form of a Universally Unique Identifier (“UUID”) or Globally Unique Identifier (“GUID”).

Each instance of software may perform a function on a device. Each instance of software may include a version identifier (“VID”). For example, software that performs different functions may have different VIDs and may be updated separated from software that performs other functions.

Software updates may be stored on a server (e.g., record management system, evidence management system, remote data center, central repository, data center) and distributed from the server to the devices. The server may also be referred to as an update distribution system.

Devices may not connect to (e.g., communicate with) the server in a predictable manner (e.g., time, place, network bandwidth, throughput). Further, high-bandwidth wireless connections between devices, and between a device and a server, may consume large amounts of battery power. So, it is desirable to provide software updates to devices when high-bandwidth connections exist. For example, the rate of transmission may be proportional to the available power. When high-bandwidth connections do not exist, they may be established when possible for necessary software updates.

Some devices may not connect directly with a server. These devices may be referred to as peripheral devices. Such devices may have limited functionality, limited power, limited communications capability (e.g., data transfer speed, range), and/or other limitations. Peripheral devices may communicate with a server through an intermediate device. The intermediate device may establish a high bandwidth connection with a server, if one does not already exist, and request and/or receive updates for the peripheral device. The intermediate device may also buffer updates until a connection may be established or reestablished with a peripheral device. The intermediate device may also provide updates to a peripheral device in installments (e.g., in sections, segments, portions, packets). The intermediate device and the peripheral device may be paired to (e.g., associated with) each other.

Pairing, as used herein, is the establishment of a connection or association between two electronic devices. The connection may be secure (e.g., encrypted or protected communication between devices). Once paired, the association remains established until either device terminates the pairing. Associations may be terminated if a connection is lost (e.g., severed). Associations may be terminated according to a schedule (e.g., timetable). Unintentional communications are avoided by permitting only paired electronic devices to transmit and/or receive information for performing a function between each device.

An example of a system illustrating the interconnections between devices for distributing software updates is shown in FIG. 1. System 100 may include user 110, vehicle 120, network 130, server 140, and docking stations 150.

A user may carry electronic devices (e.g., smart phone, cellular phone, camera, digital video recorder (“DVR”), microphone, biometric or health monitor), that wirelessly communicate between the devices on the user or between the devices on other nearby (e.g., close, separated by a short distance, proximal) users.

A user may be a police officer (e.g., law enforcement official, detective, sheriff, deputy). A user may be a member of the armed forces (e.g., member of the military, soldier, military police, national guardsman). A user may be any person, or a mix of people (e.g., police officers, military personnel, civilian), carrying electronic devices with the ability to communicate wirelessly between the devices.

User 110 may communicate with server 140 through network 130. A server includes any computer system that performs services for users and/or other components. These services include conventional services such as information search, retrieval, indexing; file storage; database management; data entry; records management; distribution and tracking of software updates to components of any mix of one or more devices.

A network provides for the transmission and/or reception of information (e.g., data) via wireless and/or wired communication links. A network interface enables a system or an electronic device, as discussed below, to communicate with other devices and/or systems over a network. The functions of a network interface may be performed by circuits, logic embedded in hardware, software instructions executable by a processor, or any combination thereof. The functions performed by a network interface enable a computing device to communicate with another device. The functions performed by a network interface, whether using hardware or software executed by a processor, may be referred to as services. A device may request the services of a communication interface to communicate with an electronic device. A network may include one or more network technologies (e.g., internet, local area network (“LAN”), wide area network (“WAN”), metropolitan area network (“MAN”), cellular network).

A server, as used herein, includes any conventional hardware and software that implements a network node that communicates via a LAN and/or a WAN with electronic devices. A server may include capability to forward messages between networks. In an implementation, the server includes conventional computer systems of a data center for communicating with a relatively large number of electronic devices (e.g., 20 to 20,000).

Vehicle 120 may communicate with user 110. Vehicle 120 may communicate with server 140 through network 130. A vehicle may include electronic devices (e.g., mobile data terminal (“MDT”), camera, computer, radio, microphone, sensors, navigation system, weapons) that can communicate directly with electronic devices carried by a user. A vehicle's electronic devices may communicate with a user's electronic devices through an access point (e.g., signal unit, hub, data concentrator).

A vehicle may include any machine for transporting people (e.g., automobile, car, bus, truck, van). A vehicle may include machines for providing transportation for specific purposes (e.g., police car, squad car, cruiser, mobile patrol, armored vehicle). A vehicle may be controlled autonomously (e.g., without a driver). A vehicle may be controlled remotely (e.g., drone, unmanned aerial system).

Docking station 150 may communicate with server 140 through network 130.

A docking station includes any apparatus that manages consumable supplies for a portable device. When consumable supplies include battery power, the docking station may include battery charging capability adapted for one or more devices. When memory in a device used for recordings is limited (analogous to other consumable supplies), the docking station may include memory copying and communication capabilities adapted for one or more devices (e.g., store and forward capability). The docking station may copy recordings to its own storage and/or forward to a server. Copying recordings may free (e.g., release, empty, clear) memory space on the portable device.

A server may cooperate with one or more docking stations to manage efficient use of communication capabilities of a system. A server may cooperate with one or more docking stations to manage efficient use of information storage capabilities of the system.

System 200 of FIG. 2 is an example of an implementation of system 100. System 200 performs the functions of a software distribution system and/or system 100 discussed above and herein. System 200 may include network 130, docking station 150, recording devices 210 and 214, handheld device 218, MDT 222, holster 230, conducted electrical weapon (“CEW”) 234, microphone 238 and server 140. Server 140 may include software data store 240, device data store 244, association data store 248, update engine 252, association 256, communication circuit 260, and processing circuit 264.

Recording devices may collect and record information. For example, recording devices include DVRs that record audio and/or visual information. Recording devices may wirelessly communicate with nearby devices. Recording devices may capture and record information. For example, a camcorder may capture as well as record audio and/or video information. Recording devices may wirelessly communicate with a server through a network. Recording devices may communicate with a server through a wired connection to a network when placed in a docking station.

Recording devices may be portable. Recording devices may be carried by a user. Recording devices may be located in a vehicle.

Recording devices may include processing circuits. A processing circuit includes any circuitry and/or electrical/electronic subsystem for performing a function. A processing circuit may include circuitry that performs (e.g., executes) a stored program (e.g., software). A processing circuit may include a digital signal processor, a microcontroller, a microprocessor, an application specific integrated circuit, a programmable logic device, logic circuitry, state machines, MEMS devices, signal conditioning circuitry, communication circuitry, a conventional computer (e.g., server), a conventional radio, a network appliance, data busses, address busses, and/or a combination thereof in any quantity suitable for performing a function and/or executing one or more stored programs.

A processing circuit may further include conventional passive electronic devices (e.g., resistors, capacitors, inductors) and/or active electronic devices (op amps, comparators, analog-to-digital converters, digital-to-analog converters, current sources, programmable logic). A processing circuit may include conventional data buses, output ports, input ports, timers, memory, and arithmetic units.

A processing circuit may provide and/or receive electrical signals whether digital and/or analog in form. A processing circuit may provide and/or receive digital information (e.g., data) via a conventional bus using any conventional protocol. A processing circuit may receive information, manipulate the received information, and provide the manipulated information. A processing circuit may store information and retrieve stored information. Information received, stored, and/or manipulated by the processing circuit may be used to perform a function and/or to perform a stored program.

A processing circuit may communicate with and/or control the operation and/or function of other circuits and/or components of a system. A processing circuit may receive status information regarding the operation of other components, perform calculations with respect to status information, and provide commands (e.g., instructions) to one or more other components, for example, for the component to start operation, continue operation, alter operation, suspend operation, or cease operation. Commands and/or status may be communicated between a processing circuit and other circuits and/or components via any type of bus including any type of conventional data/address bus.

Recording devices may include a communication circuit. A communication circuit transmits and/or receives information. A communication circuit may transmit and/or receive (e.g., communicate) information via a wireless link and/or a wired connection. A communication circuit may communicate using wireless (e.g., radio, light, sound, vibrations) and/or wired (e.g., electrical, optical) mediums. A communication circuit may communicate using any conventional wireless (e.g., Bluetooth, Zigbee, WAP, WiFi, Near Field Communication, infrared, IrDA) and/or any conventional wired (e.g., USB, RS-232, Firewire, Ethernet) communication protocol. A communication circuit may receive information from a processing circuit for transmission. A communication circuit may provide received information to a processing circuit.

A communication circuit in one device (e.g., recording device) may communicate with a communication circuit in another device (e.g., CEW). Communications between two devices may permit the two devices to cooperate in performing a function of either device. Information transferred between devices may be encrypted (e.g., encoded, enciphered).

For example, recording devices 210 and 214 perform the functions of a recording device as discussed above. Recording device 210 or 214 may communicate with peripheral devices holster 230, CEW 234, and microphone 238.

A holster (e.g., belt, sheath, case, carrier) may hold (e.g., carry) a firearm (e.g., CEW, firearm, handgun, pistol). A holster may include detectors that detect the insertion, presence, and/or withdrawal of a firearm. A holster may include a processing circuit as discussed above. A holster may include a communication circuit as discussed above.

For example, holster 230 performs the function of a holster as discussed above. Holster 230 may wirelessly communicate with recording device 210 or 214.

A CEW is a device that provides a stimulus signal through a human or animal target. A stimulus signal inhibits locomotion of the target. Locomotion may be inhibited by interfering with voluntary use of skeletal muscles and/or causing pain in the target. A stimulus signal that interferes with skeletal muscles causes the skeletal muscles to lockup (e.g., freeze, tighten, stiffen) so that the target may not voluntarily move.

A CEW may include a handle and one or more replaceable deployment units (e.g., cartridges). A handle may include the circuitry for producing the stimulus signal. A handle may include terminals for providing the stimulus signal to a target by drive stun in which the terminals are brought proximate to target tissue to provide the current. A handle may include a processing circuit. A handle may include a communication circuit.

A deployment unit may be removably coupled to a handle to provide a remote stun. To provide a remote stun, the CEW launches wire-tethered electrodes from the deployment unit toward the target to be positioned the electrodes proximate to target tissue. The CEW provides the stimulus signal to the target via the wire-tethered electrodes. A deployment unit may be inserted into a bay of the handle for use to provide a remote stun. The used (e.g., fired) deployment unit may be removed from the bay and a new (e.g., unused) deployment unit inserted into the bay for use. A handle may include one or more bays for receiving respective deployment units.

For example, CEW 234 performs the function a CEW. CEW 234 may wirelessly communicate with recording device 210 or 214.

A microphone may be a transducer that coverts sound into an electrical signal. A microphone may include a processing circuit. A microphone may include a communication circuit. A microphone may be carried by a user. A microphone may be included in a vehicle.

For example, microphone 238 performs the function of a microphone as described above. Microphone 238 may communicate over a wireless link with recording device 210 or 214.

Peripheral devices holster 230, CEW 234, and microphone 238 may be limited to communications with nearby devices due to limited and/or available battery power. These peripheral devices may communicate with other devices intermittently (e.g., not continuously, at irregular intervals) to conserve battery power or due to limited functionality.

A handheld device may be a battery powered electronic or computing device that can be held in a user's hand (e.g., palm) or carried by a user that performs one or more functions. As such, a handheld device may be a portable device. A handheld device may also be referred to as a mobile device. A handheld device may include a user interface. A handheld device may include a processing circuit. A handheld device may include a communications circuit. Examples of handheld devices include smartphones, tablet computers, personal digital assistants,

For example, handheld device 218 performs the function of a handheld device as discussed above. Handheld device 218 may wirelessly communicated with recording device 210 or 214. Handheld device 218 may communicate with server 140 via network 130. Handheld device 218 may communicate with MDT 222.

Recording devices 210 and 214, handheld device 218, and MDT 222 may perform the functions of an intermediate device for distributing updates to peripheral devices.

An MDT (e.g., mobile digital computer, motor vehicle computer) may be a computerized device used in a public transit vehicles, service trucks, commercial trucking, and emergency vehicles (e.g., police cars, ambulances, fire truck). An MDT may be removably attached to a vehicle. An MDT may provide communications with a central dispatch office. An MDT may include a user interface. An MDT may have a processing circuit. An MDT may have a communication circuit. For example, a police officer may use an MDT to communicate with a dispatch system, including such tasks as acknowledging assignment of the officer to an incident, indicating that the officer is in route to the incident, identifying any delays in responding, and/or the like. An MDT may activate recording devices in the vehicle and also recording devices within a range of the vehicle.

For example, MDT 222 performs the function of an MDT as discussed above. MDT 222 may communicate with recording device 214. MDT 222 may communicate with handheld device 218. MDT may communicate with server 140 through network 130.

Server 140 may include engines and data stores which operate to store and align software update and device data. Server 140 further includes engines and data stores to store and determine software versions for device types (e.g., recording device, handheld device, holster, CEW, MDT, microphone, camera) and/or particular devices.

The term “engine” as used herein refers to, in general, circuitry, logic embodied in hardware and/or software instructions executable by a processor of a computing device. Circuitry includes any circuit and/or electrical/electronic subsystem for performing a function. Logic embedded in hardware includes any circuitry that performs a predetermined operation or predetermined sequence of operations. Examples of logic embedded in hardware include standard logic gates, application specific integrated circuits (“ASICs”), field-programmable gate arrays (“FPGAs”), microcell arrays, programmable logic arrays (“PLAs”), programmable array logic (“PALs”), complex programmable logic devices (“CPLDs”), erasable programmable logic devices (“EPLDs”), and programmable logic controllers (“PLCs”). Logic embodied in (e.g., implemented as) software instructions may be written in any programming language, including but not limited to C, C++, COBOL, JAVA™, PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, HDL, and/or Microsoft .NET™ programming languages such as C#. The software for an engine may be compiled into an executable program or written in an interpreted programming language for execution by a suitable interpreter or virtual machine executed by a processing circuit. Engines may be callable (e.g., executable, controllable) from other engines or from themselves.

An engine described herein may be merged with other engines, other applications, or may be divided into sub-engines. Engines that are implemented as logic embedded in software may be stored in any type of computer-readable medium. An engine may be stored on and executed by one or more general purpose computers, thus creating a special purpose computer configured to perform the functions of (e.g., provide) the engine.

The devices and systems illustrated herein may include one or more processing circuit configured to perform the functions of the illustrated engines, though the processing circuits themselves have not been illustrated in every case for the sake of clarity.

An update engine may identify devices lacking the current or correct software versions. An update engine may broadcast notices of software updates to devices. An update engine may determine if a device type has current software versions. An update engine may determine if a particular device has current versions of software. An update engine may distribute software updates to devices. An update engine may distribute software updates to a peripheral device through an intermediate device. For example, update engine 252 may perform the functions of an update engine.

An association engine identifies peripheral devices paired with intermediate devices. An association engine may record a pairing when reported by an intermediate device. An association engine may record a pairing when reported by a peripheral device. An association engine may remove an association when a pairing no longer exists. An association engine may poll devices to determine pairings. An association engine may record and/or remove pairings based on a schedule (e.g., timetable). For example, association engine 256 may perform the functions of an association engine.

As understood by one of ordinary skill in the art, a “data store” as described herein may be any suitable device configured to store data for access by a computing device. A data store receives data. A data store retains (e.g., stores) data. A data store retrieves data. A data store provides data for use by a system, such as an engine. A data store may organize data for storage. A data store may organize data as a database for storage and/or retrieval. The operations of organizing data for storage in or retrieval from a database of a data store may be performed by a data store. A data store may include a repository for persistently storing and managing collections of data. A data store may store files that are not organized in a database. Data in a data store may be stored in a system.

An example of a data store which includes reliable storage but also low overhead, is a file system or database management system that stores data in files (or records) on a computer-readable medium such as flash memory, random access memory (RAM), or hard disk drives.

One example of a data store suitable for use in server 140 is a highly reliable relational database management system (“RDBMS”) executing on one or more computing devices and accessible over a network. However, any other suitable storage technique and/or device capable of quickly and reliably providing the stored data in response to queries may be used, such as a key-value store and an object database.

Data stores 240, 244, and 248 perform the functions of a data store discussed herein. A data store may be implemented using any computer-readable medium. An engine (e.g., 252 and 256) may access data stores 240-248 locally (e.g., via data bus), over a network, and/or as a cloud-based service.

One of ordinary skill in the art will recognize that separate data stores described herein may be combined into a single data store, and/or a single data store described herein may be separated into multiple data stores, without departing from the scope of the present disclosure.

A software data store stores software for devices. A software data stores a present version of software for each device type. A software data store may have one or more records (e.g., tables) that may include fields (e.g., part of a record containing the smallest accessible unit of information, cell) for device type, current software version for the device type, and current software (or a link or pointer to the current software). For example, software data store 240 may include records 310 and 312, as shown in FIG. 3. Record 310 may include fields device type 312; VID 314; and software 316. Similarly, record 320 may include fields device type 322; VID 324; and software 326.

A device data store is a repository for identifying the software version installed on each device. A device data store may have one or more records that may include fields for a unique device identifier (e.g., serial number), device type, and a current software version identifier (e.g., number) for the software install on the device. For devices with multiple instances of software, the instance may be included in the device identifier or device type fields. Additional fields may also be used to indicate multiple instances of software. Device identifier may also include information related to the assignment or owner of a device. For example, a device identifier may include information related to a law enforcement department, agency, jurisdiction or branch responsible for the device.

For example, device data store 244 may include records 400 and 420 as shown in FIG. 4. Records 400 and 420 may include fields device ID 412 and 422; device type 414 and 424; and current software version 416 and 426, respectively.

An association data store is a repository listing the pairing of intermediate devices with peripheral devices. An association data store may have one or more fields for an intermediate device identifier, and for each intermediate device, fields for paired device identifiers and types. For example, association data store 248 may include records 510 and 540. Record 510 may include intermediate device ID 512 field. For a first device paired with intermediate device ID 512, record 510 may include device ID 514 and device type 516. For a second device paired with intermediate ID 512, record 510 may further include device 518 and device type 520. Record 540 may include fields intermediate device ID 542, and for two paired device, device ID 544 and 548, and device type 546 and 550, respectively. Record 510 or 540 may include as many device ID and device type fields as needed to store all pairings. Association data store 248 may include a quantity of records to store all pairings.

Server 140 may include software data store 240, device data store 244, association data store 248, update engine 252, and association engine 256. Server 140 may also include communication circuit 260, and processing circuit 264. For example, communication circuit 260 may perform the function of a communication circuit as discussed above. Processing circuit 264 may perform the functions of a communications circuit as discussed above.

As discussed herein, updated software may be distributed by a server (e.g., pushed) to devices directly, or indirectly through intermediate devices. Update software may be requested (e.g., pulled) from a server by devices directly or indirectly through an intermediate device. An intermediate device may determine if a peripheral device has current software and provide updates, if needed. The availability of updated software may be provided (e.g., broadcast, multicast, notifications) by a server to devices. Software updates for devices may be distributed by group. For example, updates may be distributed to devices assigned to a particular police department or agency. Software updates may be distributed incrementally to devices (e.g., rolled out) by device type, device identifier, or other criteria.

Direct update method 600, shown in FIG. 6, is performed by server 140 in cooperation with any of the devices 210-238 to provide a software update to the device. Method 600 allows a device to pull current software from a server if the server determines that an instance of software on the device is not current. Method 600 includes receive message 610, device type 620, software current 630, access current 640, transmit 650, update 660, and end 670.

In receive message 610, server 140 receives a message from a device. The message may include a device type, device identifier, and a software version for each instance of software on the device. Execution then proceeds to device type 620.

In device type 620, server 140 determines the device data type and version of each instance of software installed on the device from the received message. Upon determining this information, execution proceeds to software current 630.

In software current 630, update engine 252 compares the device type and software version, extracted in device type 620, with the device type and VID recorded in software data store 240. If the version for the software instance agrees with that reported by the device, no update is need and execution proceeds to end 670. Otherwise, a software update is needed and execution proceeds to access current 640.

In access current 640, update engine 252 may retrieve the software update from software data store 240. Update engine 252 may retrieve the software update from a pointer in software data store 240. Once the software or pointer to the software has been acquired, execution proceeds to transmit 650.

In transmit 650, update engine 252, in cooperation with communication circuit 260 and processing 264, transmits the software update to the device. Execution proceeds to update 660.

In update 660, update engine 252 revises the current software VID for the device identifier and device type record in device data store 244. Execution proceeds to end 670.

As discussed above, peripheral devices may not be able to connect with a server through a network due to limited battery power and/or bandwidth. Peripheral devices may need to communicate through an intermediate device to receive software updates from a server. Indirect update method 700, shown in FIG. 7, performed by server 140 in cooperation with an intermediate device, provides software updates to peripheral devices through intermediate devices. Method 700 may include receive message 710, determine type 720, software current 730, access current 740, get associated 750, transmit 760, update 770, and end 780.

In receive message 710, server 140 receives a message from a peripheral device through an intermediate device. The message may include a device identifier, device type, and software VID of a software instance. The message may also include a device identifier and device type for the intermediate device. Execution proceeds to determine device 720.

In determine device 720, server 140 determines the type, identifier, and software version for the peripheral device. Server 140 also determines the type and identifier of the intermediate device. Execution proceeds to software current 730.

In software current 730, update engine 252 compares the peripheral device type and software version, extracted in determine device 720, with the device type and VID recorded in software data store 240. If the version for the software instance agrees with that reported by the device, no update is need and execution proceeds to update 770. Otherwise, a software update is needed and execution proceeds to access current 740.

In access current 740, update engine 252 may retrieve the software update or software pointer from software data store 240, as in access current 640. Once the software or pointer to the software has been acquired, execution proceeds to get associated 750.

In get associated 750, update engine 252 determines if any software or other instructions need to be sent to the intermediate device. For example, the intermediate device may need additional instructions to identify the peripheral device to receive the software update. The intermediate device may require software to retransmit the software update from the server to the peripheral device. The intermediate device may receive the software update on one type of communication link and retransmit it on another. Execution proceeds to transmit 760.

In transmit 760, update engine 252, in cooperation with communication circuit 260 and processing circuit 264, transmits software, identified in get associated 750, to the intermediate device. Update engine 252 also transmits the software update for the peripheral device to the intermediate device. Execution proceeds to update 770.

In update 770, update engine 252 revises the current software VID for the device identifier and device type record in device data store 244. Association engine 256 revises the record in association data store 256 listing the pairing between the intermediate device and peripheral device. Execution proceeds to end 670.

In intermediate update method 800, shown in FIG. 8, an intermediate device determines whether a software updated is needed by a paired peripheral device. If an update is needed, the intermediate device retrieves the update from the server. Method 800 may be performed by intermediate devices 210-222 in cooperation with server 140 and peripheral devices 230-238. Method 800 includes receive device ID 810, send info 820, receive 830, software current 840, get software 850, transmit 860, notice 870, update 880, and end 890.

In receive data 810, an intermediate device receives a message from a paired peripheral device. The message may include the peripheral device ID, device type, and versions of software instances. Execution proceeds to send info 820.

In send info 820, the intermediate device sends its device identifier and the peripheral device type from receive data 810 to server 140. Update engine 252 determines the current software for the peripheral device type and sends it to the intermediate device. Execution proceeds to receive 830.

In receive 830, the intermediate device receives the current software version from server 140 for the peripheral device type and software instance. Execution proceeds to software current 840.

In software current 840, the intermediate device compares the current software version received from server 140 with the software version in the message from the peripheral device. If the peripheral device software is current, execution proceeds to notice 870. Otherwise, execution proceeds to get software 850.

In get software 850, the intermediate device requests and receives the updated software for the peripheral device from server 140 over a high-bandwidth communication link. Execution proceeds to transmit 860.

In transmit 860, the intermediate device sends the software update to the peripheral device over a limited bandwidth communication link. Execution proceeds to notice 870.

In notice 870, the intermediate device determines if all software instances of each paired device have the current software. If not all software instances of each device have been updated, execution return to send info 820. Otherwise, execution proceeds to update 880.

In update 880, the intermediate device sends a message to update engine 252 providing revised software versions installed on devices. Update engines revises the records in device data store 244 to show the current version for each instance of software for particular devices. The intermediate device may also send a message to association engine 256. Association engine 256 revises the pairing between intermediate and peripheral device in association data store 248, if any. Execution then proceeds to end 890.

Devices may inquire about software updates on a periodic or scheduled basis (e.g., daily, weekly, monthly). Devices may inquire about software updates in response to an event (e.g., power on, establishing a pairing). Intermediate device may inquire about software updates for paired peripheral devices according to a schedule or in response to an event. A server may provide notification of the availability of updated software. A server may disseminate notices of software updates to particular devices or device types.

Server 140 may broadcast the availability of updated software to intermediate devices. Version notice method 900, shown in FIG. 9, performed by an intermediate device receives and updates software for itself and/or paired devices. Method 900 include receive version 910, software current 914, update required 918, receive device info 922, paired software current 926, paired update 930, notice 934, updates needed 938, connection 942, transmit 946, receive 950, transmit update 954, update 958, and end 962.

In receive version 910, the intermediate device receives a notice of the availability of updated software from server 140. The notice may be broadcasted to all devices or addressed to specific devices or device types. Execution proceeds to software current 914.

In software current 914, the intermediate device determines whether the updated software notice is for an instance of software installed on the intermediate device. If it is, the intermediate device compares the software version in the notice with that of the installed software. Execution proceeds to update required 918 if a software update is required. If no update is required, execution proceeds to receive device info 922.

In update required 918, the intermediate device determined that it requires a software update and sets an update flag accordingly. Execution proceeds to receive device info 922.

In receive device info 922, the intermediate device requests and receives the device ID, device type, and install software version from associated devices. Execution proceeds to paired software current 926.

In paired software current 926, the intermediate devices used the information received in receive device info 922 to determine if the software update notice impacts the software on associated devices. If the associated device requires a software update, execution proceeds to paired update 930. If a software update is not applicable, execution proceeds to notice 934.

In paired update 930, the intermediate device sets a flag to indicate that the associated device requires a software update. Execution proceeds to notice 934.

In notice 934, the intermediate device determines whether all associated devices have been queried for their device types and software versions. If all devices have been polled, execution proceeds to updates needed 938. If any associated device has not been polled, execution loops to receive device info 922.

In updates needed 938, the intermediate device determines when any flags were set in update required 918 or paired update 930. If no updates are necessary, execution proceeds to end 962. If updates are needed, execution proceeds to connection 942.

In connection 942, the intermediate device determines if a high-bandwidth connection exists between itself and server 140. Connection 942 loops back to itself until a high-bandwidth connection exists with server 140. Execution proceeds to transmit 946 when there is a high-bandwidth connection.

In transmit 946, the intermediate device requests the flagged software updates from update engine 252. Execution proceeds to receive 950.

In receive 950, the intermediate device waits until updated software is received from server 140. Upon receipt of the update, execution proceeds to transmit update 954.

In transmit update 954, the intermediate device installs the updated software. If an associated device requires the updated software, the intermediate device transmits the update software to the associated device. After the intermediate and/or associated devices are updated, execution proceeds to update 958.

In update 958, the intermediate device updates any resident data stores. The intermediate device provides update engine 252 with updated software versions installed on itself or associated devise. Update engine 252 revises the device data store with updated information. The intermediate device provides association engine 256 with current pairings. Association engine 256 revises association data store 248 with the updated information.

The foregoing description discusses preferred embodiments of the present invention, which may be changed or modified without departing from the scope of the present invention as defined in the claims. Examples listed in parentheses may be used in the alternative or in any practical combination. As used in the specification and claims, the words ‘comprising’, ‘comprises’, ‘including’, ‘includes’, ‘having’, and ‘has’ introduce an open-ended statement of component structures and/or functions. In the specification and claims, the words ‘a’ and ‘an’ are used as indefinite articles meaning ‘one or more’. While for the sake of clarity of description, several specific embodiments of the invention have been described, the scope of the invention is intended to be measured by the claims as set forth below. In the claims, the term “provided” is used to definitively identify an object that not a claimed element of the invention but an object that performs the function of a workpiece that cooperates with the claimed invention. For example, in the claim “an apparatus for aiming a provided barrel, the apparatus comprising: a housing, the barrel positioned in the housing”, the barrel is not a claimed element of the apparatus, but an object that cooperates with the “housing” of the “apparatus” by being positioned in the “housing”. The invention includes any practical combination of the structures and methods disclosed. While for the sake of clarity of description several specifics embodiments of the invention have been described, the scope of the invention is intended to be measured by the claims as set forth below.

The location indicators “herein”, “hereunder”, “above”, “below”, or other word that refer to a location, whether specific or general, in the specification shall be construed to refer to any location in the specification where the location is before or after the location indicator.

Claims

1. A method for distributing updates from an update distribution server to a device, the method comprising:

receiving, from the device, a message indicating a device type, a device identifier, and a software version;

determining if the software version is the current version for the device;

in response to the software version not being the current version, transmitting the current software version to the device from the server;

storing, on the server, the device identifier and the current software version on the device.

2. The method of claim 1 wherein the update distribution server includes an evidence management system.

3. The method of claim 1 wherein receiving comprising receiving communications over a network.

4. The method of claim 3 wherein the network includes the internet.

5. The method of claim 1 wherein transmitting comprising transmitting via a high-speed wireless communication link.

6. The method of claim 1 wherein transmitting comprises over a wired communication link from a docking station.

7. The method of claim 1 wherein the device includes one of a digital camera, a mobile data terminal, a holster, a conducted electrical weapon, a digital video recorder, and a signal unit.

8. A method for distributing updates from a server to a device via an intermediate device, the method comprising:

receiving, by the server, a message from the device via the intermediate device, indicating a device type, a device identifier, and a software version of the device;

in accordance with the device type and the software version, determining whether the software version of the device is a current software version;

in accordance with determining that the software version is not the current version, transmitting the current software version to the intermediate device;

transmitting, by the intermediate device, the current software from the intermediate device to the device;

confirming, by the intermediate device, to the server that the end device has installed the current software version; and

associating, on the server, the device identifier and the current software version.

9. The method of claim 8 wherein the device includes one of a digital camera, a mobile data terminal, a holster, a conducted electrical weapon, a digital video recorder, and a signal unit.

10. The method of claim 8 wherein the intermediate device includes one of a digital camera, a mobile data terminal, a digital video recorder, a docking station, and a signal unit.

11. The method of claim 8 wherein transmitting comprises transmitting via a high-speed, wireless communications link.

12. The method of claim 8 wherein associating includes updating a device data store.

13. The method of claim 8 wherein associating includes updating an association data store.

14. A method for updating an electronic device, the method comprising:

broadcasting, by a server, a notice, the notice including one or more device types and a respective current version of software for each device type;

receiving, by the electronic device, the notice;

determining, by the electronic device, whether the software version of the device is the same as the current version of the software for device according to the version notice;

transmitting, by the device, a request to the server, for the current version of software, the request including a device type and a device identifier;

transmitting, by the server, the current version of software to the device; and

storing, on the server, the device identifier and at least one of the current version of the software transmitted to the device and a version identifier of the current version of the software.

15. The method of claim 14 wherein broadcasting comprises transmitting the message to a plurality of devices without a one-to-one connection to any of the plurality of the devices.

16. The method of claim 14 wherein broadcasting comprises transmitting the message to a plurality of devices without receiving an acknowledgement of receipt from any one device.

17. The method of claim 14 wherein broadcasting comprises transmitting wirelessly using a wireless protocol.

18. The method of claim 14 wherein determining comprises comparing a date if issue of the software of the device to a date of issue of the current version of software for the device type.

19. The method of claim 14 wherein transmitting the current version comprises transmitting the current version of the software via an intermediate electronic device.

20. The method of claim 14 wherein storing comprises:

associating the device identifier to the version identifier of the current version of the software for the device; and

storing the device identifier, the version identifier, and the association in a data store.