Note: Descriptions are shown in the official language in which they were submitted.
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
SYSTEM AND METHOD FOR RATING A TRANSACTION HISTORY
BACKGROUND OF THE INVENTION
Field of the Invention
The present invention relates to generating a rating of a transaction history
in
electronic commerce, and more specifically rating a transaction history of a
digital currency.
Description of the Related Art
The internet age has fostered the development and use of digital currencies.
A digital currency is electronic money that acts as alternative currency.
Currently,
digital currencies are not produced by government-endorsed central banks nor
necessarily
backed by national currency.
Digital currencies are typically used in transactions with all goods and
services and
are not limited to electronic media such as Internet distribution of movies
and games.
Many digital currencies have been developed and found favor among users for
several
years, but are no longer active. For example, non-cryptocurrencies e-Gold and
e-Bullion, and
cryptocurrencies SolidCoin, BBQCoin, Fairbrix, and GeistGeld had varying
degrees of use in
the past, but are no longer active.
Many digital currencies such as non-cryptocurrency Ven, and cryptocurrencies
Bitcoin, Litecoin, PPcoin (Peer-to-peer coin), Freicoin, Namecoin, Terracoin,
and
Feathercoin are in active use. The appetite for digital currencies among
internet users ensures
that further digital currencies will continue to be developed.
Mainstream monetary transactions are typically based on trust. Identification
of each
party in a two party transaction is a significant part of building trust.
Digital currencies such
as Bitcoin and Bitcoin based currencies use proof-of-work, as well as proof-of-
stake for
PPcoin, as validators instead of traditional mechanisms for establishing
trust. Moreover, with
digital currencies such as Bitcoin, transactions are often carried out in
anonymity without any
exchange of identification other than a user's account identifier. Thus,
digital currency
transactions are susceptible to identity fraud or scams.
Accordingly, there is a need for alternative mechanisms to help establish
trust among
users of digital currencies.
-1-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
SUMMARY OF THE INVENTION
In an aspect there is provided, a rating system for rating a transaction
history of a
digital currency, comprising:
a storage system for storing transaction information of the digital currency;
an interface for receiving an identifier of at least one account associated
with the
digital currency and a request for rating the transaction history of the at
least one account;
a processor communicative with the storage system and the interface;
the processor identifying transactions of the at least one account from the
transaction
information stored in the storage system and assessing the amount, date, and
destination of
the identified transactions to generate a rating for the at least one account.
In another aspect there is provided, a computer-implemented method for rating
a
transaction history of a digital currency, comprising:
storing transaction information of the digital currency in a storage system;
receiving over a network via an interface an identifier of at least one
account
associated with the digital currency and a request for rating the transaction
history of the at
least one account;
identifying transactions of the at least one account from the transaction
information
stored in the storage system; and
assessing the amount, date, and destination of the identified transactions to
generate a
rating for the at least one account.
In yet another aspect there is provided, a computer readable medium embodying
a
computer program for rating a transaction history of a digital currency,
comprising:
computer readable code for storing transaction information of the digital
currency in a
storage system;
computer readable code for receiving over a network via an interface an
identifier of
at least one account associated with the digital currency and a request for
rating the
transaction history of the at least one account;
computer readable code for identifying transactions of the at least one
account from
the transaction information stored in the storage system; and
-2-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
computer readable code for assessing the amount, date, and destination of the
identified transactions to generate a rating for the at least one account.
In still another aspect there is provided, a rating system for rating a
transaction history
of a peer-to-peer digital currency, comprising:
a storage system for storing transaction information of the peer-to-peer
digital
currency;
an interface for receiving an identifier of at least one account associated
with the peer-
to-peer digital currency and a request for rating the transaction history of
the at least one
account,
a processor communicative with the storage system and the interface;
the processor identifying transactions of the at least one account from the
transaction
information stored in the storage system and assessing the destination of the
identified
transactions to generate a rating for the at least one account.
In a further aspect there is provided, a computer-implemented method for
rating a
transaction history of a peer-to-peer digital currency, comprising:
storing transaction information of the peer-to-peer digital currency in a
storage
system;
receiving over a network via an interface an identifier of at least one
account
associated with the peer-to-peer digital currency and a request for rating the
transaction
history of the at least one account;
identifying transactions of the at least one account from the transaction
information
stored in the storage system; and
assessing the amount, date, and destination of the identified transactions to
generate a
rating for the at least one account.
In an even further aspect there is provided, a computer readable medium
embodying a
computer program for rating a transaction history of a peer-to-peer digital
currency,
comprising:
computer readable code for storing transaction information of the peer-to-peer
digital
currency in a storage system;
-3-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
computer readable code for receiving over a network via an interface an
identifier of
at least one account associated with the peer-to peer digital currency and a
request for rating
the transaction history of the at least one account;
computer readable code for identifying transactions of the at least one
account from
the transaction information stored in the storage system; and
computer readable code for assessing the amount, date, and destination of the
identified transactions to generate a rating for the at least one account.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows a block diagram describing a flow example of a user interaction
with a
transaction history rating system;
Figure 2 shows a block diagram describing a flow example of the transaction
history
rating system processing the user request shown in Figure 1;
Figure 3 shows a block diagram describing a flow example of a user interaction
with a
transaction history rating system for Bitcoin transactions;
Figure 4 shows a block diagram describing a flow example of the Bitcoin
transaction
history rating system processing the user request shown in Figure 3;
Figure 5 shows a block diagram describing a flow example of the Bitcoin
transaction
history rating system generating a reference value;
Figure 6 shows a block diagram describing a flow example of the Bitcoin
transaction
history rating system generating a score characterizing the transaction
history of a specified
account;
Figure 7 shows a block diagram describing a flow example of the Bitcoin
transaction
history rating system generating an averaged score characterizing the
transaction history of a
specified account;
Figure 8 shows a block diagram describing a flow example of the Bitcoin
transaction
history rating system generating a projected score characterizing the
transaction history of a
specified account;
Figure 9 shows a block diagram describing a flow example of an aggressive
projection for generating the projected score shown in Figure 8;
-4-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050907
Figure 10 shows a block diagram describing a flow example of a conservative
projection for generating the projected score shown in Figure 8;
Figure 11 shows a block diagram describing an alternative flow example, to
that
shown in Figure 5, of the Bitcoin transaction history rating system generating
a reference
value;
Figure 12 shows a block diagram describing an alternative flow example, to
that
shown in Figure 6, of the Bitcoin transaction history rating system generating
a score
characterizing the transaction history of a specified account.
Figure 13 is a system map showing an implementation of the rating system,
Figure 14 is a system map showing an alternative implementation of the rating
system.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to the drawings, an example of the system, and method for providing
the
same, will be described in the context of a user requesting and receiving a
score for a desired
digital currency account for illustrative purposes.
Figure 1 shows a flow diagram describing an example of a user inputing an
account
identifier and requesting a score for the account identifier within the
system. The user may
perform the steps shown in Figure 1 using an application installed on a
personal computing
device or using a website interface for an online application connected to a
server computer.
Furthermore, the application installed on a personal computing device may be
used offline
with local processor and memory or may be used online in connection with a
server computer
and database. For convenience the steps are described in the context of an
application
installed on the user's personal computing device with an online connection to
a server
computer. Typically, upon start-up of the user's computing device or by
intended selection by
the user, an end-user interface application software previously installed on
the computing
device will start (110) and initiate a networked communication with a server
computer of the
system. The server computer will typically require login information (120)
that may be
provided by the application software in the form of a stored electronic data
packet such as an
electronic cookie. In the absence of automated login information provided by
the application
-5-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
software, the user is prompted to manually enter the login information (122)
such as a login
name and password. Once in a logged in environment the user can access a list
(130), for
example as a pull down menu, of predetermined score types. The system may
provide the
user with a brief description of each score type. The user selects a desired
score type (140)
and inputs an identifier for a digital currency account (150). The server
computer calculates
the score for the specified account. The user then receives the requested
score (160).
Figure 2 shows a flow diagram describing an example of processing steps
performed
by the server computer to generate the requested score. The server computer
receives (210)
the selected score type and the specified account identifier from the user's
computing device.
The server computer accesses the transaction history of the digital currency
(220) and based
on the account identifier information provided by the user (150) the server
computer can filter
the transaction history of the digital currency to analyze the transactions of
the specified
account (230). Depending upon the score type selected by the user (140) the
server computer
analyzes the transactions of the specified account with reference to one or
more relevant
parameters such as transaction amount (232), transaction frequency (234),
account age (236),
or transaction destination (238). The one or more relevant parameters may be
any single or
combination of quantifiable factors that can define a digital currency
transaction. The server
computer executes algorithm(s) based on the one or more relevant parameters to
calculate a
score (240). The score is sent to the user's computing device (250) and
received by the
application software, displayed to the user and optionally stored in memory.
Figure 3 shows a flow diagram providing an example of the steps similar to
those
shown in Figures 1 and 2 applied to generation of a score for a Bitcoin
digital currency
account. A user wishing to obtain a score for a Bitcoin account inputs
information containing
a unique identifier of the account, typically a Bitcoin address or a hash of
the address (310).
The user may choose a type of score (312) selecting from options (314) such as
Current,
Projected, Average, or Projected Average. Furthermore, the user may choose an
output
format (316) selecting from options (318) such as XML, plain text or CSV. The
information
containing the unique identifier, the choice of score type and the choice of
output format is
submitted to a processor for score calculation. The processor calculates the
requested score
with predetermined algorithms corresponding to the chosen score type (322,
326) and by
-6-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
accessing the transaction history database or Blockchain of the Bitcoin (324)
or a database
derived from the Blockchain information (328). The calculated score is
returned to the user's
personal computing device and displayed to the user.
Figure 4 shows a flow diagram providing an example of steps of a calculation
(322).
Calculation (322) is initiated by receipt of a request for a score calculation
(340) with the
request comprising information relating to an account identifier, and
optionally a score type
and an output format (342). The received information and more particularly the
account
identifier information may be validated, for example by checksum analysis, to
ensure that it is
in an appropriate form (344) with an invalid format resulting in an error
message returned to
the user (346) and a valid format proceeding to access Blockchain information
stored in a
local memory (348). The locally stored Blockchain information is assessed
(350), and if it is
up to date the processor selects an algorithm (354) corresponding to the score
type specified
in the request (342) and executes the selected algorithm (356, 357, 358 or
359). If the
Blockchain information is not up to date a networked connection is initiated
to update the
Blockchain information (352) and to calculate reference values relating to the
total, average
or mean of an accumulated value of transactions in the Blockchain. The
reference values are
used to normalize scores to facilitate comparison of scores for different
accounts at different
time points.
Figure 5 shows a flow diagram providing an example of steps to update the
Blockchain information and reference values (352). A networked connection to a
realtime
bitcoin Blockchain database is initiated and compared to a record of the last
updated
Blockchain transaction (370) to determine a starting point and size of the
update. The update
can involve updating a Bitcoin Blockchain database stored in local memory as
well as
parameter weight factors database also stored in a local memory and used for
calculating
scores. A reference value Cm is updated (374) in view of updated Blockchain
transactions.
Calculation of the reference value Cm comprises three components: a total
transaction
amount, a negative weighting penalizing longer intervals (ie., lower
frequency), and a
negative weighting penalizing greater account age. The reference value Cm can
be updated
in iterative fashion (378) by considering each subsequent updated transaction
until the current
transaction is reached (376) resulting in an updated Cm reference value.
-7-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
Figure 6 shows a flow diagram providing an example of steps to calculate a
Bitcoin
account score extending (356) from the steps shown in Figure 4. The Blockchain
and weight
factor databases (372), updated as shown in Figure 5, are accessed for
transaction information
relevant to the specified account identifier for which a score has been
requested as shown in
Figure 3 (310). Value Cid, an accumulated value of all the transactions of
Bitcoin transfers
carried out by the specified account, is then calculated (390). Similar to
reference value Cm,
calculation of value Cid comprises three components (390): a total transaction
amount, a
negative weighting penalizing longer intervals (ie., lower frequency), and a
negative
weighting penalizing greater account age. The Bitcoin account score is then
calculated as a
comparison, more specifically a ratio, of the value Cid over the reference
value Cm to yield
the score Sid (394) which is then sent (396) and displayed to the user to
complete the user's
request (320).
From Figures 5 and 6:
Sid ¨ Cid/ Cm
Cid ¨ E(di)*ai ¨ E wfi*(di ¨ (11.1 raj + EwaNcli-dorai
positive weight for aging,
id's accumulated negative weight for
calculated value decreases
transactions interval
with age
C = E(di)*Ai ¨ E Wfi*(di ¨ di_i )*Ai +EI/Vai*( Di-Dõ)*Ai
positive weight for aging,
all accumulated negative weight for
calculated value decreases
transactions interval
with age
e.i. 50% counts only half
wfi = 0=> ,<=1
of frequency contribution
1 / ( d -d0)2
Wai ¨
1(1¨ Cm / CO
-8-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
Or as an alternative (not shown in the Figures):
Cid ¨ E(di)*ai ¨ E wfi*(di ¨ d1_1 raj ¨ Ewai*(di-do)*ai
id's accumulated negative weight for
negative weight for aging
transactions interval
C = E(di)*Ai ¨ E Wfi*(di ¨ d1 )*Ai ¨ EWai*( Di-Do)*Ai
all accumulated negative weight for
negative weight for aging
transactions interval
where,
Id identifier of a digital currency account, may also be
identification
number of a report, also is the address in Bitcoin
Cid Accumulated value of transactions associated with id.
di date i
do first transaction date of id
de current date
ai amount i
wfi weight factor of frequency
Wai weight factor of aging
Accumulated value of all transactions
Ai amount i
Wft-id weight factor of frequency for date i for an id
Wm-id weight factor of aging for date i for an id
Sid Credit score of id
Cm Average value of C
Co Reference date's Cm, a date prior to the date of Cm.
Li Score Index on date d, it indicates the trends of
average score
-9-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
Figure 7 shows a flow diagram providing an example of steps to calculate a
system
index score extending (357) from the steps shown in Figure 4. The score index
Id is
calculated (400) as a comparison, or more specifically a ratio of a Cm value
at a specified
date to a Cm value at a prior reference date, designated Co. The index score
can then be
returned (402) and displayed to the user. The index score is useful for
assessing overall or top
level trends of the system between two or more dates. For example, the Index
score may
reflect overall expansion or contraction of the system between a queried date
and a reference
date. As a more specific example, the index score may be used for month-over-
month or
year-over-year comparisons.
Figure 8 shows a flow diagram providing an example of steps to calculate a
projected
Bitcoin account score extending (358) from the steps shown in Figure 4. The
Blockchain and
weight factor databases (372), updated as shown in Figure 5, are accessed for
transaction
information relevant to the specified account identifier for which a score has
been requested
as shown in Figure 3 (310). Value Cdp, a projected accumulated value of all
the transactions
of Bitcoin transfers carried out by the specified account, is then calculated
(410). The value
Cdp is for projected day dp. A projected reference value Cp is also calculated
(414). Cp is the
projected average value considering all accounts/addresses of Bitcoin as
predicted for
projected day dp. The Bitcoin account score is then calculated as a
comparison, more
specifically a ratio, of the projected account value Cdp over the projected
reference value Cp
to yield the projected score Sdp (416) for projected day dp which is then sent
(418) and
displayed to the user to complete the user's request (320). In blocks 410 and
414 fp is a
predictive function that is applied to a data set comprising a plurality of
existing Cid values
and their corresponding dates. The predictive function may be applied
independent of the
parameters considered to obtain the data set of Cid values. Many different
predictive
algorithms may be applied including Lagrange interpoloation, polynomial
regression,
trigonometric functions, complex number functions, exponential functions,
logarithmic
functions and the like.
Figures 9 and 10 show alternative calculations or predictive algorithms for
obtaining
the projected score shown in Figure 8, an aggressive projection (420) in
Figure 9 based on a
-10-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
Lagrange interpolation and a conservative projection (450) in Figure 10 based
on a
polynomial regression.
Figure 9 provides a Lagrange interpolation for fp shown in Figure 8. Data sets
for a
plurality of corresponding Cid and di data points can be obtained (422) and
treated with a
Lagrange interpolation to obtain a Cdp value (424) and a Cp value (426). The
Lagrange
expression comprises the requested projected date - d, the date of transaction
i ¨ di, and all
dates for which Cid has been calculated that are not equal to di ¨ dj. The Cdp
value is
obtained for the projected date ¨ d. The projected reference value Cp for the
projected date d
is obtained by summing all Cdp values for all Bitcoin addresses for the
projected date d
divided by the number of total addresses. The projected score is then
calculated as a
comparison, more specifically a ratio, of the Cdp value over the Cp value to
yield the
projected score Sdp (428) for the projected date d which is then sent (430)
and displayed to
the user.
Figure 10 provides a polynomial regression for fp shown in Figure 8.
Conventionally,
a polynomial regression can be expressed in matrix form and solved using a
least squares
method. Data sets for a plurality of corresponding Cid and di data points can
be obtained
(452) and treated with a polynomial regression to obtain a Cdp value (456) and
a Cp value
(458) for the projected date d. The projected score is then calculated as a
comparison, more
specifically a ratio, of the Cdp value over the Cp value to yield the
projected score Sdp (460)
for the projected date d which is then sent (462) and displayed to the user.
Figure 11 shows a flow diagram providing an alternative example, to that shown
in
Figure 5, of steps to update the Blockchain information and reference values
(352). Figure 11
differs from Figure 5 by assessing an additional parameter of transaction
destination
information. A networked connection to a realtime bitcoin Blockchain database
is initiated
and compared to a record of the last updated Blockchain transaction to
determine a starting
point and size of the update and access relevant information for calculation
of reference
values (470). The update can involve updating a Bitcoin Blockchain database
stored in local
niemory as well as parameter weight factors database also stored in a local
memory and used
for calculating scores (372). A reference value Cmk(id,idd) for each unique
account/destination pair is updated (474) in view of updated Blockchain
transactions.
-11-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
Calculation of the reference value Cmk(id,idd) comprises three components: a
total
transaction amount, a negative weighting penalizing longer intervals (ie.,
lower frequency),
and a negative weighting penalizing greater account age. The reference value
Cmk(id,idd)
can be updated in iterative fashion (478) for each unique account/destination
pair by
considering each subsequent updated transaction until the current transaction
is reached (476)
resulting in an updated Cmk(id,idd) reference value. A factor k(id,idd) is
then calculated
based on the number of repeated transactions for each unique
account/destination pair (480).
The product of factor k(id,idd) and corresponding Cmk(id,idd) reference value
for each
unique account/destination pair is then summed until all account/destination
pairs are
considered (484) to yield reference value Cmi (482). The alternative example
shown in
Figure 11 rewards greater numbers of unique account/destination pair as the
Cmk(id,idd)
reference values for each unique account/destination pair are summed. However,
repeated
transactions within the same account/destination pair are not rewarded as the
number of
transactions for each account/destination pair is placed in the denominator
for calculation of
factor k(id,idd).
Figure 12 shows a flow diagram providing an alternative example, to that shown
in
Figure 6, of steps to calculate a Bitcoin account score extending (356) from
the steps shown
in Figure 4. Figure 12 differs from Figure 6 by assessing an additional
parameter of
transaction destination information. The Blockchain and weight factor
databases (372),
updated as shown in Figure 11, are accessed for transaction information (570)
relevant to the
specified account identifier for which a score has been requested as shown in
Figure 3 (310).
Value Ck(id,idd) characterizing accumulated transactions for each unique
destination
for Bitcoin transfers from the specified account is calculated (574) in view
of updated
Blockchain transaction information. Calculation of Ck(id,idd) comprises three
components: a
total transaction amount, a negative weighting penalizing longer intervals
(ie., lower
frequency), and a negative weighting penalizing greater account age.
Ck(id,idd) can be
calculated in iterative fashion (578) for each unique destination from the
specified account by
considering each subsequent transaction until the current transaction is
reached (576). A
factor k(id,idd) is then calculated based on the number of repeated
transactions for each
unique destination for Bitcoin transfer from the specified account (580). The
product of
-12-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/(15(1967
factor k(id,idd) and corresponding Ck(id,idd) reference value for each unique
destination for
the specified account is then summed (582) until all destinations for the
specified account are
considered (584) to yield value Cid (586). The alternative example shown in
Figure 12
rewards greater numbers of unique destinations from the specified account as
Ck(id,idd)
values are summed. However, repeated transactions to the same destination are
not rewarded
as the number of transactions for each destination from the specified account
is placed in the
denominator for calculation of factor k(id,idd).
Similar to the alternative method for obtaining reference value Cm shown in
Figure
11, the alternative calculation of value Cid shown in Figure 12 comprises five
components: a
total transaction amount, a negative weighting penalizing longer intervals
(ie., lower
frequency), a negative weighting penalizing greater account age, a positive
summation
rewarding greater numbers of unique destinations, and a factor that penalizes
multiple
transactions to the same destination. The Bitcoin account score Sid may then
be calculated as
shown in Figure 6, as a comparison, more specifically a ratio, of the value
Cid over the
reference value Cm to yield the score Sid (394) which is then sent (396) and
displayed to the
user to complete the user's request (320). From Figures 11 and 12:
Sid ¨ Cid/ Cm
Ck (id,idd) =Edi * a ¨ Ewl(d) * (di ¨ )*ai + Ewa(d) * (di-
do)*ai
positive weight
id's accumulated for aging with same
negative weight for interval
transactions with destination idd, but
with same destination idd
same destination idd calculated
value
decreases with age
k(id,idd) = ( 1 / Thad )2
Cid = E k(id, idd) * Ck(id, idd)
Cink(id,idd) = E (di)*Ai ¨ Ewf(d)*(di ¨d11 )*A. + Ewa(d)*( Di-Do)*
Ai
all accumulated
positive weight
negative weight for interval
transactions with for aging with same
with same destination
same destination destination
idd, but
-13-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
calculated
value
decreases with age
¨ 1 / 1N_Itk U k(id, idd) * C,,k(id, idd)
Wa¨ I d ¨ do )2
Or, as an alternative (not shown in the Figures):
Ck (id,idd) = Ed; * a; ¨ Ewf(d) * (d; ¨ d1_1 )*a; ¨ Ewa(d) * (d,-
dõ)*a,
id's accumulated negative weight for
negative weight
transactions with interval with
same for aging with same
same destination idd destination idd destination idd
k(id,idd) = ( 1 / nidd
Cid ¨ k(id, idd) * Ck(id, idd)
C,õk(id,idd) = E (d;)*A, ¨ Ewf(d)*(d; ¨ d1 )*Ai ¨ Ewa(d)*(1);-
Do)*A;
All accumulated negative weight for
negative weight
transactions with interval with
same for aging with same
same destination destination destination idd
C,õ ¨ 1 / N.dLI k(id, idd) * Coik(id, idd)
where,
id Identifier of a digital currency account, may also be
identification number of a
report, also is the address in Bitcoin
the number I transaction of Id! all transactions
Cid Accumulated value of transactions associated with id.
d, date and time of transaction i
current date and time
do/ Do first transaction date of id I all transactions
a; / Ao transaction amount of transaction i of the Id! all transactions
wt(d) current (time d) weight factor of frequency
-14-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
wa(d) current (time d) weight factor of aging
Cm average value of Accumulated value of all transactions
Sid score of address id
idd/IDD number i transaction of the same destination address in id/all
transactions
Cmk(idk) number i transaction accumulated value of the same destination
address in id
Cmk(idk) number i transaction accumulated value of the same destination
address in id
k(id,idd) factor of same destination address transaction in id
naid total number of transactions with same destination address from
source id
Figure 13 shows a system map describing an example of an interne cloud (620)
based
implementation of the system (600) for generating ratings in respect of
Bitcoin transaction
histories, where functions for analyzing transaction histories and generating
scores are carried
out by server computers (602) operably linked to data storage systems (604)
that are isolated
from the cloud (620) by an electronic interface device (606). The electronic
interface device
has processing power, optionally including a firewall, to receive via the
internet (620)
requests from client computing devices for a score relating to an account
identifier and then
to return a score for the account identifier back to the client computing
device. The electronic
interface device (606) shields the server computers (602) and data storage
systems (604) from
direct interaction with the Internet or from direct communication with client
computers: Upon
receiving a request from a client computing device the electronic interface
device (606) logs
the request, optionally performing a validation check of the request, and then
sends a request
for a score including account identifier information to the server computers
(602). Once a
score is generated, the server computers (602) return the score to the
electronic interface
device for subsequent return to the client computing device. Bitcoin
transaction histories
termed Blockchain are publically available from many sources including Bitcoin
electronic
exchanges and connection of server computers (602) with the Bitcoin system
(610), may be
established either directly or through an electronic interface device at any
desired frequency
to ensure that the transaction history information stored within data storage
system (604) is
up to date. The computer architecture shown in Figure 13 may be simplified or
elaborated
depending upon the desired application. In a simplified implementation (500)
the system
-15-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
comprises a plurality of users (630) each with at least one computing device.
User computing
devices (630) through either a web browser or a locally installed application
communicate
over a network (620) with the scoring system (600). The scoring system (600)
may be
independent and shielded from the Bitcoin system or may be embedded in the
Bitcoin system.
In a simplified form the scoring system (600) may be hosted on a single server
with a
processor operably linked to a memory. Memory may include volatile memory such
as
various RAM types, and non-volatile such as ROM, magnetic storage systems,
optical storage
systems and the like.
Figure 14 shows a system map describing another example of an implementation
(700) of the system. User computing devices 710 including smartphones,
tablets, laptops,
desktops and the like may communicate through web browsers or locally
installed
applications with a digital currency system comprising a component for
conducting
transactions (730) and a component for recording each transaction and its
related information
(732). The user computing devices 710 may also communicate through web
browsers or
locally installed applications with a system for rating transactional
histories of the digital
currency. Corporate entity computers (712) such as financial institutions,
commodity and
currency exchanges, transaction processors and the like may also communicate
with the
digital currency system and/or the rating system through an application
programming
interface (API). Typically, the user computing devices (710) will communicate
with the
rating system through a network (720) such as the Internet, while corporate
computers (712)
may have a more direct electronic linkage. The rating system receives requests
for ratings
including an account identifier over the network (720) through website
applications (740)
hosted on a load balanced web server farm (742). Corporate computers (712) may
send
requests directly to the web server farm (742) based on an API. The web server
farm is
communicative with load balanced transaction history servers (750) and score
calculation
servers (752) which are in turn communicative with a load balanced database
server farm
(760, 762, 764, 766, 768, 770) which maintain, update, and access records from
a data
storage system (660). The transaction history servers (750) are communicative
with the score
calculation servers (752). Furthermore, the transaction history servers (750)
or the web
-16-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
servers (742) may be communicative with a publically accessible or privately
held electronic
record or data base of the transaction histories of the digital currency.
In use, the rating system described herein provides users with a rating,
score, ranking
and the like to be able to assess the activity of a targeted account of a
digital currency.
Currently, several currencies use a proof-of-work concept as a validator of a
transaction.
Proof-of-work inherently requires time to lapse after a transfer of currency.
Furthermore,
proof-of-work is difficult to understand for most users. The rating system can
provide a score
characterizing a queried account's transaction activity in advance of agreeing
to a transaction.
Thus, it may complement existing validators such as proof-of-work or proof-of-
stake to
provide confidence or trust in a digital currency system.
The rating system may be used by users that are expecting to enter into a
transaction
using a digital currency or by corporate entities such as financial
institutions or transaction
processors that may be tasked with monitoring a digital currency system.
Taking the
individual user as an example, before agreeing to a transaction in a digital
currency, a user
can obtain the account address or identifier of the opposing party. The user
can then input the
account identifier in a data entry box in a web application and send a request
over the intern&
for a rating corresponding to the account identifier. The request is received
and a rating is
calculated and returned to be displayed to the user through the web
application. The rating
may be presented in any manner of ways including numerical score, star rating,
percentile
ranking, 2D graphs, distribution curves, and the like. Once the user receives
the rating, the
user can assess the risk of the potential transaction in view of the rating.
The rating reflects
the ability of the account to fulfill a transaction of the digital currency at
a current date or a
target projected date queried by the user.
An example of the system and several illustrative variants have been described
above.
Further illustrative variants and modifications will now be described. Still
further variants,
modifications or combinations thereof will be recognized by the person of
skill in the art.
The system is typically used for rating a transaction history of a digital
currency. The
transaction history of the digital currency may be publically accessible or
privately held. For
example, the Bitcoin transaction history is publically accessible, while a
significant portion of
the transaction history of Amazon's digital currency, Amazon coins, is
privately held.
-17-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
The system may be used in conjunction with any digital currency and may
function
independently of a digital currency or may be embedded within the digital
currency
computing infrastructure.
While the rating system may be used to assess transactions histories of any
digital
currency, it may have particular benefit for peer-to-peer digital currency as
these currencies
suffer from reports of fraud and double spending. Bitcoin, Litecoin, PPcoin
(Peer-to-peer
coin), Freicoin, or Namecoin are examples of a peer-to-peer digital currency.
A peer-to-peer
digital currency is a decentralized currency managed by peer-to-peer networked
computing
technology (P2P), without a central authority. Consistent with P2P technology,
the networked
distributed computing application architecture partitions tasks or workloads
among peers or
nodes. Functions of currency issuance, transaction processing and verification
are carried out
collectively by the network, without a central supervisor or agency to oversee
operations.
The system typically requires a memory, an interface and a processor. The
types and
arrangements of memory, interface and processor may be varied according to
implementations. For example, the interface may include a software interlace
such as a web
application that launces a web browser and internet connection on an end-user
computing
device. The interface may also include a physical electronic device configured
to receive
requests or queries from an end-user.
The rating system can represent a rating in any convenient graphical or text
format.
For example, the rating system may generate a numerical score that
characterizes the
transaction history of an account of a digital currency. The numerical score
may represent a
total value for the accumulated transactions of the account, per day average,
a per transaction
average, a per destination average, or any other convenient representation.
The numerical
score may be compared to a reference value to normalize the numerical score.
The reference
value may characterize the total accumulated transaction information of the
digital currency.
The reference value may be represented as a total, average, mean or modal
(most frequently
observed) value or any other convenient representation characterizing the
accumulated
transaction information of the digital currency.
The rating system will typically assess at least one of the parameters of
amount, date
and destination of transactions that make up the transaction history of an
account of the
-18-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
digital currency. More typically, the rating system will assess at least two
of the parameters of
amount, date and destination. For example, assessing amounts alone is a
measure of currency
volume. Assessing dates alone can provide a rating based on frequency and/or
age of
transactions. Assessing destination identifiers alone can provide a rating
based on numbers of
unique destinations and/or repetition of the same destination. Thus, each
parameter of
amount, date, and destination taken alone may be able to provide a useful
rating, but taken
together with at least two of the three, or all three, co-operate to provide
an increasingly
robust rating.
The parameters of amount, date, and destination, or parameters derived
therefrom
may be negatively or positively correlated with a rating depending on the
rating scheme and
the algorithms for generating a rating. Correlations may encompass linear
relationships as
well as non-linear relationships. A correlation may be considered for any two
or more
variables that depart from independence. Typically, amount is positively
correlated with the
rating such that an increase in amount is correlated with an increase in
rating. An increase
amount may be rewarded as it reflects currency volume and provides precedent
for a
transaction level. Transaction frequency may be derived from transaction
dates, for example
by calculating intervals between each transaction, with transaction frequency
typically being
positively correlated with rating, such that an increase in transaction
frequency is correlated
with an increase in the rating. The rating system may be configured to reward
increase
frequency as higher successful active density means more creditable
contributions. Age of
transactions or age of the account can also be derived from transaction dates,
with age
typically being negatively correlated with the rating, such that a decrease in
transaction age is
correlated with an increase in the rating. The rating system may be configured
to penalize an
increase in age as a contribution erodes by time or aging, with more recent
activity providing
a better indicator. The number of unique transaction destinations may be
derived from
transaction destination information with unique transaction destinations
typically being
positively correlated with the rating, such that an increase in the number of
unique transaction
destinations is correlated with an increase in the rating. The rating system
may be configured
to reward an increase in unique destinations to reward diversity as more
unique destinations
means more diverse activities to different receivers and increased exposure to
detection of
-19-
CA 02933407 2016-06-10
WO 2015/085393 PC T/CA2013/050967
fraudulent activity. The number of repeated transactions to the same
destination may be
derived from the transaction destination information with the number of
repeated transactions
to the same destination being negatively correlated with the rating such that
a decrease in
repeated transactions to the same destination is correlated with an increase
in the rating. The
rating system may be configured to penalize increase in repeated transaction
to the same
destination to promote diversity and to limit contributions from potential
cheat or fake
transactions for the purpose of gaming the rating system to increase a rating
by simply
shuttling currency back and forth between accounts. Destinations are typically
derived from
the transaction information by extracting destination account identifiers.
The components of the system may be administered by a single organization or a
plurality of partnering organizations. The tracking and validation of
transaction histories of a
digital currency, for example, may be administered by an organization at arm's
length from
the organization administering the rest of the system. Such an arm's length
organization may
be a financial institution, accounting firm or payment transaction processor.
The system may accommodate any type of end-user computing device or client
computing device provided the computing device can be networked to the system
and is
configured to display website interfaces and/or graphical interface elements
for performing
the various functions of the system such as inputting an account identifier,
displaying a rating
or updating a transaction history database that may be locally stored in the
computing device.
For example, the computing device may be a desktop, laptop, notebook, tablet,
personal
digital assistant (PDA), PDA phone or smartphone, gaming console, portable
media player,
and the like. The computing device may be implemented using any appropriate
combination
of hardware and/or software configured for wired and/or wireless communication
over the
network.
The server computer may be any combination of hardware and software components
used to store, process and/or provide scores or ratings for transactions from
one or more
accounts using a digital currency, and monitoring and analyzing such
transactions. The server
computer components such as storage systems, processors, interface devices,
input/output
ports, bus connections, switches, routers, gateways and the like may be
geographically
centralized or distributed. The server computer may be a single server
computer or any
-20-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
combination of multiple physical and/or virtual servers including for example,
a web server, a
transaction server, an application server, a bus server, an integration
server, a user profile
server, an algorithm server, a weighting factor server, a log server, an
accounting server and
the like.
Any conventional computer architecture may be used to implement the system
including for example a memory, a mass storage device, a processor (CPU), a
Read-Only
Memory (ROM), and a Random-Access Memory (RAM) generally connected to a system
bus
of data-processing apparatus. Memory can be implemented as a ROM, RAM, a
combination
thereof, or simply a general memory unit. Software modules in the form of
routines and/or
subroutines for carrying out features of the rating system can be stored
within memory and
then retrieved and processed via processor to perform a particular task or
function. Similarly,
one or more of the flow diagrams shown in Figures 1-12 may be encoded as a
program
component, stored as executable instructions within memory and then retrieved
and
processed via a processor. A user input device, such as a keyboard, mouse, or
another
pointing device, can be connected to PCI (Peripheral Component Interconnect)
bus. The
software will typically provide an environment that represents programs,
files, options, and
so forth by means of graphically displayed icons, menus, and dialog boxes on a
computer
monitor screen.
A data-process apparatus can include CPU, ROM, and RAM, which are also coupled
to a PCI (Peripheral Component Interconnect) local bus of data-processing
apparatus through
PCI Host Bridge. The PCI Host Bridge can provide a low latency path through
which
processor may directly access PCI devices mapped anywhere within bus memory
and/or
input/output (I/0) address spaces. PCI Host Bridge can also provide a high
bandwidth path
for allowing PCI devices to directly access RAM.
A communications adapter, a small computer system interface (SCSI), and an
expansion bus-bridge may also be attached to PCI local bus. The communications
adapter can
be utilized for connecting data-processing apparatus to a network. SCSI can be
utilized to
control a high-speed SCSI disk drive. An expansion bus-bridge, such as a PCI-
to-ISA bus
bridge, may be utilized for coupling ISA bus to PCI local bus. PCI local bus
can be connected
-21-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
to a monitor, which functions as a display (e.g., a video monitor) for
displaying data and
information for an operator and also for interactively displaying a graphical
user interface.
A database can contain information on a variety of matters such as data
relating to
digital currency transactions, transfers, or conversions. For example, a
database may contain
user profiles, user preferences, transaction history, score history, and/or
history of prior score
requests. A user profile may include, but is not limited to, a user identifier
such as login
name, a password, contact information, mailing information, billing
information, saved
product searches, and/or user preferences for use in searching database and/or
displaying
product searches. Although it will be recognized that currently many users of
digital
currencies try to maintain anonymity.
The network may be a single network or a combination of multiple networks. For
example, the network may include the internet and/or one or more intranets,
landline
networks, wireless networks, and/or other appropriate types of communication
networks. In
another example, the network may comprise a wireless telecommunications
network (e.g.,
cellular phone network) adapted to communicate with other communication
networks, such
as the Internet. Typically, the network will comprise a computer network that
makes use of a
TCP/IP protocol (including protocols based on TCP/IP protocol, such as HTTP,
HTTPS or
FTP).
The system may be adapted to follow any computer communication standard
including Extensible Markup Language (XML), Comma-Separated Values (CSV),
Hypertext
Transfer Protocol (HTTP), Java Message Service (JMS), Simple Object Access
Protocol
(SOAP), Representational State Transfer (REST), Lightweight Directory Access
Protocol
(LDAP), Simple Mail Transfer Protocol (SMTP) and the like.
The system may represent a score graphically or by images and may accordingly
accommodate any type of still or moving image file including JPEG, PNG, GIF,
PDF, RAW,
BMP, TIFF, MP3, WAV, WMV, MOV, MPEG, AVI, FLV, WebM, 3GPP, SVI and the like.
The system may guide or prompt user attempts to input account identifiers and
request various score types by any convenient form of user interface element
including, for
example, a window, a tab, a text box, a button, a hyperlink, a drop down list,
a list box, a
check box, a radio button box, a cycle button, a datagrid or any combination
thereof.
-22-
CA 02933407 2016-06-10
WO 2015/085393 PCT/CA2013/050967
Furthermore, the user interface elements may provide a graphic label such as
any type of
symbol or icon, a text label or any combination thereof. Any desired spatial
pattern or timing
pattern of appearance of user interface elements may be accommodated by the
system.
The system described herein and each variant, modification or combination
thereof
may also be implemented as a method or code on a computer readable medium
(i.e. a
substrate). The computer readable medium is a tangible data storage device
that can store
data, which can thereafter, be read by a computer system. Examples of a
computer readable
medium include read-only memory, random-access memory, CD-ROMs, magnetic tape,
optical data storage devices and the like. The computer readable medium may be
geographically localized or may be distributed over a network coupled computer
system so
that the computer readable code is stored and executed in a distributed
fashion.
Still further variants, modifications or combinations thereof will be
recognized by the
person of skill in the art.
-23-
