U.S. patent application number 16/299848 was filed with the patent office on 2019-07-04 for tracking assets with a blockchain.
The applicant listed for this patent is International Business Machines Corporation. Invention is credited to Thomas T. Hanis, Bruce H. Hyre, Jessica G. Snyder.
Application Number | 20190205826 16/299848 |
Document ID | / |
Family ID | 62711804 |
Filed Date | 2019-07-04 |
![](/patent/app/20190205826/US20190205826A1-20190704-D00000.png)
![](/patent/app/20190205826/US20190205826A1-20190704-D00001.png)
![](/patent/app/20190205826/US20190205826A1-20190704-D00002.png)
![](/patent/app/20190205826/US20190205826A1-20190704-D00003.png)
![](/patent/app/20190205826/US20190205826A1-20190704-D00004.png)
![](/patent/app/20190205826/US20190205826A1-20190704-D00005.png)
United States Patent
Application |
20190205826 |
Kind Code |
A1 |
Hanis; Thomas T. ; et
al. |
July 4, 2019 |
TRACKING ASSETS WITH A BLOCKCHAIN
Abstract
A blockchain of transactions may be referenced for various
purposes and may be later accessed by interested parties for ledger
verification. One example method of operation may include reading a
tag affixed to an asset, transmitting a request to update an asset
status of the asset in a blockchain, receiving validation
confirmation based on content of the request, and updating the
asset status of the asset in the blockchain.
Inventors: |
Hanis; Thomas T.; (Raleigh,
NC) ; Hyre; Bruce H.; (Cary, NC) ; Snyder;
Jessica G.; (Raleigh, NC) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
International Business Machines Corporation |
Armonk |
NY |
US |
|
|
Family ID: |
62711804 |
Appl. No.: |
16/299848 |
Filed: |
March 12, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15399267 |
Jan 5, 2017 |
10275739 |
|
|
16299848 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 10/087 20130101;
G06Q 30/0185 20130101 |
International
Class: |
G06Q 10/08 20060101
G06Q010/08; G06Q 30/00 20060101 G06Q030/00 |
Claims
1. A method, comprising: reading, via a reader in communication
with a blockchain, and from a tag affixed to an asset, a tag
identifier associated with the asset, and a nonce value associated
with a current location of the asset, wherein the tag identifier
and the nonce value are stored in the tag and in locations in the
blockchain; generating, via the reader, a new nonce value
associated with a transfer of the asset to a new location, the new
nonce value to be stored in a location in the blockchain; and
dynamically updating, via the reader, the tag with an updated asset
status from the blockchain and the new nonce value from the
blockchain in response to a request including the tag identifier,
the nonce value, and the new nonce value.
2. The method of claim 1, comprising: transmitting, via the reader,
the request to update the asset status, of the asset, stored in the
blockchain; and receiving, via the reader, and from the blockchain,
a validation confirmation based on the request.
3. The method of claim 1, wherein the validation confirmation is
received responsive to transmitting the tag identifier and the
nonce value as the request content.
4. The method of claim 1, wherein the tag comprises a radio
frequency identification (RFID) component and a memory.
5. The method of claim 4, wherein the memory stores the tag
identifier and the nonce value.
6. The method of claim 5, wherein an initial value of the nonce
value stored in the memory is blank prior to any update to the
asset status in the blockchain.
7. The method of claim 5, wherein after the asset status of the
asset is updated in the blockchain, updating the memory to store
the new nonce value.
8. A wireless tag reader, comprising: a processor configured to:
read, via a reader in communication with a blockchain, and from a
tag affixed to an asset, a tag identifier associated with the
asset, and a nonce value associated with a current location of the
asset, wherein the tag identifier and the nonce value are stored in
the tag and in locations in the blockchain; generate, via the
reader, a new nonce value associated with a transfer of the asset
to a new location, the new nonce value to be stored in a location
in the blockchain; and dynamically update, via the reader, the tag
with an updated asset status from the blockchain and the new nonce
value from the blockchain in response to a request including the
tag identifier, the nonce value, and the new nonce value.
9. The wireless tag reader of claim 8, wherein the processor is
configured to: transmit, via the reader, the request to update the
asset status, of the asset, stored in the blockchain; and receive,
via the reader, and from the blockchain, a validation confirmation
based on the request.
10. The wireless tag reader of claim 8, wherein the validation
confirmation is received responsive to the tag identifier being
transmitted and the nonce value as the request content.
11. The wireless tag reader of claim 8, wherein the tag comprises a
radio frequency identification (RFID) component and a memory.
12. The wireless tag reader of claim 11, wherein the memory stores
the tag identifier and the nonce value.
13. The wireless tag reader of claim 12, wherein an initial value
of the nonce value stored in the memory is blank prior to any
update to the asset status in the blockchain.
14. The wireless tag reader of claim 12, wherein after the asset
status of the asset is updated in the blockchain, the memory is
updated to store the new nonce value.
15. A non-transitory computer readable storage medium configured to
store at least one instruction that when executed by a processor,
causes the processor to perform: reading, via a reader in
communication with a blockchain, and from a tag affixed to an
asset, a tag identifier associated with the asset, and a nonce
value associated with a current location of the asset, wherein the
tag identifier and the nonce value are stored in the tag and in
locations in the blockchain; generating, via the reader, a new
nonce value associated with a transfer of the asset to a new
location, the new nonce value to be stored in a location in the
blockchain; and dynamically updating, via the reader, the tag with
an updated asset status from the blockchain and the new nonce value
from the blockchain in response to a request including the tag
identifier, the nonce value, and the new nonce value.
16. The non-transitory computer readable storage medium of claim
15, wherein the processor is configured to perform: transmitting,
via the reader, the request to update the asset status, of the
asset, stored in the blockchain; and receiving, via the reader, and
from the blockchain, a validation confirmation based on the
request.
17. The non-transitory computer readable storage medium of claim
15, wherein the validation confirmation is received responsive to
transmitting the tag identifier and the nonce value as the request
content.
18. The non-transitory computer readable storage medium of claim
15, wherein the tag comprises a radio frequency identification
(RFID) component and a memory.
19. The non-transitory computer readable storage medium of claim
18, wherein the memory stores the tag identifier and the nonce
value.
20. The non-transitory computer readable storage medium of claim
19, wherein an initial value of the nonce value stored in the
memory is blank prior to any update to the asset status in the
blockchain, and wherein after the asset status of the asset is
updated in the blockchain, updating the memory to store the new
nonce value.
Description
TECHNICAL FIELD
[0001] This application relates to tracking assets, and more
particularly, to tracking assets with a blockchain.
BACKGROUND
[0002] The blockchain may be used as a public ledger to store
information. Although, primarily used for financial transactions,
the blockchain can store information including assets (i.e.,
products, packages, services, etc.). The blockchain may be used to
establish ownership, provenance, a historical record of status,
state, location changes, etc. In operation, tracked assets may
include a serial number used to uniquely identify each specific
item and that serial number may naturally be a key identifier used
in the ledger. However, there may still be fraud or misuse of the
ledger when tracking ledger updates for a particular asset. For
example, while determining whether a particular source actually has
possession of the asset, a fraudulent attempt to control the asset
may be submitted from a source that merely has knowledge of the
asset's serial number.
SUMMARY
[0003] One example embodiment may include a method that comprises
one or more of reading a tag affixed to an asset, transmitting a
request to update an asset status of the asset in a blockchain,
receiving validation confirmation based on content of the request,
and updating the asset status of the asset in the blockchain.
[0004] Another example embodiment may include an apparatus that
includes one or more of a processor configured to read a tag
affixed to an asset, a transmitter configured to transmit a request
to update an asset status of the asset in a blockchain, and a
receiver configured to receive validation confirmation based on
content of the request, and the processor is further configured to
update the asset status of the asset in the blockchain.
[0005] Still another example embodiment may include a
non-transitory computer readable storage medium configured to store
instructions that when executed cause one or more of reading a tag
affixed to an asset, transmitting a request to update an asset
status of the asset in a blockchain, receiving validation
confirmation based on content of the request, and updating the
asset status of the asset in the blockchain.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] FIG. 1 illustrates an asset identification and update
operation using a blockchain according to example embodiments.
[0007] FIG. 2 illustrates an example system signaling configuration
platform for updating asset status in the blockchain according to
example embodiments.
[0008] FIG. 3A illustrates a flow diagram of an example method of
authorizing and updating assets in the blockchain according to
example embodiments.
[0009] FIG. 3B illustrates a flow diagram of another example method
of authorizing and updating assets in the blockchain according to
example embodiments.
[0010] FIG. 4 illustrates an example network entity configured to
support one or more of the example embodiments.
DETAILED DESCRIPTION
[0011] It will be readily understood that the instant components,
as generally described and illustrated in the figures herein, may
be arranged and designed in a wide variety of different
configurations. Thus, the following detailed description of the
embodiments of at least one of a method, apparatus, non-transitory
computer readable medium and system, as represented in the attached
figures, is not intended to limit the scope of the application as
claimed, but is merely representative of selected embodiments.
[0012] The instant features, structures, or characteristics as
described throughout this specification may be combined in any
suitable manner in one or more embodiments. For example, the usage
of the phrases "example embodiments", "some embodiments", or other
similar language, throughout this specification refers to the fact
that a particular feature, structure, or characteristic described
in connection with the embodiment may be included in at least one
embodiment. Thus, appearances of the phrases "example embodiments",
"in some embodiments", "in other embodiments", or other similar
language, throughout this specification do not necessarily all
refer to the same group of embodiments, and the described features,
structures, or characteristics may be combined in any suitable
manner in one or more embodiments.
[0013] In addition, while the term "message" may have been used in
the description of embodiments, the application may be applied to
many types of network data, such as, packet, frame, datagram, etc.
The term "message" also includes packet, frame, datagram, and any
equivalents thereof. Furthermore, while certain types of messages
and signaling may be depicted in exemplary embodiments they are not
limited to a certain type of message, and the application is not
limited to a certain type of signaling.
[0014] Example embodiments provide storing asset information in a
blockchain, to storing asset status information in a blockchain and
requiring certain security measures prior to permitting asset
status modifications. Further embodiments include using a
blockchain public ledger to track assets. Assets may be shipments,
products, devices, multiple products, etc. The tracked assets may
be identified by a serial number or product identifier (ID) that is
used to uniquely identify each specific asset. The serial number
can be the main identifier used in the ledger when determining if a
ledger update for a particular asset is from a source that actually
has possession of the asset. The identifier may be mismanaged by a
source that merely has knowledge of the asset's serial number and
which is trying to modify/hack/control the asset status remotely
based on the serial number. By using serialization technology, such
as RFID tags or other wireless tags, which include readable and
writable memory, the security and authorization is able to read and
write to the tag. This process may include a user memory reading a
permanent serial number from the tag and a nonce. The nonce may be
a random or pseudo-random number that may only be used once to
perform a blockchain transaction.
[0015] By including a memory portion of the tag, an identifier and
a secret or limited knowledge measure may also be included to
provide a second level of validation to ensure that a person
attempting a ledger update actually has the asset in their
possession and is able to extract the dynamic variable, which in
this example is a dynamic nonce. This dynamic nonce, which was
updated the last time the asset was identified in a shipment chain,
custody chain, or other transfer of ownership or supervision type
chain, is configured to periodically scan the identifier
information on the wireless or RFID tag affixed to the asset and
update a central tracking system with product shipment information.
When the nonce is identified from the RFID tag and an asset update
occurs in the blockchain, the nonce that is written to the tag
after every ledger update is an updated nonce which is unique, new
and has not been used to add asset data to the blockchain. Any
attempted update to the ledger is required to produce an expected
nonce value that is identified from the RFID tag and which is known
to the blockchain data. If found to be valid, the next expected
nonce value will be updated in the blockchain and in the RFID tag
so an entity that identifies the product ID may not have access to
the latest nonce stored in the RFID and in the blockchain during a
previous asset log operation. In operation, the new nonce is
arbitrarily assigned by the reader device after an update to the
blockchain.
[0016] FIG. 1 illustrates an asset identification and update
operation 100 using a blockchain according to example embodiments.
Referring to FIG. 1, the asset 110 may be a box, crate, product,
etc., and the tag 112, may be a wireless tag with one or more of a
processor, a memory, a receiver, a transceiver, and a transceiver.
The tag may be a RFID tag that is affixed to the asset 110 via a
stick adhesive, magnet or other affixing mechanism. In other
embodiments, the tag 112 may be integrated in the body of the asset
110. The tag 112 may include radio communication functions 114
along with a memory 116 that is capable of storing product ID
information, nonce data, and other data. In operation, a RF device
120 or reader may be in communication with a computer system (not
shown) which can communicate with a blockchain or other data
storage systems. When a product is dispatched from a location (such
as a factory), received at another location (such as a shipping
facility), dispatched to a driver, etc., the product/asset and the
asset status may be updated in the blockchain for an immutable
record of the asset's existence and updated existence.
[0017] The tag memory 116 may contain a nonce value or an empty
nonce value if the asset has never been updated (prior to first
update). A nonce is a random or pseudo-random number that may only
be used once when hashing a blockchain entry for finalization. The
reader 120 may scan the tag 112 and extract the product ID 132, the
nonce value 134 and other application ledger data 136 which is
partially or wholly extracted from the asset 110 or which is
substituted from other information sources to complement the asset
data when storing the data in the blockchain. Information may
include time, number of transactions, asset specification data,
blockchain related information, etc.
[0018] An assigned serial number can be read from the tag and "user
memory" which permits for updateable data to be written to the tag.
With this approach, a nonce can be included in the user memory
portion 116 of the tag 112 that will provide a second level
validation to ensure that a person attempting a ledger update
actually does have the asset in their possession and has the serial
number and the current nonce value that matches the current nonce
value stored in the blockchain, which is dynamically assigned and
re-assigned. The nonce that is written to the tag is dynamically
updated after every ledger update. The ledger of the blockchain
then becomes a validation source for any attempted update to the
ledger which includes the expected nonce value which is also stored
in the ledger.
[0019] In this example, a ledger update may include various pieces
of information as validators including the serial number of the
tag, which is the asset ID read from the tag, the nonce value read
from the tag, and a newly updated nonce value, which is the new
nonce value that will be updated on the tag once the previous nonce
value is used to validate the blockchain transaction. For standard
usages and tracking, an update to the ledger may be performed to
identify where an item is with respect to the rest of the logistics
chain. The update to the ledger could be performed to establish a
pedigree (i.e., anti-tampering) in a supply chain (i.e.,
provenance). The update could also be performed for operational
controls, such as establishing a transit time, dwell time, "cohort"
analysis, etc.
[0020] With regard to issuing the new nonce, consider two portions
of identifying information are needed to update a ledger. One is a
serial number, which is fixed and could easily be "known" by
various parties. The other is a rotating value (nonce) that changes
at every transaction. The nonce is then be available with the
object on its tag and is also known to the ledger. In operation,
the tag will be read to extract both the serial number and the
current nonce. A transaction update to the ledger will be requested
with those two pieces of information for validation. In addition,
that transaction request will contain a "next nonce" value that the
ledger will maintain. The reader device will update the tag with
the "next nonce" value. As such, when the tag is read at the next
stop on its path, the process continues and the tag's serial and
nonce are read, sent to the ledger in a transaction to be validated
along with a newly created "next nonce" value that will be updated
in the ledger and updated on the tag. The nonce value is found to
be valid when the one in the tag matches a same value in the
blockchain.
[0021] The ledger can then determine for a given serial numbered
tag if the nonce value that was provided in the ledger update
request was the expected nonce value by comparing that nonce value
to the one stored in the blockchain. Also, such a value could only
be obtained from the tag itself. If the nonce value is found to be
valid, the ledger will update its next expected nonce value
reference with the new nonce provided. This permits the next update
request to go through the same validation. In order to protect
against fraudulent absent-observation ledger updates, the
two-factor identification mechanism for tag identification reduces
the chances of fraud. In this case, a tag is successfully
reference-able to the ledger using two pieces of information
including an assigned asset tag serial ID and a rotating
identification key (nonce). The nonce is used to provide
`originality` to a given ledger request against replay attacks and
confederate systems attempting to record tag observations by
knowing only the tag serial number.
[0022] In one example, an asset is tracked at location `A` with tag
`T`. This is an initial tracking operation. At location `A` an
object with tag `T` is read, the read information from tag `T`
contains tag ID, for example, "12345678" and nonce: <blank>.
Location A (reader device, server, etc.) generates a new random
number nonce, for example, "858469071245" to be used as the next
nonce, and makes an update request to the ledger (blockchain) for
object with tag ID "12345678". In this example, the current nonce
is blank due to an initial asset identification and logging
operation of the RFID tag which has not yet been performed, and
then a next nonce is "858469071245". Application specific
information for the ledger is included as well as part of the
ledger update. The ledger retrieves the latest reference for tag ID
"12345678" and in this case the value is null or non-existent which
indicates that this is the first entry attempt. No further
validation is required. The ledger is updated to include a
reference for tag ID "12345678" which also specifies its next
expected nonce value as "858469071245". Application specific
information is also added to the ledger entry to identify the other
transaction details. As a result, location `A` updates tag T user
information, setting the tags' nonce value to "858469071245".
[0023] FIG. 2 illustrates an example system signaling configuration
platform for updating asset status in the blockchain according to
example embodiments. Referring to FIG. 2, the system configuration
200 includes a tag 210 which is affixed to, near or integrated with
the asset to be monitored. The reader device or location site (such
as a server) 220 which is part of the location where the asset/tag
are currently located and the blockchain 230 are other entities of
the example system 200. The blockchain 230 may be stored on a
device with a processor and memory. In this example, the store
product ID 212 is assigned to the asset and stored in the memory of
the tag 210. The asset and tag may be transported to a new waypoint
location and the reader device/location site 220 may initiate a tag
reading operation 214. The tag reader 220 may retrieve the tag
information and any previous nonce values stored in the tag 210.
The tag reader may be a wireless access device that receives RF
signals from the tag. The reader 220 may generate a new nonce 216
at some point during the communication session with the tag and the
blockchain 230. The retrieved tag information is forwarded to the
blockchain 230 along with any retrieved nonce values stored in the
tag. The information is forwarded as a request 218 and as a result,
the blockchain 230 may retrieve any asset information previously
stored for the product ID provided 222 and also determine whether
the nonce exists or if this is a first update 224. The status
information of the asset is updated 226 with the new nonce value
created during this asset transaction. The tag update 228 can be
made to include the new nonce value now that the previous one is
obsolete or now that one has been assigned in the case of a first
transaction update to the tag. The nonce value is sent to the tag
232 and stored in the tag 210.
[0024] In another example, an asset is tracked at another location
`B` with tag `T`. The location `B` reader may read tag `T`. In this
example, the content of the tag will include a previously assigned
nonce since this is not the first transaction as in the example
with location `A`. The information read from tag `T` may include
tag ID: "12345678" and nonce: "858469071245". The location `B`
device may generate a new random number, "026254866907" to be used
as the next nonce after this transaction with the previous nonce is
complete. Location `B` may make an update request to the ledger for
the object/asset with tag ID "12345678", and with a current nonce
as "858469071245", and the next nonce will be "026254866907" which
replaces the previous nonce value. Application specific information
for the ledger is included as well in the request to the ledger for
the update. The ledger may retrieve a latest reference for tag ID:
"12345678" and determine that the last entry has a private data
entry for the next expected nonce with the value "858469071245".
The update request includes this same value as the current nonce
from the tag read operation so the ledger update request is
validated. The ledger is updated to include a new reference for tag
ID "12345678" and specifies its next expected nonce value as
"026254866907". Application specific information is also added to
the ledger entry. For example, location `B` updates tag T user
information which sets the tag nonce value to "026254866907".
Application specific information may include a supply chain, an
e-pedigree for pharmaceuticals, ownership/provenance for high value
items, and general location tracking use cases.
[0025] FIG. 3A illustrates a flow diagram 300 of an example method
of authorizing and updating assets in the blockchain according to
example embodiments. Referring to FIG. 3A, the method may include
one or more of reading a tag affixed to an asset 312, transmitting
a request to update an asset status of the asset in a blockchain
314, receiving validation confirmation based on request content 316
and updating the asset status of the asset in the blockchain 318.
The request content may include one or more of a tag identifier, a
nonce value stored in the tag and a new nonce value for a
subsequent update to the blockchain. The validation confirmation is
received responsive to transmitting the tag identifier and the
nonce value as the request content. The tag may include a radio
frequency identification (RFID) component and a memory. The memory
stores the tag identifier and a nonce value. An initial value of
the nonce value stored in the memory is blank/null prior to any
update to the asset status in the blockchain, however, after the
asset status of the asset is updated in the blockchain, the method
may also include updating the memory to store a new nonce
value.
[0026] FIG. 3B illustrates a flow diagram 350 of another example
method of authorizing and updating assets in the blockchain
according to example embodiments. Referring to FIG. 3B, the method
350 may include one or more of reading a tag affixed to an asset
352, transmitting a request to update an asset status of the asset
in a blockchain, wherein the request comprises a history of address
tag locations associated with the tag 354, receiving validation
confirmation based on the history of address tag locations included
in the request and the blockchain 356, and updating the asset
status of the asset in the blockchain 358. This alternative
approach includes identifying a history of location information
stored in the tag and the blockchain as an added security measure
necessary prior to receiving access to write and update asset
status in the blockchain. If the locations stored in the tag are
the same as those stored in the blockchain, the access will be
granted pending other security requirements. The locations may be
logged each time the RFID tag is scanned, read, accessed at any
location. The locations may be added each time to create a list of
locations corresponding to the information in the blockchain.
[0027] The above embodiments may be implemented in hardware, in a
computer program executed by a processor, in firmware, or in a
combination of the above. A computer program may be embodied on a
computer readable medium, such as a storage medium. For example, a
computer program may reside in random access memory ("RAM"), flash
memory, read-only memory ("ROM"), erasable programmable read-only
memory ("EPROM"), electrically erasable programmable read-only
memory ("EEPROM"), registers, hard disk, a removable disk, a
compact disk read-only memory ("CD-ROM"), or any other form of
storage medium known in the art.
[0028] An exemplary storage medium may be coupled to the processor
such that the processor may read information from, and write
information to, the storage medium. In the alternative, the storage
medium may be integral to the processor. The processor and the
storage medium may reside in an application specific integrated
circuit ("ASIC"). In the alternative, the processor and the storage
medium may reside as discrete components. For example, FIG. 4
illustrates an example network element 400, which may represent or
be integrated in any of the above-described components, etc.
[0029] As illustrated in FIG. 4, a memory 410 and a processor 420
may be discrete components of a network entity 400 that are used to
execute an application or set of operations as described herein.
The application may be coded in software in a computer language
understood by the processor 420, and stored in a computer readable
medium, such as, a memory 410. The computer readable medium may be
a non-transitory computer readable medium that includes tangible
hardware components, such as memory, that can store software.
Furthermore, a software module 430 may be another discrete entity
that is part of the network entity 400, and which contains software
instructions that may be executed by the processor 420 to
effectuate one or more of the functions described herein. In
addition to the above noted components of the network entity 400,
the network entity 400 may also have a transmitter and receiver
pair configured to receive and transmit communication signals (not
shown).
[0030] Although an exemplary embodiment of at least one of a
system, method, and non-transitory computer readable medium has
been illustrated in the accompanied drawings and described in the
foregoing detailed description, it will be understood that the
application is not limited to the embodiments disclosed, but is
capable of numerous rearrangements, modifications, and
substitutions as set forth and defined by the following claims. For
example, the capabilities of the system of the various figures can
be performed by one or more of the modules or components described
herein or in a distributed architecture and may include a
transmitter, receiver or pair of both. For example, all or part of
the functionality performed by the individual modules, may be
performed by one or more of these modules. Further, the
functionality described herein may be performed at various times
and in relation to various events, internal or external to the
modules or components. Also, the information sent between various
modules can be sent between the modules via at least one of: a data
network, the Internet, a voice network, an Internet Protocol
network, a wireless device, a wired device and/or via plurality of
protocols. Also, the messages sent or received by any of the
modules may be sent or received directly and/or via one or more of
the other modules.
[0031] One skilled in the art will appreciate that a "system" could
be embodied as a personal computer, a server, a console, a personal
digital assistant (PDA), a cell phone, a tablet computing device, a
smartphone or any other suitable computing device, or combination
of devices. Presenting the above-described functions as being
performed by a "system" is not intended to limit the scope of the
present application in any way, but is intended to provide one
example of many embodiments. Indeed, methods, systems and
apparatuses disclosed herein may be implemented in localized and
distributed forms consistent with computing technology.
[0032] It should be noted that some of the system features
described in this specification have been presented as modules, in
order to more particularly emphasize their implementation
independence. For example, a module may be implemented as a
hardware circuit comprising custom very large scale integration
(VLSI) circuits or gate arrays, off-the-shelf semiconductors such
as logic chips, transistors, or other discrete components. A module
may also be implemented in programmable hardware devices such as
field programmable gate arrays, programmable array logic,
programmable logic devices, graphics processing units, or the
like.
[0033] A module may also be at least partially implemented in
software for execution by various types of processors. An
identified unit of executable code may, for instance, comprise one
or more physical or logical blocks of computer instructions that
may, for instance, be organized as an object, procedure, or
function. Nevertheless, the executables of an identified module
need not be physically located together, but may comprise disparate
instructions stored in different locations which, when joined
logically together, comprise the module and achieve the stated
purpose for the module. Further, modules may be stored on a
computer-readable medium, which may be, for instance, a hard disk
drive, flash device, random access memory (RAM), tape, or any other
such medium used to store data.
[0034] Indeed, a module of executable code could be a single
instruction, or many instructions, and may even be distributed over
several different code segments, among different programs, and
across several memory devices. Similarly, operational data may be
identified and illustrated herein within modules, and may be
embodied in any suitable form and organized within any suitable
type of data structure. The operational data may be collected as a
single data set, or may be distributed over different locations
including over different storage devices, and may exist, at least
partially, merely as electronic signals on a system or network.
[0035] It will be readily understood that the components of the
application, as generally described and illustrated in the figures
herein, may be arranged and designed in a wide variety of different
configurations. Thus, the detailed description of the embodiments
is not intended to limit the scope of the application as claimed,
but is merely representative of selected embodiments of the
application.
[0036] One having ordinary skill in the art will readily understand
that the above may be practiced with steps in a different order,
and/or with hardware elements in configurations that are different
than those which are disclosed. Therefore, although the application
has been described based upon these preferred embodiments, it would
be apparent to those of skill in the art that certain
modifications, variations, and alternative constructions would be
apparent.
[0037] While preferred embodiments of the present application have
been described, it is to be understood that the embodiments
described are illustrative only and the scope of the application is
to be defined solely by the appended claims when considered with a
full range of equivalents and modifications (e.g., protocols,
hardware devices, software platforms etc.) thereto.
* * * * *