Note: Descriptions are shown in the official language in which they were submitted.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
ADVANCED ASSET MANAGEMENT SYSTEMS
The present invention relates to computer-based systems, processes and
methods for the management of, and the transmission, transfer, receipt,
aggregation,
distribution, and exchange of, cash and non-cash assets. This invention also
covers
data processing: financial, business practice, management or cost/price
determination.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Businesses, consumers and institutions have a multitude of reasons to transfer
assets from one to another, but regardless of their reasons have two basic
requests:
that the asset transfer mechanism afford some level of security, and that it
allow for
s either privacy (anonymity) or identification at will. Current financial
instruments and
their attendant asset transfer mechanisms offer various levels of one or the
other, but
not complete levels of both.
Commercial transactions and the corresponding association of value for
physical assets form a key basis of civilization. Among the earliest records
of
mankind are records of sale and manifests of assets. The earliest transaction
type,
barter exchange arrangements for goods, is still used today. Barter requires
that both
parties have something of value to exchange and must be physically present to
effect
the change of ownership of these goods. Merchants frequently used high value
objects to minimize the amount of goods necessary to complete the transaction,
15 choosing goods that were perpetually scarce such as gems, spices, and most
often
precious metals. Governments formalized and standardized the weight and
quality of
these scarce metals, minting coins used to replace commodities in facilitating
exchanges.
However, the weight of coinage made it impractical to move about with ease.
2o Inflation, along with the law of supply and demand created variations in
both the
worth of precious metals and their availability for use as currency. To
address these
issues, banking institutions created private paper currencies of fixed
denominations
whose value was based on the assets of the institution. However, these
multiple
private currencies were frequently not accepted at par value due to the risk
of
2s instability of the issuing institutions.
Governments addressed those problems by creating paper currency in fixed
denominations whose value was based upon an equivalent amount of precious
metal
stored at a central repository. The entire pool of currency was allowed to
change in
value as compared to the worth of the underlying assets and the stability of
the issuing
3o government. When the economy grew to require more circulating currency, far
exceeding existing precious metal assets, governments simply severed the link.
This
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
left the currency with a fixed denomination but now backed by the "faith and
credit"
of the issuing government, instead of actual assets.
Paper currency (cash) retained the best attributes of coinage, which included
being lightweight, transferable, bearer-owned, anonymous, and having a fixed
value
relative to the issuing nation. Today, the vast majority of transactions take
place
through the use of coin and paper currency. Just focusing on the interaction
between
individuals and institutions, over 550 billion coin and currency transactions
take place
each year. This number, vast as it is, does not take into account the large
number of
transactions that take place between individuals, since many gifts, wagers,
and other
1o transactions are not recorded.
The use of coin and paper (currency) for transactions is justified in that
both
are by statute considered legal tender, and thus are always valid for
conducting
business. Additionally, currency offers the privacy (anonymity and
untraceablity) that
individuals and institutions value while conducting their affairs. However,
currency
~ 5 transactions continue to suffer from the same limitations that have
plagued them since
inception: both buyers and sellers (or their agents) must be physically
present to
-,
conduct a transaction. In a modern age of national and global economies,
having to
be physically present to consummate a transaction is a distinct disadvantage.
Currency transactions pose other disadvantages as well. Individual cash
2o transactions are burdened by the need to offer precise amounts or dispense
correct
change. Furthermore, the handling and managing (including guarding) of paper
cash
and coins is inconvenient, costly and time consuming for both individuals and
financial institutions alike. It is estimated that in the United States alone,
$60 billion
is spent annually by money handlers simply to move money from one location to
25 another. The security of paper money is seriously threatened by the
relative ease of
counterfeiting using, for example, widely accessible, high quality color
copiers.
Consequently, financial institutions and corresponding government entities
have created a set of secure electronic funds transfer mechanisms affording
greater
security to move the value of cash funds between locations. Financial
institutions
3o have created new types of substitutes for cash that include checks,
traveler's checks,
money orders, and debit cards. They have also created instant credit
instruments such
as credit cards. Generally, these alternative electronic money systems require
that two
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
of the key attributes of cash are lost: anonymity and bearer-ownership. These
electronic money systems provide the ability to execute transactions from a
distance
such as mail order or electronic commerce since funds are guaranteed using a
third
party (usually a bank or other financial institution) for payment.
However, as each of these instruments and its various processing methods
were created and enhanced, new means of circumventing their security
safeguards
were likewise invented. Nearly 100 billion checks are written every year, with
more
than $140 billion en route to banks on any given day. Check fraud costs
individuals,
businesses and financial institutions in excess of $1 billion in losses
annually.
1 o Credit, debit and ATM cards now account for almost 40 billion transactions
per year. Losses associated with these financial instruments exceed $1 billion
annually. Each new step to enhance the security and increase the automation of
the
transmission of assets by financial institutions has resulted in reduced
privacy and loss
of anonymity for individuals.
~ 5 Account numbers for currently available financial instruments such as
credit
cards, debit cards, and checking accounts are easily stolen. Transaction
receipts
contain the card number, account holder name, and sometimes an imprint of the
entire
card, which would include an expiration date. Receipts are gathered by
identity
thieves by "dumpster diving," a practice of gleaning discarded receipts from
the trash.
2o Further, unscrupulous waiters in restaurants and others with the
opportunity to
directly handle these instruments can use "card skimmers," small devices that
contain
a magnetic stripe reader with a small memory that stores the card numbers for
later
retrieval, to capture this information.
With catalog and Internet e-commerce sales, the physical card need never be
25 presented to the merchant to successfully complete a transaction. Liability
for loss in
Card Not Present (CNP) credit card transactions typically is assumed by the
merchant,
instead of the issuing bank. Under US law, the consumer is generally subject
to a
maximum liability for credit card fraud of fifty dollars, which frequently is
waived.
However, while not necessarily directly impacted by such fraud, they are
indirectly as
so merchants are forced to pass on the costs of fraud to all of their
customers by raising
prices.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Debit cards, which may bear a credit card logo, are a simple link to an
underlying account and provide the consumer no equivalent protections. Most
consumers are unawaxe that their debit card provides little protection against
fraud
and that they assume the risk, not their financial institution or the
merchant.
Electronic checks can be created and submitted to the Automated Clearing
House (ACH) without a signature, a common practice among collection
departments.
In either situation, it is very easy to create fraudulent chaxges using a
stolen account
number because the account number changes only when the account is closed and
re-
opened or when fraudulent activity is detected. Additionally, new services
such as
check-by-fax allow fraudulent use of any valid account number.
The rate of identity theft and of corresponding fraudulent activity is
increasing. The Internet has provided a global communications medium whereby a
thief stealing credit card and other identity information can barter, sell, or
give away
that information by transmitting it to a few individuals or large groups.
Those
~5 ' recipients may be distributed worldwide, causing an account stolen in New
York City
to incur fraudulent charges in Asia or Europe within minutes or hours.
Internet e-commerce sites frequently axe also the subjects of hacker attacks.
Although account numbers are usually well protected by encryption when
transmitted
from the consumer's web browser to the e-commerce server, the account numbers
are
2o frequently stored for later retrieval as part of a one-click buying
process.
Additionally, the e-commerce servers retain log files of the transactions that
are used
for later accounting and auditing purposes. The account information stored on
the e-
commerce server or in the log files is rarely encrypted or protected. Thus,
even if the
consumer takes all available precautions, the merchant rnay be unwittingly
exposing
z5 large quantities of accounts. News reports have documented instances of
entire
databases of account and identity (including name and address) information
being
stolen en masse, in quantities ranging from twenty-five thousand to almost a
half
million accounts.
At the same time, corporations have begun building massive databases in
30 order to track and predict individual consumer behavior. To acquire the
information
necessary to build these predictive models, corporations have created a
variety of
reward and loyalty programs, such as proprietary point card systems (e.g.,
frequent
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
flyer miles). They have also created new types of financial instruments that
provide a
card to the consumer with various credits, minutes or other point schemes that
are
purchased for an initial quantity of cash. These points have an initial value,
but
usually cannot be converted back to currency. Corporate marketing has created
an
endless supply of discounts, coupons, and other incentives which typically
carry a
cash value of 1/20th of a cent but may have a worth that is substantially
greater when
applied in conjunction with the appropriate transaction. The data warehouses
used in
conjunction with these corporate marketing programs maintain extensive
customer
profile databases, replete with demographic characteristics, buying patterns,
spending
histories, personal preferences, lifestyle indicators, etc.
This automation and computerized profiling is robbing individuals of the
ability to monitor and control the ways information about them is collected
and used.
Already, public and private sector organizations acquire extensive personal
information and exchange it amongst themselves with few restrictions.
Individuals
have no way of knowing if this information is inaccurate, outdated, or
otherwise
inappropriate, and may only find out when they are falsely accused or denied
access
to services. New and more serious dangers derive from computerized pattern
recognition techniques as applied in data warehouse and data mining
applications:
even a small group using these and tapping into data gathered in everyday
consumer
2o transactions could secretly conduct mass surveillance, inferring
individuals' lifestyles,
activities, and associations. The automation of payment and other consumer
transactions is expanding these dangers to an unprecedented extent by exposing
transaction details most consumers would prefer to keep secret. The resulting
potential for misuse of data could have a chilling effect on individual
financial
2s security and personal freedom.
Two technologies previously offered to provide some measure of security
while maintaining a desired level of anonymity axe smartcards and electronic
wallets.
These portable electronic purses can contain a cash equivalent value, program
point
balances, and other personal information. However, neither of these
technologies has
3o gained a significant market acceptance because they require that a new type
of
merchant point of sale and banking infrastructure be created to access and
maintain
account information. Both technologies have the potential to be issued in an
anonymous, bearer-owned format, but are unlikely to be widely adopted by the
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
public. Banks and credit card issuers have sponsored pilot smartcard
implementations
with little success outside of niche markets like travel fare cards.
Electronic wallets
are deployed by web portals as a basis for instant, one-click buying on the
Internet,
but they simply manage lists of credit cards and personal information, having
no
capability to perform anonymous transactions.
Another technology more recently proposed is the use of various
"micropayment" strategies, which allow for small transactions to be
aggregated,
affording the possibility of fractional cent payments for pay-per-view web
browsing.
Aggregation is required because the credit card system for merchants is
inefficient for
transactions less than $10. Likewise the infrastructure carrying cost of other
back-end
electronic funds transfer mechanisms would cost more, on a per transaction
basis,
than the value of the discrete transaction itself. Current micropayment
initiatives
work by aggregating many small transactions and submitting a final
consolidated bill
for later settlement through a phone, credit or ISP bill, primarily becoming a
billing
~ 5 service rather than a form of electronic money.
These various types of financial implements and other electronic money
systems offer some uses but are fundamentally limited by their physical
instantiation.
They are impractical because of the way in which they are instantiated only as
a
physical card, check, passbook or electronic equivalent.
2o Thus there is a need in the art for an asset transaction and management
system
using secure virtual accounts which allow for security and privacy as well as
portability. Furthermore, a need exists for providing a means to securely and
privately electronically transfer cash and non-cash assets. This new invention
herein
detailed is mutually advantageous to individuals, corporations, and
institutions: it
25 actually increases an organizations' benefits from automation, including
improved
security, while it frees individuals from the surveillance potential of data
linking and
other dangers of unchecked record keeping. Its more advanced techniques offer
not
only wider use at reduced cost, but also greater consumer convenience and
protection.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The invention comprises several general aspects. Each of those can if desired
be combined with additional features, the resultant combinations representing
more
detailed optional embodiments of these aspects.
4.1 Apparatus Claims:
4.1.1 First Aspect:
4.1.1.1 [Claim 1
According to a first aspect of this invention an advanced asset management
system has been provided, which comprises a computer system having at least
one
data processor, at least one data storage device, and at least one
communications
device through which the computer system can communicate with one or more
entities that can connect directly or indirectly with said computer system.
Stored in
said computer system on said at least one data storage device is account
management
software for storing and managing one or more accounts, accessible at least in
part via
15 said at least one communications device. At least a portion of said one or
more
accounts respectively comprise at least one token(s), and optionally one or
more
additional tokens) stored in the computer system. These tokens) are symbols
through said one or more accounts is/are recognizable by the system. The first
mentioned tokens) affords at least one account of said one or more accounts to
be
2o recognizable by the system in communications between the system and said
entities.
Optionally, there may be one or more additional tokens) through which the
system
can recognize one or more direct and/or indirect sub-accounts) of said one or
more
accounts. The system further comprises data and/or code through which the
system
recognizes said one or more accounts, or said one or more sub-accounts thereof
upon
25 receipt, via said at least one communication device, of said at least one
token or said
one or more additional tokens. Thus, the accounts) stored in the computer
system
comprise one or more account(s), one or more direct or indirect sub-
accounts(s)
thereof, and tokens) thereof. One or more entities other than account
administrators,
including persons, organizations and/or other computer systems, owning or
having
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
control of said accounts) or at least a portion of the content thereof, and,
optionally,
one or more third party entities, can manipulate said account(s).
The various additional features included in the various aspects and
embodiments described below, even if described as embodiments of a particular
type
of system or account, represent options that may be applied singly or in any
operable
group to any type, combination, and/or enhanced version of asset management
systems or accounts, such as, but not limited to, virtual asset management
systems and
virtual accounts, credit card management systems and credit caxd accounts,
debit card
management systems and debit card accounts, smart card management systems and
smart card accounts, checking account management systems and checking
accounts,
and others.
4.1.1.2 [Claim 2]
In on.e embodiment of the foregoing general method, the advanced asset
management system comprises a plurality of computer systems.
15 4.1.1.3 [Claims 3-6]
In another embodiment the advanced asset management system comprises
data and/or code for performing at least one of the steps of activating,
authenticating,
creating, deactivating, destroying, evaluating, generating, implementing,
maintaining,
modifying, processing, registering, and/or otherwise manipulating an
account(s). In
2o yet another embodiment, said at least one data processor of the advanced
asset
management system may if desired be configured to accept one or more commands
to
perform these functions only if said commands) is/are received in conjunction
with a
PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
owning or having a right to control said account(s). In still another
embodiment the
25 advanced asset management system comprises data and/or code for permitting
access
to an account(s). In yet another embodiment said at least one communications
device
of the advanced asset management system may if desired be configured to permit
access to an accounts) based on receipt via said at least one communications
device
of a PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
3o having authorization to access an account(s).
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.1.4 [Claim 7]
In another embodiment the advanced asset management system comprises
data and/or code for managing one or more predetermined types of transactions
in or
with said account(s).
4.1.1.5 [Claims 8-9]
In another embodiment said at least one storage device of the advanced asset
management system contains an historical records) pertaining to one or more
completed transactions) of said account(s). In yet another embodiment the
advanced
asset management system has storage devices) which contains) historical
records)
pertaining to one or more completed and/or to one or more failed transactions
of said
account(s).
4.1.1.6 [Claim 10-20]
In other embodiments, the accounts) of the advanced asset management
system may comprise a savings account(s), a checking account(s), a money-
market
~ 5 account(s), an unsecured line of credit account(s), a secured line of
credit account(s),
a securities account(s), a virtual account(s), a financial institution
account(s), a non-
financial institution account(s), a currency-based account(s), and/or a non-
currency-
based account(s).
4.1.1.7 [Claim 21]
2o In another embodiment said virtual accounts) at least one private token,
stored in said computer system, that is/are a confidential symbols) through
which
said virtual accounts) is/are recognizable by the system, at least one public
token,
stored in said computer system, that is/are a symbols) through which at least
one
primary public sub-account of said virtual accounts) is/are recognizable by
the
25 system in communications between the system and an entity/entities, and
optionally,
one or more additional public tokens, stored in the computer system, through
which
one or more additional direct and/or indirect public sub-accounts of said
virtual
accounts) is/are recognizable by the system in communications between the
system
and an entity/entities. The system further comprises data and/or code though
which
so the system to recognizes said virtual accounts) or said one or more public
sub-
to
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
accounts thereof upon receipt, via said at least one communications device, of
said at
least one public token or said one or more additional public tokens without
receipt of
said at least one private token, and prevents said entities from obtaining
said at least
one private token via said at least one communications device.
s 4.1.1.8 [Claims 22]
In another embodiment said virtual accounts) comprises a private token(s),
through which the virtual accounts) is/are recognizable by the system, at
least one
primary public sub-account, recognizable by the system through a first public
token(s), and one or more public sub-accounts, subordinate to said primary
1 o account(s), each recognizable by the system through its own public
token(s).
4.1.1.9 [Claims 23-28]
In other embodiments ownership or control of said accounts) is: anonymous,
in that no information, or insufficient information, for signifying such
ownership or
control, is stored by the system; identified, in that sufficient information
for
~ 5 identifying such ownership or control is stored by the system; and/or
identified, but
with its true identity masked, in that the information stored in the system
disguises
such ownership or control. In various forms of these embodiments the advanced
asset
management system fiuther comprises data and/or code for managing,
respectively,
said anonymous, identified, and/or masked account(s).
20 4.1.1.10 jClaims 29-30]
In another embodiment the advanced asset management system comprises a
plurality of accounts) in which ownership or control of a given accounts)
differs
from at least one other accounts) as to whether said accounts) are anonymous,
identified, and/or masked. In one form of this embodiment the advanced asset
2s management system comprises a plurality of accounts) in which the system
comprises data andlor code for managing accounts wherein the ownership or
control
of a given accounts) differs) from at least one other account as to whether
said
accounts) are anonymous, identified, and/or masked.
11
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.1.11 [Claims 31-50]
In other embodiments the advanced asset management system may comprise
data and/or code that causes) the system to recognize one or more logical
connections between accounts. These connections can be between accounts,
between
sub-accounts, from an accounts) to a sub-account(s), and/or from a sub-
accounts) to
an account(s). In various optional forms of these embodiments, the first
mentioned
accounts) in each of the foregoing types of combinations of accounts may be
anonymous, identified, or identified, but with their true identity masked, to
the
accounts) connected to them. In other specific forms of these embodiments,
there
may be a plurality of said logical connections and at least one of these
respective
logical connections differs from at least one other of these logical
connections as to
whether the first mentioned accounts) involved therein is/are anonymous,
identified,
and/or masked.
4.1.1.12 [Claims 51-62]
~ 5 In other embodiments the advanced asset management system may comprise
data andlor code that will, notwithstanding receipt via said communications
devices)
of a tokens) for a particular account(s), withhold disclosure of all
information, or
disclosure at least a portion of the information, concerning the account(s),
In certain
forms of these preferred embodiments, the information may pertain to the
ownership
20 or control of said account(s), the content of said account(s), the logical
connections)
in which said accounts) are involved, any transactions in which said accounts)
is/are
involved, and/or any transaction history/histories in which said accounts)
have been
involved.
4.1.1.13 [Claims 63-73]
25 In yet other embodiments, the system comprises data andlor code that will
establish andlor dissolve one or more continuing, or temporary expiring,
logical
connections between accounts in which an account(s), serving as a parent
accounts)
to one or more accounts subordinate thereto, may be anonymous, identified,
and/or
masked with respect to said subordinate account(s). In certain forms of these
3o embodiments, the parent accounts) differs) in its/their relationships to at
least two
subordinate accounts as to whether the parent accounts) is/are anonymous,
identified,
12
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
and/or masked with respect to said subordinate accounts. In certain other
embodiments, the system comprises data and/or code that will establish and/or
dissolve one or more continuing, or temporary expiring, logical connections
between
accounts in which an account(s), subordinate to one or more accounts serving
as
parent accounts thereto, may be anonymous, identified, and/or masked with
respect to
said parent account(s). In certain specific forms of these embodiments, the
subordinate accounts) differs) in its/their relationships to at least two
parent
accounts as to whether the subordinate accounts) is/are anonymous, identified,
and/or
masked with respect to said parent accounts.
4.1.114 [Claims 79-86]
In still another embodiment the advanced asset management system may
comprise data and/or code for performing at least one of the steps of
activating,
authenticating, creating, deactivating, destroying, evaluating, generating,
implementing, maintaining, modifying, processing, registering, andlor
otherwise
~ 5 manipulating one or more domains. In one form of this embodiment, said at
least one
data processor of the advanced asset management system may if desired be
configured to accept one or more commands to perform these desired functions
only
if said commands) is/are received in conjunction with a PIN(s), passwords) or
other
authenticating tokens) signifying an entity/entities owning or having a right
to
2o control said domain(s). In another form of this embodiment, each sub-
account of an
account is assigned to one or more domains, or to a particular domain, and
said code
and/or data is configured to execute a given command or combination of
commands
that is applicable to and manipulates, as a group, all sub-accounts in at
least one
selected domain or all sub-accounts of said account. In still another
particular form of
25 this embodiment, all sub-accounts of an account represented by private
tokens are
assigned to one or more private domains, or to a particular private domain,
said
private domains) being restricted to sub-accounts represented by private
tokens, and
wherein said code and/or data is configured to execute a given command or
combination of commands that is applicable to and manipulates, as a group, all
sub-
3o accounts represented by private tokens within said account. In yet another
particular
form of this embodiment, all sub-accounts of an account represented by public
tokens
are assigned to one or more public domains, or to a particular public domain,
said
13
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
public domains) being restricted to sub-accounts represented by public tokens,
and
wherein said code and/or data is configured to execute a given command or
combination of commands that is applicable to and manipulates, as a group, all
sub-
accounts represented by public tokens within said account.
4.1.1.15 [Claims 87-123]
In certain embodiments the advanced asset management system comprises
means for encrypting an account(s). In other embodiments, the advanced asset
management system comprises means for encrypting of all or at least a portion
of any
information about the accounts) that is: stored by the system, processed by
the
1 o system, and/or communicated to or from the system. In certain forms of the
preceding embodiments, the information may pertain to, at least in part, the
ownership
or control of said account(s), at least a portion of the content of said
account(s), the
logical connections) of said account(s), the transactions involving said
account(s),
and the transaction histories in which said accounts) has/have been involved.
4.1.1.16 [Claim 124]
In another embodiment the advanced asset management system may have a
computer system comprising data and/or code that manages actual or potential
connection(s), through one or more first communications devices in said
system,
directly or indirectly, with one or more second communications devices outside
said
2o computer system, that can transmit a tokens) to said computer system, or
receive a
token from said computer system, whereby said second communications devices)
can
participate in interactions with said account(s).
4.1.1.17 [Claims 125-126]
In one other embodiment the advanced asset management system may have a
computer system comprising data and/or code for performing at least one of the
steps
of activating, authenticating, creating, deactivating, destroying, evaluating,
generating, implementing, maintaining, modifying, processing, registering,
and/or
otherwise manipulating one or more account repositories, said
repository/repositories
containing one or more accounts. In one form of this embodiment, said at least
one
so data processor of the advanced asset management system may if desired be
14
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
configured to accept one or more commands to perform these functions only if
said
commands) is/are received in conjunction with a PIN(s), passwords) or other
authenticating tokens) signifying an entity/entities owning or having a right
to
control said repository/repositories.
4.1.1.18 [Claims 127-129]
In other embodiments the advanced asset management system may comprise
any number of account repositories respectively comprising one or more
accounts and
may have one or more actual or potential communications connections with one
or
more other repositories comprising one or more accounts, with one or more
additional
communications devices, or with both, said connection/connections thereby
affording
the opportunity for interactions within.or between said
repository/repositories, and/or
their respective account(s).
4.1.1.19 [Claims 130-140]
In one form of these embodiments, said repository/repositories may represent
~5 an open group and may not be subject to any restrictions) against an
interactions)
with either one or more other repositories or their respective account(s), or
with one
or more communications devices. In a particular set of these embodiments, said
repository/repositories represent a controlled group subject to one or more
restrictions
against an interactions) with one or more repositories and/or their respective
2o accounts) outside of said group, or against a specific types) of
interactions) with
one or more repositories and/or their respective account(s), or against an
interactions)
with other than approved communications device(s). In still other forms of the
foregoing particular set of respective embodiments, the restrictions) to the
controlled
group may be dynamically selected and applied, based on data received via said
25 communications device(s). In yet other forms of the foregoing particular
set of
respective embodiments, the last mentioned restrictions) may be enforced or
abrogated based on the character of, and in response to receipt of, a PIN(s),
passwords) or other authenticating token(s).
is
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.1.20 [Claims 141-153]
In one form of these embodiments there is a plurality of said repositories
representing a distributed groups) having controlling software and/or hardware
programmed with information identifying, and comprising a communications
routes)
to, the other repositories in said group(s). In another form of these
embodiments there
is a plurality of said repositories representing a federated groups) having
controlling
software and/or hardware programmed with information identifying each of the
other
repositories in the group(s), and with code that represents a condition of
trust with
respect to transactions within and between repositories in said group(s). In
yet
another form of these embodiments, there is a plurality of said repositories
representing a distributed-federated groups) having controlling software
and/or
hardware programmed with information identifying each of the other
repositories in
the group(s), communications routes) to the other repositories in the
group(s), and
code that represents a condition of trust with respect to transactions within
and
between repositories in said group(s). In other forms of these embodiments,
there is a
plurality of said repositories that exist in an inter-networked groups) in
which a given
repository/repositories in the groups) is/are not required to be known in
advance by
another repository/repositories in the group(s), but can be discovered; and/or
a
communications connections) between repositories in the groups) is/are not
required
2o to be known in advance, but can be discovered; and/or a routes) between
repositories
in the groups) is/are not required to be known in advance, but can be
determined;
and/or a routes) between repositories in said inter-networked groups) can
change,
with no requirement that all communications connections between repositories
in the
groups) traverse the same routes) across the inter-network; and/or the
communications connections between repositories in the groups) may be
intermittent
or permanent; and/or and communications connections) between repositories in
the
groups) can be dynamically established, dissolved, moved, managed, redirected,
and/or otherwise manipulated. Among the embodiments of the invention are
advanced asset management systems wherein there is a plurality of said
repositories
3o that exist in an inter-networked groups) and in which all of the following
conditions
exist: the other repositories are not required to be known in advance, but can
be
discovered; communications connections between the repositories are not
required to
be known in advance, but can be discovered; routes between repositories in
said
16
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
groups) are not required to be known in advance, but can be determined; routes
between repositories in said groups) can change, with no requirement that
subsequent
communications connections between said repository and said other
repositories,
established after a first communications connection between said repository
and said
other repositories, must traverse the same path as said first communications
connection; communications connections between said repository and said other
repositories can be dynamically established, dissolved, moved, managed, and
redirected; and connections between repositories are either intermittent or
permanent.
The invention also includes embodiments of advanced asset management systems
wherein there is a plurality of said repositories that exist in an inter-
networked
groups) and in which at least one of the foregoing conditions exists.
4.1.1.21 [Claims 154-164]
In one other form of these embodiments, a first repository, containing at
least
one account, that is programmed to communicate and conduct transactions as an
independent repository or as a member of a given group of repositories, may
also be
programmed to communicate with, and to conduct transactions with, at least one
other
repository not comprised in said given group. In other forms of these
embodiments,
said first repository is not comprised in any group of repositories, is a
member of a
distributed group, is a member of a federated group, is a member of a
distributed-
2o federated group, or is a member of an inter-networked group. In still other
forms of
these embodiments, said at least one other repository is not comprised in any
group of
repositories, is a member of a second group of distributed repositories, is a
member of
a second group of federated repositories, is a member of a second group of
distributed-federated repositories group, or is a member of a second group of
inter-
networked repositories.
4.1.1.22 [Claims 165-171]
In one form of these embodiments the advanced asset management system
further comprises means for encrypting the repository/repositories and
its/their
comprised account(s). In other embodiments, the advanced asset management
system
so comprises means for encrypting all or at least a portion of any information
regarding
1~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
said repository/repositories and its/their comprised account(s): stored by,
processed
by, and/or communicated to or from, said advanced asset management system.
4.1.2 Second Aspect:
4.1.2.1 [Claim 172]
According to a second aspect of this invention a virtual clearinghouse system
is provided. The clearinghouse system can act as a third party intermediary
for
facilitating transactions in which the transaction participants respectively
comprise a
first participant which is at least one virtual account or a sub-accounts)
thereof, and a
second participant which is at least one participant other than said at least
one virtual
account or sub-accounts) thereof. The clearinghouse system comprises a
computer
system having at least one data processor, at least one data storage device,
and at least
one communications device through which the computer system can communicate
with one or more entities that can connect directly or indirectly with said
computer
system. Stored in said computer system on said at least one data storage
device is
~ 5 clearinghouse software for storing and managing a plurality of account
repository
connection requests, accessible to be implemented at least in part via said at
least one
communications device. The account repository connection requests respectively
comprise data representing at least one account transaction, comprising such
information as is required to characterize the transaction, at least one
address for a
2o given repository/repositories in which the participating accounts) is/are
situated, and
at least one public tokens) of a participating account(s). The system further
comprises data and/or code that represents the existence of a direct or
indirect trusting
relationship between the clearinghouse system and said
repository/repositories, and
between the clearinghouse and the second participant. The data and/or code is
also
25 configured to establish, accept, coordinate, and/or otherwise manipulate
direct or
indirect trusted connections via said at least one communications device
between the
repository/repositories and at least one of said entity/entities, with which
the second
participant may be directly or indirectly associated or which may be the
second
participant, and transmits the transaction information, whereby the
participants can
3o conduct transactions with each other without requiring a direct trusting
relationship
between the participants.
18
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.2.2 [Claims 173-184]
According to one embodiment of the invention, the virtual clearinghouse
system comprises a plurality of computer systems. In another embodiment the
virtual
clearinghouse system comprises data and/or code for performing at least one of
the
steps of activating, authenticating, creating, deactivating, destroying,
evaluating,
generating, implementing, maintaining, modifying, processing, registering,
and/or
otherwise manipulating one or more virtual clearinghouses, components thereof,
and/or communication requests thereof. In yet another embodiment, said at
least one
data processor of the virtual clearinghouse system may if desired be
configured to
1 o accept one or more commands to perform these functions only if said
commands)
is/are received in conjunction with a PIN(s), passwords) or other
authenticating
tokens) signifying an entity/entities owning or having a right to control,
respectively,
said one or more virtual clearinghouses, said components thereof, and/or said
communication requests thereof. In still another embodiment the virtual
clearinghouse system comprises data and/or code for permitting access to one
or more
virtual clearinghouses, components thereof, and/or communication requests
thereof.
In yet another embodiment said at least one communications device of the
virtual
clearinghouse system may if desired be configured to permit access to one or
more
virtual clearinghouses, components thereof, and/or communication requests
thereof,
2o based on receipt via said at least one communications device of a PIN(s),
passwords)
or other authenticating tokens) signifying an entity/entities having
authorization to
access, respectively, said one or more virtual clearinghouses, said components
thereof, and/or said communication requests thereof. In another embodiment the
virtual clearinghouse system may comprise data and/or code that causes) said
25 clearinghouse system to act as a third party intermediary for facilitating
one or more
. , . ~ ~~ ~ ~ L,
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
only if said commands) is/are received in conjunction with a PIN(s),
passwords) or
other authenticating tokens) signifying an entity/entities owning or having a
right to
control said bid pools) and/or said gaming/gambling pool(s).
4.1.2.3 [Claims 185-204]
s In one other embodiment, the virtual clearinghouse system may comprise data
and/or code that causes) said clearinghouse system to act as an agent for one
or more
repositories. In other embodiments, the virtual clearinghouse system may
comprise
data and/or code for calculating, collecting, disbursing, reporting, and/or
otherwise
manipulating taxes and/or fees, or information pertaining to at least in part
taxes
and/or fees. In yet other embodiments, the virtual clearinghouse system may
comprise data and/or code for granting, revoking, reporting, validating,
transmitting
and/or otherwise manipulating credentials and/or licenses, or information
pertaining
to at least in part credentials and/or licenses. In yet other embodiments, the
virtual
clearinghouse system may comprise data and/or code for granting, revoking,
~ 5 authenticating, validating, transmitting and/or otherwise manipulating one
or more
digital security certificates, or information pertaining to at least in part
digital security
certificates. In still other embodiments, the virtual clearinghouse system may
comprise data and/or code for granting, revoking, authenticating, validating,
transmitting and/or otherwise manipulating one or more digital signatures, or
2o information pertaining to at least in part digital signatures. According to
a series of
preferred embodiments, said at least one data processor is configured to
accept one or
more commands to perform any one of the functions previously described in this
paragraph only if said commands) is/are received in conjunction with a PIN(s),
passwords) or other authenticating tokens) signifying an entity/entities
owning or
25 having a right to control the function and/or the object thereof. In
another
embodiment the virtual clearinghouse system second participant may be at least
one
other account in the same repository/repositories in which the first
participant is
situated. In still another embodiment the virtual clearinghouse system second
participant is at least one other account in a repository other than said
given
3o repository/repositories. In still another embodiment, the virtual
clearinghouse system
second participant is not a virtual account or sub-account thereof.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.2.4 [Claims 205-241]
In certain embodiments the virtual clearinghouse system comprises means for
encrypting the clearinghouse(s). In other embodiments, the virtual
clearinghouse
system comprises means for encrypting all or at least a portion of any
information
about accounts) and participants) that is: stored by, processed by, and/or
communicated to or from, the system(s). In certain forms of the preceding
embodiments, the encrypted information may pertain at least in part to the
ownership
or control of said account(s), at least a portion of the content of said
account(s), a
logical connections) of an account(s), a transactions) involving an
account(s), and a
transaction history/histories in which an accounts) has/have been involved.
4.1.3 Third Aspect:
4.1.3.1 [Claim 242]
According to a third aspect of this invention a virtual naming system has been
provided, which comprises a computer system having at least one data
processor, at
least one data storage device, and at least one communications device through
which
the computer system can communicate with one or more entities that can connect
with
said computer system. Stored in said computer system on said at least one data
storage device is naming system software for creating, storing, maintaining,
and/or
otherwise manipulating data comprising at least one name and at least one
address for
2o each of a plurality of repositories, said data being at least in part
accessible via said at
least one communications device. Said naming system further comprises data
andlor
code that creates, stores, maintains, and/or otherwise manipulates a lists) of
known
repositories and repository addresses. Said naming system allows one or more
entities other than naming system administrators, including persons,
organizations,
and/or other computer systems, owning or having control of an accounts) in one
or
more repositories or at least a portion of the content of an accounts) in one
or more
repositories, and, optionally, one or more third party entities, to locate and
discover a
communication routes) to such repository/repositories without knowing the name
or
without knowing the address thereof.
21
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.3.2 [Claims 243-261]
Included among the embodiments of the invention are those in which the
virtual naming system comprises a plurality of computer systems. In other
embodiments the virtual naming system comprises data and/or code for
performing at
least one of the steps of activating, authenticating, creating, deactivating,
destroying,
evaluating, generating, implementing, maintaining, modifying, processing,
registering, and/or otherwise manipulating one or more naming systems and/or
lists)
thereof. Said lists) may comprise: known repositories, repository addresses,
aliases
for said repositories, repository ownership certificates, known
clearinghouses,
clearinghouse addresses, aliases for said clearinghouses, clearinghouse
ownership
certificates, known labeling systems, labeling system addresses, aliases for
said
labeling systems, labeling system ownership certificates, other known naming
systems, other naming system addresses, aliases for said other naming systems,
naming system ownership certificates, known devices, device addresses, aliases
for
~ 5 said devices, and/or device ownership certificates. In a further
embodiment, said at
least one data processor of the virtual naming system may if desired be
configured to
accept one or more commands to perform these functions only if said commands)
is/are received in conjunction with a PIN(s), passwords) or other
authenticating
tokens) signifying an entity/entities owning or having a right to control,
respectively,
2o said one or more virtual naming systems and/or said lists) thereof. In
still another
embodiment the virtual naming system comprises data and/or code for permitting
access to one or more virtual naming systems and/or lists) thereof. In yet
another
embodiment said at least one communications device of the virtual naming
system
may if desired be configured to permit access to one or more virtual naming
systems
25 and/or lists) thereof based on receipt via said at least one communications
device of a
PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
having authorization to access, respectively, said one or more virtual naming
systems
and/or said lists) thereof.
4.1.3.3 [Claims 262-268]
3o In certain embodiments the virtual naming system comprises means for
encrypting the naming system(s). In other embodiments, the virtual naming
system
comprises means for encrypting all or at least a portion of any information
regarding
22
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
said naming systems) and its/their comprised list(s): stored by, processed by,
and/or
communicated to or from, said naming system(s).
4.1.4 First Aspect, continued:
4.1.4.1 [Claims 269-270]
In an embodiment pertaining to the advanced asset management system, the
advanced asset management system comprises data and/or code for performing at
least one of the steps of activating, authenticating, creating, deactivating,
destroying,
evaluating, generating, implementing, maintaining, modifying, processing,
registering, and/or otherwise manipulating at least a portion of the content
of an
account(s). In yet another of these embodiments, said at least one data
processor of
the advanced asset management system may if desired be configured to accept
one or
more commands to perform these functions only if said commands) is/are
received in
conjunction with a PIN(s), passwords) or other authenticating tokens)
signifying an
entity/entities owning or having a right to control said account(s).
4.1.4.2 [Claims 271-272]
In one form of the preceding embodiments the advanced asset management
system comprises means for encrypting a first and second part of the at least
a portion
of the content of an accounts) independently from one another. In other forms
of the
foregoing embodiments the advanced asset management system comprises means for
2o encrypting the at least a portion of the content of an account(s), and
storing,
processing, and/or communicating said encrypted portion without requiring that
said
encrypted portion be decrypted
4.1.4.3 [Claims 273-286]
In another form of the foregoing embodiments the at least a portion of the
content within the advanced asset management system is an asset(s), and in
certain
forms of this embodiment the content may be a digital asset(s), qualitative
information about a digital asset(s), information other than qualitative
information
about a digital asset(s), a representation of a digital asset(s), qualitative
information
about a representation of a digital asset(s), information other than
qualitative
3o information about a representation of a digital asset(s), a representation
of a non-
23
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
digital asset(s), qualitative information about a representation of a non-
digital asset(s),
or information other than qualitative information about a representation of a
non-
digital asset(s). In other embodiments, wherein the assets) of an accounts)
stored in
said data storage device(s), the system may be adapted to effect transfer of
ownership
or control of at least a portion of the assets) reflected in the accounts)
from one or
more entities to one or more other entities, whereby the transfer does not
require
either physical manifestation or physical transfer of the assets)
itself/themselves. In
another form of these embodiments, the advanced asset management system may
comprise data and/or code that comprises) conversion routines) which interact
with
1o a records) of a given types) of assets) stored in one or more accounts by
said system
and with information about any qualitative and/or quantitative relationships)
between
an assets) of said given types) and of other types) of assets) and that is
able, on
command, after receipt of a tokens) for said account(s), to convert the
records) of
said given types) of asset(s), at least in part, to at least one records) of
at least one of
~5 said other types) of asset(s). In other forms of these embodiments the
advanced asset
management system may comprise data and/or code that, on command, after
receipt
of a tokens) for said account(s), causes) at least a portion of the assets)
held within
an accounts) to be reserved for future use, thus diminishing the current
available
balance by the-amount placed on reserve, without debiting the account(s). In
still
20 other embodiments the accounts) reflect information concerning the value of
a given
asset(s), expressed as a particular quantity of said assets) in particular
units, which
units may optionally be monetary units, and the system comprises data and/or
code
that, on command, expresses a quantity of units present in the accounts) when
the
particular quantity is converted to a resulting number of different units,
said number
25 of different units being of equivalent value to said particular quantity of
said
particular units.
4.1.4.4 [Claims 287-301]
In one other form of these embodiments, the advanced asset management
system may comprise one or more provisions for storing and manipulating data
with
3o respect to a plurality of different types of assets. These different types
of assets may
in some cases differ from one another in their primary function or quality. In
a
preferred embodiment, an accounts) may store assets of a first type, and of at
least
24
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
one other type, different from said first type. In derivatives of the
foregoing preferred
embodiment, said first asset type may be a given form of currency, the
currency of a
given national and/or mufti-national jurisdiction, a tangible or intangible
non-
monetary thing of measurable quantity and of measurable value, a tangible or
intangible non-monetary thing of measurable quantity but of no intrinsic
value, a
tangible or intangible non-monetary thing of no measurable quantity but of
measurable value, or a tangible or intangible non-monetary thing of no
measurable
quantity and of no intrinsic value. Tn other derivatives of the foregoing
preferred
embodiment, said first type and said at least one other type of assets may
differ in that
they are different currencies, different currencies of different national
and/or multi-
national jurisdictions, different tangible or intangible non-monetary things
of
measurable quantity and of measurable value, different tangible or intangible
non-
monetary things of measurable quantity but of no intrinsic value, different
tangible or
intangible non-monetary things of no measurable quantity but of measurable
value, or
different tangible or intangible non-monetary things of no measurable quantity
and of
no intrinsic value.
4.1.4.5 [Claims 302-314]
In one other embodiment the advanced asset management system may
comprise provisions for incrementing, validating, expiring, decrementing,
and/or
otherwise manipulating a tangible or intangible non-monetary asset of
measurable
quantity. In another embodiment the advanced asset management system may
comprise means for entering into and/or removing from an accounts) tangible or
intangible non-monetary assets) of no measurable quantity. In still another
embodiment the advanced asset management system may comprise means for
recording in an account(s), or prohibiting an accounts) from containing, an
assets) in
a particular form of currency, an assets) in the currency of a particular
national
and/or mufti-national jurisdiction, a particular tangible or intangible non-
monetary
assets) of measurable value, a particular tangible or intangible non-monetary
assets)
of measurable quantity but no measurable value, and/or a particular tangible
or
3o intangible non-monetary assets) of no measurable quantity.
2s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.4.6 [Claims 315-318]
In another embodiment regarding the first aspect, the advanced asset
management system further comprises data and/or code for performing at least
one of
the steps of activating, authenticating, creating, deactivating, destroying,
evaluating,
generating, implementing, maintaining, modifying, processing, registering,
and/or
otherwise manipulating one or more attributes. In another embodiment, said at
least
one data processor of the advanced asset management system may if desired be
configured to accept one or more commands to perform these functions only if
said
commands) is/are received in conjunction with a PIN(s), passwords) or other
authenticating tokens) signifying an entity/entities owning or having a right
to
control said one or more attributes. In still another embodiment the advanced
asset
management system comprises data and/or code for permitting access to one or
more
attributes. In yet another embodiment said at least one communications device
of the
advanced asset management system may if desired be configured to permit access
to
~5 one or more at~Tibutes based on receipt via said at least one
communications device of
a PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
having authorization to access said one or more attributes.
4.1.4.7 [Claims 319-325]
In one form of the foregoing embodiments, the attributes are user-defined, in
2o that the system affords sole control over the constitution of one or more
said user-
defined attributes of, on, and/or within said account(s), and/or at least a
portion of the
content thereof, to an entity/entities owning or having a right to control
said
account(s). In another form,. the attributes are user-selectable, in that the
system
generates a lists) of attributes of, on, and/or within said account(s), and/or
at least a
25 portion of the content thereof, from which an entity/entities owning or
having a right
to control said accounts) may select and apply one or more of said user-
selectable
attributes. In yet another form the attributes are user-determinable, in that
the values)
for an attributes) of, on, and/or within said account(s), and/or at least a
portion of the
content thereof, is not preset, but is determined, within limits, by an
entity/entities
30 owning or having a right to control said account(s). In additional forms,
the attributes
may be: of, for, and/or within at least one repository or group of
repositories; of, for,
and/or within at least one account or group of accounts; of, for, and/or
within at least a
26
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
portion of the content contained within at least one repository or group of
repositories;
and/or of, for, and/or within at least a portion of the content contained
within at least
one account or group of accounts.
4.1.4.8 [Claims 326-329]
In another embodiment regarding the first aspect, the advanced asset
management system further comprises data and/or code for performing at least
one of
the steps of activating, authenticating, creating, deactivating, destroying,
evaluating,
generating, implementing, maintaining, modifying, processing, registering,
and/or
otherwise manipulating one or more constraints. In another embodiment, said at
least
one data processor of the advanced asset management system may if desired be
configured to accept one or more commands to perform these functions only if
said
commands) is/are received in conjunction with a PIN(s), passwords) or other
authenticating tokens) signifying an entity/entities owning or having a right
to
control said one or more constraints. In still another embodiment the advanced
asset
~ 5 management system comprises data and/or code for permitting access to one
or more
constraints. In yet another embodiment said at least one communications device
of
the advanced asset management system may if desired be configured to permit
access
to one or more constraints based on receipt via said at least one
communications
device of a PIN(s), passwords) or other authenticating tokens) signifying an
2o entity/entities having authorization to access said one or more
constraints.
4.1.4.9 [Claims 330-343]
In one form of the foregoing embodiments, the constraints are user-defined, in
that the system affords sole control over the constitution of one or more said
user-
defined constraints on said account(s), and/or at least a portion of the
content thereof,
25 to an entity/entities owning or having a right to control said account(s).
In another
embodiment, the constraints are user-selectable, in that the system generates
a lists)
of constraints on said account(s), and/or at least a portion of the content
thereof, from
which an entity/entities owning or having a right to control said accounts)
may select
and apply one or more of said user-selectable constraints. In yet another
embodiment
3o the constraints are user-determinable, in that the values) for a
constraints) on said
account(s), and/or at least a portion of the content thereof, is not preset,
but is
2~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
determined, within limits, by an entity/entities owning or having a right to
control said
account(s). In additional forms, the constraints may be: on at least one
repository or
group of repositories; on at least one account or group of accounts; on at
least a
portion of the content contained within at least one repository or group of
repositories;
on at least a portion of the content contained within at least one account or
group of
accounts; and/or on at least one attribute or group of attributes.
4.1.4.10 [Claims 344-349]
In other embodiments the advanced asset management system additionally
comprises at least one repository, and data andlor code for combining, by
using any
one or more of the Boolean logic operators AND, OR, XOR (exclusive OR), and/or
NOT (inverse or complement), and/or by using any combination of the same or
different operators AND, OR, XOR, and/or NOT, and/or by using one or more
standard mathematical procedures for grouping and/or ordering of precedence,
two or
more constraints on all or at least a portion of any repository/repositories,
and/or
~ 5 content held within or controlled by a repository/repositories, and/or
accounts)
contained within or managed by a repository/repositories, and/or content held
within
or controlled by an account(s), and/or attributes of a
repository/repositories, and/or
attributes of content held within or controlled by a repository/repositories,
and/or
attributes of an account(s), .and/or attributes of content held within or
controlled by an
2o account(s). The above-mentioned standard mathematical procedures may
include use
of parenthesis, braces, and/or brackets, and/or of groups or levels of
parenthesis,
braces, and/or brackets.
4.1.4.11 [Claims 350-466]
In certain embodiments said one or more constraints exists/exist as an
integral
25 part(s), or external to, or as integral parts) of and also external to,
orie or more of the
following: a repository/repositories, an account(s), a repository/repositories
containing an account(s), content of a repositorylrepositories, a
repository/repositories
containing or controlling said content, content of an account(s), an accounts)
containing or controlling said content, an attribute(s), a
repository/repositories
3o containing an attribute(s), a repository/repositories containing an
accounts)
containing an attribute(s), an accounts) containing an attribute(s), content
of an
28
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
account(s). In other embodiments said data and/or code includes provisions for
processing and/or evaluating said constraints) internal to the system, for
cooperating
with means external to the system for external processing and/or evaluating of
said
constraint(s), or both of the preceding, with respect to one or more of the
following: a
repository/repositories, an account(s), a repository/repositories containing
an
account(s), content of a repository/repositories, a repository/repositories
containing or
controlling said content, content of an account(s), an accounts) containing or
controlling said content, an attribute(s), a repository/repositories
containing an
attribute(s), a repository/repositories containing an accounts) containing an
1o attribute(s), an accounts) containing an attribute(s), content of an
account(s).
4.1.4.12 [Claims 467-472]
In other embodiments the advanced asset management system may comprise
an inter-networked group of repositories, a distributed-federated group of
repositories,
a distributed group of repositories, a federated group of repositories, and/or
at least
one repository, and said system may comprise, or have access to through at
least one
communications device(s), data and/or code comprising one or more constraints)
on
an inter-networked group of repositories, a distributed-federated group of
repositories,
a distributed group of repositories, a federated group of repositories, or at
least one
repository, wherein said constraints) constitute a sets) of rules or controls
applicable
2o at least in part to one or more: repositories, accounts therein, portions
of the content of
said repositories, portions of the content of said accounts, attributes of
said
repositories, attributes of said accounts, andJor attributes of said portions
of the
content of said accounts or of said repositories. In other embodiments the
advanced
asset management system may comprise, or have access to through at least one
communications device(s), data and/or code comprising one or more constraints)
on
an at least one account wherein said constraints) constitute a set of rules or
controls
applicable at least in part to one or more: of said accounts, portions of the
content of
said accounts, attributes of said accounts, and/or attributes of said portions
of the
content of said accounts.
29
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.4.13 [Claims 473-486]
In other embodiments, said constraints) on a distributed-federated group of
repositories may be an extension or augmentation of rules or controls
applicable to a
larger inter-networked group of repositories with which said distributed-
federated
group of repositories interacts, wherein said constraints) axe not less
restrictive than
the constraints) applicable to the larger inter-networked group of
repositories. In still
other embodiments, said constraints) on a distributed group of repositories
may be an
extension or augmentation of rules or controls applicable to a larger inter-
networked
group and/or a larger distributed-federated group of repositories with which
said
distributed group of repositories interacts, wherein said constraints) are not
less
restrictive than the constraints) applicable respectively to the larger inter-
networked
group of repositories or the larger distributed-federated group of
repositories,
respectively. In still other embodiments, said constraints) on a federated
group of
repositories may be an extension or augmentation of rules or controls
applicable to a
~ 5 larger inter-networked group of repositories and/or a larger distributed-
federated
group of repositories with which said federated group of repositories
interacts,
wherein said constraints) are not less restrictive than the constraints)
applicable
respectively to the larger inter-networked group of repositories or the larger
distributed-federated group of repositories, respectively. In yet other
embodiments,
2o said constraints) on an at least one repository may be an extension or
augmentation
of rules or controls applicable to a larger inter-networked group of
repositories and/or
a larger distributed-federated group of repositories, and/or a larger
distributed group
of repositories, andlor a larger federated group of repositories with which
said
repository interacts, wherein said constraints) are not less restrictive than
the
25 constraints) applicable respectively to the larger inter-networked group of
repositories, the larger distributed-federated group of repositories, the
larger
distributed group of repositories, or the larger federated group of
repositories,
respectively. In still other embodiments, said constraints) on at least one
account)
may be an extension or augmentation of rules or controls applicable to an
inter-
3o networked group of repositories and/or a distributed-federated group of
repositories,
and/or a distributed group of repositories, and/or a federated group of
repositories,
and/or an individual repository with which said accounts) interact(s), wherein
said
constraints) are not less restrictive than the constraints) applicable
respectively to
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
the inter-networked group of repositories, the distributed-federated group of
repositories, the distributed group of repositories, the federated group of
repositories,
or the individual repository.
4.1.4.14 [Claims 487-556]
The invention includes further refinements of each of said embodiments
wherein said data and/or code includes provisions for storing and/or
processing all or
at least a portion of any information, regarding said one or more constraints
internal to
the system, and provisions for cooperating with means external to the system,
for
external storing and/or processing of all or at least a portion of any
information,
regarding a constraint(s), or both of the preceding, comprising means for
encrypting
all or at least a portion of any information so stored and/or processed. There
are still
further refinements of each of said embodiments wherein said data and/or code
includes provisions for communicating all or at least a portion of any
information
regarding said one or more constraints to or from the system, comprising means
for
encrypting all or at least a portion of any information so communicated.
4.1.4.15 [Claims 557-582]
In other embodiments the advanced asset management system may comprise
at least one repository and at least one communications channel, between said
at least
one communications device and said at least one repository, between at least
two
2o communications devices, and/or between at least two repositories, wherein
said at
least one communications channel is/are a public network(s), a private
network(s), a
private-over-public networks) or some combination of public, private, and/or
private-
over-public network(s). In each of the foregoing embodiments, one or more
clearinghouses may acts) as an intermediary/intermediaries between said
devices)
and said repositorylrepositories, between said devices, and/or between said
repository/repositories. In another embodiment, the advanced asset management
system may comprise data and/or code for performing at least one of the steps
of
activating, authenticating, creating, deactivating, destroying, evaluating,
generating,
implementing, maintaining, modifying, processing, registering, and/or
otherwise
so manipulating one or more constraints, restricting or granting access to a
particular
communications channels) and/or sub-components) thereof. In a particular form
of
31
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
this last embodiment said at least one data processor of the advanced asset
management system may, if desired be configured to accept one or more commands
to perform these steps only if said commands) is/are received in conjunction
with a
P1N(s), passwords) or other authenticating tokens) signifying an
entity/entities
s owning or having a right to control said constraint(s).
4.1.4.16 [Claims 583-588]
In one other embodiment the advanced asset management system may
comprise data and/or code for performing at least one of the steps of
activating,
authenticating, creating, deactivating, destroying, evaluating, generating,
implementing, maintaining, modifying, processing, registering, and/or
otherwise
manipulating one or more sub-account(s), wherein said sub-accounts) is/are the
primary accounts) within a particular domain(s). In a further embodiment, the
advanced asset management system may comprise one or more primary account(s),
and data andlor code for performing at least one of the steps of activating,
~ s authenticating, creating, deactivating, destroying, evaluating,
generating,
implementing, maintaining, modifying, processing, registering, and/or
otherwise
manipulating one or more sub-account(s), wherein said sub-accounts) is/are
related,
but subordinate to, said primary account(s). In yet another embodiment, the
advanced
asset management system may comprise one or more first sub-account(s), and
data
2o and/or code for performing at least one of the steps of activating,
authenticating,
creating, deactivating, destroying, evaluating, generating, implementing,
maintaining,
modifying, processing, registering, and/or otherwise manipulating one or more
other
sub-account(s), wherein said other sub-accounts) is/are related, but
subordinate to,
said first sub-account(s). In certain forms of each of the foregoing
embodiments the
25 advanced asset management system data processors) may, if desired, be
configured
to accept one or more commands to perform the foregoing steps only if said
commands) is/are received in conjunction with a PIN(s), passwords) or other
authenticating tokens) signifying an entity/entities owning or having a right
to
control said primary accounts) and/or said sub-account(s), respectively.
32
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.4.17 [Claims 589-591]
In a particular preferred embodiment, the tokens) for any accounts) may be
dynamically generated. In further embodiments said dynamic generation may be
performed on request, wherein said request is made by an authorized
entity/entities.
In yet another embodiment the advanced asset management system data
processors)
may, if desired, be configured to accept one or more commands to perform the
foregoing dynamic generation only if said commands) is/are received in
conjunction
with a PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities owning or having a right to control said account(s).
~0 4.1.4.18 [Claims 592-595]
In another preferred embodiment the advanced asset management 'system has
provisions for maintaining the accounts) in a hierarchy, said hierarchy having
one or
more levels wherein at least one account is the head of each level so
maintained. In
additional forms of this embodiment the hierarchies can have: zero, one or
more
15 additional accounts subordinate to said at least one account serving as the
head
account; and zero, one or more branches per level. In one form of this last
embodiment, each branch may spawn a hierarchy independent of any hierarchy
spawned by any other branch at its/their level or at any other level, and
wherein all
said spawned hierarchies are subordinate hierarchies to the hierarchy
containing said
2o branches.
4.1.4.19 [Claims 596-609]
In a particular embodiment the advanced asset management system may
comprise one or more provisions) for activating, authenticating, creating,
deactivating, destroying, evaluating, generating, implementing, maintaining,
25 modifying, processing, registering, and/or otherwise manipulating one or
more classes
of said one or more sub-accounts. In other forms of this particular embodiment
the
advanced asset management system may comprise one or more provisions) for the
preceding functions for a plurality of classes of said one or more sub-
accounts that
differ from one another in their primary function or quality. In other forms
of this
3o particular embodiment said one or more sub-accounts may comprise a first
sub-
account(s) and at least one other sub-accounts) of a class/classes different
than, or of
33
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
the same class/classes as, said first sub-account(s). Said one or more classes
of said
one or more sub-accounts may comprise: a child account(s), a peer account(s),
an
escrow account(s), a bid account(s), a gaming account(s), and a proxy
account(s). An
escrow accounts) may include an obligation account(s), a credit account(s),
and a
reserve account(s), representing sub-classes of escrow account(s). In certain
refinements of the particular embodiments, the proxy account may be
dynamically ,
generated.
4.1.4.20 [Claims 610-613]
In other embodiments the advanced asset management system may comprise
data and/or code for performing at least one of the steps of activating,
authenticating,
creating, deactivating, destroying, evaluating, generating, implementing,
maintaining,
modifying, processing, registering, and/or otherwise manipulating one or more
bid
pools, and/or one or more gaming/gambling pools. In certain forms of these
embodiments said at least one data processor of the advanced asset management
15 system may, if desired, be configured to accept one or more commands to
perform
these steps) only if said commands) is/are received in conjunction with a
PIN(s),
passwords) or other authenticating tokens) signifying an entity/entities
owning or
having a right to control, respectively, said bid pool(s), and/or said
gaming/gambling
pool(s).
20 4.1.4.21 [Claims 614-616]
In one embodiment the advanced asset management system may comprise
data and/or code for performing at least one of the steps of activating,
authenticating,
creating, deactivating, destroying, evaluating, generating, implementing,
maintaining,
modifying, processing, registering, and/or otherwise manipulating one or more
labels
25 for one or more accounts. In certain forms of this embodiment the advanced
asset
management system data processors) may, if desired, be configured to accept
one or
more commands to perform these steps) to create, implement, modify,
deactivate,
destroy, evaluate, and/or otherwise manipulate a labels) only if said
commands)
is/are received in conjunction with a PIN(s), passwords) or other
authenticating
3o tokens) signifying an entity/entities owning or having a right to control
said
34
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
account(s). In another preferred form of this embodiment, the labels) is/are
dynamically generated.
4.1.4.22 [Claims 617-622]
In other embodiments pertaining to the first aspect, the advanced asset
management system may comprise data andlor code for performing at least one of
the
steps of activating, authenticating, creating, deactivating, destroying,
evaluating,
generating, implementing, maintaining, modifying, processing, registering,
and/or
otherwise manipulating one or more domain constraint pools, wherein said
domain
constraint pools) contains) the set of all allowed attributes that may be
contained
1 o within or used by: one or more account(s), and/or at least a portion of
the content of
said account(s); and the set of all allowed constraints that may be used by or
on: one
or more account(s), at least a portion of the content of said account(s), one
or more
attributes of said account(s), and/or one or more attributes of said portion
of the
content of said account(s), and wherein said accounts) is/are located within
the
domains) governed by said one or more domain constraint pools. In certain
forms of
the foregoing embodiments the advanced asset management system said at least
one
data processor may, if desired, be configured to accept one or more commands
to
perform these steps) only if said commands) is/are received in conjunction
with a
PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
owning or having a right to control said one or more domain constraint pools.
In
other forms of the foregoing embodiments said domain constraint pools)
contains)
an allowed range of values and/or limits) for each constraints) and/or for
each
attributes) included therein. In other embodiments the advanced asset
management
system may comprise data and/or code which is responsive to the submission to
the
system of a PIN(s), passwords) or other authenticating token(s), including at
least the
public tokens) of a primary and/or subordinate accounts) in a virtual account
domain, for making available to a submitting entity one or more command
functions,
exercisable by the submitting entity, for activating, authenticating,
creating,
deactivating, destroying, evaluating, generating, implementing, maintaining,
3o modifying, processing, registering, and/or otherwise manipulating one or
more
attributes) of, in, or on a domain constraint pool or group of domain
constraint pools.
In still other embodiments the advanced asset management system may comprise
data
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
and/or code which is responsive to the submission to the system of a PIN(s),
passwords) or other authenticating token(s), including at least the public
tokens) of a
primary and/or subordinate accounts) in a virtual account domain, for making
available to a submitting entity command functions, exercisable by the
submitting
entity, for activating, authenticating, creating, deactivating, destroying,
evaluating,
generating, implementing, maintaining, modifying, processing, registering,
andlor
otherwise manipulating one or more constraints) on a domain constraint pool or
group of domain constraint pools.
4.1.4.23 [Claims 623]
In another embodiment the advanced asset management system may comprise
data and/or code which is responsive to the submission to the system of a
PIN(s),
passwords) or other authenticating token(s), including at least the public
tokens) of a
primary and/or subordinate accounts) in a virtual account domain, for making
available to a submitting entity one or more command functions, exercisable by
the
~ 5 submitting entity, for establishing one or more accounts.
4.1.4.24 [Claims 624-625]
In other embodiments the advanced asset management system may comprise
data and/or code which is responsive to the submission to the system of a
PIN(s),
passwords) or other authenticating token(s), including at least the public
tokens) of a
2o primary andlor subordinate accounts) in a virtual account domain, for
making
available to a submitting entity one or more command functions, exercisable by
the
submitting entity, for transferring the content of, or at least a portions) of
the content
of, one or more accounts, to one or more other account(s).
4.1.4.25 [Claims 626]
25 In yet other embodiment the advanced asset management system may
comprise data andlor code which is responsive to the submission to the system
of a
PIN(s), passwords) or other authenticating token(s), including at least the
public
tokens) of a primary and/or subordinate accounts) in a virtual account domain,
for
making available to a submitting entity command functions, exercisable by the
3o submitting entity, for closing one or more accounts.
36
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.4.26 [Claims 627]
In yet other embodiment the advanced asset management system may
comprise data and/or code which is responsive to the submission to the system
of a
PIN(s), passwords) or other authenticating token(s), including at least the
public
tokens) of a primary and/or subordinate accounts) in a virtual account
domain(s), for
making available to a submitting entity one or more command functions,
exercisable
by the submitting entity, fox changing the type of a subordinate account from
one type
to another.
4.1.4.27 [Claims 628-633]
In other embodiments the advanced asset management system may comprise
data and/or code responsive to the submission to the system of a PIN(s),
passwords)
or other authenticating token(s), including at least the public tokens) of a
primary
and/or subordinate accounts) in a virtual account domain(s), for making
available to
a submitting entity one or more command functions, exercisable by the
submitting
15 entity, for the transfer of one or more subordinate accounts from at least
one parent
account within its/their domains) to at least one other parent account within
its/their
domain(s), and/or the transfer of one or more accounts to a domains) other
than
its/their domain(s). In certain forms of the foregoing embodiments, said
transfer
includes the transfer of all content of said transferred account(s). In other
forms of the
2o foregoing embodiments said transfer includes the transfer of all accounts)
subordinate to said transferred account(s).
4.1.4.28 [Claims 634]
In one embodiment the advanced asset management system may comprise
data andlor code which is responsive to the submission to the system of a
PIN(s),
2s passwords) or other authenticating token(s), including at least the public
tokens) of a
primary and/or subordinate accounts) in a virtual account domain(s), for
making
available to a submitting entity a plurality of command functions.
4.1.4.29 [Claims 635-640]
In other embodiments the advanced asset management system may comprise
so data and/or code for performing at least one of the steps of activating,
authenticating,
37
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
creating, deactivating, destroying, evaluating, generating, implementing,
maintaining,
modifying, processing, registering, and/or otherwise manipulating: one or more
alerts;
one or more agents; and/or one or more triggers. In certain forms of the
foregoing
embodiments, the advanced asset management system data processors) may, if
desired, be configured to accept one or more commands to perform these steps
only if
said commands) is/are received in conjunction with a P1N(s), passwords) or
other
authenticating tokens) signifying an entitylentities owning or having a right
to
control, respectively, said alert(s), said agent(s), and/or said trigger(s).
4.1.5 Fourth Aspect:
4.1.5.1 [Claim 641 ]
According to a sixth aspect of this invention a virtual labeling system has
been
'provided, which comprises a computer system having at least one data
processor, at
least one data storage device, and at least one communications device through
which
the computer system can communicate with one or more entities that can connect
with
~ 5 said computer system. Stored in said computer system on said at least one
data
storage device is labeling system software for storing and managing data
comprising
at least one label for one or more accounts, said data being at least in part
accessible
via said at least one communications device. The labeling system further
comprises
data and/or code that creates, stores, maintains and/or otherwise manipulates
one or
2o more lists of account aliases which differ from existing public and private
tokens of
said accounts, and of known labels, including all aliases and all public and
private
token of said accounts, and ensures the uniqueness of at least all active
labels among
said known labels throughout all repositories with which it communicates. Said
labels respectively comprise data that is one or more symbols generated by the
system
z5 or by an entity/entities having ownership or control of said account(s).
One or more
entities other than labeling system administrators, including persons,
organizations
and/or other computer systems, owning or having control of an account(s), and,
optionally, one or more third party entities, can locate and communicate with
such
accounts without knowing the public tokens) for said accounts.
38
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.5.2 [Claims 642-646]
In one embodiment of the foregoing general method, the virtual labeling
system comprises a plurality of computer systems. In other embodiments the
virtual
labeling system comprises data and/or code for performing at least one of the
steps of
activating, authenticating, creating, deactivating, destroying, evaluating,
generating,
implementing, maintaining, modifying, processing, registering, and/or
otherwise
manipulating one or more virtual labeling systems, lists) thereof, and/or
labels)
thereof. In a further embodiment, said at least one data processor of the
virtual
labeling system may if desired be configured to accept one or more commands to
perform these functions only if said commands) is/are received in conjunction
with a
PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
owning or having a right to control, respectively, one or more virtual
labeling
systems, lists) thereof, and/or labels) thereof. In still another embodiment
the virtual
labeling system comprises data and/or code for permitting access to one or
more
~ 5 virtual labeling systems, lists) thereof, and/or labels) thereof. In yet
another
embodiment said at least one communications device of the virtual labeling
system
may if desired be configured to permit access to one or more virtual labeling
systems,
lists) thereof, and/or labels) thereof based on receipt via said at least one
communications device of a PIN(s), passwords) or other authenticating tokens)
2o signifying an entity/entities having authorization to access, respectively,
said one or
more virtual labeling systems, lists) thereof, and/or labels) thereof.
4.1.5.3 [Claims 647-650]
In another embodiment, the virtual labeling system may comprise data and/or
code for ensuring the uniqueness of all labels in said labeling system and all
other
25 labeling systems throughout all said repositories with which said systems)
communicate(s). In yet another embodiment, said symbols) is/are random in
nature.
In still another embodiment, said syrnbol(s) islare non-random in nature. In
still
another embodiment, the virtual labeling system may comprise data and/or code
for
selecting said syrnbol(s) in a random manner.
39
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.1.5.4 [Claims 651-656]
In other embodiments, the virtual labeling system may comprise data and/or
code for performing at least one of the steps of activating, authenticating,
creating,
deactivating, destroying, evaluating, generating, implementing, maintaining,
modifying, processing, registering, and/or otherwise manipulating: one or more
label
directories comprising a plurality of published account labels; one or more
digital
certificates or lists) thereof; andlor one or more digital signatures or
lists) thereof.
In certain forms of the foregoing embodiments the virtual labeling system data
processors) may, if desired, be configured to accept one or more commands to
perform these steps) only if said commands) is/are received in conjunction
with a
PIN(s), passwords) or other authenticating tokens) signifying an
entity/entities
owning or having a right to control said one or more virtual labeling systems
and/or
said lists) thereof.
4.1.5.5 [Claims 657-663]
According to other embodiments of the virtual labeling system, the labeling
systems) may be encrypted. Other respective embodiments include virtual
labeling
systems further comprising means for encrypting all or at least a portion of
any
information regarding said labeling systems) and its/their comprised list(s):
stored
by, processed by, and/or communicated to or from, said labeling system(s).
4.2 Method Claims:
4.2.1 Fifth Aspect:
4.2.1.1 [Claim 664]
Another aspect of the invention is a general method for managing and utilizing
virtual accounts. It comprises providing a computer system having at least one
data
processor, at least one data storage device and at least one communications
device
through which the computer system can communicate with one or more entities
that
can connect directly or indirectly with said computer system. This method
includes
maintaining in said computer system on at least said one data storage device,
data
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
and/or code with respect to at least one virtual account and, optionally, with
respect to
one or more direct and/or indirect sub-accounts thereof. Such data and/or code
comprises at least one private token that is a confidential symbols) through
which the
virtual accounts) is/are recognizable by the system, at least one public token
that is a
symbols) through which the virtual accounts) is/are recognizable by the system
in
communications via one or more of the communications devices) between the
system
and said entity/entities and, optionally, one or more additional public tokens
through
which said one or more direct or indirect sub-accounts are recognizable in
communications via said at least one communications device between the system
and
said entity/entities. According to this method, one or more of said accounts
are
manipulated, via said at least one communications device, using said at least
one
public token or said one or more additional public tokens, and without
furnishing said
at least one private token of the virtual accounts) and said entity/entities
is/are
prevented from obtaining the private tokens) via said at least one
communications
~ 5 device, and wherein the accounts) stored in said computer system comprise
one or
more virtual account(s), one or more direct or indirect public sub-accounts
thereof,
and tokens) thereof.
4.2.1.2 [Claims 665-676]
In certain embodiments of the foregoing general method, the manipulating of
2o the accounts) includes conducting transactions in which said accounts)
is/are
credited and/or debited with respect to amounts of assets transmitted via the
communications device(s). In a preferred embodiment of the general method,
data is
maintained in the system and said data is/are an asset(s). In detailed
versions of the
preferred embodiment, the assets) may be, respectively, a digital assets)
and/or
25 qualitative information about a digital assets) andJor information other
than
qualitative information about a digital assets) andlor a representations) of a
digital
assets) andlor qualitative information about a representations) of a digital
assets)
and/or information other than qualitative information about a representations)
of a
digital assets) and/or a representations) of a non-digital assets) andlor
qualitative
3o information about a representations) of a non-digital assets) and/or
information other
than qualitative information about a representations) of a non-digital
asset(s).
41
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.2.1.3 [Claims 677-700]
According to other embodiments of the foregoing method, all or at least of
portion of the software in the system, including all code, and/or all or at
least a portion
of the data in said system, is encrypted and maintained in encrypted form
throughout
is storage in the system, throughout processing of data in the system, and/or
throughout communication of data to and from the system.
4.2.2 Sixth Aspect:
4.2.2.1 [Claim 701
Another aspect of the invention includes a method for transferring assets. It
comprises providing a computer system having at least one data processor, at
least
one data storage device and at least one communications device through which
the
computer system can communicate with one or more entities that can connect
directly
or indirectly with said computer system. The computer system thus provided
further
includes virtual account data stored on said at least one data storage device.
This
~ 5 virtual account data comprises one or more virtual accounts, and for each
said virtual
account(s), respectively, at least one private token that is a confidential
symbol
through which the virtual account is recognizable by the system, at least one
public
token that is a syrnbol(s) through which the virtual account is recognizable
by the
system in communications between the system and said entity/entities and,
optionally,
20 one or more additional public token(s), through which one or more direct
and/or
indirect sub-accounts of said virtual account is/are recognizable by the
system. ~ The
provided system further comprises account management software stored on said
at
least one storage device. This software comprises data and/or code that makes
said
virtual accounts) and/or one or more sub-accounts thereof accessible, at least
in part,
2s via at least said at least one communications device and enables the system
to
recognize and manipulate a given accounts) upon receipt, via said at least one
communications device, of a public tokens) of the given accounts) without
receipt of
a private tokens) while also preventing said entitylentities from obtaining
the private
tokens) via said at least one communications device. The method includes the
step
30 of inputting into said computer, in respect to a given account or account
set, asset data
that is an assets) and/or one or more quantities of an assets) and/or one or
more
42
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
representations of a quantity/quantities of an assets) with respect to one or
more
types of tangible and/or intangible asset(s), wherein the assets)
quantity/quantities
inputted may be the same or different for different accounts where data is
inputted for
more than one account. In accordance with the method, said asset data is
logically
linked to one or more of said tokens that designates) the given account or
account set
for which said quantity is inputted. The method includes the further step,
using one or
more of said public tokens to designate the accounts) involved, of
transferring an
assets) and/or a quantity/quantities and/or a representation(s), comprising
all or a
portion of the assets) and/or quantity/quantities and/or representations) for
which
data has been inputted as to a given account or account set, from that account
or
account set to another account or account set in said computer system and/or
in
another computer systems) without requiring physical manifestation and
transfer of
the asset(s).
4.2.2.2 [Claims 702-703]
15 In certain embodiments of the transfer method, the assets) and/or
quantity/quantities and/or representations) may be transferred virtually
instantaneously upon inputting of said asset data or may be transferred after
retaining
the asset data in storage in the system at least momentarily after the
inputting of said
data.
20 4.2.2.3 [Claims 704-709]
Another embodiment of the transfer method comprises aggregation of assets,
including moving all or at least a portion of said assets) and/or
quantity/quantities
and/or representations) present in a given plurality of source accounts into a
lesser
number of one or more target accounts. Still another embodiment of the
transfer
2s method comprises distribution of assets, including moving all or at least a
portion of
said assets) and/or quantity/quantities and/or representations) present in one
or more
source accounts into a larger number of target accounts. Yet another
embodiment of
the transfer method comprises exchange of assets, including moving all or at
least a
portion of the assets) and/or quantity/quantities and/or representations)
present in a
3o first account or set of accounts into a second account or set of accounts
and,
simultaneously, or in a related later move, moving all or a portion of the
assets)
43
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
andlor quantity/quantities and/or representations) present in the second
account or set
of accounts into the first account or set of accounts. Performance of any of
the
foregoing aggregation, distribution or exchange embodiments, as the case may
be, can
include the step of converting all or a portion of the content of at least one
of the
accounts into a different form.
4.2.3 Seventh Aspect:
4.2.3.1 [Claim 710
Another aspect of the invention is a general method for operating a virtual
clearinghouse system for facilitating transactions in which the transaction
participants
1 o respectively comprise a first participant which is at least one virhial
account or a sub-
account(s) thereof, and a second participant which is at least one participant
other than
said at least one virtual account or sub-accounts) thereof. It comprises
providing a
clearinghouse computer system having at least one data processor, at least one
data
storage device, and, at least one communications device through which the
computer
system can communicate with one or more entities that can connect directly or
indirectly with said computer system. The method includes maintaining in said
clearinghouse computer system on said at least one data storage device
clearinghouse
software for storing and managing virtual account repository connection
requests to
be implemented at least in part via said at least one communications device,
and data
2o and/or code that represents the existence of direct or indirect trusting
relationships
between the clearinghouse system and one or more repositories and the
clearinghouse
system and the second participant. The method also includes receiving in said
computer system virtual account repository connection requests respectively
comprising data representing: at least one virtual account transaction,
comprising such
information as is required to characterize the transaction, at least one
address for a
given repository/repositories in which the participating accounts) is/are
situated and
at least one public token of a participating account(s). The method further
includes
establishing, accepting, coordinating, and/or otherwise manipulating direct or
indirect
trusted connections via the communications devices) between the
so repository/repositories and at least one of said entity/entities, with
which the second
participant may be directly or indirectly associated or which may be the
second
participant, and transmitting the transaction information, whereby the
participants can
44
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
conduct transactions with each other without requiring a direct trusting
relationship
between the participants.
4.2.3.2 [Claims 711-724]
In other embodiments of the foregoing method, the virtual clearinghouse
system may comprise data and/or code: that causes) said clearinghouse system
to act
as an agent for one or more repositories; for calculating, collecting,
disbursing,
reporting, andlor otherwise manipulating taxes and/or fees, or information
pertaining
to at least in part taxes and/or fees; for granting, revoking, reporting,
validating,
transmitting and/or otherwise manipulating credentials and/or licenses, or
information
pertaining to at least in part credentials and/or licenses; for granting,
revoking,
authenticating, validating, transmitting and/or otherwise manipulating one or
more
digital security certificates, or information pertaining to at least in part
digital security
certificates; and for granting, revoking, authenticating, validating,
transmitting and/or
otherwise manipulating one or more digital signatures, or information
pertaining to at
~ 5 least in part digital signatures.
4.2.3.3 [Claims 725-748]
According to other embodiments of the foregoing method, all or at least of
portion of the software in the system, including all code, and/or all or at
least a portion
of the data in said system, are encrypted and maintained in encrypted for
throughout
2o is storage in the system, throughout processing of data in the system,
and/or
throughout communication of data to and from the system.
4.2.4 Eighth Aspect:
4.2.4.1 [Claim 749]
Another aspect of the invention is a general method for operating a virtual
25 naming system. It comprises providing a computer system having at least one
data
processor, at least one data storage device, and at least one communications
device
through which the computer system can communicate with one or more entities
that
can connect with said computer system. This method includes maintaining in
said
computer system on said at least one data storage device naming service
software for
3o creating, storing, maintaining and/or otherwise manipulating data
comprising a lists)
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
of at least one name and at least one address for each of a plurality of
repositories.
The method further includes receiving from said entitylentities via said at
least one
communications device one or more requests that respectively include: a name
request, comprising an addresses) of and seeking a names) of one or more
repositories; andlor an address request, comprising a names) of and seeking an
addresses) of one or more repositories. The method causes said computer system
to
locate and to furnish to said entitylentities, one or more names) andlor
addresses)
sought by said request(s). One or more entities other than naming system
administrators, including persons, organizations and/or other computer
systems,
owning or having control of an accounts) in one or more repositories or at
least a
portion of the content of an accounts) in one or more repositories, and,
optionally,
one or more third party entities, can locate and discover a communication
routes) to
such a repositorylrepositories without knowing the name or without knowing the
address thereof.
~5 4.2.4.2 [Claims 750-763]
Included among the embodiments of this method are those in which the lists)
may comprise: known repositories, repository addresses, aliases for said
repositories,
repository ownership certificates, known clearinghouses, clearinghouse
addresses,
aliases for said clearinghouses, clearinghouse ownership certificates, known
labeling
2o systems, labeling system addresses, aliases for said labeling systems,
labeling system
ownership certificates, known naming systems, naming system addresses, aliases
for
said naming systems, naming system ownership certificates, known devices,
device
addresses, aliases for said devices, and/or device ownership certificates.
4.2.4.3 [Claims 764-787]
25 According to other embodiments of the foregoing method, all or,at least of
portion of the software in the system, including all code, and/or all or at
least a portion
of the data in said system, are encrypted and maintained in encrypted for
throughout
is storage in the system, throughout processing of data in the system, and/or
throughout communication of data to and from the system.
46
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.2.5 Ninth Aspect:
4.2.5.1 [Claim 788]
Another aspect of the invention is a general method for operating a virtual
labeling system. It comprises providing a computer system having at least one
data
processor, at least one data storage device, and at least one communications
device
through which the computer system can communicate with one or more entities
that
can connect with said computer system. This method includes maintaining in
said
computer system on said at least one data storage device labeling system
software for
storing and managing data comprising at least one label for each of one or
more
accounts, said data being at least in part accessible via said at least one
communications device, and said labels respectively comprising data that is
one or
more symbols, generated by the system or by an entity/entities having
ownership or
control of said accounts, which signify said account(s). Through said
software,
including data and/or code, the system can create, store, maintain andlor
otherwise
manipulate one or more lists of all known active labels of an account(s). The
labels
can include the private token(s), the public token(s), if any, and account
alias(es), if
any, of said account(s), wherein said account aliases) differ from any
existing public
and/or private tokens) of the accounts) to which the aliases) pertain.
Additionally,
said software, including data and/or code, can bar from introduction into said
list(s),
2o as an active label, any label which is not unique among all known active
labels
throughout all repositories with which said virtual labeling system
communicates.
The method further includes receiving from one or more repositories and/or one
or
more clearinghouses via said at least one communications device one requests
that
respectively include at least one alias of a given account and seek a public
token of
25 the given account. This method further includes fulfilling said requests by
transmitting the requested token/label to said repositories and/or
clearinghouses via
said at least one communications device. One or more third party entities who
are not
labeling system administrators, and who are not persons, organizations or
other
computer systems owning or having control of a given account(s), can locate
and
3o communicate with such accounts) without knowing the public tokens) for said
account(s).
47
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4.2.5.2 [Claims 789-794]
According to other embodiments of the foregoing method, the symbols) can
be of a random or non-random nature. In another embodiment the method further
comprises means for selecting said symbols) in a random manner. In other
s embodiments the method fiu ther comprises data and/or code for performing at
least
one of the steps of activating, authenticating, creating, deactivating,
destroying,
evaluating, generating, implementing, maintaining, modifying, processing,
registering, and/or otherwise manipulating: one or more label directories
comprising a
plurality of published account labels, one or more digital certificates or
lists) thereof,
andlor one or more digital signatures or lists) thereof.
4.2.5.3 [Claims 795-818]
According to other embodiments of the foregoing method, all or at least of
portion of the software in the system, including all code, andlor all .or at
least a portion
of the data in said system, are encrypted and maintained in encrypted for
throughout
~ s is storage in the system, throughout processing of data in the system,
and/or
throughout communication of data to and from the system.
48
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The following discussion of advantages is not intended to limit the scope of
the invention, nor to suggest that every form of the invention will have all
of the
following advantages. As will be seen from the remainder of this disclosure,
the
s present invention provides a variety of features. These can be used in
different
combinations. The different combinations are referred to as embodiments. Most
embodiments will not include all of the disclosed features. Some simple
embodiments can include a very limited selection of these features. Those
embodiments may have only one or a few of the advantages described below.
Other
preferred embodiments will combine more of these features, and will reflect
more of
the following advantages. Particularly preferred embodiments, that incorporate
many
of these features, will have most if not all of these advantages. Moreover,
additional
- advantages, not disclosed herein, that are inherent in certain embodiments
of the
invention, will become apparent to those who practice or carefully consider
the
15 invention.
This invention overcomes problems inherent in traditional asset and
transaction management systems by providing a system having a financial medium
that affords opportunities, to the extent desired, for varying levels of
security,
anonymity, portability, and bearer ownership. This medium can provide the
2o flexibility of cash and coin, yet can be interfaced with traditional
financial systems to
create a seamless and transparent set of mechanisms to transfer, pool,
distribute and/or
exchange assets. Additionally, this medium provides enhanced end-user control,
so
that individuals can, for the first time, manage their own financial risks on
a
transaction-by-transaction basis.
25 In a preferred embodiment, this financial medium is a virtual account.
Although improvements to traditional systems have been included that could
afford
some measure of end-user control for current asset and transaction management
systems, they fall short of offering the fullness of advantages to be found
when
combined with a virtual account.
3o Virtual accounts can be highly secure. They can include hierarchical
encryption on account structures and on the contents of these accounts, with a
finer
granularity than could be afforded by traditional financial media. Virtual
accounts, as
49
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
completely electronic representations of cash and other non-cash assets, allow
for new
types of flexible relationships between accounts not possible with traditional
financial
instruments. Additionally, virtual accounts can have domains that result in
coordinated management of accounts arranged in peer-to-peer and subordinate
parent-
s child-grandchild relationships, including inter-account transactions, shared
balances,
and limiting controls. When considered in the fullness of a complete advanced
asset
management system, they also offer a more robust set of user-defined, user-
selectable,
and user-determinable constraints and attributes than could be offered in more
traditional asset and transaction systems, and a finer level of granularity
than can be
offered in other advanced asset management systems considered within this
invention.
A virtual account is more secure than existing financial media because access
to its assets need not be limited to a single, unchanging account number.
Virtual
accounts can be manipulated using a token or an alias without exposing the
underlying account. This token can be dynamically generated for each
transaction, or
~ 5 in response to or in coordination with an external device like a timer.
The advanced
asset management system mechanism for generating a dynamic token can be
synchronized with a smartcard or other device to simultaneously, or on demand,
generate the appropriate token. Current financial media are insecure because
they
expose the underlying account information on every transaction, recorded
receipts of
2o which can be found months, even years, after the transaction has occurred;
the
dynamic token printed on a receipt for a virtual account transaction would be
outdated
before it could be compromised, producing a higher level of security. Combined
use
of constrains and dynamically generated tokens, if desired, can provide
particularly
high levels of security.
25 Particular embodiments of virtual accounts have inherent characteristics
through which they can readily be made anonymous. Unlike current financial
media
(other than cash), there is no prerequisite for knowing the identity of an
account
holder. A virtual account holder can thus decide to make their account
anonymous,
identified, or masked, at their discretion. Likewise, in the context of a
complete
3o advanced asset management system, transactions have attributes and
constraints
independent of the source or taxget virtual accounts. Thus, a transaction can
be
anonymous, identified, or masked, at the discretion of the parties involved,
independent of the level of identification associated with the virtual
accounts involved
f,
so
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Virtual accounts are bearer-owned. Having access to a virtual account is the
same as having a hand-full of cash or other assets. Unlike cash however,
virtual
accounts support remote transactions, and can be used for mail-order and
electronic
commerce as easily as they can for direct point-of sale transactions.
Additionally,
various levels of access can be granted, or other restrictions placed on the
account, the
content of the account, or the uses for which an account or its content can be
applied.
Thus, unlike other bearer-owned instruments, virtual accounts can maintain
layers of
security without adversely affecting their bearer-owned nature.
Virtual accounts can be portable. Virtual accounts do not have the physical
limitations found in other financial media. The physical instantiation of a
virtual
account as a card or other device can be arranged to be just an access
mechanism to
funds instead of the account itself. Then, any compatible device or access
mechanism, including, but not limited to wired and wireless telephone
networks,
Internet connections, automated teller machines, and other stand-alone devices
(e.g.,
~5 caxds, memory sticks, personal digital assistants), can all be used to
access any virtual
account. Additionally, assets can be seamlessly transferred between
centralized
systems and discrete, stand-alone systems.
A virtual account need not be limited to cash, but can also contain non-cash
assets such as program points, phone card minutes, coupons, discounts, and
other
2o assets. Non-cash assets may be interchanged with cash or other non-cash
assets
where the appropriate exchange mechanism is available.
Particular embodiments of virtual accounts can be used to facilitate both the
buyer and seller sides of electronic commerce transactions without the
establishment
of specialized infrastructure. Using the capabilities of these virtual
accounts and the
25 associated advanced asset management systems, the virtual accounts can
provide a
convenient mechanism to support electronic and conventional personal and
commercial transactions, for example forward and reverse auctions, barter
transactions, gaminglgambling transactions, and escrow transactions.
Additionally,
virtual escrow accounts can be used to enhance the security of traditional
retail or
3o service transaction where the buyer lacks confidence in the seller.
One advantage offered by some embodiments are mechanisms allowing for
the transfer, transmittal, receipt, aggregation, distribution, and exchange of
cash and
s1
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
non-cash assets within and between virtual accounts, as well as between
virtual
accounts and other types of asset management systems. In other embodiments,
this
invention provides mechanisms allowing the transfer of ownership, control, and
access methods to assets and accounts, without requiring the physical
manifestation
and transfer of the discrete assets themselves.
There are also some embodiments that have the advantage of providing
mechanisms for the at will creation and destruction of virtual accounts and
hierarchies
of accounts, and in these or other embodiments, the at will creation and
destruction of
domains of accounts, wherein the domains allow for en masse manipulation and
1o management of groups of selected virtual accounts.
Other embodiments afford additional benefits by allowing for the creation,
manipulation and destruction of system and user-defined, -selected, and -
determined
attributes and constraints, and in these and other embodiments, provisions for
the
evaluation of these attributes and constraints, allowing virtual account
holders
~ 5 unprecedented control over their assets, their information, their
accounts, and their
transactions. In addition to these, still other embodiments afford layered
encryption
services, such that individual objects within a virtual account can be secured
independently, or hierarchically. Thus, through selected use of constraints
and
encryption services, this invention affords a virtual account holder the added
benefit
20 of being able to selectively restrict the disclosure of information on a
virtual account,
its content, the relationships it has with other accounts, its transactions,
and its
transaction history.
Another unique advantage of certain embodiments of this invention is the
ability to provide both predetermined and user-defined virtual account classes
and
25 hierarchies of accounts. In certain embodiments, this invention provides
virtual
escrow accounts in which parties can securely, yet anonymously, transfer
assets
between and amongst parties for the barter of other assets, or for the
purchase of
goods, services, or other cash and non-cash assets. In other embodiments,
virtual bid
accounts are provided through which parties can securely, yet anonymously,
transfer
3o assets between and amongst parties for setting, evaluation of, and payment
of bids, for
the purchase of goods, services, or other cash and non-cash assets, most
typically
during auctions, reverse auctions, or other activities in which a conditional
purchase
offer is used. In still other embodiments, virtual gaming accounts allow
parties to
s2
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
securely, yet anonymously, transfer assets between and amongst parties for
setting,
evaluation of, and payment in connection with wagers, bets, lotteries, games
of
chance, and other gaming and gambling activities. In yet other embodiments,
virtual
proxy accounts allow for secure, anonymous transactions between conventional
and
virtual accounts, and even between multiple conventional accounts.
This invention, in certain embodiments, provides other systems and services
that enhance the ability of individuals to conduct secure transactions. These
systems
and services, among other embodiments, include repositories, groups of
repositories,
clearinghouses, naming systems, and labeling systems.
One set of services, available for use if desired in any of the various
systems,
is the use of agents, alerts, and triggers which can be configured by virtual
account
owners and system administrators to provide such services as real-time event
monitoring, automated status change notification, and pre-configured active or
passive responses. Agents, alerts, and triggers can be set for use at multiple
levels
within the various systems offered within this invention, from the lowest
content
level, through accounts and domains, to larger groupings of repositories,
transaction
pool structures used by clearinghouses, and directories and lists used by
naming and
labeling systems.
Several other embodiments provide for the management and manipulation of
2o attributes and constraints on obj ects within these various systems whereby
account
owners, system administrators, and other owning or controlling entities can
invoke,
manage and/or otherwise manipulate rules or controls on how these systems,
accounts, and objects act, place limits or ranges on the actions allowed, and
decide the
forms that these objects can take. Along with these benefits, this invention
includes
the management and manipulation of multiple access methods to accounts and
systems, and the ability to place and evaluate constraints on such access
methods.
In particular embodiments, this invention offers repositories that centrally
store, manage and maintain a specific set of virtual accounts, all public and
private
tokens for these accounts, and all transactions in which these accounts
participate. In
3o additional embodiments, this invention allows vaxious groupings of
repositories,
including but not limited to inter-networked groups, distributed-federated
groups,
distributed groups, and federated groups, each storing, managing and
maintaining a
53
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
specific set of virtual accounts, all related public and private tokens, and
all their
transactions and traceable transaction histories, along with the ability to
seamlessly
transfer, transmit, receive, aggregate, distribute, and exchange accounts,
groups of
accounts, and entire account domains, as well as information and assets, to
and from
s specific accounts stored within the respective repositories.
Virtual clearinghouses, included among the several embodiments, offer unique
enhancements to virtual account transactions and other systems and services by
providing a central, trusted, third-party through which transactions can be
coordinated. This allows for transactions to be conducted between systems
and/or
1 o devices that lack an explicit trust arrangement. Some advantages afforded
by virtual
clearinghouses, as provided by several embodiments, include the ability to
coordinate
value-added services including escrow, bid and gaming/gambling transactions
between two or more parties. Virtual clearinghouses can also render tax and
fee
services, credential and license services, and digital security certificate
and digital
15 signature services and other more traditional clearinghouse activities.
In other embodiments, virtual naming systems and virtual labeling systems
provide additional benefits and enhancements over traditional asset and
transaction
management systems. Naming systems provide means to locate and discover
communication routes to repositories, clearinghouses, labeling systems, other
naming
2o systems, and specific devices without knowing the name or without knowing
the
address of such systems and devices. In other embodiments, naming systems
offer
the added benefits of allowing parties to conduct transactions through
aliases, as well
as in guaranteeing the validity of current ownership certificates.
Other embodiments focusing on virtual labeling systems offer similar
25 benefits for individual accounts. The labeling system provides means to
locate and
communicate with accounts without the need to know their specific account
numbers
or public token(s). In additional embodiments, the labeling system can publish
directories of labels for accounts, and can create both system and end-user
generated
random and non-random labels.
3o To the extent it is desired to use the features provided by the invention,
individuals, partnerships, associations, corporations, charitable and
educational
institutions, governments and their instrumentalities, computer and
communications
54
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
systems and other entities, using virtual accounts, advanced asset management
systems and related systems, can participate with one another, in any
combination, in
cash and non-cash transactions with any desired level of privacy and security.
ss
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Each of the figures is a schematic diagram more fully described below.
Figure 1 shows a computer system containing a data processor (CPLT), a
communications device, and a storage device with an operating system, virtual
account management software, and multiple virtual accounts, communicating with
one or more entities.
Figure 2 shows a computer system containing multiple data processors (CPT~,
multiple communications devices, and multiple storage devices, each with an
operating system, virtual account management software, and multiple virtual
1 o accounts, communicating with one or more entities.
Figure 3 shows a virtual account: a single private token, a single
public/private
account connection interface, and single public account with its public token.
Figure 4 shows a virtual account: a single private account with its private
token, a single public/private account connection interface, and single public
account
~ s with its public token.
Figure 5 shows a virtual account: a single private account with its private
token, a single public/private account connection interface, and multiple
public
accounts each with its own public token, where one of the public accounts is
subordinate to the other.
2o Figure 6 shows a virtual account: a single private account with'its private
token, multiple public/private account connection interfaces, and multiple
public
accounts each with its own public token.
Figure 7 shows a virtual account: a single private account with its private
token, a single shared public/private account connection interface, and
multiple public
25 accounts each with its own public token.
Figure 8 shows a virtual account: multiple private accounts each with its own
private token, a single shared public/private account connection interface,
and single
public account with its own public token.
56
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 9 shows a virtual account: multiple private accounts each with its own
private token, a single shared public/private account connection interface,
and
multiple public accounts each with its own public token.
Figure 10 shows a virtual account: multiple private accounts each with its own
private token, multiple public/private account connection interfaces, and
multiple
public accounts each with its own public token.
Figure 11 shows a logical connection from a primary account in one virtual
account to a single primary account in a second virtual account.
Figure 12 shows a logical connection from one of multiple primary accounts
in one virtual account to a primary account in a second virtual account.
Figure 13 shows a logical connection from a primary account in one virtual
account to a primary account in a second virtual account which contains
multiple
primary accounts.
Figure 14 shows a logical connection from one primary account to another
~ 5 primary account within a virtual account.
Figure 15 shows a logical connection from a primary account in one virtual
account to a subordinate public account in a second virtual account which
contains
multiple public accounts.
Figure 16 shows a logical connection from one of multiple primary accounts
2o in one virtual account to a subordinate public account in a second virtual
account
which contains multiple public accounts.
Figure 17 shows a logical connection from a primary account in one virtual
account to a subordinate public account in a second virtual account which
contains
multiple subordinate public accounts.
25 Figure 18 shows a logical connection from a primary account in one virtual
account to a subordinate public account in a second virtual account which
contains
multiple subordinate public accounts.
Figure 19 shows a logical connection from a primary account in one virtual
account to a subordinate public account in a second virtual account which
contains
3o multiple subordinate public accounts.
5~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 20 shows a logical connection from a primary account to a subordinate
public account within one virtual account.
Figure 21 shows logical connections from a primary account to multiple
subordinate public accounts within one virtual account.
Figure 22 shows a logical connection from a primary account to an unrelated
subordinate public account within one virtual account.
Figure 23 shows a logical connection from a primary account to an unrelated
subordinate public account within one virtual account.
Figure 24 shows logical connections from multiple primary accounts to a
single subordinate public account within one virtual account.
Figure 25 shows a logical connection from one of multiple primary accounts
to an unrelated subordinate public account within one virtual account.
Figure 26 shows logical connections from multiple primary accounts to
multiple subordinate public accounts within one virtual account.
15 Figure 27 shows a logical connection from a subordinate public account in
one
virtual account to a primary account in a second virtual account.
Figure 2~ shows a logical connection from a subordinate public account in one
virtual account to a primary account in a second virtual account which
contains
multiple primary accounts.
2o Figure 29 shows a logical connection from one of multiple subordinate
public
accounts in one virtual account to a primary account in a second virtual
account.
Figure 30 shows a logical connection from one of multiple subordinate public
accounts in one virtual account to a primary account in a second virtual
account.
Figure 31 shows a logical connection from one of multiple subordinate public
25 accounts in one virtual account to a primary account in a second virtual
account.
Figure 32 shows a logical connection from a subordinate public account to a
primary account within one virtual account.
Figure 33 shows a logical connection from multiple subordinate public
accounts to a primary account within one virtual account.
s8
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 34 shows a logical connection from one of multiple subordinate public
accounts to an unrelated primary account within one virtual account.
Figure 35 shows a logical connection from one of multiple subordinate public
accounts to an unrelated primary account within one virtual account.
Figure 36 shows logical connections from a subordinate public account to
multiple primary accounts within one virtual account.
Figure 37 shows a logical connection from a subordinate public account to one
unrelated primary account within one virtual account.
Figure 38 shows logical connections from multiple subordinate public
1 o accounts to multiple primary accounts within one virtual account.
Figure 39 shows a logical connection from a subordinate public account in one
virtual account to a subordinate public account in another virtual account.
Figure 40 shows a logical connection from one of multiple subordinate public
accounts in one virtual account to a subordinate public account in another
virtual
15 account.
Figure 41 shows a logical connection from a subordinate public account in one
virtual account to one of multiple subordinate public accounts in another
virtual
account.
Figure 42 shows a logical connection from a subordinate public account in one
2o virtual account to one of multiple subordinate public accounts in another
virtual
account.
Figure 43 shows a logical connection from one subordinate public account to
another subordinate public account within one virtual account.
Figure 44 shows a logical connection from one subordinate public account to
25 another subordinate public account within one virtual account.
Figure 45 shows a logical connection from one subordinate public account to
another subordinate public account within one virtual account.
Figure 46 shows a logical connection from one subordinate public account to
another subordinate public account within one virtual account.
59
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 47 shows a logical connection from one subordinate public account to
another subordinate public account within one virtual account.
Figure 48 shows a logical connection from one subordinate public account to
another subordinate public account within one virtual account.
Figure 49 shows a virtual account with all sub-accounts of the virtual account
(a single private account and a single public account) contained within one
domain.
Figure 50 shows a virtual account with all sub-accounts of the virtual account
(multiple private accounts and multiple public accounts) contained within one
domain, sharing a single public/private account interface within the domain.
Figure 51 shows a virtual account with all sub-accounts of the virtual account
(multiple private accounts and multiple public accounts) contained within one
domain, with multiple public/private account interfaces within the domain.
Figure 52 shows a virtual account: single private domain, single private
account, and a single public/private account connection interface.
~ 5 Figure 53 shows a virtual account: single private domain, multiple private
accounts, and a single shared public/private account connection interface.
Figure 54 shows a single private domain, multiple private accounts, and
multiple public/private account connection interfaces.
Figure 55 shows a virtual account: multiple private domains, each with its own
2o private account, and a single shared public/private account connection
interface.
Figure 56 shows a virtual account: multiple private domains, each with its own
private account, and multiple public/private account connection interfaces.
Figure 57 shows a virtual account: multiple nested private domains, multiple
private accounts, and a single shared public/private account connection
interface.
25 Figure 58 shows a virtual account: multiple nested private domains,
multiple
private accounts, and multiple public/private account connection interfaces.
Figure 59 shows a virtual account: single public domain, single public
account, and a single public/private account connection interface.
Figure 60 shows a virtual account: single public domain, multiple public
so accounts, and a single public/private account connection interface.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 61 shows a virtual account: single public domain, multiple public
accounts, and a single shared public/private account connection interface.
Figure 62 shows a virtual account: single public domain, multiple public
accounts, and a single shared public/private account connection interface.
Figure 63 shows a virtual account: single public domain, multiple public
accounts, and multiple public/private account connection interfaces.
Figure 64 shows a virtual account: single public domain, multiple public
accounts, and multiple public/private account connection interfaces.
Figure 65 shows a virtual account: multiple public domains each with its own
public account, and a single public/private account connection interface.
Figure 66 shows a virtual account: multiple public domains each with its own
public account, and a single shared public/private account connection
interface.
Figure 67 shows a virtual account: multiple public domains each with one or
more public accounts, and a single shared public/private account connection
interface.
~ 5 Figure 68 shows a virtual account: multiple public domains each with one
or
more public accounts, and a single shared public/private account connection
interface.
Figure 69 shows a virtual account: multiple public domains each with its own
public account, and a single shared public/private account connection
interface.
Figure 70 shows a virtual account: multiple public domains each with its own
2o public account, and multiple public/private account connection interfaces.
Figure 71 shows a virtual account: multiple public domains each with one or
more public accounts, and multiple public/private account connection
interfaces.
Figure 72 shows a virtual account: multiple public domains each with its own
public account, and multiple public/private account connection interfaces.
25 Figure 73 shows a virtual account: multiple nested public domains each with
one or more public accounts, and a single shared public/private account
connection
interface.
Figure 74 shows a virtual account: multiple nested public domains each with
one or more public accounts, and a single shared public/private account
connection
3o interface.
61
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 75 shows a virtual account: multiple nested public domains each with
one or more public accounts, and a single shared public/private account
connection
interface.
Figure 76 shows a virtual account: multiple nested public domains each with
one or more public accounts, and a single shared public/private account
connection
interface.
Figure 77 shows a virtual account: multiple nested public domains each with
one or more public accounts, and a single shared public/private account
connection
interface.
1 o Figure 78 shows a virtual account: multiple public domains, some nested,
each
with one or more public accounts, and a single shared publiclprivate account
connection interface.
Figure 79 shows a virtual account: multiple nested public domains each with
one or more public accounts, and multiple public/private account connection
interfaces.
Figure 80 shows a virtual account: multiple nested public domains each with
one or more public accounts, and multiple public/private account connection
interfaces.
Figure 81 shows a virtual account: multiple nested public domains each with
one or more public accounts, and multiple public/private account connection
interfaces.
Figure 82 shows a virtual account: multiple nested public domains each with
one or more public accounts, and multiple public/private account connection
interfaces.
Figure 83 shows a virtual account: multiple nested public domains each with
one or more public accounts, and multiple public/private account connection
interfaces.
Figure 84 shows a virtual account: multiple public domains, some nested, each
with one or more public accounts, and multiple public/private account
connection
so interfaces.
62
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 85 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device with
an
operating system, virtual account management software, and multiple virtual
accounts, including an encryption engine, communicating with one or more
entities.
Figure 86 shows a computer system containing a dedicated encryption engine,
at least one data processor (CPS, at least one communications device, and at
least
one storage device with an operating system, virtual account management
software,
and multiple virtual accounts, communicating with one or more entities.
Figure 87 shows a computer system containing at least one data processor
(CPL>7, at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and multiple virtual
accounts, wherein said storage devices) contains) an integrated encryption
engine,
communicating with one or more entities.
Figure 88 shows a computer system containing at least one data processor
15 (CPS, at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and multiple virtual
accounts, wherein said data processors(s) contains) an integrated encryption
engine,
communicating with one or more entities.
Figure 89 shows a computer system containing at least one data processor
20 (CPIJ), at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and multiple virtual
accounts, wherein said communications devices) contains) an integrated
encryption
engine, communicating with one or more entities.
Figure 90 shows a computer system containing at least one data processor
25 (CPT~, at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and multiple virtual
accounts, wherein said communications device connects to other communications
devices) and entity/entities outside of said computer system.
Figure 91 shows a virtual account repository (referred hereafter as
30 "repository"), containing multiple virtual accounts.
Figure 92 shows a computer system containing at least one data processor
(CPL)], at least one communications device, and at least one storage device
with an
63
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
entities.
Figure 93 shows a computer system containing at least one data processor
(CPl~, at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
entities.
Figure 94 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device with
an
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
other
repositories external to said computer system.
Figure 95 shows a computer system containing at least one data processor
(CPIs, at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
entities
through one or more external communications devices.
Figure 96 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, virtual account management software, and one or more
repositories
2o each containing multiple virtual accounts, communicating with one or more
repositories through one or more external communications devices.
Figure 97 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
other
repositories external to said computer system, and through one or more
external
communications devices to one or more entities and/or other repositories.
Figure 98 shows a distributed group of repositories.
Figure 99 shows a federated group of repositories.
3o Figure 100 shows a distributed-federated group of repositories.
Figure 101 shows an inter-networked group of discrete repositories.
64
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 102 shows an inter-networked group of discrete repositories, federated,
distributed, and distributed-federated groups of repositories.
Figure 103 shows a discrete repository connected to another discrete
repository, a repository/repositories within a distributed, a federated, a
distributed-
federated, and/or an inter-networked group of repositories.
Figure 104 shows a repository within a distributed group connected to a
discrete repository, a repository/repositories witlun a distributed, a
federated, a
distributed=federated, and/or an inter-networked group of repositories.
Figure 105 shows a repository within a federated group connected to a discrete
repository, a repository/repositories within a distributed, a federated, a
distributed-
federated, and/or an inter-networked group of repositories.
Figure 106 shows a repository within a distributed-federated group connected
to a discrete repository, a repository/repositories within a distributed, a
federated, a
distributed-federated, and/or an inter-networked group of repositories.
~ 5 Figure 107 shows a repository within an inter-networked group connected to
a
discrete repository, a repository/repositories within a distributed, a
federated, a
distributed-federated, and/or an inter-networked group of repositories.
Figure 10~ shows a computer system containing at least one data processor
(CPT~, at least one communications device, and at least one storage device
with an
20 operating system, virtual account management software, repository
encryption engine,
arid one or more repositories each containing multiple virtual accounts,
communicating with one or more entities.
Figure 109 shows a computer system containing a dedicated encryption
engine, at least one data processor (CPT~, at least one communications device,
and at
25 least one storage device with an operating system, virtual account
management
software, and one or more repositories each containing multiple virtual
accounts,
communicating with one or more entities.
Figure 110 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device with
an
30 operating system, virtual account management software, and one or more
repositories
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
each containing multiple virtual accounts, communicating with one or more
entities,
wherein said storage devices) contains) an integrated encryption engine.
Figure 111 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
entities,
wherein said data processors(s) contains) an integrated encryption engine.
Figure 112 shows a computer system containing at least one data processor
(CPl~, at least one communications device, and at least one storage device
with an
operating system, virtual account management software, and one or more
repositories
each containing multiple virtual accounts, communicating with one or more
entities,
wherein said communications devices) contains) an integrated encryption
engine.
Figure 113 shows a computer system containing a data processor (CPL>7, a
communications device, and a storage device with an operating system, virtual
15 clearinghouse software, and a virtual clearinghouse (referred hereafter as
"clearinghouse"), used to facilitate virtual account transactions, escrow
transactions,
bid pools, gaming/gambling pools, and containng tax & fee, digital signature,
digital
certificate, credential & license, and agent services engines (as a group
referred
hereafter as "clearinghouse components") communicating to transaction
participants.
2o Figure 114 shows a computer system containing multiple data processors
(CPS, multiple communications devices, and multiple storage devices, each with
an
operating system, clearinghouse software, and a clearinghouse with its
components,
communicating to transaction participants.
Figure 115 shows a computer system containing at least one data processor
25 (CPU), at least one communications device, and at least one storage device
with an
operating system, clearinghouse software, and one or more clearinghouses each
with
its components, communicating to transaction participants.
Figure 116 shows a virtual clearinghouse system acting as in intermediary to
transactions within a discrete repository, as well as to transactions within
individual
3o repositories which are members of distributed-federated, distributed,
federated, andlor
inter-networked groups of repositories.
66
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 117 shows a virtual clearinghouse system acting as in intermediary to
transactions between various discrete repositories, as well as distributed-
federated,
distributed, federated, and inter-networked groups of repositories.
Figure 11 ~ shows a virtual clearinghouse system acting as in intermediary to
transactions to and from various discrete repositories, as well as distributed-
federated,
distributed, federated, and inter-networked groups of repositories from and to
non-
repository entities.
Figure 119 shows a computer system containing at least one data processor
(CPI, at least one communications device, and at least one storage device with
an
operating system, clearinghouse software, and one or more clearinghouses,
including
a virtual clearinghouse encryption engine, communicating to transaction
participants.
Figure 120 shows a computer system containing a dedicated encryption
engine, at least one data processor (CPLT), at least one communications
device, and at
least one storage device with an operating system, clearinghouse software, and
one or
~ 5 more clearinghouses, communicating to transaction participants.
Figure 121 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, clearinghouse software, and one or more clearinghouses,
wherein
said storage devices) contains) an integrated encryption engine, communicating
to
20 transaction participants.
Figure 122 shows a computer system containing at least one data processor
(CPL)7, at least one communications device, and at least one storage device
with an
operating system, clearinghouse software, and one or more clearinghouses,
wherein
said data processors(s) contains) an integrated encryption engine,
communicating to
25 transaction participants.
Figure 123 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, clearinghouse software, and one or more clearinghouses,
wherein
said communications devices) contains) an integrated encryption engine,
so communicating to transaction participants.
Figure 124 shows a computer system containing a data processor (CPS, a
communications device, and a storage device with an operating system, virtual
67
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
naming system software, and a virtual naming system (referred hereafter as
"naming
system"), including a lists) of naming system objects and lists) of naming
system
object addresses, communicating with one or more entities, wherein naming
system
objects comprise repositories, clearinghouses, labeling systems, naming
systems
and/or devices (the lists collectively referred hereafter as "naming system
lists").
Figure 125 shows a computer system containing multiple data processors
(CPl~, multiple communications devices, and multiple storage devices, each
with an
operating system, naming system software, and multiple naming systems each
with its
lists, communicating with one or more entities.
Figure 126 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device with
an
operating system, naming system software, and one or more naming systems each
with its lists, communicating with one or more entities.
Figure 127 shows a computer system containing at least one data processor
~ 5 (CPLT), at least one communications device, and at least one storage
device with an
operating system, naming system software, and one or more naming systems each
with its lists, and additionally containing a lists) of object aliases,
communicating
with one or more entities.
Figure 128 shows a computer system containing at least one data processor
20 (CPL)), at least one communications device, and at least one storage device
with an
operating system, naming system software, and one or more naming systems each
its
lists, and additionally containing and a set of object ownership certificates,
communicating with one or more entities.
Figure 129 shows a computer system containing at least one data processor
25 (CPL)), at least one communications device, and at least one storage device
with an
operating system, naming system software, and one or more naming systems each
with its lists, including a virtual naming system encryption engine,
communicating
with one or more entities.
Figure 130 shows a computer system containing a dedicated encryption
3o engine, at least one data processor (CPU), at least one communications
device, and at
least one storage device with an operating system, naming system software, and
one
or more naming systems each with its lists, communicating with one or more
entities.
68
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 131 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device
with an
operating system, naming system software, and one or more naming systems each
with its lists, communicating with one or more entities, wherein said storage
devices)
contains) an integrated encryption engine.
Figure 132 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device
with an
operating system, naming system software, and one or more naming systems each
with its lists, communicating with one or more entities, wherein said data
processors(s) contains) an integrated encryption engine.
Figure 133 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device with
an
operating system, naming system software, and one or more naming systems each
with its lists, communicating with one or more entities, wherein said
communications
15 devices) contains) an integrated encryption engine.
Figure 134 shows examples of the types of assets that can be contained within
a virtual account.
Figure 135 shows examples of the types of documents that can be contained
within a virtual account.
2o Figure 136 shows a computer system containing a data processor (CPU], a
communications device, and a storage device with an operating system, asset
management software, attribute management software, and accounts with zero,
one,
or more attributes, communicating with one or more entities.
Figure 137 shows a computer system containing multiple data processors
25 (CPU), multiple communications devices, and multiple storage devices, each
with an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more attributes, communicating with one or more
entities.
Figure 138 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device with
an
30 operating system, asset management software, attribute management software,
and
accounts with zero, one, or more attributes, communicating with one or more
entities.
69
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 139 shows the possible attributes for a generic object from a system
having system required attributes and one or more possible user-selected, user-
determined, and/or user-defined attributes.
Figure 140 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more attributes, including user-defined
attributes, user-
selectable attributes, and/or user-determinable attributes, communicating with
one or
more entities.
1 o Figure 141 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more attributes, including user-defined
attributes, user-
selectable attributes, and/or user-determinable attributes, including an
~5 account/attribute management system encryption engine, communicating with
one or
more entities.
Figure 142 shows a computer system containing a dedicated encryption
engine, at least one data processor (CPS, at least one communications device,
and at
least one storage device with an operating system, asset management software,
2o attribute management software, and accounts with zero, one, or more
attributes,
including user-defined attributes, user-selectable attributes, and/or user-
determinable
attributes, communicating with one or more entities.
Figure 143 shows a computer system containing at least one data processor
(CPT~, at least one communications device, and at least one storage device
with an
25 operating system, asset management software, attribute management software,
and
accounts with zero, one, or more attributes, including user-defined
attributes, user-
selectable attributes, and/or user-determinable attributes, communicating with
one or
more entities, wherein said storage devices) contains) an integrated
encryption
engine.
3o Figure 144 shows a computer system containing at least one data processor
(CPl~, at least one communications device, and at least one storage device
with an
operating system, asset management software, attribute management software,
and
'70
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
accounts with zero, one, or more attributes, including user-defined
attributes, user-
selectable attributes, and/or user-determinable attributes, communicating with
one or
more entities, wherein said data processors(s) contains) an integrated
encryption
engine.
Figure 145 shows a computer system containing at least one data processor
(CPI, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more attributes, including user-defined
attributes, user-
selectable attributes, and/or user-determinable attributes, communicating with
one or
more entities, wherein said communications devices) contains) an integrated
encryption engine.
Figure 146 shows a computer system containing a data processor (CPLn, a
communications device, and a storage device with an operating system, asset
management software, attribute management software, and accounts with zero,
one,
~ 5 or more constraints, communicating with one or more entities.
Figure 147 shows a computer system containing multiple data processors
(CPI, multiple communications devices, and multiple storage devices, each with
an
operating system, asset management softwaxe, attribute management software,
and
accounts with zero, one, or more constraints, communicating with one or more
20 entities.
Figure 14~ shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more constraints, communicating with one or more
25 entities.
Figure 149 shows the possible constraints for a generic object from a system
having system required constraints and one or more possible user-selected,
user-
determined, and/or user-defined constraints.
Figure 150 shows a computer system containing at least one data processor
30 (CPL)), at least one communications device, and at least one storage device
with an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more constraints, including user-defined
constraints, user-
~1
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
selectable constraints, andlor user-determinable constraints, communicating
with one
or more entities.
Figure 151 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more constraints, including user-defined
constraints, user-
selectable constraints, and/or user-determinable constraints, including an
account/constraint management system encryption engine, communicating with one
or more entities.
1 o Figure 152 shows a computer system containing a dedicated encryption
engine, at least one data processor (CPS, at least one communications device,
and at
least one storage device with an operating system, asset management software,
attribute management software, and accounts with zero, one, or more
constraints,
including user-defined constraints, user-selectable constraints, and/or user-
15 determinable constraints, communicating with one or more entities.
Figure 153 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
accounts with zero, one, or more constraints, including,user-defined
constraints, user-
2o selectable constraints, and/or user-determinable constraints, communicating
with one
or more entities, wherein said storage devices) contains) an integrated
encryption
engine.
Figure 154 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
25 operating system, asset management software, attribute management software,
and
accounts with zero, one, or more constraints, including user-defined
constraints, user-
selectable constraints, and/or user-determinable constraints, communicating
with one
or more entities, wherein said data processors(s) contains) an integrated
encryption
engine.
3o Figure 155 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device with
an
operating system, asset management software, attribute management software,
and
~2
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
accounts with zero, one, or more constraints, including user-defined
constraints, user-
selectable constraints, and/or user-determinable constraints, communicating
with one
or more entities, wherein said communications devices) contains) an integrated
encryption engine.
Figure 156 shows examples of attributes and constraints for repositories,
accounts, and the contents of repositories and accounts.
Figure 157 shows examples of the flow of constraints from an inter-networked
group of repositories downward to: a distributed-federated group, a
distributed group
(or a federated group), an individual repository, and the component parts of a
virtual
account.
Figure 158 shows examples of the flow of constraints from a distributed-
federated group of repositories downward to: a distributed group (or a
federated
group), an individual repository, and the component parts of a virtual
account.
Figure 159 shows examples of the flow of constraints from a distributed (or
federated) group of repositories downward to: an individual repository, and
the
component parts of a virtual account.
Figure 160 shows examples of the flow of constraints from an individual
repository downward to: the component parts of a virtual account.
Figure 161 shows examples of the flow of constraints from a virtual account
2o downward to: the component parts of the virtual account, including the
public and
private domain constraint pools, the individual public and private sub-
accounts, and
the contents thereof.
Figure 162 shows examples of the flow of constraints from the public and
private domain constraint pools downward to: the individual public and private
sub-
accounts within the particular domain constraint pools, and the contents
thereof.
Figure 163 shows examples of the flow of constraints from the individual
public and private sub-accounts downward to: the specific subordinate accounts
of the
public and private sub-accounts, and the contents thereof
Figure 164 shows examples of the aggregation of constraints from the largest
3o set, an inter-networked group of repositories, to the smallest, an
individual account.
73
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 165 shows examples of the common transaction and communications
infrastructure of a virtual account management system, using public, private,
and
private-over-public communications networks.
Figure 166 shows physical assets inbound to a virtual account.
Figure 167 shows physical assets outbound from a virtual account.
Figure 16~ shows communications device to repository communications
connection with one or more clearinghouses as intermediaries.
Figure 169 shows communications device to communications device
communications connection with one or more clearinghouses as intermediaries.
Figure 170 shows repository to repository communications connection with
one or more clearinghouses as intermediaries.
Figure 171 shows an example of an "n"-tiered hierarchy of accounts within the
public portion of a virtual account.
Figure 172 shows an example of a primary account domain containing a
~ 5 representative sample of the most common types of subordinate accounts,
including:
child, peer, escrow, escrow obligation, escrow credit, bid, gaming, proxy,
dynamic
proxy, proxy with dynamic VlNs, and labeled subordinate accounts, and a
subordinate
account domain.
Figure 173 shows an example of a primary account domain containing only
2o child accounts.
Figure 174 shows an example of a primary account domain containing only
child accounts, and a subordinate account domain.
Figure 175 shows an example of a primary account domain containing only
peer accounts.
25 Figure 176 shows an example of a primary account domain containing only
peer accounts, and a subordinate account domain.
Figure 177 shows an example of a primary account domain showing the
creation of an escrow account via the inheritance of the primary account's
escrow
account constraint set skeleton.
74
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 178 shows an example of the flow of assets, agents, alerts, and
triggers,
and the evaluation of constraints and external stimuli, in the creation and
operation of
an escrow account established between a generic buyer and seller, where the
escrow
account is within the domain of the buyer or seller.
Figure 179 shows an example of the flow of assets, agents, alerts, and
triggers,
and the evaluation of constraints and external stimuli, in the creation and
operation of
an escrow account established between a generic buyer and seller, where the
escrow
account is within the domain of the third party.
Figure 180 shows an example of the flow of assets, agents, alerts, and
triggers,
1o and the evaluation of constraints and external stimuli, in the creation and
operation of
an escrow account with various escrow child accounts, used as an obligation or
credit
account in transactions with other virtual accounts.
Figure 181 shows an example of a primary account domain showing the
creation of a bid account and related bid pool via the inheritance of the
primary
~ 5 account's bid account constraint set skeleton.
Figure 182 shows an example of the creation of a bid/request account with
multiple bid/request child accounts and bid pools.
Figure 183 shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of a bid account
established to
2o facilitate a bid between competing bidders.
Figure 184 shows an example of the automatic establishment and operation of
a bid escrow account within a bid pool.
Figure 185 shows an example of a primary account domain showing the
creation of a gaming account and related gaming pool via the inheritance of
the
25 primary account's gaming account constraint set skeleton.
Figure 186 shows an example of the creation of a gaming account with
multiple gaming child accounts and gaming pools.
Figure 187 shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of a gaming account
established to
3o facilitate wagers.
~s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 188 shows an example of the automatic establishment and operation of
a wager escrow account within a gaming pool.
Figure 189 shows an example of a primary account domain showing the
creation of a proxy account via the inheritance of the primary account's proxy
account
constraint set skeleton.
Figure 190 shows an example of a relationship between a primary account and
a proxy account, including some typical constraints for the proxy account.
Figure 191 shows an example of multiple proxy accounts each subordinate to
different accounts within the primary account's domain.
Figure 19~ shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of a proxy account used to
establish
a relationship to a conventional account, in this case, a bank savings
account.
Figure 193 shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of a proxy account used as
a
substitute for a conventional account in a relationship with another virtual
account.
Figure 194 shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of multiple proxy accounts
used to
establish multiple relationships to various conventional accounts.
Figure 195 shows an example of the flow of assets, constraints, and agents,
2o alerts, and triggers, in the creation and operation of single proxy account
used to
manage relationships to, from, and between multiple discrete conventional
accounts.
Figure 196 shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of single proxy account
used to
manage relationships from multiple discrete conventional accounts to
subordinate
account within the same domain.
Figure 197 shows an example of the flow of assets, constraints, and agents,
alerts, and triggers, in the creation and operation of single proxy account
used to
manage relationships from multiple discrete conventional accounts to another
virtual
account.
3o Figure 198 shows an example of a primary account domain showing the on-
demand creation of one or more dynamic proxy account(s).
76
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 199 shows an example of a primary account domain showing a primary
account with a dynamically generated V1N.
Figure 200 shows an example of a primary account domain showing multiple
subordinate accounts each with their own dynamically generated VIN.
Figure 201 shows an example of a primary account domain showing the use of
a proxy account with a dynamically generated VIN in a relationship with a
conventional account.
Figure 202 shows an example of a primary account domain showing the use of
a dynamic proxy account with a dynamically generated VIN, conducting a
transfer of
assets from a conventional account to another virtual account.
Figure 203 shows an example of the use of various types of fixed, randomly
selected, and randomly generated labels in place of VINs for various accounts.
Figure 204 shows a computer system containing a data processor (CPL>7, a
communications device, and a storage device with an operating system, virtual
labeling software, and a virtual labeling system, communicating with one or
more
entities.
Figure 205 shows a computer system containing multiple data processors
(CPU), multiple communications devices, and multiple storage devices, each
with an
operating system, virtual labeling software, and multiple virtual labeling
systems,
2o communicating with one or more entities.
Figure 206 shows a computer system containing at least one data processor
(CPLI), at least one communications device, and at least one storage device,
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, communicating with one or more entities.
Figure 207 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device,
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, including a digital certificate engine,
communicating with
one or more entities.
3o Figure 208 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device,
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, including a digital signature engine, communicating
with one
or more entities.
Figure 209 shows a computer system containing at least one data processor
(CPL>7, at least one communications device, and at least one storage device,
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, including a virtual labeling system encryption
engine,
communicating with one or more entities.
Figure 210 shows a computer system containing a dedicated encryption
1 o engine, at least one data processor (CPU, at least one communications
device, and at
least one storage device, containing an operating system, virtual labeling
system
software, and one or more virtual labeling systems, communicating with one or
more
entities.
Figure 211 shows a computer system containing at least one data processor
~ 5 (CPL>7, at least one communications device, and at least one storage
device,
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, communicating with one or more entities, wherein
said
storage devices contain an integrated encryption engine.
Figure 212 shows a computer system containing at least one data processor
20 (CPI, at least one communications device, and at least one storage device,
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, communicating with one or more entities, wherein
said data
processors contain an integrated encryption engine.
Figure 213 shows a computer system containing at least one data processor
25 (CPT~, at least one communications device, and at least one storage device,
containing an operating system, virtual labeling system software, and one or
more
virtual labeling systems, communicating with one or more entities, wherein
said
communications devices contain an integrated encryption engine.
Figure 214 shows the selection of an attribute and a constraint from the
3o available attributes and constraints contained within a domain constrain
pool, and the
application of the selected objects on an account within the domain constrain
pool's
domain.
78
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 215 shows an example of a subordinate account changing type, in this
instance a child account becoming a peer account.
Figure 216 shows an example of a subordinate account transferred from one
parent to another within the same domain.
Figure 217 shows an example of several subordinate accounts transferred as a
group from one parent to another within the same domain.
Figure 218 shows an example of a subordinate account transferred between
virtual accounts while maintaining account type, in this instance a child
account
transferred as a child account.
Figure 219 shows an example of a subordinate account transferred between
virtual accounts including a change in account type, in this instance a
transferred child
account becoming a peer account.
Figure 220 shows an example of a subordinate account becoming a primary
account in a newly created virtual account.
15 Figure 221 shows an example of a group of accounts transferred between
virtual accounts, including all subordinate accounts, as well as a change in
account
type, in this instance a primary-child pair transferred as a child-grandchild
pair.
Figure 222 shows an example of a group of accounts transferred between
virtual accounts, including all subordinate accounts, as well as a change in
account
2o type, in this instance a primary-child pair transferred as a peer-child
pair.
Figure 223 shows top-edge, front, back, and side views of a generic dynamic
token generation device, With multiple direct and indirect I/O mechanisms.
Figure 224 shows internal component view of a generic dynamic token
generation device.
25 Figure 225 shows the various form factors of dynamic token,generation
devices.
Figure 226 shows communications connections between a clearinghouse,
repository, event timer, and a dynamic token generation device for generating
a
dynamic token.
79
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 227 shows a computer system containing a data processor (CPU), a
communications device, and a storage device with an operating system, account
management software, token management software, and accounts with various
numbers of tokens, communicating with one or more entities.
Figure 22~, shows a computer system containing multiple data processors
(CPU), multiple communications devices, and multiple storage devices, each
with an
operating system, account management software, token management software, and
accounts with various numbers of tokens, communicating with one or more
entities.
Figure 229 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device,
containing an operating system, account management software, token management
software, and accounts with various numbers of tokens, communicating with one
or
more entities.
Figure 230 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device,
containing an operating system, account management software, token management
software, and accounts with various numbers of tokens, including an
account/token
management system encryption engine, communicating with one or more entities.
Figure 231 shows a computer system containing a dedicated encryption
2o engine, at least one data processor (CPU), at least one communications
device, and at
least one storage device, containing an operating system, account management
softwaxe, token management software, and accounts with various numbers of
tokens,
communicating with one or more entities.
Figure 232 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device,
containing an operating system, account management software, token management
software, and accounts with various numbers of tokens, communicating with one
or
more entities, wherein said storage devices contain an integrated encryption
engine.
Figure 233 shows a computer system containing at least one data processor
(CPU), at least one communications device, and at least one storage device,
containing an operating system, account management software, token management
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
software, and accounts with various numbers of tokens, communicating with one
or
more entities, wherein said data processors contain an integrated encryption
engine.
Figure 234 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device,
containing an operating system, account management software, token management
software, and accounts with various numbers of tokens, communicating with one
or
more entities, wherein said communications devices contain an integrated
encryption
engine.
Figure 235 shows a computer system containing a data processor (CPL, a
1 o communications device, and a storage device with an operating system,
account
management software, hierarchy management software, and accounts with various
numbers of hierarchies, communicating with one or more entities.
Figure 236 shows a computer system containing multiple data processors
(CPT~, multiple communications devices, and multiple storage devices, each
with an
15 operating system, account management software, hierarchy management
software,
and accounts with various numbers of hierarchies, communicating with one or
more
entities.
Figure 237 shows a computer system containing at least one data processor
(CPI, at least one communications device, and at least one storage device,
2o containing an operating system, account management software, hierarchy
management software, and accounts with various numbers of hierarchies,
communicating with one or more entities.
Figure 238 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device,
25 containing an operating system, account management software, hierarchy
management software, and accounts with various numbers of hierarchies,
including an
account/hierarchy management system encryption engine, communicating with one
or
more entities.
Figure 239 shows a computer system containing a dedicated encryption
3o engine, at least one data processor (CPU), at least one communications
device, and at
least one storage device, containing an operating system, account management
81
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
software, hierarchy management software, and accounts with various numbers of
hierarchies, communicating with one or more entities.
Figure 240 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device,
containing an operating system, account management software, hierarchy
management software, and accounts with various numbers of hierarchies,
communicating with one or more entities, wherein said storage devices contain
an
integrated encryption engine.
Figure 241 shows a computer system containing at least one data processor
(CPS, at least one communications device, and at least one storage device,
containing an operating system, account management software, hierarchy
management software, and accounts with various numbers of hierarchies,
communicating with one or more entities, wherein said data processors contain
an
integrated encryption engine.
~ 5 Figure 242 shows a computer system containing at least one data processor
(CPL, at least one communications device, and at least one storage device,
containing an operating system, account management software, hierarchy
management software, and accounts with various numbers of hierarchies,
communicating with one or more entities, wherein said communications devices
2o contain an integrated encryption engine.
Figure 243 shows a computer system with six modular software subsystems
including modules necessary to support fixnctionality for communications,
transaction
coordination, user interaction, cryptographic processing, records management,
and
application logic. For each subsystem, commercially available protocols and/or
25 products are listed, any of which may be used to implement the
functionality of that
module. The critical components of the computer hardware are also listed.
Figure 244 shows a single computer configuration of a system with hardware
and software subsystems wherein the data storage is internal to the computer.
The six
subsystems listed are typical of a repository configuration.
3o Figure 245 shows a single computer configuration of a system with hardware
and software subsystems wherein the data storage is both internal and.external
to the
computer.
82
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Figure 246 shows a multiple computer configuration of a system with
hardware and software subsystems wherein each computer has its own internal
data
storage and copies of any or all of the software subsystems. Shared data is
stored on a
common set of external data storage, typical of a fault-tolerant, clustered
configuration.
Figure 247 shows a multiple computer configuration wherein selected
software subsystems are distributed on a network, but acting in a coordinated
fashion.
Figure 248 shows a single computer configuration of a system with hardware
and software subsystems wherein the data storage is internal to the computer.
The
four subsystems shown are typical of a naming system configuration.
Figure 249 shows a single computer configuration of a system with hardware
and software subsystems wherein the data storage is internal to the computer.
The six
subsystems shown are typical of a clearinghouse system configuration.
Figure 250 shows a single computer configuration of a system with hardware
arid software subsystems wherein the data storage is internal to the computer.
The six
subsystems shown are typical of a labeling system configuration.
Figure 251 shows three sample hardware specifications for typical
configurations of a repository computer system identifying a small, large, and
high
availability configuration.
2o Figure 252 shows three sample hardware specifications for typical
configurations of a clearinghouse computer system identifying a small, large,
and
high availability configuration.
Figure 253 shows three sample hardware specifications for typical
configurations of a naming system computer system identifying a small, large,
and
2s high availability configuration.
Figure 254 shows three sample hardware specifications for typical .
configurations of a labeling system computer system identifying a small,
large, and
high availability configuration.
Figure 255 shows a variety of small, large, and high availability
configurations
30 of repositories, clearinghouses, naming systems, and labeling systems
existing in an
83
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
inter-networked configuration using bridges, routers, and concentrators for
networked
communications.
84
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.1 Overview
The present invention provides systems and methods for the management of
cash andlor non-cash asset accounts, and includes associated access, security,
and
transaction processing infrastructures. In addition to offering advancements
in the
state of the art of current systems, this invention offers completely new
systems with
greater capabilities than could be retrofitted into today's existing
infrastructure.
This new infrastructure provides for a unique combination of the preferred
attributes of cash, checks, credit cards, debit cards, ATM cards, money
orders, gift
certificates, traveler's checks, electronic funds transfer (EFT), wire
transfers, phone
cards, postage, event tickets, subscriptions, memberships, coupons, frequent
flyer
points, and other loyalty program accounts. Each account within this
infrastructure
may, if desired, contain a positive or negative balance of a set of specified
currencies
and/or non-cash assets. Non-cash assets can include, but are not limited to:
15 ~ program points (e.g., frequent flyer miles, S&H Greenstamps, MyPoints),
~ incremented counters (e.g., number of visits, uses per time period, total
value of
goods purchased, total value wagered),
decremented counters (e.g., remaining phone minutes, transit tokens, arcade
game
credits, postage),
20 ~ indicator flags (e.g., subscriptions, memberships),
~ coupons (e.g., discounts, benefits), and/or
~ tickets (e.g., concert or show admissions, airline tickets).
Non-cash asset types may be configured as exchangeable/non-exchangeable,
transferable/non-transferable, and/or expiring/non-expiring, or any
combination of
25 these.
In certain embodiments, the advanced asset management system (AAMS) is
capable of three fundamental operations: 1) account management, 2) account
content
management, and 3) transaction management. These embodiments advance the state
of the art in asset management in each fundamental area by being the first
system
8s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
capable of handling each of these three distinct components of a typical
transaction
individually, simultaneously, or in a coordinated fashion. In systems prior to
the
creation of the advanced asset management system, the account, the content of
the
account (most typically an asset), and the transaction were inseparable. An
.RAMS
s that has the ability to manage each component individually affords entirely
new levels
of control and interaction, adds business options to existing commercial
transaction
models, and provides for the creation of completely new transaction models.
7.1.1 Account Management
Particular embodiments of the AAMS offer unique features, including true
unconditional anonymity for account owners without sacrificing security. These
features are afforded because unlike any other financial instrument or asset
management system, the AAMS uses separate objects for account identification,
and
account ownership and control. Thus, system security can be offered in
addition to
account level security, regardless of the ownership and control of an
individual
~5 account, or the type of identification associated with the accounts.
Although some current asset management systems claim to afford anonymity
to account holders, they only offer conditional, one-way anonymity, i.e., the
account
owners must identify themselves during account creation, although that
identification
may be masked during a transaction. However, this approach, by its very
nature, is
2o not truly anonymous since transactions originating from the account can be
traced to
the account owner through the host system.
In a preferred embodiment of an ARMS, complete two-way anonymity (where
the account owner is never identified and is totally unknown to the system,
and where
no account identification is presented during transactions) is the default
condition.
25 However, both types of conditional one-way anonymity, i.e., 1) where the
account
owner is unknown to the system, but the account is identified during a
transaction in
some fashion, or 2) where the account owner is known to the system, but the
account
is not identified, or is somehow masked during a transaction, are available as
user-
selectable options. In addition to having fully anonymous or partially
anonymous (or,
3o conversely, partially identified) accounts, an account can also be
configured in such a
way that users can mask either identities with nom-de-plumes or randomized
aliases,
or mask their accounts with non-identifying labels.
86
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Another advantage afforded by some embodiments of the AAMS is the ability
for account owners to create, destroy, and/or otherwise manipulate any number
of
related sub-accounts, subordinate to their primary account. Using this
inherent
capability, an embodiment of an AAMS allows for a hierarchy of various sub-
s accounts, each designed with user-determined andlor user-defined features
and
constraints. In a typical embodiment, a user could create a series of sub-
accounts that
afford the ability to automate payment of bills, create proxy relationships to
other
real-world accounts, e.g., bank savings account, bank checking account, or a
credit
card account, create linked spending accounts fox a spouse, and create an
allowance
account for a child. It should be noted that unless otherwise specified by the
account
owner, or a person having the right to control a specific account, any account
can take
part in a transaction of any type. Additionally, other account types available
with pre-
defined sets of features allow for the creation of other specific use
accounts, for
example escrow accounts and bid accounts facilitating person-to-person
commerce.
~ 5 In specific forms of certain embodiments of the AAMS, each account can
have its own security features, access codes, and encryption algorithms.
Additionally,
for accounts with a structured hierarchy of subordinate accounts, each
subordinate
account can add additional layers of security on top of those imposed or
inherited
from the superior account. Another feature found in preferred forms of using
virtual
2o accounts is the ability of hierarchically axranged accounts to have
hierarchically
determined encryption and security, i.e., a superior account can always access
and
decrypt a subordinate account or any other account below it in its hierarchy
tree, but
subordinate accounts can not access or decrypt superior accounts. Superior
accounts
can also decrypt the content of any subordinate account.
2s 7.1.2 Content Management
In preferred embodiments of the AAMS, one can manage and manipulate a
wide variety of possible account content. In traditional financial account
management
systems, (as a more inclusive category than "asset" account management
systems),
accounts can typically hold only one type of content. Although public
perception of
3o certain everyday bills might lead one to consider that a phone bill or
electric bill has
more than one type of content in the account, these and other related bills
show two
separate accounts: the item account (phone minutes and kilowatts of
electricity,
8~ n
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
respectively), and the billing account (amount owed). A simple test to
determine if an
account contains more than one type of content is for an end-user to try to
credit and
debit each content type, or convert from one content type to the other
internal to the
account. As is obvious in the preceding examples, an end-user cannot pay for
their
phone bill in "phone minutes", nor can they request cash for 1000 kilowatt
hours
worth of electricity.
In a preferred embodiment, an AAMS is not subject to this limitation. In an
ARMS, multiple types of content can exist simultaneously in the same account,
with
each type able to be independently credited and debited, and where a
conversion or
exchange system exists, able to be changed from one type of content to
another.
Additionally, an AAMS is not restricted to only containing content that
equates with
some measure of worth or value, or in the case of a billing system in the
previous
examples, measures of expenses. An AAMS in a preferred embodiment can also
contain documents, notifications, and other related types of content. Thus, in
one
~ 5 embodiment of this invention, an account not only holds an asset, but may
also hold
documents pertaining to the use of that asset, e.g., a purchase order, and the
funds
necessary to pay the purchase order upon receipt of the corresponding invoice.
In those embodiments wherein the content is specifically an asset, an AAMS
may, if desired, allow an unlimited amount of asset types to be present in an
account
2o at one time. One embodiment of the AAMS can store and manipulate various
assets
themselves, such as cash and frequent flyer miles. Another embodiment can
store and
manipulate representations of various "real" assets, such as deeds for
property or titles
for vehicles. In still another embodiment, both assets, and representations of
assets
can be commingled in the same account. In addition to traditional currencies,
the
25 assets can include several types of non-currencies, including types which
are non-
quantifiable (e.g., discounts), or that carry no intrinsic value (e.g.,
coupons), as well as
representations of these and other types of assets. Significantly, a single
embodiment
may include all or some combination of these capabilities, or many other
combinations of capabilities.
3o Particular embodiments of the AAMS afford an account owner the ability to
specify a set of attributes and constraints on both the types of assets in an
account, and
on the assets themselves. For example, an account can be structured such that
currency of only one selected nationality is allowed to be stored, but the
88
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
representation of the value of these assets is in a different currency, with
the account
retaining the ability to receive transferred funds in any currency, but
immediately
converting them to the required currency. Thus, in one embodiment, the system,
evaluating a constraint set imposed on the subject account examines the type
of
currency being transferred into the account, and then automatically, and as
necessary,
performs a currency exchange at the current daily exchange rate to credit the
transferee in the currency of choice. As an example, a British merchant
receives
payment from a customer in German Marks; the system converts the Marks to
Euros
during the transfer, and stores the assets in the account as Euros, but
displays the
value of the assets in the account in British Pounds at the current exchange
rate.
7.'1.3 Transaction Management
As classically defined, a transaction occurs when one party transfers an asset
to another party, with or without a requirement that something of value be
given in
return. Those transactions in which assets are offered in return for currency,
goods
~5 and/or services represent the family of commercial transactions.
Historically, the
choice of asset, and of the associated asset management system, limited the
transactions in which an individual could participate. Person-to-person non-
commercial transactions have been typically conducted using cash or checks.
Person-
to-business (commercial) transactions have been conducted using a variety of
asset
2o types, including credit and debit cards. However, all of these transactions
have the
limitation that the asset must physically be transferred to another party,
either in
person, or through an intermediary (e.g., checks require banks; credit cards
require
credit card companies and banks). In one embodiment, the ARMS disposes of this
overwhelming limitation by allowing the ownership and control of an asset to
be
25 transferred without requiring the physical transfer of the underlying asset
itself.
Methods and systems which afford transfer of assets without physical delivery
of the assets in and of themselves are new, unique, and non-obvious. Financial
instruments available today appear superficially to offer this benefit, in
that they
somewhat separate the asset from its delivery or access method. However, a
check,
3o credit card, or other related instrument still requires that somewhere in
the financial
food chain, an armored car must move physical assets, typically cash, from one
bank
to another, possibly prefaced with some aggregate transactions) via FedWire or
the
89
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Automated Clearing House Association. The preferred AAMS(s) do away with this
requirement, providing complete separation of the asset, its access/delivery
method,
the ownership or control of the asset, and the ownership or control of the
access/delivery method. Thus the system ~.llows for real-time, transaction-by-
transaction instant settlement.
In conjunction with this fundamentally different model for transferring the
value/worth of an asset, particular embodiments of AAMS(s) also offer several
other
advantages related to the severability of the component pieces of the
transaction.
Since the transaction, i.e., the actual transfer of value, can now be
independent of the
asset and the account containing the asset, it can be given its own set of
attributes and
constraints, which can be independently manipulated by the transactor.
In one embodiment, the transaction can be elected by the transactor to be
anonymous, identified, or masked, with the transaction election independent of
the
ownership or control of the account used in the transaction. In an anonymous
transaction, the system does not keep a record of the target of the
transaction, as
recorded in the source account's transaction history, nor does it keep a
record of the
source of the transaction, as recorded in the target account's transaction
history. This
allows for some unique combinations of accounts and transactions. Consider for
example, an account having anonymous ownership and control, engaged in an
2o anonymous transaction with a second account, also having anonymous
ownership and
control. In this instance, the AAMS would successfully complete the
transaction
without knowing who issued the assets, who received the assets, and once the
transaction was complete, from where the transaction originated, or to where
it went.
In particularly preferred embodiments, other constraints can also be placed on
2s transactions at the discretion of the transactor. These constraints can
restrict the type
of transaction that can take place, the time or date that a transaction will
be initiated or
completed, and/or the types(s) of assets used in the transaction. These and
other
constraints can be preset for all transactions, for a particular type of
transaction (e.g., a
purchase at a registered merchant), or for a particular account. Alternately,
they can
so be dynamically determined before or during a transaction.
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.2 System Elements
In certain embodiments, the system elements of this invention relate to
specific types of attributes and constraints incorporated into traditional
asset
management systems. In other embodiments, the invention relates to new types
of
systems, and associated financial instruments.
In some of the more comprehensive embodiments, the invention can comprise
at least five elements: virtual accounts, account repositories, virtual
clearinghouses,
virtual naming systems, and virtual labeling systems. Each of these elements
is
discussed in general, along with their component parts and their relationships
to the
other elements and their respective component parts, in the following
sections. Other
elements of interest common to these include: access methods & communications
devices, constraints & attributes, dynamic tokens, and agents, alerts &
triggers.
7.3 Virtual Accounts
Although only one of many types of accounts that can be used with an RAMS,
15 virtual accounts offer certain advantages over traditional accounts due to
their lack of
legacy baggage and certain inherent characteristics. The following sections,
though
focused on virtual accounts, contain numerous embodiments that offer
advantages to,
and enhanced operation of, traditional accounts when incorporated as part of
an
AAMS that are readily apparent to those skilled in the art.
2o In certain of its aspects, a virtual account may have a private portion and
a
public portion. The private portion may contain zero, one or more private
accounts;
the public portion may contain one or more public accounts. Each private and
public
account within the virtual account is a sub-account of the virtual account.
Private
accounts, where present, connect to public accounts through a uni-directional
link
2s called the public/private account connection interface (PPACI). Through
this one-
way connection, a private accounts can be cognizant of the actions of the
public
accounts to which it/they are connected, while completely withholding from the
public accounts all information regarding the private account(s).
In certain embodiments, each public account in the public portion is
3o connected, either directly or indirectly, to at least one private account
in the private
portion. All private accounts are managed by the AAMS; public accounts are
91
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
administered by the AAMS, but managed by end-users. Persons outside the ARMS
never come into contact with the private portion or the private accounts, and
due to
the existence of the PPACI, never know any details about the private accounts
connected to their public accounts.
s Each account of the virtual account has its own token(s). A token is a
symbol(s), most typically an alphanumeric string, used to uniquely represent
an
underlying account. It is not the account number, although it can be the same
as the
account number. An account number may have multiple tokens, each of which may
represent the participation of its particular account in a transaction.
Private accounts have private token(s); public accounts have public token(s).
Tokens may be any form of symbol or set of symbols. In the embodiments
illustrated
in the drawings, the primary token for each private account is referred to as
a Virtual
Account Number (VAN). Likewise, in the embodiments shown in the drawings, the
primary token for each public account is referred to as a Virtual
Instantiation Number.
~ 5 A VIN is used to associate a transactions) with a particular public
accounts) within a
given virtual account.
In specific embodiments, a virtual account may consist of at least two sub-
accounts, one private account, held in the private portion, under the control
of the
AAMS administrator, and at least one public account, held in the public
portion,
2o under the control of an end-user. Thus, the virtual accou~lt would have at
least two
associated tokens: at least one private token, used by and for the private
account and
the advanced asset management system, and at least one public token, for
access to
the public account(s), its/their content, and the end-user accessible command
functions of the RAMS.
25 In other embodiments end-users may establish a plurality of accounts within
the public portion of the virtual account. Thus, the virtual account would
have at least
one private account, at least one primary public account, hereafter the
primary
account, and may contain an unlimited number of other public accounts, in some
fashion subordinate to the primary account, and hereafter generically referred
to as
so public sub-accounts or more simply, sub-accounts. Each public account,
whether a
primary account or a sub-account thereof, has its own unique public token(s),
and
92
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
hence, a unique VIN. The VIN acts as the access identifier for both
transaction
activities and command functions.
The term "public account" is used herein to distinguish primary and other sub-
accounts that are contained within the public portion of the virtual account
from those
s other sub-accounts that may exist in certain embodiments in the private
portion of the
virtual account. Access to the private portion and all private accounts is
denied to
even those who own or control a public accounts) within the virtual account.
Access
to the private portion is limited to the administrators of the AAMS. However,
as will
be explained further below, access to so-called public accounts may also be
restricted
in various ways.
7.3.1 Virtual Accounts: An Analogy
A fairly useful analogy for examining virtual accounts would be that of a
driver in a delivery truck carrying a package to be delivered. The truck is
the virtual
account, consisting of a private portion, the cab, and a public portion, the
cargo bay.
~ 5 Internal to the private portion is a private account, the driver, whereas
in the public
portion a package would be a public account. Each "account" on the delivery
truck
has its owl private token (the driver's employee number), or public token (the
package's address), which uniquely identify each, just like the VANS and VINs
of the
virtual account.
Warehouse = AAMS
Delivery truck= VA
Cab = Private portion
Driver = Private accounts)
Cargo bay = Public portion
Package = Public accounts)
2o A package in the back of the truck exists as a conditionally independent
entity,
just like the public accounts) of a virtual account. Although they require a
driver (the
private portion) to get them on their way, they do not interact directly with
the driver
in other than a loosely coupled manner.
A package in the truck, as related to a public account, can be a primary
25 account, and as such the head of a hierarchy of other public sub-accounts,
just as a
large package can actually be a pallet of items bound in shrink wrap destined
for the
93
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
same location. The pallet controls the general flow of the contents of its
subordinate
packages, just as the primary accounts) can control its/their subordinate
account(s).
7.3.2 Account Creation
Most preferred embodiments of the ARMS share common steps with regard to
creating accounts, with differences dependent on whether the account is a
traditional
account or a virtual account. Traditional accounts even when enhanced with
certain
features found in various embodiments in this invention, axe typically
governed by the
legacy system in which they exist, which includes rules governing account
creation.
The creation of virtual accounts, one of the preferred embodiments of an AAMS,
depends on whether the account created is a virtual account proper, a private
sub-
account of a virtual account, or one of the various public sub-accounts of a
virtual
account. A virtual account is a container that may hold zero, one or more
private sub-
accounts, and at least one public sub-account, along with at least one token
for each
account so created. End-users do not have access to the virtual account in its
entirety;
end-users are restricted to public accounts.
7.3.2.1 Private Account Creation
Virtual accounts can have any number of private accounts, which can be
arrayed in a variety of configurations and hierarchies. In most embodiments
private
accounts, when present, are the administrative accounts used by AAMS system
2o administrators to manage virtual accounts. As typically configured, private
accounts
contain status information regarding their associated public accounts, as well
as
domain and public account hierarchy information. However, in certain
embodiments,
private accounts can be used to set up a double-blind system where all account
information is hidden even from ARMS systems administrators. For those
embodiments in which zero private accounts are used, the private tokens) and
the
administrative duties of the private accounts are assigned to the virtual
account itself.
7.3.2.2 Public Account Creation
Account holders can create a wide variety of public accounts. Most
embodiments include a number of pre-defined classes and sub-classes that can
be
94
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
used as-is, or altered to suit the needs of a particular account holder.
Preferred
embodiments also include means for user-defined classes and sub-classes.
The most common type of public account is the primary account. Primary
accounts can be created at the time of creation of a virtual account, or
through the
transfer or modification of an existing subordinate public account.
For the case of a newly created virtual and public account, most embodiments
of this invention afford some portion of the following steps within the AAMS:
1 Create a virtual account
2 Assign a virtual account number to this account
3 Create zero, one, or more private accounts, as appropriate
for the system of record
4 Register the VAN (a first private token) within the AAMS
Create a public account
6 Link this public account to the private account
7 Create or generate a VIN (a public token)
8 Assign the VIN to this account (the account number and VIN
may or may not be the same
depending on AAMS configuration)
9 Register this public account as either a primary account or
subordinate account
Following the registration of the public account type, slightly different
actions
take place depending on the class of account created. For primary accounts,
most
embodiments include some portion of the following steps:
Assignment or selection of a set of default account attributes
and constraints
11 Registration of ownership as anonymous, identified, or
masked
12 Assignment or selection of a set base content (asset)
types
13 Assignment or selection of a set of default content attributes
and constraints
14 Creation of an initial primary account domain
Subordinate accounts, unlike primary accounts, are built from either system-
defined or user-defined templates. As such, when they are created, they most
usually
inherit from the parent account some minimum number of attributes and
constraints
consistent with their class, relationship to their parent account, and their
assignment or
~ 5 membership in a particular domain. For both primary and subordinate
accounts, the
AAMS then completes their creation by performing the following steps, as
necessary:
Balance adjustments, for any initial transfers of assets,
as appropriate
16 Creation of an access code or authenticating token, if
requested
17 Account activation
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.3.3 Account Ownership & Control
Each of the various public and private accounts within an AAMS can have
different ownership and control attributes, and can at the discretion of the
end user be
anonymous, identified, or masked. One major distinction of one of the
preferred
embodiments of the RAMS is the ability to create and manage truly anonymous
accounts. Anonymous is defined as lacking individuality, distinction, or
recognizability, e.g., the anonymous faces in the crowd. To provide a truly
anonymous account, an account management system should offer the following
feature: the system should maintain no information, or at least insufficient
information, to identify the account owner, or a person exercising control of
a
particular account. Thus, even if a transaction were traced back to its
source, and the
account uniquely identified, the ownership or control of that account would
remain
anonymous.
In most preferred embodiments, ownership and control of any private accounts
and their VANS (the private tokens) of a virtual account) are anonymous,
unidentified, and shielded within the AAMS, remaining unknown even to the
various
public account owners. Each public account (and VIII however, can, at the
discretion of the individual account owner, be anonymous, identified, or have
its
identity masked. The level of identification is left to the discretion of the
account
owner, and can include the full suite of standaxd identifying information
(name,
address, tax identification number, etc.) or some portion thereof. Should an
account
owner so desire, the account can be masked with a substitute identity, either
randomly
generated or of the owner's choosing, not unlike the electronic personas or
avatars
used for on-line games and chat rooms. An account so masked can also select
the
identity of a real or fictitious person (e.g., Huckleberry Finn), even if the
account is
not owned or controlled by that person. Masked accounts do not require a real,
verifiable identity to be held by the system; accounts can be masked at the
time of
account creation.
7.3.4 Relationships & Identification
3o In certain embodiments of an AAMS, all relationships are uni-directional.
Thus a first account, with a relationship of a given type to a second account,
does not
require nor imply the existence of a relationship from the second account back
to the
96
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
first account. Nor does it imply that a relationship from the second to the
first, should
such a relationship independently exist, be of the same type as the first
relationship.
In other words, all relationships can exist from source to target, with no
requirement
for feedback. As an example, private accounts preferably have one-way
relationships
with public accounts, with no return relationship allowed.
In the most common embodiments, a private accounts) likely has/have
relationships only with a single dominant public account, the primary public
account,
more simply referred to hereafter as the primary account. Although other
embodiments may have a one-to-one relationship, i.e., one private account for
each
1 o public account, or other variations wherein a private accounts) hasJhave a
unique
individual relationship with each public account, the effects mimic those
wherein a
single private account is connected to a single primary account through a
single
publiclprivate account interface, particularly when the concept of domains is
introduced.
~5 For the public accounts of an ARMS, at least four generic relationships
with
other public accounts can exist:
1) primary account to primary account
2) primary account to sub-account
3) sub-account to sub-account
4) sub-account to primary account
Since many embodiments will have only one primary account, relationships
from one primary account to another primary account will often denote a
relationship
between two distinct virtual accounts, whereas the other types of
relationships can be
2o internal to a single virtual account or between multiple virtual accounts.
Independent of both the ownership and control of an account, and its location,
the relationships between accounts can be established as anonymous,
identified, or
masked. The following table illustrates composite independent relationships
that may
exist between two accounts, a source account, ABC, and a target account 123:
Source Relationshi~to Target Relationshi~toSource
ABC Is anonymous 123 May be anonymous to ABC
May be identified to ABC
May be masked to ABC
ABC Is identified 123 May be anonymous to ABC
May be identified to ABC
97
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
May be masked to ABC
ABC Is masked 123 May be anonymous to ABC
May be identified to ABC
May be masked to ABC
Note: the relationships in the table are independent of whether the source or
target is a primary or sub-account, and are also independent of the specific
classes) of
accounts) represented by primary and/or sub-accounts.
As stated earlier, ownership and control are independent of the type of
relationship (with respect to anonymity, identification or masking) that an
account can
have. Thus combining account type and relationship type yields the following
additional examples of relationships:
Anonymous account:
~ Anonymous relationship: No information about a transaction is given,
1 o although the occurrence of a transaction can be inferred from changes to
the
contents, attributes, or constraints of an account
Identified or masked relationships: a transaction is referred to as
originating
from an "anonymous" account, e.g., "$100 was added to your account from an
anonymous source"
15 Identified account:
~ Anonymous relationship: No information about a transaction is given,
although the occurrence of a transaction can be inferred from changes to the
contents, attributes, or constraints of an account
~ Masked relationship: a transaction is referred to as originating from "an
2o account masked as ~~~XX", where X~~~XX is the number or label used to mask
the account, e.g., "$100 was added to your account from an account masked as
X~~XX"
~ Identified relationship: The account is fully identified to the limits
defined by
the end-user. Account identification can be determined on a case by case basis
25 for each relationship, e.g., in one relationship the identification
consists of
account number, owner's name, and cell phone number, in another the only
information offered is the account owner's name.
Masked account:
~ Anonymous relationship: No information about a transaction is given,
30 although the occurrence of a transaction can be inferred from changes to
the
contents, attributes, or constraints of an account
98
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
~ Masked relationship: a transaction is referred to as originating from "an
account masked as XX~~~", where ~~:~~ is the number or label used to mask
the account, e.g., "$100 was added to your account from an account masked as
XXXX". Thus, transaction masking can be used simultaneously with account
ownership and control masking. An example of such simultaneous use would
be an account that has had its identity masked (account "AAAA" masked as
"BBBB") which chooses to engage in a masked transaction, the end result
being "BBBB" is referred to as "XX:XX" where "XXXX" is new the
transaction specific token
~ Identified relationship: a transaction is referred to as originating from an
account with no mention that a mask has been applied, e.g., "$100 was added
to your account from account ABC"
In most preferred embodiments all of the relationships from a private account
to a public account are anonymous, with no information released to the public
account
~ 5 concerning any input or interactions from the private account.
Referring back to the delivery truck analogy, the same scenarios apply. Each
package has certain inherent qualities pertaining to its ownership and
control, and the
transmission and receipt of the package (the relationships that the package
engages in)
have separate qualities. A package can be an anonymous package (no description
on
2o the package), it can be sent anonymously (no return address), or it can be
received
anonymously (packages sent c!o "resident"). In a similar fashion they can be
fully or
partially identified (wedding invitation, from John to Jane), or masked.
7.3.5 Information Disclosure
In most common asset management systems, certain rules apply to the release
25 of information. Within these systems however, little thought has been given
to how
these rules can and should be altered to afford the flexibility needed to
manage a user-
configurable hierarchical account structure as provided within an AAMS. In
most
embodiments, for each account in an AAMS, the system tracks information,
attributes, and disclosure constraints for the account itself, for ownership
and control
30 of the account, for the content of an account, for the connections that the
account
makes, for its transactions, for its transaction history, and for other end-
user and
system specified objects. For each particular object, the account owner can
designate
an extent of information release xanging from none to complete disclosure.
A trivial example is relationships, wherein an identified account can be
35 identified by its account number, or an account number and owner selectable
99
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
identifier. The system also allows more complex situations by allowing the
ability to
selectively disclose information on certain objects based on a set of rules
imposed by
the account owner. For example, a person using an account to hold a hotel
reservation would want the hotel to know that their account had a balance
sufficient to
pay for the intended stay, but might not want to show his current balance,
available
credit limit, credit rating, or the name or address associated with the
account.
7.3.6 Parent-Child Relationships
The most common relationship type for sub-accounts within an ARMS is the
parent-child relationship, in which one account assumes a superior position,
and the
other, a subordinate one. Parent-child relationships do not imply any
preference
toward an anonymous, identified, or masked relationship between the accounts -
the
accounts are simply involved in a superior-subordinate logical connection. In
most
embodiments however, the subordinate account will be identified to the parent
account, but the parent still has the option of being anonymous, identified,
or masked,
~5 vis-a-vis the child account. However, embodiments are possible in which the
parent
is not directly aware of every child attached to it, and in which certain
child accounts
may be anonymous, identified, or masked to their parents. Additionally, in the
AAMS, the logical connections binding parent-child relationships may be long-
lasting
or temporary, at the discretion of the superior account.
20 7.3.7 Domains
In certain embodiments, the AAMS provides for the creation of a unifying
management structure, called a domain, through which domain controllers may
perform command and control operations on groups of selected accounts. The
size,
number, location, and parameters of a domain or set of domains, along with the
25 accounts bound within a particular domains) can be established by the ARMS,
by the
user, or both. The following table shows the most common forms of these
embodiments with respect to the types of accounts held within a particular
domain or
set of domains:
loo
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Number of DomainsDomain Tune Allowed Account
Types
One Inclusive All
Multiple Inclusive All
One Private Private
Multiple Private Private
One Public Public
Multiple Public Public
Note: use of a particular domain types) does not preclude the simultaneous use
of
another domain types) within a single virtual account.
The first two domain types shown, that of inclusive domains containing any
and all accounts, represent a conceptually simple condition of limited
usefulness. In
the first case, one domain contains all public and private accounts, and the
domain
structure requires that one account be selected as the domain controller,
tasked with
administering the domain. Although any account can serve as the domain
controller,
private accounts can not be seen nor identified by public accounts. Thus,
although
such a domain might be used by a systems administrator, an end-user would be
unable
to identify or access the private accounts. This restricts the usefulness of
any domain
containing public and private accounts.
In the second case, each account, public or private may have its own domain.
Although this is one of many possible variations, its use surrenders the
advantage of
creating an obj ect whose purpose is to allow command and control activities
on a
~ 5 "group" of related accounts.
Use of restrictive domains is much more attractive. Certain embodiments of
private domains, containing only private accounts, allow a systems
administrator to
conduct coordinated actions on groups of linked private accounts. Similarly,
embodiments having public domains containing only public accounts allow end-
users
2o to perform coordinated management and oversight of all accounts accessible
to end-
users. Thus, most preferred embodiments will leverage the use of one or more
public
domains, which are configured to suit an end-user's personal preferences.
Regardless of the type or types of domains) selected, one account within a
domain should be designated as the domain controller. The domain controller
25 account is allowed to control the operations and operational
configurations) of
accounts within its domain. For those instances wherein the domains are nested
(e.g.,
lol
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
one domain completely contained internal to a larger domain), the domain
controller
of a higher level domain can exercise control over all nested (subordinate)
domains.
In the most typical embodiment, a virtual account will have one private
account, one primary public account, and an indefinite set of other public sub-
s accounts, all in some way subordinate to said primary account. The set of
all public
accounts will commonly constitute the public domain of that virtual account,
hereafter
referred to as the account domain, or more simply, the domain. In such
embodiments,
the primary account is the default domain controller, and as such, can
determine
whether other domains, nested or otherwise, are allowed. If nested or other
domains
are allowed, the primary account designates which account within a subordinate
domain will become the subordinate domain's domain controller. At all times,
the
primary account can exercise superior control of all accounts, and all domains
so
created.
7.3.8 Account Encryption
~ 5 Encryption is a security feature which will be found in most preferred
embodiments of the AAMS. AAMS data (both system data and account data) can be
maintained in encrypted form in transit, at rest, and/or during processing,
and can be
encryptedldecrypted prior to its transmission, storage, and/or processing. In
certain
particular forms of these embodiments, multiple layers of encryption, e.g.,
stored
2o encrypted data that is encrypted a second time during transmission, are
also
supported. ARMS data not residing in the AAMS, or data that is shared between
the
AAMS and some other entity, may be encrypted by third parties.
Encryption services can be provided in hardware, software, or a combination
of hardware and software. The encryption engines may be internal or external
to the
25 RAMS computer system, or may be included within one or more of its various
subsystems, such as its data processor(s), storage device(s), communications
devices)
or other sub-systems. Encryption and decryption duties can be split between
multiple
encryption engines without loss of security. Use of a particular
encrypting/decrypting
system does not preclude the simultaneous use of other encrypting/decrypting
3o systems.
The ARMS data encrypted can be all inclusive or, more often, specifically
applied to particular subject matter or objects within the system, e.g.,
account
l02
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
ownership and control information. Certain preferred embodiments afford the
ability
to perform hierarchical encryption on various selected accounts within a
domain, and
upon various selected elements within these accounts. This unique feature of
the
ARMS offers improved flexibility by allowing superior accounts the ability to
access
subordinate accounts and subordinate account content without having to share a
PIN,
password, or other authenticating token. The phrase "PIN, password, or other
authenticating token", more simply hereafter "authenticating token", refers to
any
object that is used to set, or is evaluated by, security mechanisms in the
AAMS and/or
in any of its physical or logical extensions.
For example, a family consisting of a husband and wife with two children
establishes a single virtual account. The husband and wife each create sub-
accounts
of their own to track their individual spending, but configure them as peer
accounts to
share a common balance. The husband and wife can each use a different
protection
mechanism, without changing the encryption scheme on their account, such as a
PIN
for the husband and a fingerprint biometric for the wife. The parents
distribute
weekly allowances to sub-accounts established for each child, separately
protected by
passwords created by each child. As subordinate accounts witlun a hierarchical
encryption scheme however, the parents will have the ability to "rescue" their
children's accounts should they lose or forget their passwords.
7.3.9 Account Classes
Various embodiments of the AAMS allow creation of certain pre-defined
classes of subordinate public accounts. Creation and use of these classes can
simplify
use of the AAMS to resolve many common kinds of transactions. However, any
account within the AAMS can be configured to take the place of any other
identified
class. Additionally, creation and use of these predefined classes does not
preclude
creation of other user-defined sub-account classes, through either
modification of the
existing classes or the creation of new classes or sub-classes.
In most embodiments there are six major classes of subordinate accounts that
can be generated:
1 Child
)
2) Peer
3) Escrow
4) Bid
103
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
5) Gaming
6) Proxy
Additional forms of these embodiments allow for the creation of these and
other
subordinate accounts, as well as specific sub-classes of certain of these
classes, and
user-defined classes and sub-classes.
As has been stated above, the primary public account is called the primary
account. A primary account preferably has dominant control over all
subordinate
accounts established at all levels within its domain. As the dominant account,
the
primary account owner can "cancel", suspend the activity of, and/or modify the
rules
and controls on: any particular subordinate account; on a particular level,
group,
branch, sub-domain; and/or on all subordinate accounts within the primary
accounts
domain. The primary account owner can also overwrite and/or reset the
authenticating token used for any of the accounts or any object within any of
the
accounts within its domain.
Primary and subordinate accounts can be linked together in a variety of ways
to achieve unique configurations. In certain embodiments virtual accounts can
be set
in a hierarchical fashion, with the primary account acting as a parent
account, and
several levels of subordinate accounts, e.g., child, grandchild, and great-
grandchild
accounts. In certain other embodiments an authorized subordinate account at
one tier
in the hierarchy, allowed to act as a parent account, can securely generate
new
subordinate accounts at a lower tier within the primary account's domain.
2o The rules and controls for subordinate accounts are preferably inherited
automatically from the paxent's account upon creation of the child account.
Inherited
rules and controls provide a skeleton for the attributes, constraints, and
other objects
that define each account within the domain. Upon creating a subordinate
account, the
parent account owner can choose to leave the inherited rules and controls "as
is" or
modify them in any way the parent sees fit, including adding rules and
controls.
Should the ownership or control of the subordinate account later be
transferred to
another person or entity, the transferee can modify the rules and controls,
and/or can
add new rules and controls to the constraint set governing the subordinate
account, but
can in no case make the constraint set less restrictive than that imposed by
its parent
account.
104
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
As a simple example, consider a parent account which creates a subordinate
account and imposes two constraints: 1) that the account has an outbound cash
transaction limit of $50 per day, and 2) that the account's outbound transfers
axe
restricted to US dollars. These constraints:
~ Only pertain to cash transactions
~ Only cover transactions that are outbound, and does not place any
constraints
on in-bound transactions
~ Specifies that the total amount of all outbound cash transactions, including
all
purchases, transfers, etc., can not exceed $50 daily
~ Does not specify a maximum or minimum transaction amount
~ Does not make any provisions for carrying forward any unused balance, i.e.,
if
the first day's transfers only equaled $40, the following day still has a
maximum limit of $50, not $60
Does not prohibit the account from containing non-cash assets, but does
prohibit the outbound transit of non-cash assets
At some later time, the control of the subordinate account is transferred to
another person or entity, who attempts to impose a spending limit of $400 per
week
on the transferred account. Various embodiments of the ARMS allow for
different
configurations of the internal constraint engine. Thus, depending on the
programming
of the constraint engine in the AAMS, there are two possible outcomes.
In the first instance, the AAMS might be configured such that this constraint
is
allowed, in that a limit imposed on a per week basis is not of the same
quality as that
of the original per day constraint. Thus, both constraints could be imposed,
with the
outcome that the second constraint could never be reached since the initial
constraint
($SOlday) yields a maximum possible weekly spending limit of only $350.
In the second instance, the AAMS could alternately be configured to review
constraints that are imposed along related dimensions, performing the
necessary
conversions to guarantee that the constraints do not overlap or conflict. In
the above
example, both constraints contain the following identical dimensions: 1)
content (US
3o dollars), 2) transaction (limitation on type or volume), and 3) time (days
or weeks). In
this particular instance the AAMS could convert the requested second
constraint into
terms which provide a comparison to the first constraint. As a result the
system
would determine that the second constraint is less restrictive than the
inherited
los
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
constraint (a $400/week limit vs. the maximum possible limit of $350/week) and
thus,
rej ect it.
An authorized subordinate account, acting as a parent, can preferably create
additional subordinate accounts beneath it. The rules and controls previously
established on this first subordinate account by its parent account, and any
new rules
and controls added by the first subordinate account owner, are in turn
inherited by its
subordinate accounts. The combined set of rules and controls subsequently
inherited
by these "grandchild" accounts represent maximum values that cannot be
surpassed,
although more restrictive rules and controls can be established, or additional
rules and
controls placed, either by any parent or grandparent account, or by the
individual
grandchild account owners.
A parent account can preferably modify the rules and controls on any of its
subordinate accounts within its domain at any time. Preferably, the parent
account
can also decide whether these modifications will be instantly applied to any
~ 5 grandchild accounts, either by over-writing existing restrictions, or, if
the current
restrictions are more severe, leaving the existing restrictions intact.
7.3.9.1 Child Accounts
The most common type of subordinate account found in several embodiments
is the child account. Usually, a child account is nearly identical to the
parent account
2o that spawned it, except, as noted previously, that it maintains a
subordinate position
relative to its parent account with respect to certain aspects of the rules
and controls
that can be imposed upon it. Typically, parent and child accounts, although
related,
maintain separate account balances, and likewise have separate credit and
debit
histories recorded. However, a parent account usually has complete cognizance
of all
25 account transactions and account content of its child accounts. Child
accounts are
commonly established with an automatic timed credit/debit relationship from
their
parent account(s), e.g., on a monthly basis a fixed amount is transferred from
the
parent account to the child accounts. An ARMS can, if desired, be configured
and
established such that child accounts have one-time, sporadic, or automated
asset
3o transfers.
106
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.3.9.2 Peer Accounts
Primary and subordinate accounts within certain embodiments of the ARMS
can also be set up in a peer-to-peer relationship, with a primary account and
multiple
co-equal accounts. Preferably, although credit and debit transactions can be
recorded
individually against an appropriate peer account, all accounts in a peer-to-
peer
relationship can draw from a shared cash balance for all outbound (debit)
transactions,
and credits to any of the accounts can likewise be accumulated in a
consolidated
balance. '
Peer-to peer relationships are established when a first account creates or
1 o modifies a relationship to a second account. This first account becomes a
"first
among equals" account with respect to governing the functioning of its peer
set. The
owner of this first account can establish the rules and controls on all peer
accounts
within its set. These restrictions are inherited by any subordinate account
created
beneath any peer account within this set. Each individual peer account owner
can
15 place more restrictive rules and controls on its own account or on any
child accounts)
created beneath it, but can not make these rules and controls less restrictive
than those
established by the first peer account in the same peer-to-peer set.
7.3.9.3 Escrow Accounts
In certain embodiments an AAMS can include a virtual escrow account which
2o can facilitate or conduct escrow transactions. An escrow transaction
generally
comprises an exchange of goods, services, cash, or other non-cash assets
between two
or more parties with an independent party confirming the exchange and
transferring a
guaranteed payment. However, this requires the existence and willingness of a
third
party to facilitate or conduct the transaction, usually for a fee. Most
embodiments of
2s the AAMS overcome this limitation by allowing the creation of same-party
escrow
accounts to facilitate the transfer of assets. These and other embodiments can
also be
configured for third-party escrow transactions.
An escrow account within an RAMS will ordinarily require the creation and
maintenance of at least two unique authenticating tokens, one for a first
party, and at
30 least one other authenticating token for a second party to the transaction.
Use or
emplacement of the second authenticating token causes the ARMS to restrict
access
to and manipulation of the escrow account by any party, regardless of account
log
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
ownership or domain location. In this way, the second party has a guarantee
that the
escrow account will be locked and secured over the course of the transaction.
Virtual escrow accounts can be created to accommodate transactions involving
any number of participants. Various forms of these embodiments require an
authenticating token for each participant, whereas other forms require the
placement
of only two authenticating tokens, with other authenticating tokens being
optional.
These authenticating tokens represent mufti-party locks on the escrow
accounts.
In addition to the placement of mufti-party locks on an escrow account,
escrow accounts also contain certain standard attributes and constraints that
may be
set or established at the time the account is created. Examples of typical
attributes
and constraints are: delivery date, acceptance date, rejectionlreturn date,
expiration
date, shipping ticket confirmation, and certification of goods/services.
Thus, in a typical scenario, two parties wishing to conduct a transaction will
first agree to a set of conditions, implemented through incorporation of a
specific set
~ 5 of attributes and constraints on the escrow account. Upon reaching
agreement, one of
the parties creates an escrow account conforming to these conditions and locks
it with
an authenticating token. The second party can then review the conditions
established
by the escrow account to insure that they meet the agreed-to conditions. If
they do,
and if the second party still wishes to proceed, the second party then places
its own
2o authenticating token on the account and transfers control of the particular
assets to the
escrow account.
Internal to the AAMS, the creation of the second authenticating token causes
the system to lock the escrow account from fixrther manipulation until the
agreed
terms are met, until such time as they expire, or through the cancellation of
the escrow
25 account by mutual consent of all parties involved. The AAMS, using agents,
alerts,
triggers, and other mechanisms, evaluates the terms and conditions set forth
in the
escrow account. If the terms are met, the assets are transferred to the
appropriate
parties as set forth in the escrow account. If the terms are not met, or if
the parties
decide to cancel the escrow, then the assets revert to their original owner.
Escrows
3o can in certain embodiments be established with mutual or single party
cancellation
conditions, although in most instances a "seller" would restrict a "buyer"
from
unilateral cancellation after a particular date, such as after the product has
shipped.
l08
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
In addition to standard escrow accounts, certain embodiments of the AAMS
also allow for the creation of other sub-classes of escrow accounts, including
obligation accounts, reserve accounts, and credit accounts, to name a few.
Obligation accounts are most typically used as a means to automate
guaranteed timed release of future payments. The future payment is not
necessarily
guaranteed by the payee, and may in fact be an LO.U. Additionally,
escrow/obligation accounts may require that the receiver meet certain preset
criteria
prior to the transfer of funds. An obligation account could for example be
used by a
government agency working with a company on a fixed or variable delivery
contract.
1o Often, such a contract will have various payment release mechanisms,
including such
criteria as hours worked and milestones met. Using a hierarchy of virtual
escrow
accounts, a contract manager could establish certain escrow/obligation
accounts that
would pay out funds based on milestones met, while others would pay according
to
hours worked. These accounts could operate automatically, moving funds from
~ 5 specific government accounts only as needed, and automatically
transferring them as
appropriate, based on attributes and constraints established by the
government's
contract administrator, as evaluated by the AAMS.
A more complex use of escrow and obligation accounts involves
representations of commodity contracts. For example, a commodity delivery
contract
2o is negotiated with a supplier for delivery on an as-needed, as-consumed
basis, of a
commodity such as heating oil. The contract may have complex terms requiring
the
vendor to deliver heating oil on a monthly basis to each of several thousand
tanks on a
corporate campus or government facility such as a military base. A fixed price
for the
heating oil might not be negotiated in the case of a long-term contract
because the
25 price of the oil is based upon globally fluctuating commodity prices for
crude and
refined oil products. The contract for the oil would typically be written to
reference a
not-to-exceed (NTE) total dollar value within a specified range, with an
initial price
per unit of measure. The contract would contain an escalation (or deflation)
formula
that would be used to adjust the price periodically based on an identified
index such
so as a futures market. The formula might also contain caps that limit the
maximum
amount of increases or decreases during each evaluation period. The obligation
amount required to fund a contract with a fluctuating unit price is riot
fixed, but rather
fluctuates over the duration of the contract.
109
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
In this example, the obligation account can contain the formula used to
calculate the variable liability incurred by delivery of heating oil at
specific dates,
while "oil" escrow accounts can store digital records of the assets (oil)
consumed and
delivered. As the oil is shipped and consumed, the oil escrow account
automatically
settles based on the use and delivery factors agreed to by both parties, with
the
required funds being transferred to the obligation account. The obligation
account,
upon receipt of the asset information, uses its internal formulas to calculate
payment
required, and automatically causes funds to be transferred from a funds source
account to its payment accounts, or more likely than not, directly through to
the
suppliers' virtual accounts.
An escrow account established as a reserve account can mimic some actions of
a credit card or other line of credit. For example, consider the act of
reserving a hotel
room or rental car. To "hold" the reservation, the hotel will normally request
proof of
ability to pay. Today that proof is a line of credit, typically from a credit
card, where
the credit limit or available balance equals some percentage of the estimated
charges
or fees, and the credit card company offers some guarantee of payment.
However, by
its very nature, this precludes people who wish to conduct cash transactions,
or those
without the necessary line of credit, from participating in such reservation
systems.
With a virtual escrow account established as a reserve account, any person
2o with assets convertible to the required type can participate as if they had
a guaranteed
line of credit. The escrow/reserve account allows for funds to be reserved to
make a
future payment. At the time the reservation is secured, the ARMS, upon
authorization
from the virtual account holder, creates a temporary escrow/reserve account,
subordinate to their primary account or some other designated account within
their
domain.
It should be noted that embodiments are possible in which the constraint and
attribute set of any class of account in the AAMS could be configured to serve
as an
escrow/reserve account. However, inclusion of a standard sub-class of
escrow/reserve
accounts permits automated creation of such accoLUZts without undue end-user
input.
3o Additionally, use of escrow/reserve accounts for reserve transactions can
be
automated, such that any time an account is to partake in such a transaction,
an
escrow reserve account is created, and funded with the amount appropriate for
that
particular transaction.
llo
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
When used as a credit account, an escrow/credit account can if desired be set
up to "draw down" from a line of credit established through some other payment
mechanism. The escrow/credit account need not contain any assets itself, but
has
access to the value and use of some quantity of assets. As assets are used by
the
account during normal transactions, the value of the available line of credit
it
decreased.
Escrow/credit accounts are important financial instruments in that they may be
used when it is desired not to commit the base assets until the transaction
completes.
Unlike a traditional escrow account (which contains the assets required to
complete a
transaction), an escrow/credit account simply guarantees that the assets are
available
in the quantity required to complete the transaction. Based on certain
constraints
established by the parties to the transaction, and the acceptance of the
transaction by
all parties concerned, the ARMS, at the appropriate time, automatically
transfers the
requisite assets into the escrow/credit account from the designated sources)
for
~ 5 disbursement as required.
7.3.9.4 Bid Accounts
Another class of subordinate accounts found in several embodiments are bid
accounts, of which there are two major sub-classes, "request" accounts and
"offer"
accounts. Request accounts are accounts used by those requesting that other
2o participants bid for the right to take part in a transaction devised by the
requesting
party; offer accounts are for entities who wish to compete for the right to
participate
in a bid transaction that is being requested.
Bid accounts, and their associated bid pools, facilitate situations in which
multiple parties are vying for the right to take part in a transaction. Bid
accounts are
25 usually created with a fixed duration life span, during which the bid
account and its
associated agents, alerts, and triggers, can in certain embodiments provide
innovative
services to a prospective bidder based on constraints invoked when the account
was
created. Some of the standard constraints include: current bid price, maximum
allowed bid price, bid price increase/decrease increment, and bid account life
span.
3o Thus, in preferred embodiments, a person using a bid account to make a bid
at an
auction site would have the advantage that his bid could be automatically
increased,
within allowable preset limits, an advantage not provided by standard credit
cards or
111
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
other line of credit accounts. Additionally, the bid account could be set such
that it
causes messages to be sent to the account owner advising the owner of the
value of
the currently winning bid, and asking fox permission to raise or lower a bid.
Bid
accounts can be secured by dynamically created escrows or obligations than
insure
that a bidders) is/are sincerely intending to settle the offer placed if their
bids) is/are
deemed a winner.
Bid accounts work in conjunction with a bid pool. A request account
establishes the constraints required for transactions in which multiple
parties will be
competing for the right to meet the requestor's requirements. In most
embodiments, a
request account will typically have a few standard constraints at the time of
creation
which help to define prospective future bids. Examples include: bid entry
deadline,
bid start and end dates and times, updated or sealed current bid results,
minimum bid,
minimum required change (increase or decrease) over previous winning bid,
seller's
PIN, and transaction conditions (e.g., delivery date, product specifications,
and return
policy).
After the constraint set has been finalized, the request account owner
publishes
the request account. Upon receipt of the publication request, the AAMS or an
associated virtual clearinghouse system (VCHS) creates the bid pool. The bid
pool
coordinates all responses that meet the criteria established for the request
account.
2o Additionally, the bid pool manages the creation of alerts, agents, and
triggers,
coordinated with the constraint set of the bid creator and the various
bidders. Thus
the request creator can determine if there will be open bidding (in which the
current
maximuxnlminimum bid is publicly available), sealed bids (where no bidder's
information is available), a bid in which bidders are allowed to solicit
changes to the
constraints, or bids which can be automatically or manually adjusted dependent
upon
the level of negotiation set forth in the constraint set.
Internal to the bid pool, bids received can be ordered and organized according
to various criteria, most typically high-to-low bid, or first-come, first-
served (FCFS).
If desired, bids can be created for multiple items, wherein the bid pool
serves to match
3o several bidders to several items. It is also possible to create embodiments
in which
the type of assets) offered to pay for the bid can be a determining factor in
the
acceptance of the bid. With this facility, barter transactions can also be
conducted.
112
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Bid pools can also be created to allow for multi-party bids (e.g., some value
from bidder one, plus some value from bidder two, three, etc.) and with items
then
parceled out to the group of winning bidders either in equal shares, or by
percentage
of their bid.
Most bid pools will also typically create an internal escrow account, owned by
the bid pool, which secures the assets used or offered by the winning
bidder(s), or by
the currently selected winning bidder(s). Thus, a bid pool can be used to
automatically guarantee that the required winning assets are available before
determining that a winning bid has been made. If over the life-span of the
bidlbid
1o pool, a winning bidder is displaced by a superior bid, the former escrow
account is
dissolved and a new escrow is created. Optionally, bid pools can be set up
such that
they create and dissolve multiple escrow accounts for both the current lead
bidder,
and any other selected bidders (such as a second runner up, in cases where the
lead
bidder cancels their bid).
Request accounts can also be set in hierarchical fashion such they manage a
wide range of bids focused on some common elements. An example of such a
hierarchical arrangement is the items for bid at an estate sale. Typically,
estate sales
are constructed with the goal of disposing (selling) every item. However,
circumstances can arise wherein a prospective bidder only wishes to bid on a
portion
of a set of items, e.g., just one dining room chair, not all four dining room
chairs, and
not the entire table-chairs combination. In these circumstances a request
hierarchy
can be established such that the top level request account (and its matching
bid pool)
is created for the table-chairs as a group, with two child request accounts,
one for the
table itself, the other for the four chairs, with another level of child
accounts under the
four chairs child, this last level containing four accounts, one request
account per
chair. In this way, prospective bidders can bid on a part or on the entirety
of the
items, and the estate sale holder can thus determine the maximum gain possible
for
the totality of the items up for bid.
The occasion may arise where competition for selected pieces raises the prices
3o to be paid past the prices contemplated for the set, in which case, the
request
hierarchy creator would have the ability to selectively determine winning
bidders, or
could automate the process through the use of constraints, agents, alerts, and
triggers.
In a related fashion, offer accounts can be chained together such that a
bidder may
113
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
place multiple bids on each of the discrete items, and on the set, using
agents, alerts,
and triggers to raise, lower, or even create bids based on the status of bids
revealed.
7.3.9.5 Gaming Accounts
In certain embodiments, the ARMS offers a predefined class of accounts
called gaming accounts. Gaming accounts and their associated gaming pools are
used
to specify, record, and resolve wager transactions between two or more
parties.
In most wagers or games of chance or skill, an outcome is predicted by one
party. Depending on the wager or game, odds may be given for a variety of
possible
outcomes by the same or a different party. Once the rules of the wager or game
have
been set, along with the odds, if any, participants wager as to their belief
or desire for
or against one, some, or all of the possible outcomes. Wagers can be placed at
the
start of an event or during the course of an event; odds can change over time,
or be
altered as an event progresses; assets for wagers can be provided up-front and
in-full
prior to the start of an event, can be offered/accepted as a callable note or
LO.U., or
Can be required to be paid after an event has ended
However, as with most current financial transactions, the methods used to
provide the.assets in these transactions are inefficient at best. For example,
internet-
based casino operations can accept credit for play in the form of a credit
card, but
cannot pay out winnings if they exceed the value of the initial charge. Thus,
a
2o winning player cannot receive funds from the casino with the same speed at
which the
casino charged him for the privilege of playing, typically having to wait
weeks before
a winnings check arnves, and incurring the delay of trying to process a large
out-of
state, or out-of country check, along with additional processing fees for
currency
conversions.
~5 Additionally, in other than large-scale commercial operations, there is no
common facility for small bettors to create, place, fund, and receive pay-outs
of ,
wagers in an electronic fashion. Thus, for the typical Friday night poker
player,
unless they have cash-on-hand, they could be prohibited from joining their
weekly
game.
3o A virtual gaming account overcomes these limitations by allowing for the
creation of fixed and variable outcome wagers, including hierarchical sets of
wagers
114
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
wherein a given game may have multiple outcomes with different probabilities
and
different odds or pay-outs. One example of a hierarchical set of games would
be an
event with multiple rounds, such as a sports championship, with levels in the
hierarchy for quarter-finals, semi-finals, and finals, with each match placed
at its
s appropriate level in the hierarchy. In another example, consider the spin of
a roulette
wheel. For such an event a hierarchy could exist with separate branches for
each type
of wager: one branch of child game accounts, with one account for each
possible
outcome from 0 to 36; a second branch with accounts for bets on red or black;
a third
for odd or even. In this example, the master gaming account, typically run by
the
gaming house, would automatically aggregate and distribute funds from its
child
accounts as each spin was completed.
At its creation, the gaming account owner fixes some set of initial
conditions,
including a game title or caption, and specific wager conditions (e.g., odds,
pay-outs,
minimum/maximum allowed wagers, and wager deadlines). Upon publication of
~5 these constraints, the AAMS or VCHS creates a gaming pool. The gaming pool
manages the placing of individual bets, and can also match bets on either side
of a
wager through the creation of alerts, agents, and triggers, coordinated with
the
constraint set of the game creator and the various bettors, recording at a
minimum,
times, dates, and amounts, and providing notificationlconfirmation of receipt
and/or
2o acceptance to both the bettor and the gaming account owner.
7.3.9.6 Proxy Accounts
In most embodiments, the AAMS offers a predefined class of accounts called
proxy accounts. A proxy account is a virtual account that is associated with
and
completely subordinate to another virtual account and acts as a proxy for this
account
2s in transactions and other operations. Proxy accounts can be created for any
class of
virtual account, including other proxy accounts.
In a transaction in which a proxy account acts on behalf of the creating
virtual
account, the latter remains completely isolated, unidentified, and anonymous
to the
source or target of the transaction. Additionally, proxy accounts can be
established to
3o provide a temporary or continuous link between virtual accounts and other
conventional accounts such as bank checking and savings accounts, credit card
accounts, loyalty program accounts, and others, providing these conventional
lls
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
accounts with advantages only associated with virtual accounts, including
multi-level
encryption, true anonymity, and other security and risk-reduction technology
only
found in virtual accounts.
W operation, proxy accounts can provide management oversight between
various conventional accounts. For example, a proxy account or set of proxy
accounts can manage the flow of funds from money market, checking, and savings
accounts at multiple banks, or for various accounts at the same financial
institution.
Proxy accounts acting in the stead of a conventional accounts) can provide
purely
pass-through functionality for the transfer of assets, or can hold content for
later
distribution.
Certain embodiments include a specialized sub-class of proxy account, called
a dynamic proxy account. A dynamic proxy account is a proxy account that has a
temporary life-span, that is, it is created on demand or according to certain
preset
requirements by a superior account, and exists solely to perform a specified
~ 5 transaction, set of transactions, or other operation(s), and is destroyed
after
performing its duties.
As a way of distinguishing between an ordinary proxy account and a dynamic
proxy account, consider first a typical example of the use of an ordinary
proxy
account in the performance of a regularly scheduled tasks) that require an
interface to
2o a non-virtual account, such as the distribution of funds from a paycheck
deposited into
a bank savings account. Knowing the deposit cycle for the paycheck, a virtual
account owner establishes a proxy account for the savings account. With the
proxy
account in place, the virtual account owner can then move assets through the
proxy
account to several target accounts without needing to interact with the
banking system
25 for each distribution.
A second example involves the use of a dynamic proxy account for
performing a purchase transaction between a conventional account controlled by
an
individual (in this example, a buyer) who also owns or controls a virtual
account, and
a seller who controls another virtual account. The buyer and seller have come
to
3o agreement on the purchase of a stereo. The buyer, realizing that his
virtual account
does not have sufficient funds to pay the agreed price, and also knowing that
this will
be a~one-time transaction with the seller, establishes a virtual dynamic proxy
account
116
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
to his savings account at a local bank, allowing him to transfer funds from a
conventional savings account into his virtual account, and then onward to the
seller's
virtual account to complete the purchase.
7.4 Dynamic Tokens
A feature which is preferably made available in all classes and sub-classes of
accounts is the ability to generate a dynamic token or VIN for accessing the
account.
In these embodiments, the system makes available to a requesting account an
algorithm, or the results of an algorithm, which generates a unique random
token, and
temporarily associates that token with a particular account, most commonly the
requesting account. Dynamic tokens set a new and reduced threshold of risk
associated with the loss or misappropriation of an account number by creating
a new
account number each time an account enters into a transaction.
External to the system, a wide variety of access devices can be configured
with what are generically referred to as challenge-response systems. A
challenge-
~ 5 response system is some combination of hardware and/or software in a
remote access
device that contains an algorithm known to, or identical to, one contained in
a host
system. When the access device attempts to contact the host system to perform
a
transaction, the host system sends a challenge to the access device, which
must
respond with the correct response before the transaction is authorized. In
most typical
2o examples, a challenge-response algorithm works by taking a seed number and
some
function with respect to time, to generate an authenticating token. Since the
algorithm
is known to both the host system and the access device, and since they are, or
were,
synchronized, the host system and access device should create identical
tokens.
Matching randomly generated authenticating tokens will be accepted by the host
25 system as sufficient identification and authorization for the remote access
device to
gain access to the host system or to another system for which the host system
acts as a
gate-keeper.
A fairly complex example of the use of dynamic tokens is the ability to thwart
corporate data mining activities. For instance, a bank has entered into an
agreement
3o with the local cable, electric, and phone companies to provide consolidated
account
transaction histories for all clients. Every outbound transaction from the
bank is
11~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
matched to a payment received by these other companies, and then matched
against
other records to determine which individuals pay for what services at which
locations.
But an account owner requiring the services of these companies, particularly
one
using virtual accounts, no longer has to fear that his personal financial data
will be
used without his permission.
If the virtual account owner sets up a proxy account to handle these
transactions, the corporations could, after comparing transaction records,
determine
precisely that a specific individual owned, or accessed fund through, a
particular
virtual account. Even if the individual made a bulk transfer from the bank in
a sum
equal to the three required payments, and then made three separate payments,
the
corporations could eventually, after reviewing the consolidated transaction
histories,
uniquely identify the account owner. However, if instead of creating a proxy
account
for drawing funds from his savings account to pay his monthly bills, he
establishes a
proxy account with dynamic VINs then none of the individual transaction
histories
~ 5 recorded by the corporations will match, and the account owner's privacy
will be
secure.
7.5 Account Mod~cations
Accounts and sub-accounts, particularly those based on virtual accounts, once
initially configured, are not limited to a single permanent configuration.
Rather,
2o accounts, sub-accounts, and their inter-relationships can be adjusted as
necessary
though out their entire lifetime from creation to final destruction.
Virtual accounts and sub-accounts can have attributes whose values change.
For example, an attribute value which stores the daily spending limit can be
increased
or decreased at will (subject to any inherited constraints) by any individual
in control
25 of the account. New attributes can be created and others deleted as
necessary. For
example, an existing account might be configured with a new attribute
indicating an
affiliation with a loyalty program such as a frequent flyer number. At a
future point
in time, the control of the account may pass to another individual and the
frequent
flyer number attribute deleted.
3o Virtual accounts and sub-accounts can have constraints which are
dynamically
managed. For example, a constraint might be placed on an account for a
teenager by
118
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
a parent that limits purchase activity to Friday, Saturday, and Sunday. During
the
summer break, the parent may reconfigure, disable, or delete the constraint to
allow
activity any day of the week.
Virtual accounts and sub-accounts are classified as general accounts or a
specific specialized form such as a bid, gambling/gaming, escrow, or proxy
account.
Subject to any existing constraints, virtual accounts and sub-accounts can
change
from one class to another. For example, an general account may temporarily or
permanently convert to an escrow account to escrow funds or to a
gambling/gaming
account to place a wager. Any changes to account class are subject to existing
1 o constraints which may limit changes due to inheritance conflict, a
condition where
constraints would be violated by the class change.
Virtual accounts and sub-accounts can be transferred from one account
hierarchy to another in the same or different systems. Account content can be
left
behind during the transfer or carried along with the account. Sub-accounts can
be
trimmed and re-grafted to another location within the same account or to
another
account altogether. Trimming and grafting can carry the entire hierarchy or a
single
sub-account. For example, a family consisting of a husband, wife, son, and
daughter
all have sub-accounts to a household account. Each can establish additional
accounts
hierarchically under their personal account, such that the son may have a
college fund,
2o clothing allowance, and entertainment sub-accounts while the daughter may
choose to
manage all transactions from a single account. When the son or daughter leaves
the
household, their account hierarchies can be moved wholesale into a new
account.
Additionally, sub-accounts can be moved around within the virtual account such
that
the husband's house budget account can be moved to be a sub-account of the
wife's
on a temporary or permanent basis.
En masse manipulation of sub-accounts and their attributes and constraints can
be performed using domains and domain constraint pools instead of requiring
individual accounts to be adjusted separately. Additionally, a domain allows
for the
grouping of sub-accounts of unspecified relationships to be moved about in the
3o hierarchy.
119
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.6 Account Content
Accounts and sub-accounts can receive, hold, and transmit many different
types of content, which are generally categorized as assets. Although most
traditional
accounts are restricted to only holding one type of asset, virtual accounts
can hold
multiple types simultaneously. Assets are items of worth such as currency,
deeds,
credentials, coupons, and information. Information assets include documents
such as
financial billing records, invoices, notifications, and messages.
Today, the commercial banking system is always in need of reconciliation
with corporate account records because financial and shipping documents travel
1o pathways separate from the funds used to satisfy obligations. The same is
true for
individuals who receive bills and must write checks or charge them to credit
cards.
Even a direct deposit of payroll compensation, or an investment dividend
requires the
separate distribution of a pay stub or remittance advice. With virtual
accounts, for the
first time, financial documents and funds can move together through a combined
15 pathway. For example, funds can be obligated when an order is placed. When
a
product is shipped or a service is rendered, the appropriate documentation can
be
collected. When an invoice is received, it can be matched to the correct
payment
account and verified against co-located documentation. On the due date, funds
can be
dispersed electronically and carried with a copy of the invoice document to
the
2o vendor. This will completely change the implementation of accounts payable
and
accounts receivable systems, where the data-of record is no longer the
accounting
system, but rather where the accounting system becomes a tracking mechanism
for
the real data-of record that resides in a virtual account.
7.6.1 Content Manipulation
25 Content contained in accounts can be activated, authenticated, created,
deactivated, destroyed, evaluated, generated, implemented, maintained,
modified,
processed, registered, and/or otherwise manipulated manually or through
automated
means, by either an account owner or other entitylentities authorized to
perform
actions on or to this account. Depending on the type of content contained,
additional
3o actions may be available, included user-defined actions.
120
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.6.2 Content Security
Accounts within an ARMS offer a number of advantages over traditional
financial instruments in terms of their ability to protect the content of
their accounts.
Most preferred embodiments offer two sepaxate protection mechanisms: account
and
content level constraints, and account and content level encryption (including
constraint encryption).
Content level constraints are used to provide use restrictions, and when
properly incorporated, can severely impede malicious or fraudulent misuse or
misapplication of content from an account that may have been misappropriated.
A
~o typical example of such constraints would be a restriction against
transfers or
purchases in excess of a $50 daily limit.
Each content element can be encrypted and decrypted independently.
Encryption can be applied to an entire account, a specific set of sub-
accounts, or
individual account content. A sub-account maintaining a balance in multiple
~5 currencies where each currency and balance is separately encrypted is a
simplistic
example. A more complex example would use separate encryption of credentials,
documents, digital content, and currency all co-resident in the same sub-
account.
Separate encryption and decryption enhances security by allowing decryption of
just
the specific content element that must be manipulated, stored, processed, or
2o communicated while the remainder of the account contents remains securely
encrypted.
Individual content elements can be manipulated, stored, processed, and
communicated while remaining encrypted. For example, a sub-account containing
an
encrypted credential can transfer the credential, authenticate the credential,
or perform
25 other transactions without ever decrypting or completely decrypting the
credential.
This can be accomplished using role based access controls allowing selective
decryption of portions of an object using split keys.
7.6.3 Digital Assets
In most preferred embodiments of this invention, the content of a virtual
3o accounts can include digital assets such as electronic representations of
currency,
digital media (e.g., music, video, text), credentials, and documents. Again,
although
121
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
this discussion focuses on the capabilities of virtual accounts, certain other
traditional
accounts can hold digital assets, and those skilled in the art will be able to
relate the
enhancements detailed herein to those account types.
Each type of digital asset can carry with it, as an attachment or integral
part,
s qualitative information about that asset such as the copyright restrictions
for digital
artwork, jurisdiction and expiration date for credentials, format
characteristics for
documents, or unit of measure for currencies. Each type of digital asset can
also carry
with it, as an attachment or integral part, additional information other than
the
qualitative portion. This could consist of notes from the owner in any
language or
preferred settings for the use of the digital assets, such as play lists for
digital music
and video.
The content of a virtual account may consist of the digital asset itself, or
just
the representation of the digital asset. This representation could consist of
a digital
asset that has been compressed or packaged inside of a digital container along
with
rights management protocols. The representation may also be a deed or a
receipt for a
digital asset that is stored separately. Each representation can carry with
it, as an
attachment or an integral part, qualitative information about that
representation, such
as jurisdiction or purchase date, and can also replicate the qualitative
information of
the digital asset it represents. Additionally, each representation can also
carry with it,
2o as an attachment or integral part, additional information other than the
qualitative
portion, such as use or setting notes, warnings or restrictions.
7.6.4 Non-digital Assets
The content of a virtual account may consist of representations of non-digital
assets, as espoused in certain preferred embodiments. The representation may
be a
2s deed or a receipt for a non-digital asset that is stored separately.
Examples of
representations of non-digital assets include deeds for real-property and
securities like
stock certificates. Each different representation of a non-digital asset can
carry with
it, as an attachment or an integral part, qualitative information about that
representation of a non-digital asset such as descriptive information for the
deed,
3o assignment histories, and the unit of measure. Each different type of non-
digital asset
can also carry with it, as an attachment or integral part, additional
information other
122
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
than the qualitative portion. This could consist of notes from the owner in
any
language or instructions for use or redemption.
7.6.5 Changing Ownership and Control
A feature unique to virtual accounts within an AAMS, the ownership and
control of assets can be changed without causing or requiring the asset to be
physically manifested or even moved. For example, a virtual account containing
US$50 in currency participates in the purchase of an item costing US$20. If
the seller
also has a virtual account, the ownership and control of US$20 of the US$50 is
simply
changed to point to the second account. The account records for the
transaction will
show a debit of the first account and a credit to the second, but the asset
can appear to
move just by changing the ownership and control.
7.6.6 Asset Types
Assets are generally classified in two major categories: currencies and non-
currencies. Currencies are further categorized as national, mufti-national,
and private
~ 5 currencies. Examples of national currencies include US dollars, British
pounds, and
Japanese Yen. The Euro is an example of a mufti-national currency. In some
countries, such as China (in particular, Hong Kong), currency is issued by
authorized
private institutions such as The Bank of China, The Standard Chartered Bank,
and
The Hongkong and Shanghai Banking Corporation Limited (HSBC), instead of the
2o government. In the 19th century, private currencies flourished in US, and
even today,
there are no prohibitions in the US against the printing or use of private
currencies.
Non-currency assets are divided into those that are quantifiable and those
that
are non-quantifiable. These two groups are further subdivided into those
assets that
have an intrinsic value and those that do not. Even assets without intrinsic
value may
25 still have worth such as coupons, software licenses, subscriptions,
credentials,
government issued licenses, security keys, and incentive points like frequent
flyer
miles. Possession and control of the asset, i.e., the ability to use, is the
key
differentiator for items without intrinsic value.
Examples of non-currency assets that are quantifiable and have intrinsic value
3o include event tickets, entitlements, phone minutes, and securities such as
stocks,
bonds, futures, and options contracts.
123
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Examples of non-currency assets that are quantifiable but have no intrinsic
value include coupons, discounts, software licenses, subscriptions, and
incentive
points. Incentive points include a wide variety of loyalty program points as
well as
private currencies that are not pegged or exchangeable with any publicly
recognized
currency.
Examples of non-currency assets that are not quantifiable but have intrinsic
value include deeds, titles, memberships, insurance policies, annuities, and
perpetuities.
Examples of non-currency assets that are not quantifiable and have no
intrinsic
1o value include credentials, keys, authenticating tokens, and government
issued
licenses.
7.6.7 Document Types
Information assets including documents can be generally classified into
categories of contracting, government issued, non-government issued, and other
15 information. Contracting documents consist of a wide range of financial
documents
including the document types covered by such public standards as: Electronic
Data
Interchange (EDI), ISO 15022, UN EDIFACT, and forthcoming standards from the
World Wide Web Consortium (W3C) and the Object Management Group (OMG) for
Extensible Markup Language (XML) formatted interchanges. This includes
2o proprietary document formats such as Microsoft Office, Corel WordPerfect
Suite,
IBM Lotus, and the forthcoming Microsoft BizTalk protocols.
Contract documents include financial documents such as solicitations,
contracts, notifications, and various forms. This set includes a wide variety
of
business interchange documents such as purchase orders, invoices, receipts,
and
25 shipping manifests.
Government documents can be financial or non-financial. Government
financial documents can include records and/or deeds for real property,
property tax
assessments, personal taxes, sales taxes, and value-added taxes. Government
non-
financial documents can include certifications, credentials, licenses, voter
registration
so records, laws, filings, and forms. In the US, the Office of Management and
Budget
(OMB) maintains a large catalog of forms. Additionally, each US federal agency
124
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
makes available for publication each year numerous documents with rules,
regulations, and research. Governments at the federal, state, and local level
issue
permits such as business licenses, occupancy permits, drivers' licenses,
vehicle titles
and registrations, passports, visas, birth certificates, and death
certificates.
Legislatures issue laws; courts issue judgements. The Uniform Commercial Code
(UCC) and other bodies of law all can be stored in virtual accounts.
Non-government institutions such as universities and colleges as well as
organizations such as medical boards also issue documents such as
certifications,
credentials, licenses, records, and forms. Virtual accounts can store medical
credentials, diplomas, transcripts, and other useful documents.
Other documents that can be contained in virtual accounts include but are not
limited to text, images, audio, video, spatial, multi-media, directories,
indexes, and
forms. In the case of digital content such as books, music, or video, the
asset itself
may consist of the digital recording. In other cases, the asset may simply
consist of a
deed, ownership certificate, rights use policy, or receipt for an asset held
in another
location or form.
7.6.8 Converting Content
Account content for appropriately enabled account types can be converted
from one form to another upon receipt of a command with the appropriate
2o authorization. For example, an account holding a voucher document could be
commanded to exercise the voucher to create a reservation. The same mechanism
can
be used to redeem loyalty program points such as frequent flyer miles for
plane
tickets. Telephone minutes could be exchanged using this mechanism for a
magazine
subscription.
The virtual account, using an exchange mechanism, can convert specific
quantities of one type of asset to another type of asset taking into account
any
differences in the unit of measure. This can be used to implement currency
conversions from US dollars to Euros, Pounds, Yen, or any other currency. It
can
also be used to convert currencies and non-currencies. For example, currency
can be
so converted into telephone minutes, or frequent flyer miles exchanged for
transit tokens.
12s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.6.9 Asset Reservations
Assets held in virtual accounts can be reserved for future use. This is
accomplished by placing an encumbrance on the account limiting the use of a
specific
asset or portion of assets held in the account. Most often the encumbrance
will expire
upon the successful later completion of a pending transaction or after a
specific time
duration. The reservation of assets can be used to guarantee payment
availability for
transactions with delayed settlements. This will diminish the available
balance of
assets in the account by the amount reserved without actually debiting the
account.
For example, an account holder wishes to rent a car, for which the car rental
company
requires a guarantee of funds availability for future payment. Assets can be
reserved
to guarantee that the car rental company will be able to successfully complete
a
transaction at a future date when the car is returned. In more complex
scenarios, the
reservation may establish an escrow to control the reserved funds and place
additional
restrictions on the transaction. Account Content: Actions on Assets
~ 5 Quantifiable assets held in virtual accounts, whether tangible like
currency or
digital music, or intangible like telephone minutes and frequent flyer miles,
can be
incremented, decremented, expired, validated, or manipulated. Assets such as
loyalty
program point balances (e.g., frequent flyer miles) are frequently increased
by
incrementing a counter based on account holder actions and later redeemed in
large
2o blocks. Assets like telephone minute balances are decreased by decrementing
a
counter. Assets that are earned as credits, that are coupons for special
offers, or that
act as subscriptions may expire if unused or require validation to confirm
legitimacy.
Non-quantifiable assets held in virtual accounts, such as deeds, titles,
memberships, credentials, licenses, and insurance policies can be entered into
and
25 removed from virtual accounts.
Accounts also can be configured such that only certain kinds of assets are
allowed. These limits can be applied to currencies, national currencies, and
non-
monetary assets, including those of value, those with specific quantities but
no value,
and those With no measurable quantities and no value. This allows for
restrictions
3o such that certain currencies can only be stored in some types of accounts,
such as
might be necessary to comply with national or international laws. Other
prohibitions
126
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
might restrict a credential such as a passport or driver's license to only be
stored in
accounts housed in repositories inside certain governmental boundaries.
7.7 Account Repositories
Although an RAMS can be configured so that a single system could contain
all known accounts, this represents only one possible alternative. In certain
preferred
embodiments, the AAMS affords opportunities for the creation of multiple
account
repositories, each storing one or more accounts and related sub-accounts.
Generally
speaking, an account repository provides a unifying management structure with
which
a repository can control various aspects of a set of accounts.
Different types of repositories, serving different purposes, are contemplated.
There are two major classes: closed repositories, in which only relationships
to other
accounts within a closed repository is permitted; and open repositories, in
which an
account may have relationships with one or more accounts in one or more other
repositories. In either case, the relationships may be effected with the aid
of some
15 intermediary commiuucations devices) which permits) an account owner to
conduct
transactions without a direct connection to a repository.
A repository governs the operations and transactions of the accounts within
it.
Likewise, the accounts axe "members" of a particular repository, and inherit
some
minimum attributes, constraints, and other rules and controls, as applicable,
2o depending on account type. In a preferred embodiment virtual accounts can
add or
otherwise modify rules and controls inherited from a repository, but they can
not
make the rules and controls less restrictive.
7.7.1 Repository Content
In several preferred embodiments repositories are not restricted to containing
25 only accounts and their hierarchies. Repositories can contain alerts,
triggers, and
agents that act for the benefit of the repository and/or its accounts.
Repository content
can include additional control structures necessary to facilitate the
automation of
business models for barter, haggle, fixed price sales, auction sales
(including both
English and Dutch style), reverse auctions, demand aggregation, and exchanges.
3o Additionally, repositories can contain profiles and other analytical
structures which
12~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
can be used to direct coupons and discount offers to specific accounts.
Repositories
can also track directed advertising and sponsorship details used for cross-
selling and
up-selling of goods and services to member accounts.
In some cases, repositories can also contain control structures or system
controlled accounts that enable the repository to act in the capacity of a
market maker,
gambling/gaming house account, retail sales catalog, and auction posting
board.
As a market maker, the system may be required to maintain an inventory,
retain a currency balance, or act as a buyer or seller of last resort. This is
useful for
securities repositories run by market makers that require settlement of
transactions.
1 o For a repository supporting gambling/gaming, the house account can
participate in wagers. When bettors lose, the house account collects the
winnings.
When bettors win, the house account pays out the winnings.
When a repository acts as a retail sales catalog displaying fixed prices, or
as a
demand aggregator, the list of available products and other details such as
~ 5 descriptions, weights, shipping requirements can be retained. In
particular, for use in
demand aggregation the repository can be used to track the participating
members.
Profiles can be maintained by repositories to track individual member
accounts and sub-accounts and their corresponding activities. They can be used
in
either an identified or anonymous fashion to target advertising and forward
offers to
2o qualified accounts for specific coupons or discounts. For example, an
anonymous
profile might track the average daily balance, current balance, and types of
purchases
made by the account holder. Using this information, an airline such as United
Airlines or Delta Airlines could offer all members of a repository ten
thousand extra
frequent flyer miles with the purchase of any plane ticket costing over three
hundred
25 US dollars, with the offer expiring in two weeks. The airlines might choose
to target
the.offer to only those repository members with a minimum balance of five
hundred
US dollars who have made at least two airline ticket purchases in the last
year.
Profiles can also be used to serve up banner advertising and audio/video
advertising on a real-time basis when account owners are reviewing their
current
3o account status to check balances, adjust account features (e.g.,
constraints), or account
structure (e.g., establishing or destroying sub-accounts). These offers can
include
128
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
click-through advertising as well as on the spot click-and-buy offers that
have funds
automatically deducted from the current account.
7.7.2 Distributed Repositories
A first type of open repository is a member of a distributed group of
repositories. In a distributed group, the member repositories know or
recognize each
member of their group, and additionally know of at least one communications
route to
each member. In a distributed group, each member repository is free to set its
own
internal rules and controls, although there may and preferably is some
predominant
constraint set adhered to by all members of the group.
An example of a distributed group of repositories would comprise an
individual repository for each casino in Atlantic City, connected so that a
visitor in
one casino could use a virtual account to access funds held in any casino
account
repository without having to "cash out" each time he left a particular casino.
In such
an example, a visitor with a account held in Caesar's Atlantic City repository
could
~5 present his account at Bally's Park Place, and the Park Place repository
would transmit
credit and debit information to Caesar's.
7.7.3 Federated Repositories
A second type of open repository is a member of a federation of repositories.
A federation is a system in which members of a group agree to some form of
2o centralized management but retain control of their own internal affairs. A
federated
group of repositories thus exists as a system in which each of the
repositories in the
federation is aware of all of the members of its group, and has some condition
of trust
with respect to transactions received from these members, but maintains its
own
internal management.
25 As an example of a federated group, consider the Las Vegas casinos owned
and operated by Mandalay Resort Group, Inc (MRG). MRG owns and operates four
casinos within blocks of each other in Las Vegas. These casinos, Circus
Circus,
Luxor, Excalibur and Mandalay Bay Resort, have their own management, operate
in a
somewhat independent fashion, manage their own profit and loss, and would most
3o likely operate their own repositories. However, since they belong to the
same parent
company, the individual repositories would naturally have a condition of trust
when
129
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
reacting to transactions proposed by other members of their group. Thus the
MRG
Las Vegas casino repositories would most likely exist in a federated state,
with their
physical proximity facilitating direct connections between member
repositories.
7.7.4 Distributed-Federated Repositories
A distributed-federated group of repositories has characteristics of both
distributed and federated groups of repositories. Thus, a member of such a
group
would know all of the members of its group, know a communications route to
each
member, and exhibit a condition of trust with respect to any transaction from
any of
the members.
Again turning to the casino properties owned by MRG, consider the rest of
MRG's operations, including the Grand Victoria, a riverboat casino and
entertainment
complex in Elgin, Illinois, and Circus Circus-Reno, among others. Each
geographic
area could operate in a federated fashion (all 'of the Las Vegas properties,
all of the
Reno properties, etc.), with each of these distributed federations centrally
connected
to every other federation.
7.7.5 Repositories: Inter-networked Repositories
Inter-networked groups of repositories extend the boundaries of possible
groups to encompass any repository that might be able to locate and
communicate
with another repository. Much the same way that the web/internet is a
collection of
2o servers presenting information, an inter-networked group of repositories
represents a
widely distributed set of both individual repositories and groups of
repositories which
can cooperate in the presentation, access, management, and manipulation of
assets
and asset information.
Inter-networked groups exist when some combination of the following
conditions exists:
~ member repositories are not required to be known in advance, but can be
discovered;
~ communications connections between the repositories are not required to be
known in advance, but can be discovered;
~ routes between repositories are not required to be known in advance, but can
be
determined;
130
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
routes between repositories can change, with no requirement that
communications
connections) established between two or more repositories must traverse the
same path as their first communications connection route;
~ connections) between repositories can be intermittent or permanent;
~ communications connections between repositories can be dynamically
established,
dissolved, moved, managed, and redirected.
Expanding once again on the casino model, let us consider the totality of
properties within MRG, and now include other casinos owned by other companies
in
other cities, casinos on Native American Reservations, and Internet-based
casinos
(typically located outside of the United States). Each of these casinos, and
the various
federated, distributed, and/or distributed-federated groups could exist on a
single
inter-networked system thereby allowing for visitors at any one property to
seamlessly access, transfer, manage, and manipulate assets and asset
information at
any property.
15 Additionally, multiple inter-networked groups of repositories can be
integrated
using standard network equipment, e.g., bridges, concentrators and routers.
7.7.6 Repository Encryption & Security
Encryption is as valuable in the operation and management of an account
repository as it is to the other objects found in the ARMS. Repositories, as a
unifying
2o management tool for large groups of accounts, can be protected from
unauthorized
access and manipulation that might compromise the integrity of the contained
accounts. Additionally, since most repositories will interact with other
repositories,
the communications channels between repositories, and the transmissions
themselves,
are preferably secured to insure that only valid AAMS actions are accepted and
25 processed.
Specific embodiments of this invention allow for the creation of secure
repositories wherein data (both system data and account data) can be encrypted
in
transit, at rest, or during processing. In certain particular forms of these
embodiments, multiple layers of encryption, e.g., stored encrypted data that
is
3o encrypted a second time during transmission, are also supported. In most
instances,
all data pertinent to the operation and well-being of the repository is
encrypted,
131
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
although certain embodiments allow for cases where non-sensitive data remains
unencrypted
These encryption services can be provided in hardware, software, or a
combination of hardware and software. Encryption engines may be internal or
external to the repository computer system, or may be included within one of
the
various subsystems. Encryption and decryption duties can be split between
multiple
encryption engines without loss of security. Use of a particular
encrypting/decrypting
system does not preclude the simultaneous use of other encrypting/decrypting
systems.
~ 0 7.8 Virtual Clearinghouses
The present invention provides a system and method for the establishment of a
Virtual clearinghouse (VCH) that acts as a third party intermediary for
facilitating
transactions. Clearinghouse transactions allow virtual accounts to safely
interact with
other virtual accounts, regardless of repository location or type, and support
15 interactions with non-virtual account systems. Examples of the latter
include bank
accounts, credit card networks, securities accounts, automated teller machines
(ATMs), event ticketing networks, the Federal Reserve's FedWire, interbank
transfer
and settlement systems, the Automated Clearing House (ACH) and other similar
financial systems. A clearinghouse can if desired facilitate transactions in
which the
2o transactions take place between virtual accounts in the same repository
and/or in
which the transactions are between a physical devices) and an accounts) within
a
repository. Clearinghouses can also facilitate transactions between multiple
physical
devices in which the physical devices are operating as stand-alone virtual
accounts.
Clearinghouses may have pre-established andlor dedicated communications
25 paths to the systems and devices with which they communicate or the
communications routes may be dynamically constructed. When dynamically
constructing paths, each communications connection, and sometimes, even the
discrete portions of a message, e.g., individual message packets, may be sent
or
received via a different pathway(s).
3o Clearinghouses can if desired be used to improve financial transaction
processing by offering coordination services to transacting parties.
Typically,
132
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
clearinghouses will have trusted relationships with one or more repositories
and/or
one or more devices. By acting as a third party to a transaction, a
clearinghouse
allows two parties to indirectly contact each other and perform transactions
without
requiring a direct trust relationship to be established between the
transacting parties.
Additionally, clearinghouses can be chained or grouped together, wherein each
clearinghouse in the group has a trusted relationship with ever other member
clearinghouse. In this way, individual repositories or devices are not
required to
maintain a trusted relationship with multiple clearinghouses but are still
able to
communicate with other devices or repositories, even if they do not share a
common
clearinghouse.
7.8.1 General and Special Services
A clearinghouse may be used to facilitate account transactions such as account
existence verification, balance inquiry, available balance inquiry, credit,
debit,
transfer, and funds reservation. A clearinghouse can facilitate any account
manipulation transaction supported by a repository, including for example
activation,
authentication, creation, deactivation, destruction, evaluation, generation,
implementation, maintenance, modification, processing, or registration. This
may
include transactions that require performance of aggregations, distributions,
conversions, and/or exchanges.
2o Clearinghouses can be configured to add value by providing specialized
coordination services including: escrow account creation and escrow
transaction
management; bid pool creation, and bid transaction management; gaming/gambling
pool creation, and gaming/gambling transaction management; agent services,
including acting as an agent or proxy for a repository; tax and/or fee
collections;
credentials and license management; digital certificate management; and
digital
signature management. In these instances, the clearinghouse becomes more than
just
an intermediary to the transaction and actually becomes an integral part of
the
transaction. As an example, consider the case of a clearinghouse that creates
and
manages a bid pool, which organizes, sorts, and matches buyers to sellers. In
this
instance, the individual bidders could not complete their transactions without
the
clearinghouse bid pool. Additionally, clearinghouses afford the opportunity
for multi-
repository transactions for these various special services, especially where
the
133
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
individual repositories and/or devices involved do not have trusted
relationships with
one another, or where the various participating accounts are in different
repositories.
In various embodiments clearinghouses can provide these and other services to
single repositories, to groups of repositories, and even to transactions that
take place
within a single virtual account. As mentioned earlier, groups of repositories
may be
configured as any combination of distributed, federated, distributed-federated
and
inter-networked. Each repository or group of repositories must establish a
trust
relationship between itself and a clearinghouse by presentation and
examination of
appropriate credentials and/or secure connections. Any of the trusted
repositories
may optionally use the clearinghouse to process and coordinate transactions
within a
single account, between accounts, or with any account in any other
repositories
trusted by the clearinghouse. Additionally, clearinghouses can be used to
conduct,
manage, and coordinate transactions between repositories and various devices
connected either directly or indirectly to the clearinghouse. Like the
repositories,
~ 5 each device so connected must establish a trust relationship between
itself and the
clearinghouse by presentation and examination of appropriate credentials
and/or
secure connections.
In most embodiments, access to the clearinghouse will require the use of an
authenticating token. This limits the authorized users and administrators of
the
2o clearinghouse to known or authenticated parties. Each of the various
specialized
services offered by a clearinghouse, as well as the various sub-components
managed
by a clearinghouse, can be further secured requiring the use of the same or a
different
authenticating token for access and/or oversight.
7.8.2 Escrow Services
25 In one embodiment, the clearinghouse provides coordinated escrow services.
Any transaction of any type may be escrowed. Thus, an escrow may be
established to
guarantee: payment for purchases, contractual obligations, bids,
gaming/gambling, or
taxes or fees. The criteria for release of escrow funds conditions the payment
or
cancellation of the escrow. The clearinghouse may periodically check (poll) or
await
3o notification of a change in the conditions. A typical example might be a
person-to-
person commerce transaction for a purchase made on an Internet auction site
that
134
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
automatically releases funds subsequent to a delivery notification by a
shipper such as
UPS or FedEx.
7.8.3 Bid Services
Another embodiment of clearinghouses provides coordinated bid services.
Bid transactions include any instance in which multiple parties compete for
the right
to enter into or complete a transaction. Bidders can include buyers or sellers
(e.g.,
auctions or reverse auctions), respondents to requests for proposals (RFPs) or
requests
for quotations (RFQs), among others. A bid transaction holds a conditional
obligation
to pay based upon successful transaction settlement. Each bid may optionally
be
guaranteed by an escrow account. The clearinghouse holds bids until settlement
and
resolves winning and losing bids.
In other embodiments, bids are grouped together for simplified management
using bid pools. Bid pools are used for multiple purposes depending on the
type of
transaction. Fox auction-like transactions where there is a one-to-many
relationship,
bid pools are used to keep track of each successive winning bid and maintain a
hierarchical list of surpassed bids. Thus, should a winning bidder fail to
complete the
transaction, the offeror would have the option to contact the remaining
bidders, in
order, and try to complete their transaction.
For many-to-many transactions, bid pools can organize, sort, and determine
2o matching bids between offerors and bidders. For Dutch auctions and demand
aggregation buying situations, the bid pool can determine how many of each
object a
bidder may be able to obtain, and, based on criteria supplied by the offerors,
the price
per unit bid.
7.8.4 Gaming Services
In still another embodiment, the clearinghouse provides coordinated
gaminglgambling services. A gaming/gambling transaction holds a conditional
obligation to pay based upon successful transaction settlement after
resolution of a
wager. Gaming/gambling transactions may also optionally be guaranteed by an
escrow account. The clearinghouse holds gaminglgambling transactions until
3o settlement and resolves winning and losing wagers.
135
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Like bid pools, clearinghouses also offer gaming/gambling pools. Using a
gaminglgambling pool, wagers and associated gaminglgambling transactions are
grouped together for simplified processing and management. Additionally, they
can
also be used to select parties on each side of a wager, wherein a gambling
house
establishes the odds for a particular wager, and takes a cut of the
transactions, with the
gaming/gambling pool used to match wagerers taking one side or the other. In
such
instances, the pool can also perform one-to-many, and many-to-many matches, if
the
amounts wagered do not match on a one-to-one level.
7.8.5 Agent Services
1 o In certain embodiments, clearinghouses act as an agent, coordinating
activities
in remote or external systems. An example would be nightly sweeps of
aggregated
funds from repository accounts into the FedWire or other banking systems to
collect
interest on unencumbered funds. Another example of agent activity would
include
the automatic transfer of collected sales taxes from tax escrow accounts to
the
~ 5 appropriate government accounts. In an agent relationship, a clearinghouse
leverages
its trust relationship to facilitate transactions that a repository could not
perform or
could not perform as efficiently.
7.8.6 Tax & Fee Services
In a preferred embodiment, a clearinghouse can collect taxes and fees on
2o transactions. Each transaction can specifically identify the amount and
type of each
tax or fee and the intended recipient of the tax or fee. The tax and fee
calculation
engine can be an integral part of the clearinghouse, exist as a separate
module, or be
completely external to the clearinghouse but interfaced and accessible.
Examples of
various collection transactions include the collection of a renewal fee on the
25 registration of a motor vehicle, and the explicit capture and collection
(including
calculation) of tax amounts as identified by the retailer fox local, state, or
national
sales tax, or value-added tax.
A clearinghouse can be configured with the ability to examine the nature and
details of any transaction to determine appropriate taxes and fees, add them
to the
3o transaction amount, and withhold them from the proceeds. A more detailed
example
of tax services provided by a clearinghouse would be the automatic calculation
and
136
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
collection of local and state sales taxes on a purchase transaction for retail
goods,
taking into account the location of the purchaser, the current location of
goods, the
location of the seller, and the tax status of the purchaser, seller, and
shipper. With
regard to fees, an example would be the automatic addition of fees for the use
of
specific access devices, such as charging a fee for using another
institution's ATM
system.
7.8.7 Credential & License Services
In most preferred embodiments, clearinghouses can manage credentials and
licenses. For example, an account in a repository may hold a government
license such
as a building occupancy or elevator permit, or a credential such as university
diploma.
The clearinghouse can present, validate, certify, manage, and otherwise
manipulate
the credential or license as part of a transaction with another account or an
external
device. The clearinghouse can also facilitate the distribution, expiration, or
renewal
of credentials and licenses on behalf of the issuer. An example would be a
vehicle
~ 5 registration renewal system in which the registration and title documents
are held
electronically in an account, renewal notices are automatically distributed,
and
renewals are processed as electronic transactions between the accounts of the
issuer
and vehicle owner.
The identification of target accounts (even across entire groups of
repositories)
2o and distribution of notifications can be accomplished with a clearinghouse.
When
individuals, businesses, or other account holders renew a registration, a
clearinghouse
can negotiate the transactions with the issuer, transmit required payments
from and
deposit the renewed credentials or licenses into the holder's account(s). When
vehicles are sold and title documents transferred, a clearinghouse can
automatically
25 notify the issuer of changes in status of the credentials or licenses and
update the
documents as appropriate.
7.8.8 Digital Certificate Services
In certain embodiments, the clearinghouse manages digital certificates and
digital signatures. Digital certificates are used to enable secure
communications
3o between servers on the Internet, and to allow communications through
firewalls, by
authenticating one or more parties. In particular, most Secure Socket Layer
(SSL)
137
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
communications, a common messaging protocol used on the Internet, require a
Server
Certificate. SSL encrypts communications between servers and clients, so that
a
merchant can take credit card orders and shield sensitive personal
information.
The clearinghouse can contain a digital certificate creation and
authentication
engine, or can act as an intermediary for ascertaining the veracity of
certificates
offered by transacting parties. For example, the clearinghouse can certify the
identity
of a transaction participant using a digital certificates) without exposing or
sharing
that identity with the other transacting party/parties. This can be used to
facilitate
auditing of transactions and irrevocable binding contracts without sacrificing
the
anonymity of transaction participants.
7.8.9 Digital Signature Services
We are all familiar with the electronic pad a person signs upon receiving a
package from a delivery service such as Federal Express. In these cases, the
handwritten signature is digitized and the image transferred to the electronic
document. Once captured, these digitized signatures can be cut and pasted into
any
electronic document, making forgery a simple matter. A digital signature is
not a
digitized image of a handwritten signature. Digital signatures are
transformations of
electronic messages using public key cryptography. Through this process, the
digital
signature is tied to the document being signed, as well as to the signer, and
therefore
2o cannot be reproduced. Furthermore, digital signatures are legally
admissible in a
number of states already, and will likely be legally recognized nationwide and
worldwide in the near future.
Digital signatures are usually based on asymmetric, or public key,
cryptography. In addition to a key pair and some type of electronic
communication,
the digital signing and verification processes involve something known as a
hash
algorithm and a signature algorithm. The hash and signature algorithms are
extremely
complex mathematical equations. The hash algorithm is performed on the
original
electronic message's binary code, resulting in what is referred to as a
message digest,
which is typically a 160-bit string of digits that is unique to the original
message. The
3o signature algorithm is then performed on this message digest. The resultant
string of
digits is the digital signature. The signer's private key is incorporated into
the
138
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
signature algorithm during the signing process, and the public key is
incorporated into
the signature algorithm during the verification process.
In particular embodiments, clearinghouses can contain directories of public
keys for distribution with transactions or can authenticate digital signatures
used
during transactions. Clearinghouses can also manage the algorithms themselves,
becoming a source for the creation of secure communications. Thus,
clearinghouses
can certify the identities of transaction participants using digital
signatures without
exposing or sharing the identity of one party with any other transacting
party/parties.
This can be used to facilitate auditing of transactions and irrevocable
binding
contracts without sacrificing the anonymity of transaction participants.
7.8.10 Clearinghouse Encryption & Security
Encryption is highly advantageous in the operation and management of a
virtual clearinghouse acting as a transaction intermediary. Due to the highly
sensitive
nature of the special services that clearinghouses can provide, specific
objects within
or managed by a clearinghouse, such as bid pools or tax escrow accounts, can.
be
encrypted separately, in addition to the general encryption placed on the
administration and operation of the clearinghouse. Additionally, since most
clearinghouses will interact with other repositories, clearinghouses, devices,
and other
systems, the communications channels to and from clearinghouses, and the
2o transmissions themselves, preferably are, and in many cases must, be
secured through
the use of encryption.
Specific embodiments of this invention allow for the creation of secure
clearinghouses wherein data (both system data and account data) can be
encrypted in
transit, at rest, or during processing. In certain particular forms of these
embodiments, multiple layers of encryption, e.g., stored encrypted data that
is
encrypted a second time during transmission, are also supported. In most
instances,
all data pertinent to the operation and well-being of a clearinghouse is
encrypted,
although several embodiments permit non-sensitive data to remain unencrypted.
These encryption services can be provided in hardware, software, or a
3o combination of hardware and software. Encryption engines may be internal or
external to a clearinghouse computer system, or may be included within one of
its
various subsystems. Encryption and decryption duties can be split between
multiple
139
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
encryption engines without loss of security. Use of a particular
encrypting/decrypting
system does not preclude the simultaneous use of other encrypting/decrypting
systems.
7.9 Virtual Naming Systems
The present invention provides a system and method for the establishment of a
Virtual Naming System (VNS) that provides a directory of known systems and
devices, and system and device addresses which can be queried and disclosed to
inquirers. In various embodiments, known systems can include repositories,
clearinghouses, labeling systems, and other naming systems. The naming system
allows known systems and devices, and system and device addresses to be
aggregated
into a centralized, searchable database. When aliases are used, disclosure of
the
underlying system or device address can be restricted.
In certain embodiments, the naming system associates one or more system or
device names, addresses, andlor corresponding aliases, with a digital
certificate. In
~5 this manner, the digital certificate can be referenced in a transaction to
automatically
lookup the underlying system or device name, address, or alias. Alternately,
the
validity of an system or device name, address, or alias for use in a
particular
transaction can be verified by examining the veracity of the digital
certificate.
Access to a naming system may in some embodiments require the use of an
2o authenticating token. Use of authenticating tokens limits the authorized
inquirers of
the naming system to known or authenticated parties. The naming system itself,
and
various objects within it, including, but not limited to its directories,
lists, digital
certificates, digital signatures, and access to those objects may be further
secured
through the use of the same or a different authenticating token.
25 Various levels of access may be required of different portions of the same
naming system. For example, inquiry to the naming system may be allowed for
any
requestor, but control of a specific name definition (with the ability to make
changes,
additions, or deletions of information content) may be restricted to
authorized entities.
Additional security could be imposed on the digital certificates and/or
digital
3o signatures such that a change might require a specialized authenticating
token such as
a fingerprint or other biometric scan.
140
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.9.1 Search Requests
A naming system can in certain embodiments perform a requested search to
find the appropriate system or device transaction routing information for an
inquirer
based on presentation of a system or device name, alias, or other identifying
information. In some cases the search may be inexact, producing multiple
potential
matches which the inquirer may peruse or use to refine the search criteria.
7.9.2 Ownership Certificates
In some preferred embodiments, the naming system can participate in
electronic commerce activities by verifying the identity of a system or device
owner
and/or operator to transaction participants using digital certificates. The
naming
system can manage this identification process by activating, authenticating,
creating,
deactivating, destroying, evaluating, generating, implementing, maintaining,
modifying, processing, registering, and/or otherwise manipulating a lists) of
one or
more system or device ownership certificates. Using this mechanism, the naming
~ s system can certify the identity and legal ownership of a system or device,
a necessary
precursor to creating a valid digital contract. The naming system can
supplement the
identity information in a digital certificate and/or digital signature by
providing
additional details, such as organization name, operator name, physical
location,
authorized agents, insurance requirements, insurance coverage, shipping
preferences,
2o authorized shippers, routing information, approved
partners/suppliers/vendors or other
useful commercial details.
7.9.3 Naming Systems: An Analogy
To understand certain functions that can be imparted to naming systems, it
may be helpful to make an analogy to an Internet Domain Name Service (DNS). An
25 Internet DNS provides the ability to lookup a computer name such as
www.vassets.com, which returns the IP address of 216.147.125.58. Alternately,
the
query could look up the IP address and return the name for the associated
computer.
Using a service such as WHOIS, additional information can be obtained from the
domain name registry, including the name of the owner, the administrative
contacts,
3o associated e-mail addresses, and other contact information. Like a DNS, a
naming
system can be synchronized periodically with one or more repositories to
remove
141
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
outdated entries, automatically generate new entries, and add or remove
corresponding information. Similar to a DNS, a naming system can automatically
propagate entries and corresponding information. However, a naming system
offers
new, unique and non-obvious improvements over typical DNS-type systems, the
most
important of which include: the incorporation of integrated digital
certificate
generation, presentation, validation, and verification systems; the automated
propagation of digital certificates, disclosure rules, and security
information to other
known and trusted naming systems; and incorporation of aliases for
repositories,
clearinghouses, labeling systems, naming systems, and/or devices.
~0 7.9.4 Naming System Encryption & Security
In certain embodiments, some or all of the information stored or processed
within a naming system is encrypted. Additionally, some or all of the
information
communicated between the naming system and external entities, including but
not
limited to inquirers, authorized users, repositories, clearinghouses, labeling
systems,
~5 access devices, other naming systems, and/or other interfaced systems can
be, and
usually is, encrypted.
7.10 Virtual Labeling Systems
The present invention provides a system and method for the establishment of a
Virtual labeling System (VLS) that provides a directory of account tokens and
aliases
2o for those tokens. The labeling system creates a lists) of labels that can
include
known repositories, account tokens, aliases, digital certificates, and digital
signatures,
which can be queried and disclosed to inquirers. Labeling systems allow
account
VINs and other account access tokens from one or more repositories to be
aggregated
into a centralized, searchable database. Each account token can be stored with
the
2s address of the source repository. Additional attributes may also be
associated with
each account token, including such information as account status, names of
individuals or business entities controlling the account token, and
descriptive
information regarding the purpose of the account. In some embodiments, each
account token is stored with one or more aliases that can be used in place of
the
3o account token in transactions with a repository. When aliases axe used,
disclosure of
the underlying VIN or other account tokens can be restricted.
142
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
In some embodiments, labeling systems associate one or more VINs or other
account tokens, and corresponding aliases, with digital certificates or
digital
signatures. In this manner, a digital certificate or digital signature can be
referenced
in a transaction to automatically lookup the underlying VIN or alias.
Alternately, the
validity of a V1N, of another account token, or an alias for use in a
particular
transaction can be verified by examining the veracity of the digital
certificate or
digital signature.
An analogy which may help impart an understanding of labeling systems is
based on an electronic telephone number directory (ETND). Like an ETND a label
can be searched, returning a list of matching names, aliases, accounts, and/or
other
identifying information such as addresses. In certain cases, an address or
other
informational attributes can be searched returning the name (or alias) and the
number.
However, a virtual labeling system offers new, unique and non-obvious
improvements
over typical ETND systems, the most important of which include: the
recognition and
maintenance of the distinction between public and private accounts; the
separation of
ownership and control information from transaction participation information;
and the
inclusion of multiple layers of aliases that can substitute for any portion of
the
underlying information. In particular, a virtual labeling system provides an
additional
layer of indirection for the manipulation and reporting of an underlying
account's
2o information without exposing the details of the account.
Label systems support similar operations in that the list of virtual account
labels can be searched using either a VIN, an alias, a descriptive attribute,
or other
token, returning a set of matching results. Search results could contain
additional
information such as the name and routing address of the associated repository,
other
2s descriptive information associated with the label, or corresponding digital
certificates
or digital signatures. Like telephone directories, labeling systems can
support the
concept of an "unlisted" number. In this case the labeling system can verify
the
existence of a label without disclosing the associated account numbers or
other related
information.
3o In most embodiments, access to a labeling system may require the use of an
authenticating token. This limits the authorized inquirers of the labeling
system to
known or authenticated parties. Other labeling system obj ects, including but
not
limited to the directories and lists themselves, digital certificates, digital
signatures,
143
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
and access to these and other objects may be further secured, requiring the
use of the
same or a different authenticating token. Various levels of authority may be
required
to access different portions of the same labeling system. For example, access
to the
label directory may be granted to any requester, but control of specific label
definitions (with the ability to make changes, additions, or deletions of
information
content) may be restricted to a limited group of authorized entities.
Additional
security may also be imposed on the digital certificates andlor digital
signatures such
that a change might require a specialized authenticating token such as a
fingerprint or
other biometric scan.
~0 7.10.1 Label Generation & Selection
Various labeling system embodiments allow for multiple types of labels with
various means of generating them. Labels can be generated in random or non-
random
fashion, and may be user-selectable or randomly assigned. Six basic
combinations of
generation and assignment include:
1) System generated non-random labels, user selectable
2) System generated non-random labels, system assigned
3) System generated random labels, user selectable
4) System generated random labels, system assigned
5) User generated non-random
6) User generated random
~ 5 System and user generated non-random labels are typically pre-selected
static
identifiers, such as words in Webster's Dictionary, phrases, or various
predetermined
or allowed combinations of letters, numbers, and other symbols. The difference
between user and system generation of labels rests in the ability of the
system, but not
the user, to know which labels exist or can be made to exist within the
boundary
2o conditions set up within the label generator, without revealing whether a
label is
currently in use. The system typically has a large pre-selected list or allows
user
selected non-random labels, which are more personal.
Randomly generated labels are typically dynamically generated using a non-
random mathematical functions) or computerized algorithm(s). Alternately, a
25 random number generator can be used as an integral part of the label
generation
mathematical functions) or computerized algorithm(s). The random number
144
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
generator may be based upon a pseudo-random number generator, tied to a time
clock, or supported by internal or external computer devices.
System-assigned labels can also be assigned in either a random or non-random
fashion. Non-random assignment can include any of several types of queuing
s mechanisms, such as First In, First Out (FIFO), Last In, First Out (LIFO),
or user
selected via First Come, First Served (FCFS). When the system randomly assigns
a
label, the assignment process is typically performed through the use of a non-
random
mathematical functions) or computerized algorithm(s), with variations on these
functions and algorithms as described previously.
Labels in the form of temporary or permanent aliases can also be generated
dynamically upon inquiry by the labeling system. Using this mechanism, a label
server can support specialized transactional requirements by restricting
disclosure of
an underlying VIN(s) and other identifying information, yet disclosing
sufficient
routing and address information to facilitate the completion of a transaction.
~5 7.10.2 Account Identification & Directories
In preferred embodiments, a labeling system can be used by inquirers to
search for an appropriate VIN, and where necessary, repository transaction
routing
information, in response to presentation of a name, alias, or other
identifying
information. In some cases, the search result may include multiple potential
matches,
2o which the inquirer may peruse and use to make a selection or refine the
search
criteria.
A labeling system may be used to provide a public directory of inbound-only
accounts. In-bound only accounts have constraint sets such that they can be
used for
receiving payments (credits) but are restricted from providing general purpose
25 outbound transfers (debits). In this manner, businesses or individuals can
publish
their own inbound-only account to be used for making payments or sending gifts
to
individuals without fear that the account numbers would be compromised or
misused.
Labeling systems can also provide other directories of labels, ranging from
lists of
active labels, inactive labels, and/or allowed, pre-generated but as yet
unassigned
so labels, to name a few.
145
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.10.3 Digital Certificates & Digital Signatures
In other preferred embodiments, a labeling system can participate in
electronic
commerce activities by verifying the identities of the transaction
participants using
digital certificates and digital signatures. Using these objects, the labeling
system can
facilitate electronic contracts. A label server can supplement identity
information in a
digital certificate and/or digital signature by providing additional details
such as
organizational structure, approval levels, authorized agents, insurance
requirements,
insurance coverage, shipping preference, authorized shippers, routing
information,
approved partners/suppliers/vendors or other useful commercial details.
In a simple model, a labeling system acts as the certification authority
providing directory services through which a party transacting business with a
subscriber to the labeling system may look up the subscriber's identity. The
digital
certification and/or digital signature of the subscriber can be verified for
authenticity
and confirmed as valid and not expired. The labeling system thus acts as a
third party
~ 5 confirming the identity/identities of a transacting party/parties to
reduce risk. The
subscriber enters into a contractual relationship with the certificate
authority, agreeing
to initially submit accurate information, notify the certificate authority
when the
certificate requires an update or revocation, and to take care to maintain the
integrity
of any private encryption keys.
2o In a more complex model, a labeling system containing the certificate
authority is split into two discrete business components: a local registration
agent and
a certificate utility. The local registration agent provides a meaningful
level of
scrutiny over decisions to issue certificates. The certificate utility
provides only the
technical services associated with issuing certificates and maintenance of a
certificate
25 revocation list, and has no direct contractual relationship with either the
subscriber or
relying parties (those relying on the certificates). The local registration
agent interacts
with subscribers and potential subscribers to create their certificate. The
certificate
utility presents the known certificates pertaining to the subscriber's
identity to relying
parties upon request. The digital certification and/or digital signature can
be verified
3o for authenticity and confirmed as valid and not expired.
In certain transactions, both parties must be subscribers to a certificate
authority, though not necessarily the same one, allowing the identity of the
both the
146
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
buyer and seller to be confirmed. The certificate authority may be contained
in a label
system or housed in an independent certificate system.
In a preferred embodiment, the label system automatically generates labels for
some or all VINs in one or more repositories for use as a routing and
information
lookup. When a clearinghouse is presented with a transaction to process, it
must
identify the participating repositories and accounts. If the clearinghouse is
unaware of
one or more transaction participants, it can use the label service to discover
the
existence of the repository and/or account. To be of assistance, the labeling
system
must be aware of the existence of specific repositories and optionally the
accounts
that reside in each repository. To keep track of large volumes of accounts and
corresponding VINs, the label system supports the en masse creation of labels,
deriving a label from each published VIN. In some cases, a published label may
be an
exact copy of the related VIN, or for security purposes may be a custom-
generated
alias to be used in transactions.
~5 In another embodiment, the label system can generate a label or alias for a
dynamic VIN(s). The label or alias acts as an indirect handle for the dynamic
VIN,
whereby the current value of the dynamic VIN can be found using a search query
that
includes the label or alias.
In some implementations, labeling system services may be integrated with a
2o repository and/or clearinghouse. In this instance, the labeling system is
eliminated as
an independent system, and becomes a subsystem of the repository andlor
clearinghouse. In other implementation, the labeling system may be co-located
on the
same computer system which simultaneously houses a repository and/or
clearinghouse.
25 With such combinations security is enhanced, communications time is
reduced, and system stability is improved. Security is enhanced because the
labeling
system co-resides with the repository or clearinghouse, whereby security is
maintained for the entire computer system, not just individual components. As
an
integral component, the repository and/or clearinghouse no longer requires a
3o communication channel to the labeling service, speeding processing time.
When both
the labeling system and the repository andlor clearinghouse reside on the same
147
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
computer, the computer is either available or not; when the components are
hosted on
separate computers, one may be available even when the other is not.
However, co-location of the components improves system stability at the cost
of scalability and fault-tolerance: a single computer system may not be able
to scale as
efficiently when operating three distinct subsystems, as would three separate
computer systems, each with its own subsystem; a single computer system may
not
have the same redundancy as three separate computer systems.
In other implementations, multiple labeling systems are used to form a
redundant, fault-tolerant infrastructure for account addressing and inter-
repository
communications.
7.10.4 Labeiing System Encryption & Security
In some embodiments, some or all of the information stored or processed
within the labeling system is encrypted. Additionally, some or all of the
information
communicated between the labeling system and external entities, including but
not
limited to inquirers, authorized users, repositories, clearinghouses, naming
systems,
access devices, other labeling systems, and/or other interfacing systems, is
encrypted.
7.11 Access Methods
Specific embodiments of the main aspects of this invention permit the use of
multiple communications devices, chained together in such a way as to allow an
end-
2o user the ability to access an account, and conduct transactions, from a
variety of
sources. Allowing disparate internal and external devices to communicate with
one
another affords a variety of mufti-network configurations, all the while
providing a
seamless connection for the end-user.
In general there are three major sets of networked connections that have been
presented in this invention: private networks, public networks, and private-
over-
public networks. A private communication network is not physically accessible
to the
public. A public communication network, such as the Internet, is open to all.
Private-
over-public networks establish secure and possibly encrypted connections,
affording
private communications over publicly accessible infrastructure. An example of
a
3o private-over-public network is the use of a Virtual Private Network (VPN)
to bridge
148
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
multiple sites using a public communications backbone such as the Internet. In
addition to "direct" connections using these various networking schemes,
clearinghouses can participate as intermediaries in the communications
connections.
Communications between transacting parties (which may include any number of
repositories, clearinghouses, devices, or external systems) can be conducted
using one
or any combination of network schemes as a transmission is relayed from source
to
target.
It is likely that an inter-networked configuration of repositories and
clearinghouses would use a combination of all three communications
technologies.
1o Clearinghouses, naming systems, and label systems are likely to be
interconnected on
a private communications network connecting multiple, geographically dispersed
redundant operations centers. Discrete repositories, federations of
repositories,
distributed repositories, and distributed-federated repositories may be
connected on a
private communications network, but more likely, where guaranteed performance
is
not a requirement, would use a VPN. The VPN will guarantee secure, encrypted
communications connections despite routing over potentially public lines.
Firewalls
and other security techniques will be used to protect private portions of the
networks,
but customers will need to be able to interact with and manipulate their
accounts.
This self service activity could be supported over public communications
networks
2o such as the Internet using web browsers or the phone network via touch tone
and
voice recognition response systems. Additionally, self service activities
could be
performed using wireless Internet and phone networks through various input
devices
(e.g., hand-writing recognition systems for Palm-like devices; touch-tone,
email, or
voice recognition response systems for cellular phones). All three techniques
may be
required for the optimal configuration of networked repositories,
clearinghouses,
naming systems, labeling systems, and supporting infrastructure.
7.11.1 Private Networks
Private communications networks have long been used for the construction of
financial networks. The advantages of private networks are the ability to
provide
3o physical security, the ability to run proprietary communications protocols,
and the
ability to limit access to the network to specific parties. The disadvantages
of private
networks are the significant construction and operating expense, the high
level of
149
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
maintenance required, and the need to administer the infrastructure. Examples
of
private networks include most ATM networks, credit/debit card networks, and
certain
communications networks, such as the Apollo Reservations network which serves
as
the back-bone of United Airlines reservation system.
7.11.2 Public Networks
Public communications networks such as the Internet and the telephone
network provide general-purpose connectivity that is well suited fox customer
self
service access and information distribution. The advantages of public
communications networks are easy access from many locations, standard
communication protocols, and distributed controls without any central point of
failure.
The disadvantages of public communications networks are unpredictable
performance
and minimal security. Other examples of public networks include the broad
spectrum
of cellular phone and other radio frequency networks.
7.11.3 Private-0ver-Public Networks
Virtual Private Networks use encryption to provide networking that is
effectively private over public communications channels. The advantages of a
VPN
solution are reduced costs (versus a private network), standard communication
protocols, and the ability to limit access to the network to specific parties.
The
disadvantages of VPNs are extra expenses (over the cost of the public network
2o infrastructure), including a moderate level of administration and
maintenance
required, and unpredictable levels of performance.
7.11.4 Communications Devices
Access devices are categorized into major classifications of self service
devices, agent-operated devices, distributed devices, stand-alone system
devices,
closed system devices, and other external system devices.
Self service devices include, for example ATMs, telephones, fuel pumps,
vending machines, kiosks, electronic commerce (including phone, wireless, and
web),
as well as ticketing and ticket dispensing machines.
Examples of agent-operated devices include retail point-of sale (POS) devices,
so cash registers, billing systems, collection systems, banking systems,
government
lso
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
offices accepting fees, fines, and taxes, as well as services provided by
vendors
including accounting, legal, and other support services.
Illustrative of distributed devices are wireless devices such as pagers,
cellular
and other portable phones, personal digital assistants (PDAs), laptop
computers,
desktop computers, network computers, network appliances, set-top boxes for
televisions, and satellite systems.
Stand-alone system devices include, for example, smart cards, fare cards,
electronic wallets, memory sticks, and secure device memory cards (SDMC)
Closed system devices include private buying networks, micropayment
systems, digitized cash, and electronic coins. Other external system devices
include
the banking system, the interbank transfer system (such as S.W.LF.T.), private
wire
services (such as MoneyGram and Western Union), the Federal Reserve and other
central banking systems (such as FedWire), credit card networks (such as AmEx,
Visa, MasterCard, Discover/Novus, and DinersClub), and the Automated Clearing
~ 5 House networks (for processing of paper and electronic checks).
Additionally, a
clearinghouse can also act to coordinate and translate communications between
two
different types or models of devices.
7.11.5 Access Constraints
In most preferred embodiments, account and system owners can place
2o constraints on both access methods and access devices. Like constraints in
general,
access method constraints place restrictions, in this case restrictions on the
use of a
particular access method or set of access methods. These restrictions can be
invoked
on a wide range of obj ects, some examples of which include: a particular
system
and/or device, a class of systems, a class of devices, a class of services
offered by a
25 system and/or device, and/or a particular type of transaction. To
illustrate, consider a
common, everyday ATM. These devices typically communicate over private
networks. Thus, in order to further secure communications to and from an ATM
machine, a set of constraints might be invoked such that:
~ the ATM can only communicate through a private network, i.e., other systems
will
3o not acknowledge a communications from an ATM on a public network, or a
private-over-public network, and
151
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
~ the ATM may only connect directly to a clearinghouse or repository, and may
not
use routers, hubs, concentrators, or any other intermediary.
Access devices may also have constraints imposed directly or indirectly on
them. These constraints help improve security by minimizing the ability of
unauthorized parties to interfere with the transmission or receipt of data
between these
devices and various systems.
7.12 Attributes
In a very general but trivial sense, everything in the universe has
attributes. In
its broadest definition, an attribute is a quality that a "thing" possesses
through which
one can compare and contrast things of the same type. For example, people,have
attributes such as age, height, weight, and sex; retail products typically
have attributes
such as color, size, and style.
Attributes only have meaning as a part of something else even though they
have individual characteristics that can be manipulated. As an example,
consider the
15 attribute weight. Weight as a concept has meaning, generally how heavy
something
is, and specifically, the force of gravity exerted by a particular amount of
mass. An
attribute, weight, with a value of 200 kg, offers no clues as to whether this
is a little or
a lot. In fact, the 200 kg weight will have differing meaning depending on
whether it
is the weight of a Sumo wrestler or a car.
2o Attributes typically exist within dimensions. Dimensions are the spectrum
of
related possible qualitative and quantitative differences one can impart.
Typical
dimensions include such things as time (wherein the quantity can be expressed
in
days, weeks, months, or hours) or distance (inches, meters, or miles). Other
dimensional groupings are not based on physical distinctions or units of
measurement,
25 but rather qualitative or logical distinctions having to do with, for
example,
municipalities (site, regions, areas, city, county, or state), organizations
(group,
department, division), or products (part, assembly, unit).
In addition to an analysis of the presence or value of a particular attribute
or
set of attributes, attributes can also be combined to provide metrics. Metrics
are
3o numerical ratings that facilitate quantitative comparisons. Metrics may be
based upon
simple counts, complex formulas, grades, or flow rates. Most metrics describe
the
1s2
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
performance of some process or use over a period of time such as a velocity in
kilometers per hour, service calls per shift, or liters per minute. Other
types of
common metrics are percentage complete and gauge readings (e.g., pounds per
square
inch of pressure). Metrics can be captured in real-time (e.g., flow rate,
velocity,
acceleration) or derived from a review of available data (e.g., percentage
complete,
trend line). Metrics are often stored or displayed as "derived" attributes,
which
include such common things as for example, the velocity of an automobile
displayed
in miles per hour, or the current price of a security in dollars per share.
This invention includes both general and special attributes in two classes of
1 o systems, one using virtual accounts, the other using conventional
accounts. In both
cases, the attributes described are not necessarily limited to the trivial
information
attributes associated with everyday objects, but rather attributes focused on
enhancing
the ability of an account owner to manage the risk associated with accepting,
acquiring, managing, and maintaining assets, and conducting transactions with
these
assets.
7.12,1 Traditional Asset Management System Attributes
In most present-day asset management systems, a standard set of attributes
exists on the system, on the accounts, and in special cases, for certain types
of account
content. Examples of typical attributes for the aforementioned systems and
objects
2o are listed in the table below.
System Attribute
Bank account account type (e.g., checking,
savings)
account number
bank number/identifier
current balance
currency type
opened on date
owner's name
owner's address
Credit card account type (e.g., secured,
unsecured)
account number
issuer number/identifier
current available credit balance
credit limit
opened on date
owner's name
153
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
owner's address
Securities account account type
account number
brokerage nurnberlidentifier
securities owned
current available balance
margin limit
opened on date
owner's name
owner's address
Refernng again to the broadest possible definition of attributes, some systems
offer additional user-selectable attributes over the appearance of their
associated
financial instruments, e.g., Discover card users can choose a credit card with
one of a
number of different pictures; banks offer a variety of check types and styles.
Again,
these are trivial attributes that do not offer an end-user any reduction in
risk in the
misapplication or fraudulent misuse of assets, nor provide any additional
control over
approved uses for those assets.
These limited sets of attributes have done little to protect end-users, and in
fact
are more often than not simply a means for system managers to exercise greater
control over an end-user's assets. For example, consider some of the
additional
attributes that most credit card companies track regarding account usage. In
an
attempt to reduce the amount of fraudulent activity, credit card companies may
track
such characteristics as the volume of activity on an account, or the locations
in which
~ 5 an account is used. When they feel that there is suspicious activity, they
may deny
pending transactions or even seek to notify the account holder. However, this
is a
reactive move, typically performed after an account has already been violated,
and
sometimes even when it has not.
7.12.2 Improvements to the State of the Art
2o As expressed in several embodiments, the current invention allows for
advanced end-user control of the attributes of their accounts, the content of
their
accounts, and their transactions, both in traditional systems and in more
advanced
systems using virtual accounts. For both types of systems, three new types of
attributes have been afforded: user-defined, user-selected, and user-
determined.
154
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
User-selected attributes are the simplest of the three types. A system
containing user-selected attributes offers a list of possible attributes that
an account
owner can select and apply. Although the attribute's design and function is
owned by
the system of record, account owners have the option of which attributes to
apply, in
what order, and when. For example, instead of one global system-generated
transaction limit for all accounts, an advanced asset management system could
allow
end-users to select one, some, or all of the following attributes:
~ Running daily transaction total
~ Running weekly transaction total
~ Peak transaction value
However, like the items available at a cafeteria, account holders in systems
with user-
selectable attributes can only select those attributes presented on the menu,
and only
in the form or with the functionality as determined by the system.
Since the cost of tracking and maintaining information, though negligible, is
not free, systems can be designed such that these user-selectable attributes
are offered
on a for-fee basis. Thus, end-users can select or not select a given attribute
to be
tracked based on the value of doing so, as perceived by the respective user.
User-determined attributes, a second, more comprehensive type of attribute
covered in several embodiments, allow account holders to determine specific
attribute
2o characteristics across selected dimensions, and ranges or limits on these
characteristics. Thus, an attribute tracked for an account, such as the time
from the
last access, can be expressed in a unit of time (e.g., hours vs. days) as
desired by the
account holder. More detailed examples would include such metrics as current
amount spent, by month, in thousands of US dollars. Expanding on the preceding
example:
~ Running transaction total . . . by day
or
by week
~ Peak transaction total . . . by day
or
lss
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
by week
~ Peak transaction total . . . by merchant
or
by transaction type
Thus, instead of being restricted to the menu of the cafeteria, user-
determined
attributes allow an account owner the ability to control certain functional
parameters,
as if cafeteria manager was allowing them to determine the mix and match of
portions
and items within limits.
The most advanced systems of this invention offer user-defined attributes. In
a user-defined attribute the system affords sole control over the constitution
of the
attribute to the account owner. Whatever information the system can track is
available to an account holder, can be manipulated at their convenience to
suit their
wishes, and presented in any dimensions that they desire. Expanding again on
the
previous example, an account holder could implement a user defined metric
which
calculates bi-weekly transactions, since they get paid on a bi-weekly basis,
or they
could have any of the above metrics in the form of Euros or Yen.
These additional attribute types offer the ultimate in information
flexibility.
End-users can for the first time configure the information tracked about their
account
~5 in any way that they see fit. By offering such attributes, advanced systems
free end-
users from having limited information on which to make choices, and with other
improvements and advancements conveyed in additional embodiments, can pro- y
actively manage their accounts.
With these newfound attribute types, end-users can for the first time grade
2o their systems by the information that they can track, thus affording
account owners
the ability to make value judgements as to the true risk to which their assets
are
exposed by these systems. And these types of features become exponentially
valuable
when combined with other advanced features such as user-controllable
constraints, as
provided in additional embodiments within this invention.
156
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.12.3 Content Attributes
Details of content are contained in attributes of assets and non-assets. For
example, attributes of most currencies would include the country of issue and
denomination. Attributes of deeds and titles might include the issuing
jurisdiction, the
location of the property, the kind of property (e.g., improved or unimproved).
Attributes of credentials might include the issuing authority, the expiration
date, and
any restrictions or limitations. For example, the attributes of a driver's
license issued
by the state of Virginia could include the driver's date of birth, the license
expiration
date, and an information note detailing a restriction to driving while wearing
corrective vision lenses. Attributes of coupons might include a face value, an
expiration date, and/or a list of honoring merchants. Documents and other non-
assets
can be composed of many discrete attributes including creator, creation date,
update
history, document type, mailing/shipping/billing addresses, shipping methods,
quantities, detailed instructions, contract terms, and other legal
instructions.
~5 Some attributes exist at the asset type or document type level rather than
as
attributes of individual assets or documents. Examples of type attributes
include
number of digits present after a decimal point, for currencies, and, a lists)
of
acceptable exchange mechanisms and reporting requirements by country.
7.13 Constraints
2o A constraint is an imposed rule, including for example, a restriction that
limits
some activity to less than what a system is fully capable of performing in the
absence
of the constraint. A fairly common example is a speed limit, which reduces the
maximum possible velocity that traffic travels - especially when appropriately
supervised by law enforcement personnel. Other constraints are less obvious
but of a
2s more limiting nature, such as the difference in voltage and amperage in
different
electrical systems in countries around the world.
Constraints can be invoked on systems or obj ects, or on their attributes or
metrics. In particular, system constraints can impact objects, even though the
objects
do not have a means to measure or display the thing being evaluated. Consider
a car
3o without a working speedometer, the driver of which could still be given a
ticket if
caught speeding.
ls~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
A constraint may be enforceable but erroneous due to the absence of a given
value, even though the attribute is capable of being tracked and evaluated. As
an
example, consider a promotion for hair-coloring that plans on giving $100 to
the first
five women who appear with blonde hair. In this instance, the attribute being
evaluated is hair color, and the constraint limits the evaluation to the first
five blonde
females. In Los Angeles, this would probably be a 5 minute promotion; in Hong
Kong, the constraint might never be fulfilled.
This invention includes both general and special constraints in two classes of
systems, one using virtual accounts, the other using conventional accounts. In
both
1 o cases, the constraints described are not the trivial constraints
associated with everyday
systems, but ones which focus on expanding account owners' ability to manage
the
risk associated with accepting, acquiring, managing, and maintaining assets,
and
conducting transactions with these assets.
7.13.1 Traditional Asset Management System Constraints
15 Present-day financial systems and their concomitant financial media have
minimal constraint sets, most typically limited to available balance or credit
limit, or
with store-specific accounts or other closed systems (e.g., private buying
networks,
micro-payment systems), restricted to use at certain merchants or certain
locations.
For example, debit cards may have a daily withdrawal limit when used at an ATM
2o and a different daily purchase limit when used through the credit card
network. Both
of these constraints are typically set as system limitations that apply to all
accounts of
the same type, and often cannot be overndden even by customer service
representatives.
Additional constraints may be placed because of requirements for a specific
25 equipment infrastructure that must be established to facilitate merchant
participation.
In some cases, constraints may exist as a result of policies, regulations or
laws such as
the limitation of a single personal loan outstanding against a 401K account.
However, these constraints typically can not be manipulated by end-users,
even though they may impact the ability of end-users to use these systems or
media.
so These constraints exist to provide risk management to systems and systems
owners,
not end-users. Consider again the example of a credit card company trying to
determine whether a given transaction may or may not be fraudulent,
specifically, a
158
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
transaction originating at a location far distant from the account holder's
listed
address. Instead of a reactive assessment of a transaction that has already
been
committed, an advanced asset management system could allow the account holder
to
pro-actively determine and adjust the precise geographic areas in which
transactions
are allowed. Thus, the account holder could limit at least a portion of such
fraud
before it begins, correspondingly saving both the time and trouble associated
with
reviewing possible fraudulent transactions, and temporarily losing access to
their
accounts and assets as misappropriated accounts are closed and new accounts
opened.
7.13.2 Improvements to the State of the Art
Constraints, as expressed in several embodiments within this invention, have
been made significantly more flexible and comprehensive from the user's point
of
view. User-defined, user-selected, and user-determined constraints provide a
new
level of end-user accessible and controllable risk management. Their goal is
to
provide account owners with the ability to manage the risks that their
accounts face,
15 as they determine their own individual level of comfort with the risks
inherent in
conducting transactions in which assets and information must be exchanged.
These constraints are not restricted to the static IF-THEN-ELSE logic of
traditional software systems, but can be dynamically constructed and evaluated
using
data instead of just coded rules. Additionally, they can be incorporated into
2o individual objects within the systems themselves, enabling the constraints
to travel
system to system with the objects that they impact.
User-selected constraints are the simplest of the three types. A system
containing user-selected constraints offers a list of specific constraints
that an account
owner can select and apply at will. Although the menu of constraints is
established by
2s system.administrators, account owners have the option of which constraints
to apply,
in what order, and when. For example, account owners could apply a spending
limit
constraint (e.g., $25, $50, or $100) and a geographic constraint, among the
group of
constraints provided by the system.
User-determined constraints, a second, more flexible and comprehensive type
3o of constraints covered in several embodiments, allow account holders to
determine
specific values for the constraints they wish to invoke. Expanding on the
previous
example, an account holder could decide to apply a spending limit constraint
in which
159
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
the holder freely selects any value from within a range of values, e.g., a
$35/day limit
out of a range running from $5/day to $500/day.
The most advanced systems of this invention offer user-defined constraints.
Systems offering user-defined constraints afford sole control over the
constitution of
the constraints to the account owner. Expanding again on the previous example,
an
account holder could implement a user-defined constraint along any set of
dimensions
tracked by the system, such that they have a bi-weekly spending limit of
$1000.
These additional constraint types offer users greatly enhanced control and
flexibility. End-users can for the first time configure their accounts, and
the use of the
1 o contents and assets within, to suit their needs. They can also limit use
of and access
to their accounts in ways not offered in traditional systems. For the first
time, they
can pro-actively manage their accounts, allowing them to control the level of
risk.
7.13.3 Hierarchies of Constraints
In certain embodiments, constraints can be applied to objects in a
hierarchical,
15 layered fashion. In these cases, a constraint applied to a superior object
would be
inherited by every subordinate object beneath it. In one example a constraint
imposed
on a repository would be inherited by every account in that repository. A
constraint
applied to the primary account of a virtual account would be inherited by all
child
(and grandchild) sub-accounts. In this example, a child account constraint
would
2o have no effect on the parent or peer accounts, but would be fully inherited
by that
child account's children and grandchildren. In certain embodiments inherited
constraints cannot be overridden, deactivated, or deleted.
With respect to accounts, repositories and groups of repositories, this
invention offers several embodiments in which a repository that connects to or
is a
25 member of a larger group of repositories must abide by any constraints
applicable to
the larger group. Thus, an individual repository connected to a federation of
repositories, where the federation is part of a larger distributed-federated
group, which
in turn is connected to a still larger inter-networked group, would have to
abide by the
inter-network constraints, plus any new or more restrictive constraints from
the
3o distributed-federated group, plus any new or more restrictive constraints
from its
federation. Likewise an individual account within this repository would
inherit ali of
160
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
these constraints, plus any new or more restrictive constraints imposed by its
repository.
Constraints defined for an inter-network can apply to all connected
repositories and their contents, all clearinghouses, all naming systems, and
all labeling
systems that exist in the inter-network. This is useful to help ensure
compliance with
national and international laws that restrict the flow of certain assets. For
example, a
constraint could be defined for a US inter-network (which may still be bridged
with
other inter-networks) that restricts commerce and the interchange of funds
with
certain other countries to ensure compliance with laws passed by congress,
executive
orders, and court decisions.
Constraints can be defined for a distributed-federated group of repositories.
For example, that constraint might enforce a risk management policy of the
operator
that limits account balances to US$1 million. Similar constraints can be
applied to
distributed groups and federated groups of repositories.
15 Individual repositories can define additional constraints to further
restrict
activities of accounts contained in the repository. For example, a repository
may
define a constraint that limits the type of currency assets that can be stored
in accounts
or that restricts the maximum amount of an individual transaction.
Each account can have its own constraints, with virtual accounts offering a
2o greater degree of granularity than other traditional account types. Virtual
account
constraints can apply to the virtual account overall, and be inherited by
every public
and private sub-account of the virtual account, or it constraints can be
applied to
groups or classes of sub-accounts accounts including primary accounts.
Constraints
can be applied separately to both private and public accounts. An account
owner who
25 1 controls an individual account can, to the extent the system
configuration allows, add
or subtract constraints from the account at will.
Account constraints can be used by the account owner to personalize the
account and reduce the risk of fraudulent activity. For example, the owner
could
create and adjust as necessary, constraints on an account that limit the
geographic
3o region where the account may be used, restrict the types of merchants
accepted for
transactions, or cap the dollar amount of transactions for a specified period
of time
(e.g., a daily, weekly, monthly limit). Account constraints are particularly
useful for
161
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
parents who choose to move allowances to children's sub-accounts, making it
easy to
send money and restrict the spending of a high school or college student.
Within virtual accounts, collections of sub-accounts (either private or
public)
can be grouped together into domains. Constraints can be applied to such pools
of
s accounts regardless of the relationships of accounts in the pools to each
other. For
example, a virtual account with a large hierarchical tree of sub-accounts may
be used
by a family to manage the household budget, where all of the accounts used to
pay
bills are constrained from accepting any deposits, except when the constraints
a
temporarily and knowingly inactivated for account replenishment. This would
reduce
the incidence of accidental deposit of assets into accounts in which the
owners are not
expecting them. Another example of such a domain wide constraint would be a
constraint restricting withdrawals from accounts deemed to hold savings, such
as a
child's college fund.
Constraints can also be created on specific content held inside a virtual
~ 5 account. For example, a subscription held within a virtual account may be
constrained so as to be non-transferable. Another example might be a
restriction on
duplication of a digital asset such as a digital audio or video file. Currency
can be
constrained, for example, such that it cannot be exchanged for certain other
currencies. Securities may be constrained, for example, to be restricted from
sale
2o during a company quiet period.
7.13.4 Collections
Embodiments in which constraints exist in various levels of objects, or in
some hierarchy, are typically collected in a top-down fashion starting with
the
topmost set of constraints. First the constraints of the inter-network (if
any) are
25 collected. Then any additional constraints are collected from the
distributed and
federated group and so on through the hierarchy. As each constraint is
collected it is
combined with any already collected constraints using a mathematical union set
operation.
7.13.5 Contradictory Constraint Resolution
3o In most preferred embodiments, constraints that are more restrictive than
existing constraints are allowed, but constraints that are less restrictive
are invalid.
162
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
For example, a first constraint is collected that indicates that the maximum
purchase
transaction amount is US$10,000 for the repository. At the account level, a
constraint
exists which indicates that the maximum purchase transaction amount is
US$5,000.
Thus, for the of the sub-accounts within that virtual account, the most
restrictive
amount is US$5,000. However, a sub-account might exist with a constraint on
the
maximum purchase transaction amount of only US$800. For that sub-account, and
all
of its subordinate accounts, the limit is reduced to US$800, but other non-
subordinate
sub-accounts would still allow US$5,000 purchase transactions. If a sub-
account
attempted to create a constraint for a maximum purchase transaction amount of
1o US$7,500, it would be an invalid constraint because it is less restrictive
than the limit
imposed on the virtual account as a whole, and on any of its contained sub-
accounts.
Contradictory constraints may exist, but cannot be enforced. Within certain
embodiments unenforceable constraints are considered invalid and are disabled.
Consider constraints added at different dates. If a newer constraint would
cause other
~5 objects lower in the hierarchy to be in violation of the new constraint,
then the new
constraint is considered invalid. In one example, a repository may have
thousands of
accounts. The account with the highest U.S. dollar balance holds US$18,000. A
new
constraint created for the repository imposing a maximum account balance in
U.S.
dollars and with a limit of US$10,000 would be invalid, because at least one
account
2o would be in violation. Depending on the system configuration the constraint
may be
completely invalid and disallowed, may be disabled until the violation comes
into
compliance, or may be imposed on all accounts which are currently in
compliance,
but not imposed on out of compliant accounts until such time as they come into
compliance.
25 7.13.6 Deferred Constraints
Constraints may be created that might be invalid if they were immediately
enforced, but can be created for deferred implementation as of a specified
date. The
constraint is applied to active objects lower in the hierarchy only when they
would
have an opportunity to resolve the constraint violation. For example, an
account with
3o a current balance of US$18,000 is subject to a deferred constraint
specifying a
maximum current balance of US$10,000. Upon arrival of the specified date, the
163
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
account owner would have to hansfer or otherwise reduce funds to comply with
the
new constraint prior to commencing other account activity.
7.13.7 Boolean Operators and Precedence
Constraints may be simple expressions that can be evaluated with a simple IF-
THEN test condition or more complex expressions that require two or more
constraints to be combined together at the time of evaluation. Complex
constraints
can use the Boolean logic operators, AND, OR, XOR (exclusive OR), and NOT to
build conditional logic that would require multiple, nested IF-THEN tests. An
AND
is a Boolean logic operation that is true ifboth inputs are true. An OR is a
Boolean
logic operation that is true if any of the inputs is true. An XOR is true if
only one of
the inputs is true, but not both. A NOT is a Boolean logic inverter that
changes any
true input to false and any input false input to true.
For example, a virtual account has two constraints that are interpreted
differently depending on the Boolean logic operators. The first constraint is
that the
purchase transaction amount not exceed US$500. The second constraint is that
the
purchase transaction must be from a merchant located in the 48 continental US
states.
The following matrix summarizes the varying interpretations depending on the
Boolean logic operator selected:
Condition ~ Description
Purchase Transaction Amount The purchase transaction is accepted
< US$500 if
both the amount is less than US$500
and the
merchant is located inside the
continental US.
Merchant Located in continental
US
Purchases greater than US$500
or
originating outside the continental
US will be
rej ected.
Purchase Transaction Amount The purchase transaction is accepted
< US$500 if
OR either the amount is less than
US$500 or the
merchant is located inside the
continental US.
Merchant Located in continental
US
Purchases of less than US$500
from
outside the continental US and
purchases of
164
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
any size from within the continental
US will be
allowed.
Purchase Transaction Amount < US$500The purchase transaction is accepted
if
XOR oily the amount is less than US$500
or the
merchant is located inside the
continental US.
Merchant Located in continental
US
Purchases of less than US$500
will be
accepted from merchants outside
the
continental US, and purchases
of greater than
US$500 will be accepted from merchants
only
inside the continental US.
The NOT Boolean operator can be used to invert any condition, such as:
Condition Description
NOT Purchase Transaction Amount The purchase transaction is accepted
< US$500 if
the amount is greater tha~z US$500.
NOT Merchant Located in continentalThe purchase transaction is accepted
US if
the merchant is located outside
the continental
US.
The grouping and order of precedence during evaluation of Boolean operators
is controlled by standard mathematical operators such as parenthesis,
brackets, or
braces. The presence of parenthesis or similar mathematical operators allows
conditions to be evaluated in sets. For example, adding a third condition of a
weekly
transaction limit of US$2000 allows for a proportionally larger set of
evaluations as
shown in the following matrix (shown for an AND condition inside the
parentheses):
Condition Description
( ( Purchase Transaction Amount The purchase transaction is accepted
< US$500 if
botla the purchase amount is less
than US$500,
the merchant is located inside
the continental
Merchant Located in continental
US )
165
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
AND US, and the purchase would not
cause the total
( Total Weekly Purchase < US$2000 weekly purchase limit of US$2000
) ) to be
a exceeded.
( ( Purchase Transaction Amount The purchase transaction is accepted
< US$500 if
(a) both the amount is less than
US$500 and
the merchant is located inside
the continental
Merchant Located in continental
US ) US regardless of the total weekly
purchase
OR limit or (b) if the purchase, regardless
of
( Total Weekly Purchase < US$2000 ~o~t of location, would not cause
) ) the total
weekly purchase limit of US$2000
to be
exceeded.
( ( Purchase Transaction Amount The purchase transaction is accepted
< US$500 (a)
only if the purchase would not
cause the total
weekly purchase limit of US$2000
to be
Merchant Located in continental
US ) exceeded, or (b) once that limit
has been
XOR reached, only if the purchase is
both less than
( Total Weekly Purchase < US$2000 US$500 and from merchants located
) ) in the
continental US.
Parenthesis and other grouping and precedence operations can be nested
several times to create very complex conditions.
7.13.8 Integral Constraints
s Constraints can be integral parts of objects, such as repositories,
accounts,
content, or attributes. These built-in constraints are parts of the object's
structure.
Integral constraints can be processed internally to determine validity and
address
activity that applies to deferred constraints. When constraints are evaluated
at run-
time in response to a transaction, agent, alert, or trigger, the evaluation
engine can be
internal to the object being evaluated. Integral constraint engines are the
preferred
solution because they are tightly integrated with the storage of the data.
166
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.13.9 External Constraints
Constraints can be stored, processed, and evaluated external to repositories,
accounts, content, or attributes they reference. These external constraints
may be part
of an independent constraint engine. External constraints can be processed
externally
to determine validity and address activity that applies to deferred
constraints. When
constraints are evaluated at run-time in response to a transaction, agent,
alert, or
trigger the evaluation engine can be external to the object being evaluated.
Some constraints, particularly those related to proxy accounts for which a
connection to an external system is required, caimot even be tested for
validity until
1o the constraint is evaluated. In this case, the processing and evaluation
can occur
simultaneously.
External constraint engines are preferred when some or all of the data
necessary to evaluate a constraint resides external to the object being
evaluated. For
example, when processing an interaction with a proxy account interfaced to a
credit
card network, the constraint most likely will be evaluating conditions present
in the
underlying credit card network independent of the condition of the virtual
account.
7.13.10 Integral and External Constraints
A combination of integral and external constraint engines can be used for the
storage, processing, and evaluation of constraints. For example, a proxy
account for a
2o credit card may have integral constraints that limit the maximum purchase
transaction
amount and limit the valid list of merchants as well as an external set of
constraints
that include a fraud detection filter constraint and an available balance
constraint.
When integral and external constraints both exist, there can be and preferably
is an
implied Boolean AND condition such that both must successfully process and
evaluate the constraint.
7.13.11 Constraint Security
PINs, passwords and authenticating tokens can be required to create, destroy,
or otherwise manipulate constraints. In certain circumstances it will be
important to
provide a separate layer of security apart from the account or repository
security
3o because the constraint attached to an account, asset or other content can
be affected by
167
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
a change in the ownership and control. For example, if a pair of event tickets
has
constraints requiring that they not be separately transferred, the constraints
must be
able to survive a change in the ownership and control of the asset or the
account. This
will be of use in enforcing securities trading laws and securing documents
that retain
their carried constraints despite changes in ownership and control.
7.13.12 Constraint Encryption
Like other objects offered in this invention, particular embodiments allow for
encryption of some or all of the information stored, processed or communicated
to or
from a system, including its constraints. In particular, the constraints
within an
AAMS have the additional option of being encrypted independently from other
objects within the AAMS. Thus, even if a virtual account was fraudulently
accessed,
an illicit user may not be able to perform any activities with the account due
to the
presence of independently encrypted constraints that cannot be overcome.
7.14 Agents, Alerts 8~ Triggers
~ 5 In preferred embodiments, agents, alerts and triggers are available to all
systems, and to certain obj ects within the systems contemplated by this
invention.
Additionally, these services can be offered in pre-packaged templates, and as
various
types of user-defined, user-selected, and user-determined services.
7.14.1 Alerts
2o Alerts are real-time messages generated by system events, or created by
observers of events or current conditions, usually in response to pre-defined
thresholds. Alerts can be as simple as a notification of a successful
transaction
completion (e.g., the transfer of funds), or the availability of a coupon or
discount
offer. More complex alerts can be generated in response to observed
conditions, such
25 as the balance of available funds in an account falling below a pre-defined
amount,
such as one thousand US dollars. Alerts can be generated in response to a
system
activity such as a potential overdraft, such as when a pending transaction, if
allowed
to continue, would cause the outstanding balance of funds in an account to
fall below
zero. Alerts can also be generated as reminders of time-sensitive
requirements, such
3o as the renewal of a lease, the transfer of a deed, the renewal of a
credential, the
168
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
expiration of a stock option, the payment of an outstanding bill, or a
requirement to
pay a tax, fee, or fine.
Alerts are normally generated in real-time and can be responded to
automatically in real-time using triggers or agents. Alerts can require a
response or
may be purely informational. The alert may establish a stream of information
or be a
discrete message. When streams of data are provided, such as a stock market
ticker
feed of real-time or delayed quotes, the alert is used as a conduit to assure
a free and
uninterrupted flow of information.
Alerts may be time synchronized and thus guaranteed to arnve in a specific
order, or they may be asynchronous, allowing for any order. Queuing mechanisms
are typically used to propagate alerts and may include various synchronized
ordering
schemes such as last-in, first-out (LIFO) and first-in, first-out (FIFO)
queues.
Alerts can be marked as undelivered or delivered. Delivery flags can be used
to indicate which alerts have been previously examined, but not deleted, and
which
alerts have never been examined. Undelivered alerts can be set to
automatically
expire at a future date and time. An example of an automatically expiring
alert might
be the notification of a coupon or time sensitive discount offer that expires
at the same
time the coupon or discount expires. The receipt of a more recent alert
related to the
same topic can also cause expiration of the previous alert. One example of
alert
2o updating would be the replacement of a due-in notification (indicating the
imminent
arrival of previously ordered items) by an arnval notification (indicating
actual receipt
of the items). Another example might be a notification of a current account
balance
or credit line that is updated every four hours with each update automatically
causing
the prior alert to expire.
Alerts can act as containers for carrying information or documents of interest
to one or more recipients. The alert acts as a message header indicating the
kind of
content and perhaps providing summary level information or routing
instructions.
The content of the alert may be encrypted separately from the alert itself.
For
example, an alert may arrive from a billing system containing an encrypted
invoice
3o document destined for a specific account. The repository or clearinghouse
system
may scan the unencrypted header of the alert to identify the terms and due
date and
then forward the document to the appropriate repository and account. A
secondary
169
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
alert may be generated by an agent on or just before the due date to identify
unpaid
invoices that are close to becoming due, allowing for capture of discounts and
assuring that bills do not become unintentionally overdue.
Alerts are valuable because they identify actions that have occurred,
situations
requiring remedy, or information of interest. Alerts are also valuable because
they
can act as carrier containers to deliver valuable information and documents.
Without
alerts, account holders would have to manually search for information to see
if a
situation had happened already or potentially might happen.
7.14.1.1 Internal and External Alerts
An alert can be communicated or attached to any account, sub-account,
repository, clearinghouse, naming system, or labeling system, or the content
or sub-
components of such objects. Alerts can be generated internally by an AAMS,
VCHS,
VNS, or a VLS. These events can be propagated from one repository to another
directly or via a clearinghouse. Events generated by labeling systems, naming
15 systems, or clearinghouses can all be interchanged and propagated through
as many
intermediaries as necessary to reach the intended alert respondent.
An AAMS alert typically would be caused by a condition in a repository or in
an individual account within a repository such as an account status change, a
transaction verification, an overdraft condition, an attempted transaction
which
2o violates a constraint condition, or a potential security violation.
A VCHS alert typically would indicate an attempt to commence or complete a
transaction; an attempt to initiate or close contact with a repository, with a
labeling
system, with a naming system or with another clearinghouse; or the occurrence
of
transactional activity, bid or bid pool activity, or wager or gambling/gaming
pool
25 activity.
A VNS alert typically would be caused by a change in status of a repository
name or other attribute, the retrieval of information related to a repository,
or a change
in status of a digital certificate of ownership.
A VLS alert typically would be caused by a change in a status of a label or
so alias, an attempt to improperly access a label or alias, a change in status
of a digital
loo
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
certificate, the application of a digital signature, or a notification that a
label or alias
was retrieved.
Alerts can also be generated by external systems and devices, which include
but are not limited to externally interfaced systems, information providers,
and
interface devices. These external systems may be linked through proxy accounts
or
provide other specialized services such as tax and fee calculation. External
systems
may include providers of news or market data from stock, bond, currency,
commodity, or futures markets.
Proxy accounts and the transactions they interact with can be a frequent
source
of alerts. Proxy alerts often state the current status of an account linked by
proxy, or
provide information related to the success or failure of transactions. Typical
proxy
alerts may include available balance, available credit, transaction
approval/denial,
establishment of holds on funds, and changes in account status or ownership.
External systems may provide alerts that establish a stream of data such as
~ s market prices, discrete messages such as news items or press releases, or
one-time
messages related to specific events. Interbank transfer and settlement systems
such as
FedWire, ACH, CHIPS, S.W.LF.T.,.and the networks used by the various credit
card
and ATM providers are based upon alerts. Alerts can be generated by shippers
such
as UPS, FedEx, and the USPS to indicate receipt or delivery of packages that
may be
2o a triggering condition for the re-evaluation of an escrow. Any successful
interfaces
with those systems will require the acceptance, processing, and interchange of
alerts.
In order to be presented, alerts may require reformatting or other
restructuring using a
compatible format and signaling scheme.
External devices will often create alerts related to their status or pending
2s transactions. External devices that may typically create alerts include POS
terminals,
card processing intermediaries, fraud analysis and detection systems, and
ATMs.
Some wireless devices such as PDAs, phones, pagers, and other portable
convenience
systems may advertise their availability with an alert indicating their online
or offline
status. Such alerts may be used to automatically start and stop related alert
3o propagation that moves account, repository, or clearinghouse alerts
directly to an
account management device.
1~1
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Some external systems such as currency exchange services may provide both
streaming alerts containing frequently updated trading prices and specific
alerts
related to pending and confirmed trades.
7.14.1.2 Broadcast Alerts
Most discrete event alerts will be targeted to specific accounts or sub-
accounts. Most streaming events will be targeted to a specific repository or
clearinghouse. In some cases, the repository or clearinghouse will merely act
as a
conduit for further distribution of the alert to interested parties. Alerts
may be
broadcast to a preset list of subscribers, to all other known parties, to a
subset of all
known parties using some selection criteria, or to a channel. Channel
broadcasts
allow parties to connect and disconnect with the channel at will to listen in
on real-
time or near real-time alerts. Channel broadcasts are often used to monitor
market
conditions using sampling techniques or to watch for changes in status of
specific
devices such as ATMs (e.g., cash drawer stuck, out of cash, unable to
communicate,
~5 out of service, under repair, and back in service.).
7.14.1.3 Alerts Interfaced with Messaging Systems
Alerts may be propagated using internal pathways in, and external pathways
between, repositories, clearinghouses, labeling systems, and naming systems.
Pathways for message traffic include public, private, and private-over-public
2o networks. Most often when travelling over external or public networks, the
alert will
take the form of a packet-based communication using an existing published
protocol
including but not limited to Simple Mail Transfer Protocol (SMTP), Simple
Network
Management Protocol (SNMP), Wireless Access Protocol (WAP), or instant message
using current proprietary protocols.
2s Some alerts may be automatically displayed in chat rooms or similar
scrolling
window displays. Other alerts may be displayed using ticker interfaces,
charts,
graphs, or pop-up displays. In other interfaces, an icon may appear indicating
the
presence of an alert that can be retrieved at user request.
1~2
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.14.2 Triggers
Triggers are predefined action templates that are used to automatically
respond
to detected conditions. Triggers can be established for any account, sub-
account,
repository, clearinghouse, naming system, or label system or the content or
sub-
components of such objects. Simple triggers can be used to implement overdraft
protection by creating a conditional link between accounts - when funds
requested
from a first account exceed the available balance, an overdraft alert is
automatically
generated, which in turn triggers a pre-defined response that transfers from a
second
and/or other accounts) either a preset minimum or an amount equal to that
needed to
successfully complete the transaction. More complex triggers can be defined to
implement stock market orders on a given day, or on a good until cancelled
basis, or
to purchase or sell a security at a specific limit price based on preset price
thresholds.
This can be used to lock in profits or minimize losses in securities
transactions.
~ther useful triggers include those that automatically respond to conditions
~ 5 such as the expiration of a credential, license, lease, or other contract
to process
automatic renewals, possibly including the automatic authorization of one or
more
transactions. Triggers can be highly useful in the implementation of escrow
and
obligation accounts when they are used to initiate the release of funds from
buyer to
seller for successful transactions, and the recovery of funds for the buyer
when
2o conditions are not met within specific time limits.
Triggers can be chained to perform jobs. Each job step may be or include a
discrete trigger with a specific execution conditions) that includes) a test
of the
success, failure, or status of the prior step. Job step triggers can be linked
to invoke
other specific triggers synchronously, asynchronously, and/or in parallel.
25 Triggers may exist for repositories. These triggers can respond to
repository
alerts such as a request for a connection from an unknown device or
repository, by
initiating authentication activities. Repositories can use triggers to perform
planned
activities such as nightly sweeps of account balances into external systems
such as
FedWire.
so Triggers can exist for clearinghouses. These can respond to clearinghouse
alerts such as the evaluation of escrow conditions, bid pool activity, or
gambling/gaming pool activity. Clearinghouse triggers can also respond to
timers that
173
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
have elapsed or other counter- or clock-driven events. Clearinghouse triggers
can
cause the transfer of funds from a winning bidder's account to an escrow
account at
the close of an auction.
Triggers can exist for label systems. These can respond to label system alerts
such as the creation or destruction of a label, the expiration of a label, or
the
participation of a label in a query result. Label system triggers can also
respond to
timers that have elapsed or other counter- or clock-driven events. A label
system
could use triggers to automatically notify account owners of rejected proposed
labels
that are already in use.
Triggers can exist for naming systems. These can respond to naming system
alerts such as the creation or destruction of a name or alias, the expiration
of a name,
or the participation of a name in a query result. Name system triggers can
also
respond to timers that have elapsed or other counter- or clock-driven events.
Naming
systems can use triggers to automatically restrict access for private-access-
only
~ 5 devices that seek to connect to a system over public networks.
7.14.2.1 Triggering Conditions
Triggers can, for example, be caused to activate (test a set of conditions and
conditionally perform one or more actions) as a reaction to alerts, as a
result of a
clock event, or at the request of an agent. Triggers can activate in response
to the
2o detection of specific kinds or types of alerts such as an overdraft,
transaction activity,
lack of transaction activity, or external messages. Some triggers monitor
streaming
alerts for threshold conditions that are based upon formulas or other
mathematical
equations. Clock events can cause a trigger to activate, based on, for
example,
elapsed time (e.g., every n minutes, every x days, every z weeks), at specific
times
25 (e.g., market open, lOAM, midnight), at specific dates (e.g., January 1St,
April 15th,
December 25th), or on specific days of the week (e.g., first Monday of the
month,
every Friday, third Thursday).
7.14.2.2 Action Templates
Triggers may be based upon pre-defined action templates that can take many
3o different forms. Some may be simple built-in automation switches that are
turned on
globally for all accounts and sub-accounts in a hierarchy of accounts.
Examples of
174
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
global automation switches include those for automatic forwarding of messages
and
other alerts, for automatic propagation of all alerts to a parent in the
hierarchy, for
filters to delete or acknowledge alert types, or to delete categories of
alerts deemed to
be uninteresting.
Other triggers may be more specific to individual account conditions. For
example, a trigger may exist which imposes additional constraints when certain
conditions are found. For example, a sub-account used by a parent to
distribute a
clothing allowance to a teenage child may have a transaction limit of one
hundred US
dollars, a list of authorized merchants, and a list of authorized categories
of
merchandise that can be used. A trigger can be invoked to revise the spending
limit
down to five US dollars or create an alert for the parent's primary account if
a
transaction is attempted that would violate constraints. This could be used by
a parent
to automatically shut down a sub-account or just to monitor suspect
transactions
without prying into all sub-account transactions.
7.14.2.3 Internal and External Trigger Evaluation
Triggers can be evaluated and processed internal to an account, sub-account,
repository, clearinghouse, naming system, or labeling system, or the to
content or sub-
components of any such object. Triggers can also be evaluated and/or processed
in an
external system. Evaluation refers to testing the conditions specified within
the
2o trigger; processing refers to taking action to implement the goals of the
trigger. This
allows triggers to affect accounts linked to external systems via a proxy
relationship.
It also allows trigger activity to be separated from internal controls to
improve
security.
7.14.3 Agents
Agents are automated assistants that perform inquiries and take actions on
behalf of their owners. Agents can be used for many things, including but not
limited
to seeking out the best prices from multiple sellers, automating participation
in an
auction, automating the purchasing or selling of securities, negotiating the
terms and
conditions of contracts, bartering for goods and services, fording the best
odds for a
3o gambling/gaming wager, and automating the placing of wagers.
l~s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Agents can be proactive or reactive. Proactive agents actively scan, search,
or
peruse information sources for goods, services, alerts, and information that
meet their
objectives. Reactive agents wait for notification of an event, for example, by
an alert
or by a clock timer tracking elapsed time, waiting for specific dates, or
waiting for
specific days. Agents can have components that are both proactive and
reactive.
Agents can create and propagate alerts to notify other agents or account
holders of the results of inquiries or transactions. Agents can use alerts to
request
authority to proceed with specific lines of inquiry, negotiations, or
transactions.
Agents can be independent or dependent. Independent agents contain code
allowing for mobility or replication. They can jump from system to system
while
pursuing their quest. Dependent agents stay in a single location, but request
information and perform transactions with remote systems by communicating with
them.
Agents can exist for any account, sub-account, repository, clearinghouse,
naming system, or labeling system or for the content or sub-components of any
such
object. Account and sub-account agents act on behalf the entity that owns or
controls
them. For example, system agents can act on behalf of repository,
clearinghouse,
naming system, or labeling system owners. A repository system agent can
perform
actions such as scanning an exchange for products to offer to its account
holders,
2o distributing coupons or discount offers to members meeting certain
profiles, or
performing demand aggregation negotiations with a supplier. Clearinghouse
system
agents may perform actions such as scanning and comparing currency exchange
services for the lowest conversion rates, interacting with external systems
such as
credit card systems to coordinate batch settlement processes, evaluating
escrow
25 conditions, and automating the release of held funds when a hold has
expired.
Naming systems rnay use system agents for tasks such as identifying new
repositories
or verifying connectivity and routes to repositories already identified.
Labeling
systems may use system agents for similar purposes for specific accounts or to
automatically generate labels.
so 7.14.3.1 Internal and External Agents
Some agents are internal to an account, sub-account, repository,
clearinghouse, naming system, or label system, or to the content or sub-
components
176
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
of such objects. Other agents are external, such as those used to interact
with external
systems and proxy accounts.
1~~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Certain unique features and advantages afforded by advanced asset
management systems and virtual account-based systems are most readily
understood
when multiple embodiments axe considered together. A first set of embodiments
involves the advantages afforded by this invention to seven basic pricing
mechanisms
and attendant transfers of assets. A second such set details the freedom from
physical
device dependence brought about by this invention. In a third set, the
invention offers
new security enhancements to account holders in their efforts to limit
fraudulent use
of their accounts. The uses of and risk-reductions afforded the dynamic
generation of
tokens is conveyed in a fourth set of embodiments, while the use of this
invention to
advance the state of the art in the delivery and access of social benefits and
entitlements is offered in yet a sixth set of embodiments.
8.1 Pricing Mechanisms and Asset Transfer Systems:
When consumers and businesses purchase goods and services, there are a
~ 5 limited number of pricing mechanisms that can be used to determine the
purchase
price for the transaction. The pricing mechanisms for buyers and sellers can
be
classified as one-to-one, one-to-many, many-to-one, or many-to-many. In some
cases, virtual accounts can participate in each one of these pricing
mechanisms as
buyer, seller, or both. In other cases, the virtual account may only represent
one side
20 of the transaction, while a traditional account (e.g., checking, savings,
loan, credit
caxd) represents the other side, but the transactions are executed through an
advanced
asset management system or coordinated by a virtual clearinghouse.
Virtual accounts can contain the actual assets (e.g., currency, frequent flyer
miles, tickets, and subscriptions), digital goods (e.g., digital music, video,
and
25 publications), or deeds for the assets (e.g., real estate, vehicles,
property, and service
contracts). This permits assets to be directly exchanged inside virtual
accounts,
between virtual and non-virtual accounts, or to take place in real-world
exchanges
coordinated using virtual accounts and other objects in an advanced asset
management system.
178
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
8.1.1 The Advantages of Virtual Accounts
A number of patent applications and granted patents disclose purportedly new
business processes involving electronic or web-enabled versions of various
pricing
mechanisms or asset transfer systems, for both personal and commercial
transactions.
What is interesting to note however is that in all of these "updated" systems,
in order
for transactions to be completed to the extent that a seller will accept an
offer from a
buyer, there has to be an irrevocable guarantee of payment. Until today, that
guarantee was only available electronically through the use of credit or debit
cards.
Without credit or debit cards, these systems and patents simply would not
work.
The guarantee of payment is critical. Arguments could be made that such
systems could be made to work with checks, wire transfers, or some sort of
C.O.D.
arrangement, however, the premise behind all of these "updated" systems is
that a
buyer must agree to offer funds that are readily available so that sellers
will know that
the offers are legitimate. For sellers to participate, they must knows that
they will be
paid, i.e., that they buyer is making a fully funded offer which they will
not, and in
fact cannot, fail to consummate.
Credit/debit card authorization processes solve this problem. If buyers do not
have sufficient balances on their cards, their offers are never entered into
the system.
Thus sellers only see valid offers. Additionally, only under unusual
circumstances
2o will a valid creditldebit card charge be later rejected or rescinded. The
same cannot
be said of any other payment means: checks can be canceled with a simple stop
order;
wire transfers may never appear, and C.O.D. can be refused at its destination.
Virtual accounts change this. For the first time, cash can participate in
electronic commerce. Virtual accounts allow people to reserve a quantity of
cash in
'25 their accounts for use in a particular transaction, or to create
electronic escrow
accounts. This is an immense advancement to all of these new electronic
business
method inventions in that people without access to credit cards, or whose
current
credit limit has been reached, can still participate in these systems.
Additionally, a number of patents assert that they allow anonymous
so transactions for one or more participants. As has been documented earlier
however,
these claims are misleading. At best, prior inventions afford only
conditional, one-
way anonymity, i.e., transaction participants must identify themselves to the
system,
179
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
although that identification may be masked during a transaction. However, this
approach, by its very nature, is not truly anonymous since the systems must
know
who the transacting parties are. Additionally, their reliance on credit/debit
cards, as
mentioned earlier, further detracts from their arguments as to anonymity,
since
credit/debit cards, by their very nature, cannot be anonymous.
In virtual account-based transactions, such systems never need to know the
identities of the account owners. As with other bearer owned financial
instruments,
virtual accounts cannot be used to track identity. Thus, participants who wish
to be
buyers or sellers in one of these processes can completely shield their
identities only if
they use virtual accounts.
8.1.2 One to-0ne Transactions
8.1.2.1 Barter
Barter transactions are negotiations between two or more parties where goods
or services are exchanged. Parties usually exchange unlike assets, typically
goods
and/or services, occasionally supplemented by cash, to settle these
transactions. In
typical barter transactions, each party presents the actual goods or a deed to
those
goods for a simultaneous swap. Negotiations may cause either party to add or
subtract goods or services to or from their offer. The barter transaction may
be
coordinated by an agent or take place in a marketplace. Barter transactions
can also
2o take place between more than two parties. However, each portion of the
barter takes
place between only two parties.
Barter transactions can be executed using virtual accounts with unlike assets
being exchanged to complete a purchase between at least one buyer and at least
one
seller. A virtual account barter transaction allows buyers and sellers to
negotiate the
2s criteria for an exchange and then consummate the deal. The transaction may
be
executed using the assistance of an agent that brokers the deal by introducing
the
parties, values the property, coordinates the exchange of real-world goods,
and/or
certifies the transaction. The transaction may take place in a marketplace of
vendors
(sellers) who advertise their goods and then enter into specific barter
transactions with
3o individual buyers. Optionally, the buyer and seller may agree to use an
escrow
account to coordinate the appropriate settlement of the transaction. The
escrow
180
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
account may be managed by either the buyer or the seller, or by a third party
escrow
service.
Barter transactions using virtual accounts may take many forms, including
these examples:
~ Seller offers computers and consumer electronics for retail purchase at a
mall
store; buyer may barter with the seller to trade a new stereo for a used
computer
system; the buyer and seller meet to exchange goods
~ Seller offers the deed to a parcel of real estate which the buyer barters
for the deed
to another parcel of real estate; they agree on an exchange with proper
disposition
of taxes and government fees and the deeds are officially swapped
~ Seller offers the deed for two cows which the buyer barters for the deeds to
five
sheep; they agree to coordinate the delivery of the animals subject to a clean
veterinary inspection report to be obtained within one week and confirmed by a
third-party escrow service
~5 ~ Seller offers a collection of digital music and video from the Beatles
which the
buyer barters for two tickets to a performance of a Broadway Musical and fifty
US
dollars; the assets are transferred immediately between the two accounts
~ Seller offers four transferable season passes to Disney World with two
months
remaining which the buyer barters for fifteen thousand United frequent flyer
2o miles; during negotiation, the seller offers a coupon good for two free
nights hotel
stay in Orlando Florida if the buyer will add another five thousand frequent
flyer
miles (giving the seller enough miles to procure a free domestic ticket); they
agree
and the assets are transferred between the two accounts
~ Seller offers a new late-model sedan with full dealer warranty which the
buyer
25 barters for the exchange of a used vehicle plus fifteen-thousand US
dollars; they
agree on delivery arrangements and the assets are transferred between the two
accounts
~ Seller, a dentist, offers a root canal at their office in Seattle Washington
which the
buyer, a lawyer in Seattle, barters for services in writing a will subject to
a
3o maximum number of hours; they agree and schedule to meet to exchange
services
~ Seller offers Internet web page authoring services which the buyer, a
general
contractor. barters for kitchen remodeling services; they agree that the
seller will
purchase all supplies necessary and perform up to four hundred hours of web
consulting labor and the buyer will perform the specific remodeling tasks
35 ~ Seller offers Russian rubles which the buyer barters for US dollars; they
agree on
specific quantities, but avoid the paying of exchange fees, possibly ignoring
published exchange rates, by making the exchange personally through their
virtual
accounts
181
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
x.1.2.2 Haggling
Haggling transactions are negotiations between two or more parties in which
goods or services are exchanged. The parties negotiate the price of the
desired assets
and later settle the transaction. In typical haggle transactions, the selling
party
presents the actual goods or a deed to those goods along with an initial set
of terms for
their sale. Prospective buyers either accept these terms or make a counter-
offer. The
parties can continue to make offers and counter-offers, haggling for a
negotiated
price, until reaching agreement. The agreed-to terms are then used to
facilitate a
simultaneous swap. Negotiations may cause the selling party to add or subtract
goods
or services from the offer. The haggle transaction may be coordinated by an
agent or
take place in a marketplace.
Haggle transactions can be executed using virtual accounts wherein assets are
exchanged to complete a purchase between at least one buyer and at least one
seller.
A virtual account haggle transaction allows buyers and sellers to negotiate
the criteria
~5 for an exchange and then consummate the deal. The transaction may be
executed
using the assistance of an agent that brokers the deal by introducing the
parties, values
the property, coordinates the exchange of real-world goods, and/or certifies
the
transaction. The transaction may take place in a marketplace of vendors
(sellers) who
advertise their goods and then enter into specific haggle transactions with
individual
2o buyers. Optionally, the buyer and seller may agree to use an escrow account
to
coordinate the appropriate settlement of the transaction. The escrow account
may be
managed by either the buyer or the seller, or by a third party escrow service.
Haggle transactions using virtual accounts may take many forms, including
these examples:
25 ~ Seller offers computers and consumer electronics for retail purchase at a
mall
store; buyer haggles with the seller to arrive at a purchase price of fifteen-
hundred
US dollars for a new stereo with an upgraded set of surround-sound speakers
and
a ten percent off coupon which reduces the purchase price by one hundred and
fifty US dollars
3o ~ Seller offers the deed to a parcel of real estate for fifty thousand US
dollars;
during the negations the buyer haggles for a price of only forty thousand US
dollars; the parties agree on an exchange with proper disposition of taxes and
government fees and the deed is executed and delivered
~ Seller offers the deed for two cows for eight thousand New Zealand dollars,
the
35 buyer counter-offers seven thousand Australian dollars; they agree to
coordinate
182
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
the delivery of the animals subject to a clean veterinary inspection report to
be
obtained within one week and confirmed by a third-party escrow service
~ Seller offers a collection of digital music and video from the Beatles for
two
hundred US dollars which the buyer haggles to one hundred and eighty US
dollars; the assets are transferred immediately between the two accounts
~ Seller offers four transferable season passes to Disney World with two
months
remaining for twenty five thousand United frequent flyer miles which the buyer
haggles, offering fifteen thousand United frequent flyer miles; during
negotiation,
the seller offers a coupon good for two free nights hotel stay in Orlando
Florida if
the buyer will add another five thousand frequent flyer miles (giving the
seller
enough miles to procure a free domestic ticket); they agree and the assets are
transferred between the two accounts
~ Seller offers a new late-model sedan with full dealer warranty~ for twenty
thousand
US dollars; the buyer haggles the price down to eighteen thousand US dollars
plus
~ s an upgrade to the stereo system; they agree on delivery arrangements and
the
assets are transferred between the two accounts
~ Seller , a dentist, offers a root canal at their office in Seattle
Washington for seven
hundred US dollars and the buyer haggles for a price of five hundred US
dollars;
they agree, assets are transferred between accounts, and a schedule is agreed
upon
2o for the seller to perform the desired services
~ Seller offers Internet web page authoring services at eighty US dollars per
hour
which the buyer haggles to sixty US dollars per hour; they agree that the
seller
will perform a specified number of hours of labor at the negotiated rate with
specific milestones, payment to be arranged using an obligation account with
2s multiple escrows, one for each milestone
~ Seller offers one thousand Russian rubles, seeking one hundred US dollars;
the
buyer offers seventy-five US dollars; agreeing to eighty US dollars, both
avoid the
paying of exchange fees, possibly ignoring published exchange rates, by making
the exchange personally through their virtual accounts
30 8.1.3 One-to-Many (and Many-to-0ne)
In one-to-many or many-to-one scenarios, respectively, multiple buyers
purchase from individual sellers, or multiple sellers compete for purchases
from
individual buyers. In some cases, buyers can be aggregated to consolidate
their
purchasing power and allow them to act like a single buyer.
3s 8.1.3.1 Fixed Price
Fixed price transactions represent the typical retail transactions consumers
are
most familiar with today. In fixed price transactions, the seller sets a
price, which the
183
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
buyers may take or leave without negotiation. Sometimes fixed prices may be
reduced using coupons or the sellers may offer various discounts that may be
tied to
volume or the specific marketplace in which the sale occurs. Fixed price
transactions
include offers by sellers to supply goods or services under terms determined
by the
s seller, which may include such factors as volume and delivery commitments.
Using virtual accounts, fixed price transactions can be executed wherein
assets
and currencies are exchanged to complete a purchase between a buyer and
seller. A
virtual account fixed price transaction allows the buyer to conduct the
purchase
transaction and then consummate the deal. The transaction may be executed
using the
assistance of an agent that brokers the deal by introducing the parties,
valuing the
property, coordinating the exchange of real-world goods, andlor certifying the
transaction. The transaction may take place in a marketplace of vendors
(sellers) who
advertise their goods and then enter into specific fixed price transactions
with
individual buyers. Optionally, a buyer and a seller may agree to use an escrow
15 account to coordinate the appropriate settlement of the transaction. The
escrow
account may be managed by either the buyer or the seller, or by a third party
escrow
seance.
Fixed price transactions using virtual accounts may take many forms,
including these examples:
20 ~ Seller offers computers and consumer electronics for retail purchase at a
mall
store; buyer may purchase the desired items at the retail price plus
applicable
taxes and shipping costs and less any discounts or applicable coupons; the
buyer
completes the purchase and the payment is made by transfer between the buyer's
and seller's accounts, and the goods are delivered
25 ~ Seller offers the deed to a parcel of real estate for fifty thousand US
dollars which
the buyer can accept or decline; when they agree on an exchange with proper
disposition of taxes and government fees and the deed and payment are
officially
swapped
~ Seller offers the deed for two cows for eight thousand New Zealand dollars
which
3o the buyer agrees to purchase for the asking price; they agree to coordinate
on an
exchange and coordinate the delivery of the animals subject to a clean
veterinary
inspection report to be obtained within one week and confirmed by a third-
party
escrow service
~ Seller offers a collection of digital music and video from the Beatles for
two
35 hundred US dollars which the buyer agrees to purchase at the stated price;
the
assets axe transferred immediately between the two accounts
184
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
~ Seller offers four transferable season passes to Disney World with two
months
remaining for twenty five thousand United frequent flyer miles which the buyer
accepts; they agree and the assets are transferred between the two accounts
~ Seller offers a new late-model sedan with full dealer warranty for twenty
thousand
US dollars, which the buyer accepts; they agree on arrangements for delivery,
and
the assets are transferred between the two accounts
~ Seller is a dentist offers a root canal at their office in Seattle
Washington for seven
hundred US dollars which the buyer accepts; they agree, assets are transferred
between accounts, and they schedule to meet to perform the desired services
~ Seller offers Internet web page authoring services at eighty US dollars per
hour
which the buyer accepts; they agree that the seller will perform a specified
number
of hours of labor at the negotiated rate with specific milestones, payment to
be
arranged using an obligation account with multiple escrows, one for each
milestone
~ 5 ~ Seller offers one thousand Russian rubles which the seller desires to
convert to
seventy-five US dollars; the buyer accepts, but avoids the paying of exchange
fees, possibly ignoring published exchange rates, by making the exchange
personally through their virtual accounts
8.1.3.2 Auctions
2o Auction transactions are used in seller-dominated marketplaces to pit
buyers
against each other to discover the highest price. There are multiple forms of
auctions.
One familiar type is the ascending (English) auction where the buyers compete
by
bidding the sales price higher. Another type of auction is the descending
(Dutch)
auction where the price decreases over time, but limited quantities are
available so
25 buyers wait for the purchase price to drop but risk the quantity being sold
out if they
wait too long. Auctions are good marketplaces for consumer-to-consumer sales
like
flea markets or yard sales. Auctions are frequently used by businesses for
inventory
liquidation. Dutch-style auctions are used for the sale of perishable goods
where
complete sale of all inventory is highly desirable.
3o Auction transactions can be executed using virtual accounts to exchange
assets
and complete a purchase between a buyer and seller. A virtual account auction
transaction allows the buyer to conduct the purchase transaction and then
consummate
the deal. The transaction may be executed using the assistance of an agent
that
brokers the deal by introducing the parties, valuing the property,
coordinating the
35 exchange of real-world goods, and/or certifying the transaction. The
transaction may
18s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
take place in a marketplace of vendors (sellers) who advertise their goods and
then
enter into specific auction bid transactions with individual buyers. Bidders
may be
required to escrow or obligate funds until it is determined whether they have
a
winning bid. Optionally, the winning bidders (buyers) and seller may agree to
use an
escrow account to coordinate the appropriate settlement of the transaction.
The
escrow account may be managed by either the buyer or the seller, or by a third
party
escrow service.
Auction transactions using virtual accounts may take many forms, including
these examples:
~ Seller offers three identical new stereo systems at auction with a minimum
reserve
price of five hundred US dollars; buyers compete for the right to purchase a
specific quantity of the stereo systems at a bid price plus applicable taxes
and
shipping costs; the bidders compete by placing increasing bids for the limited
quantity of stereos; the winning bidders (buyers), if the winning bid is above
the
~ 5 reserve price, complete the purchase and the payment is made by transfer
between
the two accounts subject to appropriate delivery terms
~ Seller offers the deed to a parcel of real estate with a starting price of
thirty
thousand US dollars accepting bids in increments of five hundred dollars;
buyers
compete for the right to purchase the property at the bid price plus
applicable
2o taxes and government fees; the winning bidder (buyer) completes the
purchase
and the parties agree on an exchange with proper disposition of taxes and
government fees and the deed and payment are officially swapped
~ Seller auctions the deed for two cows for eight thousand New Zealand dollars
as a
single item, for which the buyers compete by placing bids using an escrowed
bid
25 process; the winning bidder (buyer) and seller agree to coordinate the
delivery of
the animals subject to a clean veterinary inspection report to be obtained
within
one week and confirmed by a third-party escrow service
~ Seller offers a collection of digital music and video from the Beatles as a
single
item; potential buyers examine the goods and place bids; the assets are
transferred
3o immediately between the winning bidder's and seller's accounts
~ Seller offers four transferable season passes to Disney World with two
months
remaining, accepting bids only in frequent flyer miles with a minimum reserve
of
twelve thousand United frequent flyer miles; the bidders compete by placing
increasing bids; the winning biddex, provided the bid was above the reserve
price,
3s completes the purchase and the assets are transferred between the two
accounts
~ Seller offers twenty new late-model sedans with full dealer warranty for
twenty
thousand US dollars each, using a Dutch-style auction; buyers submit bids for
the
vehicles as the price falls over time; the auction ends when all of the
vehicles axe
sold; each winning bidder (buyer) pays the seller by transfernng assets to the
186
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
seller, subject to appropriate delivery arrangements, and receiving the deed
to the
vehicle
~ Seller, a dentist, offers one thousand hours of root canal and related
dental
services at their office in Seattle Washington at auction to qualified bidders
which
include HMOs, insurance plans, and self insured businesses; the customers
place
bids for the services; the winning bidder (buyer) establishes an obligation
escrow
account to pay for the services on a monthly pro-rated basis
~ Seller offers 200 pages of Internet web page authoring services to be
exercised
within a three month period at auction using the Dutch style; the seller
initially
values the work at sixteen thousand dollars, but reduces the price in
increments of
fifty dollars until a bidder places a valid bid; the buyer prepays for the
pages with
a transfer to the seller's account
~ Seller offers one thousand Russian rubles at auction with a minimum reserve
price
of seventy five dollars which the seller desires to convert to any hard
currency; the
~ 5 buyers place bids in various currencies, with the wining bid compared to
the
currency exchange rate tables as published in the W all Street Journal; the
winning
bidder, if higher than the reserve price, avoids the payment of exchange fees,
possibly ignoring published exchange rates, by making the exchange personally
through their virtual accounts
20 8.1.3.3 Reverse auction
Reverse auction transactions are used in buyer-dominated marketplaces to pig
sellers against each other to discover the lowest price. The buyer publishes a
set of
requirement specifications (Request for Proposal, Request for Quotation,
Request for
Information) and then receives bids from potential sellers. Reverse auctions
can also
25 be conducted where they buyer commits to the purchase of various goods
and/or
services if his minimum conditions are met, insuring that at least one seller
able to
meet the buyer's demands will make a sale.
Reverse auction transactions can be executed using virtual accounts to
exchange assets and complete a purchase between a buyer and seller. A virtual
3o account auction transaction allows the buyer to conduct the purchase
transaction and
then consummate the deal. The transaction may be executed with the assistance
of an
agent that brokers the deal by introducing the parties, valuing the property,
coordinating the exchange of real-world goods, and/or certifying the
transaction. The
transaction may take place in a marketplace of purchasers (buyers) who
advertise their
35 requirement specifications and then enter into specific auction bid
transactions with
individual sellers willing to meet the conditions of the requirements
specifications.
18~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Purchasers may be required to escrow or obligate funds in the event that they
receive
a qualified bid from a seller that is determined to be a winning bid.
Optionally, the
winning bidders (sellers) and the buyer may agree to use an escrow account to
coordinate the appropriate settlement of the transaction. The escrow account
may be
managed by either the buyer or the seller, or by a third party escrow service.
Reverse auction transactions using virtual accounts may take many forms,
including these examples:
~ An individual buyer desires a Disney World vacation package for two people
for
seven nights in Orlando Florida for specific dates, but is willing to accept
any top
tier hotel and corresponding plane flight from San Francisco, California; the
buyer
offers to pay one hundred thousand United frequent flyer miles; several
sellers
review the offer and make different offers of up to and including 100,000
miles;
the lowest bid is accepted; the buyer transfers the miles into the seller's
account,
and the seller provides the appropriate ticket vouchers
~ 5 ~ An individual buyer desires to purchase a new late-model sedan with full
dealer
warranty, and indicates a willingness to pay up to twenty thousand US dollars;
a
number of sellers review the buyer's offer and make various different
responses;
the seller offering the lowest price is accepted; the buyer transfers assets
to the
sellers' account and the seller provides the deed of the vehicle to the buyer
20 8.1.3.4 Demand aggregation
Demand aggregation transactions separate the buying commitment from the
fixing of a final price. Individual buyers commit to a price they name, and
sellers
decide whether to accept the offer. In the buyer-driven variant, buyers accept
an offer
at a maximum price, which falls according to a pre-negotiated discount
schedule as
25 more buyers are aggregated to qualify for volume discounts.
Demand aggregation transactions can be executed using virtual accounts to
exchange asset and complete a purchase between one or more buyers and a seller
wherein the final price is not fixed prior to the commitment of the buyers to
purchase.
A virtual account demand aggregation transaction allows the buyer to negotiate
for a
so purchase transaction and then consummate the deal. The transaction may be
executed
using the assistance of an agent that brokers the deal by introducing the
parties,
valuing the property, coordinating the exchange of real-world goods, and/or
certifying
the transaction. The transaction may take place in a marketplace where a
seller's
goods and services are advertised and buyers agree to purchase the goods or
services,
35 for a final price to be named later (possibly calculated by a formula or
subject to a
188
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
falling maximum price). Purchasers may be required to escrow or obligate the
maximum amount of funds at the time of purchase. Escrowed funds may be
released
incrementally as the price falls or at the end of the demand aggregation cycle
when
the final price is fixed. Optionally, the winning buyers and the seller may
agree to use
an escrow account to coordinate the appropriate settlement of the transaction.
The
escrow account may be managed by either the buyer or the seller, or by a third
party
escrow service.
Demand aggregation transactions using virtual accounts may take many forms,
including these examples:
~ A group of buyers wants to purchase a specific brand and model of a new
stereo
system; the buyers publish their intent and the conditions of their purchase;
several sellers submit differing bids to provide increasing numbers of stereo
systems at a specific unit prices; after reconsidering their requirements in
light of
the bids received, the buyers complete the transaction with several sellers
directly
15 or via an intermediary
~ A group of farmers (buyers) desires to purchase dairy cows in New Zealand
meeting specific qualifications, from an identified seller; a discount
schedule is
agreed upon prior to the auction, involving a basis point reduction in the
sales
price for each five cows sold to a maximum of fifteen basis points; the
initial price
2o is fixed at four thousand New Zealand dollars; the buyers then try to
attract
additional buyers into the group to reduce the price of all of the cows by
increasing the quantity to be purchased; buyers are required to escrow the
initial
purchase price with a refund of the discount when applicable; the buyers and
the
seller agree to coordinate the delivery of the animals subject to a clean
veterinary
25 inspection report to be obtained within one week and confirmed by a third-
party
escrow service
~ A group of buyers desires to purchase collections of digital Beatles music
from an
identified seller; a discount schedule is agreed upon prior to the auction of
a three
basis point reduction in the sales price for each fifty collections sold to a
3o maximum of forty basis points; the base price for the reduction calculation
is fixed
at one hundred and thirty five US dollars; the buyers then try to attract
additional
buyers into the group to reduce the price for all buyers by increasing the
demand;
buyers are required to escrow the initial purchase price with an incremental
refund
of the discount as the price drops; the buyers and the seller agree to
exchange the
35 assets immediately upon close of the auction
~ An HMO (buyer) desires to procure dental services from board certified
dentists
in the Seattle, Washington area; the buyer advertises that it wishes to
procure
approximately fifty thousand hours of dental services, subject to listed
reimbursement fees for materials, at a rate of three hundred dollars per hour;
one
40 or more dentists or dental firms (sellers) submit bids for blocks of hours
in
hundred hour increments; the buyer accepts qualified bids making payment using
an obligation escrow account on a pro-rated monthly basis
189
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
8.1.4 Many to-Many
8.1.4.1 Exchanges
Exchange transactions are two-way simultaneous auctions, in which both the
buyer's and seller's prices float. In marketplaces with sufficient liquidity,
equilibrium
between buyers and sellers promotes the most efficient price outcomes. Prices
are
always in flux. Exchanges are important marketplaces for business-to-business
transactions especially for commodity goods. Exchanges work for consumers and
businesses in such examples as stock and bond markets.
Exchange transactions can be executed using virtual accounts wherein assets
t o are exchanged to complete a purchase between one of a set of buyers and
one of a set
of sellers and wherein the price is agreed when the buyer commits to purchase.
A
virtual account exchange transaction allows the buyer to initiate the purchase
transaction and then consummate the deal. The transaction may be executed
using the
assistance of an agent that brokers the deal by introducing the parties,
valuing the
property, coordinating the exchange of real-world goods, and/or certifying the
transaction. The transaction may take place in a marketplace where a seller's
goods
and services are advertised and buyers agree to purchase the goods or services
for the
current market price (which floats). Purchasers may be required to escrow or
obligate
a specified maximum amount of funds at the time of initiating the transaction.
2o Optionally, the winning buyer and seller may agree to use an escrow account
to
coordinate the appropriate settlement of the transaction once the price has
been
determined. The escrow account may be managed by either the buyer or the
seller, or
by a third party escrow service.
Exchange transactions using virtual accounts may take many forms, including
this example:
~ Seller is a consumer electronics manufacturer offering unbranded stereos as
an
Original Equipment Manufacturer (OEM) to wholesale distributors with an asking
price; the seller advertises the specifications of their equipment alongside
other
manufacturers of equivalent components; the buyers identify the commodity
3o stereo electronic components they wish to purchase at a particular price
(or the
market price) and the quantity desired; the exchange marketplace matches
buyers
and sellers and shows both the recent trade execution prices; the sellers are
free to
not offer quantities if the price falls too low, and the buyers can refuse to
buy if
the price is too high; the market price constantly changes, but rises and
falls based
upon supply and demand; when sales of particular kinds and numbers of goods
are
190
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
agreed upon, subject to appropriate delivery requirements, portions or all of
the
sales prices may be transferred to the seller's virtual account at or prior to
the time
of delivery
8.1.5 Basic Contract Law
A key element necessary in certain of these pricing system is the seller's
ability to bind a buyer to a legal contract under the agreed terms. In
contrast to a non-
binding request for proposal, a binding offer is attractive to potential
sellers because it
sets out each and every term and condition under which the buyer will allow
1 o themselves to be bound. In order to understand the requirements necessary
to form
binding contracts through electronic commerce, a review of the current state
of
contract law is necessary.
The formation of a legally binding contract requires three elements: offer,
acceptance, and consideration. Put another way, an essential prerequisite to
the
formation of a contract is an agreement: a mutual manifestation of assent to
the same
terms. This mutual assent is established by a process of offer and acceptance.
Further
legal requirements are imposed by the Statute of Frauds, where applicable.
An offer has been defined as a manifestation of intent to act or refrain from
acting in a specified way, so made as to justify a promise in understanding
that a
2o commitment has been made. A number of kinds of expressions border on, but
are not,
promises. The most important of these in the context of electronic commerce is
a
solicitation of an offer. For example, a clothing store advertisement of Brand
X suit
fox $150 "today only" does not constitute an offer. The advertisement is
merely an
invitation to make an offer. Since the store has not specified a quantity nor
included
any language of commitment, an advertisement of this kind is only a statement
of
intention to sell or a preliminary proposal inviting offers. Similarly, the
RFPs
discussed above are merely solicitations of offers rather than bindable
offers.
An offer may be accepted by any person in whom a power of acceptance has
been created. Because the offeror is the master of his offer, he controls the
person or
3o persons in whom a power of acceptance may be created. The identity of the
offerees
is determined by the reasonable person test. Thus, for example, it has been
determined that a reward offer may ordinarily be accepted by anyone who knows
of
the offer, but once the offer has been accepted, no one else may accept. On
the other
191
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
hand, an offer to pay a sum of money to anyone who is willing to sell an 1869
Morgan Silver Dollar in M69 condition may be accepted by anyone who knows of
the
offer and by any number of persons. Essentially, the language of the offer
determines
to whom it is offered and who may accept it. Thus, by wording an offer
appropriately, it may be directed to a number of persons but capable of
acceptance by
only one.
Under the doctrine of consideration, the third of the three basic elements of
contract formation, gratuitous promises are not enforced. This doctrine does
not pose
any difficulties in the context of electronic commerce.
1o In order judicially to enforce a contract, the Statute of Frauds requires
that a
party produce a written copy of it. However, the rule is only invoked if the
contract is
of a certain type, for example, a contract for the sale of real property. The
primary
purpose of this rule is to obviate perjury. The result is that certain oral
contracts are
unenforceable. However, because this often leads to unjust results, courts are
~5 construing the Statute narrowly and policy makers are lobbying for repeal
of at least
parts of it.
8.1.6 Electronic Contract Law and the Current State of the Art
With the advent of new technology, methods of doing business are rapidly
expanding. These new methods challenge traditional contract principles, which
axe
2o premised on personal contact and paper contracts. Thus, some legal issues
in the field
of electronic commerce remain unresolved.
One such technology is known as EDI, or electronic data interchange. It is
known that, using EDI, one party can transfer information and legally relevant
"documents" electronically to another for direct processing in the other
party's
25 information systems.
Most EDI environments involve ongoing relationships between companies
engaged in a supply or similar contract that extends over time. In current
practice,
many EDI exchanges occur under broader contracts regulating the terms of the
relationship between the two parties. These may be in the nature of
requirements or
3o franchise contracts. As applied directly to the EDI aspects of the
relationship, the
agreements are typically described as "trading partner" agreements. These
192
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
agreements deal with the terms, conditions, and limitations under which the
EDI
system will be employed to make or accept orders and, ideally, to define the
legal
consequences of the electronic exchanges between the parties to the trading
agreement. Although this technology may also be used for isolated or
intermittent
transactions between people who have no direct prior dealings, it has not been
used
for globallnon-personal seller- or buyer-driven offers.
EDI has not yet been the subject of much "lawmaking." The evolution of EDI
law has primarily involved commercial experimentation and model trading
partner
contract development, seeking an optimal contract structure for EDI use.
Little
1 o reported litigation deals with EDI relationships. Thus, the legal issues
raised by this
technology are largely unresolved.
When an exchange occurs in a purely electronic environment, the threshold
legal issue is whether the electronic messages establish an offer and
acceptance, given
the absence of documentation, and in the case of EDI, the absence of human
decisions
15 in the automated exchange. The exchange of electronic messages that offer
and
accept a contractual relationship should form a contract with respect to the
specific
order. An offer consists of an expression of a willingness to enter a contract
when
that expression occurs in a form sufficiently concrete and complete to
establish that
agreement. Under this doctrine, an electronic message may constitute the
necessary
2o expression of intent. Problems can arise if an unauthorized person or
inaccurate
information triggers an offer from a system. These problems could be solved by
methods of attribution or authentication. Once questions of attribution are
resolved,
and subject to Statute of Frauds considerations and the like, no requirement
exists in
law that a contract offer be in writing or that there be a conscious,
immediate intent to
25 make a binding commitment.
Contract rules provide that acceptance must be made in the manner
specifically required by the offeror. However, if no method for acceptance is
specified in the offer, acceptance may be in any manner and by any medium
reasonable under the circumstances. Thus, acceptance by electronic message
should
3o be valid.
The Statute of Frauds also impacts transactions involving a sale of goods for
a
price of $500 or more. U. C. C. Section 2-201 requires: (1) a writing; (2)
containing
193
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
a quantity term; (3) sufficient to indicate that a contract has been made; (4)
signed by
the party against whom enforcement is sought. In respect to EDI, this
provision raises
issues as to the existence of a "writing" and a "signature" by the party
against whom
enforcement is sought. U. C. C. Section 1-201(46) defines "writing" to include
"printing, typewriting or any other intentional reduction to tangible form."
The critical
aspect of this definition deals with the reduction of the agreement to
tangible form.
The purpose of requiring a writing to enforce a contract is to ensure some
minimum
level of proof of intent, avoid the risk of an entirely conjectural debate
regarding the
existence or scope of the agreement and prevent fraud. The sufficiency of an
1 o electronic message as a "writing" under the Statute of Frauds depends on
the manner
in which one finds the message stored or produced. Case law generally supports
the
idea that a telex or telegram satisfies the writing requirement, although it
may leave
unanswered whether the writing contains a proper signature.
Of course, the writing requirement can be satisfied by other means. For
example, if the electronic agreement is followed up by a letter or if the
system
routinely yields printed output, the requirement should be satisfied. But
apart from a
printed output at the receiving point or in a functional acknowledgment
returned after
receipt, the enforceability of a purely electronic contract depends on how the
computer system retains records of the transmitted offer (or acceptance) and
whether
2o a court will accept the idea that electronic records reduce the message to
tangible
form.
The Statute of Frauds' signature requirement also leaves ambiguity about the
legality of EDI-generated contracts. U. C. C. Section 1-201 (39) defines
"signed" as
including any "symbol executed or adopted by a party with present intention to
authenticate a writing. " Authentication here indicates that the signer
assents to the
writing and adopts it as his own. Thus, if a transmitting party includes a
particular
symbol and has indicated that symbol is intended to signify authenticity, the
message
should satisfy the signature requirement. Ordinary EDI practice often requires
an
authentication code or symbol as a matter of course to maintain the security
of the
3o system itself, and this seems to satisfy the Statute of Frauds signature
problem.
Indeed, authentication systems have been developed specifically to ensure the
enforceability of electronic contracts. One such method of authenticating
electronic
contracts in order to make them legally enforceable is disclosed in U. S. Pat.
No.
194
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
5,191,613. That system utilizes, among other techniques, digital signatures to
authenticate electronic contracts.
As discussed above, attribution via authentication is extremely important to
creating binding contracts in a buyer-driven system of electronic commerce
involving
global posting of purchase offers. It is essential for complying with the
signature
requirement of the Statute of Frauds. Authentication may become even more
important in the future, if proposed U. C. C. revisions are implemented. For
example, Proposed U. C. C. Section 2-212 states that an electronically formed
contract is legally binding if the message is authenticated by a procedure
previously
agreed to by the parties.
Moreover, any of the above-mentioned pricing systems which authenticates
the terms and conditions of offers will be more likely to attract the
attention of
potential participants, because it assures them of the legitimacy of the
offer.
8.2 Deviceless Access to Accounts
Current point-of sale (POS) and Automated Teller Machine (ATM) systems
require submission of a user-borne device such as a card, or a card and a PIN
to
identify the account holders. Without the device, the consumer is generally
unable to
conduct transactions. However, submission of the device does not guarantee
that the
holder of the device is authorized to conduct the transaction.
2o Device-less account access and transaction activity can be achieved by
substituting something in place of the physical device. This can be a piece of
information known only to the transactor and the system such as a password.
Alternately, a biometric signature such as a thumbprint scan, retinal scan, or
other
difficult to forge metric can be substituted. The system then retrieves the
specific
authorized account or makes a list of available authorized accounts, the
consumer
confirms the transaction, and the appropriate transaction occurs. There is no
need to
expose the underlying account number to either the consumer or the merchant.
To prevent circumvention of biometric signature requirements, specialized
approaches such as detection of blood flow may be required. This prevents
successful
3o use of a detached body part such as a severed thumb, or a cast impression
of a thumb,
to gain account access.
195
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Repositories, clearinghouses, and labeling services can support the ability of
an account user to transact business with third parties through an account
without
closing the actual token for that account. A biometric signature or other
symbol can
be assigned as a label or alias for an account. When the third party seeks to
access the
account using the clearinghouse and/or specific repository involved in the
transaction
can look up the account, based on the label or alias, find the actual token
and process
the transaction without disclosing that token to the third party. The label or
alias can
be assigned to any kind of account or sub-account including proxy accounts and
accounts with dynamic VINs.
~ 0 8.3 Fraud Detection
Virtual accounts enable entirely new types of consumer self protections
against fraudulent activity. This is crucial for anonymously held accounts for
which
the identity is not known or not disclosed and thus cannot be used to inhibit
fraud.
Virtual accounts facilitate the use of constraints that proscribe or otherwise
limit the
~5 use of an account; e.g., no purchase over a specified amount such as fifty
dollars,
weekly purchase limits such as two hundred dollars, only valid in specific zip
codes,
only valid at merchants located within a fixed distance such as within fifty
miles of
Chicago, only valid with specific types of merchants, only valid on certain
days of the
week or for specific date ranges, not to be used for cash advances, or only
valid for a
20 limited number of transactions. Account holders can configure specific
constraints on
individual accounts or sub-accounts, or may pick from pre-built suggested
templates.
Accou~lt holder-specified constraints help reduce the risk of fraud because
they constrain activities to certain times, locations, or pre-selected
activity types. The
account can be configured to automatically deactivate itself or respond with
an alert
25 notification if it detects an attempted use in violation of the prescribed
activities.
Although these measures increase consumer protection significantly, more can
be
done to solve the problem of stolen account numbers, as will be shown below.
8.4 Dynamic Token Generation Devices
Dynamic tokens may be incorporated in accounts, whether virtual or not, as
3o dynamic VINs that can act as temporary account numbers for the purpose of
196
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
completing transactions and then be discarded. For example, instead of having
a
fixed token, an account or sub-account can be configured to have a dynamic
token
generated by an algorithm in response to an external stimulus. The stimulus
can be a
clock with a timer that tracks elapsed time. This would, for example generate
a new
account token every fifteen minutes, each hour, every four hours, each day,
each
week, or each month. Instead of a clock, the stimulus can be the occurrence of
an
event, such as a transaction; e.g., a new token would be generated for each
new
transaction. In either case, even if the token for a given transaction were
printed on a
transaction receipt, that token would be worthless in the hands of a thief.
~0 8.4.1 Just-In Time Requested VINs
Consumers will need a mechanism for retrieving a current dynamic token so
that an account can be used for purchases and other transactions. A wireless
device
such as a cell phone, smart card, or Personal Digital Assistant (PDA) such as
a Palm
Pilot can be used to connect to a repository or clearinghouse and retrieve a
current
~ 5 dynamic token. The Palin VII contains an integrated wireless service,
other models
and those of other manufacturers support cellular models for connections. For
security purposes, the communication and storage of the current dynamic token
may
be encrypted. The wireless device can display the dynamic token to the
consumer for
use in manual transactions. However, instead of using the token manually,
e.g., by
2o transmitting it to a merchant verbally or by hand-writing, the consumer
could re-
transmit the token to the merchant's POS device appropriately enable a point-
of sale
using a fixed wire, docking port or wireless connection such as an infrared
beam. The
re-transmission may be further secured by encryption.
8.4.2 Synchronized Generation
25 Using algorithms responding to synchronized stimuli such as timers or
transaction event counters, user-carned dynamic devices and central office
token
generation devices using the same algorithm with an identical set of inputs
could
generate the same dynamic token. This has the advantage that a user-borne
dynamic
token generating device can generate a token that will be the same as that
generated at
3o a central account administration office, and will thus be accepted by that
office,
without requiring any communications connection between the user and the
central
197
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
office. This could consist of a device such as a cell phone, smart card, or
PDA that
contains a small computer with non-volatile memory. When the device is
activated or
upon demand, the current dynamic token is generated. For security purposes,
the
communications and storage of the current dynamic token could be encrypted.
The
dynamic token could be displayed to the consumer for manual transactions.
Alternately, as described above, the number could be re-transmitted using a
fixed
wire, docking port, or wireless connection such as an infrared beam to an
appropriately enabled point-of sale device. The re-transmission may be further
secured by encryption.
~ 0 8.4.3 Pay on Behalf Of
In some cases, the consumer will utilize a third party for payment. In this
case, a dynamic token can be used to contact the third party payor to confirm
availability of funds and guarantee the transaction, or alternately decline
the
transaction. The settlement event occurs separately from the authorization and
transaction guarantee. Third party payment may use just-in-time token
retrieval or
synchronized generation as a payment mechanism.
8.4.4 Request for Payment Confirmation
In some cases, a consumer will have prepaid for goods and services. In this
case, a dynamic token can be used to confirm the pre-payment. Payment
2o confirmation may use just-in-time token retrieval or synchronized
generation as a
payment mechanism.
8.4.5 Security
Additional security can be imparted to a cell phone, smart card, PDA or other
devices used to generate or receive dynamic tokens. For example, any of these
can be
equipped and programmed to require an authenticating token such as a PIN,
password, or biometric measurement to unlock the device. The device can be
programmed to deactivate itself after a select number of unsuccessful attempts
to
unlock it. Examples of this technology are a cell phone that requires a PIN, a
smart
card that requires a successful scan of a fingerprint, or a PDA that requires
a
3o password.
198
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
8.4.6 Magnetic Stripe Generation
Speedy adoption of the above-described security measures may depend on
providing this technology in a way that is least disruptive to current
merchant point-
of sale technology. Merchants, and the card processing firms that process
their
s transactions, have deployed at considerable expense small card readers that
contain a
magnetic stripe reader, a communications device, and usually a display. The
best
mode of operation for dynamic VINs is a smart card or similar device having a
magnetic stripe, requiring an authenticating token and containing equipment
necessary to program the magnetic stripe as necessary. In a simple embodiment,
the
smart card would null the magnetic stripe at all times, except for limited
periods after
entry. If an authenticating token into the card, such as by a miniature
keyboard, and
during such periods would always impart the same account token to the stripe.
In a
more capable and preferred embodiment, the smart card would include a wireless
receiver for receiving from a central office the data needed to supply or
generate
15 dynamic tokens. In the alternative, the wireless receiver can be omitted,
and dynamic
tokens can be generated without a connection to the central office in a manner
described above. Such a smart card could be configured to support multiple
accounts
with corresponding synchronized generators. When an appropriate account is
selected, the smartcard would generate the correct corresponding dynamic VIN
2o generated, and program the magnetic stripe. Each of the foregoing
embodiments
could be configured to allow the consumer or merchant to swipe the card
through
existing magnetic stripe readers without any change to the existing hardware
or
network infrastructure.
Technology for on-demand encoding of magnetic stripes on cards is widely
25 available from many manufacturers. However, integrated magnetic stripe
encoders
built directly inside the device itself are not in widespread commercial use.
The
required technology for integrated magnetic stripe encoders is disclosed in
5,434,398
Goldberg, 5,834,747 Cooper, and 5,834,756 Gutman.
8.5 Social Benefits
3o Residents of the United States do not have official national ID numbers,
but
the Social Security Number (55N) has become very similar in function. A valid
SSN
199
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
is required to obtain a job, to open an interest bearing financial account, to
trade
securities, and to file federal and state tax returns. Over the years, the SSN
has been
used as the primary identifier of an individual for driver's licenses, medical
records,
student number, and most financial records. Its disclosure, though restricted
by law,
is almost always required on a voluntary basis by any individual seeking
credit. The
end result is a simple, unchanging nine-digit number that is associated with
an
individual's name, date of birth, and primary residential address for that
individual's
entire lifetime.
This has created a distinct opportunity for identity thieves who easily can
acquire all of the necessary information (name, date of birth, SSN, and
current
address) from company human resources records, pay check stubs, public records
like
motor vehicle administrations (which sell their data) and the courts. Despite
all of its
inherent shortcomings, the SSN has become an ingrained, ubiquitous part of the
fabric
of American life. A number that was supposed to have been private has become a
~5 very public identifier with attendant opportunities for fraud.
The SSN is really just a simple account number. At the Social Security
Administration (SSA), each individual has an account with their earnings
history and
accrued benefits. However, most individuals are unaware of the current
"balance" of
their SSA accounts because it is not easy to view the history for accuracy and
2o statements are not regularly issued (though some plans are under
consideration to
issue regular statements by mail).
Virtual accounts can be used to provide secure social benefits accounts (such
as for Social Security or other benefits) having the functionality of
unchanging,
confidential account number. A private token can be used as the true social
benefits
2s account number. For example, the SSA, as an operator of a secure
repository, could
issue to each individual with an SSN a virtual account, but not disclose the
internal
social benefits account number to that individual or others. The public tokens
of the
social benefits account could match the nine-digit current SSN format or a
new, more
secure format with additional digits and/or characters. The individual would
then be
3o able to monitor their account and create new sub-accounts at will. Thus, an
individual
desiring to protect their privacy could create a sub-account for an employer,
for taxes,
for each credit application, or for other purposes, such that each would be
independently verifiable but have no obvious linkages to the other accounts of
the
200
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
individual based on the number alone. Authority to view or make changes to an
account could be controlled using a digital certificate.
The same solution works well for other US government agencies such as the
Internal Revenue Service (IRS) that administers corporate Tax IDs, the Health
Care
Financing Administration (HCFA) that administer Medicare and Medicaid
benefits,
and the Department of Education that administers student aid. If virtual
account
repositories were used as the basis for collecting and disbursing fixnds, the
government would realize significant operational efficiencies, while at the
same time
providing tools to let individuals and commercial entities monitor their
records. The
same is true of any government agency, in any country, that collects or
disperses
funds.
201
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.1 Figures 1 and 2
Figures 1 and 2 show one of the many preferred embodiments of this
invention, wherein the computer system 1000 can contain one or more data
processors
1020, communications devices 1201, and storage devices 1060. Internal to each
storage device is an operating system 1100 and account management software
2000,
in this case, that of a generic advanced asset management system. These
systems
have the ability to communicate with other entities 1001 through the use of
their
communications devices) 1201. For these figures, the accounts detailed in the
storage device include virtual accounts 2100, but could in fact be any account
or
accounts under the control of a single or multiple management systems.
Additional modules can be added to the storage device, to make available
certain options found in particular embodiments of the AAMS, for incorporation
in
whole or in part, when offered as enhancements of existing legacy systems. In
other
~5 figures, these modules are illustrated in detail, with the remainder of the
AAMS being
omitted to permit enlarged renderings of these modules.
9.2 Figures 3-10
In the following figures, some of the possible configurations of a virtual
account are documented. The virtual account 2100, being the overall container
for
2o zero, one or more private accounts 2200, is connected through a uni-
directional
interface 2300, to one or more public accounts 2400. Figure 3 shows the
minimal
configuration of a virtual account. Figure 4 is one of the more preferred
embodiments, which is used as a template for examining other variations on the
possible configurations of virtual accounts, especially in regard to the use
of domains.
25 Figures 5-10 document some of the additional possible variations having one
or more
private accounts 2200, connected through one or more public/private account
interfaces 2300, to one or more public accounts 2400.
_. 202
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.3 Figures 11-08
These figures detail some of the possible ways in which virtual accounts and
their sub-accounts can be logically connected, although in these instances,
the
connections are not made directly to any of the private accounts, but instead
through
public accounts controlled by private accounts. Since each virtual account
must have
at least one public account, for example a primary public account,
communications
from a primary account in one virtual account to a primary or any other public
account in another virtual account constitute communications between virtual
accounts. Although not shown, systems administrators may logically connect
private
1 o accounts or entire virtual accounts, although these actions are unknowable
to end-
users.
Logical connections between accounts are irrespective of the number and
configuration of accounts.
9.3.1 Figures 11-14
Figures 11-14 detail a few of the types of connections 2480 possible between
one primary public account 2410 and another, both within and between virtual
accounts 2100.
9.3.2 Figures 15 26
Figures 15-26 detail some of the many possible connections 2480 possible
2o between primary accounts 2410 and subordinate accounts 2420, both within
and
between virtual accounts. These drawings also illustrate one-to-many, many-to-
many,
and many-to-one connections.
9.3.3 Figures 27-38
Figures 27-38 detail some of the many possible connections 2480 possible
between subordinate accounts 2420 and primary accounts 2410, both within and
between virtual accounts. These drawings also illustrate one-to-many, many-to-
many,
and many-to-one connections.
203
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.3.4 Figures 39-48
In figures 39-48, logical connections 2480 between various subordinate
accounts 2420 are illustrated.
9.4 Figures 49-84
In several embodiments, domains of accounts are detailed. These domains can
for example accommodate some or all of the accounts within a virtual account,
and
are most often encountered as either public and/or private domains. There are
simply
too many possible types of public and private domains to provide drawings that
include every possible iteration and combination of both types. Instead,
drawings are
offered that show public and private sets of domains. These drawings can be
combined in a Mr. Potato HeadTM fashion, with any top (a set of private
domains)
connected to any bottom (a set of public domains) as long as the numbers of
public/private account interfaces 2300 are in agreement.
9.4.1 Figures 49-61
Figures 49-51 are simplistic cases, in which all of the public 2410 and
private
2210 accounts of a virtual account 2100 are combined in a single domain 2500.
9.4.2 Figures 52,54
Figures 52-54 document some of the possible permutations wherein all private
accounts 2210 are within a single private domain 2510.
9.4.3 Figures 55-68
Figures 55-58 illustrate multiple private domains 2510, including nested sets
of private domains.
9.4.4 Figures 59-64
Figures 59-64 depict various configurations of public accounts, both primary
2s accounts 2410 and other subordinate accounts 2420, contained within a
single public
account domain 2520.
204
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.4.5 Figures 65-84
In figures 65-84, some of the possible variations and permutations of public
accounts, both primary accounts 2410 and other subordinate accounts 2420, are
contained within multiple public account domains 2520, including several
examples
s of nested domains.
9.5 Figures 85-89
Figures 85-89 detail some of the possible ways in which the encryption
capabilities of an AAMS can be configured in both hardware, software, or some
combination of hardware and software. The possible encryption engines include
the
AAMS Encryption Engine 1501 (Fig. 85), a dedicated encryption engine 1505
(Fig.
86), storage device encryption engines 1502 (Fig. 87), data processor
encryption
engines 1503 (Fig. 88), and communications device encryption engines 1504
(Fig.
89). Each of these encryption engines can be used alone, or in combination
with
some or all of the other engines.
15 9.6 Figure 90
Figure 90 details the use of external communications devices 1202 through
which entities 1001 can communicate indirectly with the AAMS.
9.7 Figures 91 97
In figures 91-97, the use of a consolidated account management structure, a
2o repository 3000, is detailed. Although shown containing only virtual
accounts 2100,
repositories can contain any type of accounts or combinations of types of
accounts.
Accounts within a repository are numbered in typical vector format, with the
first
digit being the repository number of the "parent" repository, and the second
being the
account number within that repository. The continuing indefinite series is
denoted by
25 standard mathematical notation, e.g., "m" and "n".
These figures are also useful in illustrating the ability of a computer
systems)
to hold more than one repository (Fig. 93-97) and the ability of any
repository to
communicate with other repositories within or external to its system, and
other
2os
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
entities 1001, directly or indirectly through its own 1201 or external 1202
communications devices.
9.8 Figur~a 98-102
Repositories can be grouped in various configurations, which may afford
s differing levels of privilege and trust depending upon the characteristics
of groups in
which they have membership in a particular group. Membership in a group is
denoted
in standard vector format (Group number, Member number) as described
previously,
with standard series notation.
9.8.1 Figure 98
Figure 98 documents an arrangement of repositories 3000 in a distributed
group 3100. The connections between the repositories 3110 constitute
identified
communications routes between members of the group. Note that in later
drawings
the overall outline of the distributed group with undistinguished internal
components
is used to allow for variations in drawing scale.
15 9.8.2 Figure 99
Figure 99 documents the arrangement of repositories 3000 in a federated
group 3200. The connections 3210 between the repositories constitute trusted
relationships between members of the group. Note that in later drawings the
federated
group is identified by the same outline shown in this figure to allow for
variations in
20 drawing scale.
9.8.3 Figure 100
Figure 100 depicts an arrangement of repositories 3000 in distributed-
federated group 3300. Connections 3210 between the repositories 3310
constitute
both trusted relationships between members of the group and communications
routes
2s between members. Note that in later drawings the distributed-federated
group is
identified by the same outline show in this figure to allow for variations in
drawing
scale.
206
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.8.4 Figures 101-102
Figures 101-102 show the arrangement of discrete repositories 3000 and
groups of repositories 3100, 3200, and 3300, connected in an inter-networked
group
3400, in which the respective inter-networked groups constitute all
repositories within
the f gore. Additionally, other objects are typically part of or connected to
such a
group, including, but not limited to, inter-network connection equipment (the
inter-
network 3410, routers 3420, concentrators 3430, and bridges 3440) and other
systems
(clearinghouses 4010, naming systems 5010, and labeling systems 6010). Note
that in
later drawings the inter-networked group is identified by the same outline
shown in
this figure to allow for variations in drawing scale.
9.9 Figures 103-107
Figures 103-107 demonstrate some of the connections available to individual
repositories 3000, and individual repositories with membership in larger
groups 3100,
3200, 3300 and 3400, to communicate and conduct transactions with other
individual
repositories and repositories within other groups.
9.10 Figures 108-112
Figures 108-112 detail some of the possible ways in which the encryption
capabilities of an ARMS can be configured in both hardware, software, or some
combination of hardware and software when the ARMS supports repositories. The
2o possible encryption engines include the AAMS Repository Encryption Engine
1511
(Fig. 108), a dedicated encryption engine 1505 (Fig. 109), storage device
encryption
engines 1502 (Fig. 110), data processor encryption engines 1503 (Fig. 111),
and
communications device encryption engines 1504 (Fig. 112). Each of these
encryption
engines can be used alone, or in combination with some or all of the other
engines.
9.11 Figures 113-123
These figures show the creation and operation of a virtual clearinghouse
20'7
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.11.1 Figures113-115
Figures 113-115 show the creation of one or more virtual clearinghouses 4010
through the use of virtual clearinghouse software 4000. Virtual clearinghouses
can
contain a number of associated obj ects, a few examples of which include
account
transactions 4011, escrow transactions 4100, bid pools 4200, gaming/gambling
pools
4300, tax and fee engines 4400, digital signature engines 4500, digital
certificate
engines 4600, credential and license engines 4700, and agent services engines
4800.
These objects have distinctive outlines in Figure 113, and are represented by
the same
respective shapes in Figures 114 and 115.
~0 9.11.2 Figures 116-118
As detailed in figures 116-118, clearinghouses can participate in transactions
involving many types of objects, including transactions internal to specific
repositories 3000 and groups of repositories 3100, 3200, 3300 and 3400 as
shown in
figure 116, or between individual and/or member repositories and/or other
external
~ 5 entities 1-N, as shown in figures 117 and 118.
9.11.3 Figures 119-123
Figures 119-123 detail some of the possible ways in which the encryption
capabilities of a VCHS 4000 can be configured in both hardware, software, or
some
combination of hardware and software. The possible encryption engines include
the
2o VCHS Encryption Engine 1521 (Fig. 119), a dedicated encryption engine 1505
(Fig.
120), storage device encryption engines 1502 (Fig. 121), data processor
encryption
engines 1503 (Fig. 122), and communications device encryption engines 1504
(Fig.
123). Each of these encryption engines can be used alone, or in combination
with
some or all of the other engines.
25 9.12 Figures 1?A~133
The following figures detail the creation and component parts of a virtual
naming system, and the various encryption strategies which can be
incorporated.
208
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.12.1 Figures 124-128
Figures 124-128 detail the creation of one or more virtual naming systems
5010 through the use of virtual naming system software 5000. The naming system
can comprise a number of internal objects including lists of repositories
5100, lists of
repository addresses 5200, lists of repository aliases 5300, and lists of
repository
ownership certificates 5400. Each of these lists can also be expanded to
include,
respectively, clearinghouses, labeling systems, other naming systems, and
devices.
9.12.2 Figures 129-133
Figures 129-133 detail some of the possible ways in which the encryption
1 o capabilities of a VNS 5000 could be configured in both hardware, software,
or some
combination of hardware and software. The possible encryption engines include
the
VNS Encryption Engine 1531 (Fig. 129), a dedicated encryption engine 1505
(Fig.
130), storage device encryption engines 1502 (Fig. 131), data processor
encryption
engines 1503 (Fig. 132), and communications device encryption engines 1504
(Fig.
133). Each of these encryption engines can be used alone, or in combination
with
some or all of the other engines.
9.13 Figures 134-135
Figures 134 and 135 detail some of the possible things that can be stored in
virtual accounts.
9.14 Figures 136-145
These figures detail the creation and operation of an attribute management
subsystem, which can be included as an enhancement to certain legacy account
management systems, or as an integral part of an ARMS.
9.14.1 Figures 136-138
Figures 136-138 show the use of attribute management system software 1910,
an optional addition to the ARMS, Additionally, attributes 1911 are shown for
various accounts 1901.
209
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.14.2 Figures 139-140
Figure 139 illustrates attributes that may exist in various embodiments of the
invention, including system attributes, and user-selected, user-determined,
and user-
defined attributes. Any generic object can contain some measure of any of
these
types of attributes, depending upon system configuration. Figure 140 expands
on the
scope of attributes that an account can contain, incorporating some of the
additional
types of attributes 1912, 1913, and 1914 illustrated in figure 139
9.14.3 Figures 141-145
Figures 141-145 detail some of the possible ways in which the encryption
capabilities of a AccountlAttribute Management System could be configured in
both
hardware, software, or some combination of hardware and software. The possible
encryption engines include the A/AMS Encryption Engine 1551 (Fig. 141), a
dedicated encryption engine 1505 (Fig. 142), storage device encryption engines
1502
(Fig. 143), d~.ta processor encryption engines 1503 (Fig. 144), and
communications
~ 5 device encryption engines 1504 (Fig. 145). Each of these encryption
engines can be
used alone, or in combination with some or all of the other engines.
9.15 Figures 1.46-155
These figures detail the creation and operation of an constraint management
subsystem, which can be included as an enhancement to certain legacy account
2o management systems, or as an integral part of an AAMS.
9.15.1 Figures 146-148
Figures 146-148 show the use of constraint management system software
module 1920 as an optional but preferred addition to the AAMS. Additionally,
various constraints 1921 are shown for various accounts 1901.
25 9.15.2 Figures 149-150
Figure 149 illustrates several types of constraints that may be provided in
various embodiments of the invention, including system constraints, and user-
selected, user-determined, and user-defined constraints. Any generic object
could
210
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
contain some measure of any of these types of constraints depending upon
system
configuration.
Figure 150 expands on the scope of constraints that an account can contain,
incorporating some of the additional types of constraints 1922, 1923, and 1924
illustrated in figure 149.
9.15.3 Figures 151-155
Figures 151-155 detail some of the possible ways in which the encryption
capabilities of a Account/Constraint Management System could be configured in
both
hardware, software, or some combination of hardware and software. The possible
encryption engines include the A/CMS Encryption Engine 1561 (Fig. 151), a
dedicated encryption engine 1505 (Fig. 152), storage device encryption engines
1502
(Fig. 153), data processor encryption engines 1503 (Fig. 154), and
communications
device encryption engines 1504 (Fig. 155). Each of these encryption engines
can be
used alone, or in combination with some or all of the other engines.
9.16 Figure 156
Figure 156 depicts some of the possible attributes 1911, 1912, 1913, and 1914,
and constraints 1921, 1922, 1923, and 1924, that can be found in certain
preferred
embodiments of an AAMS in conjunction with virtual accounts. Note the finer
level
of granularity offered by the AAMS/VA combination, allowing for attributes and
2o constraints on repositories, virtual accounts, various sub-accounts within
the virtual
account, and on the domains.
9.17 Figures 157164
Figures 157-163 show the impact of constraints from higher level objects
dowwthrough lower level objects. Lower level objects collect constraints from
higher
level before adding or modifying constraints. The build-up or collection of
constraints is detailed in figure 164.
211
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.18 Figure 165
Figure 165 illustrates various communications connections for the transfer of
assets within an AAMS, and the interaction with various closed 7200, stand-
alone
7300 and external 7500 systems.
s 9.19 Figures 166-167
Figures 166 and 167 exemplify the flow of assets 8000 into and out of virtual
accounts, including the necessary settlement activities 8200.
9.20 Figures 168-170
Figures 168-170 demonstrate the use of one or more clearinghouses 4010
1 o acting as intermediaries for communications between various communications
devices 1201 and repositories 3000.
9.21 Figures 171-203
Figures 171-203 show some examples of classes and sub-classes available for
use in an AAMS. The virtual account 2100 itself is not shown due to space
~ 5 limitations, so that interactions and internal features of the various sub-
accounts can
be illustrated in greater detail.
9.21.1 Figure 171
Figure 171 is one of the simpler hierarchical structures possible, showing
three
levels of public accounts within a primary account domain 2520. At the highest
level
2o is the primary account 2410, followed by successive levels of subordinate
child and
grandchild accounts 2421.
9.21.2 Figure 172
Figure 172 is a more detailed illustration of the wide variety of accounts and
account configurations available within a virtual account.
212
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.21.3 Figures 173-174
Figures 173 and 174 show various configurations of child accounts 2421
arranged in hierarchical fashion. Figure 174 incorporates an additional domain
2520
that extends across hierarchies.
s 9.21.4 Figures 175-176
Figures 175-176 exemplify the use of peer accounts 2422, in these examples,
peers of the primary account, including in figure 176, a peer account with a
subordinate domain.
9.21.5 Figures 177-180
1o Figures 177-180 illustrates the creation and use of a virtual escrow
account
2600.
9.21.5.1 Figure 177
Figure 177 is an example of an escrow account 2600 which inherits an initial
constraint set skeleton 2631 from a primary account. The constraint set
skeleton can
15 be used as is, or modified to produce the escrow constraint set 2630 shown.
9.21.5.2 Figures 178-179
Figures 178 and 179 show the flow of assets 2460 and agents, alerts and
triggers 2450, between different accounts during the operation of an escrow
account
2600. The escrow account incorporates certain constraints from the buyer and
seller
20 2431 into its constraint set 2630. The escrow account also incorporates
information
relayed through agents, alerts and triggers from various external stimuli
2470, such as
a delivery receipt, which may affect the status of the escrowed assets.
In figure 178, the escrow account resides within the domain of the buyer, but
could just as easily reside in the seller's domain. Alternately, as shown in
figure 179,
25 the escrow account can exist in a third party domain.
9.21.5.3 Figure 180
Figure 180 shows the use of a hierarchy of escrow accounts as obligation
accounts. In this particular example, a contract manager establishes a global
set of
213
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
rules and conditions through which assets are released to various contractors.
For
each set of conditions and associated milestones, the contractors have
assigned a
particular PIN to the accounts within the contract manager's domain. As the
milestones are met, the escrow constraint sets are evaluated, with funds
automatically
released
9.21.6 Figures 181-184
Figures 181-184 depicts several embodiments of the creation and use of
virtual bid accounts 2700.
9.21.6.1 Figure 181
Figure 181 shows the creation of a bid account 2700 which inherits an initial
constraint set skeleton 2731 from a primary account. The constraint set
skeleton can
be used as is, or modified to produce the bid constraint set 2730 shown. Also
shown
is a bid pool 2740, used to track and record bids 2471 made in response to the
offer
contained in 2700 as detailed in 2730.
~ 5 9.21.6.2 Figure 182
Figure 182 is an expansion of figure 181 showing a hierarchy of bids, with
each bid having its own bid pool, 1,2 through 1,n.
9.21.6.3 Figure 183
Figure 183 shows bids 2741 coming from two separate bidders, Bidder 1 and
2o Bidder 2, responding to an offer by an auction house. In conjunction with
their bids,
additional constraints 2431 may be incorporated in their bids. Assets 2460 may
be
required with the bids, or only after a bidder has been selected as the winner
of the
auction. Both the bid 2700 and the bid pool 2740 may interact with external
stimuli
2470, in order to track such things as timestamps for bid receipts, and the
closing of
25 the auction.
9.21.6.4 Figure 184
Figure 184 illustrates the use of an escrow account 2600 within a bid pool so
that a bid's assets can be secured.
214
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.21.7 Figures 185-188
Figures 185-188 demonstrate the creation and use of virtual gaming accounts
2800.
9.21.7.1 Figure 185
Figure 185 shows the creation of a gaming account 2800 which inherits an
initial constraint set skeleton 2831 from a primary account. The constraint
set
skeleton can be used as is, or modified to produce the gaming constraint set
2830
shown. Also shown is a gaming pool 2840, used to track and record wagers 2471
made in response to the game contained in 2800 as detailed in 2830.
9.21.7.2 Figure 186
Figure 186 is an expansion of figure 185 showing a hierarchy of games, with
each game having its own gaming pool.
9.21.7.3 Figure 187
Figure 187 shows wagers 2841 coming from two separate bettors, Bettor 1 and
~5 Bettor 2, responding to a game offered by a gaming house. Additional
constraints
2431 may be incorporated in their wagers. Assets 2460 may be required at the
time or
wagering or only after the results are posted. Both the gaming account 2821
and the
gaming pool 2840 may interact with external stimuli 2470, in order to track
such
things as timestamps for gaming receipts, and the results.
20 9.21.7.4 Figure 188
Figure 188 details the use of an escrow account 2600 within a gaming pool so
that wager assets can be secured.
9.21.8 Figures 189-198
Figures 189-198 provide various examples of proxy accounts and examples of
25 types of relationships possible using proxy accounts.
215
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.21.8.1 Figures 189-191
Figure 189 shows the creation of a proxy account 2900 which inherits an
initial constraint set skeleton 2931 from a primary account. The constraint
set
skeleton can be used as is, or modified to produce the proxy constraint set
2930
s shown. The relationship of the proxy account to the primary account is shown
in
Figure 190, while Figure 191 shows proxy accounts with various constraint sets
for
other accounts within a primary account domain.
9.21.8.2 Figures 192-193
Figure 192 illustrates how proxy accounts 2900 can be used to interact with
conventional accounts 2940, in this instance a savings account. Proxy
interactions
can be manual or automated, and can incorporate agents, alerts and triggers
2450 to
facilitate the flow of assets 2460. The assets transferred between the
conventional and
proxy accounts can be contained within the proxy account, or as shown in
Figure 193,
can be used in transactions with other accounts.
~5 9.21.8.3 Figures 194-197
A parent account can spawn multiple simultaneous proxy accounts 2900, with
each proxy account shown on figure 194 having a unique relationship with a
different
conventional account 2940. Alternately, a single proxy account can have
multiple
simultaneous relationships with multiple conventional accounts as illustrated
in
2o Figure 195.
Proxy accounts can also simultaneously participate in a variety of other
relationships with accounts within (Figure 196) and external to (Figure 197)
their
virtual account, with the relationships, and any transactions to these
accounts, used as
to determine which conventional account or group of accounts the proxy will
interact
25 with to transfer the required assets.
9.21.8.4 Figure 198
Figure 198 illustrates the relationship of a dynamic proxy account 2990 to a
parent account. After a dynamic proxy account is defined by the parent
account,
various dynamic proxy accounts can be created to support any relationship that
a
3o normal proxy account may have, with the key difference being that the
dynamic proxy
216
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
account has a limited lifespan, which may be as short as a single transaction.
Dynamic proxy accounts can also be defined such that every time a new
transaction of
a specified type is required for a particular conventional account, a new
dynamic
proxy is created. Multiple dynamic proxies can exist simultaneously for the
same
dynamic proxy definition, and a parent account may have multiple dynamic proxy
definitions available for use.
9.22 Figures '199-203
Figures 199-203 illustrate the use of dynamic tokens in various account types.
In particular, for the virtual account types shown, the dynamic tokens are
instantiated
as dynamic VINs.
9.22.1 Figure 199
Figure 199 shows a primary account 2410 containing a Dynamic VIN, where
the value of the token is established through the use of some external
stimuli, such as
a clock reading, timer event, or counter. Agents, alerts and triggers 2450 can
also be
used to determine the value of the token, or to transfer stimuli between the
account
and external sources.
9.22.2 Figure 200
Figure 200 illustrates that multiple accounts can have independently generated
tokens: the child account 2421 uses algorithm fl(t,x) to calculate its token,
while the
2o peer account 2422 used f2(t,x). Both algorithms can share a source of
external stimuli
2470, and even use an identical stimuli, but due to the differences in their
algorithms,
the tokens will be unique.
9.22.3 Figure 201
Figure 201 portrays a proxy account 2900 with a Dynamic VIN interacting
with a conventional account 2940, in this case a credit card account. Using a
Dynamic VIN, the proxy account would be able to generate a unique token for
each
transaction in which it takes the place of the credit caxd account.
21~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.22.4 Figure 202
In a more complex use of a dynamic token, a dynamic proxy account 2990 is
defined such that the VINs for each instance of the dynamic proxy are Dynamic
VTNs. In this example the dynamic proxy accounts are created according to a
preset
signal via the primary account in accordance with a creation definition. They
interact
with a known conventional account 2940, in this case a credit card account,
and
present a dynamic token to record their participation in the credit card
transaction. As
assets are transferred to other accounts, in this case another virtual
account, the
dynamic proxy account generates a new Dynamic VIN to record its participation
in
~o the second transaction.
9.23 Figure 203
Figure 203 shows multiple child accounts each using a different version of a
label in place of their normal V1N: for account #1, the label is a non-random
user-
defined label; for account #2, the label is a randomly assigned label; and for
account
#3, the label is a randomly generated label.
9.24 Figures 204-213
The following figures illustrate the creation and component parts of a virtual
labeling system, and the various encryption strategies which can be
incorporated.
9.24.1 Figures 204 208
2o Figures 204-208 exemplify the creation of one or more virtual labeling
systems 6010 through the use of virtual labeling system software 6000. The
labeling
system can comprise a number of internal objects including several lists 6100.
These
lists can contain for example, known labels for accounts, account aliases, and
public
and private tokens. The labeling system can also incorporate both a digital
certificate
engine 4600 and a digital signature engine 4700 as integral parts.
9.24.2 Figures 209-213 ,
Figures 209-213 detail some of the possible ways in which the encryption
capabilities of a VLS 6000 could be configured in both hardware, software, or
some
218
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
combination of hardware and software. The possible encryption engines include
the
VLS Encryption Engine 1541 (Fig. 209), a dedicated encryption engine 1505
(Fig.
210), storage device encryption engines 1502 (Fig. 211), data processor
encryption
engines 1503 (Fig. 212), and communications device encryption engines 1504
(Fig.
213). Each of these encryption engines can be used alone, or in combination
with
some or all of the other engines.
9.25 Figure 214
Figure 214 illustrates attributes and constraints for an account 2421 within a
domain, in particular showing the use of the domain constraint pool 2521 of
domain
1,1 from which the various listed attributes and constraints can be selected.
9.26 Figures 215-222
Figures 215-222 detail the transition of an account from one type to another,
or from one parent to another, both within a particular domain or virtual
account, and
between virtual accounts. Additionally, multiple examples are given in which
an
~ 5 entire group of accounts is transitioned with the structure of the group
remaining
intact after the change.
9.27 Figures 223-226
Figures 223-226 show the form, internal components, and use of various
examples of dynamic token generation devices (DTGD).
20 9.27.1 Figure 223
Figure 223 shows a mufti-function, generic, DTGD, in top edge 9001, front
9002, back 9003, and side 9004 views. The top view 9001 portrays a typical
infrared
port on the left-hand side and a radio antenna on the right. In the front view
9002 four
separate Input/output (I/~) devices are shown, including the display, a
keypad, a
~5 biometric scanner, and electronic contacts suitable for use in a docking
port. The rear
view 9003 show the location of a reconfigurable magnetic stripe. The side view
9004,
in this instance a left side view, shows again the electronic contacts and
magnetic
stripe, along with a standard computer-style Il0 port.
219
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.27.2 Figure 224
Figure 224 shows the internal components 9100 of a generic dynamic token
generation device (DTGD), numbered and shaded by function. Regardless of the
form any particular DTGD might take, the most preferred embodiments will have
a
CPU 9101, a system clock/timer 9102, an algorithm generator 9103, non-volatile
memory 9104, and a tamper detection engine 9105. Another class of components
includes the power sources) available including possible control circuitry.
For
example, these comprise a power source 9201, an external power coupling 9202
for
recharging the power source, and a power controller 9203. Various types of
DTGD
will have some of the following components, including an encryption engine
9301, a
keypad controller 9302, and a biometric scanner 9303. Depending on the
configuration of the DTGD, one or more I/O devices will be included, most
typically
a display controller 9401, a radio transceiver 9402, an infrared transceiver
9403, a
magnetic stripe generator 9404, and a physical contact ports) 9405.
9.27.3 Figure 225
Figure 225 contains examples of devices currently in existence that could be
used as-is, or with modest modification, to function as DTGDs.
9.27.4 Figure 226
Figure 226 illustrates communications between a DTGD and a repository or a
2o clearinghouse, and between all three of these objects and a source of
external stimuli,
to synchronize a token.
9.28 Figures 227 234
These figures detail the creation and operation of an token management
subsystem, which can be included as an enhancement to certain legacy account
management systems, or as an integral part of an AAMS.
9.28.1 Figures 227 229
Figures 227-229 show the use of token management system software 1940 as
an optional addition to the AAMS. Additionally, various tokens 1941 are shown
for
220
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
various accounts 1901. ' The accounts and tokens illustrated by ovals in
Figure 227 are
represented by circles and ovals, respectively, in Figure 228.
9.28.2 Figures 230 234
Figures 230-234 detail some of the possible ways in which the encryption
capabilities of an Account/Token Management System could be configured in both
hardware, software, or some combination of hardware and software. The possible
encryption engines include the A/TMS Encryption Engine 1571 (Fig. 230), a
dedicated encryption engine 1505 (Fig. 231), storage device encryption engines
1502
(Fig. 232), data processor encryption engines 1503 (Fig. 233), and
communications
device encryption engines 1504 (Fig. 234). Each of these encryption engines
can be
used alone, or in combination with some or all of the other engines.
9.29 Figures 235-242
These figures detail the creation and operation of an hierarchy management
subsystem, which can be included as an enhancement to certain legacy account
~ 5 management systems, or as an optional integral part of an AAMS.
9.29.1 Figures 235 237
Figures 227-229 show the use of hierarchy management system software 1950
as an optional but preferred addition to the AAMS. Additionally, various
hierarchies
1941 are shown for various accounts 1901. The downward-proj ecting branches of
the
2o inverted trees represent sub-accounts. The asset management accounts
represented by
ovals in Figure 235, are also represented by differently oriented ovals in
Figure 236.
9.29.2 Figures 238 242
Figures 238-242 detail some of the possible ways in which the encryption
capabilities of an Account/Hierarchy Management System could be configured in
25 both hardware, software, or some combination of hardware and software. The
possible encryption engines include the A/HMS Encryption Engine 1581 (Fig.
238), a
dedicated encryption engine 1505 (Fig. 239), storage device encryption engines
1502
(Fig. 240), data processor encryption engines 1503 (Fig. 241), and
communications
221
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
device encryption engines 1504 (Fig. 242). Each of these encryption engines
can be
used alone, or in combination with some or all of the other engines.
9.30 Figure 243
By way of illustration and not limitation, Figure 243 lists the modular
software
subsystems and identifies commercially available protocols and products which
may
be used to implement the functionality of various modules in the system
architecture.
For example, the communications subsystem 1200 may be implemented using
low-level networking protocols such as TCP/IP sockets or SNA 1201.
Alternately,
the communications subsystem may be implemented at a higher level using a
message
1o queuing and distribution system such as IBM MQ-Series 1202 BEA MessageQ
1203.
The transaction coordination subsystem 1300 can be implemented using
message broadcasting, routing and distribution software from Talarian 1301 or
more
traditional transaction process monitors such as BEA Tuxedo 1302.
The user interaction subsystem 1400 includes the user interfaces required for
~5 an individual or corporate user to perform actions such as inquiries as to
account
balances, manipulation of account structures, and the initiation of
transactions via any
communication medium including Internet web browsers, touch tone/ voice
recognition response, cell phone, and wireless technologies such as WAP. User
interaction portals that can be made accessible (a) from a web browser, are
2o commercially available from S1 corporation including their S1 Retail
Banking 1401,
and (b) from a touch tone, voice recognition, cell phone or wireless device,
are
commercially available from S1, e.g., Edify IVR.
The cryptographic processing subsystem 1500 can be implemented using
public key cryptography toolkits available from vendors such as RSA 1502 or
using
25 symmetric and split key cryptography toollcits from TecSec CI~M 1501.
The records management subsystem 1600 can be implemented using any
commercially available database including products such as Oracle RDBMS 8I
1601
or 1BM DB2 1602. The records management subsystem includes an on-line
transaction processing (OLTP) component operating in conjunction with a data
3o warehouse or analytical component.
222
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The application logic subsystem 1700 consists of all of the specialized
computer code necessary to build the specific functionality of the module,
such as
account manipulation, transaction processing, account profiling, as well as
any
specialized account features, such as escrow, bid, and gambling/gaming, that
may be
selected for inclusion. Application logic can be built using custom code in
computer
languages such as Java 1701 or "C" 1702. Alternately, transactions can be
evaluated
and processed using a commercial message management, mapping, and data
transformation processor such as GE InterLinx 1703.
The subsystems should have an appropriate execution environment, which for
example includes a clock 1010, an operating system 1100 (for which there are
many
possible choices), CPUs) 1020, memory 1030, network interfaces 1040,
input/output
(I/O) controller 1050, and internal data storage 1060.
9.31 Figures 244247
In Figures 244 and 245, various possible configurations of hardware and
software are described, including data storage that may be internal 1060
and/or
external 1061. In Figure 246 the configuration of the hardware is clustered to
share
data to achieve a higher probability that at least one of the computers will
be available
to process transactions and interact with users. In Figure 247, the software
configuration is shown with the various subsystems operating in a coordinated
fashion
2o using multiple computers connected via a network.
9.32 Figures 248-250
In the figures, representative configurations of hardware and software are
shown for naming systems, clearinghouse systems, and labeling systems.
9.33 Figures 25'1 255
In figures 251-254, sample hardware models are shown for small, large, and
high availability repositories 3000, naming systems 5010, clearinghouse
systems 4010
and labeling systems 6010. In Figure 255, a sample inter-networked
configuration
3410 comprising a selection of small, large, and high availability systems is
shown
223
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
along with communications networking equipment such as routers 3420,
concentrators 3430, and bridges 3440.
224
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
10.1 Arochitecture Considerations
When selecting the physical hardware components of repositories,
clearinghouses, naming systems, and label systems, the architect must consider
reliability, availability, maintainability, security, performance, and budget.
It is
impossible to achieve a perfectly reliable, 100% available, easily
maintainable, totally
secure, instantaneously performing set of systems. Given a reasonable budget,
currently available hardware and software components are available that allow
the
creation of a highly reliable, 99.95% available, serviceable, highly secure,
and top
1o performing set of systems. The architect must make trade-offs between costs
of
individual technologies and benefits achieved. Technology is subject to the
law of
diminishing returns - each step toward perfection costs significantly more for
each
incrementally smaller improvement, with total perfection being an unreachable
goal.
Reliability is the measure of the amount of time between failures. For systems
containing many component parts, the reliability is limited to the mean time
between
failures (MTBF) of the part most likely to fail. Reliability considers not
just the
MTBF of the specific hardware, but extends to the environment in which the
equipment is located. The environmental concerns include building
infrastructure
such as power conditioning, HVAC, fire suppression, and communications
capability.
2o Reliability can be improved by redundancy. Fault tolerant equipment
contains
redundant components which continue processing in the event of a failure.
Common
types of fault tolerance include multiple uninterruptable power supplies,
redundant
disk drives, drive controllers, network cards, communication pathways, and
generators.
Availability is the measure of the amount of time a system is accessible and
free of failures or planned outages. High availability equipment typically is
fault
tolerant to minimize the impact of component failures, but also includes one
or more
redundant operational sites. When one site fails, a backup site takes over
operational
duties (sometimes with degraded performance). Backups can be configured to act
as
3o mirrors of the operational site or as standby systems that can be brought
up to date
and online quickly. Several other strategies are also available: fast crash
recovery
22s
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
where the system does not try to totally avoid crashes, but rather tries to
recover from
crashes as quickly as possible; and massively distributed configurations where
the
desired services and data (replicated or copied) can be obtained from any of a
multitude of potential systems.
Maintainability is a measure of ease of service maintenance. Systems
maintainability is affected by the need for and required frequency of planned
service,
ease of preventative maintenance, emergency maintenance, and upgrades. Some
systems are designed to allow service while they are operating and others
require that
systems be unavailable during maintenance with attendant implications to
availability.
Systems maintenance is further complicated by compatibility concerns between
versions of operating systems, databases, encryption engines, communications
protocols, server software, and application codes.
Security is the measure of the trustworthiness and integrity of the system.
Secure access can be verified using PINs, passwords or other authenticating
tokens
~5 such as biometric signatures and digital certificates. The operating
system, database,
messaging queues, and interaction protocols must be protected from
unauthorized
access. Security is enhanced with encryption of data at rest, data in transit,
and data
in process, but additional steps should be taken to be sure that encryption
keys are
properly managed. Security must account for the validity and veracity of data
and
2o commands from other systems (both trusted and unfrosted). Security can be
enhanced
with tripwires and other intrusion detection mechanisms that act as alarms.
System
security is a combination of protection against electronic incursion, physical
barriers,
policies, procedures, and controls that minimize the threat from outside and
inside,
including sabotage.
25 Performance is the measure of the speed of execution of commands and the
manipulation of data. Faster performance reduces wait times for customers.
Performance requirements for a system are calculated for sustained, burst, and
peak
activity levels. Depending on usage cycles and customer expectations, needs
will
vary. Load balancing can be used to spread the work over multiple servers, and
is
3o usually based upon available memory and unused processing power.
Budget is usually the limiting factor in system procurement. The architect
sizes the system by creating a capacity plan showing expected levels of
activity for
226
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
sustained, burst, and peak activity levels and then matching it to account
holder
requirements. While budgets are often limiting, they must also be sufficiently
large to
allow sufficiently strong implementations of each of the other considerations
so as not
be over-weighted or under-weighted for any one consideration.
10.2 Disaster Recovery
When disasters strike, financial data must be protected from loss. Although
the best solutions, often very expensive, provide for geographically
dispersed,
redundant, fault tolerant, high availability systems, budgetary limitations or
practical
implementation concerns may dictate selection of less capable equipment. In
the
event that a replica is not constructed, is unavailable, or is damaged, the
original data
must be restored. In order to prevent the catastrophic loss of data, backups
are
essential. Restoration may take place on the same computer hardware or
different
hardware at a totally different location. Backups may be complete or
incremental.
They may be "cold" backups taken when systems were not running or "hot"
backups
~5 that are taken while systems are operating.
10.3 Encryption
Cryptography is the process of taking information (called the plaintext) and
passing it through an encryption process to produce an encrypted copy of the
information (called the ciphertext) that can be decrypted and restored to the
original
2o plaintext through the application of a cipher key. Modern cryptography is
based on
encryption algorithms that apply mathematical keys to plaintext to produce
ciphertext.
The strength of a cryptographic key is measured by how hard it would be for an
outsider to guess the key from the ciphertext. The longer the mathematical key
used,
in general, the more secure the encryption system will be from attack by
outsiders.
25 The size of a cryptographic key is measured in bits, such as 56 bits, 128
bits, or 392
bits. The more samples of ciphertext that are available, the more information
a
cryptanalyst has to work with in trying to break a key. Thus, an important
principle of
cryptographic key management is that keys should be retired at regular
intervals and
replaced with new keys.
22~
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
There are two main types of cryptography: conventional (also known as secret
key or symmetric) and public key (also known as asymmetric or dual key). With
conventional cryptography, the same key is used to both encrypt and decrypt a
message. Public key or asymmetric cryptography substantially solves the
problem of
key distribution. Public key cryptography is based on a mathematical
breakthrough
that permits two different but related keys to be used to encrypt and decrypt
messages.
One key (known as the public key) can be freely distributed and used by
anyone. The
other key, known as the private key, must be kept secure. Although the two
keys
have a mathematical relationship to each other, it is extremely difficult to
use one key
to guess the other. A public key can be used to send a message to the holder
of the
private key. The sender is assured that no one other than the holder of the
private key
will be able to read the contents of the message. Furthermore, the private key
can be
used to encrypt a message that the public key can be used to decrypt. This use
of the
keys permits a holder of the public key to be certain that a message came from
no
~ 5 source other than a holder of the private key corresponding to the public
key used to
decrypt the message.
One disadvantage of public key cryptography compared with symmetric key
cryptography is that the process of encryption is more computationally
intensive
because of the complex mathematical algorithms necessary to produce the
asymmetric
2o keys. As a result, public key cryptography is not well suited for
encrypting bodies of
data. However, if the contents of a message do not require a high degree of
confidentiality but an authentication is needed, public key cryptography can
be used
to produce a "digital signature" that assures the recipient of the
authenticity of the
message and the integrity of the contents, without the guaranteed
confidentiality of
25 the text of the message.
A certification authority is a trusted third party who is in the business of
associating a public key with a particular individual. The certification
authority
associates an individual with a public key by issuing a certificate that at a
minimum
contains a copy of the public key in question and the identity of the person
associated
3o with it. It may also include information about how long the certificate
will be valid or
special characteristics identifying the context in which the public key will
be used.
The certification authority then signs the certificate with its own digital
signature.
228
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Constructive Key Management (CKM) is a cryptographic key management
and distribution system. The design builds on the advantages, and takes into
account
the disadvantages, of both public and symmetric cryptographic key management.
CKM combines a cryptographic key generation process based on split keys with
access control credentials and an authentication process based on public-key
techniques. CKM technology is integrated into ANSI Standard X9.69 "Framework
for Key Management Extensions."
CKM is a cryptographic key management method that embeds role-based
access attributes within the object itself. These attributes reflect access
policies
mandated by network owners and/or administrators. The access parameters of
each
object may be determined without access to content. This enables flow control
of
objects by network routing and other smart control devices. Flow control
thereby
enforces end-to-end traffic within the network. Proportional access to the
content of
each obj ect is cryptographically enforced.
15 CKM is well suited for role-based access designs that look to the roles
users
have within an organization, and to the information access that is assigned to
each
role. Users' access permissions are changed as their roles within an
organization
change. Under CKM, any number of roles may be identified for an organization
or
defined group of users. A matrix of identified roles, mirroring existing
organizational
2o roles, is then made part of the cryptographic key management system.
As a symmetric design, the cryptographic architecture model for CKM is
restricted to those users authorized to participate. A new user is assigned a
specific
suite of key splits reflecting that person's access profile. By these means,
participation in the encryption and decryption process can be controlled. CKM
can be
25 applied to data-at-rest and data-in-transit. In addition, the CKM process
can be part of
the key and attribute exchange process for data transmission.
In order to protect the integrity of virtual accounts, assets, account
content,
repositories, clearinghouses, naming systems, and label systems, data may be
encrypted and decrypted as it is processed, in transit, andlor while it is at
rest.
3o Encryption is a key component of the preferred system architecture. There
are many
commercially available and public domain encryption algorithms that can be
used in
conjunction with virtual accounts, repositories, clearinghouses, naming
systems, and
229
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
label systems. These algorithms include Public Key (PK such as DES, RSA, PGP)
and Constructive Key Management (CKM such as TecSec).
10.4 Software Architecturte
To implement the functionality of the repositories, clearinghouses, naming
systems, and label systems, each component and sub-component could be coded
from
scratch. However, software is rarely constructed from scratch, but rather is
an
integration of existing commercial software components providing generic
capabilities. Usually, only the custom logic of the specific application needs
to be
coded from scratch.
~ 0 10.5 Repositories
10.5.1 Configurations
Virtual account repositories are designed to be deployable in a number of
different configurations that are each individually useful. Examples of these
configurations include discrete repositories, distributed groups of
repositories,
~ 5 federated groups of repositories, and federated and distributed groups of
repositories.
Any or all of these various individual and group configurations of
repositories can be
connected together into an inter-network configuration.
Discrete repositories are individual repositories that implicitly trust no
other
repositories. Discrete repositories standalone, are self contained, but can
still be inter-
2o connected with other repositories using an inter-network. Discrete
repositories can
support small, medium, and large user populations. Discrete repositories are
appropriate for closed communities of members. These may be relatively small
groups such as the customers of a single casino or single retail
establishment;
moderate size groups such as the customers of an online auction service,
students at a
25 university, or a retail chain; or large groups such as beneficiaries of
government
benefits. A single large repository may be easier and more efficient to
manipulate
than multiple smaller repositories, which may be less expensive and more
reliable.
Distributed groups of repositories are discrete repositories that are linked
together with one or more communications pathways. Distributed groups are
230
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
typically geographically disparate. Distributed repositories although linked
together,
must sometimes operate under differing constraints, perhaps due to deployment
across
the borders of nations with different laws.
In Federated groups, the repositories implicitly trust other member
repositories
of the federation, allowing an extended range of transactions that might
otherwise be
limited or barred in a distributed group. Federated repositories communicate
with
each other but are often co-located or consolidated into regional sites.
Federated
groups can be used to partition or segment an account holder population into
multiple
smaller repositories to make them easier to manage.
Federated, distributed groups of repositories are configured to implicitly
trust
other repositories whether located nearby or far away. They combine the best
features
of distributed repositories with those of federated repositories.
The inter-networked configurations have communications infrastructure that
allows discrete repositories or members of groups of repositories (in any
15 configuration) to exchange transactions and publish information. This is
accomplished by communicating over pathways using standard protocols such as
TCIP/If and SNA through a series of consolidators, routers, and bridges.
Clearinghouses, naming systems, and label systems can further support the
inter-
network by providing components needed by repositories to discover each other,
to
2o establish trusting relationships using intermediary services, and to
successfully
transact secure operations. An inter-networked configuration of virtual
accounts can
be used to create a massively-distributed, highly redundant account management
backbone capable of surviving nearly any natural disaster or regional
disruption of
service. Distributed systems with many levels of fault tolerance are highly
desirable
2s attributes of financial services systems.
10.5.2 Repository Software Integration
Each repository is comprised of subsystems: e.g., communications, transaction
coordination, records management, cryptographic processing, application logic,
and
user interaction.
3o The repository subsystems can be assembled by integrating commercial-off
the-shelf (COTS) software packages with custom-built application logic
supported by
231
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
message-based communications using formats derived from international
standards
such as ISO 15022 and EDIFACT. The communications subsystem consists of the
TCP/IP network transport protocol as implemented by an operating system,
typically
Microsoft Windows NT or UNIX (including derivatives such as Sun Solaris,
Hewlett-
s Packard HP-UX, and IBM AIX). Alternate protocols such as SNA, FTP, or others
may be substituted. Transaction communication processes based upon message
queue
servers and clients utilize the transport protocol. Queue management software
such as
IBM MQ-Series or BEA MessageQ can be used to create fault-tolerant queues with
persistent data storage and real-time integration with the records management
system.
The availability and flexibility of message queues can be further enhanced
using
Talarian MQexpress to add publish-subscribe interfaces that extend the
functionality
of the underlying queue management software.
The transaction coordination subsystem is used to route messages between
queues and servers as well as integrating queues with application processing
logic.
~ 5 Talarian SmartSockets provides naming service, dynamic transaction
routing, and
shortest-path route discovery. BEA Tuxedo provides transaction monitor
capabilities
to coordinate transactions, and is particularly useful for distributed
repository
configurations.
The records management subsystem provides a persistent data storage
2o capability with a high degree of transactional integrity, guaranteeing
referential
integrity between various bits of related data, and extensive query support.
Relational
Database Management System (RDBMS) implementations such as Oracle Si and IBM
DB2 both support data management, archive management, and standards-based
query
languages such as Structured Query Language (SQL). The records management
25 subsystem can also be used to support the data analysis, aggregation, and
account
profiling activities of data warehousing and data mining.
The cryptographic processing subsystem provides the ability to encrypt and
decrypt messages passing through specific queues. TecSec Constructive Key
Management (CKM) encryption/decryption products provide an implementation of
so ANSI Standard X9.69 suitable for the encoding and decoding of individual
messages
and stored data within a repository as well as for encrypted communications
that are
coordinated with external systems such as a clearinghouse. RSA Security
provides
the RSA Keon Public Key Infrastructure (PKI) products for the management of
digital
232
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
certificates. RSA also provides alternative encryption techniques suitable for
encrypting message traffic.
Application logic will ordinarily be custom-built programming logic that
retrieves incoming messages from queues, acts on those messages, and then
places
outgoing messages onto the appropriate queues. The programming logic interacts
with the records management system to store the results of calculations and
other data
manipulation. Application logic can be built using languages such as Java and
C. In
message processing systems, a significant amount of the application logic is
related to
the reformatting and transformation of messages from one type to another. For
existing systems such as the SWIFT interbank systems and standards-based EDI
transactions, message-mapping software such as GE InterLinx can be purchased
with
hundreds of pre-built maps and message templates.
User interaction requires flexible interfaces. Account information should be
available in real-time via interaction interfaces over the Internet using a
web browser,
personal digital assistant (PDA), wireless device, or network appliance as
well as by
phone or e-mail. This requires deployment of technologies such as the Wireless
Access Protocol (WAP) and voice recognition software. S1 has developed a
Retail
Banking portal that provides a web browser-based implementation of banking
software suitable for the basic presentation of a virtual assets account. S 1
also
2o manufactures the Edify IVR products for integration with voice and wireless
devices
that is integrated with the Retail Banking portal. Corillian manufactures a
Consumer
Banking Suite, which can be substituted as an alternative to the S1 offerings.
10.5.3 Repository Hardware Architecture
Subsystems can coexist on a single computer or be distributed across multiple
computers. For a high availability configuration, tvvo or more similarly
configured
servers act as coordinated nodes of a cluster sharing a common set of external
storage
devices. Fault-tolerance can be further enhanced using redundant power
supplies,
disk drives, processors, memory, I/O controllers, and network interfaces.
3o A workgroup or enterprise server with sufficient memory, conununications
bandwidth, processing capability, and data storage can be used to host the
repository.
233
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
For repositories with smaller numbers of accounts, an example of a suitable
personal
computer or workstation is the Dell PowerEdge 1300 configured with at least
one
Intel Pentium III processor, 256MB or more of RAM, an Intel Pro/100+ Dual Port
Server Adapter network communications interface, a PowerEdge Expandable RAID
disk controller, and four Seagate ST39103LC Ultra2 SCSI disk drives housed in
the
R.A~ cabinet, running the Microsoft Windows NT 4.0 operating system.
For larger or more active repositories, a mid-range enterprise server such as
the Sun E4500 can be used, having one or more UltraSparc processors, 512MB or
more RAM, with one or more I/O boaxds supporting 10/100 or gigabit Ethernet
network interfaces, one or more SBUS FC-AL fibre channel I/O boards, and at
least
one external Sun StorEdge A3500FC disk array, running the Sun Solaris 2.6
operating
system. A high-availability configuration can be achieved using two or more
similarly configured Sun E4500 mid-range enterprise servers sharing a common,
external Sun StorEdge A3500FC disk array with the addition of Sun Cluster 2.2
~ 5 operating system software.
10.6 Clearinghouses
10.6.1 Clearinghouse Software Integration
Each clearinghouse is comprised of subsystems: e.g., communications,
transaction coordination, records management, cryptographic processing,
application
20 logic, and user interaction.
The clearinghouse subsystems can be assembled by integrating commercial-
off the-shelf (COTS) software packages with custom-built application logic
supported
by message-based communications using formats derived from international
standards
such as ISO 15022 and EDIFACT. The communications subsystem can include the
25 TCP/IP network transport protocol as implemented by an operating system,
typically
Microsoft Windows NT or UNIX (including derivatives such as Sun Solaris,
Hewlett-
Packard HP-UX, and IBM AIX). Alternate protocols such as SNA, FTP, or others
may be substituted. Transaction communication processes based upon message
queue
servers and clients utilize the transport protocol. Queue management software
such as
30 ~M MQ-Series or BEA MessageQ can be used to create fault-tolerant queues
with
persistent data storage and real-time integration with the records management
system.
234
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The availability and flexibility of message queues can be further enhanced
using
Talarian MQexpress to add publish-subscribe interfaces that extend the
functionality .
of the underlying queue management software.
The transaction coordination subsystem is used to route messages between
queues and servers as well as integrating queues with application processing
logic.
Talarian SmartSockets provides naming service, dynamic transaction routing,
and
shortest-path route discovery. BEA Tuxedo provides transaction monitor
capabilities
to coordinate transactions, and is particularly useful for transactions
between
distributed repositories or distributed clearinghouse configurations.
The records management subsystem provides a persistent data storage
capability with a high degree of transactional integrity, guaranteeing
referential
integrity between various bits of related data, and extensive query support.
Relational
Database Management System (RDBMS) implementations such as Oracle 8i and IBM
DB2 both support data management, archive management, and standards-based
query
languages such as Structured Query Language (SQL). The records management
subsystem can also be used to support the data analysis, aggregation, and
account
profiling activities of data warehousing and data mining.
The cryptographic processing subsystem provides the ability to encrypt and
decrypt messages passing through specific queues. TecSec Constructive Key
2o Management (CKM) encryption/decryption products provide an implementation
of
ANSI Standard X9.69 suitable for the encoding and decoding of individual
messages
and stored data within a repository as well as for encrypted communications
that are
coordinated with external systems such as other clearinghouses. RSA Security
provides the RSA Keon Public Key Infrastructure (PKI) products for the
management
of digital certificates. RSA also provides alternative encryption techniques
suitable
for encrypting message traffic.
Application logic will ordinarily be custom-built programming logic that
retrieves incoming messages from queues, acts on those messages, and then
places
outgoing messages onto the appropriate queues. The programming logic interacts
3o with the records management system to store the results of calculations and
other data
manipulation. Application logic can be built using languages such as Java and
C. In
message processing systems, a significant amount of the application logic is
related to
235
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
the reformatting and transformation of messages from one type to another. For
existing systems such as the SWIFT interbank systems and standards-based EDI
transactions, message-mapping software such as GE InterLinx can be purchased
with
hundreds of pre-built maps and message templates.
User interaction requires flexible interfaces. Account information should be
available in real-time via interaction interfaces over the Internet using a
web browser,
personal digital assistant (PDA), wireless device, or network appliance as
well as by
phone or e-mail. This requires deployment of technologies such as the Wireless
Access Protocol (WAP) and voice recognition software. S 1 has developed a
Retail
Banking portal that provides a web browser-based implementation of banking
software suitable for the basic presentation of a virtual assets account. S1
also
manufactures the Edify IVR products for integration with voice and wireless
devices
that is integrated with the Retail Banking portal. The SlVertical One products
allow
for account aggregation from multiple repositories and external accounts such
as bank
~ 5 accounts, credit card accounts, mutual fund accounts, and brokerage
accounts, to a
common portal.
10.6.2 Clearinghouse Hardware Architecture
Each clearinghouse is comprised of subsystems: communications, transaction
coordination, records management, cryptographic processing, application logic,
and
2o user interaction. Subsystems can coexist on a single computer or be
distributed across
multiple computers. For a high availability configuration, two or more
similarly
configured servers act as coordinated nodes of a cluster sharing a common set
of
external storage devices. Fault-tolerance can be further enhanced using
redundant
power supplies, disk drives, processors, memory, Il0 controllers, and network
25 interfaces.
An enterprise server with sufficient memory, communications bandwidth,
processing capability, and data storage can be used to host the clearinghouse.
For
clearinghouses with smaller numbers of concurrent transactions, one can use a
mid-
range enterprise sewer such as the Sun E4500 with one or more UltraSparc
3o processors, 512MB or more of RAM, one or more I/O boards supporting 10/100
or
gigabit Ethernet network interfaces, one or more SBUS FC-AL fibre channel I/O
boards, and at least one external Sun StorEdge A3500FC disk array, running the
Sun
236
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Solaris 2.6 operating system. A high-availability configuration can be
achieved using
two or more similarly configured Sun E4500 mid-range enterprise servers
sharing a
common, external Sun StorEdge A3500FC disk array with the addition of Sun
Cluster
2.2 operating system software.
For more active clearinghouses, Hewlett-Packard 9000 V2250 is a suitable
high-end enterprise server, especially when running the HP-UX 11 operating
system
with one or more 440-MHz PA-$500 processors, 1GB or more of RAM, one or more
I/O boards supporting 10/100 or gigabit Ethernet network interfaces, a fibre
channel
I/O board, at least one external disk array such as the EMC Symmetrix 3930-36.
A
high-availability configuration can be achieved using two or more similarly
configured Hewlett-Packard 9000 V2250 enterprise servers sharing a common,
external EMC Symmetrix 3930-36 disk array with the addition of HP HyperPlex
operating system software.
10.7 Naming Systems
10.7.1 Naming System Software Integration
Each naming system is comprised of subsystems: e.g., communications,
transaction coordination, records management, cryptographic processing,
application
logic, and user interaction.
The naming system subsystems can be assembled by integrating commercial-
off the-shelf (COTS) software packages with custom-built application logic
supported
by message-based communications using formats derived from international
standards
such as ISO 15022 and EDIFACT. The communications subsystem may include the
TCP/IP network transport protocol as implemented by an operating system,
typically
Microsoft Windows NT or UNIX (including derivatives such as Sun Solaris,
Hewlett-
Packard HP-UX, and IBM AIX). Alternate protocols such as SNA, FTP, or others
may be substituted. Transaction communication processes based upon message
queue
servers and clients utilize the transport protocol. Queue management software
such as
IBM MQ-Series or BEA MessageQ can be used to create fault-tolerant queues with
persistent data storage and real-time integration with the records management
system.
ao The availability and flexibility of message queues can be further enhanced
using
237
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Talarian MQexpress to add publish-subscribe interfaces that extend the
functionality
of the underlying queue management software.
The transaction coordination subsystem is used to route messages between
queues and servers as well as integrating queues with application processing
logic.
Talarian SmartSockets provides naming service, dynamic transaction routing,
and
shortest-path route discovery. BEA Tuxedo provides transaction monitor
capabilities
to coordinate transactions, and is particularly useful for distributed
repository
configurations.
The records management subsystem provides a persistent data storage
capability with a high degree of transactional integrity, guaranteeing
referential
integrity between various bits of related data, and extensive query support.
Relational
Database Management System (RDBMS) implementations such as Oracle 8i and IBM
DBE both support data management, archive management, and standards-based
query
languages such as Structured Query Language (SQL).
~ 5 The cryptographic processing subsystem provides the ability to encrypt and
decrypt messages passing through specific queues. TecSec Constructive Key
Management (CKM) encryption/decryption products provide an implementation of
ANSI Standard X9.69 suitable for the encoding and decoding of individual
messages
and stored data within a repository as well as for encrypted communications
that are
2o coordinated with external systems such as a clearinghouse. RSA Security
provides
the RSA Keon Public Key Infrastructure (PKI) products for the management of
digital
certificates. RSA also provides alternative encryption techniques suitable for
encrypting message traffic.
Application logic will ordinarily be custom-built programming logic that
25 retrieves incoming messages from queues, acts on those messages, and then
places
outgoing messages onto the appropriate queues. The programming logic interacts
with the records management system to store the results of calculations and
other data
manipulation. Application logic can be built using languages such as Java and
C.
Custom naming system logic will include name, alias, and address management
3o functionality.
User interaction with the naming system is likely to be limited except for
data
maintenance operations. The naming system services likely will be designed to
be
238
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
accessed programmatically using a sequence of inbound and outbound messages on
queues or an application programming interface (API).
10.7.2 Naming System Hardware Architecture
Subsystems can coexist on a single computer or be distributed across multiple
computers. For a high availability configuration, two or more similarly
configured
servers act as coordinated nodes of a cluster sharing a common set of external
storage
devices. Fault-tolerance can be further enhanced using redundant power
supplies,
disk drives, processors, memory, I/O controllers, and network interfaces.
A workgroup or enterprise server with sufficient memory, communications
bandwidth, processing capability, and data storage can be used to host the
naming
system. For repositories with smaller numbers of accounts, a personal computer
or
workstation will suffice, such as a Dell PowerEdge 1300 configured with at
least one
Intel Pentium III processor, 256MB or more of RAM, an Intel Pro/100+ Dual Port
Server Adapter network communications interface, a PowerEdge Expandable RAID
15 disk controller, and four Seagate ST39103LC Ultra2 SCSI disk drives housed
in the
RAID cabinet, running the Microsoft Windows NT 4.0 operating system.
Suitable equipment for larger or more active naming systems includes mid-
range enterprise servers such as the Sun E4500 with one or more UltraSparc
processors, 512MB or more of RAM, one or more I/O boards supporting 101100 or
2o gigabit Ethernet network interfaces, one or more SBUS FC-AL fibre channel
I/O
boards, and at least one external Sun StorEdge A3500FC disk array, running the
Sun
Solaris 2.6 operating system. A high-availability configuration can be
achieved using
two or more similarly configured Sun E4500 mid-range enterprise servers
sharing a
common, external Sun StorEdge A3500FC disk array with the addition of Sun
Cluster
25 2.2 operating system software.
239
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
10.8 Labeling Systems
10.8.1 Labeling System Software Integration
Each labeling system is comprised of subsystems: e.g., communications,
transaction coordination, records management, cryptographic processing,
application
logic, and user interaction.
The labeling system subsystems can be assembled by integrating commercial-
off the-shelf (COTS) software packages with custom-built application logic
supported
by message-based communications using formats derived from international
standards
such as ISO 15022 and EDIFACT. The communications subsystem may include the
TCP/IP network transport protocol as implemented by an operating system,
typically
Microsoft Windows NT or UNIX (including derivatives such as Sun Solaris,
Hewlett-
Packard HP-UX, and IBM AIX). Alternate protocols such as SNA, FTP, or others
may be substituted. Transaction communication processes based upon message
queue
servers and clients utilize the transport protocol. Queue management software
such as
~5 IBM MQ-Series or BEA MessageQ can be used to create fault-tolerant queues
with
persistent data storage and real-time integration with the records management
system.
The availability and flexibility of message queues can be further enhanced
using
Talarian MQexpress to add publish-subscribe interfaces that extend the
functionality
of the underlying queue management software.
2o The transaction coordination subsystem is used to route messages between
queues and servers as well as integrating queues with application processing
logic.
Talarian SmartSockets provides naming service, dynaanic transaction routing,
and
shortest-path route discovery. BEA Tuxedo provides transaction monitor
capabilities
to coordinate transactions, and is particularly useful for distributed
repository
25 configurations.
The records management subsystem provides a persistent data storage
capability with a high degree of transactional integrity, guaranteeing
referential
integrity between various bits of related data, and extensive query support.
Relational
Database Management System (RDBMS) implementations such as Oracle ~i and IBM
so DB2 both support data management, archive management, and standards-based
query
languages such as Structured Query Language (SQL).
240
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The cryptographic processing subsystem provides the ability to encrypt and
decrypt messages passing through specific queues. TecSec Constructive Key
Management (CKM) encryption/decryption products provide an implementation of
ANSI Standard X9.69 suitable for the encoding and decoding of individual
messages
and stored data within a repository as well as for encrypted communications
that are
coordinated with external systems such as a clearinghouse. RSA Security
provides
the RSA Keon Public Key Infrastructure (PKI) products for the management of
digital
certificates. RSA also provides alternative encryption techniques suitable for
encrypting message traffic.
Application logic will ordinarily be custom-built programming logic that
retrieves incoming messages from queues, acts on those messages, and then
places
outgoing messages onto the appropriate queues. The programming logic interacts
with the records management system to store the results of calculations and
other data
manipulation. Application logic can be built using languages such as Java and
C.
15 Custom labeling system logic will include label, alias, and address
management
fimctionality.
User interaction with the labeling system is likely to be limited except for
data
maintenance operations. The labeling system services likely will be designed
to be
accessed programmatically using a sequence of inbound and outbound messages on
2o queues or an application programming interface (API).
10.8.2 Labeling System Hardware Architecture
Subsystems can coexist on a single computer or be distributed across multiple
computers. For a high availability configuration, two or more similarly
configured
servers act as coordinated nodes of a cluster sharing a common set of external
storage
25 devices. Fault-tolerance can be further enhanced using redundant power
supplies,
disk drives, processors, memory, I/O controllers, and network interfaces.
A workgroup or enterprise server with sufficient memory, communications
bandwidth, processing capability, and data storage can be used to host the
label
system. For repositories with smaller numbers of accounts, a personal computer
or
3o workstation is suitable, such as a Dell PowerEdge 1300 configured with at
least one
Intel Pentium III processor, 256MB or more of RAM, an Intel Pro/100+ Dual Port
Server Adapter network communications interface, a PowerEdge Expandable RAID
241
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
disk controller, and four Seagate ST39103LC Ultra2 SCSI disk drives housed in
the
RAID cabinet, running the Microsoft Windows NT 4.0 operating system.
For larger or more active labeling systems, good results can be obtained with
a
mid-range enterprise server such as the Sun E4500 with one or more UltraSparc
processors, 512MB or more of RAM, one or more I/O boards supporting 10!100 or
gigabit Ethernet network interfaces, one or more SBUS FC-AL fibre channel I/O
boards, and at least one external Sun StorEdge A3500FC disk array, running the
Sun
Solaris 2.6 operating system. A high-availability configuration can be
achieved using
two or more similarly configured Sun E4500 mid-range enterprise servers
sharing a
1o common, external Sun StorEdge A3500FC disk array with the addition of Sun
Cluster
2.2 operating system software.
242
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The following terms are defined so as to provide a reference to readers in
their
review of other text in this application.
Account The term account includes any form of account,
whether standing alone or
' included in a group of accounts and the tokens
thereof. An account may
for example store information with respect
to tangible or intangible things or
. collections of things, such as assets of
value or no value, licenses,
relationships or rights or other things of
any kind. Where a system is not
restricted to one account, the things in
at least one of the respective
accounts, subject to any grouping requirements
imposed on the system,
can be retrieved andlor manipulated separately
from things in other
accounts.
Alias Any symbol, for instance one or more letters,
numbers, characters, patterns
or biometric readings that represents an
entity without identifying it
Alphanumeric Any symbol, which consists of any combination
of letters and digits and
possibly certain punctuation marks such as
commas and/or dashes
Anonymous Refers to the absence of, or lack of sufficient
amounts of, information that
identifies or defines, such as: information
about an account(s), for example
information concerning the ownership, control
or content of an account(s);
and information about the nature of logical
connections between accounts.
Anonymity, i.e. the absence or lack referred
to above, may be a condition
of a system, of a system component, or of
a person. Using a VAMS
(Virtual Account Management System) and information
about ownership as
illustrations, anonymous may refer to a total
absence of owner-identifying
information, or to the presence of some information
which is insufficient to
identify the owner, throughout a VAMS, or
at least in some portion of a
VAMS, such as in an account or domain.
While anonymity can refer to lack or insufficiency
of information
("ignorance") on the part of a system, it
can also, or in the alternative, refer
to ignorance on the part of a person. For
example, two children of the
same parent, each having his/her own child-type
sub-account subordinate
to the parent account of their common parent,
may each be totally ignorant
of the other child's account, although the
relationship between those sub-
accounts and the virtual account of their
parent is "known" to the account
management system and to their parent.
Anonymous An unlisted or unpublished owner where the
owner's identification is
ownership undisclosed or unknown
Anonymous An unlisted or unpublished relationship of
which one or more of the
relationship relationship participants may be unaware
Anonymous A transaction between one or more parties
in which the identity of at least
transaction one transaction participant is undisclosed
or unknown
243
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Authenticating An authenticating token is a token of any
token kind, such as a PIN or password,
that signifies the authority of an entity
that employs it to take one or more
forms of action, for example in or with respect
to an account, a virtual
account management system, any other form
of advanced asset
management system, a clearing house, a naming
service, any other
system included in or cooperative with any
of the foregoing or any
combination of the foregoing.
Bridge A networking device used to connect two separate
networks together such
that they appear as one logical unit to devices
on either side of the
connection
Child account A hierarchically subordinated account that
exists subject to the rules of a
parent account which is one level higher
on the hierarchy
Clearinghouse A system that acts as an intermediary to
facilitate transactions and
settlement activities between one or more
parties lacking a trusting
relationship
Closed system A system that allows interaction only among
a defined group of participants
Communications A device of any type, including without limitation
modems, routers,
device keyboards, keypads, card readers, infra red
"open air" transmitters and
receivers, and optical fiber senders and
receivers, through which it is
possible to convey information to and/or
from a computer system or a
portion thereof, such as may be required
for the operation of a virtual
account management system, of any other form
of AAMS (Advanced Asset
Management System), of a clearing house,
of a naming service, of any
other system included in or cooperative with
any of the foregoing or of any
combination of the foregoing, whether such
information constitutes data
and/or code.
Concentrator A networking device used to merge two or
more separate communications
channels into one consolidated communications
channel
Condition of A relationship between entities, for example
trust virtual account management
systems, other advanced asset management
systems, repositories,
clearing houses, naming services or other
systems included in or
cooperative with any of the foregoing, or
any combination of the foregoing,
which is accepted as sufficient by a first
entity (such as a clearinghouse) to
take action, such as entering into, facilitating
or completing a transaction or
otherwise manipulating one or more accounts
and/or content thereof, .
between a second entity (for example a seller)
and a third entity (for
example a buyer).
Constraint A restriction or rule that when enforced
compels the constrained entity to
avoid or to perform some action
Cryptography The enciphering and deciphering of messages
in secret code or cipher
Decryption To cryptographically convert data from code
to plaintext
Distributed A system in which processing occurs at more
system than one location in a
coordinated fashion
244
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Distributed, A system in which members of a group, processing
federated at many locations,
system agree to some form of centralized management
and minimum level of trust
between members of the group but retain control
of their own internal
affairs
Domain The mathematical set of entities that defines
a sphere of influence
Encryption To cryptographically convert data into a code
for security purposes
Entity A discrete unit that can be considered apart
from its properties, for example
an individual, partnership, association, corporation,
government,
government agency, other organization, communications
device or other
equipment
Escrow A deed, a bond, money, or other thing of value
held in trust by a party to be
turned over to a grantee only upon fulfillment
of a condition
Expression Something that manifests, embodies, or symbolizes
something else
Federated systemA system in which members of a group agree
to some form of centralized
management and minimum level of trust between
members of the group
but retain control of their own internal affairs
Hub A networleing device that joins communications
lines together in a star
configuration.
Identified ownershipA form of ownership where the owner's identification
is known, preferably
with certainty
Identified A relationship of which at least one of the
relationship participants is aware
relationships
Identified A transaction between one or more parties
in which the identity of at least
transactions one transaction participants) is known to
any other participant
Identity The set of distinguishing characteristics
that collectively signify a particular
entity
Identity maskingA process that provides a false identity for
an entity making it anonymous to
another
Label A symbol that acts as a published handle for
manipulation of an underlying
entity
Labeling systemA directory of account tokens and aliases
for those tokens
Manipulating Manipulating and manipulation are used in
the broadest possible sense to
refer to "operating upon" an object. For instance,
it includes activating,
authenticating, creating, deactivating, destroying,
evaluating, generating,
implementing, maintaining, modifying, querying,
registering, andlor other
forms operating upon. The object of such manipulation
may for example
be an accounts) or the content thereof.
Mask Something that serves to conceal, disguise
or cover up
245
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Naming system A directory of known systems and devices,
and system and device
addresses which can be queried and disclosed
to inquirers
Open system A system that allows interaction among potential
participants that are not
limited to. a defined list
Organization A group of physical persons, a corporation,
a legal entity, or a governmental
department or agency that acts on its own
behalf at its own discretion
Parent accountA hierarchically defined account that co-exists
with at least one
subordinated account relationship one level
lower in the hierarchy
Password A symbol, frequently alphanumeric, that is
used to gain secure access to a
device, system, communications network, account
or any other object,
service, or activity
Peer account A hierarchically defined account that co-exists
with at least one other
account at the same level in the hierarchy
Person An individual that acts on its own behalf
at its own discretion
PIN A Personal Identification Number, frequently
a password consisting of all
numeric digits used to gain secure access
to a device, communications
network, account or any other object, service,
or activity
Primary accountA sub-account, constituting all or part of
the public portion of a virtual
account, standing alone at the highest level
of subordination to the private
portion of the virtual account
Privacy The quality or state of being apart from unauthorized
intrusion or
observation
Private Intended for or restricted to the use of a
particular person or organization,
not known or intended to be known publicly
Private token A private symbol by which an account or other
object, for example, the
private portion of a virtual account, may
be recognized by the
administrators thereof
Public The quality or state of being exposed to general
view
Public token A public symbol, by which an account or other
object, for example, the
public portion of a virtual account, may be
recognized
Repository A system that includes and provides a unifying
management structure for
accounts
Router A networking device that fotvvards communications
from one
communications network to another
Secure In general, free from danger and from risk
of loss or made safe against
adverse contingencies; in a more particular
sense, configured to inhibit
unauthorized access
Sub-account An abbreviation of subordinate account
246
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Subordinate A hierarchically defined account that exists
account one or more levels removed
from the top of the hierarchy and is subject
to control from accounts higher
in the hierarchy
Switch A networking device that can join communications
lines together
Symbol One or more letters, numbers, characters,
patterns, biometric readings, or
any other thing that indirectly represents
another underlying entity whose
distinguishing features are obscured
Token Any symbol, using that term in its broadest
possible sense, which is
capable of serving as a unique indicator.
In the present invention, such
symbols may for example be letters of any
alphabet, punctuation or
inflection symbols, numerals of any type,
digital strings, graphic elements,
images of fingerprints (including minutiae),
images generated by retinal
scans, voice prints, other sound patterns,
electrical pulses, and other things
of whatever form or type that can serve as
unique indicators. These may
be used singly or in any combination. The
symbols are for example used
by an asset management system (e.g., an AAMS
(Advanced Asset
Management System, which may or may not be
or include a VAMS)) to
distinguish a given account from all other
accounts which the asset
management system may include or interact
with, and thus need be unique
only to the extent required to perform this
function. Outside the system, the
symbol may be wholly intangible, not fixed
in any form, or may be
embodied in (including within or on) any suitable
physical object, such as in
the magnetic string of a card resembling a
credit card, or in an integrated
chip of a smart card.
Transaction An activity or request, most frequently an
exchange or transfer of goods,
services or funds
Transaction A record of past activities or requests
history
Virtual An adjective that expresses a condition without
boundaries or constraints,
often used to define a feature or state that
is electronically processed or
simulated as opposed to taking place in the
physical world
Virtual accountAn account wherein ownership and control of
assets can be manipulated
without requiring the physical manifestation
of the asset
Virtual asset Any content of a virtual account
Virtualized A physical, real-world asset for which a digital
asset representation has been
stored in a virtual account
247
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Changes and Corrections
The following changes and corrections to typographical errors were made in
Patent Application
No. 09/569,023 "Advanced Asset Management Systems". No substantive corrections
~overe
made.
In the Specification:
1) Pg 61, line 16
".. . and determined. . ." to ".. . and -determined.. ."
2) Pg 77, line 27
"Figure 166 shows Physical assets Inbound to virtual account." to
"Figure 166 shows physical assets inbound to a virtual account."
3) Pg 77, line 28
"Figure 167 shows Physical assets Outbound from virtual account " to
"Figure 167 shows physical assets outbound from a virtual account."
4) Pg 110, line 32
"$400/week limit vs. ..." [Note: double space after vs.] to "$400/week limit
vs. ..."
[single space after vs.~
S) Pg I25, line 12
" » " »
(e.g. music ... , to (e.g., music ...
6) Pg 132, line 2
"(e.g. frequent dyer mules)" to ""(e.g., frequent flyer miles)"
7) Pg 141, line 8
"offerer" to "offeror"
8} Pg 162, line 12
"vs. ..." [Note: double space after vs.] to "vs. ..." [sixlgle space after
vs.)
9) Pg 168, line 30
"(e.g. daily...}" to '"'(e.g., daily...)"
10) Pg 185, line 20
"(e.g. checking...)" to "(e.g., checking...)"
11) Pg I85, line 21
"but the transactions are executed through An advanced asset..." to
"but the transactions are executed through an advanced asset ..."
248
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
12) Pg 186, line 29
"Additionally, a number of patents asset . .." to
"Additionally, a number of patents assert .. ."
13) Pg 211, line 4\
'snot made directly to any of the private accounts, but instead through pubic
accounts" to
"not made directly to any of the private accounts, but instead through public
accounts"
In the Claims:
I4) Pg 2C1, lines I0, 12, 14, I6, 18, 20, and 22
"An advanced asset management system havin according to claim 1 in" to
"An advanced asset management system according to claim 1 in"
15) Pg 262, lines I, 3, and 5
"An advanced asset management system ha, Vlng according to claim 1 in" to
"An advanced asset management system according to claim 1 in"
In the Drawings:
16) Figure I6
Missing object callout, LHS, in Virtual Account One, Private Account VAN(1,1 )
Add -[ 2210
I7) Figure 28
Missing object callout, LHS, in Virtual Account One, Private Account VAN(1,1)
Add -[ 2210
18) Figure 98
Object callout 3100 (Distributed Crroup) is now underlined
19) Figure 99
Object callout 3200 (Federated Group) is now underlined
20) Figure 100
Object callout 3300 (Distributed-Federated Group) is now underlined
21 ) Figure I 72
Under the RHS Escrow Account ("Obligations"), the second subordinate Proxy
account
"Dyamic". to "Dynamic"
249
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
22) Figure 179
Tn the Escrow Account (object = 2630)
"Delivery Reciept" to "Delivery R,e, ceipt"
23) Figure 180
In the Escrow Account (object = 2630)
"Delivery Reciept" to "Delivexy Recei t"
24) Figure 181
W the Escrow Account (object = 2630)
"Delivery Reciept" to "Delivery Recei t"
25) Figur a 192
External Stimuli (object = 2470)
"Withdrawl" to "Withdrawal"
2G) Figure 193
External Stimuli (object = 2470)
"Withdrawl" to "Withdrawal"
27) Figure 194
Extexnal Stimuli (object = 2470)
"Withdrawl" to "Withdrawal"
28) Figure 195
External Stimuli (object = 2470)
"Withdrawl" to "Withdrawal"
29) Figure I96
External Stimuli (object = 2470)
"Withdrawl" to "Withdrawal"
30) Figure 197
External Stimuli (object = 2470)
"Withdrawl" to "Withdrawal"
31) Figure 202
RHS, External Stinnuli (object = 2470)
"Withdrawl" to "Withdrawal"
32) Figure 205
Four places
"Labelinging" to "Labeling"
250
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Virtual a~.ssets Inc.
U.S. Patent Specification Enticed
"Advanced Asset Management Systems"
VIRTUAL ASSETS, INC.
10387 Eclipse Way
Columbia, MD 21044
(443) 414-8580
~ci~ynht 2f~00; X301 by'~?ir~ual Asset ~.c. All rights reserved.,
Px4prie~~y and cc~~.~ntia. '
2s1
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
Table of Contents
1
ABSTRACT.......................................................................
..........................,......................,.,..................,.....1
2 TECI~1VICAL
FIELD..........................................................................
.........................................................2
3 BACKGROUND OF THE
INVENTION......................................................................
...........................3
4 SiTlVn~~ARY OF THE EWENTION
...............................................................................
.......................... 9
4.1 APPARATUS CLAI1VIS:
...............................................................................
...............................................9
4.1.1
FirstAspect.'..................................................................
.................................................................9
4.1.2
SecondAspect:.........,........................................................
...........................................................19
4.1.3 Third Aspect:
...............................................................................
................................................. 22
4.1.4 FirstAspect,
continued:.....................................................................
..........................................24
4.1.5 Fourth Aspect:
...............................................................................
............................................... 39
4.2 METHOD CLAIMS:
...............................................................................
..................................................41
4.2.1 F~h Aspect:
...............................................................................
.................................................. 41
4.2.2 Sixth Aspect:
...............................................................................
.................................................. 43
4.2.3 Seventh Aspect:
...............................................................................
............................................. 45
4.2.4 Eighth Aspect:
...............................................................................
............................................... 46
4.2.5 Ninth Aspect.'
...............................................................................
................................................. 48
ADVANTAGES OF THE INVENTION
...............................................................................
.................50
6 BRIEF DESCRIPTION OF THE
DRAWINGS.......................................................................
.............57
7 GENERAL
EMBODll~ZENTS..................................................................
................................................86
7.1 OVERVIEW
...............................................................................
..............................................................
86
71.1AccountManagement..........................................................
........................................................87
71.2ContentManagement..........................................................
.........................................................88
71.3Transaction
Management.....................................................................
.......................................
90
7.2 SYSTEM Et,EMENTS
...............................................................................
................................................
92
7.3
VIRTUALAccourrrs...............................................................
..............................................................92
7.3.1Idirtual Accounts: An
Analogy........................................................................
.............................
94
73.2Account Creation
...............................................................................
..........................................
95
73.3Aceount Qwnership &
Control........................................................................
............................97
7.3.4Relationships c~.
Identification.................................................................
....................................97
7.3.5Information
Disclosure.....................................................................
.........................................100
73.6ParetZt
ChildRelationships.,...,...,..,................................................
..........................................101
73.7Domains....................................................................
..................................................................101
7.3.8Account
Encryption.....................................................................
...............................................103
73.9Account Classes
...............................................................................
..........................................104
7.4 118
DSrNAMIC
Tox.ENS
...............................................................................
...............................................
7.5 119
ACCOUNT
MODIFICATIONS..................................................................
...............................................
7.6 121
ACCOUNT
CONTENT........................................................................
....................................................
76.1ContentManipulation........................................................
........................................................121
7.6.2Content
Security.......................................................................
..................................................122
76.3DigitalAssets..............................................................
................................................................122
7. Non-digital Assets
...............................................................................
.......................................123
6.4
7.6.5Changing Ownership and
Control........................................................................
....................124
7. Asset Types
...............................................................................
..................................................124
6.6
7.6.7Document
Types..........................................................................
...............................................125
76.8ConvertirZg
Conterat....,..................................................................
.............................................126
7. Asset
Reservatiorzs..................................................................
....................................................127
6.9
7.7 128
ACCOUNT
REPOSITORIES
...............................................................................
.....................................
7.71Repository
Content........................................................................
.............................................128
772
DistributedRepositories........................................................
....................................................130
77.3FederatedRepositories......................................................
.......................................................,130
252
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
7.7.4 Distributed Federated
Repositories...................................................................
.......................131
7.7.5 Repositories: Inter-networked Repositories
...........,.................................................................13
1
7.7.6 Repository Encryption c~
Security.......................................................................
...,........,.........132
7.8 VIRTUAL
CLEARINGHOUSES.................................................................
..............................................133
7.8.1 General and Special
Services.......................................................................
.............................134
7.8.2 Escrow Services
...............................................................................
..........................................135
7.8.3
BidServices......................................................,.....,.......
............................................................136
7.8.4 Gaming Sezvices
................................,..............................................
.........................................136
7.8.5
AgezztServices...............,.................................................
...........................................................137
7.8.6 Tax & Fee Services
...............................................................................
.....................................137
7.8.7 Credential & License Services
...............................................................................
...................138
7.8.8 Digital Certificate
Services.......................................................................
..,..............................138
7.8.9 Digital Signature
Services.......................,...............................................
..................................139
7.8.10 Clearinghouse Encryption &
Security.......................................................................
...............140
7.9 141
VIRTUAL
NAMING
SYSTEMS........................................................................
.......................................
7.9.1 Search Requests
...............................................................................
..........................................142
7.9.2 Ownership
Certificates...................................................................
...........................................142
7.9.3 Naming Systems: An Analogy
..................................,............................................
....................142
7.9.4 Namizzg Systezn Encryption ~
Security.......................................................................
..............143
7.10 143
VIRTUAL
LABELING
SYSTEMS
...............................................................................
.............................
7.10.1 Label Generation &
Selection......................................................................
.............................145
7.10.2
Accouzztldentifzcation&Directories.............................................
............................,..............146
7.10.3 Digital Certificates & Digital Signatures
...............................................................................
..147
7.10.4 LabelingSystem Encryption &
Security.......................................................................
............149
7.11 149
ACCESS
METHODS
...............................................................................
...............................................
7.11.1 Private
Networks.......................................................................
.................................................150
7.11.2 Public
Networks.......................................................................
..................................................151
7.11.3 Private-Over-Public
Networks.......................................................................
...........................1
SI
7.11.4 Conznzunications Devices
...............................................................................
...........................151
7.11.5 Access Constraints
...............................................................................
......................................152
7.12 153
ATTRIBUTES
...............................................................................
.........................................................
7.12.1 Traditional Asset Management System
Attributes....................................................................1
54
7.12.2 Improvements to the State
oftheArt.......................................................................
..................155
7.12.3
ContentAttributes..............................................................
........,...............................................158
7.13 158
CONSTRA1NTS....................................................................
..................................................................
7.13.1 TraditionalAssetManagementSystem
Constraints.................................................................159
7.13.2 Improvements to the State of
theArt.........................................................................
................160
7.13.3 Hiez archies of Constraints
...............................................................................
.........................I
61
7.13.4
Collections....................................................................
..............................................................163
7.13.5 Contradictory
ConstraintResolution.........................................................,.
.............................163
7.13. Deferred Constraints
...............................................................................
..................................164
6
7.13.7 Boolean Operators and
Precedence..........................................................,..........
....................165
7.13.8 Integral
Constraints....................................................................
...............................................167
7.13.9 External
Constraints....................................................................
..............................................168
7.13.10Integral andExternal
Constraints...........................................:........................
....................168
7.13.11Constraint Security......................... 168
...............................................................................
...
7.13.12Constraint Encryption
...............................................................................
............................169
7.14 1E9
AGENTS,
ALERTS
& TRIGGERS
...............................................................................
...........................
7.14.1
Alerts.........................................................................
..................................................................169
7.14.2 Triggers
...............................................................................
.......................................................174
7.14.3 Agents
...............................................................................
..........................................................176
8 SPECIFIC
ElVIBOD11VVIENTS...............................................................
..................................................179
8.1 PRICING MECHANISMS AND ASSET TRANSFER SYSTEMS:
................................................................179
8.1.1
TheAdvantagesofVirtualAccounts.................................................
........................................180
8.1.2 One-to-One
Transactions...................................................,...............
.......................................181
8.1.3 One-to Many (andMany-to-
One)...........................................................................
..................184
8.1.4 Many-to
Many....................................,........................,.............
.................................................191
8.1.5 Basic
ContractLaw....................................................................
.................,.............................192
8.1.6 Electronic Contract Law and the Current State of the Art
......................................................193
253
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
8.2 DEVICELESS ACCESS To AccoUNTS
...............................................................................
...................196
8.3 FRAUD DETECTION
...............................................................................
..............................................197
8.4 DYrIAIvIIC ToI~EN GENERATION
DEVICES........................................................................
..................197
8.4.1 Justln-TimeRequested
VINs................................,..........................................
.........................198
8.4.2 Synchronized
Generation...........,...........................,.............................
.,...................................198
8.4.3 Pay on Behalf Of
:..............................................................................
.........................................199
8.4.4 Request for Payment
Confirmation...................,...............................................
.......,................199
8.4.5
Security....................................................................,..
.............................,..................................199
8.4.6 Magnetic Strzpe Generation
...............................................................................
.......................200
8.5 SOCIAL, BENEFITS
...............................................................................
.................................................200
9 DETAILED DESCRIPTION OF THE DRAWINGS
........................................................................203
9.1 FIGURES 1 Arm
2
...............................................................................
..................................................203
9.2 FIGURES 3-
10.............................................................................
.............................,.........".................203
9.3 FIGURES 11-
48.............................................................................
........................................................204
9.3.1 Figures 11-
14.............................................................................
................................................204
9.3.2 Figures I
...............................................................................
...................................
S-26........... 204
9.3.3 Figures 27
.......................................................................,.......
...................................204
38...........
9.3.4 Figures 39-
48..........:..................................................................
................................................205
9.4 FIGURES 49-
84.............................................................................
........................................................205
9.4.1 Figures 49-
51...............................,.............................................
................................................205
9.4.2 Figures 52-
54.............................................................................
................................................205
9.4.3 Figures SS-
58.............................................................................
................................................205
9.4.4 Figures 59-
64.............................................................................
................................................205
9.4.5 Figures 65-
84.............................................................................
................................................206
9.5 FIGURES 85-
89.............................................................................
........................................................206
9.6 FIGURE 90
...............................................................................
.............................................................206
9.7 FIGURES 91-
97....................,........................................................
........................................................206
9.8 FIGURES 98-
102............................................................................
......................................207
................
9.8.1 Figure
98.............................................................................
.......................................................207
9.8.2 Fib re
99...........................,.................................................
.......................................................207
9.8.3 Figure
100............................................................................
......................................................207
9.8.4 Figures 101-
102............................................................................
.............................................208
9.9 FIGURES 103-
107............................................................................
......................................208
..............
9.10 FIGURES 108-
112...................,........................................................
......................................208
..............
9.11 FIGURES 113-
123............................................................................
......................................208
..............
9.11.1 Fibres113-
115............................................................................
..............................................209
9.11.2 Fibres l
...............................................................................
...................................
l b 118....... 209
9.11.3 Figures
...............................................................................
...................................209
119-123.......
9.12 FIGURES 124-133
...............................................................................
.................................................209
9.12.1 Figures
...............................................................................
.........................,.........210
124-128.......
9.12.2 Fibres 129-
133............................................................................
.............................................210
9.13 FIGURES 134-
135..................,.........................................................
......................................210
..............
9.14 FIGURES 136-145
...............................................................................
.................................................210
9.14.1 Figures
...............................................................................
...................................210
136-138.......
9.14.2 Figures
...............................................................................
...................................211
139-140.......
9.14.3 Figures
...............................................................................
...................................211
141-145.......
9.15 FIGURES 146-155
...............................................................................
.................................................211
9.15.1 Figures
...............................................................................
...................................211
146148.......
9.1 S.2 Figures
...............................................................................
...................................211
149-150.......
9.15.3 Figzsres
...............................................................................
...................................212
151-155.......
9.16 FIGURE
156............................................................................
..............................................................212
9.17 FIGURES 157-164
...............................................................................
.................................................212
9.18 FIGURE
165............................................................................
..............................................................213
9.19 FIGURES 166-
167............................................................................
....................................................213
9.20 FIGURES 168-170
...............................................................................
.................................................213
9.21 FIGURES 171-203
...............................................................................
.................................................213
9.21.1 Figure
171............................................................................
......................................................213
9.21.2 Figure
172............................................................................
......................................................213
9.21.3 Figures
...........,...................................................................
...................................214
173-174.......
254
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9.21.4 Figures 175-
176......................................,.....................................
.............................................214
9.21.5 Figures
177180.........................................................................
................................................214
9.21.6 Figures 181-
184......................................................,.....................
.............................................21 S
9.21.7 Figures 185-
188............................................................................
.............................................216
9.21.8 Figures 189-
198........................................................................,...
.............................................216
9.22 FIGURES 199-203
...............................................................................
.................................................218
9.22.1 Figure
199............................................................................
......................................................218
9.22.2 Figure
200............................................................................
......................................................218
9.22.3 Figure 201..........................................;218
...............................................................................
........
9.22.4 Figure
202......................,...........,.........................................
......................................................219
9.23 FIGURE 203
...............................................................................
...........................................................219
9.24 FIGURES 204-213
...............................................................................
.................................................219
9.24.1 Figures 204-
208............................................................................
.............................................219
9.24.2 Figures 209-
213........................................:...................................
.............................................219
9.25 FIGURE
214............................................................................
..............................................................220
9.26 FIGURES 215-222
...............................................................................
.................................................220
9.27 FIGURES 223-226
...............................................................................
.................................................220
9.271 Figure
223............................................................................
......................................................220
9.272 Figure
224............................................................................
......................................................221
9.273 Figure
225............................................................................
.....................................,................221
9.274 Figure
226............................................................................
...................................................:..221
9.28 FIGURES 227-234
...............................................................................
.................................................221
9.28.1 Figures 227
229............................................................................
.............................................221
9.28.2 Figures 230-
234............................................................................
.............................................222
9.29 FIGURES 235-242
...............................................................................
.................................................222
9.29.1 Figures 235-
237............................................................................
.............................................222
9.29.2 Figures 238-
242............................................................................
.............................................222
9.30 FIGURE 243
...............................................................................
...........................................................223
9.31 FIGURES 244-247
...............................................................................
.................................................224
9.32 FIGURES 248-250
...............................................................................
.................................................224
9.33 FIGURES 251-255
...............................................................................
.................................................224
SYSTE1VIS
ARCHITECTURE...................................................................
........................................226
10.1 titcCHITECTCTRE CONSIDERATTONS
...............................................................................
......................226
10.2 DISASTERRECOVERY
......................................,.,...................,..........,.......
........................,.................228
10.3
ENCRYPTION.....................................................................
...................................................................228
10.4
S~FTWAREAACHITECTCTRE................................,.,.......................
.....,.....,...........,..............................231
10.5
REPOSITORIES...................................................................
...................................................................231
10.5.1
Configurations.................................................................
...........................................................231
10.5.2 Repository Software Integration
...............................................................................
................232
10.5.3 Repository Hardware
Architecture...................................................................
........................234
10.6
CLEARINGIIOUSES................................................................
...............................................................235
10.6.1 Clearinghouse Software
Integration....................................................................
.....................235
10. 6.2 Clearinghouse Hardware Architecture
...............................................................................
.....237
10.7 NAMING
SYS'rEMS.......................................................................
........................................................238
10. 7.1 Naming System Software Integj
ation..........................................................................
..............238
10.7.2 Naming
SystemHardwareArchitecture......................................,..............
..............................240
10.8 LABELING
SYSTEMS........................................................................
....................................................241
10.8.1 Labeling System Software
Integration....................................................................
..................241
10.8.2 Labeling System Hardware
Architecture...................................................................
...............242
11 DEFINITIONS
...............................................................................
.......................................................244
12
CLAIMS.........................................................................
........................................................................249
12.1 249
~IrPARA~rus
CLAm~IS:.......................................................................
....................................................
12.1.1FirstAspect..............................................................
...................................................................249
12.1.2Second
Aspect.........................................................................
....................................................273
12.1.3ThirdAspect..............................................................
.................................................................283
12.1.4FirstAspect,
continued......................................................................
........................................287
12.1.5Fourth
Aspect.........................................................................
....................................................343
255
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
12.2 1VIE~oD CLAiMS:
...............................................................................
................................................347
12.2.1 F~h
Aspect.........................................................................
........................................................ 347
12.2.2 Sixth
Aspect...................,.....................................................
.......................................................351
12.2.3 Seventh
Aspect...............,.........................................................
................................................... 353
12.2.4 Eighth
Aspect.........................................................................
..................................................... 358
12.2.5 Ninth Aspect
.................."............................................................
............................................... 362
13 APPENDIX
A..............................................................................
..............................................................1
256
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
The following table identifies the objects labeled in the included drawings.
1000 Computer System
1001 Entity or Entities
1002 Transaction Participants
1010 System Clock
1020 CPU
1030 Memory
1040 Network Interface
1050 I/O Controller
1060 Storage Device
1061 Internal Data Storage
1062 External Data Storage
1100 Operating System
1200 Communications Subsystem
1201 Communications Devices)
1202 External Communications Devices)
1300 Transaction Coordination Subsystem
1400 User Interaction Subsystem
1500 Cryptographic Processing Subsystem
1501 VAMS Encryption Engine
1502 Storage Device Encryption Engine
1503 Data Processor Encryption Engine
1504 Communications Devices) Encryption Engine
1505 Dedicated Encryption Engine
1511 VAMS Repository Encryption Engine
1521 VA Clearinghouse Encryption Engine
257
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
1531 VA Naming System Encryption Engine
1541 VA Label System Encryption Engine
1551 Account/Attribute Management System Encryption
Engine
1561 Account/Constraint Management System Encryption
Engine
1571 Account/Token Management System Encryption
Engine
1581 Account/Hierarchy Management System Encryption
Engine
1600 Records Management Subsystem
1700 Application Logic Subsystem
1800 Name, Alias, and Address Management Subsystem
1900 Account Management System
1901 Asset Management Account
1910 Attribute Management Software
1911 Attributes
1912 User-selected Attributes
1913 User-determined Attributes
1914 User-defined Attributes
1920 Constraint Management Software
1921 Constraints
1922 User-selected Constraints
1923 User-determined Constraints
1924 User-defined Constraints
1940 Token Management Software
1941 Tokens
1950 Hierarchy Management Software
2000 Virtual Account Management Software
2100 Virtual Account
2200 Private Account
2201 Private Token
258
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
2210 Specific Private Account
2300 Public/Private Account Connection Interface
2400 Public Account
2401 Public Token
2410 Primary Account
2420 Subordinate Account
2421 Child Account
2422 Peer Account
2430 Account Constraint Set
2431 Imposed Account Constraint Limits
2450 Agents, Alerts, Triggers
2460 Asset
2470 External Stimuli
2480 Logical Connection
2500 Virtual Account Domain
2510 Private Account Domain
2520 Public Account Domain
2521 Domain Constraint Pool
2600 Escrow Account
2621 Escrow Child Account
2630 Escrow Constraint Set
2631 Escrow Constraint Set Skeleton
2700 Bid Account
2721 Bid Child Account
2730 Bid Constraint Set
259
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
2731 Bid Constraint Set Skeleton
2740 Bid Pool
2741 Bid
2800 Gaming Account
2821 Gaming Child Account
2830 Gaming Constraint Set
2831 Gaming Constraint Set Skeleton
2840 Gaming Pool
2841 Wager
2900 Proxy Account
2930 Proxy Constraint Set
2931 Proxy Constraint Set Skeleton
2940 "Real" Account
2990 Dynamic Proxy Account
3000 Virtual Account Repository
3100 Distributed Repositories
3110 Identified Communications Route
3200 Federated Repositories
3210 Trusted Communications Route
3300 Distributed-Federated Repositories
3400 Inter-networked Repositories
3410 Inter-Network Communications Route
3420 Router
3430 Concentrator
3440 Bridge
3450 Inter-network
260
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
4000 Virtual Account Clearinghouse Software
4010 VA Clearinghouse
4100 Escrow Transactions
4200 Bid Transactions
4300 Gaming/Gambling Transactions
4400 Tax & Fee Engine
4500 Digital Signature Engine
4600 Digital Certificate Engine
4700 Credential & License Engine
~
4800 Agent Services Engine
5000 Virtual Account Naming System Software
5010 VA Naming System
5100 List of Known Entities
5200 List of Entity Addresses
5300 List of Entity Aliases
5400 Entity Ownership Certificates
6000 Virtual Account Label System Software
6010 VA Label System
6100 Listed Labels
7000 Virtual Account and Repository Back End Systems
7010 Accounting System
7020 Host System
7030 Secure Gateway
7100 Access Devices
7110 Agent-Operated Access Devices
7111 Agent
261
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
1120 Self Service Access Devices
7130 Distributed Access Devices
7200 Closed Systems
7210 Micropayment System
7220 Digitized Cash/Coin
7230 Private Buying Network
7300 Stand-Alone Systems
7310 Electronic Wallet
7320 Smartcard
7400 Communications Networks
7410 Public Network
7420 Private Network
7430 Private-Over-Public Network
7500 Other External Systems
8000 Physical Assets
8100 Funding Event
8200 Settlement Event
8300 Release Event
9000 Dynamic Token Generation Device
9001 DTGD - Top Edge View
9002 DTGD - Front View
9003 DTGD - Back View
9004 DTGD - Side View
9101 DTGD CPU
9102 DTGD Clock/Timer
9103 DTGD Algorithm Engine
262
CA 02416550 2002-11-12
WO 01/84906 PCT/USO1/15283
9104 DTGD Non-Volatile Memory
9105 DTGD Tamper Detection Engine
9201 DTGD Internal Power Supply
9202 DTGD External Power Coupling
9203 DTGD On/Off Switch
9301 DTGD Encryption Engine
9302 DTGD Keypad Control
9303 DTGD Biometric Scanner
9401 DTGD Display Controller
9402 DTGD Radio Transceiver
9403 DTGD Infrared Transceiver
9404 DTGD Magnetic Stripe Generator
9405 DTGD I/O Contact Ports
9900 DTGD Form Factors
9910 Pager
9920 Cellular Phone
9930 Laptop Computer
9940 PDA
9950 Memory Stick
9960 Secure Device Memory Cards
263
