U.S. patent application number 14/936812 was filed with the patent office on 2017-02-16 for systems and methods for detecting and resolving data inconsistencies among networked devices using hybrid private-public blockchain ledgers.
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, Orin Del Vecchio, Perry Haldenby, John Jong Suk Lee, Rajan Mahadevan.
Application Number | 20170046693 14/936812 |
Document ID | / |
Family ID | 57994253 |
Filed Date | 2017-02-16 |
United States Patent
Application |
20170046693 |
Kind Code |
A1 |
Haldenby; Perry ; et
al. |
February 16, 2017 |
SYSTEMS AND METHODS FOR DETECTING AND RESOLVING DATA
INCONSISTENCIES AMONG NETWORKED DEVICES USING HYBRID PRIVATE-PUBLIC
BLOCKCHAIN LEDGERS
Abstract
The disclosed embodiments include computerized systems and
methods that generate secured blockchain-based ledger structures
that facilitate event-based control of tracked assets. In one
embodiment, an apparatus associated with a centralized authority of
the secured blockchain-based ledger may detect an occurrence of a
triggering event, and may access and decrypt a set of rules hashed
into the secured blockchain-based ledger using a
confidentially-held master cryptographic key. The apparatus may
identify a rule associated with the detected event, and perform one
or more operations consistent with the rule. In some aspects, the
detected event may correspond to a dispute involving one or more
terms or conditions of a contractual agreement between a first
party and one or more second parties, and the performed operations
may resolve the dispute.
Inventors: |
Haldenby; Perry;
(Mississauga, CA) ; Mahadevan; Rajan;
(Mississauga, CA) ; Lee; John Jong Suk; (Waterloo,
CA) ; Chan; Paul Mon-Wah; (Markham, CA) ; Del
Vecchio; Orin; (Richmond Hill, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
The Toronto-Dominion Bank |
Mississauga |
|
CA |
|
|
Assignee: |
The Toronto-Dominion Bank
|
Family ID: |
57994253 |
Appl. No.: |
14/936812 |
Filed: |
November 10, 2015 |
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 40/08 20130101;
G06Q 10/1097 20130101; H04L 9/0891 20130101; H04L 63/12 20130101;
H04N 2005/91342 20130101; G06Q 10/0631 20130101; G06Q 20/065
20130101; G06Q 50/18 20130101; H04L 63/0442 20130101; H04L 9/0894
20130101; G06F 21/645 20130101; H04L 63/0876 20130101; H04L 9/3247
20130101; H04L 9/0816 20130101; Y02P 90/80 20151101; H04L 9/0861
20130101; H04L 63/062 20130101; G06Q 10/063114 20130101; H04L
2209/38 20130101; G06Q 30/0214 20130101; H04L 63/061 20130101; H04N
5/913 20130101; Y02P 90/86 20151101; H04L 63/0435 20130101; G06Q
20/4016 20130101; G06Q 40/128 20131203; G06Q 20/102 20130101; G06Q
20/405 20130101; G06Q 50/08 20130101; H04L 63/08 20130101; G06Q
10/08 20130101; G06Q 20/367 20130101; H04L 2209/24 20130101; Y04S
10/50 20130101; G06Q 10/103 20130101; G06Q 20/401 20130101; G06Q
20/0655 20130101; G06F 21/62 20130101; G06Q 2220/00 20130101; G06Q
2230/00 20130101; G06Q 20/3829 20130101; H04L 2209/56 20130101;
G06Q 2220/10 20130101 |
International
Class: |
G06Q 20/38 20060101
G06Q020/38; G06Q 20/40 20060101 G06Q020/40 |
Claims
1. An apparatus, comprising: at least one processor; and a memory
storing executable instructions that, when executed by the at least
one processor, causes the at least one processor to perform the
steps of: accessing data corresponding to at least one blockchain
ledger; obtaining notification data identifying a dispute involving
a contractual agreement between a first party and one or more
second parties; decrypting (i) a first encrypted portion of the
blockchain ledger data using a first cryptographic key and (ii) a
second encrypted portion of the blockchain ledger data using a
second cryptographic key, the decrypted first data portion
identifying a plurality of triggering events controlled by a rules
authority, and the decrypted second data portion identifying a
plurality of rules associated with the triggering events;
establishing that the identified dispute corresponds to at least
one of the triggering events; identifying, based on the detected
second data portion, at least one of the rules that exhibits a
causal relationship with the detected first event; and generating
an electronic command to perform one or more operations to resolve
the identified dispute consistent with the at least one identified
rule.
2. The apparatus of claim 1, wherein the executed instructions
further cause the at least one processor to perform the step of
detecting, within at least a portion of the accessed blockchain
ledger data, an occurrence of an electronic transfer of funds from
an account of the first party to an account of at least one of the
second parties, the electronic transfer being initiated in response
to a performance of one or more activities by the at least one
second party.
3. The apparatus of claim 2, wherein: at least one of a device of
the second party or a system of a financial institution associated
with the first party executes instructions to initiate the
electronic transfer of funds from the first party account to the at
least one second party account; and the executed instructions
further cause the at least one processor to perform the step of
receiving the notification data from at least one of a device of
the first party or a system of a financial institution associated
with the first party.
4. The apparatus of claim 2, wherein the identified dispute
represents a dispute between the first and second parties regarding
a conformity of the one or more performed activities to the
contractual agreement.
5. The apparatus of claim 2, wherein the executed instructions
further cause the at least one processor to perform the steps of:
extracting data that characterizes the contractual agreement from
at least a portion of the accessed blockchain ledger data;
determining, based on the data characterizing the contractual
agreement and a portion of the notification data, that the
performance of the one of more activities by the second party fails
to conform to the contractual agreement; and in response to the
determination, generate a first electronic command to initiate a
reversal of the electronic transfer.
6. The apparatus of claim 5, wherein the portion of the
notification data identified the one or more performed
activities.
7. The apparatus of claim 5, wherein the executed instructions
further cause the at least one processor to perform the step of
generating a second electronic command to establish at least one
additional data block, the at least one additional data block
comprising at least one of (0 data identifying the dispute, (ii)
data establishing the non-conformity of the one or more performed
activities with the contractual agreement, or (Hi) data indicative
of the initiated reversal of the electronic transfer.
8. The apparatus of claim 5, wherein the executed instructions
further cause the at least one processor to perform the steps of:
obtaining rules authority data identifying a plurality of entities
that function as rules authorities for the at least one blockchain
ledger; transmit at least a portion of the obtained notification
data and the extracted contractual agreement data to systems
associated with corresponding ones of the entities, the transmitted
portion of the notification data identifying the one or more
performed activities; receiving, from the entity systems, data
indicative of the conformity of the one or more performed
activities to the contractual agreement; and determining, based on
the received data, whether the one of more performs activities by
the second party conforms to the contractual agreement.
9. The apparatus of claim 1, wherein the executed instructions
further cause the at least one processor to perform the steps of:
identifying an establishment of at least one additional data block;
determining that the establishment of the at least one additional
data block corresponds to at least one of the triggering events;
identifying, based on the detected second data portion, at least
one of the rules that exhibits a causal relationship with the
detected first event; and generating an electronic command to
append the at least one additional data block to the at least one
blockchain ledger in accordance with the at least one rule.
10. The apparatus of claim 1, wherein the executed instructions
further cause the at least one processor to perform the steps of:
receiving data identifying at least one additional rule, the
additional rule being associated with at least one of the
triggering events, and the data being received from a device
associated with at least one of the first or second parties;
modifying the decrypted second data portion to incorporate at least
a portion of the received data; and encrypting the modified second
data portion using the second cryptographic key.
11. The apparatus of claim 1, wherein the executed instructions
further cause the at least one processor to perform the steps of:
receiving data identifying at least one additional triggering event
controlled by the rules authority, the data being received from a
device associated with at least one of the first or second parties;
modifying the decrypted first data portion to incorporate at least
a portion of the received data; and encrypting the modified first
data portion using the first cryptographic key.
12. The apparatus of claim 1, wherein: the first cryptographic key
comprises a private cryptographic key associated with at least one
of the parties; and the second cryptographic key corresponds to a
master cryptographic key; and the executed instructions further
cause the at least one processor to perform the steps of:
generating the master cryptographic key; storing the generated
master cryptographic key in a portion of a secure data repository;
and establishing at least one access permission for the stored
master cryptographic key, the at least one established access
permission preventing at least one of parties from accessing the
stored master cryptographic key.
13. A computer-implemented method, comprising: accessing, using at
least one processor, data corresponding to at least one blockchain
ledger; obtaining, using the at least one processor, notification
data identifying a dispute involving a contractual agreement
between a first party and one or more second parties; using the at
least one processor, decrypting (0 a first encrypted portion of the
blockchain ledger data using a first cryptographic key and (ii) a
second encrypted portion of the blockchain ledger data using a
second cryptographic key, the decrypted first data portion
identifying a plurality of triggering events controlled by a rules
authority, and the decrypted second data portion identifying a
plurality of rules associated with the triggering events;
establishing, using the at least one processor, that the identified
dispute corresponds to at least one of the triggering events;
identifying, using the at least one processor, and based on the
detected second data portion, at least one of the rules that
exhibits a causal relationship with the detected first event; and
generating, using the at least one processor, an electronic command
to perform one or more operations to resolve the identified dispute
consistent with the at least one identified rule.
14. The method of claim 13, further comprising detecting, within at
least a portion of the accessed blockchain ledger data, an
occurrence of an electronic transfer of funds from an account of
the first party to an account of at least one of the second
parties, the electronic transfer being initiated in response to a
performance of one or more activities by the at least one second
party.
15. The method of claim 14, wherein: at least one of a device of
the second party or a system of a financial institution associated
with the first party executes instructions to initiate the
electronic transfer of funds from the first party account to the at
least one second party account; and the executed instructions
further cause the at least one processor to perform the step of
receiving the notification data from at least one of a device of
the first party or a system of a financial institution associated
with the first party.
16. The method of claim 14, wherein; the identified dispute
represents a dispute between the first and second parties regarding
a conformity of the one or more performed activities to the
contractual agreement; and the method further comprises: extracting
data that characterizes the contractual agreement from at least a
portion of the accessed blockchain ledger data; determining, based
on the data characterizing the contractual agreement and a portion
of the notification data, that the performance of the one of more
activities by the second party fails to conform to the contractual
agreement; in response to the determination, generate a first
electronic command to initiate a reversal of the electronic
transfer and generating a second electronic command to establish at
least one additional data block, the at least one additional data
block comprising at least one of (i) data identifying the dispute,
(ii) data establishing the non-conformity of the one or more
performed activities with the contractual agreement, or (iii) data
indicative of the initiated reversal of the electronic
transfer.
17. The apparatus of claim 16, further comprising: obtaining rules
authority data identifying a plurality of entities that function as
rules authorities for the at least one blockchain ledger; transmit
at least a portion of the obtained notification data and the
extracted contractual agreement data to systems associated with
corresponding ones of the entities, the transmitted portion of the
notification data identifying the one or more performed activities;
receiving, from the entity systems, data indicative of the
conformity of the one or more performed activities to the
contractual agreement; and determining, based on the received data,
whether the one of more performs activities by the second party
conforms to the contractual agreement.
18. The apparatus of claim 13, further comprising: identifying an
establishment of at least one additional data block; determining
that the establishment of the at least one additional data block
corresponds to at least one of the triggering events; identifying,
based on the detected second data portion, at least one of the
rules that exhibits a causal relationship with the detected first
event; and generating an electronic command to append the at least
one additional data block to the at least one blockchain ledger in
accordance with the at least one rule.
19. The apparatus of claim 13, further comprising; receiving data
identifying at least one additional rule, the additional rule being
associated with at least one of the triggering events, and the data
being received from a device associated with at least one of the
first or second parties; modifying the decrypted second data
portion to incorporate at least a portion of the received data; and
encrypting the modified second data portion using the second
cryptographic key.
20. The apparatus of claim 13, further comprising: receiving data
identifying at least one additional triggering event controlled by
the rules authority, the data being received from a device
associated with at least one of the first or second parties;
modifying the decrypted first data portion to incorporate at least
a portion of the received data; and encrypting the modified first
data portion using the first cryptographic key.
21. The apparatus of claim 13, wherein: the first cryptographic key
comprises a private cryptographic key associated with at least one
of the parties; and the second cryptographic key corresponds to a
master cryptographic key; and the method further comprises:
generating the master cryptographic key; storing the generated
master cryptographic key in a portion of a secure data repository;
and establishing at least one access permission for the stored
master cryptographic key, the at least one established access
permission preventing at least one of parties from accessing the
stored master cryptographic key.
22. A tangible, non-transitory computer-readable medium storing
instructions that, when executed by at least one processor, cause
the at least one processor to perform a method comprising the
following steps: accessing data corresponding to at least one
blockchain ledger; obtaining notification data identifying a
dispute involving a contractual agreement between a first party and
one or more second parties; decrypting (i) a first encrypted
portion of the blockchain ledger data using a first cryptographic
key and (ii) a second encrypted portion of the blockchain ledger
data using a second cryptographic key, the decrypted first data
portion identifying a plurality of triggering events controlled by
a rules authority, and the decrypted second data portion
identifying a plurality of rules associated with the triggering
events; establishing that the identified dispute corresponds to at
least one of the triggering events; identifying, based on the
detected second data portion, at least one of the rules that
exhibits a causal relationship with the detected first event; and
generating an electronic command to perform one or more operations
to resolve the identified dispute consistent with the at least one
identified rule.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional
Patent Application No. 62/204,768, filed Aug. 13, 2015, which is
expressly incorporated by reference herein to its entirety.
DESCRIPTION
[0002] Technical Field
[0003] The disclosed embodiments generally relate to computerized
systems and methods for securing data, and more particularly, and
without limitation, computerized systems and methods that generate
secured blockchain-based ledger structures that facilitate
event-based control of tracked assets.
[0004] Background
[0005] Today, virtual and crypto-currencies, such as Bitcoin.TM.,
are gaining acceptance as viable mechanisms for performing purchase
transactions and other financial services transactions. The
transfer of units of these virtual and crypto-currencies between
owners, which is essential to the ultimate success of these virtual
and crypto-currencies, relies on a robust blockchain ledger
structure that, due to its public nature, redundant verification,
and resistance to fraudulent activity, offers advantages over
existing centralized server systems. Despite its many advantages,
conventional systems exhibit significant flaws, especially when
used to track assets in secure, high-risk, and/or sensitive
applications and when used to resolve inconsistencies within data
associated with the tracked assets.
SUMMARY
[0006] The disclosed embodiments relate to computerized systems and
methods that generate secured blockchain-based ledger structures
that facilitate event-based control of tracked assets.
[0007] In an embodiment, an apparatus includes at least one
processor and a memory storing executable instructions that, when
executed by the at least one processor, causes the at least one
processor to perform the steps of accessing data corresponding to
at least one blockchain ledger, obtaining notification data
identifying a dispute involving a contractual agreement between a
first party and one or more second parties, and decrypting (i) a
first encrypted portion of the blockchain ledger data using a first
cryptographic key and (ii) a second encrypted portion of the
blockchain ledger data using a second cryptographic key. In some
aspects, the decrypted first data portion may identify a plurality
of triggering events controlled by a rules authority, and the
decrypted second data portion may identify a plurality of rules
associated with the triggering events. The executed instructions
may further cause the at least one processor to perform the steps
of establishing that the identified dispute corresponds to at least
one of the triggering events, identifying, based on the detected
second data portion, at least one of the rules that exhibits a
causal relationship with the detected first event, and generating
an electronic command to perform one or more operations to resolve
the identified dispute consistent with the at least one identified
rule.
[0008] The disclosed embodiments also include a
computer-implemented method that accesses, using at least one
processor, data corresponding to at least one blockchain ledger,
that obtains, using the at least one processor, notification data
identifying a dispute involving a contractual agreement between a
first party and one or more second parties, and using the at least
one processor, decrypts (0 a first encrypted portion of the
blockchain ledger data using a first cryptographic key and (ii) a
second encrypted portion of the blockchain ledger data using a
second cryptographic key. In some aspects, the decrypted first data
portion may identify a plurality of triggering events controlled by
a rules authority, and the decrypted second data portion may
identify a plurality of rules associated with the triggering
events. The method may also include establishing, using the at
least one processor, that the identified dispute corresponds to at
least one of the triggering events, identifying, using the at least
one processor, and based on the detected second data portion, at
least one of the rules that exhibits a causal relationship with the
detected first event, and generating, using the at least one
processor, an electronic command to perform one or more operations
to resolve the identified dispute consistent with the at least one
identified rule.
[0009] In further embodiments, a tangible, non-transitory
computer-readable medium storing instructions that, when executed
by at least one processor, cause the at least one processor to
perform a method that includes accessing data corresponding to at
least one blockchain ledger, obtaining notification data
identifying a dispute involving a contractual agreement between a
first party and one or more second parties, and decrypting (i) a
first encrypted portion of the blockchain ledger data using a first
cryptographic key and (ii) a second encrypted portion of the
blockchain ledger data using a second cryptographic key. In some
aspects, the decrypted first data portion may identify a plurality
of triggering events controlled by a rules authority, and the
decrypted second data portion may identify a plurality of rules
associated with the triggering events. The method may also include
the steps of establishing that the identified dispute corresponds
to at least one of the triggering events, identifying, based on the
detected second data portion, at least one of the rules that
exhibits a causal relationship with the detected first event, and
generating an electronic command to perform one or more operations
to resolve the identified dispute consistent with the at least one
identified rule.
[0010] It is to be understood that both the foregoing general
description and the following detailed description are exemplary
and explanatory only, and are not restrictive of the disclosed
embodiments as claimed. Further, the accompanying drawings, which
are incorporated in and constitute a part of this specification,
illustrate aspects of the present disclosure and together with the
description, serve to explain principles of the disclosed
embodiments as set forth in the accompanying claims
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is a diagram of an exemplary computing environment,
consistent with disclosed embodiments.
[0012] FIG. 2 is a schematic diagram illustrating a conventional
blockchain ledger architecture.
[0013] FIG. 3 is a schematic diagram illustrating a hybrid,
public-private blockchain ledger architecture, consistent with
disclosed embodiments.
[0014] FIGS. 4 and 5 are flowcharts of exemplary processes for
performing event-based operations on assets tracked within a hybrid
blockchain ledger, consistent with the disclosed embodiments.
DETAILED DESCRIPTION
[0015] Reference will now be made in detail to the disclosed
embodiments, examples of which are illustrated in the accompanying
drawings. The same reference numbers in the drawings and this
disclosure are intended to refer to the same or like elements,
components, and/or parts.
[0016] In this application, the use of the singular includes the
plural unless specifically stated otherwise. In this application,
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.
I. Exemplary Computing Environments, Networks, Systems, and
Devices
[0017] FIG. 1 illustrates an exemplary computing environment 100
consistent with certain disclosed embodiments. In one aspect,
computing environment 100 may include client devices 102, 104, and
106, system 140, peer systems 160, and a communications network 120
connecting one or more of the components of environment 100.
[0018] Consistent with the disclosed embodiments, one or more of
the components of computing environment 100 may be configured to
address problems inherent to conventional blockchain-based ledgers
by embedding a private-master encryption key architecture into a
conventional blockchain architecture (e.g., a blockchain-based
architecture associated with the public Bitcoin.TM. ledger). In
some aspects, the resulting hybrid blockchain architecture may
facilitate a selective encryption of information by client devices
102, 104, and 106, system 140, and/or peer systems 160, thus
providing a technical solution that protects sensitive and/or
confidential instructions sets and event triggers and corresponding
confidential instructions sets.
[0019] a. Exemplary Client Devices
[0020] In one embodiment, client devices 102, 104, and/or 106 may
include a computing device, such as, but not limited to, 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(s), consistent with
disclosed embodiments. In certain embodiments, at least one of
client devices 102, 104, and/or 106 may be associated with one or
more users, such as users 108, 110, and/or 112. For instance, user
110 may operate client device 104 and may do so to cause client
device 104 to perform one or more operations consistent with the
disclosed embodiments.
[0021] Client devices 102, 104, and/or 106 may include 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/or 106 may
include one or more display devices that display information to a
user and one or more input device(s) to allow the user to input
information to client device 102, 104, and/or 106 (e.g., keypad,
keyboard, touchscreen, voice activated control technologies, or any
other type of known input device).
[0022] In one aspect, client devices 102, 104, and/or 106 may store
in memory one or more software applications that run on client
device 104 and are executed by the one or more processors. In some
instances, client device 104 may store 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 blockchain ledger generated and
maintained in accordance with the disclosed embodiments.
[0023] In other instances, and as described below, one or more of
client devices 102, 104, and/or 106 may execute the one or more
stored software application and to obtain data from the hybrid
blockchain ledger that includes, but not limited to, data
identifying one or more tracked assets, and/or a public key of one
or more users. Further, and as described below, the one or more
executed software applications may cause client devices 102, 104,
and/or 106 to extract, from the one or more accessed blocks, a copy
of an encrypted and/or hashed ownership/rules portion of the
transaction block (e.g., including the identification 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 actions involving the tracked
assets). In additional instances, and as further described below,
client devices 102, 104, and/or 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.
[0024] In some aspects, the one or more stored applications may
include a wallet application provided by business entity 150 (e.g.,
a mobile wallet application or an application executable on a
desktop computer) and capable of initiating transactions
denominated in one or more currencies, including virtual currencies
such as Bitcoin.TM..
[0025] b. Exemplary Computer Systems
[0026] Systems 140, 141, and 146 may be computing systems
configured to execute software instructions to perform one or more
operations consistent with disclosed embodiments. In one aspect,
systems 140 and 141 may be associated with business entities 150
and 151 (e.g., a financial institution) that provide financial
accounts, financial services transactions, and investment services
one or more users (e.g., customers of the business entities 150 and
151). In further aspects, system 146 may be associated with a
neutral third party (e.g., clearinghouse entity 152) that, among
other things, may resolve disputes regarding contractual terms,
conditions, and performance between financial institutions 150 and
151 and between users 108, 110, and 112. In some aspects, systems
140, 141, and/or 146 may be distributed systems that may include
computing components distributed across one or more networks, such
as network 120, or other networks.
[0027] In one aspect, systems 140, 141, and 146 may include
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). Similarly, system 141
may include one or more servers (e.g., server 143) and tangible,
non-transitory memory devices (e.g., data repository 145), and
system 146 may include one or more servers (e.g., server 147) and
tangible, non-transitory memory devices (e.g., data repository
149).
[0028] Server 142 (and additionally or alternatively, servers 143
and 147) may include one or more computing devices that may be
configured to execute software instructions to perform one or more
processes consistent with the disclosed embodiments. In one
example, server 142 may be a computing device that executes
software instructions that perform operations that provides
information to one or more other components of computing
environment 100.
[0029] In one embodiment, server 142 (and additionally or
alternatively, servers 143 and 147) may include a computer (e.g., a
personal computer, network computer, or mainframe computer) having
one or more processors that may be 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, and services consistent with
disclosed embodiments. 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.
[0030] In other aspects, servers 142, 143, and/or 147 (or other
computing components of systems 140, 141, and/or 146) 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 consistent with the disclosed embodiments. In some
instances, server 142 may provide 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 may be configured by the executed application program to
present portions of the information to corresponding users through
a corresponding graphical user interlace (GUI).
[0031] In further aspects, servers 142, 143, and/or 147 (or other
computing components of systems 140, 141, and/or 146) may be
configured to provide to client devices 102, 104, and/or 106
(and/or receive from client device 104) information associated with
services provided by business entities 150 and 151 and
clearinghouse entity 152. 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 may execute 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, servers 142, 143,
and/or 147 may be incorporated as a corresponding node in a
distributed network, and additionally or alternatively, as a
corresponding networked server in a cloud-computing environment.
Furthermore, servers 142, 143, and/or 147 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.
[0032] In further aspects, business entity 150 may represent a
"rules entity" capable of regulating transactions involving assets
(e.g., units of virtual currency, units of various financial
instruments, physical assets, connected devices, real estate, etc.)
tracked within hybrid public-private ledgers consistent with the
disclosed embodiments. Further, business entity 150, acting as the
rules authority, may be capable of regulating transfers of
ownership of these assets, either singly or jointly through
subdivided interests, tracked within hybrid public-private ledgers
consistent with the disclosed embodiments. By way of 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 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.).
[0033] Additionally, in some aspects, 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 blockchain keys), and transmit at least
the private blockchain key to user 110 through secure,
non-accessible processes, in accordance with one or more of the
established rules.
[0034] Further, by way of example, 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 that 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 further, to generate a new pair of public
and private blockchain keys for user 110, as described above. 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 of at least a portion of the
tracked assets (e.g., through corresponding transaction requests
consistent with the disclosed embodiments) to one or more
additional owners identified by user 110 and specified within
corresponding ones of the identified rules.
[0035] In some aspects, system 140 may be configured to establish
one or more of the rules, and further, one or more of the causal
relationships and triggering events, based on internal regulations
associated with business entity 150. For example, the one or more
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 the
recovery protocols outlined above. In other aspects, system 140 may
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. The disclosed
embodiments are, however, not limited to the exemplary triggering
events and established rules described above, and in further
aspects, the disclosed embodiments may be configured to generate
any additional or alternate 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 (i.e., acting as a rules authority for the hybrid
public-private ledger).
[0036] Further, and as outlined below, 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). Additionally or alternatively, 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).
[0037] As described above, one or more computing components of
system 140 (e.g., server 142) may be configured to generate pairs
of public and private blockchain keys for user 110 (e.g., user
110's public/private blockchain key pair), and to provide the
generated private blockchain 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.
In 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 a
confidence of the generated master key.
[0038] In additional aspects, system 140 may be configured to
generate and maintain a private crypto key on behalf of user 110
(and additionally or alternatively, user 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 user 108 and 112)
through secure, non-accessible and/or out-of-band communications.
Further, and as described above, system 140 may store copies of the
private crypto keys in a portion of data repository 144.
[0039] Further, in additional embodiments, one or more computing
components of system 140 (e.g., server 140) may be configured to
hash the generated (and encrypted) rules engine and event trigger
list into a genesis block associated with the hybrid public-private
ledger. In other aspects, system 140 may provide the encrypted
rules engine and event triggers list to one or more of peer system
160, which may be configured to hash the encrypted rules engine and
event trigger list into the genesis block. By way of example, and
by hashing the encrypted rules engine and event trigger list into
the genesis block of the hybrid public-private ledger, the
disclosed 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
[0040] In additional embodiments, one or more computing components
of system 141 (e.g., server 143) and/or system 146 (e.g., server
147) may perform one or more of the exemplary operations described
above in reference to system 140, which facilitate a capability of
business entities 150 and 151 (and any additional or alternate
financial institutions within environment 100) and/or clearinghouse
entity 152 to function as a "rules authority" within computing
environment 100.
[0041] c. Exemplary Data Repositories and Stored Data
[0042] 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 consistent with disclosed embodiments. Data
repository 144 may also be configured to store information relating
to business entity 150, e.g., a financial institution.
[0043] For instance, data repository 144 may store customer data
that uniquely identifies customers of a financial institution
associated with system 140. By way of example, a customer of the
financial institution (e.g., users 108, 110, and/or 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).
[0044] In additional aspects, and as described above, 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 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 users 108, 110, and/or 112,
processes that recover assets racked in the hybrid public-private
ledger, etc.). Further, and as described above, 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 blockchain ledger (e.g., "triggering events").
[0045] In some aspects, system 140 may be configured to establish
one or more of the rules, and further, 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).
[0046] In an embodiment, data repository 144 may also store a copy
of a master key and private crypto keys associated with users 108,
110, and 112 (and additionally or alternatively, additional private
crypto keys associated with other users). By way of 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 ones of user 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 additionally or alternatively, to 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, consistent with the
disclosed 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.
[0047] d. Exemplary Communications Networks.
[0048] Communications network 120 may include one or more
communication networks or medium 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. Consistent with 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
consistent with the disclosed 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.
[0049] e. Exemplary Peer Systems
[0050] 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 consistent with
disclosed 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.
[0051] In an embodiment, one or more of peer system 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 blockchain ledgers consistent with the
disclosed embodiments. By way of 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.
[0052] In some aspects, the one or more of peer systems 160 may be
configured (e.g., by the executed software programs) to validate
the received information and to generate a new block of the hybrid
blockchain 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 of
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 of peer
system 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
(and additionally or alternatively, other client devices associated
with other users) upon receipt of a request across network 120
and/or at regular or predetermined intervals.
[0053] 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 blockchain
ledger.
II. Exemplary Processes for Tracking Assets Using Hybrid
Private-Public Ledgers
[0054] 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 blockchain ledgers. In some aspects, the
use of public blockchain 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.
[0055] a. Tracking Assets Using Conventional Blockchain Ledgers
[0056] FIG. 2 is a schematic diagram of an exemplary structure 200
of a conventional blockchain ledger, which may be generated through
the interaction of components of computing environment 100. For
example, as described in reference to FIG. 2, a user (e.g., user
110) may be associated with a device (e.g., client device 104) that
executes a stored software application (e.g., a wallet application)
capable of obtaining a current version of a conventional blockchain
ledger from one or more networked computer systems (e.g., one of
peer systems 160 configured to "mine" broadcasted transaction data
and update ledgers). In some aspects, the current version of a
conventional blockchain ledger may represent a "longest" blockchain
ledger that includes a maximum number of discrete "blocks," which
may identify transactions that transfer, distribute, etc., portions
of tracked assets among various owners, including user 110.
[0057] For example, client device 104 may obtain the current
blockchain ledger, and may process the block chain ledger to
determine that a prior owner (e.g., user 108) transferred ownership
of a portion of the tracked assets to user 110 in a corresponding
transaction (e.g., transaction 202, schematically illustrated in
FIG. 2). As described above, one or more of peer systems 160 may
have previously verified, processed, and packed data associated
with transaction 202 into a corresponding block of the conventional
blockchain using any of the exemplary techniques described above
and/or apparent to one of ordinary skill in the art.
[0058] In some aspects, as illustrated in FIG. 2, transaction 202
may include input data that references one or more prior
transactions (e.g., transactions that transferred ownership of the
tracked asset portion to user 108), and further, output data that
includes instructions for transferring the tracked asset portion to
one or more additional owners (e.g., user 110). For example, input
data consistent with the disclosed embodiments may include, but is
not limited to, a cryptographic hash of the one or more prior
transactions (e.g., hash 202A) and the set of rules and triggers
associated with the assets while the output data consistent with
the disclosed embodiments may include, but is not limited to, a
quantity or number of units of the tracked asset portion that are
subject to transfer in transaction 202 and a public key of the
recipient (e.g., public key 202B of user 110).
[0059] Further, in some aspects, the transaction data may include a
digital signature 202C of user 108 (e.g., the prior owner), which
may be 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 and appropriate to the conventional
blockchain ledger architecture. By way of example, the presence of
user 108's public key within transaction data included within the
conventional blockchain ledger may enable client device 104 and/or
peer systems 160 to verify user 108's digital signature, as applied
to data associated with transaction 202.
[0060] In an embodiment, user 110 may elect to further transfer the
tracked asset portion to an additional user (e.g., user 112). For
example, as described above, client device 104 may execute one or
more software applications (e.g., wallet applications) that
generate input and output data specifying a transaction (e.g.,
transaction 204 of FIG. 2) 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 clock-chain ledger.
[0061] For example, data specifying transaction 204 may include,
but is not limited to, 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 using any of the exemplary techniques described above.
Further, and by way of example, the presence of user 110's public
key 202B within transaction data included within the conventional
blockchain 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 204C, as applied to data
specifying transaction 204.
[0062] As described above, 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
blockchain 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 blockchain ledger and distributed across peer systems 160
(e.g., through a peer-to-peer network) and to other connected
devices of environment 100.
[0063] In some aspects, conventional blockchain ledger
architectures described above may enable the public to review
content of the ledgers and verify ownerships. Further, the
decentralized nature of conventional blockchain ledgers may also
enable multiple distributed networks to verify the contents of a
single ledger. The resulting redundancy may render conventional
blockchain ledger architecture more robust than centralized server
systems, and effectively eliminate the falsification of ledger data
by malicious parties.
[0064] Despite these advantages, conventional blockchain ledger
architectures may exhibit significant flaws when implemented by
secured, high-risk systems. By way of example, unencrypted
conventional ledger blocks may represent a security concern for
transactions of sensitive nature, and further, 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 blockchain
ledgers, may represent private information that should not be
available to future owners, let alone members of the public.
[0065] Further, if an owner were to lose or misplace a
corresponding private key, the distributed nature of conventional
blockchain ledger architectures, such as those described above,
provide little recourse to recover possession of the one or more
tracked assets. In certain aspects, the rigidity and inflexibility
of these conventional blockchain 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 a public trust of conventional blockchain
ledgers.
[0066] Thus, there is a need for improved systems and methods that
not only enhance the security of blockchain ledger architectures
for use high-risk, sensitive applications, but that also provide a
framework that provides owners or holders of assets tracked by
blockchain ledger architectures with recourse in an event of fraud
or malicious activity, while maintaining the public availability
and verification characteristic of blockchain ledgers.
[0067] b. Exemplary Hybrid Public-Private Blockchain Ledger
Architectures
[0068] The disclosed embodiments address these and other problems
associated with conventional block-ledger architectures in a
technical manner, by providing computer-implemented systems and
methods that augment a conventional blockchain ledger with a
private-master encryption key architecture that, in conjunction
with an owner's pair of public and private blockchain keys,
selectively encrypt ledger data to protect both a privacy of owners
of tracked assets and a confidentiality of existing instruction
sets maintained within the blockchain ledger.
[0069] Further, by incorporating an encrypted rules engine and
corresponding list of triggering events (e.g., an event triggers
list) into each block of the conventional blockchain ledger
architecture (and thus generating a hybrid, public-private
blockchain architecture), computer-implemented systems and methods
consistent with the disclosed 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
blockchain ledgers.
[0070] In certain aspects, discrete data blocks of the conventional
blockchain ledgers (e.g., as outlined above in reference to FIG. 2)
and of the hybrid blockchain 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 further, a digital signature
applied to the input and/or output data using a corresponding
public key of a current owner of the tracked asset portion. The
disclosed 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 blockchain ledgers may
represent any additional or alternate transaction appropriate to
the tracked assets, and further, any additional or alternate data
appropriate to the tracked assets and to the transaction.
[0071] In contrast to the conventional blockchain ledgers described
above, the disclosed 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 blockchain ledger
architectures described herein, and further, 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.).
[0072] For example, and as described above, 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
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 racked in the hybrid public-private ledger, etc.).
Further, and as described above, 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).
[0073] In some aspects, system 140 may establish 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
create a new transaction and generate a new pair of public and
private blockchain 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 involving user 110 and/or
user 110's death (e.g., triggering events).
[0074] In further contrast to the conventional blockchain ledgers
described above, 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 a confidence of the
generated master key.
[0075] 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 a processing of the transaction blocks
throughout the hybrid blockchain ledger. In certain aspects, system
140 may also perform operations that generate and maintain
additional private cryptographic keys (e.g., a private "crypto"
key) associated with each owner associated with the assets tracked
within the hybrid blockchain ledger (e.g., users 108, 110, and/or
112) and further, that would enable the owners to decrypt and
access the list of triggering events and additionally or
alternatively, 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,
non-accessible and/or out-of-band communications.
[0076] The disclosed 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
blockchain 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 blockchain 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 blockchain
ledger. In some aspects, by incorporating the hashed and encrypted
rules engine and list of triggering events into blocks of the
hybrid blockchain ledger, the disclosed 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.)
[0077] Further, in some instances, 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 blockchain 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
blockchain ledger (e.g., associated with corresponding portions of
the tracked assets).
[0078] In certain aspects, 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 blockchain ledger, system 140 may leverage the stored master
cryptographic key to access and modify the hashed and encrypted
rules engine. System 140 may, in certain instances, 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 blockchain ledger. For example,
the one or more of peer systems 160 may incorporate the hashed and
encrypted modified rules engine into the hybrid blockchain ledger
as a special transaction (e.g., a "0" value transaction), such that
the hybrid blockchain ledger tracks each change within the modified
rules engine.
[0079] FIG. 3 is a schematic diagram of illustrating an exemplary
structure 300 of a hybrid, public-private blockchain ledger, which
may be generated through the interaction of components of computing
environment 100, in accordance with the disclosed embodiments. For
example, as described in 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 blockchain
ledger from one or more networked computer systems (e.g., one of
peer systems 160 configured to "mine" broadcast transactions and
update ledgers).
[0080] Further, in some aspects, and as described above, a system
associated with a centralized authority (e.g., system 140
associated with business entity 150) may generate a rules engine
that regulate transactions involving the assets tracked by the
hybrid blockchain ledger (e.g., distributions, transfers of
ownership, other actions, etc.), and further, 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. In additional aspects, and
as described above, system 140 may generate a master encryption key
(e.g., master key 301 of FIG. 3), 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 master key 301 and/or 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, in
additional aspects, encrypt the generated rules engine and the
generated list of triggering events, and further, perform
operations that hash the encrypted rules engine and list of
triggering events into a genesis block of the hybrid blockchain
ledger (e.g., genesis block 304).
[0081] In an embodiment, 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 blockchain
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). In some aspects,
the current version of a hybrid blockchain ledger may represent a
"longest" blockchain ledger that 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.
[0082] For example, client device 102 may obtain the current hybrid
blockchain ledger, and may process the hybrid blockchain 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). As
described above, one or more of peer systems 160 may have
previously verified, processed, and packed data associated with
transaction 306 into a corresponding block of the conventional
blockchain using any of the exemplary techniques described above
and/or apparent to one of ordinary skill in the art.
[0083] In some aspects, 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, and as described above,
input data consistent with the disclosed embodiments may include,
but is not limited to, a cryptographic hash of the one or more
prior transactions (e.g., hash 306A), and output data consistent
with the disclosed embodiments may include, but is not limited to,
a quantity or number of units of the tracked asset portion that are
subject to transfer in transaction 306 and a public key 306B of
user 108 (Le., 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 conventional blockchain ledger architecture.
[0084] Further, and in contrast to the conventional blockchain
ledger architectures described above, transaction 306 may also
include encrypted and/or hashed copies of rules engine 324 and
event trigger list 322. In certain aspects, 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 blockchain ledger obtained from one or more of peer systems
160), may parse genesis block 306, and may extract copies of the
encrypted and/or hashed rules engine 324 and event trigger list
322. The prior owner's device may transmit to one or more of peer
systems 160 along with 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
blockchain ledger.
[0085] In an embodiment, user 108 may elect to further transfer
that tracked asset portion to an additional user (e.g., user 110).
For example, as described above, 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 blockchain ledger.
[0086] For example, data specifying transaction 308 may include,
but is not limited to, 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).
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 using any of the exemplary techniques described above.
Further, and by way of example, the presence of user 108's public
key within transaction data included within the conventional
blockchain 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.
[0087] Additionally, and as described above, client device 102 may
also parse data specifying prior transaction 306 (e.g., as obtained
from the current version of the hybrid blockchain ledger) and
extract encrypted and/or hashed copies of rules engine 324 and
event trigger list 322. In certain aspects, client device 102 may
append the encrypted and/or hashed copies of rules engine 324 and
event trigger 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 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 blockchain ledger.
[0088] Further, and as described above, private crypto key 302A may
enable client device 102 (e.g., associated with user 108) to access
encrypted event trigger list 322 upon extracted from the hybrid
blockchain ledger, as described above. In some embodiments, private
crypto key 302A may provide client device 102 with read-only access
to the encrypted event trigger list 322. In some aspects, client
device 102 may obtain private crypto key 302A from system 140 using
secured out-of-band communications, and additionally or
alternatively, as input provided by user 108 through a web page or
other graphical user interface (GUI) presented by client device
104.
[0089] In an embodiment, 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 blockchain ledger by peer systems
160. In further embodiments, and as described above, user 110 may
elect to further transfer that tracked asset portion to yet another
user (e.g., user 112). For example, as described above, 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 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 blockchain ledger.
[0090] For example, data specifying transaction 310 may include,
but is not limited to, 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
the user 110, which may be applied to hash 310A and public key 310B
using a private key 310D of user 110, as described above.
Additionally, and by way of example, the presence of user 110's
public key 308B within transaction data included within the hybrid
blockchain ledger may enable various devices and systems (e.g.,
client devices 102, 104, and/or 106, peer systems 160, etc.) to
verify the user 110's digital signature 310C, as applied to data
specifying transaction 310.
[0091] Additionally, and as described above, client device 104 may
also parse data specifying prior transaction 308 (e.g., as obtained
from the current version of the hybrid blockchain ledger) and
extract encrypted and/or hashed copies of rules engine 324 and
event trigger list 322. In certain aspects, client device 104 may
append the encrypted and/or hashed copies of rules engine 324 and
event trigger 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 blockchain ledger. In an embodiment, 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
blockchain ledger by peer systems 160.
[0092] Further, and as described above, 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
blockchain ledger, as described above. In some aspects, 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. In other aspects, client device 104 may identify and extract
private crypto key 302B from a portion of the hybrid blockchain
ledger obtained from peer systems 160 (e.g., as a secure in-band
communication).
[0093] 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 customer-specified controls of transactions
involving assets tracked within a hybrid blockchain ledger. For
example, client devices 102, 104, and/or 106 may generate
transaction data that includes 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 blockchain ledger for
reference in subsequent transactions. Further, in certain aspects,
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 in reference to FIG. 4.
[0094] FIG. 4 is a flowchart of an exemplary process 400 for
automatically performing event-based operations on assets tracked
within a hybrid blockchain ledger in accordance with disclosed
embodiments. In an embodiment, a centralized authority may be
assigned to establish regulatory-based, policy-based, and
customer-specified control over assets tracked within the hybrid
blockchain ledger. In some aspects, tracked assets consistent with
the disclosed embodiments may include, but are not limited to,
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.
[0095] In one aspect, 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 402). 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.).
Further, and as described above, 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).
[0096] In certain instances, system 140 may establish, in step 402,
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
blockchain keys for user 110 in response to a verification of
particular authentication credentials. Further, and by way of
example, 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 recover the stolen portion of the tracked assets
and generate a new pair of public and private blockchain keys for
user 110.
[0097] In other instances, system 140 may establish, in step 402,
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 involving
user 110 and/or user 110's death (e.g., triggering events). The
disclosed 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.
[0098] Further, one or more computing components of system 140 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 (e.g., in step 404). By way of
example, in step 404, system 140 may generate a master
cryptographic key with which system 140 may encrypt the generated
and stored rules engine, as described above. 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 a confidence of the
generated master key.
[0099] Further, in step 404, system 140 may also perform operations
that generate and maintain additional private cryptographic keys
(e.g., private "crypto" keys) associated with each owner of the
assets tracked within the hybrid blockchain ledger. As described
above, the generated private crypto keys may enable a device of
each owner 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] 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 of the exemplary
techniques described above that facilitate 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
blockchain 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 blockchain ledger. In some aspects, by
incorporating the hashed and encrypted rules engine and list of
triggering events into the blocks of the hybrid blockchain ledger,
the disclosed 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.).
[0101] Further, 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 blockchain key associated with a portion of
the tracked assets. In other instances, system 140 may detect an
event in step 408 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.). Further, 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. The disclosed 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.
[0102] 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 were to identify the detected
event 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, in some aspects,
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).
[0103] 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).
[0104] 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/or any of the exemplary techniques
described above), 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.
[0105] In some aspects, 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 blockchain 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 blockchain ledger as a special
transaction (e.g., a "0" value transaction), such that the hybrid
blockchain ledger tracks each change within the modified rules
engine and/or list of triggering event Exemplary process 400 is
then complete in step 426.
[0106] Referring back to step 418, if system 140 were to determine
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 pass forward to step 426, and exemplary process 400
is complete. Further, and in reference to step 410, if system 140
were to determine that the list of triggering events fails to
include the detected event (e.g., step 410; NO), exemplary process
400 may pass forward 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.
[0107] 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. In certain
aspects, the operations performed by system 140, which utilize
hybrid blockchain ledgers consistent with the disclosed
embodiments, would not be possible using the conventional
blockchain ledgers described above.
[0108] For example, user 110 may be an avid user of a virtual or
crypto-currency (e.g., Bitcoin.TM.), user 110 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 retrieved from the swimming pool, user 110 may establish
that the laptop no longer functions and that data on the laptop is
not recoverable.
[0109] Through a device in communication with network 120 (e.g.,
user 110's smartphone), user 110 may access a conventional
blockchain 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 blockchain
ledger, and the Bitcoins.TM. associated with the orphaned block are
unrecoverable and permanently lost.
[0110] In other aspects, user 110 may access a hybrid blockchain
ledger (e.g., as described above in 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 an embodiment,
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 blockchain 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 blockchain ledger (e.g., through the smartphone) and confirm
the Bitcoin transfer to recover the crypto-currency.
[0111] 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 blockchain ledger (e.g., conventional blockchain
ledgers described above, and/or hybrid blockchain ledgers
consistent with the disclosed 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 e-crime unit
and report the theft, and the police may confirm the accuracy of
user 110's allegations regarding the theft.
[0112] User 110 may, in some instances, be capable of processing
the conventional blockchain ledgers described above to determine an
address of the malicious entity responsible for the theft. The
decentralized and anonymous nature of conventional blockchain
ledgers may, however, prevent user 110 from identifying the
malicious entity, and the stolen Bitcoins.TM. may remain
permanently unrecoverable.
[0113] The disclosed embodiments may, however, address the
deficiencies of conventional blockchain ledgers and provide user
110 with recourse to recover the stolen Bitcoins.TM.. For example,
the police e-crime unit may notify the centralized authority of the
theft of user 110's Bitcoins.TM. and 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 blockchain
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).
[0114] The hybrid blockchain 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 blockchain ledger architectures consistent with the
disclosed 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 the conventional techniques described above, the hybrid
blockchain 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.
[0115] In the embodiments described above, and 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 consistent with the disclosed
embodiments may include, but are not limited to, 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
[0116] In additional aspects, the exemplary hybrid blockchain
algorithms described above may track a location, performance,
usage, and/or status one or more additional client devices (e.g.,
"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 device 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. Further, in some aspects, 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).
[0117] 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, as
described above in reference to client devices 102, 104, and 106.
By way of example, connected devices consistent with the disclosed
embodiments may include, but are not limited to 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.).
[0118] Further, in additional aspects, the connected devices may
include sensor devices in communication with the one or more
processors and the memories. The sensor devices may, in some
aspects, 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, but is
not limited to, 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.
[0119] In other aspects, 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. The additional computing system may, in an
embodiments, 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 at 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.
[0120] In further aspects, 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. By way of 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. In further
aspects, 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). In certain aspects, client devices 102, 104,
and/or 106 may also incorporate corresponding portions of the
monitored data, e.g., as received from the connected devices, into
hybrid blockchain ledgers consistent with the disclosed embodiments
in order to record, track, and publicly monitor the location,
performance, usage, and/or status of the connected devices.
III. Systems and Methods for Detecting and Resolving Data
Inconsistencies among Networked Devices Using Hybrid Private-Public
Ledgers
[0121] In various embodiments described above, computer systems of
centralized authority (e.g., a financial institution, etc.) augment
conventional, decentralized blockchain ledger architectures by
selectively encrypt ledger data to protect both a privacy of owners
of tracked assets and a confidentiality of existing instruction
sets maintained within the blockchain ledger. Further, by
incorporating an encrypted rules engine and corresponding list of
triggering events (e.g., an event trigger list) into each block of
the conventional blockchain ledger architectures (and thus
generating a hybrid, public-private blockchain ledger
architecture), computer implemented systems and methods consistent
with the disclosed embodiments may perform operations that, for
example, provide owners or holders of tracked assets with recovery
options in an event of fraud or malicious activity, while
maintaining the public availability and verification characteristic
of conventional blockchain ledgers.
[0122] Further, and consistent with the disclosed embodiments,
client devices 102, 104, and/or 106 may execute stored software
applications (e.g., mobile applications provided by the centralized
authority), which may cause client devices 102, 104, and/or 106 to
transmit data identifying transactions involving held assets to one
or more computer systems across network 120 (e.g., one or more of
peer systems 160). As described above, peer systems 160 may act as
"miners" for hybrid blockchain ledgers consistent with the
disclosed embodiments, and may competitively process the received
transaction data (either alone or in conjunction with other data)
to generate additional ledger blocks, which may be appended to the
hybrid blockchain ledgers and distributed across peer systems 160
(e.g., through a peer-to-peer network) and to other connected
devices of environment 100 (e.g., across network 120).
[0123] a. Exemplary Processes for Establishing and Enforcing
Contractual Terms and Obligations Using Hybrid, Blockchain Ledger
Data Structures
[0124] In some embodiments, one or more of the exemplary hybrid
blockchain ledger data structures described above may provide a
centralized and transparent mechanism that records obligations
enforceable on various parties to a contractual agreement, and
further, that tracks data indicative of one or more transactions
initiated by the contracting parties in partial or total
satisfaction of the recorded obligations. Additionally, given the
transparent and centralized nature of these exemplary hybrid
blockchain ledger data structures, the disclosed embodiments may
enable a system of a clearinghouse entity to access the portions of
the hybrid blockchain ledger data, reconcile assets, funds, and
other tracked data against the recorded obligations and further,
identify and media conflicts between the various parties.
[0125] For example, a first party (e.g., user 108) may engage with
a second party (e.g., user 110) to renovate a portion of user 108's
home in exchange for an agreed-upon sum (e.g., $15,000). In certain
aspects, users 108 and 110 may establish terms that require payment
of the agreed-upon sum not on once, but in a first installment
prior to initiation of the renovation (e.g., an initial payment of
$5,000 for supplies), and in two subsequent installments contingent
upon user 108's approval of user 110's progress in the renovations.
For example, user 108 may agree to pay $5,000 on or before November
15.sup.th, may agree to pay a first $5,000 installment on December
1.sup.st in response to user 110's satisfactory completion of 50%
of the renovation, and further, may agree to pay a second $5,000
installment on December 15.sup.th in response to user 110's
satisfactory completion of the remainder of the renovation.
[0126] In some instances, devices associated with users 108 and 110
(e.g., client devices 102 and 104) may execute software
applications (e.g., one or more "smart contract" applications) that
establish, facilitate, verify, and/or enforce the negotiation or
performance of a contractual agreement (e.g., that establish and
implement a "smart contract" between the parties). In certain
aspects, user 108 may provide, to client device 102 as input to a
graphical user interface (GUI) generated by the executed start
contract applications, data that, among other things, identifies
the contracting parties (e.g., users 108 and 110), the contracted
activity (e.g., the renovation of user 108's home), user 108's
obligations under the contractual agreement (e.g., the initial
$5,000 payment on November 15.sup.th and the $5,000 installment
payments due on December 1.sup.st and December 15.sup.th in
exchange for satisfactory completion of portions of the
renovation), and user 110's scheduled performance under the
contractual agreement (e.g., to initiate work on by November
15.sup.th, to complete 50% of the renovation by December 1.sup.st,
and to complete renovations by December 15.sup.th). Additionally or
alternatively, user 108 may provide input that identifies one or
more financial services accounts held by user 108 at a first
financial institution (e.g., a checking, savings, and/or investment
account, a home equity line-of-credit, etc.), upon which user 108
may draw to service the financial terms of the financial
agreement,
[0127] Client device 108 may, for example, package the inputted
data into one or more data structures for storage in a locally
accessible data repository or within secure, remote data repository
accessible across network 120 (e.g., a cloud-based data
repository). In further instances, client device 108 may transmit
portions of the inputted data, including, but not limited to, data
that identifies the contracting parties, the contracted activity,
user 108's obligations under the contractual agreement, and user
110's scheduled performance, to a system maintained by the first
financial institution (e.g., system 140). As described below,
system 140, acting as a rules authority, may execute software
applications that decrypt, access, and update portions of an
encrypted list of triggering events (e.g., event triggers list 322)
and an encrypted rules engine (e.g., rules engine 324) to include
portions of the transmitted data, and may establish and maintain a
new ledger block of a hybrid, blockchain ledger data structure to
record and track the terms of the contractual agreement, as input
into client device 102 by user 108.
[0128] For example, as described above, system 140 may access
copies of the encrypted list of triggering events and the encrypted
rules engine (e.g., as stored locally in data repository 144 and/or
as obtained from a latest, longest version of the hybrid,
blockchain ledger data structure), and may decrypt the encrypted
list of triggering events and the encrypted rules engine using any
of the exemplary techniques described above. In some aspects,
system 140 may execute software applications that modify and/or
augment the decrypted list of triggering events to include data
identifying user 108's scheduled payments (e.g., November
15.sup.th, December 1.sup.st, and December 15.sup.th) and the
conditions facilitating on one or more of these scheduled payments
(e.g., 50% completion on December 1.sup.st and 10% completion on
December 15.sup.th).
[0129] Additionally, and in certain aspects, system 140 may modify
and/or augment the decrypted rules list to include one or more
operations associated with the scheduled payments and/or
facilitating conditions. For example, system 140 may generate and
include, within the decrypted rules data, additional rules data
identifying operations that initiate an electronic funds transfer
of $5,000 from an account of user 108 to an account of user 110 on
November 15.sup.th. Further, and by way of example, system 140 may
include, within the decrypted rules data, operations that confirm a
completion of 50% the renovation on or before December 1.sup.st
(e.g., based on an electronic confirmation digitally signed by user
108's private key), and that initiate an electronic funds transfer
of the $5,000 installment on December 1.sup.st in response to the
confirmation. Similarly, in some instances, system 140 may include,
within the decrypted rules data, operations that confirm a
completion of the renovation on or before December 15.sup.th (e.g.,
based on an electronic confirmation digitally signed by user 108's
private key), and that initiate an electronic funds transfer of the
final $5,000 installment on December 15.sup.th in response to the
confirmation.
[0130] System 140 may encrypt the modified list of triggering
events and the modified rules engine using any of the exemplary
techniques described above, and may store the encrypted list of
triggering events and the encrypted rules engine in a locally
accessible data repository (e.g., data repository 144) and/or in a
remote data repository accessible across network 120 (e.g., a
cloud-based data repository). Further, and in certain aspects,
system 140 may execute software applications to establish and
maintain a new ledger block of the exemplary hybrid blockchain
ledger that records data indicative of the terms of and parties to
the contractual agreement (e.g., data identifying the contracting
parties, the contracted activity, user 108's obligations under the
contractual agreement, user 110's scheduled performance, etc.), the
encrypted list of triggering events, and the encrypted rules engine
using any of the exemplary techniques described above,
[0131] For example, and as described above, system 140 may append
the new ledger block to the latest, longest version of the hybrid
blockchain ledger, which may be distributed to one or more
additional devices and systems operating within environment 100.
Additionally, in some aspects, system 140 may append the new ledger
block to one or more sidechains or other blockchain-ledger-based
data structures that track terms and conditions of the contractual
agreement.
[0132] In additional aspects, similar to those described above,
user 110 may provide, to client device 104 as input to a GUI
generated by the executed start contract applications, data that
among other things, identifies the contracting parties (e.g., users
108 and 110), the contracted activity (e.g., the renovation of user
108's home), user 110's obligations under the contractual agreement
(e.g., initiate renovations on or before November 15.sup.th,
complete 50% of the renovations to user 108's satisfaction on or
before December 1.sup.st, and complete the renovations to user
108's satisfaction on or before December 15.sup.th), and user 108's
required performance under the terms of the contractual agreement
(e.g., the initial $5,000 payment on November 15.sup.th and the
$5,000 installment payments due on December 1.sup.st and December
15.sup.th in exchange for satisfactory completion of portions of
the renovation). Additionally or alternatively, user 110 may
provide input that identifies one or more financial services
accounts held by user 110 at a second financial institution (e.g.,
a checking, savings, and/or investment account, a business account,
etc.) into which the proceeds of the contractual agreement may be
deposited,
[0133] Client device 104 may, in some instances, package the
inputted data into one or more data structures for storage in a
locally accessible data repository or within secure, remote data
repository accessible across network 120 (e.g., a cloud-based data
repository). In further instances, client device 104 may transmit
portions of the inputted data, including, but not limited to, data
that identifies the contracting parties, the contracted activity,
user 110's obligations under the contractual agreement, and user
108's scheduled performance, to a system maintained by the second
financial institution (e.g., system 141). As described below,
system 141, acting as a rules authority, may execute software
applications that decrypt, access, and update portions of an
encrypted list of triggering events(e.g., event triggers list 322)
and an encrypted rules engine (e.g., rules engine 324) to include
portions of the transmitted data, and may establish and maintain a
new ledger block of a hybrid, blockchain ledger data structure to
record and track the terms of the contractual agreement, as input
into client device 104 by user 110.
[0134] For example, as described above, system 141 may access a
copies of the encrypted list of triggering events and the encrypted
rules engine (e.g., as stored locally in data repository 145 and/or
as obtained from a latest, longest version of the hybrid,
blockchain ledger data structure), and may decrypt the encrypted
list of triggering events and the encrypted rules engine using any
of the exemplary techniques described above. In some aspects,
system 141 may execute software applications that modify and/or
augment the decrypted list of triggering events to include data
identifying performance milestones that would result in receipt of
payment (e.g., initiation of renovations on or by November
15.sup.th, satisfactory completion of 50% of the renovations on
December 1.sup.st, and satisfactory completion of all renovations
on December 15.sup.th),
[0135] Additionally, and in certain aspects, system 140 may modify
and/or augment the decrypted rules list to include one or more
operations associated with the scheduled payments and/or
facilitating conditions. For example, system 140 may generate and
include within the decrypted rules data identifying operations that
confirm receipt of an electronic funds transfer of $5,000 from an
account of user 103 on November 15.sup.th (e.g., prior to
initiating renovations). Further, and by way of example, system 141
may include, within the decrypted rules data, rules data confirming
a satisfactory completion of 50% the renovation on or before
December 1.sup.st (e.g., based on an electronic confirmation
digitally signed by user 108's private key), and confirming receipt
of an electronic funds transfer of the $5,000 installment on
December 1.sup.st. Similarly, in some instances, system 141 may
include, within the decrypted rules data, rules data confirming a
satisfactory completion of the renovation on or before December
15.sup.th (e.g., based on an electronic confirmation digitally
signed by user 105's private key), and confirming receipt of an
electronic funds transfer of the final $5,000 installment on
December 15.sup.th.
[0136] Using any of the exemplary techniques described above,
system 141 may encrypt the modified list of triggering events and
the modified rules engine, and may store the encrypted list of
triggering events and the encrypted rules engine in a locally
accessible data repository (e.g., data repository 145) and/or in a
remote data repository accessible across network 120 (e.g., a
cloud-based data repository). Further, and in certain aspects,
system 141 may execute software applications to establish and
maintain a new ledger block of the exemplary hybrid blockchain
ledger that records data indicative of the terms of and parties to
the contractual agreement (e.g., data identifying the contracting
parties, the contracted activity, user 110's obligations under the
contractual agreement, user 108's scheduled performance, etc.), the
encrypted list of triggering events, and the encrypted rules engine
using any of the exemplary techniques described above.
[0137] For example, and as described above, system 141 may append
the new ledger block to the latest, longest version of the hybrid
blockchain ledger, which may be distributed to one or more
additional devices and systems operating within environment 100.
Additionally or alternatively, system 140 may append the new ledger
block to one or more sidechains or other blockchain-ledger-based
data structures that track terms and conditions of the contractual
agreement.
[0138] Further, and by way of example,the new ledger blocks may be
structured to include, among other things: a block header (which
identifies an address of a prior block); an identifier of the
corresponding one of system 140, system 141, and/or peer systems
160 that created the additional ledger block; a rules header that
includes a rules associate key (e.g., that associates a rule to the
Internet-connected device); an encrypted list of event triggers and
an encrypted rules engine; a header for received transaction data;
and the received transaction data written into the hybrid,
blockchain data structure, as described above.
[0139] In certain aspects, the disclosed embodiments may enable
system 140 (e.g., maintained by the first financial institution of
user 108) and system 141 (e.g., maintained by the second financial
institution of user 110) to establish and maintain distinct ledger
blocks within the hybrid blockchain ledger data structure (and/or
one or more sidechain data structures) that record terms of the
contractual agreement provided by user 108 and by user 110. By
memorializing these contractual terms in corresponding ledger
blocks, which include encrypted lists of event triggers accessible
by corresponding ones of the contracting parties (e.g., crypto keys
302A and 302B, as described above), the disclosed embodiments may
enable each of the contracting parties to access the hybrid
blockchain ledger data structures and confirm their understanding
and interpretation of the mutually agreed-upon terms.
[0140] Further, one or more of the exemplary hybrid blockchain
ledger data structures described above may enable client devices
102 and 104, and additionally or alternatively, systems 140 and
141, to monitor and publicly record data indicative of activities
by users 108 and 110 that partially satisfy one or more of the
obligations set forth in the contractual agreement between users
108 and 110. In other aspects, as described below, computer systems
maintained by a neutral third party (e.g., system 146 of
clearinghouse entity 150) may access one or more data blocks of the
exemplary hybrid blockchain ledger data structures described above,
and may reconcile portions of the recorded contractual terms and
conditions (e.g., as provided by users 108 and 110) and further,
mediate disputes between users 108 and 110 in an open and
transparent manner.
[0141] For example, as described above, client device 102 may
execute one or more software applications (e.g., one or more of the
smart contract applications described above) that access one or
more portions of stored contractual data (e.g., as input by user
108, above) and determine that the contractual agreement requires
an initial transfer of $5,000 to an account held by user 110 on
November 1.sup.st to initiate the agreed-upon renovations. The
executed software applications may, for example, cause client
device 102 to perform operations that transfer $5,000 in virtual
currency from a mobile wallet maintained by client device 102 to a
corresponding mobile wallet of user 110 (e.g., as maintained by a
mobile wallet application executed by client device 104) using any
of the exemplary techniques described above.
[0142] In some aspects, client device 102 may initiate the transfer
(e.g., from user 108's account to user 110's account) by
establishing a peer-to-peer communications (P2P) session with
client device 104 (e.g., using near-field communications (NFC)
protocols, Bluetooth.TM. communications protocols, etc.), and one
or more applications programs executed by client devices 102 and
104 (e.g., mobile wallet applications, etc.) may exchange data
effecting the transfer of the $5,000 installment without recourse
to the first or second financial institutions. In other aspects,
and consistent with the disclosed embodiments, client device 102
may perform operations that initiate an electronic transfer of
funds from an account held by user 108 at the first financial
institution to an account held by user 110 at the second financial
institution (e.g., through appropriate API calls) and additionally
or alternatively, receive input from user 108 indicative of a
payment of the $5,000 installment in cash or by check. The
disclosed embodiments are, however, not limited to these exemplary
transfer protocols, and in additional aspects, user 108 and/or
client device 102 may initiate a transfer of the $5,000 installment
using any additional or alternate techniques apparent and
appropriate to users 108 and 110.
[0143] Additionally, client devices 102 and/or 104 may generate
data indicative of the initiated transfer of the $5,000 installment
payment, and additionally or alternatively, the completion of the
initiated transfer (e.g., which signals the available of the funds
for use by user 110). In some aspects, client devices 102 and/or
104 may transfer portions of the generated data for inclusion in
one or more additional ledger blocks of the hybrid blockchain
ledger data structure, which may memorialize user 108's partial
satisfaction of the obligations set forth on the contractual
agreement.
[0144] For example, client device 102 may transmit portions of the
generated data that identify the initiated transfer (e.g., an
amount of the transfer, a timestamp, a confirmation number or other
identifier of the initiated transfer, etc.) to system 140. In
certain aspects, system 140 may access and decrypt an encrypted
list of event triggers (e.g., event trigger list 322) and an
encrypted rules engine using any of the exemplary techniques
described above. Additionally, in further aspects, system 140 may
parse the decrypted list of triggering events to determine that the
$5,000 transfer initiated on November 1.sup.st represents a first
installment payment mandated by the contractual agreement (e.g., to
enable user 110 to being renovations), and based on the decrypted
rules engine, may identify one or more rules that are associated
with the first installment payment and specify a generation of an
additional ledger block that records the first installment payment
in partial satisfaction of user 108's contractual obligations. In
accordance with the one or more identified rules, system 140 may
execute software applications that establish a new ledger block
that includes portion of the data identifying the initiated
transfer, as well as the encrypted list of triggering events and
encrypted rules engine maintained by system 140, using any of the
exemplary techniques described above.
[0145] Additionally or alternatively, client device 102 may
transmit portions of the generated data that identify the initiated
and/or completed transfer (e.g., the transferred amount of the
transfer, a timestamp of the initiated and/or completed transfer,
the confirmation number, etc.) to system 141. As described above,
and based on an accessed and decrypted list of triggering events
and corresponding rules engine, system 140 may execute software
applications that establish a new ledger block that includes
portion of the data identifying the initiated transfer and/or
completed transfer, as well as the encrypted list of triggering
events and encrypted rules engine maintained by system 141, using
any of the exemplary techniques described above.
[0146] In response to the initiated and completed transfer of the
initial $5,000 installment, user 110 may purchase necessary
supplies and begin renovations on user 108's home in accordance
with the contractual agreement. With the November 15.sup.th
deadline looming for completing 50% of the renovations to user
108's home, which would trigger a transfer of the second $5,000
installment from user 108 to user 110, users 108 and 110 may agree
to meet and review the progress of the renovations. For example,
after reviewing the progress and status of the renovations, user
108 and 110 may tentatively agree that user 110 completed at least
50% of the agreed-upon renovations, which would trigger the
transfer of the agreed-upon $5,000 transfer.
[0147] In response to the tentative agreement regarding the pace of
renovations, user 110 may provide input data to client device 104
specifying the portion of the agreed-upon renovations completed
prior to the December 1.sup.st deadline and further, specifying the
completed portions represents at least 50% of the agreed-upon work.
For example, user 104 may input the data into a GUI or other
interface presented to user 110 by client device 104, and client
device 104 may package the inputted data into a corresponding data
structure (e.g., an electronic construction report). Client device
104 may, in some instances, execute one or more software
applications (e.g., one or more of the smart contract applications
described above) that parse the electronic construction report and
determine that user 110 satisfied the obligations for transfer of
the second $5,000 installment of funds. The executed smart contract
applications may cause client device 104 to generate data
requesting a transfer of the second $5,000 installment from user
108 to user 110, which may be transmitted with the electronic
construction report to system 141 using any of the communications
protocols outlined above. Additionally or alternatively, client
device 104 may also transmit the electronic construction report to
client device 102 for review and approval by user 108.
[0148] In some aspects, and in response to the received request,
system 140 may access and decrypt an encrypted list of event
triggers (e.g., event trigger list 322) and an encrypted rules
engine (e.g., rules engine 324) using any of the exemplary
techniques described above. For example, system 140 may access
copies of the encrypted list of event triggers and an encrypted
rules engine from a locally accessible data repository (e.g., data
repository 144) and/or may extract the encrypted list of event
triggers and an encrypted rules engine from a latest, longest
version of the hybrid, blockchain ledger data structure described
above. System 140 may parse the decrypted list of triggering
events, in conjunction with the electronic construction report, to
establish that the portion of the renovations performed by user 110
(e.g., as set forth in the electronic construction report)
represent an event triggering disbursement of the second $5,000
installment. Based on one or more of the decrypted rules, system
140 may perform operations to initiate the disbursement and record
the initiated disbursement in a new ledger block of the hybrid,
blockchain ledger data structure (and/or one or more sidechain data
structures) using any of the exemplary techniques described
above.
[0149] In other aspects, client device 102 may receive the
electronic construction report from client device 102, and may
execute one or more application programs (e.g., the smart contract
applications described above) to process and render portions of the
electronic construction report for presentation to user 108 through
a corresponding GUI. In some aspects, client device 102 may also
receive data (e.g., from system 140 maintained by the first
financial institution of user 108) indicative of the transfer of
the second $5,000 installment from user 108 to user 110 (e.g., from
accounts of user 108 to accounts of user 110, a transfer of units
of virtual currency, etc.). Upon review of the presented portions
of the electronic construction report, user 108 may determine that
the portion of the renovations completed by user 110 falls short of
the 50% required triggering the transfer of the second $5,000
installment,
[0150] For example, upon negotiation of the terms of the
contractual agreement, users 108 and 110 may agree that the
renovation process includes four specific construction projects
(e.g., a removal of carpet from a portion of the home, an
installation of a new hardwood floor, a removal of a partial wall,
and an application of new paint within a portion of the home). In
some instances, and upon review of the electronic construction
report, user 108 may reconsider the prior agreement with user 110
and may determine that user 110 failed to complete at least two of
the four specific construction requirements before December
1.sup.st, and thus failed to complete the 50% of the renovations
necessary to trigger the transfer of the second $5,000
installment.
[0151] In some aspects, user 108 may provide input to client device
102 (e.g., through a corresponding GUI generated by the one or more
executed smart contract applications) that disputes user 110's
performance of 50% of the renovation prior to the December 1.sup.st
deadline and further, disputed the propriety of the executed
transfer of the second $5,000 installment. In response to user
108's input, client device 102 may generate data that, among other
things, identifies the party initiating the dispute (e.g., an
identifier of user 108), the other contracting party (e.g., user
110), a corresponding device that initiated the dispute (e.g., an
IP address or MAC address associated with client device 102), the
one or more disputed terms of the contractual agreement (e.g., the
performance by user 110 of 50% of the renovation prior to the
December 1.sup.st deadline), one or more disputed actions (e.g.,
the transfer of the second $5,000 installment from user 108 to user
110), and/or evidence supporting the disputed one or more terms and
actions (e.g., the electronic construction report). Client device
102 may, in some instances, transmit the generated data to system
140 across network 120 using any of the communications protocols
outlined above.
[0152] System 140 may, upon receipt of the transmitted data may
store portions of the transmitted data in a corresponding portion
of a local data repository (e.g., data repository 144). In
additional aspects, system 140 may decrypt copies of an encrypted
list of triggering events and an encrypted rules engine using any
of the exemplary techniques described above. For example, and based
on the decrypted event triggers, system 140 may determine that the
receipt of the data indicative of the disputed term of the
contractual agreement (e.g., the performance by user 110 of 50% of
the renovation prior to the December 1.sup.st deadline) and the
transfer of the second $5,000 from user 108 to user 110 represents
a disagreement between the interpretation of the contractual terms
and user 110's performance by the first financial institution
(which deems user 110's performance insufficient to initiate
transfer of the second $5,000 installment) and the second financial
institution (which deemed user 110's performance sufficient to
transfer the second $5,000 installment from user 108 to user
110).
[0153] In some aspects, system 140 may parse the decrypted rules
engine to identify one or more dispute resolution procedures, which
may include, but are not limited to, requesting that a neutral
third party, such as clearinghouse entity 152, resolve the dispute
between the first and second financial institutions regarding the
transfer of the second $5,000 installment. In certain aspects,
system 140 may execute software applications that generate a
request for dispute resolution that includes, but is not limited
to, data that identifies the party initiating the dispute (e.g., an
identifier of user 108), the other contracting party (e.g., user
110), a corresponding device that initiated the dispute (e.g., an
IP address or MAC address associated with system 140), the first
and second financial institutions, the one or more disputed terms
of the contractual agreement (e.g., the performance by user 110 of
50% of the renovation prior to the December 1.sup.st deadline), one
or more disputed actions (e.g., the transfer of the second $5,000
installment from user 108 to user 110), and/or evidence supporting
the disputed one or more terms and actions (e.g., the electronic
construction report).
[0154] System 140 may, in certain aspects, execute software
applications that generate one or more additional ledger blocks of
the hybrid blockchain ledger data structure to memorialize the
dispute between the dispute between the first and second financial
institutions using any of the exemplary techniques described above.
System 140 may, in further aspects, transmit the generated
dispute-resolution request to a computer system maintained by
clearinghouse entity 152 (e.g., system 146), which may perform
operations that automatically and transparently resolve the dispute
between the first and second financial institutions, as described
below.
[0155] b. Exemplary Processes for Resolving Disputed Contractual
Terms Using Hybrid, Blockchain Ledger Data Structures
[0156] In some aspects, and as described above, computing
environment 100 may include a number of computer systems maintained
by various financial institutions systems 140 and 141), which may
act as rules authorities, and which may execute software
applications to establish and maintain ledger blocks of the
exemplary hybrid blockchain ledger data structures described above.
For example, various parties may mutually agree on terms of a
contractual agreement, which accords rights to the various parties
and imposes corresponding obligations for performance. As described
above, client devices operated by these various parties (e.g.,
client devices 102, 104, and 106) may execute mutually compatible
"smart contract" applications that establish and enforce
performance of the contractual agreement and further, transmit data
indicative of the terms, rights, obligations, and/or performance by
the parties to corresponding ones of the financial institution
systems, which may process and incorporate portions of the
transmitted data into ledger blocks of the exemplary hybrid
blockchain ledger data structures using any of the exemplary
techniques described above.
[0157] By way of example, the parties may agree on contractual
terms that require a first party (e.g., user 108) to pay a
predetermined sum to a second party (e.g., user 108) in exchange
for specified actions performed by user 110 on behalf of user 108.
In some instances, and as described above, the payment may
represent a transfer of units of a virtual currency held by user
108 (e.g., within a mobile wallet maintained by client device 102)
to user 110 (e.g., to a mobile wallet maintained by client device
104). Additionally or alternatively, the payment may represent a
transfer of funds from an account of user 108 at a first financial
institution to an account of user 110 at a second financial
institution. Further, in additional instances, such as those
described above, user 110 may provide (e.g., through client device
104) evidence of the performance of the specified actions to user
108 (e.g., through client device 102), and client devices 102
and/or 104 may transmit identifying the evidenced performance and
the effected transfer to systems maintained by the first and second
financial institutions (e.g., systems 140 and 141), which may
process and incorporate portions of the transmitted data into
ledger blocks of the exemplary hybrid blockchain ledger data
structures using any of the exemplary techniques described
above.
[0158] In some aspects, however, the first and second financial
institutions may disagree on a sufficiency of user 110's
performance, and first financial institution may dispute the
propriety of the transfer of funds from user 108 to user 110. For
example, and as described above, client device 104 may present an
electronic construction report to system 141 as evidence that user
110 completed 50% of an agreed-upon renovation of user 108's home,
and based on a decrypted list of triggering events and rules
engine, perform operations that transfer funds (e.g., a second
$5,000 installment) from user 108 to user 110 in exchange for user
110's performance, as described above. In certain aspects, system
140 may dispute the sufficiency of user 110's performance, as
outlined in the electronic construction report (e.g., which client
device 104 provided to client device 102, and which client device
102 provided to system 140), and may initiate processes to
automatically and transparently resolve the dispute and perform
corrective actions, as described below in reference to FIG. 5.
[0159] FIG. 5 is a flowchart of an exemplary process 500 for
automatically resolving contracting disputes using data tracked
within a hybrid blockchain ledger, in accordance with disclosed
embodiments. The disclosed embodiments may, for example, enable a
system maintained by a neutral third party (e.g., system 146 of
clearinghouse entity 152) to receive notification of a dispute
between two or more parties (e.g., between financial institutions,
etc.) regarding an implementation of one or more contractual terms
(e.g., as set forth in rules engines maintained by systems of the
financial institution), and further, to arbitrate and resolve the
dispute based on one or more rules and operations established and
maintained by system 146 (e.g., within data repository 149).
[0160] In some aspects, system 146 may receive notification of a
dispute between multiple parties to a contractual agreement (e.g.,
in step 502). By way of example, and as described above, system 141
(e.g., maintained by the second financial institution of user 110)
may determine, based on decrypted copies of an encrypted list of
triggering events and an encrypted rules engine, that an electronic
construction report (e.g., generated by client device 104)
indicates that user 110 completed at least 50% of the agreed-upon
renovations to user 108's home prior to Dec. 1, 2015, which
triggers a transfer of a second $5,000 installment from user 108 to
user 110 in accordance with terms of a corresponding contractual
agreement. In contrast, system 140 (e.g., maintained by the first
financial institution of user 108) may dispute the sufficiency of
user 110's performance, and may establish that the transfer of the
second $5,000 installment is improper and inconsistent with the
contractual agreement. As described above, and in response to the
detected dispute, system 140 may generate corresponding
notification data that identifies the dispute, the parties, and
disputed evidence, and transmit the notification data to system 146
as a notification of a dispute (e.g., which system 146 may receive
in step 502).
[0161] The notification data may, in certain instances, include,
but is not limited to, data that identifies the party initiating
the dispute (e.g., an identifier of user 108), the other
contracting party (e.g., user 110), a corresponding device that
initiated the dispute (e.g., an IP address or MAC address
associated with system 140 and/or client device 102), the first and
second financial institutions, the one or more disputed terms of
the contractual agreement (e.g., the performance by user 110 of 50%
of the renovation prior to the December 1.sup.st deadline), one or
more disputed actions (e.g., the transfer of the second $5,000
installment from user 108 to user 110), and/or evidence supporting
the disputed performance (e.g., the electronic construction report
generated by client device 104). The disclosed embodiments are not
limited to this exemplary notification data, and in further
embodiments, system 146 may receive any additional or alternate
data capable of characterizing the dispute and appropriate to
system 146.
[0162] System 146 may, in some aspects, access a latest, longest
version of a hybrid blockchain ledger data structure corresponding
to the contractual agreement (and additionally or alternatively, a
sidechain data structure), and may obtain, from the accessed hybrid
blockchain ledger data structure, data identifying terms, provided
rights, and imposed obligations of the contractual agreement and
any recorded performance by the parties (e.g., in step 504). By way
of example, and as described above, the accessed hybrid blockchain
ledger data structure may include a first data block (e.g.,
established by system 140) that records the contractual terms
provided to system 140 by client device 102 (e.g., including terms
input by user 108 into GUI generated by an executed smart contract
application), and a second data block (e.g., established by system
141) that records the contractual terms provided to system 141 by
client device 104 (e.g., including terms input by user 110 into GUI
generated by an executed smart contract application). Additionally,
in some instances, the accessed hybrid blockchain ledger data
structure may include one or more third data blocks that specify or
identify portions of user 110's disputed performance (e.g., data
blocks that incorporate portions of the electronic construction
report included within the received notification data. In some
aspects, system 146 may extract data corresponding to the first,
second, and third data blocks, which may be stored in corresponding
portions of a locally accessible data repository (e.g., data
repository 149).
[0163] Further, in step 506, system 146 may also access and decrypt
an encrypted list of triggering events (e.g., event trigger list
322) and an encrypted rules engine (e.g., rules engine 324). In
some aspects, and as described above, system 146 may access and
decrypt the encrypted list of triggering events and encrypted rules
engine hashed into the latest, longest version of the hybrid
blockchain ledger data structure corresponding to the contractual
agreement (e.g., as obtained above in step 504). In other aspects,
consistent with the disclosed embodiments, system 146 may access a
locally stored copy of the encrypted list of triggering events
and/or the encrypted rules engine (e.g., as stored within data
repository 149).
[0164] In some aspects, the decrypted list of triggering events may
specify that the received notification data represents an event
triggering initiation and performance of a dispute-resolution
process by system 146, which may be defined by one or more
associated rules set forth in the decrypted rules engine. For
instance, the decrypted rules engine may include one or more rules
that define operations performed by system 146 to resolve a dispute
involving terms of and/or performance related to the contractual
agreement between users 108 and 112. By way of example, the
specified dispute-resolution operations may include a first
operation that determines whether users 108 and 110 specified
mutually consistent terms and conditions (e.g., within the
extracted first and second data blocks described above), and one or
more second operations (e.g., specified by the first and second
financial institutions, a governmental and/or regulatory entity,
etc.) to determine a compliance of the evidenced performance (e.g.,
the electronic construction report) with the mutually consistent
terms and conditions.
[0165] Further, in additional instances, the decrypted rules engine
may also identify operations that enable system 146 to resolve the
contractual dispute between users 108 and 110, and further, between
the first and second financial institutions, based on a consensus
of those financial institutions capable of acting as rules
authorities for the hybrid blockchain ledger data structure. For
example, one or more of the rules may cause system 146 to provide
portions of the received notification data to systems maintained by
the financial institution (e.g., that operate as rules authorities
within environment 100). In some aspects, the transmitted
notification data portions may cause software applications executed
by the financial institution systems to prompt a competent
representative of each financial institutions (e.g., an attorney in
the office of the general counsel) to review the evidence and the
contractual terms, and identify the prevailing party (e.g., user
108 or user 110) within an established time period. The financial
institution systems may transmit data indicative of the prevailing
party to system 146, which may aggregate the received data and
establish, as the prevailing party, that contracting party
identified by a plurality and/or a majority of the financial
institutions.
[0166] In other instances, and consistent with the disclosed
embodiments, the decrypted rules engine may include multiple groups
of rules specifying operations that resolve corresponding types of
disputes. For example, the decrypted rules engine may include
groups of rules specifying operations for resolving disputes
involving constructions contracts, employment contracts, licensing
agreement, and any additional or alternate type of contract
appropriate to the first and second financial institutions and
users 108 and 110. The disclosed embodiments are not limited to
these exemplary rules, and in additional embodiments, the decrypted
rules engine may specify any additional or alternate
dispute-resolution rule appropriate to the contractual agreement,
the contracting parties, and the various financial
institutions.
[0167] In further aspects, system 146 may select one or more of the
decrypted rules associated with the resolution of the contractual
dispute involving users 108 and 110 (e.g., in step 508), and may
perform operations consistent with the one or more selected rules
to resolve the contractual dispute (e.g., in step 510). For
example, and in accordance with the selected rules, system 146 may
execute software applications that access locally stored data
(e.g., extracted from the first and second data blocks described
above) identifying each set of terms and conditions specified by
users 108 and 110. Based on the accessed data, system 146 may
determine that users 108 and 110 specified mutually consistent
terms and conditions specifying a disbursement of the second $5,000
installment upon completion of at least 50% of the renovation of
user 108's home prior to December 1.sup.st. System 146 may parse
the electronic construction report to determine, for example, that
the renovation includes four specific construction projects (e.g.,
a removal of carpet from a portion of the home, an installation of
a new hardwood floor, a removal of a partial wall, and an
application of new paint within a portion of the home), which may
be subdivided into twenty discrete tasks. Based on the electronic
construction report, system 146 may also determine that, while user
110 did not complete any of the four tasks by December 1.sup.st,
user 110 complete fourteen of the twenty discrete tasks. In certain
aspects, system 146 may determine that user 110's performance
complied with the terms of the contractual agreement in step
510.
[0168] In other instances, system 146 establish user 110's
compliance with the contractual agreement in accordance with a
consensus decision of all financial institutions capable of acting
as rules authorities for the hybrid blockchain ledger data
structure. For example, system 146 may identify nine such financial
institutions, and may obtain IP addresses and other information
identifying computer systems maintained by these nine financial
institution (e.g., from a corresponding portion of data repository
149). System 146 may, in some instances, transmit portions of the
received notification data to these nine systems, and software
executed by these nine systems may request that representatives of
the corresponding institutions review the disputed terms and
evidence and provide input identifying whether the user 110
complied with the contractual agreement within a predetermined time
period (e.g., one hour, twenty-four hours, etc.). The systems
maintained by these none financial institutions may transmit the
provided input back to system 146, and system 146 may process and
aggregate the results to determine the consensus decision.
[0169] By way of example, system 146 may receive responses from
seven of the nine computer systems within the predetermined time
period, and system 146 may determine that six of the seven
financial institutions agree that user 110's performance complied
with the terms of the contractual agreement. System 146 may, in
certain aspects, and based on the consensus decision, determine in
step 510 that user 110's performance complied with the terms of the
contractual agreement.
[0170] The disclosed embodiments are, however, not limited to these
exemplary dispute resolution processes. In additional embodiments,
system 146 may resolve the dispute in a multi-step process that
initially reviews the provided evidence in light of the terms of
the contractual agreement, and if the outcome were ambiguous, would
establish a final decision regarding user 110's compliance with the
contractual agreement on the basis of the consensus decision of the
participating financial institutions, as described above. In
further embodiments, system 146 may also implement any additional
or alternate processes to resolve the identified dispute that would
be appropriate to the disputed terms of the contractual agreement,
the contracting parties, and/or the corresponding financial
institutions.
[0171] Based on the resolved dispute, system 146 may determine the
propriety of the transfer of the second $5,000 installment from
user 108 to user 110 (e.g., in step 512). For example, if system
146 were to determine that user 110 completed at least 50% of the
agreed-upon renovations by December 1.sup.st, user 110's
performance may be compliant with the contractual agreement. System
146 may determine that the transfer of the second $5,000
installment from user 108 to user 110 is proper and consistent with
the contractual agreement (e.g., step 512; YES), and system 146 may
execute software applications that establish and maintain a new
ledger block identifying the propriety of the transfer and the
resolution of the dispute between users 108 and 110 and between the
first and second financial institutions using any of the exemplary
techniques described above (e.g., in step 514). Exemplary process
500 is then complete in step 516.
[0172] If, however, system 146 were to determine that user 110
failed to complete at least 50% of the agreed-upon renovations by
December 1.sup.st, user 110's performance may be non-compliant with
the contractual agreement. System 146 may determine that the
transfer of the second $5,000 installment from user 108 to user 110
is inappropriate and inconsistent with the contractual agreement
(e.g., step 512; NO), and system 146 may execute software
instructions that initiate an additional transaction to reverse the
transfer of the second $5,000 installment from user 108 to user 110
and to return the $5,000 in funds to user 108 using any of the
exemplary techniques described above (e.g., in step 518). Exemplary
process 500 may then pass back to step 514, and system 146 may
establish and maintain a new ledger block identifying the
impropriety of the transfer and the initiation of the new
transaction returning the second $5,000 installment to user 108
using any of the exemplary techniques described above. Exemplary
process 500 is then complete in step 516.
[0173] In the embodiments described above, system 146 of
clearinghouse entity 152 may resolve disputes between financial
institutions and between contracting parties that involve an
interpretation of contractual terms and/or a performance of the
contracting parties. In additional aspects, and consistent with the
disclosed embodiments, system 146 may apply one or more of the
rules and/or event triggers described above to determine a
propriety of one or more new ledger blocks added to the hybrid
blockchain ledger data structure (and/or one or more sidechain data
structures)by systems of various rules authorities (e.g., systems
140 and 141), and further, to reconcile various assets and funds
tracked within the hybrid blockchain ledger data structure and/or
the one or more corresponding sidechain data structures.
[0174] Various embodiments have been described herein with
reference to the accompanying drawings. It will, however, be
evident that various modifications and changes may be made thereto,
and additional embodiments may be implemented, without departing
from the broader scope of the disclosed embodiments as set forth in
the claims that follow.
[0175] Further, other embodiments will be apparent to those skilled
in the art from consideration of the specification and practice of
one or more embodiments of the present disclosure. It is intended,
therefore, that this disclosure and the examples herein be
considered as exemplary only, with a true scope and spirit of the
disclosed embodiments being indicated by the following listing of
exemplary claims.
* * * * *