US10510053B2 — Send cryptographic currency to email address (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.
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 themerchants 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 ormodal 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 embodimentmay 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
merchantwallet 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,510,053 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
14 proceeds at 248 to update the account represented at 220
a personal vault is created for a user. At 220, the user already with
has an account that the user can log into using a website . The 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 .
10 If
[email protected] . The account also has a phone num associated with one or more of the additional email addresses are not
ber associated therewith and one or more wallets as herein any accounts within the first host computer
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 accountshown 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 addresses represented in the accountat 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 usermay, 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,510,053 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. At340 , 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,510,053 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 /0 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 At432 , 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
ofthe 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 managementmodule 44 (FIG . 1B ). At 448, the first
372 signs the authorization with the private key thathas 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 thatwas 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,510,053 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.At500 , 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
not have a separate frame for pasting the embedded code . 14 executes a bitcoinreceived , the first host computer system
address generator 506. The bitcoin
Instead , another manner of activating payment features of address generator 506 then generates
the invention may be provided , such as a separate URL link , 15 at 508 , stores the bitcoin address in a association
bitcoin address and ,
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. At512 , 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 panel520 , 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 paymentscript 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. At550, 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 panel520 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,510,053 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 accountpayment 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 ofthe 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.
Order gateways
At 564, the transaction processor 154 updates the bits 480 602 to receive buy 604 are connected to the Internet interface
and sell offers via the Internet interface
by adding the bits of the present transaction to the bits 480 602 from the user computers
already stored within the data store . The bits 480 within the A to C. A matching engine 606
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.
paymentscript 526. The third party payment script 526 then 30 An exchange database 612 includes records of bitcoin and
transmits a transaction (ofbitcoin 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 clearingmodule 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 firsthost 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, at570 , 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 atuser 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,510,053 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 user618 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 exchange There is no need for recalculating the totals within the
transfers and provides an alert to an operator. The operator currency ordatabasebitcoin
612 at this stage . The same amount of
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 thus still indicates totals ofuser
been added to another $ 30. The
and exchange
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 out after the trading algorithm in FIG . 73d . At 10a ,
$ 20 from wallet B to the exchange user 618. The exchange a user at
user 618 calculates the total amount held by the exchange 15 example , user computer C requests a withdrawal of, for
$ 10 . 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 notmake 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 . 73eminus the $ 10 thathas 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. At5d , 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 machinemay 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 thatmachine .
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 thematch . 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,510,053 B2
35 36
processing unit (GPU ), or both ), a main memory 932 ( e.g., wherein the user interface link includes a uniform
read -only memory (ROM ), flash memory, dynamic random resource locator (URL ) for a user interface for claiming
access memory (DRAM ) such as synchronous DRAM the second wallet, and
(SDRAM ) or Rambus DRAM (RDRAM ), etc. ), and a static wherein establishing a new , second wallet comprises:
memory 934 (e.g., flash memory , static random access 5 the hosted email module instructing the bitcoin wallet
memory (SRAM , etc.), which communicate with each other establishment module to generate a second public
via a bus 936 . key and a second private key, store the second public
The computer system 900 may further include a video key and the second private key at a computer read
display 938 ( e.g., a liquid crystal displays (LCD ) or a able medium , generating a second bitcoin address of
cathode ray tube (CRT)). The computer system 900 also 10 the second wallet by using the second public key , and
includes an alpha -numeric input device 940 (e.g., a key recording the received second e -mail address as an
board ), a cursor control device 942 ( e.g., a mouse ), a disk identifier of the second wallet, and
drive unit 944 , a signal generation device 946 (e.g., a the hosted email module instructing the bitcoin wallet
speaker ), and a network interface device 948 . management module to record the second amount in
The disk drive unit 944 includes a machine - readable 15
medium 950 on which is stored one or more sets of instruc bitcoin specified by the transfer request in associa
tions 952 (e.g., software) embodying any one or more of the tion with the generated second bitcoin address of the
methodologies or functions described herein . The software second wallet and record transfer of the second
may also reside, completely or at least partially , within the amount in bitcoin from a first bitcoin address of the
main memory 932 and /or within the processor 930 during 20 first wallet, and
execution thereof by the computer system 900 , the memory wherein the instructions include instructions that, when
932 and the processor 930 also constituting machine read executed by the processor, control the website user
able media . The software may further be transmitted or interface to : responsive to the hosted email module
received over a network 954 via the network interface sending the e -mail that includes the user interface link
device 948 . 25 to the second user device by using the second e -mail
While certain exemplary embodiments have been address :
described and shown in the accompanying drawings, it is to receive , from the second user device for the established
be understood that such embodiments are merely illustrative second wallet, a website request that identifies the
and not restrictive of the current invention , and that this URL ,
invention is not restricted to the specific constructions and 30 transmit the user interface to the second user device as
arrangements shown and described since modificationsmay a response to the website request , the user interface
occur to those ordinarily skilled in the art . including a field for a password and a field for
confirmation of the password for the established
What is claimed : second wallet,
1. A system for processing a request to perform a Bitcoin 35 receive the password for the second wallet from the
transaction using a bitcoin address, the system comprising : second user device via the user interface , wherein the
a bitcoin wallet host computer system communicatively password is stored in the computer readablemedium
coupled to a host node of a Bitcoin network , and in association with the second wallet,
communicatively coupled to a first user device and a wherein the website user interface is constructed to trans
second user device via the Internet, the bitcoin wallet 40 mit the user interface to the second user device after
host computer system comprising: establishing the second wallet .
a processor ; 2. The system of claim 1 , wherein the second wallet is
a network interface device connected to the processor ; stored in a data store connected to the processor.
and 3. The system of claim 2 , wherein the second wallet
a computer readable medium connected to the processor 45 includes a plurality of bitcoin addresses wherein each bit
and storing a set of instructions that are executable by coin address represents a respective transfer ofbitcoin to the
the processor, the instructions comprising : instructions second wallet.
that when executed control the bitcoin wallet host 4. The system of claim 1, further comprising: the first user
computer system to execute : a website user interface, a device ; and the host node.
hosted email module coupled to the website user inter- 50 5. The system of claim 4 , further comprising : the second
face via a login module, a bitcoin wallet management user device.
module coupled to the hosted email module , and a 6. The system of claim 1, wherein first user interface
bitcoin wallet establishment module coupled to the includes a button for receiving user -input indicating accep
website user interface and the hosted email module, tance of a user agreement for the second wallet.
wherein the instructions further include instructions that, 55 7. A method of transacting bitcoin comprising : with a
when executed by the processor, control the hosted bitcoin wallet host computer system that includes a website
email module to : responsive to the website user inter user interface, a hosted email module coupled to the website
face receiving from the first user device a transfer user interface via a login module , a bitcoin walletmanage
request that specifies a second e-mail address of the ment module coupled to the hosted email module , and a
second user device and information specifying a second 60 bitcoin wallet establishment module coupled to the website
amount in bitcoin to be transferred from a first wallet, user interface and the hosted email module :
simultaneously : responsive to the website user interface receiving from a
establish a new , second wallet of the second e-mail first user device a transfer request that specifies a
address of the transfer request , and second e -mail address of a second user device and
send an e -mail that includes a user interface link to the 65 information specifying a second amount in bitcoin to be
second user device by using the second e-mail transferred from a first wallet associated with the first
address specified by the transfer request, user device , the hosted email module simultaneously :
US 10,510,053 B2
37 38
establishing a new , second wallet of the second e -mail control the host computer system to : execute a website user
address of the transfer request , and interface , a hosted emailmodule coupled to the website user
sending an e-mail that includes a user interface link to interface via a login module , a bitcoin wallet management
the second user device by using the second e-mail module coupled to the hosted email module , and a bitcoin
address specified by the transfer request, 5 wallet establishment module coupled to the website user
wherein the user interface link includes a uniform interface and the hosted email module ,
resource locator (URL ) for a user interface for claim wherein the instructions further include instructions that,
ing the second wallet , and when executed by the processor, control the hosted
wherein establishing a new , second wallet comprises: email module to : responsive to the website user inter
with the hosted emailmodule , instructing the bitcoin 10 face receiving from a first user device a transfer request
wallet establishment module to generate a second that specifies a second e -mail address of a second user
public key and a second private key , store the device and information specifying a second amount in
second public key and the second private key at a bitcoin to be transferred from a first wallet of the first
computer readable medium , generate a second user device, simultaneously : establish a new , second
bitcoin address of the second wallet by using the 15
second public key, and record the received second wallet of the second e-mail address, and send an e -mail
e -mail address as an identifier of the second wal that includes a user interface link to the second user
let, and device by using the second e-mail address specified by
with the hosted email module , instructing the bitcoin the transfer request ,
wallet management module to record the second 20 wherein the user interface link includes a uniform
amount in bitcoin specified by the transfer request resource locator (URL ) for a user interface for claim
in association with the generated second bitcoin ing the second wallet, and
address of the second wallet and record transfer of wherein establishing a new , second wallet comprises :
the second amount in bitcoin from a first bitcoin the hosted email module instructing the bitcoin wal
address of the first wallet ; and 25 let establishment module to generate a second
responsive to the hosted email module sending the e -mail public key and a second private key, store the
that includes the user interface link to the second user second public key and the second private key at a
device by using the second e -mail address: computer readable medium , generate a second
with the website user interface , receiving , from the bitcoin address of the second wallet by using the
second user device for the established second wallet, 30 second public key, and record the received second
a website request that identifies the URL , e -mail address as an identifier of the second wal
with the website user interface, transmitting the user let, and
interface to the second user device as a response to the hosted email module instructing the bitcoin wal
the website request, the user interface including a let management module to record the second
field for a password and a field for confirmation of 35 amount in bitcoin specified by the transfer request
the password for the established second wallet , in association with the generated second bitcoin
with the website user interface, receiving the password
for the second wallet from the second user device via address of the second wallet and record transfer of
the user interface, and the second amount in bitcoin from a first bitcoin
with the login module , storing the password in the 40 address of the first wallet, and
computer readable medium in association with the wherein the instructions further include instructions that,
second wallet, when executed by the processor, control the website
wherein the website user interface transmits the user user interface to : responsive to the hosted email module
interface to the second user device after establishing the sending the e -mail that includes the user interface link
second wallet. 45 to the second user device by using the second e -mail
8. The method of claim 7 , wherein the second wallet is address :
stored in a data store of the host computer system . receive , from the second user device for the established
9. The method of claim 8 , wherein the second wallet second wallet , a website request that identifies the
includes a plurality of bitcoin addresses wherein each bit URL ,
coin address represents a respective transfer of bitcoin to the 50 transmit the user interface to the second user device as
second wallet. a response to the website request , the user interface
10. The method of claim 7 , including a field for a password and a field for
wherein the user interface includes a button for receiving confirmation of the password for the established
user- input indicating acceptance of a user agreement second wallet,
for the second wallet, and 55
wherein the user interface indicates the second amount in receive the password for the second wallet from the
bitcoin transferred to the second wallet from the first second user device via the user interface , and
wallet, wherein the password is stored in the computer read
the method further comprising : the bitcoin wallet host able medium in association with the second wallet,
computer system receiving information indicating 60 wherein the instructions further comprise instructions
acceptance of the user agreement for the second wallet that, when executed by the processor, control the web
from the second user device via the user interface after site user interface to transmit the user interface to the
establishing the second wallet. second user device after establishing the second wallet.
11. A non -transitory computer-readable medium having 12. The computer -readable medium of claim 11, wherein
stored thereon a set of instructions that are executable by a 65 the host computer system stores a first e-mail address of the
processor of a host computer system , the instructions com first wallet of the first user device , first login details of the
prising instructions that when executed by the processor, first wallet, a first public key of the first bitcoin address of
US 10,510,053 B2
39 40
the firstwallet, a first private key of the first bitcoin address,
the first bitcoin address, and a first amount of bitcoin for the
first bitcoin address .
*