U.S. patent application number 15/233475 was filed with the patent office on 2017-02-16 for product tracking and control system.
This patent application is currently assigned to The Toronto-Dominion Bank. The applicant listed for this patent is The Toronto-Dominion Bank. Invention is credited to Paul Mon-Wah CHAN, Arthur Carroll CHOW, Perry Aaron Jones HALDENBY, John Jong Suk LEE.
Application Number | 20170046709 15/233475 |
Document ID | / |
Family ID | 57994253 |
Filed Date | 2017-02-16 |
United States Patent
Application |
20170046709 |
Kind Code |
A1 |
LEE; John Jong Suk ; et
al. |
February 16, 2017 |
PRODUCT TRACKING AND CONTROL SYSTEM
Abstract
An apparatus for use in a product tracking system includes a
storage device and a processor, the storage device storing software
instructions that when executed by the processor configure the
processor to: receive a signal representing data including event
information detailing an event involving a manufactured product;
load a portion of a block-chain ledger for tracking information
associated with the product, the block-chain ledger including,
within a block thereof and associated with the product,
trigger-event data reflecting an event trigger and rules data
reflecting a rule associated with the event trigger; and compare
the event information with the trigger-event data, wherein the
event trigger identifies a causal relationship between a possible
event involving the product and an operation with respect to the
product.
Inventors: |
LEE; John Jong Suk;
(Toronto, CA) ; CHOW; Arthur Carroll; (Toronto,
CA) ; HALDENBY; Perry Aaron Jones; (Toronto, CA)
; CHAN; Paul Mon-Wah; (Toronto, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
The Toronto-Dominion Bank |
Toronto |
|
CA |
|
|
Assignee: |
The Toronto-Dominion Bank
Toronto
CA
|
Family ID: |
57994253 |
Appl. No.: |
15/233475 |
Filed: |
August 10, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62204768 |
Aug 13, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 20/401 20130101;
H04L 9/0891 20130101; G06Q 20/367 20130101; H04L 2209/24 20130101;
H04L 9/0816 20130101; H04L 2209/38 20130101; Y04S 10/50 20130101;
G06Q 50/18 20130101; G06Q 2230/00 20130101; G06Q 10/1097 20130101;
G06Q 20/065 20130101; G06Q 50/08 20130101; G06Q 10/103 20130101;
G06Q 2220/10 20130101; H04L 63/0435 20130101; H04L 63/061 20130101;
H04L 63/12 20130101; G06Q 10/0631 20130101; H04N 5/913 20130101;
G06Q 20/3829 20130101; Y02P 90/86 20151101; G06F 21/645 20130101;
G06F 21/62 20130101; G06Q 20/0655 20130101; H04L 63/062 20130101;
Y02P 90/80 20151101; G06Q 30/0214 20130101; G06Q 10/063114
20130101; G06Q 10/08 20130101; H04L 2209/56 20130101; H04L 63/08
20130101; H04L 63/0876 20130101; G06Q 20/4016 20130101; G06Q 20/405
20130101; G06Q 40/08 20130101; H04N 2005/91342 20130101; H04L
9/3247 20130101; H04L 9/0861 20130101; G06Q 40/128 20131203; H04L
63/0442 20130101; H04L 9/0894 20130101; G06Q 20/102 20130101; G06Q
2220/00 20130101 |
International
Class: |
G06Q 20/40 20060101
G06Q020/40; G06Q 20/38 20060101 G06Q020/38 |
Claims
1. An apparatus for use in a product tracking system, comprising: a
storage device; and a processor coupled to the storage device, the
storage device storing software instructions for controlling the
processor that when executed by the processor configure the
processor to: receive a signal representing data including event
information detailing an event involving a product; load a portion
of a block-chain ledger for tracking information associated with
the product, the block-chain ledger including, within a block
thereof and associated with the product, trigger-event data
reflecting an event trigger and rules data reflecting a rule
associated with the event trigger; and compare the event
information with the trigger-event data, wherein the event trigger
identifies a causal relationship between a possible event involving
the product and an operation with respect to the product.
2. The apparatus of claim 1, wherein the processor is further
configured to: apply the rule reflected in the rules data to the
event information when the event information corresponds to the
event trigger reflected in the trigger-event data; automatically
select and perform the operation dependent on an outcome of the
applying the rule to the event information; and save information
corresponding to the event information to the block-chain
ledger.
3. The apparatus of claim 1, wherein the block of the block-chain
ledger includes the trigger event data, the rules data, and a
cryptographic hash of information reflecting a prior event
associated with the product saved to the block-chain ledger.
4. The apparatus of claim 1, wherein the event trigger includes one
or more of the shipment of the product, the delivery of the
product, the receipt of the product, the sale of the product or the
registration of the product.
5. The apparatus of claim 1, wherein the rule defines sales,
distribution and/or use restrictions on the product.
6. The apparatus of claim 1, wherein the operation is processing a
financial transaction for the product or declining a financial
transaction for the product.
7. The apparatus of claim 1, wherein the product is a connected
product that can be remotely provisioned or remotely controlled,
and wherein the operation includes provisioning the products,
enabling the product or disabling the product.
8. The apparatus of claim 1, wherein the rules data is encrypted
within the block-chain ledger, wherein the processor is further
configured to decrypt the encrypted rules data using a master
cryptographic key.
9. The apparatus of claim 1, wherein the processor is further
configured to: encrypt the rules data using a master cryptographic
key; and perform operations that cause the hashing of the encrypted
rules data into a genesis block of the block-chain ledger.
10. The apparatus of claim 9, wherein the processor is further
configured to: encrypt the trigger-event data using the master
cryptographic key; and perform operations that cause the hashing of
the encrypted trigger-event data into the genesis block of the
block-chain ledger.
11. The apparatus of claim 10, wherein the processor is further
configured to: generate a private cryptographic key associated with
a party having an interest in the product, the private
cryptographic key being capable of decrypting the encrypted
trigger-event data; and provide the private cryptographic key to
the party.
12. The apparatus of claim 11, wherein the processor is further
configured to generate at least a portion of the trigger-event data
based on input received from the party.
13. The apparatus of claim 10, wherein the processor is further
configured to: decrypt the trigger-event data and the rules data;
perform operations that modify at least a portion of the
trigger-event data and the rules data; encrypt the modified
trigger-event data and modified rules data; and perform operations
that cause the hashing of the modified encrypted rules data and
modified encrypted trigger-event data into a block of the
block-chain ledger corresponding to a special transaction.
14. The apparatus of claim 2, wherein: the event information
corresponds to a request to regenerate a private block-chain key of
a party having an interest in the product, the request being
received from a device of the party; the applied rule identifies an
operation that regenerates the private block-chain key; and the
processor is further configured to perform the operation, the
operation comprising: regenerating the private block-chain key; and
providing the regenerated private block-chain key to the party.
15. An apparatus for vetting transactions in real-time involving a
product, comprising: a storage device; and a processor coupled to
the storage device, the storage device storing software
instructions for controlling the processor that when executed by
the processor configure the processor to: receive a signal
representing data including event information detailing an event
involving the manufactured product, wherein the manufactured
product is a connected device and at least a part of the event
information is obtained from the manufactured product when in a
connected state; load a portion of a block-chain ledger for
tracking information associated with the product, the block-chain
ledger including, within a block thereof and associated with the
product, trigger-event data reflecting an event trigger and rules
data reflecting a rule associated with the event trigger, the rule
defining at least one of sales, distribution and use restrictions
on the product; apply the rule reflected in the rules data to the
event information when the event information corresponds to the
event trigger reflected in the trigger-event data; automatically
select and perform an operation dependent on an outcome of the
applying the rule to the event information; and save information
corresponding to the event information to the block-chain
ledger.
16. The apparatus of claim 15, wherein the event information
includes a product identifier associated with the connected
device.
17. The apparatus of claim 15, wherein the operation comprises
processing a financial transaction associated with the manufactured
product.
18. The apparatus of claim 17, wherein processing the financial
transaction includes approving the financial transaction, wherein
the processor is configured to save the information corresponding
to the event information to the block-chain ledger responsive to
approving the financial transaction.
19. The apparatus of claim 15, wherein the operation comprises
notifying a manufacturer of a transaction associated with the
product violating the rule.
20. A computer implemented method of tracking a manufactured
product comprising the steps of: receiving with a processor a
signal representing data including event information detailing an
event involving the manufactured product; loading with the
processor a portion of a block-chain ledger for tracking
information associated with the product, the block-chain ledger
including, within a block thereof and associated with the product,
trigger-event data reflecting an event trigger and rules data
reflecting a rule associated with the event trigger; and comparing
the event information with the trigger-event data, wherein the
event trigger identifies a causal relationship between a possible
event involving the product and an operation with respect to the
product.
21. The method of claim 20, further comprising the steps of:
applying with the processor the rule reflected in the rules data to
the event information when the event information corresponds to the
event trigger reflected in the trigger-event data; automatically
selecting and performing with the processor the operation dependent
on an outcome of the applying the rule to the event information;
and saving with the processor information corresponding to the
event information to the block-chain ledger.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims priority under 35 U.S.C.
.sctn.119(e) from co-pending U.S. Provisional Application Ser. No.
62/204,768 filed Aug. 13, 2015, the entirety which is hereby
incorporated by reference herein.
BACKGROUND
[0002] Processes that prevent an introduction of counterfeit or
otherwise unauthorized products such as manufactured goods into the
marketplace are essential to preserve the intellectual property
rights of manufacturers and ensure that criminal activities do not
negatively affect legitimate manufacturers. Processes that prevent
the unauthorized distribution, sales or uses of legitimately
manufactured or distributed products are also important. In many
instances, however, manufacturers lose track of their goods once
they leave their manufacturing plants and move into the hands of
shipping partners or distribution partners, leaving the possibility
that losses may occur before a customer is able to purchase the
product or put the product to legitimate use.
[0003] Conventional block chain ledgers are well adapted to
tracking assets, but despite their many advantages, conventional
block-chain ledger systems do not provide effective systems that
provide for both product tracking and product control during
product distribution or use. For example, while a conventional
block-chain ledger system allows for an individual to verify if a
product has an authentic chain of custody, this block-chain ledger
system provides manufacturers no control over the distribution
channels and how their products are traded or used.
SUMMARY
[0004] In some embodiments of the present disclosure, an apparatus
for use in a product tracking system includes a storage device and
a processor coupled to the storage device, the storage device
storing software instructions for controlling the processor that
when executed by the processor configure the processor to: receive
a signal representing data including event information detailing an
event involving a manufactured product; load a portion of a
block-chain ledger for tracking information associated with the
product, the block-chain ledger including, within a block thereof
and associated with the product, trigger-event data reflecting an
event trigger and rules data reflecting a rule associated with the
event trigger; and compare the event information with the
trigger-event data, wherein the event trigger identifies a causal
relationship between a possible event involving the product and an
operation with respect to the product.
[0005] In embodiments of the apparatus, the processor is further
configured to apply the rule reflected in the rules data to the
event information when the event information corresponds to the
event trigger reflected in the trigger-event data; automatically
select and perform an operation dependent on an outcome of the
applying the rule to the event information; and save information
corresponding to the event information to the block-chain
ledger.
[0006] In some embodiments of the present disclosure, an apparatus
for vetting transactions in real-time involving a manufactured
product includes a storage device; and a processor coupled to the
storage device, the storage device storing software instructions
for controlling the processor that when executed by the processor
configure the processor to: receive a signal representing data
including event information detailing an event involving the
manufactured product, wherein the manufactured product is a
connected device and at least a part of the event information is
obtained from the manufactured product when in a connected state;
load a portion of a block-chain ledger for tracking information
associated with the product, the block-chain ledger including,
within a block thereof and associated with the product,
trigger-event data reflecting an event trigger and rules data
reflecting a rule associated with the event trigger, the rule
defining sales, distribution and/or use restrictions on the
product; apply the rule reflected in the rules data to the event
information when the event information corresponds to the event
trigger reflected in the trigger-event data; automatically select
and perform an operation dependent on an outcome of the applying
the rule to the event information; and save information
corresponding to the event information to the block-chain
ledger.
[0007] In some embodiments of the present disclosure, a computer
implemented method of tracking a manufactured product includes the
steps of receiving with a processor a signal representing data
including event information detailing an event involving the
manufactured product; loading with the processor a portion of a
block-chain ledger for tracking information associated with the
product, the block-chain ledger including, within a block thereof
and associated with the product, trigger-event data reflecting an
event trigger and rules data reflecting a rule associated with the
event trigger; and comparing the event information with the
trigger-event data, wherein the event trigger identifies a causal
relationship between a possible event involving the product and an
operation with respect to the product.
[0008] In embodiments of the method, the method further includes
applying with the processor the rule reflected in the rules data to
the event information when the event information corresponds to the
event trigger reflected in the trigger-event data; automatically
selecting and performing with the processor an operation dependent
on an outcome of the applying the rule to the event information;
and saving with the processor information corresponding to the
event information to the block-chain ledger.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The following will be apparent from elements of the figures,
which are provided for illustrative purposes and are not
necessarily to scale.
[0010] FIG. 1 is a diagram of a system in accordance with some
embodiments of the present disclosure.
[0011] FIG. 2 is a diagram of a conventional block-chain ledger
architecture.
[0012] FIG. 3 is a diagram of a hybrid public-private block-chain
ledger architecture in accordance with some embodiments.
[0013] FIG. 4 is a flowchart of a process for performing
event-based operations on assets tracked within a hybrid
block-chain ledger in accordance with some embodiments.
[0014] FIG. 5 is a diagram of a hybrid public-private block-chain
ledger architecture capable of tracking usage data of users in
accordance with some embodiments.
[0015] FIG. 6 is a diagram of a hybrid public-private block-chain
ledger architecture capable of encrypting usage data and metadata
in accordance with some embodiments.
[0016] FIG. 7 is a diagram illustrating an embodiment using a
hybrid block-chain ledger for tracking a manufactured good.
[0017] FIG. 8 is a diagram illustrating the product chain in an
embodiment of a product tracking and control system using a hybrid
block-chain ledger.
DETAILED DESCRIPTION
[0018] This description of the exemplary embodiments is intended to
be read in connection with the accompanying drawings, which are to
be considered part of the entire written description. The use of
the singular includes the plural unless specifically stated
otherwise. The use of "or" means "and/or" unless stated otherwise.
Furthermore, the use of the term "including," as well as other
forms such as "includes" and "included," is not limiting. In
addition, terms such as "element" or "component" encompass both
elements and components comprising one unit, and elements and
components that comprise more than one subunit, unless specifically
stated otherwise. Additionally, the section headings used herein
are for organizational purposes only, and are not to be construed
as limiting the subject matter described.
[0019] FIG. 1 is a block diagram of a system 100 in accordance with
some embodiments of the present disclosure. System 100 may be a
computing environment including client devices 102, 104, and 106,
system 140, one or more peer systems 160, and a communications
network 120 connecting various components of system 100. Although
three client devices are shown in this example, any number of
client devices may be present.
[0020] Various components of computing environment 100 are
configured to address problems associated with conventional
block-chain-based ledgers by embedding a master encryption key
architecture into a conventional block-chain architecture (e.g., a
block-chain-based architecture associated with the public
Bitcoin.TM. ledger). In various embodiments, the resulting hybrid
public-private block-chain architecture facilitates selective
encryption of information by client devices 102, 104, and 106,
system 140, and/or peer systems 160, thus providing a solution that
protects sensitive and/or confidential instructions.
[0021] The conventional block-chain architecture is described below
with reference to FIG. 2, and then hybrid public-private
block-chain architectures in accordance with various embodiments
are described.
[0022] Asset Tracking Using Conventional Block-Chain Ledgers
[0023] FIG. 2 is a diagram of a structure 200 of a conventional
block-chain ledger, which may be generated through the interaction
of components of computing environment 100. In the example of FIG.
2, user 110 is associated with client device 104, which executes a
stored software application (e.g., a wallet application) capable of
obtaining a current version of a conventional block-chain ledger
from one or more networked computer systems (e.g., one of peer
systems 160 configured to "mine" broadcasted transaction data and
update ledgers). The current version of a conventional block-chain
ledger may represent a "longest" block-chain ledger that includes a
maximum number of discrete "blocks." The blocks identify respective
transactions that transfer and/or distribute portions of tracked
assets among various owners, including user 110.
[0024] FIG. 2 shows blocks corresponding to two transactions 202
and 204, with arrows to the left and right of these transactions
indicating that these are merely two transactions in a potentially
longer series of chained blocks (hence the term "block-chain
ledger"). In the first transaction (transaction 202) depicted in
FIG. 2, user 108 transfers ownership of a portion of tracked assets
(e.g., of some amount of a virtual currency or cryptocurrency) to
user 110. In the second transaction (transaction 204), user 110
transfers ownership to user 112. In general, any number of
transactions may be supported.
[0025] Client device 104 obtains the current block-chain ledger and
processes the block-chain ledger to determine that a prior owner
(user 108 in this example) transferred ownership of a portion of
the tracked assets to user 110 in transaction 202. One or more peer
systems 160 previously verified, processed, and packed data
associated with transaction 202 into a corresponding block of the
conventional block-chain.
[0026] Transaction 202 includes a cryptographic hash (e.g., hash
202A) of one or more prior transactions, and a public key of the
recipient (e.g., public key 202B of user 110). The transaction data
may also include a digital signature 202C of user 108 (the prior
owner), which is applied to hash 202A and public key 202B using a
private key 202D of user 108 through any of a number of techniques
apparent to one of skill in the art. The presence of user 108's
public key within transaction data included within the conventional
block-chain ledger facilitates verification of user 108's digital
signature 202C by client device 104 and/or peer systems 160.
[0027] In the second transaction (transaction 204), user 110
transfers the tracked asset portion to user 112. For example,
client device 104 may execute one or more software applications
(e.g., wallet applications) that generate data specifying a
transaction (e.g., transaction 204) transferring ownership of the
tracked asset portion from user 110 to user 112, and further. The
software application(s) transmit the generated data to one or more
of peer systems 160 for verification, processing (e.g., additional
cryptographic hashing) and inclusion into a new block of the
block-chain ledger.
[0028] For example, data specifying transaction 204 may include a
cryptographic hash 204A of prior transaction 202, a quantity or
number of units of the tracked asset portion that are subject to
transfer in transaction 204, and a public key of the recipient
(e.g., public key 204B of user 112). Further, in some aspects, the
data specifying transaction 204 may include a digital signature
204C of the user 110, which may be applied to hash 204A and public
key 204B using a private key 204D of user 110. Further, and by way
of example, the presence of user 110's public key 202B within
transaction data included within the conventional block-chain
ledger may enable various devices and systems (e.g., client devices
106, 106, and/or 108, peer systems 160, etc.) to verify user 110's
digital signature 204C, as applied to data specifying transaction
204.
[0029] One or more of peer systems 160 may receive the data
specifying transaction 204 from client device 104. In certain
instances, peer systems 160 may act as "miners" for the block-chain
ledger, and may competitively process the received transaction data
(either alone or in conjunction with other data) to generate
additional blocks of the ledger, which may be appended to the
block-chain ledger and distributed across peer systems 160 (e.g.,
through a peer-to-peer network) and to other connected devices of
environment 100.
[0030] Conventional block-chain ledger architectures enable the
public to review content of the ledgers and verify ownership
details. The decentralized nature of conventional block-chain
ledgers enables multiple distributed networks to verify the
contents of a single ledger. The resulting redundancy may render
the conventional block-chain ledger architecture more robust than
centralized server systems, and effectively eliminates the
falsification of ledger data by malicious parties.
[0031] Despite these positive characteristics, conventional
block-chain ledger architectures have certain drawbacks when
implemented by secured, high-risk systems. For example, unencrypted
conventional ledger blocks may represent a security concern for
transactions of sensitive nature and may represent a privacy
concern for members of the general public. For instance,
information indicative of an interaction of a prior asset owner and
a corresponding device, as present within conventional block-chain
ledgers, may represent private information that should not be
available to future owners, let alone members of the public.
[0032] Furthermore, if an owner loses his/her private key, the
distributed nature of conventional block-chain ledger architectures
provides little or no opportunity to recover possession of the
tracked asset(s). The rigidity and inflexibility of these
conventional block-chain ledger architectures, and their inability
to adapt to changing circumstances (e.g., loss of private keys,
theft of tracked assets due to fraudulent or malicious activity),
often results in volatility in the usage of the tracked assets and
an erosion in the public's trust of conventional block-chain
ledgers.
[0033] Various embodiments address the foregoing deficiencies of
conventional block-chain ledger architectures by providing security
features suitable for use in high-risk, sensitive scenarios.
Furthermore, various embodiments provide a framework that gives
recourse to owners or holders of assets tracked by block-chain
ledger architectures in the event of fraud or malicious activity,
while maintaining the public availability and verification
characteristics of block-chain ledgers.
[0034] Client Devices
[0035] Referring back to FIG. 1, each of client devices 102, 104,
and 106 may include a computing device, such as a hashing computer,
a personal computer, a laptop computer, a tablet computer, a
notebook computer, a hand-held computer, a personal digital
assistant, a portable navigation device, a mobile phone, a smart
phone, a wearable computing device (e.g., a smart watch, a wearable
activity monitor, wearable smart jewelry, and glasses and other
optical devices that include optical head-mounted displays (OHMDs),
an embedded computing device (e.g., in communication with a smart
textile or electronic fabric), and any other type of computing
device that may be configured to store data and software
instructions, execute software instructions to perform operations,
and/or display information on a display device. At least one of
client devices 102, 104, and 106 may be associated with one or more
users, such as users 108, 110, and 112, as shown in FIG. 1. For
example, user 110 operates client device 104 and causes it to
perform one or more operations in accordance with various
embodiments.
[0036] Each client device 102, 104, 106 includes one or more
tangible, non-transitory memories that store data and/or software
instructions, and one or more processors configured to execute
software instructions. Client devices 102, 104, and 106 may include
one or more display devices that display information to a user and
one or more input devices (e.g., keypad, keyboard, touchscreen,
voice activated control technologies, or any other type of known
input device) to allow the user to input information to the client
device.
[0037] In one aspect, each client device 102, 104, and 106 stores
in memory one or more software applications that run on the client
device and are executed by the one or more processors. In some
instances, each client device stores software applications that,
when executed by one or more processors, perform operations that
establish communications with one or more of peer systems 160
(e.g., across network 120) and that obtain, from peer systems 160,
a current version of a hybrid block-chain ledger generated and
maintained in accordance with various embodiments.
[0038] Each client device 102, 104, and 106 may execute the stored
software application(s) to obtain data from the hybrid block-chain
ledger that includes data identifying one or more tracked assets,
and/or a public key of one or more users. The executed software
applications may cause client devices 102, 104, and 106 to extract,
from one or more accessed transaction blocks of the block-chain
ledger, a copy of an encrypted and/or hashed ownership/rules
portion of the transaction block(s) (e.g., including the
identification of a holder of a master key) and/or a copy of an
encrypted and/or hashed master data block (e.g., encrypted using
the master key and including rules permitting preconfigured and/or
permissible actions involving the tracked assets). Client devices
102, 104, and 106 may provide information associated with one or
more actions or transactions involving the tracked assets (e.g.,
information identifying the actions or transaction, information
identifying the assets, a public key, a digital signature, etc.) to
peer systems 160, along with copies of the encrypted and/or hashed
rules engines and lists of triggering events.
[0039] In some embodiments, the stored application(s) include a
wallet application provided by business entity 150 (e.g., a mobile
wallet application or an application executable on a desktop
computer). The wallet application is capable of initiating
transactions denominated in one or more currencies, including
virtual currencies such as Bitcoin.TM..
[0040] Exemplary Computer Systems
[0041] System 140 may be a computing system configured to execute
software instructions to perform one or more operations in
accordance with various embodiments. In one aspect, system 140 is
associated with a business entity 150 (e.g., a financial
institution) that provides financial accounts, financial services
transactions, and investment services to one or more users (e.g.,
customers of business entity 150). In some aspects, system 140 is a
distributed system that includes computing components distributed
across one or more networks, e.g., network 120.
[0042] In one aspect, system 140 includes computing components
configured to store, maintain, and generate data and software
instructions. For example, system 140 may include one or more
servers (e.g., server 142) and tangible, non-transitory memory
devices (e.g., data repository 144). Server 142 may include one or
more computing devices configured to execute software instructions
to perform one or more processes in accordance with various
embodiments. In one example, server 142 is a computing device that
executes software instructions to perform operations that provide
information to at least one other component of computing
environment 100.
[0043] In one embodiment, server 142 includes a computer (e.g., a
personal computer, network computer, or mainframe computer) having
one or more processors that are selectively activated or
reconfigured by a computer program. In one aspect, server 142 (or
other computing components of system 140) may be configured to
provide one or more websites, digital portals, etc., that provide
services consistent with business entity 150, such as a digital
banking or investment portal. For instance, server 142 may be
configured to provide information associated with a requested web
page over communications network 120 to client device 104, which
may render the received information and present content from the
web page on a display device, e.g., a touchscreen display unit.
[0044] In other aspects, server 142 (or other computing components
of system 140) may be configured to provide information to one or
more application programs executed by client device 104, e.g.,
through a corresponding application programming interface (API).
For example, client device 104 may execute an application program
associated with and provided by business entity 150, such a mobile
banking application and/or a mobile wallet application, to provide
services in accordance with various embodiments. In some instances,
server 142 provides information to client devices 102, 104, and/or
106 (e.g., through the API associated with the executed application
program), and client devices 102, 104, and/or 106 present portions
of the information to corresponding users through a corresponding
graphical user interface (GUI).
[0045] Server 142 (or other computing components of system 140) may
be configured to provide to client devices 102, 104, and/or 106
(and/or receive from any of the client devices) information
associated with services provided by business entity 150. For
example, client device 104 may receive the transmitted information,
and store portions of the information in locally accessible storage
device and/or network-accessible storage devices and data
repositories (e.g., cloud-based storage). In one instance, client
device 104 executes stored instructions (e.g., an application
program, a web browser, a mobile banking application, and/or a
mobile wallet application) to process portions of the stored data
and render portions of the stored data for presentation to user
110. Additionally, server 142 may be incorporated as a
corresponding node in a distributed network or as a corresponding
networked server in a cloud-computing environment. Furthermore,
server 142 may communicate via network 120 with one or more
additional servers (not shown), which may facilitate the
distribution of processes for parallel execution by the additional
servers.
[0046] In further aspects, business entity 150 may represent a
"controlling entity" capable of regulating transactions assets
(e.g., units of virtual currency, units of various financial
instruments, physical assets, including tangible products, such as
manufactured products, etc.) tracked within hybrid public-private
ledgers in accordance with various embodiments. Additional details
of embodiments with respect to tracking and control of products are
provided in the section below titled "Product Tracking and
Control/Counterfeit Prevention", though it should be understood
that the description herein regarding tracking "assets" through the
hybrid block-chain ledgers applies to tracking and control of
products (manufactured or otherwise (e.g., grown, produced,
recovered, mined, etc.)) through the improved block chain ledger
architecture. In this regard, such products can be considered a
form of "asset".
[0047] For example, one or more computing components of system 140
(e.g., server 142) may be configured (e.g., by executed software
instructions) to establish one or more rules that regulate a
distributions of and/or transactions associated with the tracked
assets, an initiation of transfers of the tracked assets (e.g., a
sale, a use of the tracked assets as collateral in a secured
transaction etc.), and any other action involving the tracked
assets and/or the hybrid public-private ledger (e.g., processes
that generate additional cryptographic key sets for user 110,
processes that recover assets tracked in the hybrid public-private
ledger, etc.).
[0048] System 140 may establish causal relationships between one or
more of the established rules and one or more events that trigger
an initiation of one or more corresponding regulated distributions,
transfers, and/or other actions involving assets tracked within the
hybrid public-private ledger (e.g., "triggering events"). For
example, a confirmed loss of a private cryptographic key issued to
user 110 may represent a triggering event that causes system 140 to
verify user 110's identity, initiate a transaction of the orphaned
assets, generate a new pair of public and private cryptographic
keys for user 110 (i.e., public and private block-chain keys), and
transmit at least the private block-chain key to user 110 through
secure, non-accessible processes (e.g., by mail), in accordance
with one or more of the established rules.
[0049] A theft of a portion of user 110's tracked assets (e.g.,
units of virtual currency specified within one of more blocks of
the hybrid public-private ledger) may represent a triggering event.
This triggering event causes system 140 to initiate a recovery
protocol to generate a transaction request to recover the value of
the stolen assets (e.g., to transfer the stolen assets back to user
110), and also causes system 140 to generate a new pair of public
and private block-chain keys for user 110. In other instances, a
death and/or incapacitation of user 110 may represent a triggering
event that causes system 140 to initiate a series of transaction to
distribute at least a portion of the tracked assets (e.g., through
corresponding transaction requests) to one or more additional
owners identified by user 110 and specified within corresponding
ones of the identified rules.
[0050] In some aspects, system 140 is configured to establish one
or more of the rules, and one or more of the causal relationships
and triggering events, based on internal regulations associated
with business entity 150. For example, the internal regulations
associated with business entity 150 may specify that system 140
verify an identity of user 110 (e.g., based on various forms of
multi-factor authentication data) and/or obtain specific elements
of documentation (e.g., a police report, etc.) prior to initiating
the lost private key protocol and/or recovery protocols outlined
above. In other aspects, system 140 may establish one or more of
the rules and/or triggering events based on information received
from user 110 (e.g., as input provided to a web page or other
graphical user interface (GUI) presented by client device 104 and
provided to system 140). For example, user 110 may specify, as
input to the web page or GUI presented by client device 104, one or
more individuals that would receive portions of the tracked assets
upon completion of one or more tasks and/or in the event of user
110's accidental death. Various embodiments are, however, not
limited to the exemplary triggering events and established rules
described above, and in other aspects, various embodiments may be
configured to generate any other user- and system-specified rules
and triggering events consistent with the hybrid public-private
ledger and appropriate to the tracked assets, user 110, and/or
business entity 150 (acting as a centralized authority for the
hybrid public-private ledger).
[0051] In embodiments where the hybrid block-chain ledger is used
in tracking and control of products, such as manufactured goods,
rules may govern the sale, distribution or use of the product in
the distribution chain between the manufacturer and the end user.
Triggering events along the distribution chain may include, by way
of example only, the shipping of the product, the receipt of the
product, the sale of the product, modification of a rule or term
associated with the product, and the use of the product (e.g., in
the case of a connected device). Operations based on application of
a rule to an event may include, without limitation, registering a
product, activating a product, deactivating a product, approving a
transaction, declining a transaction, and transferring of funds
related to a service (e.g., shipping) pertaining to the product or
for a sale of the product.
[0052] System 140 may be configured to store the one or more
established rules (e.g., as a rules engine) and one or more of the
established trigger events (e.g., as an event trigger list) within
a portion of a local data repository (e.g., data repository 144).
System 140 may be configured to store portions of the rules engine
and/or event trigger list within a secure data repository
accessible to system 140 across network 140 (e.g., cloud-based
storage).
[0053] One or more computing components of system 140 (e.g., server
142) may be configured to generate pairs of public and private
block-chain keys for user 110 (e.g., user 110's public/private
block-chain key pair), and to provide the generated private
block-chain key to user 110 through secure, non-accessible and/or
out-of-band communications (e.g., by mail, etc.). In further
embodiments, the one or more components of system 140 (e.g., server
142) may be configured to generate and maintain additional
cryptographic keys that facilitate a generation and maintenance of
portions of the hybrid public-private ledger. For instance, system
140 may be configured to generate a master key, which system 140
may leverage to encrypt the stored rules engine. System 140 may
store copies of the generated master key in a portion of data
repository 144 that is not accessible to user 110 (and any other
users), thus maintaining a confidence of the generated master
key.
[0054] System 140 may be configured to generate and maintain a
private crypto key on behalf of user 110 (and users 108 and 112),
which system 140 may leverage to encrypt the stored event trigger
list, and which may be provided to user 110 (and/or to users 108,
112) through secure, non-accessible and/or out-of-band
communications. System 140 may store copies of the private crypto
keys in a portion of data repository 144.
[0055] In some embodiments, one or more computing components of
system 140 (e.g., server 140) is configured to hash the generated
(and encrypted) rules engine and event trigger list into a genesis
block associated with the hybrid public-private ledger. System 140
may provide the encrypted rules engine and event triggers list to
one or more of peer systems 160, which may be configured to hash
the encrypted rules engine and event trigger list into the genesis
block. By hashing the encrypted rules engine and event trigger list
into the genesis block of the hybrid public-private ledger, various
embodiments enable an in-band communication of the encrypted rules
engine and event triggers from user to user within blocks (e.g.,
transactions) of the hybrid public-private ledger.
[0056] Exemplary Data Repositories and Stored Data
[0057] Data repository 144 may include one or more memories that
are configured to store and provide access to data and/or software
instructions. Such memories may include tangible non-transitory
computer-readable media that store software instructions that, when
executed by one or more processors (e.g., of server 132), perform
one or more operations in accordance with various embodiments. Data
repository 144 may also be configured to store information relating
to business entity 150, e.g., a financial institution.
[0058] For instance, data repository 144 may store customer data
that uniquely identifies customers of a financial institution
associated with system 140. As one example, a customer of the
financial institution (e.g., any of users 108, 110, and 112) may
access a web page associated with system 140 (e.g., through a web
server executed by a corresponding front end), and may register for
digital banking services and provide data, which may be linked to
corresponding ones of users 108, 110, and/or 112, and stored as
customer data within data repository 144. The stored customer data
may, for example, include personal information, government-issued
identifiers, employment information, and contact information. The
stored customer data may also include authentication credentials
associated with registered users of the financial institution,
e.g., a user name, a user-specified password, a system-generated
password, an alphanumeric identification number (e.g., a PIN
number) specified by the users or assigned by financial system 140,
biometric information, and information facilitating enhanced
authentication techniques.
[0059] Data repository 144 may store a rules engine identifying one
or more rules that regulate a distribution of the tracked assets,
an initiation of one or more transactions involving the tracked
assets (e.g., a sale, a transfer in ownership, a use of the tracked
assets as collateral in a secured transaction etc.), and any other
action involving the tracked assets and/or the hybrid
public-private ledger (e.g., processes that generate additional
cryptographic key sets for users 108, 110, and/or 112, processes
that recover assets tracked in the hybrid public-private ledger,
etc.). Data repository 144 may also store information identifying
an event triggers list that identifies causal relationships
established by system 140 between one or more of the established
rules and one or more events that trigger an initiation of one or
more corresponding regulated distributions, transactions, and/or
assets tracked within the hybrid block-chain ledger (e.g.,
"triggering events").
[0060] In some aspects, system 140 is configured to establish one
or more of the rules, and one or more of the causal relationships
and triggering events, based on one or more internal regulations
associated with business entity 150. In other aspects, system 140
may establish one or more of the rules and/or triggering events
based on information received from one or more of users 108, 110,
and/or 112, e.g., as input provided to a web page or other
graphical user interface (GUI) presented by client devices 102,
104, and/or 106 and provided to system 140.
[0061] Data repository 144 may also store a copy of a master key,
private crypto keys associated with users 108, 110, and 112, and
additional private crypto keys associated with other users. For
example, system 140 may be configured to store the private crypto
keys in a data structure that includes information that associates
the private crypto keys with corresponding users 108, 110, and 112,
and further, may be configured to store the master key in a data
structure within data repository 144 that is inaccessible to users
108, 110, and/or 112 (and other users). Further, in some aspects,
data repository 144 may be configured to store the rules engine
and/or event triggers list in raw, unencrypted form. In other
aspects, in accordance with various embodiments, data repository
144 may be configured to store the rules engine and/or event
triggers in encrypted form (e.g., using the stored master key),
and/or store a hashed representation of the rules engine and/or the
event triggers list.
[0062] Exemplary Communications Networks
[0063] Communications network 120 may include one or more
communication networks or media of digital data communication.
Examples of communication network 120 include a local area network
("LAN"), a wireless LAN, a RF network, a Near Field Communication
(NFC) network, (e.g., a "WiFi" network), a wireless Metropolitan
Area Network (MAN) connecting multiple wireless LANs, NFC
communication link(s), and a wide area network ("WAN"), e.g., the
Internet. In accordance with various embodiments of the present
disclosure, communications network 120 may include the Internet and
any publicly accessible network or networks interconnected via one
or more communication protocols, including, but not limited to,
hypertext transfer protocol (HTTP) and transmission control
protocol/internet protocol (TCP/IP). Communications protocols in
accordance with various embodiments also include protocols
facilitating data transfer using radio frequency identification
(RFID) communications and/or NFC. Moreover, communications network
120 may also include one or more mobile device networks, such as a
GSM network or a PCS network, allowing client device 104 to send
and receive data via applicable communications protocols, including
those described herein.
[0064] Exemplary Peer Systems
[0065] Referring back to FIG. 1, peer systems 160 may include one
or more computing systems configured to execute software
instructions to perform one or more operations in accordance with
various embodiments. In some aspects, peer systems 160 may include
computing components configured to store, maintain, and generate
data and software instructions. For example, each of peer systems
160 may include one or more computing devices (e.g., a server,
network computer, or mainframe computer) having one or more
processors that may be selectively activated or reconfigured by
executable instructions (e.g., computer programs) stored in one or
more tangible, non-transitory computer-readable storage
devices.
[0066] In an embodiment, one or more of peer systems 160 may be
configured to receive, from client device 104 across network 120,
information associated with a distribution of, transaction
involving, or other action associated with one or more assets
tracked within hybrid block-chain ledgers in accordance with
various embodiments. For example, the received information may
include, but is not limited to, data identifying at least a portion
of the tracked assets, data identifying a current owner of the
portion of the tracked assets (e.g., user 110) (or a obfuscated
owner identifier), and further, encrypted copies of and/or hash
values representative of the rules engine and event triggers
list.
[0067] In some aspects, one or more of peer systems 160 are
configured (e.g., by the executed software programs) to validate
the received information and to generate a new block of the hybrid
block-chain ledger that includes the received information, either
alone (e.g., using a "one transaction, one block" paradigm) or in
combination with information identifying additional distributions,
transactions, or other actions associated with one or more tracked
assets (e.g., as a multiple-transaction block). The one or more
peer systems 160 may be further configured to generate one or more
hashes representative of the new block, which may be appended to a
prior version of the hybrid private-public ledger along with the
newly generated block. In some aspects, the one or more peer
systems 160 may maintain the updated versions of the hybrid
private-public ledger (i.e., the latest, longest hybrid
private-public ledger), and may provide the updated version of the
hybrid private-public ledger to client devices 102, 104, and/or 106
(or other client devices associated with other users) upon receipt
of a request across network 120 and/or at regular or predetermined
intervals.
[0068] In certain instances, and in addition to a connection with
network 120, peer systems 160 may be interconnected across a
peer-to-peer network (not depicted in FIG. 1) using any of the
wired or wireless communications protocols outlined above. Further,
in some instances, one or more of peer systems 160 may function as
a "miner," where any miner may be compensated in units of a virtual
currency (e.g., Bitcoin.TM.) for validating the received data and
for generating updated versions of the hybrid block-chain
ledger.
[0069] Exemplary Processes for Tracking Assets Using Hybrid
Private-Public Ledgers
[0070] In some embodiments, client devices 102, 104, and/or 106 may
execute one or more stored applications that enable corresponding
users to track, in conjunction with peer systems 150 and other
components of computing environment 100, a disposition and
distribution of one or more assets using conventional, publicly
available and transparent block-chain ledgers. In some aspects, the
use of public block-chain ledgers to track ownership, disposition,
and distribution of actual and/or virtual assets (e.g., unit of
virtual currencies, such as Bitcoin.TM., unit of other financial
instruments and securities, physical assets, etc.) may present
advantages over existing centralized server systems, such as those
provided by financial institutions that leverage private
ledgers.
[0071] Exemplary Hybrid Public-Private Block-Chain Ledger
Architectures
[0072] Various embodiments address problems associated with
conventional block-ledger architectures in a technical manner, by
providing computer-implemented systems and methods that augment a
conventional block-chain ledger with a private-master encryption
key architecture that, in conjunction with an owner's pair of
public and private block-chain keys, selectively encrypt ledger
data to protect both the privacy of owners of tracked assets and
the confidentiality of existing instruction sets maintained within
the block-chain ledger.
[0073] By incorporating an encrypted rules engine and corresponding
list of triggering events (e.g., an event triggers list) into each
block of the conventional block-chain ledger architecture (and thus
generating a hybrid, public-private block-chain architecture),
computer-implemented systems and methods in accordance with various
embodiments may perform operations that provide owners or holders
tracked assets with recovery options in an event of fraud or
malicious activity, while maintaining the public availability and
verification characteristic of conventional block-chain
ledgers.
[0074] Discrete data blocks of the conventional block-chain ledgers
(e.g., as outlined above in reference to FIG. 2) and of the hybrid
block-chain ledgers (e.g., as described in reference to FIG. 3) may
include common elements of data that may specify transactions that
distribute, transfer, and/or otherwise act upon portions of tracked
assets. For example, these common data elements may include, but
are not limited to, input data that references one or more prior
transactions (e.g., a cryptographic hash of the one or more prior
transactions), output data that includes instructions for
transferring the tracked asset portion to one or more additional
owners (e.g., a quantity or number of units of the tracked asset
portion that are subject to the transaction and a public key of the
recipient), and a digital signature applied to the input and/or
output data using a corresponding private key of a current owner of
the tracked asset portion. Various embodiments are, however, not
limited to exemplary transactions that include a transfer of
tracked assets and to the exemplary data elements described above,
and in further embodiments, discrete blocks of the hybrid
block-chain ledgers may represent any other transaction appropriate
to the tracked assets and any other data appropriate to the tracked
assets and to the transaction.
[0075] In contrast to conventional block-chain ledgers, various
embodiments may establish a "centralized authority" capable of
vetting real-time transactions (e.g., distributions, transfers,
and/or other actions) involving portions of assets tracked within
the exemplary hybrid block-chain ledger architectures described
herein, and capable of establishing and maintaining rules (e.g.,
through a rules engine and corresponding list of triggering events)
that facilitate regulatory-based, policy-based, and
customer-specified controls of transactions involving the tracked
assets (e.g., units of virtual currency, etc.).
[0076] For example, business entity 150 may represent the
centralized authority, and one or more computing components of
system 150 may perform operations that establish the rules engine
and the list of triggering events, which may be stored within a
secure data repository (e.g., data repository 144). In some
aspects, the generated and stored rules engine may identify one or
more rules that regulate a distribution of the tracked assets, an
initiation of one or more transactions involving the tracked assets
(e.g., a sale, a use of the tracked assets as collateral in a
secured transaction etc.), and further, any other action involving
the tracked assets and/or the hybrid public-private ledger (e.g.,
processes that generate additional cryptographic key sets for user
110, processes that recover assets racked in the hybrid
public-private ledger, etc.). The generated and stored list of
triggering events may include information that specifies causal
relationships between one or more of the established rules and one
or more events that trigger an initiation of one or more
corresponding regulated distributions, transactions, and/or actions
associated with assets tracked within the hybrid public-private
ledger (e.g., the triggering events).
[0077] System 140 may establish one or more of the rules and/or
triggering events to reflect regulations and/or policies
promulgated by a governmental entity, a financial regulator, and/or
the centralized authority. For example, system 140 may establish a
loss of a private key by user 110 as a "triggering event" that
would cause system 140 to perform operations that create a new
transaction and generate a new pair of public and private
block-chain keys for user 110 in response to a verification of
particular authentication credentials. In other aspects, system 140
may establish one or more of the rules and/or triggering events
based on information received from user 110 (e.g., as input
provided to a web page or other graphical user interface (GUI)
presented by client device 104 and provided to system 140). For
example, user 110 may specify a particular distribution of tracked
assets (e.g., recurring bill payments, distributions to other
owners, etc.) in response to an accident that may occur in the
future involving user 110 and/or user 110's death (e.g., triggering
events).
[0078] In further contrast to conventional block-chain ledgers, one
or more computing components of system 140 (e.g., server 142 upon
execution of stored instructions) may generate additional
cryptographic keys that facilitate the exemplary regulation of
transactions (e.g., distributions, transfers, and/or actions)
involving assets tracked within the hybrid public-private ledger.
By way of example, system 140 may generate a master cryptographic
key with which system 140 may encrypt the generated and stored
rules engine. In some aspects, system 140 may store copies of the
generated master key in a portion of data repository 144 that is
not accessible to user 110 (and any other users), thus maintaining
confidence in the generated master key.
[0079] System 140 may also perform operations that encrypt the
generated list of triggering events, either alone or in conjunction
with metadata identifying the centralized authority and/or
information facilitating processing of the transaction blocks
throughout the hybrid block-chain ledger. System 140 may also
perform operations that generate and maintain additional private
cryptographic keys (e.g., a private "crypto" key) associated with
each owner and associated with the assets tracked within the hybrid
block-chain ledger (e.g., users 108, 110, and/or 112). The private
crypto keys enable the owners to decrypt and access the list of
triggering events and the metadata identifying the centralized
authority. System 140 may store copies of the generated private
crypto keys in a portion of data repository 144. Furthermore,
system 140 may also perform operations that provide corresponding
ones of the private crypto keys to users 108, 110, and/or 112
through secure, inaccessible, and/or out-of-band
communications.
[0080] Various embodiments may also be configured to communicate
the encrypted and/or hashed rules engine and list of triggering
events to owners of, and/or user associated with, the tracked
assets through "in-band" communication processes, such as through
an incorporation of the encrypted rules engine and list of
triggering events into the transaction blocks of the hybrid
block-chain ledger. For example, system 140 may perform operations
that hash the encrypted rules engine and list of triggering events
into a genesis block of the hybrid block-chain ledger, the contents
of which may be incorporated (e.g., by client devices 102, 104,
and/or 106, peer systems 160, etc.) into each of the subsequent
transaction blocks generated and appended to the hybrid block-chain
ledger. In some aspects, by incorporating the hashed and encrypted
rules engine and list of triggering events into blocks of the
hybrid block-chain ledger, various embodiments may ensure that the
established rules are followed even in an event of actions by
malicious parties to disrupt the tracked assets (e.g., instances of
Bitcoin.TM. peeling, etc.)
[0081] The additional private crypto keys held by the owners and/or
users (e.g., stored in corresponding ones of client devices 102,
104, and/or 106 and accessible to executable application programs)
may enable the owners and/or users to access the encrypted list of
triggering events maintained within the hybrid block-chain ledger.
The owners and/or user may, through corresponding client devices,
view the individual events that, when detected by system 140, could
cause system 140 to perform operations that recover, authorize,
audit, and/or verify the transaction and/or ownership data included
within the hybrid block-chain ledger (e.g., associated with
corresponding portions of the tracked assets).
[0082] One or more computing components of system 140 may perform
operations that modify portions of the stored rules and/or list of
triggering events, e.g., in response to changes in regulations
and/or policies, in response to additional owner input, etc. In
order to access and modify the generated rules engine (and/or the
list of triggering events) maintained within the hybrid block-chain
ledger, system 140 may leverage the stored master cryptographic key
to access and modify the hashed and encrypted rules engine. System
140 may encrypt and re-hash the modified rules engine and submit
the encrypted and hashed modified rules engine to one or more of
peer systems 160 for inclusion in a block of the hybrid block-chain
ledger. For example, one or more of peer systems 160 may
incorporate the hashed and encrypted modified rules engine into the
hybrid block-chain ledger as a special transaction (e.g., a "0"
value transaction), such that the hybrid block-chain ledger tracks
each change within the modified rules engine.
[0083] FIG. 3 is a schematic diagram illustrating an exemplary
structure 300 of a hybrid, public-private block-chain ledger, which
may be generated through the interaction of components of computing
environment 100 in accordance with various embodiments. For
example, as described with reference to FIG. 3, users 108, 110, and
112 may be associated with corresponding devices (e.g., client
devices 102, 104, and 106), which may be configured to execute one
or more stored software applications (e.g., a wallet application)
capable of obtaining a current version of a hybrid block-chain
ledger from one or more networked computer systems (e.g., one of
peer systems 160 configured to "mine" broadcast transactions and
update ledgers).
[0084] A system associated with a centralized authority (e.g.,
system 140 associated with business entity 150) may generate a
rules engine that regulates transactions involving the assets
tracked by the hybrid block-chain ledger (e.g., distributions,
transfers of ownership, other actions, etc.) and a list of
triggering events that, upon detection by system 140, trigger an
initiation of one or more of the distributions, transfers, and/or
other actions regulated by the generated rules engine. System 140
may generate a master encryption key (e.g., master key 301 of FIG.
3), which may be maintained in a portion of data repository 144,
and may generate additional private "crypto" keys 302A and 302B,
which may be associated with corresponding ones of users 108 and
110 In some aspects, system 140 may maintain private crypto keys
302A, 302B, and 302C in a portion of data repository 144 and
provide private crypto keys 302A, 302B, and 302C to users 108, 110,
and 112 through secure, out-of-band communications. System 140 may
encrypt the generated rules engine and the generated list of
triggering events, and may perform operations that hash the
encrypted rules engine and list of triggering events into a genesis
block of the hybrid block-chain ledger (e.g., genesis block
304).
[0085] One of the users (e.g., user 108) may own and/or control a
portion of the tracked assets. For example, a device associated
with user 108 (e.g., client device 102) may execute a stored
software application (e.g., a wallet application) capable of
obtaining a current version of a hybrid block-chain ledger,
including genesis block 304, from one or more networked computer
systems (e.g., one of peer systems 160 configured to "mine"
broadcast transactions and update ledgers). The current version of
a hybrid block-chain ledger may represent a "longest" block-chain
ledger than includes a maximum number of discrete "blocks," which
may identify transactions that transfer, distribute, etc., portions
of tracked assets among various owners, including user 108.
[0086] For example, client device 102 may obtain the current hybrid
block-chain ledger and process the hybrid block-chain ledger to
determine that a prior owner transferred ownership of a portion of
the tracked assets to user 108 in a corresponding transaction
(e.g., transaction 306, schematically illustrated in FIG. 3). One
or more of peer systems 160 may have previously verified,
processed, and packed data associated with transaction 306, which
may be in a corresponding block of the block-chain.
[0087] As illustrated in FIG. 3, data specifying transaction 306
may include input data that references one or more prior
transactions (e.g., transactions that transferred ownership of the
tracked asset portion to the prior owner), and further, output data
that includes instructions for transferring the tracked asset
portion to user 108. For example, input data in accordance with
various embodiments may include a cryptographic hash of the one or
more prior transactions (e.g., hash 306A), and output data in
accordance with various embodiments may include a quantity or
number of units of the tracked asset portion that are subject to
transfer in transaction 302 and a public key 306B of user 108
(i.e., the recipient of the tracked asset portion transferred in
transaction 306). Further, in some aspects, the transaction data
may include a digital signature 306C of the prior owner, which may
be applied to hash 306A and public key 306B using a private key of
the prior owner through any of a number of techniques apparent to
one of skill in the art and appropriate to the block-chain ledger
architecture.
[0088] Further, and in contrast to the conventional block-chain
ledger architectures described above, transaction 306 may also
include encrypted and/or hashed copies of rules engine 320 and
trigger event list 322. A device of the prior owner (e.g., which
may execute one or more software applications) may access genesis
block 304 (e.g., from the current version of the hybrid block-chain
ledger obtained from one or more of peer systems 160), may parse
genesis block 304, and may extract copies of the encrypted and/or
hashed rules engine 324 and trigger event list 322. The prior
owner's device may transmit to one or more of peer systems 160 the
hash 306A, public key 306B, and digital signature 306C for
verification, processing (e.g., additional cryptographic hashing)
and inclusion into a new block of the hybrid block-chain ledger. In
an embodiment, user 108 may elect to further transfer that tracked
asset portion to an additional user (e.g., user 110). For example,
the one or more software applications executed by client device 102
may cause client device 102 to perform operations that generate
input and output data specifying a new transaction (e.g.,
transaction 308 of FIG. 3) that transfers ownership of the tracked
asset portion from user 108 to user 110, and further, that transmit
the generated data to one or more of peer systems 160 for
verification, processing (e.g., additional cryptographic hashing)
and inclusion into a new block of the hybrid block-chain
ledger.
[0089] For example, data specifying transaction 308 may include a
cryptographic hash 308A of prior transaction 306, a quantity or
number of units of the tracked asset portion that are subject to
transfer in transaction 308, and a public key of the recipient
(e.g., public key 308B of user 110). The data specifying
transaction 308 may include a digital signature 308C of the user
108, which may be applied to hash 308A and public key 308B using a
private key 308D of user 108. The presence of user 108's public key
within transaction data included within the conventional
block-chain ledger may enable various devices and systems (e.g.,
client devices 102, 104, and/or 106, peer systems 160, etc.) to
verify user 108's digital signature 308C, as applied to data
specifying transaction 308.
[0090] Client device 102 may also parse data specifying prior
transaction 306 (e.g., as obtained from the current version of the
hybrid block-chain ledger) and extract encrypted and/or hashed
copies of rules engine 324 and trigger event list 322. Client
device 102 may append the encrypted and/or hashed copies of rules
engine 324 and trigger event list 322 to the data specifying
transaction 308 (e.g., cryptographic hash 308A, public key 308B,
and digital signature 308C), and transmit the data specifying
transaction 308B to one or more of peer systems 160 for
verification, processing (e.g., additional cryptographic hashing)
and inclusion into a new block of the hybrid block-chain
ledger.
[0091] Private crypto key 302A may enable client device 102 (e.g.,
associated with user 108) to access encrypted event trigger list
322 upon extraction from the hybrid block-chain ledger. In some
embodiments, private crypto key 302A provides client device 102
with read-only access to the encrypted event trigger list 322.
Client device 102 may obtain private crypto key 302A from system
140 using secured out-of-band communications or as input provided
by user 108 through a web page or other graphical user interface
(GUI) presented by client device 104.
[0092] Ownership of the tracked asset portion may be transferred
from user 108 to user 110 upon verification and publication of the
data specifying transaction 308 within a corresponding block of the
hybrid block-chain ledger by peer systems 160. User 110 may elect
to further transfer that tracked asset portion to yet another user
(e.g., user 112). For example, the one or more software
applications executed by client device 104 may cause client device
104 to perform operations that generate input and output data
specifying a new transaction (e.g., transaction 310 of FIG. 3) that
transfers ownership of the tracked asset portion from user 110 to
user 112, and that transmit the generated data to one or more of
peer systems 160 for verification, processing (e.g., additional
cryptographic hashing) and inclusion into a new block of the hybrid
block-chain ledger.
[0093] Data specifying transaction 310 may include a cryptographic
hash 310A of prior transaction 308, a quantity or number of units
of the tracked asset portion that are subject to transfer in
transaction 310, and a public key 310B of user 112. The data
specifying transaction 310 may include a digital signature 310C of
the user 110, which may be applied to hash 310A and public key 310B
using a private key 310D of user 110. The presence of user 110's
public key 308B within transaction data included within the hybrid
block-chain ledger may enable various devices and systems (e.g.,
client devices 102, 104, and/or 106, peer systems 160, etc.) to
verify user 110's digital signature 310C, as applied to data
specifying transaction 310.
[0094] Client device 104 may also parse data specifying prior
transaction 308 (e.g., as obtained from the current version of the
hybrid block-chain ledger) and extract encrypted and/or hashed
copies of rules engine 324 and trigger event list 322. Client
device 104 may append the encrypted and/or hashed copies of rules
engine 324 and trigger event list 322 to the data specifying
transaction 310 (e.g., cryptographic hash 310A, public key 310B,
and digital signature 310C), and transmit the data specifying
transaction 310 to one or more of peer systems 160 for
verification, processing (e.g., additional cryptographic hashing)
and inclusion into a new block of the hybrid block-chain ledger.
Ownership of the tracked asset portion may be transferred from user
110 to user 112 upon verification and publication of the data
specifying transaction 310 within a corresponding block of the
hybrid block-chain ledger by peer systems 160.
[0095] Private crypto key 302B may enable client device 104 (e.g.,
associated with user 110) to decrypt event trigger list 322 upon
extraction from the hybrid block-chain ledger. Client device 104
may obtain private crypto key 302B from system 140 using secured
out-of-band communications, and additionally or alternatively, as
input provided by user 110 through a web page or other graphical
user interface (GUI) presented by client device 104. Client device
104 may identify and extract private crypto key 302B from a portion
of the hybrid block-chain ledger obtained from peer systems 160
(e.g., as a secure in-band communication).
[0096] In the embodiments described above, system 140 may establish
and maintain rules (e.g., through a rules engine and corresponding
list of triggering events) that facilitate regulatory-based,
policy-based, and/or customer-specified controls of transactions
involving assets tracked within a hybrid block-chain ledger. For
example, client devices 102, 104, and/or 106 may generate
transaction data that includes a rules engine and list of
triggering events, and one or more of peer systems 160 may embed
the generated transaction data into blocks of the hybrid
block-chain ledger for reference in subsequent transactions. System
140 may be configured to detect an occurrence of an event (e.g.,
based on data received from client devices 102, 104, and/or 106,
etc.), may determine whether the list of triggering events includes
the detected event, and when triggering event list includes the
detected event, perform one or more operations consistent with an
established rule that references the detected event, as described
below with reference to FIG. 4.
[0097] FIG. 4 is a flowchart of a process 400 for automatically
performing event-based operations on assets tracked within a hybrid
block-chain ledger in accordance with some embodiments. In an
embodiment, a centralized authority may be assigned to establish
regulatory-based, policy-based, and/or customer-specified control
over assets tracked within the hybrid block-chain ledger. In some
aspects, tracked assets in accordance with various embodiments may
include units of a virtual currency or a crypto-currency, units of
financial instruments held by one or more owners, and physical
assets utilized by one or more individuals and/or entities. In some
aspects, a computer system associated with the centralized
authority (e.g., system 140 associated with business entity 150)
may execute one more stored application programs to cause system
140 to recover, authorize, audit, and/or verify an ownership of at
least a portion of the tracked assets and/or transactions involving
the tracked assets based on established and maintained rules.
[0098] One or more computing components of system 140 may generate
cryptographic keys that facilitate the exemplary regulation of
transactions (e.g., distributions, transfers, and/or actions)
involving assets tracked within the hybrid public-private ledger
(e.g., in step 404). For example, in step 402, system 140 generates
a master cryptographic key with which system 140 may encrypt the
generated and stored rules engine. In some aspects, certain
aspects, system 140 may store copies of the generated master key in
a portion of data repository 144 that is not accessible to user 110
(and any other users), thus maintaining confidence in the generated
master key.
[0099] In step 402, system 140 may also perform operations that
generate and maintain additional private cryptographic keys (e.g.,
private "crypto" keys) associated with each user who may be an
owner of the assets tracked within the hybrid block-chain ledger.
The generated private crypto keys may enable a device of each user
to decrypt and access the list of triggering events and
additionally or alternatively, metadata identifying the centralized
authority. System 140 may store copies of the generated private
crypto keys in a portion of data repository 144. Furthermore,
system 140 may also perform operations that provide corresponding
ones of the private crypto keys to users 108, 110, and/or 112
through secure, non-accessible and/or out-of-band
communications.
[0100] One or more computing components of system 140 may generate
a rules engine and a list of triggering events, which may be stored
within a portion of data repository 144 (e.g., in step 404). For
example, the generated and stored rules engine may identify one or
more rules that regulate a distribution of the tracked assets, an
initiation of one or more transactions involving the tracked assets
(e.g., a sale, a use of the tracked assets as collateral in a
secured transaction etc.), and further, any additional or alternate
action involving the tracked assets and/or the hybrid
public-private ledger (e.g., processes that generate additional
cryptographic key sets for user 110, processes that recover assets
tracked in the hybrid public-private ledger, etc.). The generated
and stored list of triggering events may include information that
specifies causal relationships between one or more of the
established rules and one or more events that trigger an initiation
of one or more corresponding regulated distributions, transfers,
and/or actions involving assets tracked within the hybrid
public-private ledger (e.g., the triggering events).
[0101] System 140 may establish, in step 404, one or more of the
rules and/or triggering events to reflect regulations and/or
policies promulgated by governmental entity, a financial regulator,
and/or the centralized authority. For example, system 140 may
establish a loss of a private key by user 110 as a "triggering
event" that would cause system 140 to perform operations that
generate a new pair of public and private block-chain keys for user
110 in response to a verification of particular authentication
credentials. System 140 may deem a documented theft of a portion of
the tracked assets a "triggering event" that would cause system 140
to perform operations to recover the stolen portion of the tracked
assets and generate a new pair of public and private block-chain
keys for user 110.
[0102] System 140 may establish, in step 404, one or more of the
rules and/or triggering events based on information received from
user 110 (e.g., as input provided to a web page or other graphical
user interface (GUI) presented by client device 104 and provided to
system 140). For example, user 110 may specify a particular
distribution of tracked assets (e.g., recurring bill payments,
etc.) in response to an accident that may occur in the future
involving user 110 and/or user 110's death (e.g., triggering
events). Various embodiments are, however, not limited to these
exemplary triggering events and corresponding rules, and in further
embodiments, system 140 may establish any additional or alternate
rules and/or triggering events appropriate to the tracked assets,
to business entity 150, and further, to users 108, 110, and
112.
[0103] In step 406, system 140 may perform operations that encrypt
the generated and stored rules engine (e.g., using the master
encryption key) and further, that encrypt the generated and stored
list of triggering events (e.g., using any technique that
facilitates decryption using the private crypto keys). For example,
system 140 may perform operations in step 406 that hash the
encrypted rules engine and list of triggering events into a genesis
block of the hybrid block-chain ledger, the contents of which may
be incorporated (e.g., by client devices 102, 104, and/or 106, peer
systems 160, etc.) into each of the subsequent transaction blocks
generated and appended to the hybrid block-chain ledger. By
incorporating the hashed and encrypted rules engine and list of
triggering events into the blocks of the hybrid block-chain ledger,
various embodiments may ensure that the established rules are
followed even in an event of actions by malicious parties that
disrupt the tracked assets (e.g., instances of Bitcoin.TM. peeling,
etc.).
[0104] In some embodiments, one or more computing components of
system 140 may detect an occurrence of an event involving a portion
of the tracked assets, an owner of a portion of the tracked assets,
and/or a transaction involving a portion of the detected assets
(e.g., in step 408). For example, system 140 may receive data from
client device 104 that indicates user 110 lost a corresponding
private block-chain key associated with a portion of the tracked
assets. In other instances, system 140 may detect an event in step
140 based on data received across network 120 from one or more
systems associated with local, state, and/or federal governmental
entities (e.g., data from a law enforcement system notifying
business entity 150 of a theft of a portion of the tracked assets,
data from a local government confirming a death of an owner of a
portion of the tracked assets, etc.). In additional instances,
system 140 may detect an occurrence of an event based on one or
more sensors and devices communicatively connected to network 120
and capable of transmitting data to system 140. Various embodiments
are, however, not limited to these exemplary events, and in further
embodiments, system 140 may be configured to detect any additional
or alternate event appropriate to the tracked assets and to the
components of computing environment 100.
[0105] System 140 may also be configured to access the stored list
of triggering events (e.g., within database 144), and may determine
whether the list of triggering events includes the detected event
(e.g., in step 410). If system 140 identifies the detected event as
being within the list of triggering events (e.g., step 410; YES),
system 140 may establish the detected event as a triggering event,
and may access the encrypted rules engine using the master
encryption key (e.g., in step 412). System 140 may further
identify, within the accessed rules engine, one or more of the
established rules that are causally related to the detected
triggering event (e.g., in step 414). Further, system 140 may be
configured to perform one or more operations, either individually
or in sequence, that are consistent with the identified rules
(e.g., in step 416). For example, the accessed rules engine may
include information identifying the one or more operations
associated with the identified rules. In other instances, at least
one of the performed operations may represent a default operation
associated with the identified rules (e.g., a specific type of
authentication required before performing the one or more
operations on behalf of user 110).
[0106] In one embodiment, one or more computing components of
system 140 may also determine whether to update portions of the
generated rules engine and/or list of triggering events (e.g., in
step 418). For example, system 140 may identify an update or
modification to one or more regulations and/or policies promulgated
by governmental entity, a financial regulator, and/or the
centralized authority. In other instances, system 140 may obtain,
from client device 104, information updating a rule and/or
triggering event previously established by system 140 based on
input received from user 110 (e.g., through a web page and/or GUI
presented by client device 104).
[0107] If system 140 determines to update portions of the generated
rules engine and/or list of triggering events (e.g., step 418;
YES), system 140 may access appropriate portions of the rules
engine and/or list or triggering events in step 420 (e.g., using
the master encryption key), and may modify the appropriate portions
of the rules engine and/or list of triggering events to reflect the
updated regulations, policies, user-specified rules, and/or
user-specified events (e.g., in step 422). In some instances,
system 140 may modify the accessed rules engine by adding a new
rule, deleting an existing rule, modifying one or more parameters
of an existing rule, and/or modifying one or more operations
associated with an existing rule. In other instances, system 140
may modify the accessed list of event triggers to add a new
triggering event, delete an existing triggering event, and/or add
or modify parameters associated with an existing triggering
event.
[0108] System 140 may encrypt and re-hash the modified rules engine
and/or list of triggering events, and may submit the encrypted and
hashed modified rules engine and/or list of triggering events to
one or more of peer systems 160 for inclusion in a block of the
hybrid block-chain ledger (e.g., in step 424). For example, one or
more of peer systems 160 may incorporate the hashed and encrypted
modified rules engine and/or list of triggering events into the
hybrid block-chain ledger as a special transaction (e.g., a "0"
value transaction), such that the hybrid block-chain ledger tracks
each change within the modified rules engine and/or list of
triggering events. Exemplary process 400 is then complete in step
426.
[0109] Referring back to step 418, if system 140 determines that no
modification to the rules engine and/or the list of triggering
events is warranted (e.g., step 418; NO), exemplary process 400 may
proceed to step 426, and exemplary process 400 is complete.
Further, and in reference to step 410, if system 140 determines
that the list of triggering events does not include the detected
event (e.g., step 410; NO), exemplary process 400 may proceed to
step 418, and system 140 may determine whether to update portions
of the rules engine and/or list of triggering events using any of
the exemplary processes described above.
[0110] In the embodiments described above, and through the
generation of the master cryptographic key and management of the
generated rules engine and corresponding list of triggering events,
system 140 may perform operations that recover, authorize, audit,
and/or verify an ownership of at least a portion of the tracked
assets and/or transactions involving the tracked assets. The
operations performed by system 140, which utilize hybrid
block-chain ledgers in accordance with various embodiments, would
not be possible using the conventional block-chain ledgers
described above.
[0111] For example, user 110 may be a user of a virtual or
crypto-currency (e.g., Bitcoin.TM.) and may store a private key
(e.g., private key 310D) on a laptop computer (e.g., client device
104) to generate and confirm Bitcoin.TM. transactions. In one
instance, user 110 may unfortunately drop the laptop into a
swimming pool while confirming a Bitcoin.TM. with private key 310D,
and upon retrieval from the swimming pool, user 110 may establish
that the laptop no longer functions and that data on the laptop is
not recoverable.
[0112] Traditionally, through a device in communication with
network 120 (e.g., user 110's smartphone), user 110 may access a
conventional block-chain ledger, such as those conventional
architectures outlined above, and determine that the Bitcoin.TM.
transfer was incomplete when user 110 dropped the laptop into the
swimming pool. Further, user 110 may determine that the Bitcoin.TM.
transaction represents an orphaned block within the conventional
block-chain ledger, and the Bitcoins.TM. associated with the
orphaned block are unrecoverable and permanently lost.
[0113] In some embodiments, user 110 may access a hybrid
block-chain ledger (e.g., as described with reference to FIG. 3),
and may determine that the Bitcoin.TM. transfer was incomplete when
user 110 dropped the laptop into the swimming pool. In some
embodiments, however, user 110 may provide input to the smartphone
identifying the unrecoverable private key, which the smartphone may
transmit to system 140 across network 120. In some aspects, system
140 may receive the transmitted message (e.g., in step 408), may
determine that user 110's loss of private key 310D represents a
triggering event (e.g., step 410; YES), and may perform operations
that authenticate user 110's identity and that regenerate a pair of
private and public block-chain keys for user 110, which system 140
may transmit to user 110 through any of the secure non-accessible
processes outlined above (e.g., in steps 412, 414, and 416). Upon
receipt of the newly generated private key, user 110 may access the
hybrid block-chain ledger (e.g., through the smartphone) and
confirm the Bitcoin.TM. transfer to recover the
crypto-currency.
[0114] Further, and by way of example, user 110 may access a wallet
application executed by client device 104, and further, may
determine that the mobile wallet is missing a number Bitcoins.TM..
User 110 may suspect that the loss of the Bitcoins.TM. represents a
theft by a malicious entity, and through a complex search of a
corresponding block-chain ledger (e.g., conventional block-chain
ledgers described above, and/or hybrid block-chain ledgers in
accordance with various embodiments), user 110 may trace the theft
of the Bitcoins.TM. to a single transaction within a corresponding
block. User 110 may contact the police and report the theft, and
the police may confirm the accuracy of user 110's allegations
regarding the theft.
[0115] User 110 may, in some instances, be capable of processing
the conventional block-chain ledgers described above to determine
an address of the malicious entity responsible for the theft. The
decentralized and anonymous nature of conventional block-chain
ledgers may, however, prevent user 110 from identifying the
malicious entity, and the stolen Bitcoins.TM. may remain
permanently unrecoverable.
[0116] Various embodiments may, however, address the deficiencies
of conventional block-chain ledgers and provide user 110 with
recourse to recover the stolen Bitcoins.TM.. For example, the
police may notify the centralized authority of the theft of user
110's Bitcoins.TM. and provide a destination address associated
with the malicious entity (e.g., through a message transmitted to
system 140 and received, e.g., in step 408). System 140 may
determine that the theft of the Bitcoins.TM. represents a
triggering event included within the generated list (e.g., step
410; YES), and may perform operations that automatically create a
request for a new transaction that returns the stolen Bitcoins.TM.
to user 110 using any of the exemplary techniques described above
(e.g., in steps 412, 414, and 416). System 140 may also perform
operations that regenerate a pair of private and public block-chain
keys for user 110, which system 140 may transmit to user 110
through any of the secure non-accessible processes outlined above
(e.g., in steps 412, 414, and 416).
[0117] The hybrid block-chain ledger architectures described above
may add a level of sophistication to conventional mechanisms for
trustless communication by allowing transactions involving tracked
assets to occur according to common transaction rules. Further, the
hybrid block-chain ledger architectures in accordance with various
embodiments may allow owners of the tracked assets to project
authority over the tracked assets by establishing customized rules
for transaction authorization. Furthermore, and in contrast to
conventional techniques described above, the hybrid block-chain
ledger architecture may enable a centralized authority (e.g.,
business entity 150 associated with system 140) to recover,
authorize, audit, and/or verify an ownership of at least a portion
of the tracked assets and/or transactions involving the tracked
assets based on established and maintained rules.
[0118] In various embodiments, through the generation of a master
cryptographic key and management of a generated rules engine and
corresponding list of triggering events, system 140, acting as a
centralized authority, may perform operations that recover,
authorize, audit, and/or verify an ownership of at least a portion
of the tracked assets and/or transactions involving the tracked
assets. In some aspects, and as outlined above, tracked assets in
accordance with various embodiments may include units of a virtual
currency or a crypto-currency, units of financial instruments held
by one or more owners, and physical assets utilized by one or more
individuals and/or entities.
[0119] In additional aspects, the exemplary hybrid block-chain
algorithms described above may track a location, performance,
usage, and/or status of one or more additional client devices
(referred to as "connected devices") disposed within computing
environment 100 (not shown in FIG. 1), which may be configured to
establish communications with client devices 102, 104, and 106, and
further, with system 140, using any of the communications protocols
outlined above. For example, client devices 102, 104, and 106,
system 140, and the connected devices may be uniquely identifiable
and addressable within communications network 120, and may be
capable of transmitting and/or receiving data across the
established communications sessions. System 140 may be configured
to establish the communications sessions with one or more of the
connected devices, and to exchange data with the connected devices
autonomously and without input or intervention from a user of
client device 104 (e.g., user 110).
[0120] In some aspects, the connected devices may be implemented as
a processor-based and or computer-based device that includes one or
more processors and tangible, computer-readable memories. For
example, connected devices in accordance with various embodiments
may include mobile communications devices (e.g., mobile telephones,
smart phones, tablet computers, etc.) and other devices capable of
communicating with client device 104 (e.g., internet-ready
televisions, internet-ready appliances and lighting fixtures,
computing devices disposed within motor vehicles, etc.).
[0121] The connected devices may include sensor devices in
communication with the one or more processors and the memories. The
sensor devices may be configured to monitor the usage, location,
status, etc., of corresponding ones of the connected devices, and
may be configured to provide sensor data to corresponding ones of
the processors. In some aspects, the sensor data may include data
identifying a current state, data specifying intended and/or
unintended interaction with one or more of users 108, 110, and/or
112 (e.g., through client devices 102, 104, and/or 106),
inadvertent interactions (e.g., drops, other accidental
interactions, etc.), and data describing any additional or
alternate characteristics of the connected devices capable of being
monitored and quantified by the sensor devices.
[0122] Computing environment 100 may include one or more additional
computing systems in communication with the connected devices using
any of the communications protocols outlined above. In some
embodiments, the additional computing system include one or more
sensor devices capable of monitoring a location, performance,
usage, and/or status of the connected devices, which may establish
a "sensor network" capable of monitoring the connected devices.
These additional computing systems may provide the additional
sensor data to the connected devices using any of the
communications protocols outlined above, either a regular intervals
or in response to requests from the connected devices. In some
instances, the additional computing systems may be implemented as
processor-based and/or computer-based systems consistent with the
exemplary systems described above.
[0123] The connected devices may be configured to transmit portions
of the sensor data (e.g., as detected by on-board sensor devices
and/or received from the sensor network) to client devices 102,
104, and/or 106 and additionally or alternatively, to system 140,
using any of the communications protocols outlined above. For
example, the sensor data may characterize an interaction between
the connected devices and users 108, 110, and 112 (e.g., the
monitored data may represent usage data indicative of a consumption
of one or more services provided by the connected devices), and the
connected devices may transmit the usage data for users 108, 110,
and/or 112 to corresponding ones of client devices 102, 104, and/or
106, which may store the received usage data in a corresponding
data repository. The connected devices may also transmit the usage
data to system 140, along with information linking specific
elements of the usage data to corresponding users and/or client
devices (e.g., user 110's usage data may be linked to an identifier
of user 110 and/or of client device 104). As described below in
reference to FIGS. 4 and 5, client devices 102, 104, and/or 108 may
also incorporate corresponding portions of the monitored data,
e.g., as received from the connected devices, into hybrid
block-chain ledgers in accordance with various embodiments in order
to record, track, and publicly monitor the location, performance,
usage, and/or status of the connected devices.
[0124] FIG. 5 is a schematic diagram illustrating an exemplary
structure 500 of a hybrid, public-private block-chain ledger, which
may be generated through the interaction of components of computing
environment 100, in accordance with various embodiments. For
example, as described in reference to FIG. 4, users 108, 110, and
112 may be associated with corresponding devices (e.g., client
devices 102, 104, and 106), which may be configured to execute one
or more stored software applications (e.g., a wallet application)
capable of obtaining a current version of a hybrid block-chain
ledger from one or more networked computer systems (e.g., one of
peer systems 160 configured to "mine" broadcast transactions and
update ledgers).
[0125] Embodiments shown in FIG. 5 may incorporate the exemplary
hybrid block-chain ledger described above in reference to FIG. 3
(e.g., hybrid block-chain ledger structure 300), and may augment
hybrid block-chain ledger structure 300 to include and track
monitored data indicative of a location, performance, usage, and/or
status of one or more connected devices 502 disposed within
environment 100 and in communication with client devices 102, 104,
and 106. For example, connected devices 502 may be implemented as
processor-based and/or computer-based systems that include one or
more processors and corresponding tangible, non-transitory
computer-readable memories.
[0126] The one or more processors of connected devices 502 may
obtain sensor data from one or more on-board sensor devices capable
of monitoring connected devices 502 and additionally or
alternatively, from one or more external sensor devices disposed
within additional computing systems in communication with connected
devices 502. The on-board and external sensor devices may, in some
aspects, collectively form a sensor network 504 that generates and
provides sensor data to the connected devices. For instance, the
sensor data may include data identifying a current state, data
specifying intended and/or unintended interaction with one or more
of users 108, 110, and/or 112 (e.g., through client devices 102,
104, and/or 106), inadvertent interactions (e.g., drops, other
accidental interactions, etc.), and data describing any additional
or alternate characteristics of the connected devices capable of
being monitored and quantified by the sensor devices. The connected
devices may be configured to transmit portions of the received
sensor data to corresponding ones of client devices 102, 104, and
106, and to system 140, using any of the communications protocols
outlined above (e.g., through peer-to-peer communications,
etc.).
[0127] For example, the sensor data received by connected devices
502 may specify usage or consumption of one or more services of the
connected devices by corresponding ones of users 108, 110, and 112
(e.g., associated with client devices 102, 104, and 106). In some
aspects, portions of the usage data attributable to corresponding
ones of users 108, 110, and 112 may be transmitted to corresponding
ones of client devices 102, 104, and 106, and further, to system
140. The user-specific portions of the usage data may be stored
within corresponding user-specific usage data repositories (e.g.,
usage data repositories 506, 508, and/or 510 of FIG. 5). In some
embodiments, as described below in reference to FIG. 5, client
devices 102, 104, and/or 106, in conjunction with system 140, may
augment the exemplary hybrid block-chain ledger structures
described above to include usage data and corresponding metadata,
thus enabling the hybrid block-chain ledger to monitor the
location, performance, usage, and/or status of the connected
devices over time (e.g., during transfers in ownership of the
connected devices, use of the connected devices as collateral,
etc.).
[0128] FIG. 6 is a schematic diagram of illustrating an exemplary
structure 600 of a hybrid, public-private block-chain ledger, which
may be generated through the interaction of components of computing
environment 100, in accordance with various embodiments. For
example, as described in reference to FIG. 6, users 108, 110, and
112 may be associated with corresponding devices (e.g., client
devices 102, 104, and 106), which may be configured to execute one
or more stored software applications (e.g., a wallet application)
capable of obtaining a current version of a hybrid block-chain
ledger from one or more networked computer systems (e.g., one of
peer systems 160 configured to "mine" broadcast transactions and
update ledgers).
[0129] Some embodiments shown in FIG. 5 may incorporate the
exemplary hybrid block-chain ledger described above in reference to
FIGS. 3 and 5 (e.g., hybrid block-chain ledger structures 300 and
400), and may augment hybrid block-chain ledger structure 300 of
FIG. 3 to include and track monitored data indicative of a
location, performance, usage, and/or status of one or more
connected devices 502 disposed within environment 100 and in
communication with client devices 102, 104, and 106, as received
from sensor network 404.
[0130] A prior owner (e.g., user 108) may elect to further transfer
a portion of tracked assets to an additional user (e.g., user 110).
For example, the one or more software applications executed by
client device 102 may cause client device 102 to perform operations
that generate input and output data specifying a new transaction
(e.g., transaction 308 of FIG. 6) that transfers ownership of the
tracked asset portion from user 108 to user 110, and further, that
transmit the generated data to one or more of peer systems 160 for
verification, processing (e.g., additional cryptographic hashing)
and inclusion into a new block of the hybrid block-chain
ledger.
[0131] For example, data specifying transaction 308 may include a
cryptographic hash 308A of a prior transaction (e.g., which
transferred ownership to user 108), a quantity or number of units
of the tracked asset portion that are subject to transfer in
transaction 308, and a public key of the recipient (e.g., public
key 308B of user 110). Further, in some aspects, the data
specifying transaction 308 may include a digital signature 308C of
the user 108, which may be applied to hash 308A and public key 308B
using a private key 308D of user 108. The presence of user 108's
public key within transaction data included within the conventional
block-chain ledger may enable various devices and systems (e.g.,
client devices 102, 104, and/or 106, peer systems 160, etc.) to
verify the user 108's digital signature 308C, as applied to data
specifying transaction 308. Client device 104 may also parse data
specifying the prior transaction and extract encrypted and/or
hashed copies of rules engine 324 and trigger event list 322.
[0132] The data specifying transaction 308 may also include user
108's usage data (e.g., as received from connected devices 502),
which may be encrypted using master key 301 (e.g., by array
controller encryption 604B) to generate an encrypted array 604A of
user 108's usage data. The data specifying transaction 308 may also
include metadata indicative of a duration of usage, time, date,
location, and/or other network connected devices in proximity,
which may be encrypted using private crypto key 302A of user 108
(e.g., by array controller encryption 602B) to generate an
encrypted array of metadata 602A.
[0133] Client device 102 may append the encrypted and/or hashed
copies of rules engine 324 and trigger event list 322 to the data
specifying transaction 308 (e.g., cryptographic hash 308A, public
key 308B, and digital signature 308C) and the usage data (e.g.,
encrypted arrays 602A and 604A from array controller encryption
602B and 604B), and transmit the data specifying transaction 308 to
one or more of peer systems 160 for verification, processing (e.g.,
additional cryptographic hashing) and inclusion into a new block of
the hybrid block-chain ledger.
[0134] User 110 may elect to further transfer that tracked asset
portion to yet another user (e.g., user 112). For example, the one
or more software applications executed by client device 104 may
cause client device 104 to perform operations that generate input
and output data specifying a new transaction (e.g., transaction 310
of FIG. 6) that transfers ownership of the tracked asset portion
from user 110 to user 112, and further, that transmit the generated
data to one or more of peer systems 160 for verification,
processing (e.g., additional cryptographic hashing) and inclusion
into a new block of the hybrid block-chain ledger.
[0135] Data specifying transaction 310 may include a cryptographic
hash 310A of prior transaction 308, a quantity or number of units
of the tracked asset portion that are subject to transfer in
transaction 310, and a public key 310B of user 112. Further, in
some aspects, the data specifying transaction 310 may include a
digital signature 310C of user 110, which may be applied to hash
310A and public key 310B using a private key 310D of user 110. The
presence of user 110's public key 308B within transaction data
included within the hybrid block-chain ledger may enable various
devices and systems (e.g., client devices 102, 104, and/or 106,
peer systems 160, etc.) to verify user 110's digital signature
310C, as applied to data specifying transaction 310.
[0136] Data specifying transaction 310 may also include user 110's
usage data (e.g., as received from connected devices 402), which
may be encrypted using master key 301 (e.g., by array controller
encryption 614B) to generate an encrypted array 614A of user 108's
usage data. The data specifying transaction 308 may also include
metadata indicative of a duration of usage, time, date, location,
and/or other network connected devices in proximity, which may be
encrypted using user 110's private crypto key 302A (e.g., by array
controller encryption 612B) to generate an encrypted array of
metadata 612A.
[0137] Client device 104 may append the encrypted and/or hashed
copies of rules engine 322 and trigger event list 324 to the data
specifying transaction 310 (e.g., cryptographic hash 310A, public
key 310B, and digital signature 310C) and the usage data (e.g.,
encrypted arrays 612A and 614A from array controller encryption
612B and 614B), and transmit the data specifying transaction 310 to
one or more of peer systems 160 for verification, processing (e.g.,
additional cryptographic hashing) and inclusion into a new block of
the hybrid block-chain ledger.
[0138] The inclusion of usage data within hybrid block-chain
ledgers maintains a continuous log of usage and/or consumption of
connected-device resources by users 108, 110, and 112, and any
additional or alternate users that generate and submit (through
corresponding client devices) transaction data to one or more of
peer systems 160. The sensor data (e.g., as received from connected
devices 502) may be batched in a periodic set and treated as a
transaction, and may be appended into an associated repository of
the transaction block-chain (e.g., using system 140, peer systems
160, etc.).
[0139] The exemplary block-chain ledgers described above may
facilitate processes that track an ownership of one or more of the
connected devices and enable current owners (e.g., user 110) to
transfer ownership to others (e.g., user 112). For example, when a
new block is created to account for usage data, a private key of
the current owner may be used to authenticate the usage and allow
for the generation of the new block. A private key linked to a
device of the current owner (e.g., stored locally on a memory of
the current owner's device) may authenticate the usage and allow
for the generation of the new block without input or intervention
from the current owner. In some instances, the private key of the
current owner's device may differ from the current owner's private
key. The automated and programmed authentication of the usage by
the current owner's device may reduce instances of under-reported
usage data associated with owner-initiated authentication
protocols.
[0140] Exemplary Use Cases for Hybrid Private-Public Ledgers
[0141] Behavior Tracking Using Connected Devices
[0142] Various embodiments may enable a business entity 150 (e.g.,
a financial institution) to track users' behavior and their ability
to "care for" and/or "keep in good maintenance" one or more owned
items (e.g., connected devices, such as cars, clothing, and
appliances) and/or one or more financial obligations (e.g., timely
monthly mortgage payments, timely payments of credit card bills, no
overdrafts, etc.). For example, business entity 150 may, through
system 140, monitor and collect user 110's historical behavior data
in order to determine a "care score," which may factor into a
credit adjudication process for user 110. For example, when system
140 accesses a block-chain repository to determine user 110's "care
score,", system 140 may decrypt the current version of the hybrid
block-chain ledger using the master key, and determine a score for
either a specific category of products or an overall score based on
the sensor data. System 140 may establish the "care rating" for
user 110 based on the determined score. Further, various
embodiments may maintain a record of corresponding usage data
(e.g., within the disclosed exemplary hybrid block-chain ledgers)
and adjust a deprecation value, which system 140 may store along
with a unique identifier value as a key value pair.
[0143] Various embodiments also facilitate processes that group
subsets of connected devices (e.g., various office equipment),
track a usage of these connected devices as a group, and aggregate
the above-described calculations for the group of connected
devices. In some aspects, the tracking and manipulation of group
usage data may balance out the heavy use of a singular item with
items which are used infrequently.
[0144] Each of connected devices 502 may provide data indicative of
usage, care, maintenance, and repayments to a centralized server
(e.g., a server of system 140), which may perform operations that
update a creditworthiness of an owner based on the predicted life
of connected devices 502 and risk exposures (e.g., for purposes of
providing insurance) in real time. Various embodiments may, for
example, reward good behavior from an individual with rewards of
better terms and/or penalize poor behavior, and thus customizing
both load and insurance product to the individual.
[0145] For example, office equipment and a company car of a
business owner may represent "connected devices," and various
embodiments may monitor usage of the connected devices based on
embedded sensors and/or a surrounding network of sensors disposed
within in the environment. In some aspects, portions of the office
equipment may be used infrequently (e.g., as most of the business
is off premises), and system 140 may establish, based on the usage
data, that the office equipment experiences a relatively low level
of depreciation, while the company car experiences a substantial
amount of depreciation. In accordance with various embodiments,
system 140 may assign a "medium" deprecation rating to the
collective group of connected devices (e.g., the office equipment
and the company car) based on the usage data, and system 140 may
leverage this information when the business owner attempts to
collateralize these connected devices, e.g., in support of a loan
application.
[0146] Ownership Tracking of Connected Devices and Payment
[0147] Additionally, conventional block-chain ledgers are often
inadequate to track a partial ownership of various assets, as
ownership rights and agreements change over the course of time.
Moreover, actual cosigners of loans or accounts may experience
difficulty in establishing their own individual responsibility in
the instances of partially owned assets.
[0148] Hybrid block-chain ledgers in accordance with various
embodiments may, in some aspects, provide a shared ledger payment
mechanism that, at the time of purchase settlement, assigns
ownership to a purchased item by making a connection to the item
and embedding the item with an unique owner identifier, timestamp
and purchase value. If there is split ownership of the item,
various embodiments may record the multiple owners as a value pair
and register corresponding percentages of ownership. Various
embodiments may further complete registration of the purchased item
within the hybrid block-chain ledger, which tracks the ownership
and allows the system and/or devices to periodically check-in with
the ledger system to maintain a corresponding ownership record.
[0149] By tracking partial ownership of assets, hybrid block-chain
ledgers in accordance with various embodiments allow for real-time
tracking of individual contributions spread over the entire
ownership structure. The real-time tracking provided by various
embodiments may be useful in partial ownership situations with
complex disbursement schemes. For example, system 140 may perform
operations that automatically disburse profits according to the
ownership and/or disbursement arrangements and/or create new
genesis blocks based on the ownership instructions set forth within
event trigger list 322 and/or rules engine 324.
[0150] For instance, a husband and wife may jointly purchase car
for $10,000. Upon the completion of payment for the car, system 140
may determine that husband contributed 60% of the cost, and the
wife contributed 40% of the cost. In some aspects, rules engine 324
may include rules establishing joint ownership on the basis of the
proportional contributions of the husband and wife, and in the
event of divorce (e.g., a triggering event within event trigger
list 322), system 140 may distribute the ownership in accordance
with rules engine 324. Various embodiments are, however, not
limited to property settlements subsequent to divorce, and event
trigger list 322 and/or rules engine 324 may include additional
data that supports the disbursement of profits upon sales of items
and/or within a partnership.
[0151] Further, a startup company may exhibit a distributed
ownership structure including three co-founders and an investor
owner. Rules engine 324 may include an existing payment structure
rule that specifies a distribution of profits among the co-founders
and the investor. When the startup company is acquired or receives
funding, system 140 may detect a triggering event, and rules engine
322 proceeds to create a new ownership structure, and creating a
new genesis block.
[0152] Automated Ownership Transfers
[0153] Using conventional block-chain ledger systems, all entries
are made sequentially and are generated in a wide range of
applications, which can lead to delays in executing the
transactions. Many transactions, however, follow a standardized set
of rules based on events associated with the owner. In some
aspects, the disclosed hybrid block-chain ledgers may facilitate a
transfer of ownership of tracked assets in response to an
occurrence of a set of standardized events, thus expediting
disbursement and ownership transfers, and reducing the need for
protracted analysis of the ownership structures.
[0154] Various embodiments may track an ownership of connected
devices based on a unique identifier and periodic checks with a
network connection, which may be aggregated with associated data
(e.g., value, purchase time, usage duration, geo-location, etc.) to
form a connected asset inventory system. If items cannot
periodically check into the ownership network, system 140 may
prompt the customer to reconcile, or a public network may request
independent verification.
[0155] Various embodiments may also establish a number of
predetermined trigger conditions which, when triggered, execute the
sale or disbursement and re-allocation of ownership of items
registered with the connected asset inventory system. These
predetermined instructions may be stored on a ledger system, and
the event and completion of the disbursement may be validated by
the public "miners" (e.g., peer systems 160).
[0156] In some aspects, transactions related to ownership of a
particular property may be added to the exemplary hybrid
block-chain ledgers described above. System 140, acting on behalf
of the centralized authority (i.e., business entity 150) may
generate a genesis block in partnership with a
manufacturer/retailer at the time of purchase, and/or appends
information from a genesis block created by a manufacturer. System
140 may also generate a set of rules for ownership transfer based
on input from the individuals involved in the transfer, which may
be incorporated into the hybrid block chain ledger as a rules
engine (e.g., rules engine 324). Public portions of hybrid
block-chain ledgers in accordance with various embodiments may
verify a current status of ownership, and when a preset event or
criteria is reached (e.g., within event trigger list 322), system
140 performs operations that initiate a transfer of ownership of
the property based on the established rules, and the ownership
transfer is updated through the distributed network.
[0157] For instance, life insurance claims processes may proceed
upon a death of a family member and a receipt of an official
"certified" death certificate from a governmental entity (e.g.,
trigger events). Various embodiments may require that the ledger
"miners" of peer systems 160 validate the trigger events as well as
validate the completion of the "disbursement" or payment event.
[0158] During estate planning, various embodiments may "tag" or
track every asset that uses a network connection to generate and
create rules around automatic disbursements. Upon an event
trigger/confirmation (e.g., as specified in event trigger list
322), system 140 automatically puts into effects the rules created
by a customer (e.g., as stored within rules engine 324). The
automated transfer of ownership may, in some aspects, reduce the
workload of an executor and track all changes made to the event
triggers, which allows for greater clarity.
[0159] Processes for Tracking Earmarked Distributions
[0160] Many electronic funds transfers are earmarked for specific
uses and/or for specific purchases of certain types of products
(e.g., earmarked donations, child support, welfare, child's
allowance, some government grants, etc.). Using conventional
processes, it may be difficult to track and verify that the
allotted funds are used strictly on allowed purchases. Furthermore,
using conventional processes, an individual that provides funds may
rely on reports that the funds have been used appropriately, and
moreover, the appropriate use of funds may often be taken on
faith.
[0161] In various embodiments, a hybrid block-chain ledger can
create and enforce rules controlling transfer of earmarked funds,
thus providing a systematic mechanism for tracking and controlling
spending. For example, system 140 may establish (e.g., in rules
engine 324) a set of allowed transaction rules that enforce the set
of earmarks for particular funds.
[0162] In some aspects, these systems could be used in
international remittance, where funds are sent for specific uses.
If the transaction is earmarked for specific items and/or types of
items, the established rules may be incorporated into an encrypted
event trigger list and/or rules engine (e.g., by system 140) within
the transaction block sending the funds overseas. The recipient of
the fund will be able to review the trigger events that facilitate
a use of the particular funds. If the recipient attempts to use the
funds in a way that violates the transaction earmarks, the
transaction may be refused, and/or the provider of the fund may be
notified.
[0163] In some aspects, system 140 may establish rules within the
rules engine (e.g., rules engine 324) that allow compliant
transactions to proceed, while initiating a set of contingency
steps transactions outside of the earmarks. These steps may include
notifying the originating party, flagging the transaction, and/or
denying the transaction.
[0164] For example, a customer of business entity 150 (e.g., user
110) may intend to send money to his parents to repair their roof
in a remote village in China. User 110's parents do not have a bank
account, so user 110 must send the money through an intermediary
(e.g., user 112). User 110 may worry that user 112 may use the
funds inappropriately, leading to an unrepaired roof. In some
aspects, user 110 may transfer funds using the exemplary hybrid
block-chain described above, and may establish (e.g., within event
trigger list 322 and/or rules engine 324) an earmark for a
contractor already selected for the roof repairs. Although user 112
believes she can get a better deal by getting the roof repaired by
a different contractor, user 112 accesses event trigger list 322
(e.g., using user 112's private crypto key) and determines that the
different contractor cannot be paid with user 110's funds.
[0165] Shipping Beacons Based on Connected Devices
[0166] The consumer market is moving towards a model where
purchases are often made directly from manufacturers. In some
instances, as the point of purchase becomes closer and closer to
the manufacturers, inherent problems exist in tracking and paying
for these goods in an equitable way that protects both the
manufacturer and the purchaser. For example, using conventional
processes, a cost of a product is paid up-front by a purchaser, who
relies on the seller's reputation and ethical behavior to produce
and ship the product. As smaller manufacturers enter the
marketplace and purchases are made on a global scale, these
conventional payment processes are often unable to account for the
realities of modern consumer and manufacturer behavior.
[0167] In various embodiments, hybrid block-chain ledgers provide a
basis for a payment system that tracks the good/product through its
shipping route, thus mitigating risks associated with remote
purchases, and incentivizing manufacturer to produce and ship its
products on schedule. For example, upon the purchase of a product
from a manufacturer, system 140 may establish a payment and
shipment schedule, which may be included within event trigger list
322 and/or rules engine 324. Further, upon acceptance of the
conditions by the manufacturer, system 140 may disburse an initial
amount of funds to the manufacturer and create an appropriate
genesis/new block.
[0168] A trusted shipping party (e.g., FedEx, DHL, etc.) may
utilize a private key to sign transactions along one or more stages
of shipping of the product, and a partial disbursement of funds may
occur at these stages to both the trusted shipping party and the
manufacturer. As the shipment crosses set target checkpoints (e.g.,
international borders, customs, provincial/state boundaries, etc.)
further partial disbursement is made as the trusted shipping party
signs transactions within the hybrid block-chain ledger. When the
purchaser signs the receipt of the product into the hybrid
block-chain ledger, system 140 may perform operations to make the
final disbursement, thus settling all accounts of the shipment.
[0169] For example, a customer of business entity 150 (e.g., user
110) may purchase ten barbeque grills from an overseas manufacturer
for use and distribution to friends and family. User 110 may
approach business entity 150 and request establishment of a
disbursement schedule for the manufacturer based on the exemplary
hybrid block-chain ledgers described above. System 140 may, in some
aspects, create a transaction in the hybrid block-chain ledger that
holds user 110's payment (e.g., an escrow account), and system 140
may establish rules that sequentially disburse the payment when the
item ship, when the items clear customs, when they are in the same
town as user 110, and finally when user 110 is able to sign for
items after inspection.
[0170] Clearinghouse Models for Contract Settlement
[0171] In some instances, "smart contracts" that leverage
conventional block-chain ledgers may serve to enforce agreements in
a timely and efficient manner, creating a permanent record of the
transaction with all the enforceable rules associated with the
contracts. In further aspects, the use of the exemplary hybrid
block-chain ledgers described above allows the terms of these smart
contracts to be modified by a centralized authority to accommodate
the changing realities of the real world. Problems remain, however,
surrounding the reconciliation of disputes and/or the initiation of
transactions by the centralized authority to correct problems in
the list of transactions.
[0172] Hybrid block-chain ledgers may be further augmented to
include a "side" block-chain ledger that tracks any automated
transactions initiated either by the rules residing on the hybrid
block-chain ledger (e.g., event trigger list 322 and/or rules
engine 324) or by a centralized authority having power to enact a
transaction outside of normal transaction usage.
[0173] When a rule-based or centralized-authority-initiated
transaction occurs, the associated supporting documentation and
triggering events may be tracked in a special transaction category
that requires validation by a neutral third party to verify that
the transaction is in accordance with the set of rules/agreements
allowed on those particular smart contracts. These processes allow
for reconciliation of assets, funds, and ledger tracked items via a
neutral third party. Various embodiments may also allow for parties
involved in the transaction to request reviews of transactions in
cases of errors or conflicting triggering events, and a neutral
third party may act as an arbitrator in the cases where conflict
exists.
[0174] For example, various embodiments enable a customer of
business entity 150 (e.g., user 110) to create, within a hybrid
block-chain ledger, a set of rules pertaining to a smart contract
involving a contractor renovating user 110's house. The smart
contract may specify scheduled disbursements based on mutually
agreed-upon inspections of work. In one instance, the contractor
presents an inspection report to a corresponding financial
institution to receive a scheduled disbursement. Upon receipt of a
notification of the disbursement, user 110 requests that system 140
recovers the disbursement, and user 110 has not completed the
requisite and triggering inspection, and system 140 generates
non-compliance rules (e.g., within rules engine 324 using the
master key or within the side block-chain) to recover user 110's
funds. The contractor may, however, argue to the financial
institution that the required inspection has occurred and provides
a corresponding report (that was not signed off by user 110's
private key). Business entity 150 and the contractor's financial
institution may initiate an automated arbitration between user 110
and the contractor against the terms of the smart contract. The
arbitration finds in favor of user 110, who recovers the funds, and
system 140 records the arbitration decision into corresponding
transaction data for submission to peer systems 160.
[0175] Document Tracking Using Hybrid Block-Chain Ledgers
[0176] Processes that maintain deeds and other important documents
are crucial for proper record keeping and accessibility. Records
are maintained in a secure, accessible repository and available to
prove ownership or an occurrence of an event in a case of
conflicting documentation. For example, a document may be hashed
into a hybrid block-chain ledger using a secure, known technique.
In some embodiments, an image (e.g., from a camera) of the document
is hashed. The hashed document may also be used in the case of
transactions, and an ownership chain may be maintained. Using
hybrid block-chain ledgers may enable financial institutions and
other entities that provide loans secured against any of these
deeds to automatically execute liens in the case of default on the
loan. Further, the use of secured images may also provide further
security, especially in a case of conflicting documentation.
[0177] Product Tracking and Control/Counterfeit Prevention
[0178] Embodiments described herein provide a product tracking and
control system. Techniques described above and herein for use of
the hybrid block-chain ledger for tracking assets can be applied to
tangible goods, such as products, including manufactured products,
enabling manufacturers in embodiments to track and control these
products downstream after manufacture and/or distribution to, for
example, their shipping partners, their retailers and ultimately
their customers. Heretofore, conventional block chain ledgers could
not be adapted to systems for both tracking and controlling
assets--and particularly tangible products--through a block chain
ledger.
[0179] Processes that prevent an introduction of counterfeit
manufactured goods into the marketplace are essential to preserve
the intellectual property rights of manufacturers and ensure that
criminal activities do not negatively affect legitimate
manufacturers. In many instances, however, manufacturers lose track
of their goods once they leave their manufacturing plants and move
into the hands of shipping partners or distribution partners,
leaving the possibility that losses may occur before a customer is
able to purchase the product. Various embodiments may provide a
mechanism to track a legitimate product through its lifecycle and
to control and confirm transactions involving the legitimate
product, thus reducing an ability of counterfeiters to enter and
disrupt the marketplace.
[0180] A possible solution to this problem is to use the hybrid
block-chain ledger architecture in accordance with various
embodiments described herein to function as a public repository of
products that tracks ownership chains. The hybrid block-chain
ledger may also provide a centralized authority functionality that
enables manufacturers to establish rules regarding transactions
(e.g., minimum pricing, authorized dealer location, etc.). The
centralized authority functionality may also be shared with a
financial institution (e.g., business entity 150) to control
financing terms or transaction funds.
[0181] The traditional block-chain ledger architecture may enable
an individual to verify if a product has an authentic chain of
custody, but manufacturers would have very little control over the
distribution channels and how their products are traded using such
traditional block-chains. By enabling the use of a hybrid
block-chain, these same manufacturers would have the ability to, by
way of non-limiting example, identify demo models not for sale, or
set targeted minimum pricing for certain geographies to address
some of the "grey-market" activities associated with these
products.
[0182] For instance, a customer of business entity 150 may be a
manufacturer and direct sale merchant of a specialized biomedical
product with strict export regulations and a targeted regional sale
strategy. The customer may work with business entity 150 to
incorporate regional sales rules into a hybrid block-chain ledger
for each product during manufacturing (e.g., within event trigger
list 322 and rules engine 324). Due to import restrictions, one of
the rules may specify a location of sales for each product, and a
manufacturer may receive an automated message indicating that a
product intended for a developing market is being transacted in the
Europe. Working with business entity 150 and local authorities, the
financial transaction is flagged, and the product is recovered due
to usage agreement violations. In some aspects, system 140 performs
operations that revert an immediately prior transaction back to the
customer to facilitate the recovery of the customer's products for
proper deployments.
[0183] FIG. 7 illustrates an embodiment using a hybrid block-chain
ledger for tracking a manufactured good. The methodology has
particular usefulness when used with connected products, that is
with products that can be self-connected to a network, e.g., smart
products. Controls for such products can be implemented through the
block-chain by allowing for a verification to occur anytime the
product changes hands in the manufacture/distribution stream
through to the sale of the product to a consumer and thereafter
upon resales. This control can be used to prevent or at least
significantly deter grey markets that are prevalent with some
products, whether low cost, high volume products or high cost, low
volume products. By "grey market", it is meant market where a
product is bought and sold outside of the manufacturer's authorized
trading channels or outside of the manufacturer's authorized terms.
A conventional block-chain may be used to authenticate products but
it cannot prevent grey markets in those goods. Controls can also be
written into the block-chain such that validation or verification
through the block-chain is required in order to allow usage of or
unlocking of an electronic product. This authentication could be
performed each time the product is used (e.g., each time the
product is connected to the system), periodically or upon
activation of the product.
[0184] In the following example, the manufactured good is assumed
to be a cell phone. The process is illustrated with respect to the
roles of various nodes and/or participants in the system, including
the manufacturer of the good (702), the customer (704), the central
authority (which may be a financial institution) (706), the product
identifier (708), the third-party re-seller (710) and the hybrid
block-chain (712). The manufacturer, customer, central authority
and third party reseller are assumed to have processing devices for
operating as a particular node of the system as described above in
connection with FIG. 1 and for implementing the flow illustrated in
FIG. 7.
[0185] The process starts with the manufacture of a new product
(714). In the case of a cellular phone, the cellular phone is
likely manufactured as part of a manufacturing run or batch by the
manufacturer 702. Each individual product is associated with a
product identifier (716). In the case of a cellular phone, this
product identifier can be assigned by the manufacture and
programmed into the phone in a persistent manner. In embodiments,
the product identifier can be a serial number for the product or
other unique identifying factor. In certain embodiments (whether in
the case of a phone or other product), the identifier may be stored
in a bar code, RF ID or other identification mechanism within or on
the product or the product's packaging. This product ID may be
generated by the manufacturer's tracking system, by the central
authority (706) or by other suitable source.
[0186] At 718, the product ID and other pertinent information about
the manufactured product normally maintained by a manufacturer
(e.g., product batch, run or lot; product details; etc.) are
entered into a product database of the manufacturer.
[0187] At 720, the central authority (e.g., financial institution,
anti-counterfeiting institution, trade organization, or other
centralized authority) captures relevant information from the
manufacturer for starting the hybrid-block chain ledger. This
information includes the product IDs and all intended rules
associated with the product IDs. For example, in the case of a cell
phone, there may be rules that set price requirements by geographic
area, regions where the product can be sold, and sales schedules
(e.g., to enforce staging schedules), to name a few. As an example,
a particular batch of phones may be intended for sale only in the
United States at one price and a different batch of phones (with
different product IDs) may be intended for sale in Asia at a
different price point.
[0188] At 722, the central authority generates a new genesis block
for a hybrid block chain. This genesis block includes the product
ID information as well as the rules engine and event trigger list
(described above) associated with the product ID. At 724, the
central authority or other node in the network generates a new
block-chain associated with the product(s) being tracked, using the
genesis block generated at 722. This block-chain is used to update
the central authority's asset database (726) with the information
associated with the product (e.g., product ID, rules and trigger
events). Information in the product database 718 can be update from
the asset database 726 as reflected in FIG. 7.
[0189] At 728, the manufacturer ships the product (here, a batch of
cell phones) through a distributor. In embodiments, each time the
product hits a new intermediary (between the manufacturer and the
end-user purchaser) in the distribution channel, the asset database
726 is updated and optionally the product database 718.
Specifically, a new transaction is written into the block-chain to
validate that it is a valid transaction according to the
originating rules (from the manufacturer) for that particular
product's product line. The distributor (more specifically, the
distributor's processor) is just a node in the network that creates
its own block for the hybrid-block chain or provides information
for creation of a new block in the block-chain to another
processing node. For example, the distributor may inform the
central authority that it has received a batch of cellular phones
and distributed that batch to a particular recipient. Details of
this transaction are reported to the central authority to update
the asset database (730) and this transaction is processed on the
block-chain (732) by the central authority. In that operation, the
central authority validates the transaction against the
rules/trigger events associated with the product ID for the
transferred products. For example, the central authority could
confirm that the products were shipped within the terms defined by
the manufacturer. The central authority may also authorize the
release of funds or payment for the distributor's services in
accordance with the rules defined by the manufacturer. At 734 this
new transaction (receipt of the product by the distributor and/or
distribution of the product to another entity) is reflected as a
new transaction on the block-chain in accordance with the
description of the hybrid block-chain set forth above.
[0190] It should be appreciated that the validity of the
transaction and the flow of the product can be tracked entirely
through the hybrid block-chain, as all of the pertinent information
is contained in the block-chain, so the asset database 726 is not
technically necessary. However, the asset database 726 can provide
redundancy in the system or be used for quick checks on the product
status as well as updating product database 718.
[0191] Eventually, at 736, the third-party re-seller receives the
product. Though not shown in FIG. 7, this transaction may be
reflected in the hybrid block-chain in the same manner as the
shipping of the product through the distributor was reflected
(i.e., by adding a verified transaction to the hybrid block-chain)
and the asset database can be updated to reflect the latest status
of the products.
[0192] The sales rules are available (at 736) in the rules engine
of the hybrid block-chain. The third-party re-seller can access the
rules engine (at 738) in the block-chain to verify the rules of
sale associated with the products (cell phones) it has received.
Specifically, the third-party re-seller can have access to the sale
rules (via its relationship with the manufacturer) and validate
those rules against the information in the hybrid block-chain using
its private key. Once validated, the re-seller can offer the
product for sale (at 740).
[0193] At 742, the customer wishing to purchase the product may try
to initiate the purchase of the particular cell phone. The details
of the transaction are reported to the central authority which is
tasked with determining if the transaction parameters are in accord
with the rules associated with the product. The central authority
may double as the financial institution that can approve/disapprove
a credit transaction associated with the product or be independent
of such a financial institution (e.g., a standalone, independent
central authority tasked by the manufacturer or an industry with
approving/disapproving downstream transactions associated with a
product). As an example, assume the customer's credit card company
or bank (financial institution) is acting as the central authority
(or alternatively can operate with the central authority). The
financial institution receives the transaction parameters (i.e.,
product ID and sales terms (e.g., location, price and date)),
accesses the hybrid block-chain to determine the rules associated
with that particular product, compares the transaction parameters
against the rules and either declines (disapproves or at least
flags) (746) or processes (approves) (752) the transaction. In the
case of a declined transaction, the manufacturer is notified (at
748), which can take any necessary grey market mitigation steps (at
750).
[0194] Assuming the transaction complies with the rules for such
transactions, then at 752 the transaction is processed and the
hybrid block-chain is updated to reflect the details of the
transaction (e.g., the sale to customer and terms of the sale).
This update results in a new transaction reflected in the hybrid
block-chain at 754. The asset database of the central authority may
be updated at 756 to reflect the most recent product status.
[0195] There are several incentives for a financial institution (or
group of institutions) to operate as or with a central authority as
noted above. One incentive is potentially to reduce the number of
chargebacks involves with products. For example, a customer
learning that a product purchased from a seller might later learn
that the product was a counterfeit and seek to reverse the
transaction. It is more preferable to be able to decline such a
transaction in the first instance (because the transaction could
not be validated) than later process a chargeback and refund to the
customer.
[0196] Another incentive is more generally to try to reduce
instances of fraud.
[0197] A third incentive is for the financial institution to be
able to offer value added services to its customers. For example,
the financial institution's asset database 726 can track thousands
of different products associated with large numbers of
manufacturers. The financial institution can advertise to is
customers that it can validate transactions that its customers make
vis a vis these products and manufactures, essentially certifying
the authenticity of the product and the transaction to its
customers (both consumer and commercial). In a world where the
Internet of Things is becoming a reality, it is possible for
connected devices to be controlled, shut down or operationally
limited from remote sources. A certified product would have a lower
chance (from a customer's perspective) of being shut down or
operationally limited (e.g., by the manufacturer) once connected
and/or registered with the manufacturer.
[0198] It should be understood that the grey market mitigation
process 750 can involve the automated enforcement of the
manufacturer's rules reflected in the hybrid block-chain in the
case of connected devices. For example, assume a transaction is
declined at 746. This event can cause the manufacturer to remotely
lock the device (when the device is on-line), otherwise remotely
render the device partially or totally inoperable, or thereafter
prevent registration and use of the device.
[0199] The disabling of a device in case of a transaction that
violates a manufacturers rules can even take place after a
transaction. For example, let's assume the product is a low cost,
high volume product, making it likely that it could enter the grey
market. For example, assume the product is a smart, connected light
bulb (i.e., one that can be controlled remotely by a user's
Internet connected device (e.g., computer, laptop or cell phone) to
dim it or turn it on/off and that requires provisioning in able to
enable this control). Let's also assume that the first time the
light bulb is turned on and connected is a transaction. The light
bulb registers this event into the system. This event (transaction)
is checked by the central authority against the rules for that
product set forth in the hybrid block-chain. One such rule may be
that the light bulb not be sold and used in the United States. Such
as rule may exist as part of the business plan of the manufacturer
or may be implemented as part of an intellectual property policy or
agreement. For example, it may be that the manufacturer has a
license associated with the light bulb outside of the United States
and another manufacturer has exclusive rights inside of the United
States. If it turns out that the light bulb is located in the
United States, then it can be determined from the hybrid
block-chain that that event violates a manufacturer's rules. Such a
violation can trigger the manufacturer to disable the connected
light bulb. This transaction can also be added to the block-chain.
In embodiments, the asset's (e.g., light bulb's) location can be
tracked or identified through, for example, the IP address, network
ID, cell ID, or other identifier or information associable with a
location obtained when the asset is in a connected state.
[0200] Of course, if the registration event reflects that the light
bulb is not in the United States (as allowed by the manufacturer's
rules), then no disable signal is sent and the hybrid-block chain
is updated with this latest transaction. Moreover, the hybrid
block-chain can be used to enforce the manufacturer's rules in
perpetuity (or at least for some set time period (e.g., the length
of a license restriction), as potentially also reflected in the
rules for the product in the hybrid block-chain). That is, the
light bulb (or other connected product) may be designed to register
every time it is turned on or periodically (e.g., monthly). Each
registration event allows for the central authority to validate the
use of the product (light bulb) against the rules reflected in the
hybrid block-chain and log the transaction in the hybrid-block
chain. The rules can also be enforced (e.g., resulting in the
transmission of a disabling signal when appropriate) as a result of
any one of these registration events.
[0201] Returning to the product example of the cell phone, the
hybrid block-chain can be used to enforce the manufacturer's rules
even when a transaction could not be caught by the central
authority. For example, let's assume that the sale from a third
party re-seller was a cash sale. In that case, there was no
transaction reported to the financial institution and thus no
opportunity for the financial institution to validate the
transaction against the rules for the product in the hybrid
block-chain. Nonetheless, the customer must still turn the phone on
and register it on the network, e.g., the cellular provider's
network or even a LAN network such as a WiFi network. The network
will recognize that device, and ping the manufacturer's database to
download the provision required for that phone and the rules for
that phone. The system will validate those rules against a hybrid
block-chain to ensure that they are the correct rules for that
phone. At this point, assuming the phone was not intended for sale
in that market, then the customer would be notified and the phone
would not be activated. This process can prevent a user from making
use of a grey market device.
[0202] In an example, a batch of phones may be intended for India
where the manufacturer's rules establish a lower sales price than
in the United States. A person may purchase 20 such phones in
India, and these transactions are reflected in the hybrid
block-chain. That person may then sell those phones in the United
States for cash. When the user tries to register those devices, the
hybrid block-chain can be used to recognize those transactions as
violating the manufacturer's rules. Even if the manufacturer
chooses to allow registration of those devices, the manufacturer
can use the hybrid block-chain to determine the last recorded sales
transaction (i.e., the distribution to the reseller in India or the
sale in India, if recorded) and take any desired mitigating steps.
One such mitigating step may be to establish as rule in future or
existing block-chains that that particular reseller is not an
authorized reseller. It should also be noted that from a technical
perspective this hybrid block-chain approach is superior to
approaches that build restrictions into the device itself, such as
country locks on phones. This is because device-centric solutions
are subject to jailbreak. In contrast, the hybrid block-chain
solution implements the control mechanism outside of the phone
(i.e., outside of the product) with the central authority. That is,
establishing the rules in a block-chain, in a distributed network,
controlled by one or more central authorities and multiple nodes,
provides a securer mechanism for enforcing rules.
[0203] FIG. 8 is a diagram illustrating the product chain in an
embodiment of a product tracking and control system using a hybrid
block-chain ledger. The participants in the product chain include
the manufacturer 800, a financial institution 806 (or other
controlling entity), one or more reseller, distributor and/or
retailer 810 and the consumer 814. It should be understood that the
manufacturer could also be any other business entity with a
tangible product that is trackable. For example, the manufacturer
could be a producer (e.g., a farming entity), salvager,
reconditioner, reseller, miner or any other such entity that places
a product into the stream of commerce. Upon manufacture of the
product, the manufacturer registers the product, and any rules
associated with the product, with the financial institution (step
802), which maintains the asset database for tracking the product
and generates the hybrid block-chain for tracking and control of
the product. The manufacturer ships the product (step 804) and it
is handled at different points in the product chain by a
distributor, reseller or retailer. Events associated with the
product at these participants are written into the asset database
and blocks of the hybrid block-chain at 808 maintained for the
product. The financial institution (controlling entity) is
responsible for traversing event information against trigger event
data and rules associated with the product as described above.
These events may include receipt of the product, shipping of the
product, sale of the product and registration of the product, as
examples. At 812 the consumer purchases (or otherwise takes control
of) the product. This event is also registered (step 816) a block
in the maintained hybrid block-chain and, as an event, traversed
against any rules associated with the product. It should be
understood that each time a triggering event is traversed against a
rule, an action (besides updating the hybrid block-chain) can be
taken. Such action include, by way of example only, approving a
transaction, denying a transaction, alerting the authorities,
activating a product and deactivating a product. Step 816 may also
include initial and/subsequent events relating to the use of the
product, which also then involve traversing the event information
against rules associated with the product and performing an
operation dictated by the outcome of the comparison.
[0204] Value Tracking Using Block-Chain Ledgers to Capture Customer
Interactions
[0205] Today, a deep understanding of the relationship between a
customer and a business is paramount for delivering a positive
customer experience. Unfortunately, the fragmented nature of
existing corporate structures presents a complex challenge in
trying to accurately capture the various touch points experienced
by a customer. This is especially true of large corporate entities
such as financial institutions, which offer a wide portfolio of
products which may operate as separate lines-of-businesses (LOBs)
under the same corporate banner. The fragmented nation of these
existing corporate structures can thus lead to multiple approaches
in providing customer service. The lack of cross-LOB integration
may lead to an environment with very low cohesive customer
management, which may also lead to an inability to track and
quantify cross-LOB referrals and interactions. Various embodiments
provide mechanisms for tracking customer interactions across
different LOB's that provide not only a customer-centric view, but
also with techniques for tracking the intrinsic value of each
interaction with the customer.
[0206] In some aspects, the exemplary hybrid block-chain ledgers
described above may be configured to track and reward referral
programs for a single customer in a multi-LOB environment. Within a
hybrid block-chain ledger, the interactions and activities between
a customer and staff can be recorded as a transaction, and the
value generated by the transaction can be added to the hybrid
block-chain ledger and compared to the expected value of the
referral. Effectively tracking the value of each interaction and
referrals allows greater visibility and transparency of the value
generation chain. This increased transparency can be used to
optimize the incentives for all participants.
[0207] Systems and processes in accordance with various embodiments
may integrate all communication channels into a single tracking
system, and provide a platform upon which referrals can be
monetized. These systems and processes can further increase the
value proposition for each customer going through this interaction.
Thus, various have advantages over existing systems which leverage
conventional block-chain ledgers.
[0208] Hybrid block-chain ledgers can further be augmented by
allowing for incentives and payouts to occur in the transaction and
allowing for direct justification of the payouts. The augmentation
reduces the need to maintain records of all transaction, referrals
and sales as it would be integrated into a single location in the
hybrid block-chain ledgers.
[0209] In the hybrid block-chain model described above, the rules
surrounding how incentives and payouts are made can be controlled
by a central authority, thereby automating the referral processes
(e.g., in event trigger list 322 and/or rules engine 324). The
participants can view the triggers which can translate to the
actions, or thresholds associated with the incentives. The actual
distribution can be controlled by the rules engine hashed within in
the exemplary hybrid block-chain ledger.
[0210] In some aspects, system 140 combines multiple trigger events
(e.g., within event trigger list 322) to invoke the rules engine
(e.g., rules engine 324), which may change the set rewards and
incentives. The multiple trigger events may include a certain
transaction value, sale, customer interaction, a referral, and/or a
combination thereof
[0211] The apparatuses and processes are not limited to the
specific embodiments described herein. In addition, components of
each apparatus and each process can be practiced independent and
separate from other components and processes described herein.
[0212] The previous description of embodiments is provided to
enable any person skilled in the art to practice the disclosure.
The various modifications to these embodiments will be readily
apparent to those skilled in the art, and the generic principles
defined herein may be applied to other embodiments without the use
of inventive faculty. The present disclosure is not intended to be
limited to the embodiments shown herein, but is to be accorded the
widest scope consistent with the principles and novel features
disclosed herein.
* * * * *