US10755241B2 — Hot wallet for holding bitcoin (Part 5 of 5)
Document text
Research, not advice. Part of the Bitcoin research archive (October 2026). Claims labelled unverified, contested or fringe are reported, not endorsed; statuses of bills and rules are as of the date checked. Government, court and patent records are public domain; the research notes are CC BY 4.0.
the local storage 56 having its private key removed . At this stage
private key 79 has been split in FIG . 46. The assembler 94 60 it may be desirable to restore the values of the Bitcoin
assembles the private key 79 when the minimum number of addresses 76 and 78. The private key of the first Bitcoin
codes has been received . address 80A within the local storage 56 is restored to the
The private key 79 of the Bitcoin address 80 in the local vault 64 as hereinbefore described with reference to FIG . 50 .
storage 56 is used to access the vault 64. The local controller The respective values of the Bitcoin addresses 76 and 78 are
58 then restores the private key 79 from the local storage 65 then restored from the vault 64A to the Bitcoin addresses 76
into the vault for association with the Bitcoin address. The and 78 in the wallet 42. Because the values of the Bitcoin
block chain will know whether the private key 79 that has addresses 76 and 78 are restored within the wallet 42 , the
US 10,755,241 B2
19 20
Bitcoin addresses 76 and 78 of the first transfer set can , at FIG . 54 illustrates a network environment 136 that, in
least for the time being, be used together with the second addition to the first host computer system 14 , includes a
transacting set for transacting with another user . customer computer system 138 and a merchant computer
The same Bitcoin addresses 74 , 76 , 78 and 98 that are system 140 that are connected to one another over the
shown in FIG . 51a are also shown in FIGS . 516 and 51c . It 5 Internet 142. The merchant computer system 140 has an
should be understood that the Bitcoin addresses may change online store 144 and a website 146. The customer computer
system 138 has a browser 148. A customer at the customer
between the figures. The system allows for the value that computer
was previously associated with one Bitcoin address to be website 136system over
138 can use the browser 148 to access the
the Internet 142. The website 136 is then
restored to another Bitcoin address if necessary .
As shown in FIG. 51d , the first vault 64A is discarded 10 displayed on the browser 148. The website 136 allows for
the customer to make purchase on the online store 144. The
after the value therein is restored . The first Bitcoin address
customer may, for example, purchase real goods , virtual
80A within the local storage 56 and the first vault 64A will goods
never be used again . or services from the online store 144 .
The first host computer system 14 includes an application
TheTheprivate
Bitcoinkeyaddress 78 is selected
of the Bitcoin address as80Ca third
of thetransfer set. 15 programmable interface ( API) 150, a reference code gen
third vault
erator 152 , a transaction processor 154 , a currency converter
64C is transferred into the local storage 56 and stored in 156 and merchant, and customer and host wallets 158 , 160
association with a third Bitcoin address 80C . The value of and 162. The wallets 158 , 160 and 162 may be of the kind
the Bitcoin address 78 is transferred from the wallet 42 to the as hereinbefore described .
third vault 64C . The user of the wallet 42 can now not use 20 As shown in FIG . 55 , the customer is shown a shopping
the Bitcoin address 78 for transacting with another user . The cart with several payment options, including " Pay with
Bitcoin address 76 forms part of a third transacting set that Credit Card ” and “ Pay with bitcoin . ” Prior to being dis
could include one or more Bitcoin addresses . The Bitcoin played the shopping cart, the customer has traveled through
address 76 can be used by the user of the wallet 42 for the shopping flow of the merchant computer system 140 , has
transacting with another user because the value of the 25 selected one or more items to be purchased and has selected
Bitcoin address 76 is associated therewith within the wallet a shopping or checkout cart, which causes the display of the
42. The second and third transacting sets can thus be used by view shown in FIG . 55. When the user selects the button
the user for transacting with another user. The second and “ Pay with bitcoin ” the merchant computer system 140 , at
third transfer sets are unusable for transacting with another 166 , transmits an API call to the first host computer system
user because their private keys have been removed . 30 14. The API call includes a request for payment. The request
FIG . 52 illustrates how the local controller 58 ( see FIGS . for payment includes an amount in a currency, in the present
46 to 50 ) maintains transaction sets of a wallet 42 within a example $ 14.00 , an order name ( usually a number ), order
target range 101. Should all the Bitcoin addresses of the descriptions (usually items in the checkout cart in a single
wallet 42 have values associated therewith, the wallet 42 is line - item entry separated by commas ), and a success uni
said to be 100 % hot and 0 % cold . If all the Bitcoin addresses 35 form resource locater (URL ) if desired ( a page to which the
in a wallet 42 have their values removed, the wallet 42 is to customer is redirected at checkout if the order completes).
be 0 % hot and 100 % cold . The target range 101 for the total When the first host computer system 14 receives the API
bitcoin value within the wallet may for example be 5 % to call at 166 , the reference code generator 152 generates a
10 % hot. At 102 , the values of the first transacting set are unique reference code for the specific order. The reference
transferred from the wallet 42 as described with reference to 40 code is thus uniquely generated for each API call . The first
FIG . 51a . At 104 , the user transacts with some of the Bitcoin host computer system 14 then stores the reference code in its
addresses and the total value within the wallet 42 of the database . At 168 , the first host computer system 14 responds
Bitcoin addresses that are hot is reduced . At 106 , the values to the API call received at 166 to transmit the reference code
of the second transfer set are removed from the wallet 42 as to the merchant computer system 140. The merchant com
described with reference to FIG . 51b . At 108 , the values of 45 puter system 140 then receives the reference code as refer
the first transfer set are restored as described with reference ence code 170. The merchant computer system 140 stores
to FIG . 51c . At 110 , the user transacts and gains further the reference code as reference code 172 within its account
Bitcoin addresses for additional value within their wallet 42 . ing system 173 and associates the reference code 172 with
At 112 , values of the third transfer set are transferred out of the particular order shown in the shopping cart . The mer
the wallet 42 as described with reference to FIG . 51d . It can 50 chant computer system 140 also creates a URL 174. The
thus be seen that the local controller 58 in FIGS . 46 to 50 reference code 170 is used as a reference code 176 within the
adjusts the total value of bitcoin that is not within the target URL 174 when the URL 174 is created .
range 101. The local controller 58 typically recalculates the The first host computer system 14 creates a URL 180 that
hot / cold value ratio of each wallet on a daily basis and includes a reference code 182. The reference code 182 and
automatically adjusts the value to the target range 101 . 55 the reference code 176 are the same .
FIG . 53 illustrates the use of an intermediate hot wallet The merchant computer system 140 at 178 redirects the
114 that is used to collect bitcoin values from a plurality of browser 148 (FIG . 54 ) using the URL 174. The browser is
wallets 42A to C. The wallet 42 A is that same as the wallet then redirected to the URL 180 of the first host computer
42 as described above . The wallet 42B has bitcoin addresses system 14 .
120 , 122 , 124 and 126 associated therewith . The wallet 42C 60 The URL 180 may, for example, be the URL of a landing
has bitcoin addresses 128 , 130 , 132 and 134 associated page , iFrame or modal window 184. The landing page ,
therewith . Each wallet 42A , B or C is held within the target iFrame or modal window 184 presents checkout options to
range 101 in FIG . 50. The values of the bitcoin addresses 76 , the customer, including to pay with the customer wallet 160
78 , 120 , 122 , 128 and 130 are identified for transfer to the if one exists , to pay with bitcoin using an external account,
vault 64A and are first transferred or " swept ” to the inter- 65 or to create a wallet at the first host computer system 14 for
mediate hot wallet 114 from where they are transferred to the purposes of completing the purchase . In a different embodi
vault 64A . ment, instead of being automatically redirected by the mer
US 10,755,241 B2
21 22
chant computer system 140 to the first computer system 14 , computer system 14 communicates with a bank of the
the customer may be redirected to a different page at the merchant computer system 140. Such communication, at
merchant computer system 140 , which will then contain a 204 , results in transfer of funds from a host bank account
link for the customer to navigate to the landing page , iFrame 206 to a merchant bank account 208 .
or modal window 184 . 5 In the present example, the customer uses their customer
When the browser 148 of the customer computer system wallet 160 to transfer funds in the form of bitcoin from the
138 downloads the landing page , iFrame or modal window customer wallet 160 to the merchant wallet 158 and the
184 , the first host computer system 14 automatically gen funds are then transferred in the form of bitcoin from the
erates a bitcoin address 186 specifically for the customer's merchant wallet 158 to the host wallet 162. In another
order within the merchant wallet 158 . 10 embodiment, the merchant wallet 158 can be bypassed such
The first host computer system 14 also creates a bitcoin that the customer transfers funds in the form of bitcoin from
price based on the price in local currency and displays the the customer wallet 160 directly into the host wallet 162. In
bitcoin price within the landing page / iFrame or modal either embodiment the funds that are received by the host
window 184 within the browser 148. The graph illustrates a wallet 162 are used as a basis for calculating the amount of
fluctuating bitcoin to dollar exchange rate. In the present 15 money in local currency that is transferred by the bank
example , the exchange rate at minute ( is used at 190 to transfer module 200 , minus a fee that is held back by the first
calculate the exchange rate . The local currency price in the host computer system 14 for purposes of processing the
present example is $ 14.00 which gives a bitcoin price of transaction .
0.02 BTC . The price of 0.02 BTC that is based on the Referring again to FIG . 54 , the API 150 sends and
exchange rate at minute 0 is maintained for a select period 20 receives API calls at 166 , 168 and the order status message
of time , in the present example 10 minutes, before it resets. in response to the send instruction 192 in FIG . 55. The
The customer may not wish to immediately send the bitcoin , currency converter 156 is responsible for receiving and
but may do so at any time before the price resets at minute maintaining exchange rate for bitcoin to local currency and
10 and the exchange rate remains locked in and the bitcoin for calculating the bitcoin price based on the local currency
price thus remains unchanged at 0.02 BTC during that time . 25 price and the exchange rate at any particular moment in
An option is displayed to the customer to send the bitcoin time . The transaction processor 154 is responsible for trans
together with the price in bitcoin at minute 0. When the ferring funds in the form of bitcoin or local currency from
customer selects the option to send the bitcoin, the customer one wallet or bank account to another.
computer system 138 transmits a send instruction to the first In the embodiment above , the exchange rate is locked in
host computer system 14. The first host computer system 14 30 when the customer accesses the landing page , iFrame or
receives and at 192 detects the send instruction . The cus modal window 184 and is locked for ten minutes. In such an
tomer may for example request to send bitcoin from the embodiment the merchants typically create a payment “ but
cus mer wallet 160 or via another path as hereinbefore ton ” or using the API , specifically the button API , of the first
described . The first host computer system 14 responds to the host computer system . Selection of the button by the cus
send instruction to transmit an order status message that 35 tomer results from the process described above wherein the
includes the reference code for the transaction to the mer customer is directed to the landing page , iFrame or modal
chant computer system 140. The merchant computer system window 184. Such a button does not need to look any
140 receives the reference code as reference code 194. The different from the merchant's standard " submit order ” but
merchant computer system 140 then matches the reference ton and the button API is linked into the standard " submit
code 194 to the reference code 172 within its accounting 40 order ” button of the merchant computer system 140 , which
system 173 and marks the transaction as complete . when clicked will direct the user directly to the landing page ,
In the present example , the send instruction is processed iFrame or modal window 184. When the user hits the
at minute 6. The exchange rate has in the present example landing page the exchange rate is locked . The merchant
changed between minute ( and minute 6. Should the bitcoin " order " is thus not created i.e., with locked in exchange
price of 0.02 BTC be converted to local currency at this time 45 rate until the user clicks the payment button to land on our
it would result in a different price in local currency than the landing page .
original transaction. The difference between the original Another embodiment is used in white - label solutions . In
price at minute ( and minute 6 represents either a loss or a these instances , the user is not directed away from the
gain for the first host computer system 14. The loss and gain merchant domain to a landing page such as the landing page ,
is used to calculate bitcoin replacement costs on a periodic 50 frame or modal window 184 to complete payment. Instead ,
basis . the checkout information that would have otherwise shown
In the present example the first computer system 14 on the landing page is displayed inside the merchant's
responds to the send instruction received at 192 to transmit browser checkout tool . Such an embodiment may not allow
0.02 BTC to the bitcoin address 186 associated with the " one - click ” checkout for users who are already signed into
merchant wallet 158. When the bitcoin reaches the bitcoin 55 their customer wallet 160 ; a user can only pay by QR code
address 186 , the first host computer system 14 , at 196 , scan and /or manual entry of a bitcoin address . In order for
immediately purchases the bitcoin from the merchant wallet this information to be incorporated into the merchant's
158 , resulting in a transfer of the bitcoin from the merchant webpage , the merchant ( 1 ) creates a “ button " when they post
wallet 158 to the host wallet 162. The first host computer an item for sale to the website ( the button includes the price
system 14 purchases the bitcoin at the exchange rate locked 60 in local currency, but not a bitcoin price and can be created
in at minute 0 . at any time e.g., weeks before a purchase ); and ( 2 ) when
Periodically, for example daily, the first host computer the customer wishes to pay, e.g. , by clicking on a “ Place
system 14 calculates the total amount of bitcoin sold by the Order ” button , the merchant computer system 140 sends an
merchant wallet 158 that day at the locked in prices . The first API call to the first host computer system 14 which responds
host computer system 14 has a bank transfer module 200 65 by sending back a locked in exchange rate , which again is
that, at 202 , transmits a payment instruction to a bank for the good for ten minutes. The merchant then displays the
first host computer system 14. The bank for the first host checkout information to the user — i.e ., the proper bitcoin
US 10,755,241 B2
23 24
address and amount. This embodiment differs in that: ( 1 ) the At 246 , the first host computer system 14 makes a
" order" is created earlier in time , and the exchange rate determination whether all the additional email addresses are
follows on as a separate API call ; and ( 2 ) the checkout associated with other accounts within the first host computer
information is hosted within the merchant's domain . system 14. If all the additional email addresses are associ
FIG . 56 illustrates a method of managing bitcoin wherein 5 ated with other accounts, then the first host computer system
a personal vault is created for a user. At 220 , the user already 14 proceeds at 248 to update the account represented at 220
has an account that the user can log into using a website . The with a vault that includes the first email address, the addi
account has a first email ( electronic communication ) therewith tional email addresses and the phone number associated
address . The first email address may be .
[email protected] . The account also has a phone num associatedorwith
10 If one more of the additional email addresses are not
any accounts within the first host computer
ber associated therewith and one or more wallets as herein
system 14 , then the first host computer system 14 , at 250 ,
before described . The website provides the user with a link transmits
to create a vault. At 222 , the user is provided an option to associatedanwithemail to the additional email address that is not
an account to create an account. A user
create an individual vault or a group vault. In an individual 15 receiving the email transmitted at 250 can proceed at 252 to
vault the user will be required to respond to two emails in create an account with the second email address associated
order to transfer bitcoin out of the vault . In a group vault with the account. Only after all the additional email
multiple users are required to respond to emails in order for addresses are associated with accounts does the first host
the user of the account represented at 220 to transfer the computer system 14 , at 248 , proceed to register a vault.
bitcoin out of the vault . 20 The first host computer system 14 then at 254 provides a
The user may, at 224 , select an individual vault . At 226 , summary through the interface of the website . The summary
an interface of the website is presented with a field for the shows that in order to transfer bitcoin, emails will be sent to
user to enter a second email address. The second email and confirmations will be required from the first email
address may for example be [email protected] . The address and the minimum of the additional email addresses.
user enters the second email address and selects a button to 25 The summary also includes the phone number associated
transmit the second email address from their device to the with the vault and states the waiting period before the bitcoin
first host computer system 14. When the first host computer is transferred . The website also includes a “ Finish ” button
system 14 receives the second email address, the first host which, when selected by the user at 238 , lands the browser
computer system 14 , at 228 , transmits a confirmation email used by the user in the vault .
with a confirmation link to the second email address. The 30 FIG . 57 illustrates how bitcoin is transferred into and out
purpose of the email that is transmitted at 228 is to confirm of the vault. At 260 , the user first transfers bitcoin into the
the second email address . At 230 , the first host computer vault. The user may transfer the bitcoin from one of their
system 14 waits for the confirmation . The first host computer wallets associated with their account into the vault or may
system 14 does not proceed to create a vault if the confir transfer the bitcoin into the vault from an external source .
mation is not received . At 232 , the user selects the confir- 35 The bitcoin is then stored within the vault .
mation link , which causes transmission of the confirmation At 262 , the user requests a transfer out of the vault using
from the device of the user to the first host computer system the website . The user includes the amount of bitcoin to be
14. When the first host computer system 14 receives the transferred , the reason for the transfer and selects a wallet to
confirmation, the first host computer system 14 proceeds at which the bitcoin is to be transferred . The user also includes
232 to register a vault within the same account shown at 220. 40 a two - factor code which the user may obtain through a
The vault includes the first and second email addresses. The mobile application or via SMS communication with the first
vault also includes the phone number of the account. host computer system 14 .
At 236 , the first host computer system 14 updates the At 264 , the first host computer system 14 determines
interface of the website to provide a summary . The summary whether the two - factor code is correct. If the two - factor code
indicates that, in order to transfer bitcoin out of the vault, 45 is incorrect, then the first host computer system 14 , at 266 ,
emails will be sent to the first and second email addresses, makes no change to the website interface .
and the summary includes the phone number associated with If the determination is made at 264 that the two - factor
the vault and that the bitcoin will not be transferred out of code is correct, then the first host computer system 14
the vault for a period of 48 hours . The interface also includes proceeds at 268 to transmit all emails . In the case of an
a “ Finish ” button . When the user selects the “ Finish ” button , 50 individual vault, emails are sent to the first and second email
the browser used by the user, at 238 , lands in the vault . The addressesrepresented in the account at 234 in FIG . 56. In the
vault looks like a wallet , but has a security feature that limits case of a group vault , then emails are transmitted to the first
transfer of bitcoin out of the vault. email address and the additional email addresses represented
The user may, at 240 , select a group vault . At 242 , the first in the account at 248 in FIG . 56. At 270 , the first host
host computer system 14 provides the user with an option 55 computer system 14 updates the transaction list within the
whether 2 out of 3 confirmations are required or 3 out of 5 website to represent that approval is being awaited .
confirmations are required. If the user selects that 2 out of 3 Each one of the emails has a respective link that can be
confirmations are required, then the user is required to enter selected by a recipient. At 272 , a user receiving one of the
two email addresses in addition to their own email address emails reacts to the email by clicking on the link . Selection
shown in the account at 220. If the user selects that 3 out of 60 of the link causes an authorization instruction to be trans
5 confirmations are required , then the user is required to mitted from a device of the respective user to the first host
enter four email addresses in addition to their email address computer system 14. At 274 , the first host computer system
shown in the account at 220 . 14 detects the authorization instruction received in response
At 224 , the interface of the website is updated to request to one of the emails that have been transmitted. Selection of
the additional email addresses from the user . The interface 65 the link on the email opens a browser on the recipient's
typically includes fields for the user to enter the additional device and displays a message that the authorization has
email addresses . been successfully approved .
US 10,755,241 B2
25 26
At 276 , the recipient of a second one of the emails reacts At 306 , the first host computer system 14 generates a seed
to the email by clicking the link on the second email to send for a master key. At 308 , the first host computer system 14
an authorization instruction . At 278 , the first host computer uses the seed generated at 306 to generate a master key. The
system 14 detects the authorization instruction transmitted at master key includes a public key for the master key and a
276 and displays a web page indicating that the authoriza- 5 private key for the master key. At 310 , the first host
tion has been successfully approved . computer system 14 stores the public key for the master key
When all the predetermined approvals have been and , at 312 , stores the private key for the master key. The
received , the first host computer system 14 proceeds, at 280 , combination of the keys stored at 310 and 312 form a master
to update the transaction list to indicate that clearance is key set 314 .
being awaited . At 282 , only if the minimum number of 10 A generation script 316 initially resides on the first host
approvals are detected , the first host computer system 14 computer system 14. At 318 , the first host computer system
starts a countdown timer and sends an email to the user of 14 transmits the generation script 316 to the first user device
the account informing the user that the bitcoin will be 18. The first user device 18 receives the generation script
transferred after 48 hours . Block 284 represents the trans 15 316 , which is executable on the first user device 18 .
mission of three email reminders to the user during the 48 At 320 , the generation script 316 generates a seed for a
hour waiting period. Each email includes the time remaining shared key. The generation script 316 includes a key gen
before the 48 hours will have elapsed and the amount of eration algorithm . At 321 , the key generation algorithm uses
bitcoin that will be transferred out of the vault. Each email the seed generated at 320 to generate a shared key. The
also includes a “ Cancel ” link . The user can select the 20 shared key includes a public key and a private key .
" Cancel” link , which caused the transmission of a cancel The private key for the shared key is shown at 322. The
instruction to the first host computer system 14. The cancel generation script 316 also includes an interface with a field
instruction will cancel the transfer of the bitcoin and there for a user to enter a password via a keyboard . At 324 , the
fore the request that was transmitted at 262 . user enters the password into the interface. The generation
At 286 , the first host computer system 14 detects an end 25 script 316 also includes an encryption algorithm . At 326 , the
of the time period. The first host computer system 14 then encryption algorithm generates an encrypted seed from the
transfers the amount of bitcoin out of the vault and in to the private key shown at 322 and the password entered at 324 .
destination selected at 262. The first host computer system At 328 and 330 , the key generation algorithm and encryp
14 also updates the transaction list on the website to indicate tion algorithm respectively send the public key of the shared
that the transaction has been cleared . 30 key and the encrypted seed to the first host computer system
FIG . 58 illustrates components of the first host computer 14. At 332 , the first host computer system 14 stores the
system 14 that are used for carrying out the method shown public key for the shared key and, at 334 , stores the
in FIGS . 56 and 57 , including an account 290 of a user, a encrypted seed for the shared key. The public key stored at
website 292 , a vault establishment wizard 294 , a vault 332 and the encrypted seed 334 can be viewed as a shared
management module 296 and the transaction processor 154 35 key set 336. Additionally, the private key shown at 322
hereinbefore described . The vault establishment wizard 294 forms part of the shared key set 336. The private key shown
is programmed to execute the establishment of the vault as at 322 is however never transmitted from the first user
described with reference to FIG . 56. The vault management device 18 to the first host computer system 14 .
module 296 is programmed to manage the vault as described At 338 , the generation script 316 further generates a seed
with reference to FIG . 57. A user accesses the website 292 40 for a user key. At 340 , the key generation algorithm uses the
and downloads an interface so as to interact via the website seed generated at 338 to generate a user key. The user key
292 with the vault establishment wizard 294 and the vault includes a public key for the user key and a private key for
management module 296. The vault management module the user key. At 342 , the key generation algorithm transmits
296 provides instructions to the transaction processor 154 to only the public key for the user key to the first host computer
transfer the bitcoin out of the vault . 45 system 14. At 344 , the first host computer system 14 stores
FIG . 59 shows the email that is transmitted at 228 in FIG . the public key for the user key.
56. FIG . 60 shows an interface of the website 292 in FIG . 58 At 346 , the generation script 316 displays the private key
when the user requests a transfer out of a vault at 262 in FIG . for the user key to the user. The user can then store the
57. FIGS . 61 and 62 show the emails that are transmitted at private key manually on the first user device 18 or write it
268 in FIG . 57. FIG . 63 shows the interface of the website 50 down for later use . The first user device 18 never transmits
after the minimum number of approvals are received and the the private key displayed at 346 to the first host computer
countdown clock has been started at 282 in FIG . 57 . system 14. The combination of the public key for the user
Email addresses are used in the exemplary embodiment key stored at 344 and the private key for the user key
for electronic communication via email . Another embodi displayed at 346 form a user key set 348 .
ment may make use of other electronic communication 55 FIG . 65 illustrates how the user - controlled vault is used
addresses such as text messages to phone numbers or by the user . At 360 , the user of the first user device 18 creates
messages through social networks. Such messages may and transmits a request to transact using bitcoin of the
include authorization links as described or authorization user - controlled vault. At 362 , the request reaches the trans
may be obtained otherwise such as sending a reply message action processor 154 hereinbefore described . At 364 , the first
and including “ Y ” or “ Yes ” in the reply message . A sec- 60 host computer system 14 creates an authorization for the
ondary electronic communication address may be an indi transaction .
vidual address or a group address . The master key set 312 , shared key set 336 and user key
FIG . 64 illustrates the establishment of a user - controlled set 334 are replicated from FIG . 64 and the same reference
vault. At 302 , a user at the first user device 18 transmits a numerals apply. It should however be understood that these
request for a user -controlled vault to the first host computer 65 keys are stored or displayed in FIG . 64 and that the stored
system 14. At 304 , the first host computer system 14 and displayed keys are not stored but only retrieved and used
responds to the request to initiate key generation . in FIG . 65 .
US 10,755,241 B2
27 28
At 366 , the first host computer system 14 signs the host computer system 14 proceeds to 398 to provide an
authorization 364 with the private key for the master key. authorization for the transaction due to the signature being
Such signature then allows for an authorization to transact at correct. The authorization provided at 398 may be one of the
368. As shown in 370 , two out of three authorizations are authorizations required at 370 .
required in order to transact and the authorization provided 5 What should be noted this time is that the password
at 368 may form one of the two authorizations. entered at 376 is never transmitted to the first host computer
A verification script 372 initially resides on the first host system 14. Similarly, the private key entered at 390 is never
computer system 14. At 373 , the first host computer system transmitted to the first host computer system 14. The user's
14 initiates key collection by transmitting the verification control over the password and private key effectively dis
script 372 to the first user device 18. The verification script 10 allows the transaction from being processed outside of the
372 is executable on the first user device 18. Both the user's control.
generation script 316 in FIG . 64 and the verification script After two out of the three authorizations have been
372 in FIG . 65 may be in the form of JavaScriptTM that is received at 370 , the first host computer system 14 proceeds
executable by a browser on the first user device 18 . at 400 to authorize the transaction with the transaction
The encrypted seed stored at 334 on the first host com- 15 processor 154 .
puter system 14 is transmitted together with the verification FIG . 66 illustrates an address generator 402 that is used to
script 372 and is received at 374 by the first user device 18 . generate addresses such as the bitcoin address that are used
The verification script 372 further includes an interface with for the transaction requested at 360 in FIG . 65. A master key
a field for entering a password. At 376 , the user enters the seed 404 , shared key seed 406 and user key seed 408 are
same password that the user entered at 324 in FIG . 64 into 20 generated. The master key seed 404 is used to generate a
the field provided in the interface using a keyboard . The master public key 410 and a master private key 412. The
verification script 372 further includes a decryption algo shared key seed 406 is used to generate a shared public key
rithm . At 378 , the decryption algorithm uses the encrypted 414 and a shared private key 416. The user key seed 408 is
seed and the password to decrypt the encrypted seed and used to generate a user public key 418 and user private key
obtain the private key. The encryption at 326 in FIG . 64 and 25 420 .
decryption at 378 in FIG . 65 may follow the BIP38 protocol Each one of the keys 410 to 420 may be used to generate
which is commonly understood by those skilled in the art of child keys M/0 , M/ 1 .... The shared keys at each level may
bitcoin encryption . then be combined to generate an address. For example, the
The authorization 364 is transmitted together with the M / O keys of the master public key 410 , shared public key
verification script 372 to the first user device 18. The 30 414 and user public key 418 may be used to generate an
verification script 372 further has a signature algorithm . At address ( Address 0) . The M / O level may for example be the
380 , the signature algorithm signs the authorization with the public keys stored at 310 , 332 and 334 in FIG . 64. The
private key. The signature algorithm then transmits the address ( Address 0) may for example be the bitcoin address
signed authorization ( together with the signature) to the first for the transaction . Similarly, the M / 1 level keys of the
host computer system 14 . 35 master public key 410 , shared public key 414 and user
The first host computer system 14 has a verification public key 418 may be used to generate another address
module . As will be commonly understood as those skilled in (Address 1 ) . The further addresses may be generated to
the art, a verification module is an algorithm that verifies a create further bitcoin addresses of for other purposes.
signature that was created with a private key using a public FIG . 67 of the accompanying drawings illustrates the first
key. At 382 , the verification module verifies the signature 40 host computer system 14 , a partner computer system 422
using the same public key stored at 332 for the shared key and a receiver computer system 424. The receiver computer
in the shared key set 336 that also includes the encrypted system 424 includes a receiver browser 426. The partner
seed stored at 334. At 384 , the verification module deter computer system 422 has a website, in the present example
mines whether the signature is correct. If the signature is not a blog with a blog post 428 that has a blog post URL 430 .
correct, then the first computer system 14 returns to 374 45 At 432 , a user of the receiver computer system 424 uses the
where the encrypted key is received and the user enters a receiver browser 426 to create the blog post 428 .
password . If, at 384 , a determination is made that the The first host computer system 14 has a wallet in the form
signature is correct, then the first host computer system 14 of receiver account 434 , an embedded code generator and a
proceeds to 386 to provide an authorization due to the button ID generator 438. At 440 , the user of the receiver
signature being correct. The authorization at 386 may be one 50 computer system 424 creates the receiver account 434. The
of the authorizations required at 370 in order to authorize the receiver account 434 has login details 442 and a receiver
transaction . account identifier (ID ) 444. At 446 , the user of the receiver
The verification script 372 further includes an interface computer system 424 logs into the receiver account 434 and
for entering the private key of the user key that was enters the blog post URL 430 through the user interface 36
previously displayed at 346 to the user . At 390 , the user 55 (FIG . 1B ) . The blog post URL 430 is then stored in asso
enters the private key into the field provided therefor .At 392 , ciation with the particular receiver account 434 with the
a signature algorithm forming part of the verification script wallet management module 44 (FIG . 1B ) . At 448 , the first
372 signs the authorization with the private key that has been host computer system 14 provides the blog post URL 430 to
entered by the user. The signature algorithm then transmits the embedded code generator and button ID generator 438 .
the signed authorization ( together with the signature ) to the 60 The embedded code generator 438 then generates an embed
first host computer system 14. At 394 , a verification module ded code 450 and , at 452 , transmits the embedded code 450
verifies the signature using the public key that was stored at to the receiver browser 426. The embedded code 450
344. At 396 , the verification module determines whether the includes the blog post URL 430 , receiver account ID 444
signature is correct. If the signature is incorrect, then the first and a startup caller 454 .
host computer system 14 instructs the verification script 372 65 The blog post 428 on the partner computer system 422 has
to return to 390 where the user is again asked for the private a frame for pasting the embedded code 450 due to prior
key for the user key. If the signature is correct, then the first agreement between operators of the first host computer
US 10,755,241 B2
29 30
system 14 and the partner computer system 422. At 456 , the a session call to the first host computer system 14. The
user of the receiver computer system 424 copies the embed session call 496 includes the cookies 472 .
ded code 450 received at 452 and pastes the embedded code The first host computer system 14 includes a session
450 into the frame of the blog post 428. The embedded code responder 498 that receives the session call 496. At 500 , the
450 is then embedded and forms part of the HyperText 5 session responder 498 checks all data for the button ID 460
Markup Language (HTML) of the blog post 428 . that has been received in the session call 496. The data
A blog post 428 is used herein to describe the invention associated with the button ID 460 may include a bitcoin
by way of example. It should however be understood that the address 502 , although no bitcoin address may be included
invention may have broader application. A URL of a page
may for example have a video , song or news article. Such a 10 within
session
the cookies 472 of the session call 496. At 504 , the
responder 498 determines whether a bitcoin address
page will typically have a frame for pasting the embedded was received
code 450. Alternatively, media content such as a video may bitcoin addressin was the cookies 472 of the session call 496. If no
received, the first host computer system
not have a separate frame for pasting the embedded code . 14 executes a bitcoin address generator 506. The bitcoin
Instead , another manner of activating payment features of address generator 506 then generates a bitcoin address and ,
the invention may be provided , such as a separate URL link , 15 at 508 , stores the bitcoin address in association with the
voice activation , detection of human gestures of a user, etc. button ID 460. The newly saved bitcoin address is repre
The button ID generator ( see 438 ) generates a unique
button ID . At 458 , the button ID generator stores the button sented as bitcoin address 510. At 512 , the session responder
ID as button ID 460 within a data store of the first host 498 transmits the bitcoin address 510 that has been gener
computer system 14. At 462 , the button ID generator 438 20 ated by the bitcoin address generator 506 to the sender
stores the button ID 460 in association with the particular computer system 464. At 514 , the session script 486 stores
receiver account ID 444 and particular blog post URL 430 . the bitcoin address 510 in association with the button ID 460
Multiple receiver accounts may exist within the first host within the sender cookies 472. Upon a browser refresh , the
computer system 14. In addition , a receiver account may process started at 466 in FIG . 68 is restarted and all cookies
have multiple blog post URL’s associated therewith . Each 25 are stored from earlier browser sessions are collected and
pair of a respective receiver account ID and respective blog transmitted by the startup caller 454 .
post URL have a unique button ID . At 516 , the session responder 498 determines whether the
FIG . 68 shows the first host computer system 14 , the sender computer system 464 is signed into a sender account.
partner computer system 422 and a sender computer system The determination is made based on whether a signed -in
464. The sender computer system 464 has a sender browser 30 cookie is found among the cookies transmitted in the session
( not shown ). At 466 , the sender browser downloads the blog call 496. If no signed - in cookie is found, then the session
post 428 from the partner computer system 422. The startup responder 498 proceeds to 518. At 518 , the session
caller 454 is a script, e.g. JavaScript , that automatically responder 498 sends a sign - in panel 520 , a sign - in script 522 ,
executes on the sender computer system 464. At 470 , the a listen code 524 , a third party payment script 526 , and a pull
startup caller 454 retrieves all sender cookies 472 on the 35 code 528 to the sender computer system 464. The session
sender computer system 464. The startup caller 454 , at 474 , script 486 creates an overlay window that includes the
transmits a startup call to the first host computer system 14 . sign- in panel 520 with a sign- in button 530 having the
The startup call includes the cookies 472 , the blog post URL sign- in script 522 associated therewith . The user can select
430 and the receiver account ID 444 . the sign - in button 530 which , at 532 , initiates the sign - in
The first host computer system 14 includes a startup call 40 script 522. The sign - in script 522 creates and opens a further
responder 476 that receives the startup call 474. The startup window (not shown) that allows the sender of the sender
call responder 476 , at 478 , uses the blog post URL 430 and computer system 464 to enter login details 534 of a sender
receiver account ID 444 received in the startup call 474 to account 536. At 540 , the sign - in script 522 signs the sender
identify the particular button ID 460 . computer system 464 into the sender account 536 using the
The button ID 460 in storage may have bits 480 repre- 45 login details 534. The sign - in script 522 , at 548 , stores a
senting all payments made in association with the button ID signed - in cookie 549 within the sender cookies 472. The
460. At 482 , the startup call responder 476 retrieves the bits sign- in panel 520 further includes two payment selections ,
480 associated with the button ID 460 from the data store . including a third party wallet button 544 , and a Quick
At 483 , the startup call responder 476 transmits a startup Response (QR) code 546. The third party payment script 526
call response to the sender computer system 464. The startup 50 is stored in association with the third party wallet button
call response transmitted at 483 is in response to the startup 544. The listen code 524 and pull code 528 are stored in an
call received at 474. The startup call response includes a executable manner within the sender computer system 464 .
button 484 , the bits 480 , a session script 486 and the button The session script 486 retrieves the bitcoin address 510 from
ID 460. A display 490 of the sender computer system 464 the sender cookies 472 and displays the bitcoin address 510
displays the blog post 428. The embedded code 450 has 55 within the sign - in panel 520 .
added the button 484 and the bits 480 to the blog post 428 . As shown in FIG . 70 , if the determination at 516 is made
The button 484 is a two - dimensional button that is selectable that the sender computer system 464 is signed - in to the
by a user of the sender computer system 464. The session sender account 436 , or after the sender computer system 464
script 486 is associated with the button 484 so as to be signs - in at 540 in FIG . 69 , the session responder 498
executable when the user selects the button 484 . 60 proceeds to 550. At 550 , the session responder 498 transmits
The embedded code 450 , at 491 , stores the button ID 460 a signed - in panel 552 , the listen code 524 , the third party
within the sender cookies 472. The button ID 460 stored payment script 526 , the pull code 528 and a host account
within the sender cookies 472 can now be used to identify payment script 554 to the sender computer system 464. The
the button ID 460 within the first host computer system 14 . signed -in panel 552 is the same as the sign- in panel 520 with
In FIG . 69 , the user has selected the button 484 which , at 65 the exception that it includes a host account button 556
492 , initiates the session script 486. The session script 486 , instead of the sign -in button 530. The third party payment
at 494 , retrieves the sender cookies 472 and, at 496 , makes script 526 is stored in association with the third party wallet
US 10,755,241 B2
31 32
button 544. The host account payment script 554 is stored in the bitcoin address 510 ) to a third party transaction proces
association with host account button 556 . sor such as the third party transaction processor 562 .
Selection by the user of the host account button 556 The button 484 shown in FIG . 69 can be used as a Tip
initiates at 560 the host account payment script 554. The host button . A user of the sender computer system 464 can use the
account payment script 554 transmits an instruction to the 5 button 484 to make a small discrete payment to the user of
transaction processor 154 of the selection . At 561 , the the receiver computer system 424. Such a payment may, for
transaction processor 154 makes a payment out of the sender example , be as a reward for the content of the blog post 428 .
FIG . 72 shows a system 600 for transacting bitcoin . An
account 536 to the receiver account 434 as hereinbefore
Internet interface 602 allows for user computers (user com
described without going through the bitcoin network or the 10 puters
block chain . A to C ) to connect to the system 600 over the Internet.
At 564 , the transaction processor 154 updates the bits 480 602 to gateways
Order
receive
604 are connected to the Internet interface
buy and sell offers via the Internet interface
by adding the bits of the present transaction to the bits 480 602 from the user computers A to C. A matching engine 606
already stored within the data store . The bits 480 within the is connected to the order gateways 604. The matching
data store thus represent an ongoing tally of all payments 15 engine 606 can receive the buy and sell offers from the order
made in association with the button ID 460. The bitcoin gateways 604 .
addresses 502 and 510 represent bitcoin addresses that are A feed generator 608 is connected to the Internet interface
generated for different sender computer systems 464 using 602. The matching engine 606 provides an output to a
the same button ID 460 . multicast pipeline 610. The feed generator 608 is connected
After the host account payment script 554 transmits the 20 to the multicast pipeline 610. The feed generator 608
instruction to the transaction processor 15 , the host account receives the buy and sell offers from the multicast pipeline
payment script 554 initiates the pull code 528. The pull code 610 and displays any buy and sell offers via the Internet
528 , at 574 , pulls the new bit count from the bits 480 in the interface 602 to the user computers A to C. Users can thus
storage of the first host computer system 14. At 566 , the pull view any buy and sell offers already in the system before
code 528 updates the bits 480 in the blog post 428 based on 25 making their own buy and sell offers .
the bits that have been pulled by the pull code 528 in FIG . The matching engine 606 can match buy and sell offers
70 . and broadcast the matches to the multicast pipeline 610. The
As shown in FIG . 71 , the user selects the third party wallet feed generator 608 displays the matches via the Internet
button 544 which, at 560 , causes execution of the third party interface 602 to the user computers A to C.
payment script 526. The third party payment script 526 then 30 An exchange database 612 includes records of bitcoin and
transmits a transaction ( of bitcoin to the bitcoin address 510 ) currency held by users A to C corresponding to the user
to a third party transaction processor 562. The third party computers A to C. A clearing module 614 is connected to the
transaction processor 562 is hosted by a host computer multicast pipeline 610 and receives matches from the mul
system other than the first host computer system 14. At 564 , ticast pipeline 610. An exchange 616 is connected to the
the third party transaction processor 562 broadcasts the 35 clearing module 614. The exchange 616 is also connected to
transaction to the bitcoin network 12 and it is picked up by the Internet interface 602. Users at the user computers A to
the blockchain . C can provide instructions via the Internet interface 602 to
The first host computer system 14 further includes a block the exchange 616 to transfer bitcoin or currency. The
chain checker 567 and a bit updater 568. The block chain exchange 616 has a number of functions, including calcu
checker 567 , at 570 , periodically checks the block chain . For 40 lating total amounts of bitcoin and currency as represented
purposes of this discussion , the block chain checker 567 in the exchange database 612 , cross checking bitcoin and
checks the block chain to determine whether there are any currency totals between the exchange database 612 and an
new transactions for the bitcoin addresses 502 and 510 exchange user 618 , transferring bitcoin and currency
stored in association with the button ID 460. If the block between wallets A to C that correspond respectively to the
chain checker 567 finds any further transactions, the block 45 users A to C in the exchange database 612 , updating bitcoin
chain checker 567 notifies the bit updater 568. At 572 , the bit and currency amounts of the users A to C in the exchange
updater 568 updates the bits 480 that are associated with the database 612 , and may receive and execute instructions from
respective bitcoin address 502 or 510. The bits 480 are the clearing module 614 to transfer bitcoin and currency
updated by adding bits for any new transactions that have between the users A to C in the exchange database 612 .
been picked up by the block chain checker 567 . 50 The exchange is connected to a ledger 620. The ledger
At 574 , the bit updater 568 transmits a push update 620 hold records of wallets A to C and further functions to
notification to the sender computer system 464. The listen cross - check balances between the exchange database 612
code 524 receives the push update notification . Websocket and exchange user 618 .
technology may for example be used for the push update FIG . 73a shows the beginning of a transfer - in algorithm
notification in order to open an interactive communication 55 that is executed by the system 600. A user at user computer
link . The listen code 524 is continuously active and therefore A has $ 10 of currency in the exchange database 612. For
continuously listens for push update notifications. When the purposes of discussion , no other users have any bitcoin or
listen code 524 receives the push update notification, the currency . The exchange 616 calculates the total amount of
listen code 524 initiates the pull code 528. The pull code currency and bitcoin within the exchange database 612 and
528 , at 574 , pulls the new bit count from the bits 480 in 60 records the total amount as $ 10 and 0 bitcoin . The exchange
storage. At 566 , the pull code 528 updates the bits 480 in the user 618 has $ 10 , representing a previous transfer from
blog post 428 based on the bits that have been pulled by the wallet A to the exchange user 618 .
pull code 528 in FIG . 70 . At la , a user at user computer B requests a transfer via the
The QR code 546 may be scanned by an app on a mobile Internet interface 602. The transfer may for example be to
phone . The bitcoin address 510 is encoded in the QR code 65 transfer $ 20 from wallet B to the exchange user 618. At 1b ,
546. The app can decode the QR code 546 to extract the the Internet interface 602 provides the transfer request to the
bitcoin address 510 and transmit a transaction ( of bitcoin to exchange 616. At 2a , the exchange 616 sends a cross - check
US 10,755,241 B2
33 34
request to the ledger 620 and at 2b the ledger 620 cross At 9a , the clearing module 614 updates user A within the
checks the totals in the exchange database 612 and the exchange database 612 by adding 2 bitcoin and subtracting
exchange user 618 before proceeding with a transfer. In the $ 10 from user A. At 9b , the clearing module 614 updates
present example, the exchange database 612 has $ 10 and 0 user C by subtracting 2 bitcoin from and adding $ 10 to user
bitcoin and the exchange user 618 has $ 10 and 0 bitcoin . The 5 C. The clearing module 614 makes the updates directly to
totals therefore match . If either the currency or bitcoin totals the exchange database 612 .
do not match , the exchange 616 does not make any further There is no need for recalculating the totals within the
transfers and provides an alert to an operator. The operator exchange
currency
database 612 at this stage . The same amount of
or bitcoin that has been subtracted from one user
will then remedy any mismatches and then reactivate the
exchange 616. Because the totals match, the exchange 616 10 has been added to another
thus still indicates totals ofuser
$ 30. The
andexchange
5 bitcoin .database 612
proceeds with the transfer. FIG . 73e shows a withdrawal algorithm that can be
As shown in FIG . 73b , the exchange 616 , at 3 , transfers carried
$ 20 from wallet B to the exchange user 618. The exchange a user atoutuser after the trading algorithm in FIG . 73d . At 10a ,
user 618 calculates the total amount held by the exchange 15 example, $ 10 . computer C requests a withdrawal of , for
The request is received via the Internet
user 618 as $ 30 , representing the $ 10 that was there before interface 602 and is passed on to the exchange 616 at 10b .
the transfer plus another $ 20 because of the transfer. At 11a , the exchange 616 sends a cross - check request to
At 4a , the exchange 616 records $ 20 for user B in the the ledger 620 and at 11b the ledger 620 cross checks the
exchange database 612. At 4b , the exchange 616 updates the totals before proceeding. In the present example, the amount
totals and records a total amount of $30 , representing the 20 of bitcoin in the exchange user 618 and the total amount of
$ 10 held by user A and the $ 20 that has been added for user bitcoin represented in the exchange database 612 are the
B. same and the total currency amount in the exchange user 618
FIG . 73c illustrates the totals in the exchange database and in the exchange database 612 are the same. Should
612 and the exchange user 618 after a further transfer either of these two comparisons result in a mismatch , the
wherein a user at the user computer C has requested a 25 exchange 616 will not make any withdrawal and create an
transfer of 5 bitcoin from wallet C to the exchange user 618 . alarm for an operator.
The exchange user 618 now holds 5 bitcoin and $ 30 . User As shown in FIG . 73f, at 12 , the exchange 616 transfers
C , within the exchange database 612 , now holds 5 bitcoin . $ 10 from the exchange user 618 to the wallet C. The
The totals held with the exchange database 612 are $ 30 and exchange user 618 now has $ 20 , representing the $ 30 in
5 bitcoin . For purposes of discussion, this ends the transfer- 30 FIG . 73e minus the $ 10 that has been transferred out . At 13a ,
in algorithm that was started in FIG . 73a . the exchange 616 adds a representation for user C in the
FIG . 73d shows a trading algorithm that is carried out exchange database 612 showing a withdrawal of $ 10 . At
after the transfer - in algorithm if FIGS . 73a to 730. At a 13b , the exchange 616 updates the totals . Because user C has
user ( buyer ) at user computer A submits a buy offer of 2 made a withdrawal of $ 10 , the total currency amount within
bitcoin at $ 5 each ( $ 10 total ) . As noted previously, all offers 35 the exchange database 612 amounts to $ 20 . The amount of
are transmitted via the Internet interface 602 , one of the bitcoin is still the same . The total amounts in the exchange
order gateways 604 , the matching engine 606 and the user 618 and in the exchange database 612 are thus the same .
multicast pipeline 610 to the feed generator 608 which Other users may submit similar withdrawal requests. For
displays the offers on the Internet interface 602. A user at example , a user at user computer A may request a with
user computer C can thus see the buy offer submitted by the 40 drawal of 1 bitcoin . The exchange 616 then cross checks the
user at user computer A. At 5b , the user ( seller) at user total amounts, makes a transfer of 1 bitcoin from the
computer C submits a sell offer for 2 bitcoin at $ 5 each to exchange user 618 to wallet A and updates the exchange
the Internet interface 602. At 5c , the buy and sell offers are database 612 by deducting 1 bitcoin from user A and updates
submitted by the Internet interface 602 to one of the order the total amount of bitcoin to 4 bitcoin .
gateways 604. At 5d, the order gateway 604 provides the buy 45 FIG . 74 shows a diagrammatic representation of a
and sell offers sequentially to the matching engine 606 . machine in the exemplary form of a computer system 900
As mentioned, the user at user computer C can see the buy within which a set of instructions, for causing the machine
offer of the user at user computer A before submitting the to perform any one or more of the methodologies discussed
sell offer. In another example, the user at user computer C herein , may be executed . In alternative embodiments, the
can first submit the sell offer and the sell offer can be seen 50 machine operates as a standalone device or may be con
by the user at user computer A. The buy and sell offers will nected (e.g. , networked ) to other machines . In a network
typically be received by the matching engine 606 at different deployment, the machine may operate in the capacity of a
times . server or a client machine in a server - client network envi
Multiple users may submit one or more buy and sell ronment, or as a peer machine in a peer - to -peer (or distrib
offers. The matching engine 606 attempts to match the buy 55 uted ) network environment. The machine may be a personal
and sell offers to one another. At 6 , the matching engine 606 computer ( PC ) , a tablet PC , a set -top box ( STB ) , a Personal
has matched the buy and sell offers received from users at Digital Assistant ( PDA) , a cellular telephone, a web appli
the user computers A and C. ance , a network router, switch or bridge, or any machine
The matching engine 606 then provides a broadcast of the capable of executing a set of instructions ( sequential or
match over the multicast pipeline 610 discussed with refer- 60 otherwise) that specify actions to be taken by that machine .
ence to FIG . 72. At 7a , the feed generator 608 receives a Further, while only a single machine is illustrated, the term
multicast that includes the match . At 7b , the clearing module “ machine ” shall also be taken to include any collection of
614 receives the same multicast that includes the match . At machines that individually or jointly execute a set (or
8 , the feed generator 608 provides a feed to the Internet multiple sets ) of instructions to perform any one or more of
interface 602 that includes the match . As previously men- 65 the methodologies discussed herein .
tioned , the feed generator 608 also provides a feed of buy The exemplary computer system 900 includes a processor
and sell offers to the Internet interface 602 . 930 ( e.g. , a central processing unit (CPU) , a graphics
US 10,755,241 B2
35 36
processing unit ( GPU) , or both ), a main memory 932 ( e.g. , receiving , by the host computer system , the first code, the
read -only memory (ROM ) , flash memory , dynamic random second code and the third code via the first restoration
access memory (DRAM ) such as synchronous DRAM API , the second restoration API and the third restora
( SDRAM ) or Rambus DRAM (RDRAM ), etc. ), and a static tion API , respectively ;
memory 934 (e.g. , flash memory, static random access 5 assembling, by the host computer system , the first private
memory (SRAM , etc. ) , which communicate with each other key of the first vault Bitcoin address by using each code
via a bus 936 . and storing the first private key ;
The computer system 900 may further include a video transferring, by the host computer system , the first bitcoin
display 938 ( e.g. , a liquid crystal displays ( LCD ) or a 10 value from the first vault bitcoin address to the first
cathode ray tube (CRT ) ). The computer system 900 also bitcoin address of the first wallet by using the
includes an alpha -numeric input device 940 ( e.g. , a key assembled first private key;
board ), a cursor control device 942 ( e.g. , a mouse) , a disk calculating, by the host computer system , that a first ratio
of total bitcoin value within the first wallet to total
drive unit 944 , a signal generation device 946 (e.g. , a bitcoin value within the first vault is above a target
speaker ), and a network interface device 948 . 15 range ;
The disk drive unit 944 includes a machine - readable automatically decreasing, by a local controller of the host
medium 950 on which is stored one or more sets of instruc computer system , the total bitcoin value within the first
tions 952 ( e.g. , software ) embodying any one or more of the wallet to a new total bitcoin value that results in a
methodologies or functions described herein . The software calculated second ratio of total bitcoin value within the
may also reside, completely or at least partially , within the 20 first wallet to total bitcoin value within the first vault
main memory 932 and / or within the processor 930 during that is within the target range, wherein automatically
execution thereof by the computer system 900 , the memory decreasing the total bitcoin value within the first wallet
932 and the processor 930 also constituting machine read comprises:
able media. The software may further be transmitted or identifying, by the local controller, a set of bitcoin
received over a network 954 via the network interface 25 addresses within the first wallet with appropriate
device 948 . associated values of bitcoin ,
While certain exemplary embodiments have been transferring, by the local controller, the associated
described and shown in the accompanying drawings, it is to values of bitcoin from the identified set of bitcoin
be understood that such embodiments are merely illustrative 30 addresses within the first wallet to an intermediate
and not restrictive of the current invention , and that this wallet, and
invention is not restricted to the specific constructions and transferring, by the local controller, the value of bitcoin
arrangements shown and described since modifications may from the intermediate wallet to the first vault ;
occur to those ordinarily skilled in the art. transacting, by the host computer system , bitcoin value
from an address of the first wallet ;
What is claimed :
35 calculating, by the host computer system , that a third ratio
of total bitcoin value within the first wallet to total
1. A method comprising : bitcoin value within the first vault is below the target
storing , by a local storage of a bitcoin host computer range ;
system , a first private key of a first vault Bitcoin automatically increasing , by the local controller, the total
address; 40 bitcoin value within the first wallet to a new total
splitting, by the host computer system , the first private bitcoin value that results in a fourth calculated ratio of
key of the first vault bitcoin address into a plurality of total bitcoin value within the first wallet to total bitcoin
overlapping codes ; value within the first vault that is within the target
transmitting, by the host computer system , each code to a range , wherein automatically increasing the total bit
separate remote storage of a plurality of remote stor- 45 coin value within the first wallet comprises:
ages via a network interface device , wherein each assembling, by an assembler of the bitcoin host com
remote storage stores a respective one of the received puter system , the first private key of the first vault
codes; bitcoin address by using the first code , the second
removing, by the host computer system , the first private code, and the third code received via respective
key from the host computer system ; 50 restoration APIs , and
transferring, by the host computer system , a first bitcoin transferring, by the bitcoin host computer system , value
value of a first bitcoin address of a first wallet of a first of at least the first vault bitcoin address to at least one
user to the first vault bitcoin address such that the first bitcoin address of the first wallet , by using the
bitcoin address has no bitcoin value after the transfer; assembled first private key.
providing, by a first remote storage of the plurality of 55 2. The method of claim 1 , further comprising the host
remote storages , a first one of the codes to the host computer system communicating with a first user device of
computer system via a first restoration application the first user via the Internet .
programmable interface (API ) of the host computer 3. The method of claim 2 , further comprising the host
system ; computer system communicating with a plurality of user
providing, by a second remote storage of the plurality of 60 devices via the Internet.
remote storages, a second one of the codes to the host 4. The method of claim 1 , wherein the host computer
computer system via a second restoration API of the system includes the first wallet , and wherein the first wallet
host computer system ; is a hot wallet , wherein the first wallet includes a plurality
providing, by a third remote storage of the plurality of of bitcoin addresses, wherein the host computer system
remote storages , a third one of the codes to the host 65 includes a first vault , and wherein the first vault includes a
computer system via a third restoration API of the host plurality of bitcoin addresses including the first vault bitcoin
computer system ; address.
US 10,755,241 B2
37 38
5. A system comprising: wherein the host computer system transacts bitcoin
a remote node of a Bitcoin network ; value from an address of the first wallet ,
a bitcoin host computer system that includes a local wherein the host computer system periodically calcu
controller, a first wallet of a first user and a first vault lates a ratio of total bitcoin value within the first
of the first user ; 5
wallet to total bitcoin value within a first vault ,
a plurality of remote storages ; and wherein , in response to the calculated ratio being above
a host node of the Bitcoin network that is communica a target range, the local controller automatically
tively coupled to the host computer system , decreases the total bitcoin value within the first
wherein a local storage of the host computer system wallet to a new total bitcoin value that results in a
stores a first private key of a first vault bitcoin 10 new calculated ratio of total bitcoin value within the
address of the first vault , first wallet to total bitcoin value within the first vault
wherein the host computer system splits the first private that is within the target range , wherein the local
key of the first vault bitcoin address into a plurality controller automatically decreasing the total bitcoin
of overlapping codes,
wherein the host computer system transmits each code 15 value within the first wallet comprises:
to a separate remote storage of the plurality of identifying a set of bitcoin addresses within the first
remote storages via a network interface device of the wallet with appropriate associated values of bit
host computer system , coin ,
wherein each remote storage stores a respective one of transferring the associated values of bitcoin from the
the received codes , 20 identified set of bitcoin addresses within the first
wherein the host computer system removes the first wallet to an intermediate wallet, and
private key from the host computer system , transferring the value of bitcoin from the intermedi
wherein the host computer system transfers a first ate wallet to the first vault,
bitcoin value of a first bitcoin address of the first wherein, in response to the calculated ratio being below
wallet to the first vault bitcoin address such that the 25 the target range , the local controller automatically
first bitcoin address has no bitcoin value after the increases the total bitcoin value within the first wallet
transfer, to a new total bitcoin value that results in a new
wherein a first remote storage of the plurality of remote calculated ratio of total bitcoin value within the first
storages provides a first one of the codes to the host wallet to total bitcoin value within the first vault that
computer system via a first restoration application 30 is within the target range, wherein the local control
programmable interface (API ) of the host computer ler automatically increasing the total bitcoin value
system , within the first wallet comprises:
wherein a second rer te storage of the plurality of assembling the first private key of the first vault
remote storages provides a second one of the codes bitcoin address by using the first code, the second
to the host computer system via a second restoration 35 code , and the third code received via respective
API of the host computer system , restoration APIs , and
wherein a third remote storage of the plurality of transferring value of at least the first vault bitcoin
remote storages provides a third one of the codes to address to at least one bitcoin address of the first
the host computer system via a third restoration API wallet , by using the assembled first private key.
of the host computer system , 40
6. The
wherein the host computer system receives the first systems Communicatively system of claim 5 , wherein the host computer
code, the second code and the third code via the first the firsturva theretcoupled .
a first user device of
restoration API , the second restoration API and the 7. The system of claim 6 , wherein the host computer
third restoration API , respectively,
wherein the host computer system assembles the first 45 system isviacommunicatively coupled to a plurality of user
private key of the first vault bitcoin address by using devices the ternet.
8.The system ofcam5, wherein the first wallets a hot
each code and storing the first private key,
wherein the host computer system transfers the first wallet , where in the frst wallet includes plurality of bitcoin
bitcoin value from the first vault bitcoin address to addresses, and wherein the first vault includes a plurality of
the first bitcoin address of the first wallet by using the 50 bitcoin addresses including the first vault bitcoin address.
assembled first private key,