U.S. patent application number 13/902921 was filed with the patent office on 2014-03-13 for payment system and method using tokens.
This patent application is currently assigned to DIVERSINET CORP.. The applicant listed for this patent is Mordhay BARKAN. Invention is credited to Mordhay BARKAN.
Application Number | 20140074695 13/902921 |
Document ID | / |
Family ID | 40793591 |
Filed Date | 2014-03-13 |
United States Patent
Application |
20140074695 |
Kind Code |
A1 |
BARKAN; Mordhay |
March 13, 2014 |
Payment System and Method Using Tokens
Abstract
A method of payment using tokens issued by a third party
comprising the steps of: a. A transaction management unit receives
a request to perform a service for which payment with tokens is
required; b. The management unit checks whether there are yet
unused tokens available; If an unused token was found, go to step
(c); If there are no available tokens, then indicate that, then
END; c. The management unit requests information on an available
token from a database. The status of the used token is changed to
"used"; d. During the subsequent transaction, the management unit
sends information relating to the token now used. A system for
managing and monitoring the use of tokens, comprising: a. a
transactions management unit using tokens, wherein the unit is
activated when a local user requires to perform a service for which
payment using tokens is required; b. a tokens database which
includes information on tokens acquired from the third party; c. a
tokens use monitoring unit, to verify the correct use of tokens; d.
a database of tokens reports; e. a communication channel to other
users.
Inventors: |
BARKAN; Mordhay; (Kefar
Sirkin, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
BARKAN; Mordhay |
Kefar Sirkin |
|
IL |
|
|
Assignee: |
DIVERSINET CORP.
Toronto
CA
|
Family ID: |
40793591 |
Appl. No.: |
13/902921 |
Filed: |
May 27, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12457351 |
Jun 9, 2009 |
|
|
|
13902921 |
|
|
|
|
09586881 |
Jun 5, 2000 |
7555460 |
|
|
12457351 |
|
|
|
|
PCT/IL98/00563 |
Nov 19, 1998 |
|
|
|
09586881 |
|
|
|
|
Current U.S.
Class: |
705/39 |
Current CPC
Class: |
G06Q 20/3674 20130101;
G06Q 20/105 20130101; G06Q 20/0655 20130101; G06Q 20/06 20130101;
G06Q 20/10 20130101; G06Q 20/29 20130101; G06Q 20/367 20130101;
G06Q 20/382 20130101; G06Q 20/102 20130101 |
Class at
Publication: |
705/39 |
International
Class: |
G06Q 20/06 20060101
G06Q020/06 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 20, 1997 |
IL |
122263 |
Claims
1. A method of payment using tokens issued by a third party, during
a transaction between a first and second party, and where the third
party does not take part in the transaction, comprising the
following steps: a. A transaction management unit, pertaining to
the software of the first party, receives from a user there a
request to perform a service for which payment with tokens is
required; b. The management unit checks whether there are yet
unused tokens available in the system, that is tokens whose status
is "ready" as opposed to "used" or "canceled". If an unused token
was found, go to step (c); If there are no available tokens, then
indicate to the user that the service cannot be performed because
of lack of tokens, then END; c. The management unit requests and/or
retrieves information on an available (unused as yet) token from a
database or storage unit pertaining to the software of the first
party. The status of the token which was retrieved is automatically
changed in the database, and will thereafter be designated as
"used" or "canceled"; d. During a subsequent transaction with the
second party, the management unit sends information relating to the
token now used and canceled to the second party, through a
communication channel.
2. The method of payment according to claim 1, wherein after step
(d) the first user further sends to the second user information
relating to previous token or tokens used by the first user.
3. The method of payment according to claim 1, wherein after step
(d) the first user further sends to the second user information
relating to the use of token or tokens by other parties, as
reported to the first party during previous transactions.
4. The method of payment according to claim 1, wherein the second
user receives information relating to the use of tokens by other
parties, and discards the oldest information to limit the total
information stored therein.
5. A method for monitoring the proper use of tokens during a
transaction between a first and second party, where a third party
has issued the tokens to the first party but does not take part in
the transaction, comprising the following steps: a. The first party
sends to the second party a report including information relating
to the token used and canceled by the first party for that
transaction; b. The second party maintains a database of previous
reports relating to tokens used in the past, and the report
received in step (a) is added to the database; c. The second party
compares the information received in step (a) with previous reports
for the same first party; d. If the comparison detects a violation
of the rules for the use of tokens, then the second party stores
that information and/or displays a violation report and/or reports
that to the tokens issuer, and/or sends a note to the first party
of such token.
6. The method for monitoring the proper use of tokens according to
claim 5, wherein in step (b) the second party maintains a database
of previous reports relating to tokens used in the past by the
first party.
7. The method for monitoring the proper use of tokens according to
claim 5, wherein in step (b) the second party maintains a database
of previous reports relating to tokens used in the past by a
plurality of other parties or users.
8. The method for monitoring the proper use of tokens according to
claim 5, wherein in step (b) the database of previous reports is
being updated to include the latest reports, and the oldest reports
are deleted therefrom.
9. The method for monitoring the proper use of tokens according to
claim 5, wherein in step (d) one of the rules for use of tokens is
that no token is allowed to be used twice.
10. The method for monitoring the proper use of tokens according to
claim 5, wherein in step (d) one of the rules for use of tokens is
that the serial number of successive tokens should be in ascending
order.
11. The method for monitoring the proper use of tokens according to
claim 5, wherein in step (d) one of the rules for use of tokens is
that the serial number of issued tokens should correspond to a
document or permit issued by the third party.
12. A system for managing and monitoring the use of tokens during
transactions between a first and a second party, comprising: a. a
transactions management unit using tokens, wherein the unit is
activated when a local user requires to perform a service for which
payment using tokens is required, to activate tokens stored in a
tokens database; b. a tokens database which includes information on
tokens acquired from the third party, and wherein each token
presented to the management unit to be used is then designated as
"used" or "canceled" to prevent the use of the same token in
subsequent transactions; c. a tokens use monitoring unit, to verify
the correct use of tokens by other parties who connect to the local
system; d. a database of tokens reports, including information on
acquired tokens which are available for performing the service for
fee, and wherein each token includes status indicating means, which
change from "ready" to "used" or "canceled" after a token is used;
e. a communication channel to other users.
13. The managing and monitoring system according to claim 12,
wherein a software package to implement the managing and monitoring
system is installed in the facilities of the first and second party
and of any party which may take part in transactions using
tokens.
14. The managing and monitoring system according to claim 12,
wherein the transactions management unit will perform the required
service only if there are available tokens, that is tokens which
are not "canceled" or "used", in the database of tokens
reports.
15. The managing and monitoring system according to claim 12,
wherein the communication channel may include a telephone line
and/or a wireless link or a connection to Internet or other means
for performing a digital communication session with other users.
Description
FIELD OF THE INVENTION
[0001] The present invention relates to systems and methods for
collecting payments in a distributed digital communications
environment. The invention relates in particular to large networks
and the Internet.
BACKGROUND OF THE INVENTION
[0002] In the present distributed digital communication systems,
service providers may find it difficult to collect a fee for
services performed. It may be desirable for users to have an
instrument for paying for various services or products available in
the net.
[0003] At present, it is not possible for service/product providers
to get paid for service where the provider does not take part in
every transaction. Prior art systems and methods may not be
suitable to answer this need.
[0004] Thus, a service provide may possibly devise a software
package with an integral module which accounts for the use of the
software, so that the service provider may charge the user
accordingly. Thus, for example, a provider of a registered E-mail
service may be paid for services provided.
[0005] A weak point in such a software is that it is too easy to
neutralize the accounting module, to render it inoperable, so that
the user may use the software for free.
[0006] And, if one user does not have the required technical skills
for that, he/she may be sure that a hacker somewhere across the
globe already did it, and that a "cracked/broken" version of the
software is available on the Internet. Thus, a hacker or
unauthorized person may spread worldwide a software package to
attack the legitimate software. This may result in a large scale
misuse of the software, while avoiding the required payment.
[0007] At present, it is impossible to detect such an attack on
one's software or to prevent it. It is impossible to detect
illegitimate use of the software, that is use of "cracked" software
which denies the software owner their legitimate profits.
[0008] In the present business climate, with users of the software
spread across the globe, it is very difficult or impossible to
enforce a policy or to survey transactions performed.
[0009] Another approach to the fee collecting problem may be to
channel all transactions through the service provider's facility.
The service provider then has control on any and all transactions
being performed, and can enforce a payment policy as desired.
[0010] This would require a tremendous investment by the service
provider, to set up huge service centers worldwide, capable of
concurrently serving many users. Thus, this approach may not be
practical. It is therefore not desirable that the service provider
take part in any and all transactions between users.
[0011] Still another payment method may include the user using
his/her credit card to pay in real time for any transaction.
[0012] The disadvantage of this method is that the credit card
number may be compromised, since the Internet and similar links are
not secure. If an unauthorized person intercepts the credit card
information, this may be used in fraudulent transactions. The card
owner may find it difficult to prove a specific transaction was not
authorized, or even to detect some of the unauthorized charges.
[0013] At present, a person paying with his/her credit card over
the Internet may be exposed to large losses. Thus, payment over a
distributed net is difficult.
[0014] Still more difficult is collecting fees for transactions
between two parties, where the service provider is a third party
and is not a party to the actual transactions.
[0015] For example, a provider of walkie-talkie devices or wireless
sets cannot collect a fee from each call, since the communication
is direct between users, without the manufacturer's mediation.
[0016] Another example is the use of a software for premium
services relating to E-mail. It may be advantageous both to
manufacturer and user to charge per use, not a global fee for the
software. But how to account for use of the software? The
manufacturer may even not be aware of the existence of the user,
who may have obtained the software from a third party.
[0017] Still another problem with prior art systems is the use of
"digital cash". Prior art systems involve the issuance of "digital
cash" which include a credit for a fixed amount of money, signed by
the "cash" issuer.
[0018] A possible problem is that these documents can be copied, so
each can be used in multiple transactions. To prevent that, the
issuer maintains a center which approves in real time each "cash"
to be used. This is an immense task, to participate in every
business transaction worldwide, more so when one considers the
small amounts involved.
[0019] At present, there apparently are no methods which may enable
a third party to collect a fee from transactions between two
parties over a distributed network, where the third party takes no
part in the actual transactions between the two parties.
[0020] Patent Application No. 122,263 has been filed in Israel on
this invention by the present inventor. Application PCT/IL98/00563
has been subsequently filed with PCT.
[0021] It is an objective of the present invention to provide for a
system and method of payment using tokens, with means for
overcoming the abovedetailed deficiencies.
SUMMARY OF THE INVENTION
[0022] It is an object of the present invention to provide a system
and method for collecting payments or paying for a service or
product in a distributed digital communications environment,
especially suitable for large networks and the Internet.
[0023] In accordance with the invention, the object is basically
accomplished using a method of payment including the steps of (a) A
transaction management unit receives from a user there a request to
perform a service for which payment with tokens is required; (b)
The management unit checks whether there are yet unused tokens
available in the system. If an unused token was found, go to step
(c); If there are no available tokens, then the service cannot be
performed, END; (c) The management unit requests information on an
available token and changes its status to "canceled"; (d) During
the subsequent transaction with the second party, the management
unit sends information relating to the token now used and canceled
to the second party.
[0024] The invention allows a third party to collect a fee from a
transaction between two parties, even though the third party does
not participate in transactions between the two parties.
[0025] According to one aspect of the present invention, a user is
provided with electronic tokens or stamps, against a payment. The
user, while using the service performed by the service provider,
destroys a token or stamp as payment for that service. After
several uses of the service, the tokens are all "used" or
"destroyed", so the user has to buy new tokens for future use of
the service.
[0026] Moreover, the method may be used to pay for various
available services or products.
[0027] According to a second aspect of the present invention, the
user is required to make public or present proof that he/she indeed
did destroy the tokens as required.
[0028] Thus, a party to a transaction and the public in general can
monitor the legitimacy of the use of tokens by a specific user.
Thus, a large number of possible monitoring persons may verify a
large number of the service or software, to ensure there are no
illegitimate transactions, or at least that the number of these
illegitimate transaction will not grow to large numbers.
[0029] According to a third aspect of the present invention, the
system and method performs an automatic process of presenting proof
of destroying the tokens, and of checking that the other party
presented a legitimate proof as well. Thus, during normal
transactions between users, users will check each other with
respect to the performance of payments as required, without
requiring a deliberate effort on the part of the users.
Furthermore, the software package will include means for
automatically displaying and reporting any detected lack of payment
or lack of report of tokens being destroyed as required.
[0030] According to still another aspect of the present invention,
the system and method include means for diffusing the information
on the use of tokens among many users, to allow high visibility of
each user's proper conduct.
[0031] Another important aspect of the use of tokens is to pay to a
second party for a service or product. Whereas the tokens provider
will eventually pay to the second party, there is no need that the
tokens provider approve in real time each and every
transaction.
[0032] Moreover, the invention discloses an effective method for
dissemination of tokens to users. The special structure and
operation of a large-scale, distributed payment system impose
special requirements, including inter glia the need to effectively
distribute tokens to a huge number of users of these tokens, and to
keep track of them all.
[0033] Further objects, advantages and other features of the
present invention will become obvious to those skilled in the art
upon reading the disclosure set forth hereinafter.
BRIEF DESCRIPTION OF DRAWINGS
[0034] FIG. 1 illustrates the structure of a system for presenting
reports on tokens to other users, and for monitoring other's
reports.
[0035] FIG. 2 details the structure of a token information
management and storage database.
[0036] FIG. 3 illustrates the structure of a report detailing the
use of tokens.
[0037] FIG. 4 illustrates the use of reports on tokens in
transactions between various users, with FIGS. 4(A), 4(B) and 4(C)
illustrating three possible consecutive transactions.
[0038] FIG. 5 illustrates another embodiment of the structure of a
report detailing the use of tokens.
[0039] FIG. 6 illustrates a structure of a tokens use report, with
means for token use diffusion among users.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0040] A preferred embodiment of the present invention will now be
described by way of example and with reference to the accompanying
drawings.
[0041] Referring to FIG. 1, a system for presenting reports on
tokens to other users and for monitoring other's reports may
include the following parts:
[0042] 1. a transactions management unit 11, using tokens. The unit
11 is activated when the user requires to perform a service for
which payment using tokens is required. For example, such a service
may include a special type of E-mail or an encryption procedure or
other service provided, on the Internet or elsewhere.
[0043] 2. a tokens database 12, which includes information on
tokens acquired from the service provider, which is usually also
the tokens issuer. Unit 11 reads tokens from the database 12 each
time there is a requirement to use the service and pay with tokens.
Only if there are tokens available, will the service be performed.
If the service is performed, then the database 12 is instructed to
"cancel" the token, that is to indicate that the token was
used.
[0044] Thus, database 12 serves as a storage for tokens, keeping
both used and available tokens and additional information related
to these tokens.
[0045] 3. tokens use monitoring unit 13, to verify the correct use
of tokens by other parties who connect to the system as shown.
[0046] 4. a database of tokens reports 14, including information on
acquired tokens available for performing the service for fee. Each
token also includes status indicating means, which change from
"ready" to "used" or "canceled" after a token is used.
[0047] 5. a communication channel to other users 15. Channel 15 may
include a telephone line and/or a wireless link or a connection to
Internet or other means for performing a digital communication
session with other users.
[0048] Tokens may be used as payment means for a wide variety of
services, for example including but not limited to registered
E-mail, legal E-mail, permits generation and management,
certificates generation and management.
[0049] Tokens may also be used to pay for products in commercial
transactions over the Internet.
[0050] To achieve these goals, the system detailed in FIG. 1 may be
used, together with methods to be detailed below.
Method 1 for Providing Paid Services
[0051] A method for providing service with tokens used as payment
means may include the following steps:
[0052] a. Transaction management unit 11 receives from the local
user a request to perform a service for which payment with tokens
is required.
[0053] b. Unit 11 checks whether there are yet unused tokens
available in the system, that is in tokens database 12, that is
tokens whose status is "ready" as opposed to "used" or
"canceled".
[0054] If an unused token was found, go to step (c);
[0055] If there are no available tokens, then indicate to the user
that the service cannot be performed because of lack of tokens,
then END.
[0056] If there are no available tokens, then indicate to the user
that the service cannot be performed because of lack of tokens,
then END.
[0057] c. Unit 11 requests and/or retrieves information on an
available (unused as yet) token from the database or storage unit
12. The status of the token which was retrieved will be
automatically changed in the database 12, and will thereafter be
designated as "used" or "canceled".
[0058] d. During the subsequent transaction with another party,
unit 11 sends information relating to the used token to that other
party, through channel 15.
Method 2 for Monitoring Proper Use of Tokens
[0059] A method for monitoring proper use of tokens by other users
may include the following steps:
[0060] a. Tokens use monitoring unit 13 receives reports from other
users, indicating their use of tokens and cancellation of tokens in
each transaction.
[0061] b. Unit 13 transfers the received reports to a database of
tokens reports 14, which including information on use of tokens by
other users. Preferably, latest information on tokens is store, and
oldest information is discarded.
[0062] c. Unit 13 requests and/or retrieves information on previous
reports from the same user from database 14.
[0063] d. Unit 13 processes reports on the use of tokens by the
other user, comparing according to predefined criteria.
[0064] e. If a criterion was violated, that is the reports indicate
a fraud or inappropriate use of tokens, then unit 13 stores that
information in database 14 and/or displays a violation report
and/or reports that to the tokens issuer, and/or sends a note to
the user of such token.
[0065] Thus, the structure and operation of the system detailed
above allows for secure payment over a distributed network. There
is no need that the tokens provider take part in each and every
transaction, since two parties can do business and report use of
tokens directly. Thus there is no requirement that a huge center be
organized, to approve each transaction.
[0066] Moreover, the abovedetailed system and method allow a third
party (the tokens issuer) to collect a fee from a transaction
between two parties, even though that third party does not
participate in transactions between the two parties.
[0067] For example, with a walkie-talkie/wireless sets provider,
the provider can now collect a fee per call, using tokens. Tokens
may be loaded into the wireless set and their use accounted for as
detailed above, including a report to the other party for
verification purposes.
[0068] Using this invention, wireless sets like citizen band
systems can now be sold at a discount or even distributed for free,
like cellular sets. Until now, that was not possible since, whereas
cellular sets connect through a center and bring a fee to the
manufacturer each time the set is used, wireless sets are used
directly between users and a fee policy could not be enforced.
[0069] Another example--now a software package for premium services
relating to E-mail may be freely distributed, and the provider may
get paid as the package is used.
[0070] Although the package is used directly between users, without
the intervention of the software provider, the use of tokens as per
the present invention ensures that the software provider will be
paid for the service.
[0071] The invention may be advantageously used to pay for services
on a network, especially for services required irregularly, where
the user desires to pay per use.
[0072] For example, a user may desire to connect to a database. The
prevalent method of payment now in use is a subscription for a
fixed period, so that during that period the user is permitted
unlimited access to the database, or a given amount of time. This
may not be a satisfactory solution, since there are so many
databases and other services now available, that a user may desire
to use just a short time in each of them. But it may not be
economical to subscribe to all of them, and to pay for a long time
in each, where the user expects not to fully utilize all that
time.
[0073] The use of tokens according to the present invention solves
the problem, since now the user is free to select each of the
services which accept these tokens, and pay only as per actual
use.
[0074] Other examples of resources in a net may be hardcopy
printers belonging to a third party. A user may use the printer and
pay with tokens, according to the volume of use, or the number of
pages printed.
[0075] Another example would be for network computers. A new
concept in computers relates to a system where each user will have
just a simple, low cost computer, and will use software resources
available in the net. For a commercially viable system, there
should be a payment for the use of these resources.
[0076] Resources may include advanced word processors, database
systems, super fast signal processors and much more. There are so
many resources available, and so many users. There is the difficult
problem of paying for the use of these resources, and for
accounting for actual use of each resource by each user.
[0077] All these problems are solved with the tokens according to
the present invention, as detailed above. The provider of the
services may offer the services through many outlets. Separately,
the provider sells tokens for the use of these resources. Then the
provider does not have to take part in every transaction, but the
tokens will be used and new tokens will have to be bought by users,
as detailed above.
[0078] The abovedetailed applications refer to payments to a third
party for services rendered.
[0079] Another important application of tokens is to actually pay
to a second party for a service or product. According to
implementation, tokens may each represent a fixed amount of money
or time of use of resource, or a specific number of calls using a
resource.
[0080] A token may represent a prepaid amount of money, or a credit
to that specific amount.
[0081] An example involves not the Internet, but a local net, like
a net in a business center. Many firms may have offices in the
center, and they all may occasionally use services provided by
other firms there, like printing or copying or data archiving or
CD-ROM programming or ordering products like office supplies.
[0082] All the firms, customers and service providers, are
connected through the local communication net. Services are ordered
through the net, and payment is made with tokens according to the
present invention.
[0083] Another example is in motels where a counter is activated
for the use of electricity or gas. The counter is coin operated,
and the guest pays in advance for a specific amount of the service
to be used.
[0084] Here, tokens are used to actually pay to a second party for
a service or product. Unlike prior systems, here there is no need
that the tokens provider approve in real time each and every
transaction. Thus, no huge centers are required to support all the
transactions in the world.
[0085] Some amount of fraud is expected, but fraud has a good
chance of being detected and may possibly be traceable to source.
This is achieved with a relatively low cost center, that is a
center which does not take part in every transaction and does not
have to respond in real time.
[0086] No system is completely secure, as intruders may interfere
with the authorization process itself, may break the encryption
codes or may devise other methods. In a commercial enterprise, what
matters is the level of security versus the cost to achieve it.
[0087] If a statistically reasonable security is achieved at
reasonable cost, that may be satisfactory; losses may be further
reduced with insurance. This is a practical solution to security
over the net.
[0088] Thus, an acceptable business solution can be achieved.
[0089] FIG. 2 details the structure of a token information
management and storage database.
[0090] This is one embodiment of information stored in the tokens
database 12 (see FIG. 1).
[0091] Database 12 may include token identification part 21, which
includes (not shown) token unique serial number and optional
additional information, all signed or encrypted with the private
key of the service provider and/or the tokens issuer.
[0092] The optional information may include the value of a token,
if several products/services are available. Thus, the present
invention is not limited to use/payment with one service provider.
Tokens may be presented to various providers of services or
products.
[0093] If token is presented to a third party, that party may
require payment from the tokens issuer, so in effect the issuer
performs the actual payment between users.
[0094] A token status part 22, indicates whether the token was
already used or not. If not--it is ready and available for the next
use.
[0095] A date of use 23, available only for used tokens. Allows
subsequent monitoring of transactions and adequate use of
tokens.
[0096] A time of use 24, only used for used tokens. Allows more
precise monitoring of the use of tokens, since many tokens may be
used daily and a finer time resolution may be required. In the
example, time is given in hours.minutes. A more precise indication
may be used, for example down to seconds and even parts of a
second. The exact time is less important, than the relative timing
of consecutive reports from any specific user.
[0097] Tokens are preferably arranged in chronological order of
use, with last used token placed first in the list, as shown.
Unused tokens are preferably arranged in chronological order with
earliest token first. This structure allows for more efficient,
faster processing by recipient.
[0098] In the example shown, the tokens T-100, T-101 and T-102 were
already used, as indicated in the status part 22 and the date of
use 23 and time 24.
[0099] Tokens T-103 to T-111, T-903 and T-903 are ready to use.
[0100] Tokens T-100 to T-111 may have been issued at a specific
date, with tokens T-903 and T-903 issued at a later date. Hence the
different serial number and the relative location in the table.
[0101] FIG. 3 illustrates the structure of a report detailing the
use of tokens. This is sent to another user during a transaction
therebetween which requires that User-1 will "spend" or "use" or
"lose" a token.
[0102] The report is sent so as to show the other party that indeed
payment was performed for the transaction.
[0103] This report enables the second party to verify that indeed
User-1 had a token available prior to the transaction, and did
destroy that token during the transaction, as required.
[0104] As detailed there, the logical parts of the report in column
31, with an example of possible specific values assigned to these
parts in column 32.
[0105] User of service ID 331 contains the name or nickname or
other information to identify the user who pays with tokens. The
name should be understood or traceable by the service provider
and/or tokens issuer, since they are the ultimate party who
monitors the use of their tokens. In this example, a nickname
"User-1" is reported.
[0106] Tokens are preferably arranged in chronological order of
use, with the last used token (the token used in the present
transaction) being placed first in the list, as shown.
[0107] The report may otherwise indicate which token was used last,
and the order of use of previous tokens. This information is
helpful to allow monitoring for correct use of tokens, as detailed
below.
[0108] There may be a limit on the number of used tokens reported,
to keep the communications effective. Then--only the last token(s)
may be transmitted to other users, for example one or five or ten
or 100 for example. Here, only three previous tokens are shown,
however the actual number of tokens may be much larger.
[0109] The date of use 332 indicates the date of use of the
service, that is the day when a specific token (to be detailed as
well) was destroyed or canceled. In the example, the date is
10.26.97.
[0110] The time of use 333 is the time when the token was canceled,
here 19.55.
[0111] In one embodiment of the invention, a common time may be
used by all the users in the system, for example Greenwich
time.
[0112] In another embodiment, each user presents his/her local
time. Since time of various reports is compared separately for each
user, there is no need to compare time reports among different
users, so there is no need for a uniform time base.
[0113] In other words, consecutive reports from any user may be
checked to ensure that the time and date reported therein are in
chronological order. It is not allowed to prevent a report, and to
send it at a later date--this may be indicative of fraudulent
activity. The time relationship among reports from different users,
however, may not include significant information indicative of
possible fraud, and in any case are much more difficult to
verify.
[0114] The token ID 334 indicates the specific token which was used
in the present transaction, in this example the value was T-103.
Token ID 334 may include (not shown) an unique serial number,
together with the signature of the tokens issuer. The signature may
use the private key of the issuer. Alternatively, an unique
combination of serial code and date may be used. In still another
embodiment, a digital code indicative of time of issue may be
used.
[0115] Additional optional information may include the details of
the buyer of that token (to whom it was sold), an expiry date
and/or other information. All the information may be signed by the
tokens provider.
[0116] Previous token ID 335 indicates the token which was used in
a previous transaction by User-1, that is the last token used
before token T-103. In the example, this was token T-102.
[0117] A report including this information allows the other party
to the transaction to verify that the tokens reported to be used
are changing with time, that is that User-1 updates his/her tokens
database and presents each time a different token, thus User-1 pays
for the transaction with tokens, as required.
[0118] The date of use 336 may be useful for monitoring the use of
tokens, here its value is 10.22.97.
[0119] The time of use 337 allows a more precise comparison and
evaluation of reports, here it was 14.50.
[0120] A plurality of previously used tokens is preferable since it
increases the chance that the other party has in their database a
related report, and can detect discrepancies if the use of tokens
was not proper.
[0121] In the example illustrated, previous token ID 338 is T-101,
and its date of use 339 is 10.22.97. Time of use 340 is 13.15.
[0122] Still a previous token used ID 341 was, in this example,
T-100. The date of use 342 was 10.22.97, and the time of use 343
was 11.05.
[0123] The signature of user 344 is proof that User-1 sent that
report. It may include a hash or CRC of the abovementioned
information, encrypted with the private key of User-1.
[0124] Using the information in the report as detailed in FIG. 3, a
tokens use monitoring unit 13 (See FIG. 1) at another user's
facility may monitor the transaction for proper use of tokens. The
monitoring unit 13 uses information in a database of tokens reports
14 attached thereto.
[0125] An implementation of a monitoring routine is illustrated as
Method 13 below. The method is automatically performed by computer
means (not shown) at another user's facility.
Method 3 for Monitoring Use of Tokens
[0126] A second user, upon receiving a tokens use report, can
evaluate the report to determine whether improper use of tokens has
been made by User-1, by performing the following steps:
[0127] a. The token ID, date and time of all tokens reported are
compared, to ensure that they are different. That is, there are no
two tokens with identical ID, and there are no two tokens which
were used at exactly the same date and time.
[0128] If two identical tokens or identical time/date was
found--then a discrepancy was detected, go to step (z) (store,
display and/or report misuse of tokens).
[0129] b. The date and time of all tokens reported are compared, to
verify whether they are in chronological order, with the last token
used located first in the list.
[0130] If they are not in order--then a discrepancy was detected,
go to step (z) (store, display and/or report misuse of tokens).
[0131] c. Each token in the report is compared with tokens stored
in the database of tokens reports 14 (see FIG. 1), for User-1.
[0132] If a token with the same ID was detected, but with a
different time/date, or a token with an identical time/date but
with a different token ID was found in the database, then a
discrepancy was detected, go to step (z).
[0133] d. The time span of the tokens in the report is evaluated,
that is the time between the first used token and the last used
token.
[0134] If a token report was found in the database, whose time is
within the above time span but for which there is no corresponding
token report in the report, then a token report is missing, thus a
discrepancy was detected, go to step (z).
[0135] e. Conclusion: no discrepancy was found. END.
[0136] z. Conclusion: a discrepancy was detected. Store details of
present transaction, display to user and/or report misuse of
tokens. END.
[0137] The above method is efficient in a statistical sense. It
cannot guarantee that absolutely no one will misuse the system,
however misuse on a large scale has a good chance of being
detected. Thus, it is not necessary that each user store huge
databases with reports of past use of tokens. Even with modest
databases, a user who frequently misuses the system has a good
chance of being detected doing so.
[0138] The method can thus effectively prevent large scale fraud
and avoidance of payments due.
[0139] FIG. 4 illustrates the use of reports on tokens in
transactions between various users.
[0140] As illustrated in FIG. 4(A), a first user 1 (User-1) may
connect to various other users. It is assumed in the example that
first user 1 is the party who has to pay with tokens for the
transactions as detailed.
[0141] An identical method is used when user 1 is addressed by
another party, and that other party then sends a report
instead.
[0142] A first user 1 connects through communication channel 15 to
a second user 18 (User-2 in the example).
[0143] A tokens use report 3 is sent from first user 1 to the
second user 18. Report 3 includes details on token T-104 (the
presently used token) as well as previously used tokens T-103,
T-102, T-101 and T-100. Actually a report 3 may be more detailed,
to include for example information as detailed in FIG. 3 above.
[0144] This is apparently a legitimate transaction with legitimate
past transactions, since all the tokens are different and in
consecutive order.
[0145] A subsequent transaction is illustrated in FIG. 4(B). Here,
the first user 1 (User-1) connects to a third user 19 (User-51),
through communication channel 152. The communication channels may
be different, or the same channel may be used.
[0146] A tokens use report 38 is sent from first user 1 to third
user 19. Report 38 is an updated version of report 3 above, to
indicate token T-105 as the presently used token. Token T-104 now
belongs to the previously used tokens list, together with T-103,
T-102 and T-101.
[0147] Assuming that the reports are limited to four previous
tokens, then token T-100 (the oldest) is now removed from the
report. The list may include many more tokens, however it should
preferably be limited anyway, to prevent waste of communication
time and of storage space. Thus, a limit will be reached
eventually, and then the oldest tokens will be removed from
subsequently transmitted reports.
[0148] A later transaction is illustrated in FIG. 4(C). Here, for
example, the first user 1 (User-1) connects again to the second
user 18 (User-2).
[0149] A communication channel 152 may be used, maybe a channel
different than that used in the previous transaction illustrated in
FIG. 4(A).
[0150] A tokens use report 39 is sent from first user 1 to second
user 18.
[0151] Again the report 39 is an updated version of report 38, to
indicate token T-106 as the presently used token. Tokens T-105,
T-104 now belong to the previously used tokens list, together with
T-103 and T-102. Token T-101 (the oldest) is now being removed from
the report 39.
[0152] The reports 3 and 39 associated with the transactions with
second user 18 now allow the second user 18 to compare the reports
to verify whether the first user 1 is using tokens properly, as
detailed in Method 4 below.
Method 4 for Monitoring the Use of Tokens
[0153] A user 18, upon receiving two subsequent token use reports
3, 39 from a first user 1, may evaluate the reports to determine
whether improper use of tokens was made, by performing the
following steps:
[0154] a. The tokens used in the two reports 3, 39 are compared to
ensure they are different (that is, the token ID is different).
[0155] If the same token is used in different transactions--then a
discrepancy was detected, go to step (z) (store, display and/or
report misuse of tokens).
[0156] In the example as shown, report 3 indicates that token T-104
was used, whereas later report 39 indicates the use of token T-105.
Therefore, there appear to be no discrepancy in this respect.
[0157] b. The date and time of the tokens used in the two reports
are compared, to verify whether they are in chronological
order.
[0158] If the later report 39 has the same date/time as the earlier
report 3, or if the later report 39 has an earlier date/time than
the earlier report 3--then a discrepancy was detected, go to step
(z) (store, display and/or report misuse of tokens).
[0159] In the example as shown, the date and time was not detailed
in reports 3, 38 and 39. The method should be applied taking in
consideration the presented of such information in one or other
form, as illustrated and described with reference to FIG. 3
above.
[0160] c. Each token in one report 39 is compared with the tokens
stored in the other report 3. If there is an overlap between the
tokens, then the tokens should appear in the same order, with none
missing, otherwise a discrepancy is declared.
[0161] For example, if report 39 details used tokens as T-107,
T-106, T-105, T-103 and T-102, whereas report 3 indicated tokens
T-104, T-103, T-102, T-101 and T-100, then a discrepancy was
found--in the later report 39 the use of token T-104 between T-103
and T-105 is missing.
[0162] It was probably erased to allow fraudulent later reuse of
that token.
[0163] If a discrepancy was detected, then go to step (z).
[0164] d. Conclusion: no discrepancy was found. END.
[0165] z. Conclusion: a discrepancy was detected. Store details of
present transaction, display to user and/or report misuse of
tokens. END.
[0166] Again, the method is efficient in a statistical sense.
However, by comparing two or more reports from the same user, a
higher probability of detecting fraud by the first user 1 is
achieved.
[0167] FIG. 5 illustrates another embodiment of the structure of a
report detailing the use of tokens, with means for transferring
information on use of tokens between users.
[0168] The logical parts of the report in column 31, with an
example of possible specific values assigned to these parts in
column 32.
[0169] The report here differs from that illustrated in FIG. 3 in
that now the sender signs each token used, separately. Thus, the
report includes
[0170] User of service ID 331 contains the name or nickname or
other information to identify the user who pays with tokens.
[0171] Again, tokens are preferably arranged in chronological order
of use, with the last used token placed first in the list, as
shown.
[0172] Date of use 332 indicates the date of use of the service,
that is the day when a specific token (to be detailed as well) was
destroyed or canceled. In the example, the date is 10.26.97.
[0173] Time of use 333 is the time when the token was canceled,
here 19.55.
[0174] Token ID 334 indicates the specific token which was used in
the present transaction, in this example the value was T-103.
[0175] Signature-3 346 is the signature of the sender (User-1) on
the last token used, that is T-103 and related information. In the
example, its value is 3597711.
[0176] This is the difference from the report in FIG. 3--now each
token reported is also separately signed by the sending party, that
is the user who paid with that token and prepared the report
shown.
[0177] Similarly, other tokens in the report are each signed with
Signature-2 (347), Signature-1 (348) and Signature-0 (349)
respectively.
[0178] This structure allows the recipient to distribute part of
the token information to other users, so as to diffuse the
information relating to the use of tokens. This allows each user to
store information on the use of tokens from various users in their
respective database of tokens reports 14, and to subsequently
compare the information with other reports from other users or from
a user directly reporting to them on the use of tokens.
[0179] This is automatically implemented in the tokens use
monitoring unit 13, see FIG. 1.
[0180] FIG. 6 illustrates a structure of a tokens use report, with
means for diffusion of reports about token use among other
users.
[0181] Again, the logical parts of the report are illustrated in
column 31, with an example of possible specific values assigned to
these parts included in column 32.
[0182] The report includes two parts, a report on own use of tokens
41 and a report on other's use of tokens 42
[0183] The report 41 includes information on last tokens used by
the present sender, as detailed in FIG. 5 above and the related
description. It includes an indication of the user of service ID
331, with the name or nickname or other information to identify the
sender.
[0184] Date of use 332 indicates the date of use of the service,
that is when the token 334 was canceled.
[0185] Time of use 333 is the time when the token 334 was
canceled.
[0186] Token ID 334 indicates the specific token which was used in
the present transaction.
[0187] Signature-3 346 is the signature of the sender (User-1) on
the last token used. Similarly, report 41 further includes
information on previously used tokens as illustrated in FIGS. 6 and
5.
[0188] A report on others' use of tokens 42 is a collection of
token reports from various user, as sent by other users when they
connected to the present sender and reported their use of
tokens.
[0189] Thus, in the present example, user of service ID 421 refers
to an user designated as User-5, who had previously reported the
use of a token on the Date of use 422, that is the date when the
token 424 was canceled in the User-5 tokens database.
[0190] Time of use 423 is the time when the token 424 was canceled.
Token ID 424 indicates the specific token which was then used.
Signature-37 425 is the signature of the sender (User-5) on the
report relating to the use of that token, T-788 used.
[0191] Similarly, report 42 further includes information on other
users' use of tokens, like User-19 illustrated there.
[0192] Each such token report is extracted from a report from
another user, in the form as illustrated in FIG. 5. Thus, if the
sender signs for each token reported, then each token can be
included by recipient in his/her reports to other users.
[0193] Thus, a report regarding the use of a token becomes highly
visible, since it may be communicated to many other users.
[0194] The advantage of the method is that the public becomes the
watchdog over the proper use of the tokens.
[0195] The process is automatic, thus fast and effective, and does
not require an effort on the part of the user.
[0196] Since the reports on the use of tokens may be further
transferred to other users, there is no indication of the parties
to a specific transaction, at a given time. Thus, the privacy of
the transactions is preserved, while allowing the monitoring of the
use of tokens by many users.
[0197] When a user communicates with the token issuer entity, they
can transfer the various reports stored in that user's storage. The
tokens issuer can then perform further tests and comparisons based
on that information and additional information from other users, to
detect illegitimate use of tokens.
Method 5 for Dissemination of Information Relating to Use of
Tokens
[0198] a. unit 11 requests and/or retrieves information on an
available (unused as yet) token from the database or storage unit
12, as well as information on previously used tokens;
[0199] b. unit 11 prepares a first part of a token use report,
including information on the last token used as well as previous
tokens used by the present user;
[0200] c. tokens use monitoring unit 13 request and/or retrieves
from unit 14 reports on the use of tokens by other users, and
transfers these reports to unit 11;
[0201] d. unit 11 prepares a second part of a token use report,
including information on the use of tokens by other users;
[0202] e. a report including the first part prepared in step (b)
and a second part prepared in step (d) is sent to another user
during a paid transaction.
[0203] In another embodiment of the invention, the second part of
the report in step (d) may be performed by unit 13, then sent to
unit 11 or directly to the other user.
[0204] In still another embodiment, information relating to
violation of token use rules by others is always included in the
token use report. Thus the information on violations or fraud is
diffused throughout the system, until it reaches the tokens issuer
or other party with enforcing capabilities.
Method 6 for Verification of the Use of Tokens
[0205] a. Tokens use monitoring unit 13 receives reports from other
users, indicating their use of tokens, as well as information on
the use of tokens by others;
[0206] b. Unit 13 transfers the received reports to a database of
tokens reports 14;
[0207] c. Unit 13 organizes the information in database 14
according to chronological order and separately for each user;
[0208] d. For each user, the reports on the use of tokens are
processed as detailed in the following steps, to detect conflicts
or inconsistencies;
[0209] e. The token ID, date and time of all tokens reported are
compared, to ensure that they are different. That is, there are no
two tokens with identical ID, and there are no two tokens which
were used at exactly the same date and time.
[0210] If two identical tokens or identical time/date was
found--then a discrepancy was detected, go to step (z) (store,
display and/or report misuse of tokens).
[0211] f. The date and time of all tokens reported are compared, to
verify whether they are in chronological order, with the last token
used located first in the list.
[0212] If they are not in order--then a discrepancy was detected,
go to step (z) (store, display and/or report misuse of tokens).
[0213] g. Each token in the report is compared with tokens stored
in the database of tokens reports 14 (see FIG. 1), for User-1.
[0214] If a token with the same ID was detected, but with a
different time/date, or a token with an identical time/date but
with a different token ID was found in the database, then a
discrepancy was detected, go to step (z).
[0215] h. The time span of the tokens in the report is evaluated,
that is the time between the first used token and the last used
token.
[0216] If a token report was found in the database, whose time is
within the above time span but for which there is no corresponding
token report in the report, then a token report is missing, thus a
discrepancy was detected, go to step (z).
[0217] i. Conclusion: no discrepancy was found. END.
[0218] z. Conclusion: a discrepancy was detected. Store details of
present transaction, display to user and/or report misuse of
tokens. END.
[0219] Moreover, the present invention discloses an effective
method for dissemination of tokens to users. One possible method is
to create a file "token", to include an indication of the value of
the token, signed or encrypted with the private key of the tokens
provider.
[0220] Each token may represent a fixed amount of money or time of
use of resource, or a specific number of calls using a resource, as
the need be.
[0221] A disadvantage of the above method is that, for huge amounts
of tokens distributed to many users, it may be difficult for the
tokens issuer to keep track of them all, to prevent duplicates and
to detect fraud.
[0222] Thus the tokens issuer may become a bottleneck in the
digital commerce. The above special requirements stem from the
structure and operation of a large-scale, distributed payment
system.
[0223] A possible method to effectively distribute tokens to a huge
number of users and to keep track of them all is not to actually
create and distribute the tokens, but for the tokens issuer to give
permits to each user, to generate the tokens themselves, as
detailed in Method 7.
Method 7 for Tokens Creation by Users
[0224] a. User calls tokens issuer, and asks for a specific number
(K) of tokens. User pays for the tokens or uses credit, as per the
business arrangement between user and tokens issuer;
[0225] b. Token issuer prepares a digital document, allowing the
user to generate K tokens, with specific parameters. These may
include the value of each token, and the serial number of the first
and last token.
[0226] For example, the digital information in the document may
effectively say:
[0227] "User-73 is hereby allowed to issue 100 tokens at value $10
each, with serial numbers 240 to 339. Date issued: Oct. 15, 1997.
Valid for 6 months."
[0228] The above digital document is signed or encrypted with the
private key of the tokens issuer, and delivered to the user.
Actually, the document is delivered to a software package at the
user's facility, a software which is responsible for tokens issuing
and accounting for, that is unit 11, see FIG. 1;
[0229] c. To perform a paid transaction, the user software (unit
11) checks whether a token can be issued, according to the
permit/digital document. If positive, a counter of used tokens is
incremented, and a token prepared with a serial number which is the
successor of the last token generated, all within the serial
numbers according to the digital document.
[0230] For example, a token may effectively include the
following:
[0231] "Token No. 256, value $10, generated by User-73, according
to permit from Issuer-9". The token is signed or encrypted with the
private key of User-73.
[0232] If encrypted, then an indication to identify User-73 should
be left en clair, to allow decryption of the message. Go to step
(d).
[0233] If all the tokens were already generated according to the
digital document issued in step (a), then no token is generated,
and the user is informed accordingly "no more tokens available".
END.
[0234] d. Send the token prepared in step (c) together with the
digital document prepared in (a) to the other party, as proof of
payment for the present transaction. END.
[0235] A measure of safety is achieved in the above method, since
the user issuing these tokens may have to sign with his/her private
key, so that each token is traceable to source, and if there is
suspicion of fraudulent use, then a user may be held
accountable.
[0236] On the other hand, this very possibility may prevent users
from misusing the tokens in the first place, thus achieving the
desired safety.
[0237] Thus, the safety in this method is achieved not in a
centralized system with the center having "dictatorial" powers and
intervening in each transaction, but a distributed system
"democratic", where users participate in enforcing the tokens and
payment policy, and in checking that other users do the same.
[0238] In another embodiment of invention illustrated in Method 7,
a user will not report to others about the use of tokens, however
the system assigns to each token a serial number, with number in
ascending order.
[0239] A recipient of a token may compare the serial number of the
presently received token with the serial number of a previous token
or previous tokens. If the serial numbers are not all different
from each other and in ascending order, this is an indication of
tokens misuse. A tokens misuse is thus displayed for others to see.
The method is detailed below as Method 8.
Method 8 for Tokens Creation by Users
[0240] a. User calls tokens issuer, and asks for a specific number
(K) of tokens. User pays for the tokens or uses credit, as per the
business arrangement between user and tokens issuer;
[0241] b. Token issuer prepares a digital document, allowing the
user to generate K tokens, with specific parameters. These may
include the value of each token, and the serial number of the first
and last token.
[0242] For example, the digital information in the document may
effectively say:
[0243] "User-73 is hereby allowed to issue 100 tokens at value $10
each, with serial numbers 240 to 339. Date issued: Oct. 15, 1997.
Valid for 6 months."
[0244] The above digital document is signed or encrypted with the
private key of the tokens issuer;
[0245] c. To perform a paid transaction, the user software (unit
11) checks whether a token can be issued, according to the
permit/digital document. If positive, a counter of used tokens is
incremented, and a token is prepared with a serial number which
equals the previous serial number plus a fixed increment (for
example, the previous number plus 1), where all the serial numbers
are within the serial numbers according to the digital
document.
[0246] For example, a token may effectively include the following:
"Token No. 256, value $10, generated by User-73, according to
permit from Issuer-9". The token is signed or encrypted with the
private key of User-73. Go to step (d).
[0247] If all the tokens were already generated according to the
digital document issued in step (a), then no token is generated,
and the user is informed accordingly "no more tokens available".
END.
[0248] d. Send the token prepared in step (c) together with the
digital document prepared in (a) to the other party, as proof of
payment for the present transaction. END.
[0249] In the above method, there is no need to indicate the date
and time, since the serial number of tokens may be used to detect
misuse of tokens.
[0250] Various embodiments of the present invention will become
apparent to persons skilled in the art upon reading the present
disclosure.
[0251] For example, the order of implementation of the steps in the
above methods may be interchanged, while still performing the basic
function detailed therein.
[0252] It is possible to use tokens of various value, where the
value of each token is embedded in the token ID as created by the
token issuer. This allows the user to pay various amounts for
different services or products, as the need be. This is equivalent
to the use of different money bills, each having a different
value.
[0253] In this case, as the tokens are arranged in the order of
their issue, the tokens may also be arranged in the order of their
value. Alternately, several separate sections may be used in tokens
database 12, each section including only tokens of a specific
value.
[0254] To pay varying amounts of money, the methods may be updated
to permit the use of a plurality of tokens at one time/date. Such
an activity will then be considered as valid.
[0255] The recipient has the ability to verify that the tokens are
valid, by performing a hash or CRC, then decrypting the hash or CRC
in the token with the known, public key of the tokens issuer, and
comparing results. If the results do not correspond, then the
tokens are false.
[0256] The recipient also has the ability to verify the signature
of the reports sending party, again by verifying the signature of
that party as detailed above: perform a hash or CRC, then decrypt
the hash or CRC in the report with the known, public key of the
other user issuer, and compare results. If the results do not
correspond, then the other user is an impostor.
[0257] Throughout the present disclosure, signature by a party
involves the computation of a hash or CRC of a piece of
information, and encryption of the hash or CRC with the private key
of the sender.
[0258] A token may include additional information, for example a
picture and/or graphics and/or an audio message. Thus a digital
token may resemble an ordinary coin, by having a value attached
thereto as well as additional information.
[0259] A token may be used as letterhead or paper for a firm. The
firm assigns tokens to employees, who can use these tokens in
official letters, for example in E-mail messages. The token becomes
the letterhead of the company in this electronic paper application.
The company may authorize employees to use a token in each E-mail
message sent in the course of their work.
[0260] Thus, the token is used as digital paper, to "write"
messages thereon.
[0261] The tokens need not be prepaid by the user. It is possible
to include advertising in the token, with the firm benefiting from
the advertising paying for the use of tokens. This approach may be
better suited for the Internet environment, where services are
generally free. Other methods to replace direct payment by the user
may be used.
[0262] The advertising may be implemented in the additional
information in the token, which may include pictures, graphics,
audio and/or other information.
[0263] It will be recognized that the foregoing is but one example
of an apparatus and method within the scope of the present
invention and that various modifications will occur to those
skilled in the art upon reading the disclosure set forth
hereinbefore.
* * * * *