U.S. patent application number 15/411192 was filed with the patent office on 2017-07-27 for compressed binary patching over wireless network.
This patent application is currently assigned to Rigado, LLC. The applicant listed for this patent is Rigado, LLC. Invention is credited to David Nichols, Justin Rigling, Eric Stutzenberger.
Application Number | 20170212750 15/411192 |
Document ID | / |
Family ID | 57966154 |
Filed Date | 2017-07-27 |
United States Patent
Application |
20170212750 |
Kind Code |
A1 |
Stutzenberger; Eric ; et
al. |
July 27, 2017 |
COMPRESSED BINARY PATCHING OVER WIRELESS NETWORK
Abstract
A method of modifying a binary image on a device includes
receiving data of at least a portion of a binary patch file over a
network, the binary patch file being representative of a difference
between a first binary image stored on the device and a second
binary image. The method further includes decompressing at least a
portion of the data of the portion of the binary patch file to
obtain decompressed data, modifying at least a portion of the first
binary image stored on the device based at least in part on the
decompressed data, and transmitting a request to receive data of a
further portion of the binary patch file.
Inventors: |
Stutzenberger; Eric; (Salem,
OR) ; Rigling; Justin; (Salem, OR) ; Nichols;
David; (Salem, OR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Rigado, LLC |
Salem |
OR |
US |
|
|
Assignee: |
Rigado, LLC
Salem
OR
|
Family ID: |
57966154 |
Appl. No.: |
15/411192 |
Filed: |
January 20, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62286005 |
Jan 22, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
F04B 43/1261 20130101;
B05B 7/0416 20130101; F04B 17/06 20130101; B05B 9/042 20130101;
F04B 43/1253 20130101; G06F 8/654 20180201; H04L 69/04 20130101;
F04B 17/03 20130101; F04B 43/0072 20130101; B05B 7/2489 20130101;
G06F 8/656 20180201; B05B 7/0093 20130101; H04L 67/34 20130101 |
International
Class: |
G06F 9/445 20060101
G06F009/445; H04L 29/08 20060101 H04L029/08; H04L 29/06 20060101
H04L029/06 |
Claims
1. A method of modifying a binary image on a device, comprising:
over a network, receiving data of at least a portion of a binary
patch file, the binary patch file being representative of a
difference between a first binary image stored on the device and a
second binary image; decompressing at least a portion of the data
of the portion of the binary patch file to obtain decompressed
data; modifying at least a portion of the first binary image stored
on the device based at least in part on the decompressed data; and
transmitting a request to receive data of a further portion of the
binary patch file.
2. The method of claim 1, wherein the modifying further comprises:
copying the portion of the first binary image to volatile memory;
and storing a modified portion of the first binary image in
non-volatile memory when a constraint on the volatile memory is
met.
3. The method of claim 2, further comprising storing the modified
portion of the first binary image in the non-volatile memory when
the volatile memory is full.
4. The method of claim 2, further comprising storing the modified
portion of the first binary image in the non-volatile memory when
the data of the portion of the binary patch file is fully
decompressed.
5. The method of claim 2, further comprising clearing the volatile
memory after the modified portion of the first binary image is
stored in the non-volatile memory.
6. The method of claim 1, further comprising decrypting the data of
the portion of the binary patch file.
7. The method of claim 1, wherein the network is a low-energy
wireless network.
8. The method of claim 1, further comprising repeating the
receiving, decompressing, modifying, and transmitting until the
entirety of the binary patch file has been received and the first
binary image has been modified based on the binary patch file.
9. The method of claim 8, further comprising performing a cyclic
redundancy check on the first binary image as modified by the
binary patch file.
10. The method of claim 1, wherein the first binary image is a
firmware image, and the binary patch file is a firmware update.
11. One or more non-transitory computer-readable storage media
storing computer-executable instructions for causing a computer to
perform a method of modifying a binary image on a device, the
method comprising: over a network, receiving data of at least a
portion of a binary patch file, the binary patch file being
representative of a difference between a first binary image stored
on the device and a second binary image; decompressing at least a
portion of the data of the portion of the binary patch file to
obtain decompressed data; modifying at least a portion of the first
binary image stored on the device based at least in part on the
decompressed data; and transmitting a request to receive data of a
further portion of the binary patch file.
12. The computer-readable storage media of claim 11, wherein the
modifying further comprises: copying the portion of the first
binary image to volatile memory; and storing a modified portion of
the first binary image in non-volatile memory when a constraint on
the volatile memory is met.
13. The computer-readable storage media of claim 12, wherein the
method further comprises storing the modified portion of the first
binary image in the non-volatile memory when the volatile memory is
full.
14. The computer-readable storage media of claim 12, wherein the
method further comprises storing the modified portion of the first
binary image in the non-volatile memory when the data of the
portion of the binary patch file is fully decompressed.
15. The computer-readable storage media of claim 12, wherein the
method further comprises clearing the volatile memory after the
modified portion of the first binary image is stored in the
non-volatile memory.
16. The computer-readable storage media of claim 11, wherein the
method further comprises repeating the receiving, decompressing,
modifying, and transmitting until the entirety of the binary patch
file has been received and the first binary image has been modified
based on the binary patch file.
17. The computer-readable storage media of claim 16, wherein the
method further comprises performing a cyclic redundancy check on
the first binary image as modified by the binary patch file.
18. A system, comprising: a transceiver; non-volatile storage
memory including a first binary image stored thereon; and a
controller in electrical communication with the transceiver and
with the non-volatile storage memory, the controller being operable
to: in volatile memory, store data of at least a portion of a
binary patch file received by the transceiver, the binary patch
file being representative of a difference between the first binary
image stored in the non-volatile memory and a second binary image;
decompress at least a portion of the data of the portion of the
binary patch file to obtain decompressed data; modify at least a
portion of the first binary image based at least in part on the
decompressed data; and transmit control signals to cause the
transceiver to transmit a request to receive data of a further
portion of the binary patch file.
19. The system of claim 18, wherein the controller is further
operable to: copy the portion of the first binary image to be
modified to the volatile memory; and store a modified portion of
the first binary image in the non-volatile memory when the volatile
memory is full.
20. The system of claim 18, wherein the controller is further
operable to repeat the storing, decompressing, modifying, and
transmitting until the entirety of the binary patch file has been
received and the first binary image has been modified based on the
binary patch file.
Description
CROSS REFERENCE TO RELATED APPLICATION
[0001] This application claims the benefit of and priority to U.S.
Provisional Patent Application No. 62/286,005, filed Jan. 22, 2016,
which is incorporated herein by reference in its entirety.
FIELD
[0002] The present application concerns systems and methods of
performing software and firmware updates on devices over a
bandwidth-constrained network.
BACKGROUND
[0003] It can be beneficial to perform updates to software or
firmware instructions operating on devices connected to a radio
frequency network to, for example, provide new features or fix
bugs. However, bandwidth constraints on a network, such as a
low-energy wireless network, and/or hardware constraints on a
device, such as limited available memory, can complicate
transmission and application of updates. Such constraints can
result in a relatively long period of time required to transmit and
apply an update to existing binary on the device, during which
period the device may be inoperable. Additionally, such long update
periods can result in increased energy usage by the device. This
can unnecessarily limit the life of, for example, devices without
rechargeable or replaceable batteries, or devices, such as remote
sensing devices, that cannot be easily retrieved for recharging or
battery replacement. Accordingly, improvements to systems and
methods of performing software and/or firmware updates are
desirable.
SUMMARY
[0004] Certain embodiments of the disclosure are directed to
systems and methods of performing software and/or firmware updates
to a binary image on a device over a wireless network. In a
representative embodiment, a method of modifying a binary image on
a device comprises receiving data of at least a portion of a binary
patch file over a network, the binary patch file being
representative of a difference between a first binary image stored
on the device and a second binary image. The method further
comprises decompressing at least a portion of the data of the
portion of the binary patch file to obtain decompressed data,
modifying at least a portion of the first binary image stored on
the device based at least in part on the decompressed data, and
transmitting a request to receive data of a further portion of the
binary patch file.
[0005] Another representative embodiment includes one or more
non-transitory computer-readable storage media storing
computer-executable instructions for causing a computer to perform
a method, the method comprising receiving data of at least a
portion of a binary patch file over a network, the binary patch
file being representative of a difference between a first binary
image stored on the device and a second binary image. The method
further comprises decompressing at least a portion of the data of
the portion of the binary patch file to obtain decompressed data,
modifying at least a portion of the first binary image stored on
the device based at least in part on the decompressed data, and
transmitting a request to receive data of a further portion of the
binary patch file.
[0006] In another representative embodiment, a system comprises a
transceiver, non-volatile storage memory including a first binary
image stored thereon, and a controller in electrical communication
with the transceiver and with the non-volatile storage memory. The
controller is operable to store data of at least a portion of a
binary patch file received by the transceiver in volatile memory,
the binary patch file being representative of a difference between
the first binary image stored on the non-volatile memory and a
second binary image. The controller is further operable to
decompress at least a portion of the data of the portion of the
binary patch file to obtain decompressed data, modify at least a
portion of the first binary image based at least in part on the
decompressed data, and transmit control signals to cause the
transceiver to transmit a request to receive data of a further
portion of the binary patch file.
[0007] The foregoing and other objects, features, and advantages of
the disclosed technology will become more apparent from the
following detailed description, which proceeds with reference to
the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 is a schematic illustration of a representative
embodiment of a system including a remote device in communication
with a host computer system over a network.
[0009] FIG. 2 is a schematic illustration of a representative
embodiment of a remote device.
[0010] FIG. 3 is a process flow diagram illustrating a
representative method of modifying a binary image on a device.
[0011] FIG. 4 is a process flow diagram illustrating another
representative method of modifying a binary image on a device.
[0012] FIG. 5 is a schematic block diagram of a representative
computing environment.
DETAILED DESCRIPTION
[0013] FIG. 1 illustrates a representative system including a host
computer system 102 in communication with a remote device 104 over
a wireless network 106. The host computer system 102 can include a
binary image database 108 having a binary image 136 stored thereon,
a binary patch creation tool 110, a compression tool 112, an
encryption tool 114, and a binary patch file division tool 115. In
the illustrated embodiment, the remote device 104 can include a
computing device such as a microcontroller 116, and a power source,
such as a battery 150. In the illustrated embodiment, the
microcontroller 116 can be in communication with one or more
sensors located on the remote device such as sensors 118A-118C, and
can process signals received from the sensors to, for example,
control operation of a system in which the remote device is
incorporated, and/or transmit data of the sensor signals to an
end-use or terminal device (e.g., a smartphone, tablet computer,
laptop, etc.) for display to a user. For example, in some
embodiments the microcontroller 116, along with a variety of other
components such as the sensors 118A-118C and/or a transceiver 120,
can be arranged on a printed circuit board (PCB) or configured as a
system on a chip (SOC) for use with the remote device 104.
[0014] With reference to FIG. 2, the microcontroller 116 can
include a decryption tool 122, a decompression tool 124, and a
binary patching tool 126. The microcontroller 116 can also include
a volatile memory 128, and can be in communication with a
non-volatile memory 130 (FIG. 1). The non-volatile memory 130 can
include a binary image 132 comprising machine-readable instructions
(e.g., firmware or software) for operating any of various
components located on the remote device 104 (e.g., the sensors
118A-118C).
[0015] Returning to FIG. 1, the remote device 104 can also include
a transceiver module 120 to allow transmission and receipt of data
between the host system 102 and the remote device over the wireless
network 106. In some embodiments, the wireless network 106 can be a
relatively low-power wireless network, such as a local or personal
area network (e.g., Bluetooth.RTM. Low Energy, Bluetooth.RTM.
Smart, Thread, etc.), a low-power wide area network such as
LoRa.TM., any of various networks operating according to the IEEE
802.15.4 standard for low-rate wireless networks, or any other
suitable wireless network protocol. The foregoing wireless networks
and other equivalent networks are termed herein "low-energy" or
"low-power" wireless networks. Such low-power wireless networks are
often designed for relatively low data transmission rates over
relatively short distances, which can promote increased battery
life for devices such as the remote device 104. However, although
the following discussion proceeds with reference to relatively
low-energy wireless networks, it should be understood that the
systems and techniques described herein are not limited to such
networks, but are applicable to devices operating over any suitable
wireless network, regardless of power level or data bandwidth.
[0016] In certain examples, it can be desirable to update the
binary image 132 operating on the remote device to, for example,
fix bugs, add additional features or capabilities, or otherwise
improve functionality of the remote device and/or its component
systems. A representative method of updating a binary image is
given below with reference to FIGS. 1 and 2, and the process flow
diagram illustrated in FIG. 3.
[0017] Referring to FIG. 1, the binary patch creation tool 110 can
compare the binary image 136 (a "first" binary image) with a second
binary image 138, which can include changes or updates to the first
binary image 136 (e.g., a firmware update). In certain examples,
the first binary image 136 can be substantially the same as the
binary image 132 stored on the remote device 104. The binary patch
creation tool 110 can identify differences between the first and
second binary images 136, 138, and output a binary patch file 134
containing information of the differences between the first and
second binary images (e.g., a firmware patch file). In some
embodiments, the binary patch creation tool 110 can also perform a
cyclic redundancy check ("CRC") (e.g., 32-bit CRC) on the first
binary image 136 and the second binary image 138 to validate that
the first binary image 136 is stored in the non-volatile memory 130
on the remote device 104 (e.g., as the binary image 132) prior to
applying the binary patch 134, and that the binary image 132 as
modified by the binary patch 134 matches the second binary image
138. In other words, the CRC process can validate whether the
binary stored in the non-volatile memory 130 after application of
the binary patch 134 to the binary image 132 matches the second
binary image 138.
[0018] The binary patch 134 can be provided to the compression tool
112, which can compress the binary patch file to a suitable size
for transmission to the remote device. The compressed binary patch
file 134 can then be provided to the encryption tool 114, which can
encrypt the compressed binary patch file before transmission of the
file to the remote device 104 over the wireless network. In some
embodiments, the encryption step can be optional, as desired. The
binary patch file 134 can then be provided to the division tool
115.
[0019] Transmission of the binary patch file 134 to the remote
device 104 can proceed in a piecemeal fashion in which a portion of
the binary patch file (e.g., as determined by the division tool
115) is transmitted to the remote device, applied to the binary
image on the remote device and, upon occurrence of a condition
(e.g., full utilization of a specified memory), the remote device
can request another portion of the binary patch file. An exemplary
process flow diagram is presented in FIG. 3 illustrating the method
by which the existing binary (e.g., binary image 132) on the remote
device can be modified according to the binary patch file 134.
[0020] With reference to FIG. 3, after the binary patch file 134
has been compressed and (optionally) encrypted, the host system 102
can transmit initialization data 140 (FIG. 1) to the remote device
104 at block 202 instructing the remote device to prepare to
receive the binary patch file 134. Upon receipt of the
initialization data 140, the binary patching tool 126 can perform a
CRC on the binary image 132. In some embodiments, the remote device
104 can transmit a request to the host system 102 requesting the
first portion of data of the binary patch file (e.g., pending
successful conclusion of the CRC of the binary image 132).
Alternatively, transmission of the initial data file can proceed
with or without prompting from the remote device.
[0021] Meanwhile, the division tool 115 of the host system can
determine a portion 142 (e.g., 20 bytes, 200 bytes, etc.) of the
binary patch file 134 to be transmitted to the remote device 104.
The host system 102 can then transmit the portion 142 of the binary
patch file 134, which can be received by the remote device 104 at
block 204. In some embodiments, the division tool 115 (or another
component of the host system) can specify an order in which
portions of the binary patch file 134 should be transmitted to the
remote device. This can allow information such as control data to
be provided to the binary patching tool 126 in a specified order.
However, in other embodiments, portions of the binary patch file
134 can be transmitted in any order, such as in a random order.
[0022] At block 206, if the received portion 142 of the binary
patch file is encrypted, the data can be decrypted by the
decryption tool 122 at block 208. Next, at block 210, the portion
142 can be at least partially decompressed by the decompression
tool 124 and provided to the binary patching tool 126.
[0023] Meanwhile, a portion 144 of the binary image 132
corresponding to the portion 142 of the binary patch file 134 can
be copied to the volatile memory 128, or a portion of the volatile
memory designated as buffer memory. At block 212, the binary
patching tool 126 can apply the decompressed data of the portion
142 of the binary patch file to the portion 144 of the binary image
132 contained in the volatile memory 128. At block 214, if the
volatile memory 128 (e.g., the non-volatile storage buffer of block
214) is not yet fully utilized, decompression of the portion 142 is
not yet complete (block 218), and more data is available by further
decompressing the portion 142 (block 220), then the process returns
to block 210. This can continue until the volatile memory 128 is
full, or the portion 142 of the binary patch file is fully
decompressed, and the portion 144 of the binary image 132 in the
volatile memory has been modified to a selected extent (e.g., as
far as possible) with the decompressed binary. If either of these
conditions are true, the modified portion 144 of the binary image
132 can be written to the non-volatile memory 130, and the volatile
memory 128 can be cleared.
[0024] When the portion 142 has been fully decompressed and/or the
portion 144 of the binary image 132 has been modified to a selected
extent based on the decompressed data of the portion 142, the
remote device can transmit a request 146 to the host system at
block 222 for another portion of the binary patch file 134. The
host system can transmit another portion of the binary patch file
134 to the remote device, and the process can continue as above
until the entirety of the binary patch file has been transmitted to
the remote device and applied to the binary image 132. At this
point, application of the patch 134 to the binary image 132 can be
verified at block 224 by, for example, performing a CRC on the
binary image 132 as modified by the binary patch file. If this CRC
matches the CRC performed on the second binary image 138, then the
patching process is concluded.
[0025] The binary patching processes and systems described herein
can offer significant advantages over known patching techniques,
particularly with respect to memory and/or power-constrained
devices operating over low-power networks where data rates are
relatively low. For example, for an exemplary remote device having
1024 bytes of RAM available for patching processes and running a
firmware image requiring about 26 KB of memory, a 2 KB patch file
can be compressed to about 292 bytes, and transferred to the remote
device in portions of about 20 bytes in the manner described above,
allowing the update process to be completed in about 1.8 seconds.
By contrast, in a typical patching technique in which the entirety
of the new firmware image is transmitted to a device, transfer of
the 26 KB firmware image can require about one minute or longer.
Because transfer time correlates strongly with power usage by the
remote device, performing a binary update according to the
techniques described herein requires only about 7% of the power
required to transfer the full firmware image.
[0026] Although only a single remote device is illustrated in FIG.
1, it should be understood that the host system 102 can be in
communication with a plurality of devices such as device 104, and
can perform the methods described herein with such devices
separately or concurrently. It should also be understood that the
systems and methods described herein can be useful for transmitting
any kind of software or firmware program or program update to a
device. Further, in practice, the systems shown herein, such as the
system 102, can vary in complexity, with different functionality,
components of differing complexity, and the like. Although a single
instance is shown, a large number of instances, some sharing data,
databases, configuration information, and the like, can be
supported. Also, the system 102 can comprise a variety of other
functionality not shown to address synchronization, security, load
balancing, multi-tenancy, redundancy, and the like.
[0027] Although various components of the systems herein are shown
as a single component, in practice, the boundaries between
components can be changed. For example, the functionality of any of
the software tools described herein may be combined or subsumed
with any of the other tools or functionalities described.
Additionally, functionality can be implemented across one or more
machines, virtual or physical.
[0028] The system 102, any of the other systems described herein,
and subsets of such systems can be implemented in conjunction with
any of the hardware components described herein, such as the
described computing systems (e.g., processing units, memory, and
the like). In any of the examples herein, the inputs, outputs,
binary images, databases, and the like can be stored in one or more
computer-readable storage media or computer-readable storage
devices. The technologies described herein can be generic to the
specifics of operating systems or hardware and can be applied in
any variety of environments to take advantage of the described
features.
[0029] FIG. 4 is a process flow diagram illustrating another
representative method of modifying or updating a binary image on a
device. At block 302, data of at least a portion of a binary patch
file can be received over a network. The binary patch file can be
representative of a difference between a first binary image stored
on the device and a second binary image.
[0030] At block 304, at least a portion of the data of the portion
of the binary patch file can be decompressed to obtain decompressed
data.
[0031] At block 306, at least a portion of the first binary image
stored on the device can be modified based at least in part on the
decompressed data.
[0032] At block 308, a request to receive data of a further portion
of the binary patch file can be transmitted.
Representative Computing Environment
[0033] FIG. 5 depicts a generalized example of a suitable computing
environment 400 in which software and control algorithms for the
described innovations may be implemented. For example, the host
system 102 and/or the remote device 104 may include, or may be
implemented on, one or more of the features described with respect
to FIG. 5. The computing environment 400 is not intended to suggest
any limitation as to scope of use or functionality, as the
innovations may be implemented in diverse general-purpose or
special-purpose computing systems. For example, the computing
environment 400 can be any of a variety of computing devices (e.g.,
desktop computer, laptop computer, server computer, tablet
computer, gaming system, mobile device, programmable automation
controller, etc.).
[0034] With reference to FIG. 5, the computing environment 400
includes one or more processing units 410, 415 and memory 420, 425
(e.g., for storing data indicative of stage vibration). In FIG. 5,
this basic configuration 430 is included within a dashed line. The
processing units 410, 415 execute computer-executable instructions.
A processing unit can be a general-purpose central processing unit
(CPU), a processor in an application-specific integrated circuit
(ASIC) or any other type of processor. In a multi-processing
system, multiple processing units execute computer-executable
instructions to increase processing power. For example, FIG. 5
shows a central processing unit 410 as well as a graphics
processing unit or co-processing unit 415. The tangible memory 420,
425 may be volatile memory (e.g., registers, cache, RAM),
non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or
some combination of the two, accessible by the processing unit(s).
The memory 420, 425 stores software 480 implementing one or more
innovations described herein, in the form of computer-executable
instructions suitable for execution by the processing unit(s).
[0035] A computing system may have additional features. For
example, in some embodiments, the computing environment 400
includes storage 440, one or more input devices 450, one or more
output devices 460, and one or more communication connections 470.
An interconnection mechanism (not shown) such as a bus, controller,
or network, interconnects the components of the computing
environment 400. Typically, operating system software (not shown)
provides an operating environment for other software executing in
the computing environment 400, and coordinates activities of the
components of the computing environment 400.
[0036] The tangible storage 440 may be removable or non-removable,
and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs,
DVDs, or any other medium that can be used to store information in
a non-transitory way and can be accessed within the computing
environment 400. The storage 440 stores instructions for the
software 480 implementing one or more innovations described herein
(e.g., a binary patch file).
[0037] The input device(s) 450 may be, for example: a touch input
device, such as a keyboard, mouse, pen, or trackball; a voice input
device; a scanning device; any of various sensors; another device
that provides input to the computing environment 400; or
combinations thereof. For video encoding, the input device(s) 450
may be a camera, video card, TV tuner card, or similar device that
accepts video input in analog or digital form, or a CD-ROM or CD-RW
that reads video samples into the computing environment 400. The
output device(s) 460 may be a display, printer, speaker, CD-writer,
or another device that provides output from the computing
environment 400.
[0038] The communication connection(s) 470 enable communication
over a communication medium to another computing entity. The
communication medium conveys information, such as
computer-executable instructions, audio or video input or output,
or other data in a modulated data signal. A modulated data signal
is a signal that has one or more of its characteristics set or
changed in such a manner as to encode information in the signal. By
way of example, and not limitation, communication media can use an
electrical, optical, RF, or other carrier.
[0039] Any of the disclosed methods can be implemented as
computer-executable instructions stored on one or more
computer-readable storage media (e.g., one or more optical media
discs, volatile memory components (such as DRAM or SRAM), or
nonvolatile memory components (such as flash memory or hard
drives)) and executed on a computer (e.g., any commercially
available computer, including smart phones, other mobile devices
that include computing hardware, or programmable automation
controllers). The term computer-readable storage media does not
include communication connections, such as signals and carrier
waves. Any of the computer-executable instructions for implementing
the disclosed techniques as well as any data created and used
during implementation of the disclosed embodiments can be stored on
one or more computer-readable storage media. The
computer-executable instructions can be part of, for example, a
dedicated software application or a software application that is
accessed or downloaded via a web browser or other software
application (such as a remote computing application). Such software
can be executed, for example, on a single local computer (e.g., any
suitable commercially available computer) or in a network
environment (e.g., via the Internet, a wide-area network, a
local-area network, a client-server network (such as a cloud
computing network, or other such network) using one or more network
computers.
[0040] For clarity, only certain selected aspects of the
software-based implementations are described. Other details that
are well known in the art are omitted. For example, it should be
understood that the disclosed technology is not limited to any
specific computer language or program. For instance, the disclosed
technology can be implemented by software written in C, C++, Java,
Perl, JavaScript, Adobe Flash, or any other suitable programming
language. Likewise, the disclosed technology is not limited to any
particular computer or type of hardware. Certain details of
suitable computers and hardware are well known and need not be set
forth in detail in this disclosure.
[0041] It should also be well understood that any functionality
described herein can be performed, at least in part, by one or more
hardware logic components, instead of software. For example, and
without limitation, illustrative types of hardware logic components
that can be used include Field-programmable Gate Arrays (FPGAs),
Program-specific Integrated Circuits (ASICs), Program-specific
Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex
Programmable Logic Devices (CPLDs), etc.
[0042] Furthermore, any of the software-based embodiments
(comprising, for example, computer-executable instructions for
causing a computer to perform any of the disclosed methods) can be
uploaded, downloaded, or remotely accessed through a suitable
communication means. Such suitable communication means include, for
example, the Internet, the World Wide Web, an intranet, software
applications, cable (including fiber optic cable), magnetic
communications, electromagnetic communications (including RF,
microwave, and infrared communications), electronic communications,
or other such communication means.
General Considerations
[0043] For purposes of this description, certain aspects,
advantages, and novel features of the embodiments of this
disclosure are described herein. The disclosed methods, apparatus,
and systems should not be construed as being limiting in any way.
Instead, the present disclosure is directed toward all novel and
nonobvious features and aspects of the various disclosed
embodiments, alone and in various combinations and sub-combinations
with one another. The methods, apparatus, and systems are not
limited to any specific aspect or feature or combination thereof,
nor do the disclosed embodiments require that any one or more
specific advantages be present or problems be solved.
[0044] Although the operations of some of the disclosed embodiments
are described in a particular, sequential order for convenient
presentation, it should be understood that this manner of
description encompasses rearrangement, unless a particular ordering
is required by specific language set forth below. For example,
operations described sequentially may in some cases be rearranged
or performed concurrently. Moreover, for the sake of simplicity,
the attached figures may not show the various ways in which the
disclosed methods can be used in conjunction with other methods.
Additionally, the description sometimes uses terms like "provide"
or "achieve" to describe the disclosed methods. These terms are
high-level abstractions of the actual operations that are
performed. The actual operations that correspond to these terms may
vary depending on the particular implementation and are readily
discernible by one of ordinary skill in the art.
[0045] As used in this application and in the claims, the singular
forms "a," "an," and "the" include the plural forms unless the
context clearly dictates otherwise. Additionally, the term
"includes" means "comprises." Further, the terms "coupled" and
"associated" generally mean electrically, electromagnetically,
and/or physically (e.g., mechanically or chemically) coupled or
linked and does not exclude the presence of intermediate elements
between the coupled or associated items absent specific contrary
language.
[0046] In some examples, values, procedures, or apparatus may be
referred to as "lowest," "best," "minimum," or the like. It will be
appreciated that such descriptions are intended to indicate that a
selection among many alternatives can be made, and such selections
need not be better, smaller, or otherwise preferable to other
selections.
[0047] In view of the many possible embodiments to which the
principles of the disclosed technology may be applied, it should be
recognized that the illustrated embodiments are only preferred
examples and should not be taken as limiting the scope of the
disclosure. Rather, the scope of the disclosure is defined by the
following claims.
* * * * *