CA2416550A1 - Advanced asset management systems - Google Patents

Advanced asset management systems Download PDF

Info

Publication number
CA2416550A1
CA2416550A1 CA002416550A CA2416550A CA2416550A1 CA 2416550 A1 CA2416550 A1 CA 2416550A1 CA 002416550 A CA002416550 A CA 002416550A CA 2416550 A CA2416550 A CA 2416550A CA 2416550 A1 CA2416550 A1 CA 2416550A1
Authority
CA
Canada
Prior art keywords
account
asset management
management system
data
advanced asset
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002416550A
Other languages
French (fr)
Inventor
John V. Zambrzycki
Christopher K. Jackson
Carolyn H. Choie
Kevin W. Layman
Edward J. Newman, Jr.
David E. Richardson, Jr.
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
VIRTUAL ASSETS Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by VIRTUAL ASSETS Inc filed Critical VIRTUAL ASSETS Inc
Publication of CA2416550A1 publication Critical patent/CA2416550A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/387Payment using discounts or coupons
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance

Abstract

Methods and Systems for virtual account management, see figure 1, that establish public/private mechanisms (2000) with which users can transfer, transmit receive, aggregate and distribute and exchange cash and non-cash assets, wherein a user (1001), the user's account(s) (2100) and its transactions can be chosen to be any combination of anonymous, identified, masked or tracable. Also described are methods and systems for managing accounts, attributes, contents and other related objects. Applications of the systems may be in the field of retail, wholesale, entitlement, gifting, auction, barter, gaming, investment, security and other commercial and non-commercial activities.

Description

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.

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 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 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.

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 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 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.

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 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).

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 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.

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, 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 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 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 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 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~

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.

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, 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.

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.

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 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-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 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 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 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~

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 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.

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 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 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.

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 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 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 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.

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, 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.

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.

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 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).

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 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) 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 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) 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.

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).

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.

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 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 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 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 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 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 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 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.

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~

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 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.

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.

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.

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.

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 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.

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 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.

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 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.

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.

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 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 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 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.

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.

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 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).

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, 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.

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.

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 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 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.

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 inter-networked configuration using bridges, routers, and concentrators for networked communications.

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 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.

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 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 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 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.

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 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 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 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 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 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 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

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 ~ 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 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 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 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 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 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.

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 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.

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 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 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.

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 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 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.

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 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 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 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 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~

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 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.

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.

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 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 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.

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 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 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 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~

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 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 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;

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, 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, 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 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 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.

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 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) 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 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 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.

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 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.

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, 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 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.

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 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 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 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 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 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 ~ 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 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 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.

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 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.

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~

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 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 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 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 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.

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 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 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 ) 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.

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 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 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 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 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 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 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 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 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 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 of such objects. Other agents are external, such as those used to interact with external systems and proxy accounts.
1~~

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.

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, 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 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 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 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 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 ~ 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 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 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~

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 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 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 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 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 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 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.

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.

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 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 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.

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

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 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.
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 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.

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.

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 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.

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 (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 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.

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.

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 (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 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 (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.

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.

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 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 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.

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 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.

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 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 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~

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 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.

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 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 (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 (Fig. 240), data processor encryption engines 1503 (Fig. 241), and communications 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

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.

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 along with communications networking equipment such as routers 3420, concentrators 3430, and bridges 3440.
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 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 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~

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.

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 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 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 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 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.

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.

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 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 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 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 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.

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).

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

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.

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 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 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 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 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 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 ..."
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"

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"

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 Table of Contents ABSTRACT.......................................................................
..........................,......................,.,..................,.....1 2 TECI~1VICAL
FIELD..........................................................................
.........................................................2 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 DRAWINGS.......................................................................
.............57 EMBODll~ZENTS..................................................................
................................................86 7.1 OVERVIEW
...............................................................................
..............................................................

71.1AccountManagement..........................................................
........................................................87 71.2ContentManagement..........................................................
.........................................................88 71.3Transaction Management.....................................................................
.......................................

7.2 SYSTEM Et,EMENTS
...............................................................................
................................................

7.3 VIRTUALAccourrrs...............................................................
..............................................................92 7.3.1Idirtual Accounts: An Analogy........................................................................
.............................

73.2Account Creation ...............................................................................
..........................................

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 DistributedRepositories........................................................
....................................................130 77.3FederatedRepositories......................................................
.......................................................,130 7.7.4 Distributed Federated Repositories...................................................................
.......................131 7.7.5 Repositories: Inter-networked Repositories ...........,.................................................................13 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 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

7.13.4 Collections....................................................................
..............................................................163 7.13.5 Contradictory ConstraintResolution.........................................................,.
.............................163 7.13. Deferred Constraints ...............................................................................
..................................164 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 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 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 ........................................................................203 9.1 FIGURES 1 Arm ...............................................................................
..................................................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.......

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 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 ...............................................................................
.......................................................244 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 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 A..............................................................................
..............................................................1 The following table identifies the objects labeled in the included drawings.
1000 Computer System 1001 Entity or Entities 1002 Transaction Participants 1010 System Clock 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 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 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 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 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 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 9102 DTGD Clock/Timer 9103 DTGD Algorithm Engine 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 9950 Memory Stick 9960 Secure Device Memory Cards

Claims (818)

12 Claims 12.1 Apparatus claims:
12.1.1 First Aspect
1. An advanced asset management system, comprising:
A. a computer system having:
1) at least one data processor 2) at least one data storage device, and 3) 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;
B. account management software stored in said computer system on said at least one data storage device for storing and managing one or more accounts at least in part accessible via said at least one communications device, 1) at least a portion of said one or more accounts respectively comprising:
2) at least one token, stored in said computer system, that is/are a symbol(s) through which said one or more accounts is/are recognizable by the system, and 3) optionally, one or more additional public tokens, stored in the computer system, through which one or more additional direct and/or indirect sub-accounts of the account(s) is/are recognizable;
C. said system further comprising data and/or code through which the system recognizes said one or more accounts or said one or more sub-accounts thereof upon receipt, via said at least one communications device, of said at least one token or said one or more additional tokens;
wherein the account(s) stored in said computer system comprise one or more accounts, one or more direct or indirect sub-accounts thereof, and tokens) thereof, and whereby one or more entities other than account administrators, including persons, organizations and/or other computer systems, owning or having control of said account(s) or at least a portion of the content thereof, and, optionally, one or more third party entities, can manipulate said account(s).
2. An advanced asset management system according to claim 1 in which said system comprises a plurality of computer systems.
3. An advanced asset management system according to claim 1 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 an account(s).
4. An advanced asset management system according to claim 1 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate, an account(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization owning or having a right to control said account(s).
5. An advanced asset management system according to claim 1 comprising data and/or code for permitting access to an account(s).
6. An advanced asset management system according to claim 1 in which said at least one communications device is configured to permit access to an account(s) based on receipt via said at least one communications device of a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization to access said account(s).
7. An advanced asset management system according to claim 1 comprising data and/or code for managing one or more predetermined types of transactions in or with said account(s).
8. An advanced asset management system according to claim 1 in which said at least one storage device contains an historical record(s) pertaining to one or more completed transactions of said account(s).
9. An advanced asset management system according to claim 1 in which said at least one storage device contains an historical record(s) pertaining to one or more completed and/or one or more failed transactions of said account(s).
10. An advanced asset management system according to claim 1 in which said account(s) comprise a savings account(s).
11. An advanced asset management system according to claim 1 in which said account(s) comprise a checking account(s).
12. An advanced asset management system according to claim 1 in which said account(s) comprise a money-market account(s).
13. An advanced asset management system according to claim 1 in which said account(s) comprise an unsecured line of credit account(s).
14. An advanced asset management system according to claim 1 in which said account(s) comprise a secured line of credit account(s).
15. An advanced asset management system according to claim 1 in which said account(s) comprise a securities account(s).
16. An advanced asset management system according to claim 1 in which said account(s) comprise a virtual account(s).
17. An asset management system having attributes according to claim 1 in which said account(s) comprise a financial institution account(s).
18. An asset management system having attributes according to claim 1 in which said account(s) comprise a non-financial institution account(s).
19. An advanced asset management system according to claim 1 in which said account(s) comprise currency-based assets.
20. An advanced asset management system according to claim 1 in which said account(s) comprise non-currency-based assets.
21. An advanced asset management system according to claim 16 in which at least a portion of said virtual account(s) comprise:
A. at least one private token, stored in said computer system, that is/are a confidential symbol(s) through which virtual account(s) is/are recognizable by the system, B. at least one public token, stored in said computer system, that is/are a symbol(s) through which at least one primary public sub-account of virtual account(s) is/are recognizable by the system in communications between the system and an entity/entities, and C. 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 account(s) is/are recognizable by system in communications between the system and an entity/entities;
D. said system further comprising data and/or code:
1) through which the system to recognizes said virtual account(s) or said one or more public sub-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 2) prevents said entities from obtaining said at least one private token via said at least one communications device.
22. An advanced asset management system according to claim 16in which said virtual account(s) comprises a private token(s), through which the virtual account(s) 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 account(s), each recognizable by the system through its own public token(s).
23. An advanced asset management system according to claim 1 wherein ownership and control of said account(s) is anonymous, in that no information, or insufficient information, for signifying such ownership or control, is stored by the system.
24. An advanced asset management system according to claim 23 further comprising data and/or code for managing said anonymous account(s).
25. An advanced asset management system according to claim 1 wherein ownership and control of said account(s) is identified, in that sufficient information for identifying such ownership or control is stored by the system.
26. An advanced asset management system according to claim 25 further comprising data and/or code for managing said identified account(s).
27. An advanced asset management system according to claim 1 wherein ownership and control of said account(s) is identified, but with the true identity of said identified account(s) masked, in that the information stored by the system disguises such ownership or control.
28. An advanced asset management system according to claim 27 further comprising data and/or code for managing said masked account(s).
29. An advanced asset management system according to claim 1 having a plurality of account(s) in which ownership or control of a given account(s) differ(s) from at least one other account as to whether said account(s) are anonymous, identified, and/or masked.
30. An advanced asset management system according to claim 29 having a plurality of account(s) in which the system comprises data and/or code for managing accounts wherein the ownership or control of a given account(s) differ(s) from at least one other account as to whether said account(s) are anonymous, identified, and/or masked.
31. An advanced asset management system according to claim 1 in which the system comprises data and/or code that cause(s) the system to recognize one or more logical connections between an account(s) and another account(s).
32. An advanced asset management system according to claim 31 in which the logical connections are anonymous.
33. An advanced asset management system according to claim 31 in which the logical connections are identified.
34. An advanced asset management system according to claim 31 in which the logical connections are identified, but with their true identity masked.
35. An advanced asset management system according to claim 31 having a plurality of said logical connections in which at least one of the respective logical connections differs from at least one other logical connection as to whether the virtual account(s) involved therein is/are anonymous, identified, and/or masked.
36. An advanced asset management system according to claim 1 in which the system comprises data and/or code that cause(s) the system to recognize one or more logical connections from an account(s) to any sub-account(s).
37. An advanced asset management system according to claim 36 in which an account(s) is/are anonymous to the sub-account(s) connected with it/them.
38. An advanced asset management system according to claim 36 in which an account(s) is/are identified to the sub-account(s) connected with it/them.
39. An advanced asset management system according to claim 36 in which an account(s) is/are identified, but with its true identity masked, to the sub-account(s) connected with it/them.
40. An advanced asset management system according to claim 36 having a plurality of said logical connections in which at least one of the respective logical connections differs from at least one other logical connection as to whether an account(s) involved therein is/are anonymous, identified, and/or masked.
41. An advanced asset management system according to claim 1 in which the system comprises data and/or code that cause(s) the system to recognize one or more logical connections from a sub-account(s) to an account(s).
42. An advanced asset management system according to claim 41 in which a sub account(s) is/are anonymous to the account(s) connected with it/them.
43. An advanced asset management system according to claim 41 in which a sub-account(s) is/are identified to the account(s) connected with it/them.
44. An advanced asset management system according to claim 41 in which a sub-account(s) is/are identified, but with its true identity masked, to the account(s) connected with it/them.
45. An advanced asset management system according to claim 41 having a plurality of said logical connections in which at least one of the respective logical connections differs from at least one other logical connection as to whether a sub-account(s) involved therein is/are anonymous, identified, and/or masked.
46. An advanced asset management system according to claim 1 in which the system comprises data and/or code that cause(s) the system to recognize one or more logical connections between a sub-account(s) and another sub-account(s).
47. An advanced asset management system according to claim 46 in which the logical connections are anonymous.
48. An advanced asset management system according to claim 46 in which the logical connections are identified.
49. An advanced asset management system according to claim 46 in which the logical connections are identified, but with their true identity masked.
50. An advanced asset management system according to claim 46 having a plurality of said logical connections in which at least one of the respective logical connections differs from at least one other logical connection as to whether a sub-account(s) involved therein is/are anonymous, identified, and/or masked.
51. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, notwithstanding receipt via said communications device(s) of a token(s) for a particular account(s), withhold disclosure of all information concerning the account(s).
52. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, notwithstanding receipt via said communications device(s) of a token(s) for a particular account(s), withhold disclosure of all information concerning ownership or control of the account(s).
53. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, notwithstanding receipt via said communications device(s) of a token(s) for a particular account(s), withhold disclosure of all information concerning the content of the account(s).
54. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, notwithstanding receipt via said communications device(s) of a token(s) for a particular account(s), withhold disclosure of all information concerning any logical connection(s) in which the account(s) are involved.
55. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, notwithstanding receipt via said communications device(s) of a token(s) for a particular account(s), withhold disclosure of all information concerning any transaction(s) in which the account(s) are involved.
56. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, notwithstanding receipt via said communications device(s) of a token(s) for a particular account(s), withhold disclosure of all information concerning any transaction history/histories in which the account(s) have been involved.
57. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, upon receipt via said communications device(s) of a token(s) for a particular account(s), disclose at least a portion of any information concerning the account(s).
58. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, upon receipt via said communications device(s) of a token(s) for a particular account(s), disclose at least a portion of any information concerning ownership or control of the account(s).
59. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, upon receipt via said communications device(s) of a token(s) for a particular account(s), disclose at least a portion of any information concerning the content of the account(s).
60. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, upon receipt via said communications device(s) of a token(s) for a particular account(s), disclose at least a portion of any information concerning any logical connection(s) in which the account(s) are involved.
61. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, upon receipt via said communications device(s) of a token(s) for a particular account(s), disclose at least a portion of any information concerning any transaction(s) in which the account(s) are involved.
62. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will, upon receipt via said communications device(s) of a token(s) for a particular account(s), disclose at least a portion of any information concerning any transaction history/histories in which the account(s) have been involved.
63. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more continuing logical connections between accounts in which an account(s), serving as a parent account(s) to at least one account subordinate thereto, is/are anonymous to the subordinate account(s).
64. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more continuing logical connections between accounts in which an account(s), serving as a parent account(s) to at least one account subordinate thereto, is/are identified to the subordinate account(s).
65. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more continuing logical connections between accounts in which an account(s), serving as a parent account(s) to at least one account subordinate thereto, is/are identified, but with its true identity masked, to the subordinate account(s).
66. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve a plurality of continuing logical connections between accounts in which an account(s), serving as a parent account(s) to a plurality of accounts subordinate thereto, differ(s) in its/their relationships to at least two subordinate accounts as to whether the parent account(s) is/are anonymous, identified, and/or masked with respect to said subordinate accounts.
67. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more temporary, expiring logical connections between accounts in which an account(s), serving as a parent account(s) to at least one account subordinate thereto, is/are anonymous to the subordinate account(s).
68. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more temporary, expiring logical connections between accounts in which an account(s), serving as a parent account(s) to at least one account subordinate thereto, is/are identified to the subordinate account(s).
69. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more temporary, expiring logical connections between accounts in which an account(s), serving as a parent account(s) to at least one account subordinate thereto, is/are identified, but with its true identity masked, to the subordinate account(s).
70. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve a plurality of temporary, expiring logical connections between accounts in which an account(s), serving as a parent account(s) to a plurality of accounts subordinate thereto, differ(s) in its/their relationships to at least two subordinate accounts as to whether the parent account(s) is/are anonymous, identified, and/or masked with respect to said subordinate accounts.
71. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more continuing logical connections between accounts in which an account(s), subordinate to at least one account serving as a parent account(s) thereto, is/are anonymous to the parent account(s).
72. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more continuing logical connections between accounts in which an account(s), subordinate to at least one account serving as a parent account(s) thereto, is/are identified to the parent account(s).
73. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more continuing logical connections between accounts in which an account(s), subordinate to at least one account serving as a parent account(s) thereto, is/are identified, but with its true identity masked, to the parent account(s).
74. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve a plurality of continuing logical connections between accounts in which an account(s), subordinate to a plurality of accounts serving as a parent account(s) thereto, differ(s) in its/their relationships to at least two parent accounts as to whether the subordinate account(s) is/are anonymous, identified, and/or masked with respect to said parent accounts.
75. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more temporary, expiring logical connections between accounts in which an account(s), subordinate to at least one account serving as a parent account(s) thereto, is/are anonymous to the parent account(s).
76. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more temporary, expiring logical connections between accounts in which an account(s), subordinate to at least one account serving as a parent account(s) thereto, is/are identified to the parent account(s).
77. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve one or more temporary, expiring logical connections between accounts in which an account(s), subordinate to at least one account serving as a parent account(s) thereto, is/are identified, but with its true identity masked, to the parent account(s).
78. An advanced asset management system according to claim 1 in which the system comprises data and/or code that will establish and/or dissolve a plurality of temporary, expiring logical connections between accounts in which an account(s), subordinate to a plurality of accounts serving as a parent account(s) thereto, differ(s) in its/their relationships to at least two parent accounts as to whether the subordinate account(s) is/are anonymous, identified, and/or masked with respect to said parent accounts.
79. An advanced asset management system according to claim 1 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 domains.
80. An advanced asset management system according to claim 79 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a domain(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said domain(s).
81. An advanced asset management system according to claim 79 wherein all sub-accounts of an account are assigned to a particular domain and wherein said data and/or code 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.
82. An advanced asset management system according to claim 79 wherein one or more sub-accounts of an account are assigned to one or more domains and wherein said data and/or code 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.
83. An advanced asset management system according to claim 79 wherein all sub-accounts of an account, respectively represented by a private token(s), are assigned to a particular private domain, said private domain being restricted to sub-accounts represented by a private token(s), and wherein said data and/or code 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.
84. An advanced asset management system according to claim 79 wherein one or more sub-accounts of an account, respectively represented by a private token(s), are assigned to one or more private domains, said private domain(s) being restricted to sub-accounts represented by a private token(s), and wherein said data and/or code 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.
85. An advanced asset management system according to claim 79 wherein all sub-accounts of an account, respectively represented by a public token(s), are assigned to a particular public domain, said public domain being restricted to sub-accounts represented by a public token(s), and wherein said data and/or code 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.
86. An advanced asset management system according to claim 79 wherein one or more sub-accounts of an account, respectively represented by a public token(s), is/are assigned to one or more public domains, said public domain(s) being restricted to sub-accounts represented by a public token(s), and wherein said data and/or code 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.
87. An advanced asset management system according to claim 1 comprising means for encrypting an account(s).
88. An advanced asset management system according to claim 1 comprising means for encrypting all of said information about the account(s) stored by the system.
89. An advanced asset management system according to claim 88 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
90. An advanced asset management system according to claim 88 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
91. An advanced asset management system according to claim 88 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
92. An advanced asset management system according to claim 88 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
93. An advanced asset management system according to claim 88 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
94. An advanced asset management system according to claim 1 comprising means for encrypting at least a portion of any information about the account(s) stored by the system.
95. An advanced asset management system according to claim 94 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
96. An advanced asset management system according to claim 94 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
97. An advanced asset management system according to claim 94 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
98. An advanced asset management system according to claim 94 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
99. An advanced asset management system according to claim 94 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
100. An advanced asset management system according to claim 1 comprising means for encrypting all of said information about the account(s) processed by the system.
101. An advanced asset management system according to claim 100 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
102. An advanced asset management system according to claim 100 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
103. An advanced asset management system according to claim 100 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
104. An advanced asset management system according to claim 100 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
105. An advanced asset management system according to claim 100 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
106. An advanced asset management system according to claim 1 comprising means for encrypting at least a portion of any information about the account(s) processed by the system.
107. An advanced asset management system according to claim 106 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
108. An advanced asset management system according to claim 106 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
109. An advanced asset management system according to claim 106 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
110. An advanced asset management system according to claim 106 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
111. An advanced asset management system according to claim 106 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
112. An advanced asset management system according to claim 1 comprising means for encrypting all information about the account(s) communicated to or from the system.
113. An advanced asset management system according to claim 112 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
114. An advanced asset management system according to claim 112 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
115. An advanced asset management system according to claim 112 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
116. An advanced asset management system according to claim 112 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
117. An advanced asset management system according to claim 112 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
118. An advanced asset management system according to claim 1 comprising means for encrypting at least a portion of any information about the account(s) communicated to or from the system.
119. An advanced asset management system according to claim 118 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
120. An advanced asset management system according to claim 118 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
121. An advanced asset management system according to claim 118 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
122. An advanced asset management system according to claim 118 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
123. An advanced asset management system according to claim 118 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
124. An advanced asset management system according to claim 1 in which said computer system comprises 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 computer system, that can transmit a token(s) to said computer system, or receive a token from said computer system, whereby said second communications device(s) can participate in interactions with said account(s).
125. An advanced asset management system according to claim 1 in which said computer 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 account repositories, said repository/repositories containing one or more accounts.
126. An advanced asset management system according to claim 125 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a repository/repositories only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said repository/repositories.
127. An advanced asset management system according to claim 1 comprising any number of account repositories respectively comprising one or more accounts, and having one or more actual or potential communications connections with one or more other repositories comprising one or more accounts, said connection/connections affording the opportunity for interactions between the repositories and/or their respective account(s).
128. An advanced asset management system according to claim 1 comprising any number of account repositories respectively comprising one or more accounts, and having one or more actual or potential communications connections with one or more additional communications devices, said connection/connections affording the opportunity for interactions within or between the repository/repositories and/or its/their respective account(s).
129. An advanced asset management system according to claim 1 comprising any number of account repositories respectively comprising one or more accounts, and having one or more actual or potential communications connections with one or more other repositories comprising one or more accounts, and having one or more actual or potential communications connections to one or more additional communications devices, said connection/connections affording the opportunity for interactions within or between the repositories and/or their respective account(s).
130. An advanced asset management system according to claim 125 in which said repositories represent an open group not subject to any restriction(s) against an interaction(s) with one or more other repository/repositories or their respective account(s).
131. An advanced asset management system according to claim 125 in which said repositories represent an open group not subject to any restriction(s) against an interaction(s) with one or more additional communications devices.
132. An advanced asset management system according to claim 125 in which said repositories represent a controlled group subject to one or more restrictions against an interaction(s) with one or more other repositories, and/or their respective account(s), that are outside the group.
133. An advanced asset management system according to claim 125 in which said repositories represent a controlled group subject to one or more restrictions against a specific type(s) of interaction(s) with one or more repositories, and/or their respective account(s).
134. An advanced asset management system according to claim 125 in which said repositories represent a controlled group subject to one or more restrictions against an interaction(s) with other than an approved communications device(s).
135. An advanced asset management system according to claim 132 in which the system comprises data and/or code for dynamically selecting and applying said restriction(s) based on data received via said communications device(s).
136. An advanced asset management system according to claim 133 in which the system comprises data and/or code for dynamically selecting and applying said restriction(s) based on data received via said communications device(s).
137. An advanced asset management system according to claim 134 in which the system comprises data and/or code for dynamically selecting and applying said restriction(s) based on data received via said communications device(s).
138. An advanced asset management system according to claim 135 in which the system comprises data and/or code for enforcing or abrogating said restriction(s) based on the character of, and in response to receipt of, a PIN(s), password(s) or other authenticating token(s).
139. An advanced asset management system according to claim 136 in which the system comprises data and/or code for enforcing or abrogating said restriction(s) based on the character of, and in response to receipt of, a PIN(s), password(s) or other authenticating token(s).
140. An advanced asset management system according to claim 137 in which the system comprises data and/or code for enforcing or abrogating said restriction(s) based on the character of, and in response to receipt of, a PIN(s), password(s) or other authenticating token(s).
141. An advanced asset management system according to claim 125 in which there is a plurality of said repositories representing a distributed group(s) having controlling software and/or hardware programmed with information identifying, and comprising a communications route(s) to, the other repositories in said group(s).
142. An advanced asset management system according to claim 125 in which there is a plurality of said repositories representing a federated group(s) having controlling software and/or hardware programmed with information identifying each of the other repositories in the group(s), and with data and/or code that represents a condition of trust with respect to transactions within and between each of the other repositories in said group(s).
143. An advanced asset management system according to claim 125 in which there is a plurality of said repositories representing a distributed-federated group(s) having controlling software and/or hardware is programmed with information comprising:
A. information identifying each of the other repositories in the group(s), and B. communications route(s) to the other repositories in the group(s), and C. code that represents a condition of trust with respect to transactions within and between each of the other repositories in said group(s).
144. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) wherein a given repository/repositories in the group(s) is/are not required to be known in advance by another repository/repositories in the group(s), but can be discovered.
145. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) in which a communications connection(s) between repositories in the group(s) is/are not required to be known in advance, but can be discovered.
146. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) in which a route(s) between repositories in the group(s) is/are not required to be known in advance, but can be determined.
147. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) in which a route(s) between repositories in said inter-networked group(s) can change, with no requirement that all communications connections between repositories in the group(s) traverse the same route(s) across the inter-network.
148. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) having an intermittent communication connection(s) between repositories in the group(s).
149. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) having a permanent communication connection(s) between repositories in the group(s).
150. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s) in which a communications connection(s) between repositories in the group(s) can be dynamically established, dissolved, moved, managed, redirected and/or otherwise manipulated.
151. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s),and in which all of the following conditions exist:
A. said other repositories are not required to be known in advance, but can be discovered;
B. communications connections between the repositories are not required to be known in advance, but can be discovered;
C. routes between repositories in said inter-networked group(s) are not required to be known in advance, but can be determined;
D. routes between repositories in said inter-networked group(s) can change, with no requirement that a subsequent communications connection(s) 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;
E. connections between repositories are intermittent; and F. communications connections between said repository and said other repositories can be dynamically established, dissolved, moved, managed, and redirected.
152. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist, in an inter-networked group(s), and in which all of the following conditions exist:
A. said other repositories are not required to be known in advance, but can be discovered;
B. communications connections between the repositories are not required to be known in advance, but can be discovered;
C. routes between repositories in said inter-networked group(s) are not required to be known in advance, but can be determined;
D. routes between repositories in said inter-networked group(s) can change, with no requirement that a subsequent communications connection(s) 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;
E. connections between repositories are permanent; and F. communications connections between said repository and said other repositories can be dynamically established, dissolved, moved, managed, and redirected.
153. An advanced asset management system according to claim 125 in which there is a plurality of said repositories that exist in an inter-networked group(s), and in which at least one of the following conditions exists:

A. said other repositories are not required to be known in advance, but can be discovered;
B. communications connections between the repositories are not required to be known in advance, but can be discovered;
C. routes between repositories in said inter-networked group(s) are not required to be known in advance, but can be determined;
D. routes between repositories in said inter-networked group(s) can change, with no requirement that a subsequent communications connection(s) 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;
E. some connection(s) between repositories is/are intermittent;
F. other connection(s) between repositories is/are permanent; and/or G. communications connections between said repository and said other repositories can be dynamically established, dissolved, moved, managed, and redirected.
154. An advanced asset management system according to claim 125 in which 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, is also programmed to communicate with, and to conduct transactions with, at least one other repository not comprised in said given group.
155. An advanced asset management system according to claim 154 in which said first repository is not comprised in any group of repositories.
156. An advanced asset management system according to claim 154 in which said at least one other repository is not comprised in any group of repositories.
157. An advanced asset management system according to claim 154 in which said first repository is a member of a distributed group of repositories.
158. An advanced asset management system according to claim 154 in which said at least one other repository is a member of a distributed group.
159. An advanced asset management system according to claim 154 in which said first repository is a member of a federated group.
160. An advanced asset management system according to claim 154 in which said at least one other repository is a member of a federated group.
161. An advanced asset management system according to claim 154 in which said first repository is a member of a distributed-federated group.
162. An advanced asset management system according to claim 154 in which said at least one other repository is a member of a distributed-federated group.
163. An advanced asset management system according to claim 154 in which said first repository is a member of an inter-networked group.
164. An advanced asset management system according to claim 154 in which said at least one other repository is a member of an inter-networked group.
165. An advanced asset management system according to claim 125 comprising means for encrypting said repository/repositories.
166. An advanced asset management system according to claim 125 comprising means for encrypting all information regarding said repository/repositories and its/their comprised accounts) stored by said advanced asset management system.
167. An advanced asset management system according to claim 125 comprising means for encrypting at least a portion of any information regarding said repository/repositories and its/their comprised account(s) stored by said advanced asset management system.
168. An advanced asset management system according to claim 125 comprising means for encrypting all information regarding said repository/repositories and its/their comprised accounts) processed by said advanced asset management system.
169. An advanced asset management system according to claim 125 comprising means for encrypting at least a portion of any information regarding said repository/repositories and its/their comprised account(s) processed by said advanced asset management system.
170. An advanced asset management system according to claim 125 comprising means for encrypting all information regarding said repository/repositories and its/their comprised account(s) communicated to or from said advanced asset management system.
171. An advanced asset management system according to claim 125 comprising means for encrypting at least a portion of any information regarding said repository/repositories and its/their comprised account(s) communicated to or from said advanced asset management system.
12.1.2 Second Aspect
172. A virtual clearinghouse system which 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-account(s) thereof, said clearinghouse system comprising:
A. a computer system having:
1) at least one data processor 2) at least one data storage device, and 3) 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;
B. clearinghouse software stored in said computer system on said at least one data storage device for storing and managing a plurality of account repository connection requests to be implemented at least in part via said at least one communications device, C. said account repository connection requests respectively comprising data representing:

1) at least one account transaction, comprising such information as is required to characterize the transaction, and 2) at least one address for a given repository/repositories in which the participating account(s) is/are situated and at least one public token of a participating account(s);
D. said system comprising data and/or code that:
1) represents the existence of a direct or indirect trusting relationship between 2) the clearinghouse system and said repository/repositories, and 3) the clearinghouse and the second participant;
4) is 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 conduct transactions with each other without requiring a direct trusting relationship between the participants.
173. A virtual clearinghouse system according to claim 172 in which said system comprises a plurality of computer systems.
174. A virtual clearinghouse system according to claim 172 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 virtual clearinghouses, components thereof, and/or communication requests thereof.
175. A virtual clearinghouse system according to claim 172 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate, one or more virtual clearinghouses, components thereof, and/or communication requests thereof, only if said commands) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization owning or having a right to control, respectively, said virtual clearinghouses, said components thereof, and/or said communication requests thereof.
176. A virtual clearinghouse system according to claim 172 comprising data and/or code for permitting access to one or more virtual clearinghouses, components thereof, and/or communication requests thereof.
177. A virtual clearinghouse system according to claim 172 in which said at least one communications device is configured to permit access to one or more virtual clearinghouses, components thereof, and/or communication requests thereof, based on receipt via said at least one communications device of a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization to access, respectively, said one or more virtual clearinghouses, said components thereof, and/or said communication requests thereof.
178. A virtual clearinghouse system according to claim 172 in which said system comprises data and/or code that cause(s) said clearinghouse system to act as a third party intermediary for facilitating one or more escrow transactions.
179. A virtual clearinghouse system according to claim 172 in which said system comprises data and/or code that causes) said clearinghouse system to act as a third party intermediary for facilitating one or more bid transactions.
180. A virtual clearinghouse system according to claim 172 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 bid pools.
181. A virtual clearinghouse system according to claim 180 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a bid pool(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said bid pool(s).
182. A virtual clearinghouse system according to claim 172 in which said system comprises data and/or code that cause(s) said clearinghouse system to act as a third party intermediary for facilitating one or more gaming/gambling transaction(s).
183. A virtual clearinghouse system according to claim 172 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 gaming/gambling pool(s).
184. A virtual clearinghouse system according to claim 183 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a gaming/gambling pool(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said gaming/gambling pools(s).
185. A virtual clearinghouse system according to claim 172 in which said system comprises data and/or code that cause(s) said clearinghouse system to act as an agent for one or more repositories.
186. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for calculating, collecting, disbursing, reporting, and/or otherwise manipulating taxes and/or fees.
187. A virtual clearinghouse system according to claim 186 in which said at least one data processor is configured to accept one or more commands to calculate, collect, disburse, report and/or otherwise manipulate taxes and/or fees only if said command(s) is/axe received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said taxes and/or fees.
188. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for calculating, collecting, disbursing, reporting, and/or otherwise manipulating information pertaining to at least in part taxes and/or fees.
189. A virtual clearinghouse system according to claim 188 in which said at least one data processor is configured to accept one or more commands to calculate, collect, disburse, report and/or otherwise manipulate information pertaining to at least in part said taxes and/or fees only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said information pertaining to at least in part said taxes and/or fees.
190. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating one or more credentials and/or licenses.
191. A virtual clearinghouse system according to claim 190 in which said at least one data processor is configured to accept one or more commands to grant, revoke, report, validate, transmit and/or otherwise manipulate said credentials and/or licenses only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said credentials and/or licenses.
192. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating information pertaining to at least in part credentials and/or licenses.
193. A virtual clearinghouse system according to claim 192 in which said at least one data processor is configured to accept one or more commands to grant, revoke, report, validate, transmit and/or otherwise manipulate information pertaining to at least in part said credentials and/or licenses only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said information pertaining to at least in part said credentials and/or licenses.
194. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for granting, revoking, authenticating, validating, transmitting and/or otherwise manipulating one or more digital security certificates.
195. A virtual clearinghouse system according to claim 194 in which said at least one data processor is configured to accept one or more commands to grant, revoke, report, validate, transmit and/or otherwise manipulate said digital security certificate(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said digital security certificate(s).
196. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for granting, revoking, authenticating, validating, transmitting and/or otherwise manipulating information pertaining to at least in part digital security certificates.
197. A virtual clearinghouse system according to claim 196 in which said at least one data processor is configured to accept one or more commands to grant, revoke, report, validate, transmit and/or otherwise manipulate information pertaining to at least in part said digital security certificates) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said information pertaining to at least in part said digital security certificate(s).
198. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for granting, revoking, authenticating, validating, transmitting and/or otherwise manipulating one or more digital signatures.
199. A virtual clearinghouse system according to claim 198 in which said at least one data processor is configured to accept one or more commands to grant, revoke, report, validate, transmit and/or otherwise manipulate said digital signature(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said digital security signature(s).
200. A virtual clearinghouse system according to claim 172 in which the system comprises data and/or code for granting, revoking, authenticating, validating, transmitting and/or otherwise manipulating information pertaining to at least in part digital signatures.
201. A virtual clearinghouse system according to claim 200 in which said at least one data processor is configured to accept one or more commands to grant, revoke, report, validate, transmit and/or otherwise manipulate information pertaining to at least in part said digital signature(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said information pertaining to at least in part said digital signature(s).
202. A virtual clearinghouse system according to claim 172 in which the second participant is at least one other account in the same repository/repositories in which the first participant is situated.
203. A virtual clearinghouse system according to claim 172 in which the second participant is at least one other account in a repository other than the repository/repositories in which the first participant is situated.
204. A virtual clearinghouse system according to claim 172 in which the second participant is not a virtual account or sub-account thereof.
205. A virtual clearinghouse system according to claim 172 comprising means for encrypting the clearinghouse(s).
206. A virtual clearinghouse system according to claim 172 comprising means for encrypting all information about the account(s) and participant(s) stored by the system.
207. A virtual clearinghouse system according to claim 206 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
208. A virtual clearinghouse system according to claim 206 in which the information so encrypted pertains at least in part to the content of an account(s).
209. A virtual clearinghouse system according to claim 206 in which the information so encrypted pertains at least in part to a logical connections) of an account(s).
210. A virtual clearinghouse system according to claim 206 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
211. A virtual clearinghouse system according to claim 206 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
212. A virtual clearinghouse system according to claim 172 in which at least a portion of any information about the account(s) and participant(s) stored by the system is encrypted.
213. A virtual clearinghouse system according to claim 212 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
214. A virtual clearinghouse system according to claim 212 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
215. A virtual clearinghouse system according to claim 212 in which the information so encrypted pertains at least in part to a logical connections) of an account(s).
216. A virtual clearinghouse system according to claim 212 in which the information so encrypted pertains at least in part to a transactions) involving an account(s).
217. A virtual clearinghouse system according to claim 212 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
218. A virtual clearinghouse system according to claim 172 in which the system includes means for encrypting all information about the account(s) and participant(s) processed by the system.
219. A virtual clearinghouse system according to claim 218 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
220. A virtual clearinghouse system according to claim 218 in which the information so encrypted pertains at least in part to the content of an account(s).
221. A virtual clearinghouse system according to claim 218 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
222. A virtual clearinghouse system according to claim 218 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
223. A virtual clearinghouse system according to claim 218 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
224. A virtual clearinghouse system according to claim 172 in which the system includes means for encrypting at least a portion of any information about the account(s) and participant(s) processed by the system.
225. A virtual clearinghouse system according to claim 224 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
226. A virtual clearinghouse system according to claim 224 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
227. A virtual clearinghouse system according to claim 224 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
228. A virtual clearinghouse system according to claim 224 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
229. A virtual clearinghouse system according to claim 224 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
230. A virtual clearinghouse system according to claim 172 in which the system includes means for encrypting all information about the account(s) and participant(s) communicated to or from the system.
231. A virtual clearinghouse system according to claim 230 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
232. A virtual clearinghouse system according to claim 230 in which the information so encrypted pertains at least in part to the content of an account(s).
233. A virtual clearinghouse system according to claim 230 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
234. A virtual clearinghouse system according to claim 230 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
235. A virtual clearinghouse system according to claim 230 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.
236. A virtual clearinghouse system according to claim 172 in which the system includes means for encrypting at least a portion of any information about the account(s) and participant(s) communicated to or from the system.
237. A virtual clearinghouse system according to claim 236 in which the information so encrypted pertains at least in part to the ownership or control of an account(s).
238. A virtual clearinghouse system according to claim 236 in which the information so encrypted pertains at least in part to at least a portion of the content of an account(s).
239. A virtual clearinghouse system according to claim 236 in which the information so encrypted pertains at least in part to a logical connection(s) of an account(s).
240. A virtual clearinghouse system according to claim 236 in which the information so encrypted pertains at least in part to a transaction(s) involving an account(s).
241. A virtual clearinghouse system according to claim 236 in which the information so encrypted pertains at least in part to a transaction history/histories in which an account(s) has/have been involved.

12.1.3 Third Aspect
242. A virtual naming system, comprising:

A. a computer system having:
1) at least one data processor 2) at least one data storage device, and 3) at least one communications device through which the computer system can communicate with one or more entities that can connect with said computer system;

B. naming system software stored in said computer system on said at least one data storage device for creating, storing, maintaining and/or otherwise manipulating data comprising at least one name and at least one address for each of a plurality of repositories, said data being at least in part accessible via said at least one communications device, said naming system comprising data and/or code that creates, stores, maintains and/or otherwise manipulates one or more lists containing:

1) known repositories 2) repository addresses whereby one or more entities other than naming system administrators, including persons, organizations and/or other computer systems, owning or having control of an account(s) in one or more repositories or at least a portion of the content of an account(s) in one or more repositories, and, optionally, one or more third party entities, can locate and discover a communication route(s) to such a repository/repositories without knowing the name or without knowing the address thereof.
243. A virtual naming system according to claim 242 in which said system comprises a plurality of computer systems.
244. A virtual naming system according to claim 242 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 virtual naming systems and/or list(s) thereof.
245. A virtual naming system according to claim 242 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate one or more virtual naming systems and/or lists) thereof only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control, respectively, said one or more virtual naming systems and/or said list(s) thereof.
246. A virtual naming system according to claim 242 comprising data and/or code for permitting access to one or more virtual naming systems and/or lists) thereof.
247. A virtual naming system according to claim 242 in which said at least one communications device is configured to permit access to one or more virtual naming systems and/or the list(s) thereof, based on receipt via said at least one communications device of a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization to access, respectively, said one or more virtual naming systems and/or said list(s) thereof.
248. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more aliases for one or more repositories.
249. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more repository ownership certificates.
250. A virtual naming system according to claim 242 wherein said one or more lists additionally comprise known clearinghouses and clearinghouse addresses.
251. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more aliases for one or more clearinghouses.
252. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more clearinghouse ownership certificates.
253. A virtual naming system according to claim 242 wherein said one or more lists additionally comprise known labeling systems and labeling system addresses.
254. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more aliases for one or more labeling systems.
255. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more labeling system ownership certificates.
256. A virtual naming system according to claim 242 wherein said one or more lists additionally comprise other known naming systems and other naming system addresses.
257. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, andlor otherwise manipulating a list(s) of one or more aliases for one or more other naming systems.
258. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more other naming system ownership certificates.
259. A virtual naming system according to claim 242 wherein said one or more lists additionally comprise known devices and device addresses.
260. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more aliases for one or more devices.
261. A virtual naming system according to claim 242 wherein said system comprises data and/or code for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more device ownership certificates.
262. A virtual naming system according to claim 242 comprising means for encrypting said naming system(s).
263. A virtual naming system according to claim 242 comprising means for encrypting all information regarding said naming system(s) and its/their comprised list(s), stored by said naming system(s).
264. A virtual naming system according to claim 242 comprising means for encrypting at least a portion of any information regarding said naming system(s) and its/their comprised list(s), stored by said naming system(s).
265. A virtual naming system according to claim 242 comprising means for encrypting all information regarding said naming system(s) and its/their comprised list(s), processed by said naming system(s).
266. A virtual naming system according to claim 242 comprising means for encrypting at least a portion of any information regarding said naming system(s) and its/their comprised list(s), processed by said naming system(s).
267. A virtual naming system according to claim 242 comprising means for encrypting all information regarding said naming system(s) and its/their comprised list(s), communicated to or from said naming system(s).
268. A virtual naming system according to claim 242 comprising means for encrypting at least a portion of any information regarding said naming systems) and its/their comprised list(s), communicated to or from said naming system(s).

12.1.4 First Aspect, continued
269. An advanced asset management system according to claim 1 in which the 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 at least a portion of the content of an account(s).
270. An advanced asset management system according to claim 269 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate the at least a portion of the content of an account(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said account(s).
271. A.n advanced asset management system according to claim 269 comprising means for encrypting a first and second part of the at least a portion of the content of an account(s) independently from one another.
272. An advanced asset management system according to claim 269 comprising means for 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.
273. An advanced asset management system according to claim 269 wherein the content is/are an asset(s).
274. An advanced asset management system according to claim 269 wherein the content is/are a digital asset(s).
275. An advanced asset management system according to claim 269 wherein the content is/are qualitative information about a digital asset(s).
276. An advanced asset management system according to claim 269 wherein the content is/are information other than qualitative information about a digital asset(s).
277. An advanced asset management system according to claim 269 wherein the content is/are a representation of a digital asset(s).
278. An advanced asset management system according to claim 269 wherein the content is/are qualitative information about a representation of a digital asset(s).
279. An advanced asset management system according to claim 269 wherein the content is/are information other than qualitative information about a representation of a digital asset(s).
280. An advanced asset management system according to claim 269 wherein the content is/are a representation of a non-digital asset(s).
281. An advanced asset management system according to claim 269 wherein the content is/are qualitative information about a representation of a non-digital asset(s).
282. An advanced asset management system according to claim 269 wherein the content is/are information other than qualitative information about a representation of a non-digital asset(s).
283. An advanced asset management system according to claim 273 wherein the asset(s) of an account(s) is/are stored in said data storage device(s), and the system is adapted to effect transfer of ownership or control of at least a portion of the asset(s) reflected in the account(s) 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 asset(s) itself/themselves.
284. An advanced asset management system according to claim 273 wherein the system comprises data and/or code that comprise(s) conversion routines which interact with a record(s) of a given type(s) of asset(s) stored in one or more accounts by said system and with information about any qualitative and/or quantitative relationship(s) between an asset(s) of said given type(s) and of other type(s) of asset(s) and that is able, on command, after receipt of a token(s) for said account(s), to convert the record(s) of said given type(s) of asset(s), at least in part, to at least one record of at least one of said other type(s) of asset(s).
285. An advanced asset management system according to claim 273 wherein the system comprises data and/or code that, on command, after receipt of a token(s) for said account(s), cause(s) at least a portion of the asset(s) held within an account(s) to be reserved for future use, diminishing the current available balance by the amount placed on reserve, without debiting the account(s).
286. An advanced asset management system according to claim 273 wherein the account(s) reflect information concerning the value of a given asset(s), expressed as a particular quantity of said asset(s) 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 of different units being of equivalent value to said particular quantity of said particular units.
287. An advanced asset management system according to claim 273 in which the system comprises one or more provisions for storing and manipulating data with respect to a plurality of different types of assets.
288. An advanced asset management system according to claim 287 wherein the different types of assets differ from one another in their primary function or quality.
289. An advanced asset management system according to claim 287 wherein an account(s) store(s) assets of a first type, and of at least one other type, different from said first type.
290. An advanced asset management system according to claim 289 in which said first asset type is a given form of currency.
291. An advanced asset management system according to claim 289 in which said first asset type is the currency of a given national and/or multi-national jurisdiction.
292. An advanced asset management system according to claim 289 in which said first asset type is a tangible or intangible non-monetary thing of measurable quantity and of measurable value.
293. An advanced asset management system according to claim 289 in which said first asset type is a tangible or intangible non-monetary thing of measurable quantity but of no intrinsic value.
294. An advanced asset management system according to claim 289 in which said first asset type is a tangible or intangible non-monetary thing of no measurable quantity but of measurable value.
295. An advanced asset management system according to claim 289 in which said first asset type is a tangible or intangible non-monetary thing of no measurable quantity and of no intrinsic value.
296. An advanced asset management system according to claim 289 in which said first type and said at least one other type of assets differ in that they are different currencies.
297. An advanced asset management system according to claim 289 in which said first type and said at least one other type of assets differ in that they are different currencies of different national and/or multi-national jurisdictions.
298. An advanced asset management system according to claim 289 in which said first type and said at least one other type of assets differ in that they are different tangible or intangible non-monetary things of measurable quantity and of measurable value.
299. An advanced asset management system according to claim 289 in which said first type and said at least one other type of assets differ in that they are different tangible or intangible non-monetary things of measurable quantity but of no intrinsic value.
300. An advanced asset management system according to claim 289 in which said first type and said at least one other type of assets differ in that they are different tangible or intangible non-monetary things of no measurable quantity but of measurable value.
301. An advanced asset management system according to claim 289 in which said first type and said at least one other type of assets differ in that they are different tangible or intangible non-monetary things of no measurable quantity and of no intrinsic value.
302. An advanced asset management system according to claim 1 wherein the system comprises one or more means for incrementing, decrementing, expiring, validating, and/or otherwise manipulating a tangible or intangible non-monetary asset(s) of measurable quantity.
303. An advanced asset management system according to claim 1 wherein the system comprises one or more means for entering into an account(s) a tangible or intangible non-monetary asset(s) of no measurable quantity.
304. An advanced asset management system according to claim 1 wherein the system comprises one or more means for removing from an account(s) a tangible or intangible non-monetary asset(s) of no measurable quantity.
305. An advanced asset management system according to claim 1 wherein the system comprises one or more means for recording in account(s) an asset(s) in a particular forms) of currency.
306. An advanced asset management system according to claim 1 wherein the system comprises one or more means for prohibiting an accounts) from containing an asset(s) in a particular form of currency.
307. An advanced asset management system according to claim 1 wherein the system comprises one or more means for recording in an account(s) an asset(s) in the currency of a particular national and/or multi-national jurisdiction.
308. An advanced asset management system according to claim 1 wherein the system comprises one or more means for prohibiting an account(s) from containing an asset(s) in the currency of a particular national and/or multi-national jurisdiction.
309. An advanced asset management system according to claim 1 wherein the system comprises one or more means for recording in an account(s) a particular tangible or intangible non-monetary asset(s) of measurable value.
310. An advanced asset management system according to claim 1 wherein the system comprises one or more means for prohibiting an account(s) from containing a particular tangible or intangible non-monetary asset(s) of measurable value.
311. An advanced asset management system according to claim 1 wherein the system comprises one or more means for recording in an account(s) a particular tangible or intangible non-monetary asset(s) of measurable quantity, but no measurable value.
312. An advanced asset management system according to claim 1 wherein the system comprises one or more means for prohibiting an account(s) from containing a particular tangible or intangible non-monetary asset(s) of measurable quantity, but no measurable value.
313. An advanced asset management system according to claim 1 wherein the system comprises one or more means for recording in an account(s) a particular tangible or intangible non-monetary asset(s) of no measurable quantity.
314. An advanced asset management system according to claim 1 wherein the system comprises one or more means for prohibiting an account(s) from containing a particular tangible or intangible non-monetary asset(s) of no measurable quantity.
315. An advanced asset management system according to claim 1 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 attributes.
316. An advanced asset management system according to claim 1 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate one or more attributes only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more attributes.
317. An advanced asset management system according to claim 1 comprising data and/or code for permitting access one or more attributes.
318. An advanced asset management system according to claim 1 in which said at least one communications device is configured to permit access to one or more attributes based on receipt via said at least one communications device of a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization to access said one or more attributes.
319. An advanced asset management system according to claim 315 in which said one or more attributes are user-defined attributes, in that the system affords sole control over the constitution of said one or more 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).
320. An advanced asset management system according to claim 315 in which said attributes are user-selectable, in that the system generates a list(s) of attributes of, on, and/or within 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 account(s) may select and apply one or more of said user-selectable attributes.
321. An advanced asset management system according to claim 315 in which said attributes are user-determinable, in that the value(s) 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 owning or having a right to control said account(s).
322. An advanced asset management system according to claim 315 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 said one or more attributes of, for, and/or within at least one repository or group of repositories.
323. An advanced asset management system according to claim 315 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 said one or more attributes of, for, and/or within at least one account or group of accounts.
324. An advanced asset management system according to claim 315 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 said one or more attributes of, for, and/or within at least a portion of the content contained within at least one repository or group of repositories.
325. An advanced asset management system according to claim 315 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 said one or more attributes of, for, and/or within at least a portion of the content contained within at least one account or group of accounts.
326. An advanced asset management system according to claim 1 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 constraints.
327. An advanced asset management system according to claim 1 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate one or more constraints only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more constraints.
328. An advanced asset management system according to claim 1 comprising data and/or code for permitting access one or more constraints.
329. An advanced asset management system according to claim 1 in which said at least one communications device is configured to permit access to one or more constraints based on receipt via said at least one communications device of a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization to access said one or more constraints.
330. An advanced asset management system according to claim 326 in which said 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, to an entity/entities owning or having a right to control said account(s).
331. An advanced asset management system according to claim 326 in which said constraints are user-selectable, in that the system generates a list(s) 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 account(s) may select and apply one or more of said user-selectable constraints.
332. An advanced asset management system according to claim 326 in which said constraints are user-determinable, in that the value(s) for a constraint(s) on 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 owning or having a right to control said account(s).
333. An advanced asset management system according to claim 326 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 said one or more constraints on at least one repository or group of repositories.
334. An advanced asset management system according to claim 326 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 said one or more constraints on at least one account or group of accounts.
335. An advanced asset management system according to claim 326 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 said one or more constraints on at least a portion of the content contained within at least one repository or group of repositories.
336. An advanced asset management system according to claim 326 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 said one or more constraints on at least a portion of the content contained within at least one account or group of accounts.
337. An advanced asset management system according to claim 326 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 said one or more constraints on at least one attribute or group of attributes.
338. An advanced asset management system. according to claim 333 wherein said constraint(s) restrict(s) the ability of at least a portion of any A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attribute(s) of a repository/repositories, and/or F. attribute(s) of the content held within or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attributes) of content held within or controlled by an account(s).
to be transferred, transmitted, received, aggregated, distributed, exchanged, altered and/or otherwise manipulated.
339. An advanced asset management system according to claim 334 wherein said constraint(s) restrict(s) the ability of at least a portion of any A. of said account(s), and/or B. attribute(s) of said account(s), and/or C. content held within or controlled by said account(s), and/or D. attribute(s) of the content held within or controlled by said account(s), to be transferred, transmitted, received, aggregated, distributed, exchanged, altered and/or otherwise manipulated.
340. An advanced asset management system according to claim 335 wherein said constraint(s) restrict(s) the ability of at least a portion of any A. of said content, and/or B. attribute(s) of said content, to be transferred, transmitted, received, aggregated, distributed, exchanged, altered and/or otherwise manipulated.
341. An advanced asset management system according to claim 336 wherein said constraint(s) restrict(s) the ability of at least a portion of any A. of said content, and/or B. attribute(s) of said content, to be transferred, transmitted, received, aggregated, distributed, exchanged, altered and/or otherwise manipulated.
342. An advanced asset management system according to claim 337 wherein said constraint(s) restrict(s) the ability of said attribute(s) to be altered and/or otherwise manipulated.
343. An advanced asset management system according to claim 337 wherein said constraint(s) restrict(s) the allowed values of said attribute(s).
344. An advanced asset management system according to claim 1 in which the system additionally comprises at least one repository, comprises data and/or code for combining, by using the Boolean logic operator AND, two or more constraints on all or at least a portion of any A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attribute(s) of a repository/repositories, and/or F. attribute(s) of the content held within or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attribute(s) of content held within or controlled by an account(s).
345. An advanced asset management system according to claim 1 in which the system additionally comprises at least one repository, comprises data and/or code for combining, by using the Boolean logic operator OR, two or more constraints on all or at least a portion of any A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attribute(s) of a repository/repositories, and/or F. attribute(s) of the content held within. or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attribute(s) of content held within or controlled by an account(s).
346. An advanced asset management system according to claim 1 in which the system additionally comprises at least one repository, comprises data and/or code for combining, by using the Boolean logic operator XOR (exclusive OR), two or more constraints on all or at least a portion of any A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attribute(s) of a repository/repositories, and/or F. attribute(s) of the content held within or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attribute(s) of the content held within or controlled by an account(s).
347. An advanced asset management system according to claim 1 in which the system additionally comprises at least one repository, comprises data and/or code for combining, by using the Boolean logic operator NOT (inverse or complement), two or more constraints on all or at least a portion of any A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attribute(s) of a repository/repositories, and/or F. attribute(s) of the content held within or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attribute(s) of content held within or controlled by an account(s).
348. An advanced asset management system according to claim 1 in which the system additionally comprises at least one repository, comprises data and/or code for combining, by using one or more of the same or different Boolean operators AND, OR, XOR, and/or NOT, two or more constraints on all or at least a portion of any A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attributes) of a repository/repositories, and/or F. attribute(s) of the content held within or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attribute(s) of content held within or controlled by an account(s).
349. An advanced asset management system according to claim 1 in which the system additionally comprises at least one repository, comprises data and/or code for combining, 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 A. repository/repositories, and/or B. content held within or controlled by a repository/repositories, and/or C. account(s) contained within or managed by a repository/repositories, and/or D. content held within or controlled by an account(s), and/or E. attribute(s) of a repository/repositories, and/or F. attribute(s) of the content held within or controlled by a repository/repositories, and/or G. attribute(s) of an account(s), and/or H. attribute(s) of content held within or controlled by said account(s), said procedures including use of parenthesis, braces, and/or brackets, and/or groups or levels of parenthesis, braces, and/or brackets.
350. An advanced asset management system according to claim 333 wherein said constraint(s) exists/exist as an integral parts) of said repository/repositories.
351. An advanced asset management system according to claim 334 wherein said constraint(s) exists/exist as an integral parts) of said account(s).
352. An advanced asset management system according to claim 334 wherein said constraints) exists/exist as an integral part(s) of a repository/repositories containing said account(s).
353. An advanced asset management system according to claim 335 wherein said constraint(s) exists/exist as an integral part(s) of said content.
354. An advanced asset management system according to claim 335 wherein said constraint(s) exists/exist as an integral part(s) of an account(s) containing or controlling said content.
355. An advanced asset management system according to claim 336 wherein said constraint(s) exists/exist as an integral part(s) of said content.
356. An advanced asset management system according to claim 336 wherein said constraint(s) exists/exist as an integral part(s) of a repository/repositories containing or controlling said content.
357. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of said attribute(s).
358. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of a repository/repositories containing said attribute(s).
359. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s).
360. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of a repository/repositories containing or controlling content, and wherein said content contains said attribute(s).
361. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of an account(s) containing said attribute(s).
362. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of an account(s) containing or controlling content, and wherein said content contains said attribute(s).
363. An advanced asset management system according to claim 333 wherein said constraint(s) exists/exist external to said repository/repositories.
364. An advanced asset management system according to claim 334 wherein said constraint(s) exists/exist external to said account(s).
365. An advanced asset management system according to claim 334 wherein said constraints) exists/exist external to a repository/repositories containing said account(s).
366. An advanced asset management system according to claim 335 wherein said constraint(s) exists/exist external to said content.
367. An advanced asset management system according to claim 335 wherein said constraint(s) exists/exist external to an account(s) containing or controlling said content.
368. An advanced asset management system according to claim 336 wherein said constraint(s) exists/exist external to said content.
369. An advanced asset management system according to claim 336 wherein said constraint(s) exists/exist external to a repository/repositories containing or controlling said content.
370. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist external to said attribute(s).
371. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist external to a repository/repositories containing said attribute(s).
372. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist external to a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s).
373. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist external to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s).
374. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist external to an account(s) containing said attribute(s).
375. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist external to an account(s) containing or controlling content, and wherein said content contains said attribute(s).
376. An advanced asset management system according to claim 333 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, said repository/repositories.
377. An advanced asset management system according to claim 334 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, said account(s).
378. An advanced asset management system according to claim 334 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, a repository/repositories containing said account(s).
379. An advanced asset management system according to claim 335 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, said content.
380. An advanced asset management system according to claim 335 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, an account(s) containing or controlling said content.
381. An advanced asset management system according to claim 336 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, said content.
382. An advanced asset management system according to claim 336 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, a repository/repositories containing or controlling said content.
383. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, said attribute(s).
384. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, a repository/repositories containing said attribute(s).
385. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s).
386. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, a repository/repositories containing or controlling content, and wherein said content contains said attribute(s).
387. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral part(s) of, and also external to, an account(s) containing said attribute(s).
388. An advanced asset management system according to claim 337 wherein said constraint(s) exists/exist as an integral parts) of, and also external to, an account(s) containing or controlling content, and wherein said content contains said attribute(s).
389. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for processing said constraint(s) internal to said repository/repositories.
390. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for processing said constraint(s) internal to said account(s).
391. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for processing said constraint(s) internal to a repository/repositories containing said account(s).
392. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for processing said constraint(s) internal to said content.
393. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for processing said constraint(s) internal to an account(s) containing or controlling said content.
394. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for processing said constraint(s) internal to said content.
395. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for processing said constraint(s) internal to a repository/repositories containing or controlling said content.
396. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing said constraint(s) internal to said attribute(s).
397. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing said constraint(s) internal to a repository/repositories containing said attribute(s).
398. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing said constraint(s) internal to a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s).
399. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing said constraint(s) internal to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s).
400. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing said constraint(s) internal to an account(s) containing said attribute(s).
401. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing said constraint(s) internal to an account(s) containing or controlling content, and wherein said content contains said attribute(s).
402. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for cooperating with means external to said repository/repositories for processing said constraint(s).
403. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for cooperating with means external to said account(s) for processing said constraint(s).
404. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing said account(s) for processing said constraint(s).
405. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for cooperating with means external to said content for processing said constraint(s).
406. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for cooperating with means external to an account(s) containing or controlling said content for processing said constraint(s).
407. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for cooperating with means external to said content for processing said constraint(s).
408. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing or controlling said content for processing said constraint(s).
409. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to said attribute(s) for processing said constraint(s).
410. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing said attribute(s) for processing said constraint(s).
411. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s), for processing said constraint(s).
412. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s), for processing said constraint(s).
413. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to an account(s) containing said attribute(s) for processing said constraint(s).
414. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to an accounts) containing or controlling content, and wherein said content contains said attribute(s), for processing said constraint(s).
415. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to said repository/repositories for external processing of, said constraints.
416. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to said account(s) for external processing of, said constraints.
417. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to a repository/repositories containing said account(s) for external processing of, said constraints.
418. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to said content for external processing of, said constraints.
419. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to an account(s) containing or controlling said content for external processing of, said constraints.
420. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to said content for external processing of, said constraints.
421. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to a repository/repositories containing or controlling said content for external processing of, said constraints.
422. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to said attribute(s) for external processing of, said constraints.
423. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to a repository/repositories containing said attributes) for external processing of, said constraints.
424. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s), for external processing of, said constraints.
425. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s), for external processing of, said constraints.
426. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to an account(s) containing said attribute(s) for external processing of, said constraints.
427. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to an account(s) containing or controlling content, and wherein said content contains said attribute(s), for external processing of, said constraints.
428. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to said repository/repositories.
429. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to said account(s).
430. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to a repository/repositories containing said account(s).
431. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to said content.
432. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to an account(s) containing or controlling said content.
433. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to said content.
434. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to a repository/repositories containing or controlling said content.
435. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to said attribute(s).
436. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to a repository/repositories containing said attribute(s).
437. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s).
438. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s).
439. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to an account(s) containing said attribute(s).
440. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for evaluating said constraint(s) internal to an account(s) containing or controlling content, and wherein said content contains said attribute(s).
441. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for cooperating with means external to said repository/repositories for evaluating said constraint(s).
442. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for cooperating with means external to said account(s) for evaluating said constraint(s).
443. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing said account(s) for evaluating said constraint(s).
444. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for cooperating with means external to said content for evaluating said constraint(s).
445. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for cooperating with means external to an account(s) containing or controlling said content for evaluating said constraint(s).
446. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for cooperating with means external to said content for evaluating said constraint(s).
447. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing or controlling said content for evaluating said constraint(s).
448. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to said attribute(s) for evaluating said constraint(s).
449. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing said attribute(s) for evaluating said constraint(s).
450. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing an account(s), and wherein said accounts) contain(s) said attribute(s), for evaluating said constraint(s).
451. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s), for evaluating said constraint(s).
452. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to an account(s) containing said attribute(s) for evaluating said constraint(s).
453. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperating with means external to an account(s) containing or controlling content, and wherein said content contains said attribute(s), for evaluating said constraint(s).
454. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to said repository/repositories for external evaluating of, said constraints.
455. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to said account(s) for external evaluating of, said constraints.
456. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to a repository/repositories containing said account(s) for external evaluating of, said constraints.
457. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to said content for external evaluating of, said constraints.
458. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to an account(s) containing or controlling said content for external evaluating of, said constraints.
459. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to said content for external evaluating of, said constraints.
460. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to a repository/repositories containing or controlling said content for external evaluating of, said constraints.
461. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to said attribute(s) for external evaluating of, said constraints.
462. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to a repository/repositories containing said attribute(s) for external evaluating of, said constraints.
463. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to a repository/repositories containing an account(s), and wherein said account(s) contain(s) said attribute(s), for external evaluating of, said constraints.
464. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to a repository/repositories containing or controlling content, and wherein said content contains said attribute(s), for external evaluating of, said constraints.
465. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to an account(s) containing said attribute(s) for external evaluating of, said constraints.
466. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal evaluating of, and for cooperation with means external to an account(s) containing or controlling content, and wherein said content contains said attribute(s), for external evaluating of, said constraints.
467. An advanced asset management system according to claim 1 further comprising an inter-networked group of repositories, said system comprising, or having access to through at least one communications device, data and/or code comprising one or more constraints on said inter-networked group of repositories, said constraint(s) constituting a set(s) of rules or controls applicable at least in part to one or more:
A. repositories in said group of repositories, B. accounts therein, C. portions of the content of said repositories, D. portions of the content of said accounts, E. attributes of said repositories, F. attributes of said accounts, and/or G. attributes of said portions of the content of said repositories or said accounts.
468. An advanced asset management system according to claim 1 further comprising a distributed-federated group of repositories, said system comprising, or having access to through at least one communications device, data and/or code comprising one or more constraints on said distributed-federated group of repositories, said constraints constituting a set(s) of rules or controls applicable at least in part to one or more:
A. repositories in said group of repositories, B. accounts therein, C. portions of the content of said repositories, D. portions of the content of said accounts, E. attributes of said repositories, F. attributes of said accounts, and/or G. attributes of said portions of the content of said repositories or said accounts.
469. An advanced asset management system according to claim 1 further comprising a distributed group of repositories, said system comprising, or having access to through at least one communications device, data and/or code comprising one or more constraints on said distributed group of repositories, said constraints constituting a set(s) of rules or controls applicable at least in part to one or more:
A. repositories in said group of repositories, B. accounts therein, C. portions of the content of said repositories, D. portions of the content of said accounts, E. attributes of said repositories, F. attributes of said accounts, and/or G. attributes of said portions of the content of said repositories or said accounts.
470. An advanced asset management system according to claim 1 further comprising a federated group of repositories, said system comprising, or having access to through at least one communications device, data and/or code comprising one or more constraints on said federated group of repositories, said constraints constituting a set(s) of rules or controls applicable at least in part to one or more:
A. repositories in said group of repositories, B. accounts therein, C. portions of the content of said repositories, D. portions of the content of said accounts, E. attributes of said repositories, F. attributes of said accounts, and/or G. attributes of said portions of the content of said repositories or said accounts.
471. An advanced asset management system according to claim 1 further comprising at least one repository, said system comprising, or having access to through at least one communications device, data and/or code comprising one or more constraints on said at least one repository, said constraints constituting a set(s) of rules or controls applicable at least in part to one or more:

A. of said repositories, B. accounts therein, C. portions of the content of said repositories, D. portions of the content of said accounts, E. attributes of said repositories, F. attributes of said accounts, and/or G. attributes of said portions of the content of said repositories or said accounts.
472. An advanced asset management system according to claim 1 comprising, or having access to through at least one communications device, data and/or code comprising one or more constraints on at least one account, said constraints constituting a set(s) of rules or controls applicable at least in part to one or more:
A. of said accounts, B. portions of the content of said accounts, C. attributes of said accounts, and/or D. attributes of said portions of the content of said accounts.
473. An advanced asset management system according to claim 468 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger inter-networked group with which said distributed-federated group of repositories interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger inter-networked group of repositories.
474. An advanced asset management system according to claim 469469 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger inter-networked group of repositories with which said distributed group interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger inter-networked group of repositories.
475. An advanced asset management system according to claim 469469 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger distributed-federated group of repositories with which said distributed group of repositories interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger distributed-federated group of repositories.
476. An advanced asset management system according to claim 470 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger inter-networked group of repositories with which said federated group of repositories interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger inter-networked group of repositories.
477. An advanced asset management system according to claim 470 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger distributed federated group of repositories with which said federated group of repositories interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger distributed-federated group of repositories.
478. An advanced asset management system according to claim 471 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger inter-networked group of repositories with which said at least one repository interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger inter-networked group of repositories.
479. An advanced asset management system according to claim 471 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger distributed-federated group of repositories with which said at least one repository interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger distributed-federated group of repositories.
480. An advanced asset management system according to claim 471 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger distributed group of repositories with which said at least one repository interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger distributed group of repositories.
481. An advanced asset management system according to claim 471 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a larger federated group of repositories with which said at least one repository interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger federated group of repositories.
482. An advanced asset management system according to claim 472 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to an inter-networked group of repositories of repositories with which said at least one account(s) interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger inter-networked group of repositories.
483. An advanced asset management system according to claim 472 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a distributed-federated group of repositories of repositories with which said at least one account interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger distributed-federated group of repositories.
484. An advanced asset management system according to claim 472 wherein:

A. said constraint(s) are an extension or augmentation of rules or controls applicable to a distributed group of repositories of repositories with which said at least one account interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger distributed group of repositories.
485. An advanced asset management system according to claim 472 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a federated group of repositories of repositories with which said at least one account interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the larger federated group of repositories.
486. An advanced asset management system according to claim 472 wherein:
A. said constraint(s) are an extension or augmentation of rules or controls applicable to a repository with which said at least one account interacts, and B. said constraint(s) are not less restrictive than the constraint(s) applicable to the repository.
487. An advanced asset management system according to claim 333 in which information regarding said one or more constraints is stored internal to the system, comprising means for encrypting all of said information.
488. An advanced asset management system according to claim 334 in which information regarding said one or more constraints is stored internal to the system, comprising means for encrypting all of said information.
489. An advanced asset management system according to claim 335 in which information regarding said one or more constraints is stored internal to the system, comprising means for encrypting all of said information.
490. An advanced asset management system according to claim 336 in which information regarding said one or more constraints is stored internal to the system, comprising means for encrypting all of said information.
491. An advanced asset management system according to claim 337 in which information regarding said one or more constraints is stored internal to the system, comprising means for encrypting all of said information.
492. An advanced asset management system according to claim 333 in which at least a portion of any information regarding said one or more constraints is stored internal to the system, comprising means for encrypting at least a part of said portion.
493. An advanced asset management system according to claim 334 in which at least a portion of any information regarding said one or more constraints is stored internal to the system, comprising means for encrypting at least a part of said portion.
494. An advanced asset management system according to claim 335 in which at least a portion of any information regarding said one or more constraints is stored internal to the system, comprising means for encrypting at least a part of said portion.
495. An advanced asset management system according to claim 336 in which at least a portion of any information regarding said one or more constraints is stored internal to the system, comprising means for encrypting at least a part of said portion.
496. An advanced asset management system according to claim 337 in which at least a portion of any information regarding said one or more constraints is stored internal to the system, comprising means for encrypting at least a part of said portion.
497. An advanced asset management system according to claim 333 in which information regarding said one or more constraints is stored external to the system, comprising means for encrypting all of said information.
498. An advanced asset management system according to claim 334 in which information regarding said one or more constraints is stored external to the system, comprising means for encrypting all of said information.
499. An advanced asset management system according to claim 335 in which information regarding said one or more constraints is stored external to the system, comprising means for encrypting all of said information.
500. An advanced asset management system according to claim 336 in which information regarding said one or more constraints is stored external to the system, comprising means for encrypting all of said information.
501. An advanced asset management system according to claim 337 in which information regarding said one or more constraints is stored external to the system, comprising means for encrypting all of said information.
502. An advanced asset management system according to claim 333 in which at least a portion of any information regarding said one or more constraints is stored external to the system, comprising means for encrypting at least a part of said portion.
503. An advanced asset management system according to claim 334 in which at least a portion of any information regarding said one or more constraints is stored external to the system, comprising means for encrypting at least a part of said portion.
504. An advanced asset management system according to claim 335 in which at least a portion of any information regarding said one or more constraints is stored external to the system, comprising means for encrypting at least a part of said portion.
505. An advanced asset management system according to claim 336 in which at least a portion of any information regarding said one or more constraints is stored external to the system, comprising means for encrypting at least a part of said portion.
506. An advanced asset management system according to claim 337 in which at least a portion of any information regarding said one or more constraints is stored external to the system, comprising means for encrypting at least a part of said portion.
507. An advanced asset management system according to claim 333 in which information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting all of said information.
508. An advanced asset management system according to claim 334 in which information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting all of said information.
509. An advanced asset management system according to claim 335 in which information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting all of said information.
510. An advanced asset management system according to claim 336 in which information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting all of said information.
511. An advanced asset management system according to claim 337 in which information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting all of said information.
512. An advanced asset management system according to claim 333 in which at least a portion of any information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting at least a part of said portion.
513. An advanced asset management system according to claim 334 in which at least a portion of any information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting at least a part of said portion.
514. An advanced asset management system according to claim 335 in which at least a portion of any information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting at least a part of said portion.
515. An advanced asset management system according to claim 336 in which at least a portion of any information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting at least a part of said portion.
516. An advanced asset management system according to claim 337 in which at least a portion of any information regarding said one or more constraints is stored internal and external to the system, comprising means for encrypting at least a part of said portion.
517. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for processing information regarding said one or more constraints internal to the system, comprising means for encrypting all of said information.
518. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for processing information regarding said one or more constraints internal to the system, comprising means for encrypting all of said information.
519. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for processing information regarding said one or more constraints internal to the system, comprising means for encrypting all of said information.
520. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for processing information regarding said one or more constraints internal to the system, comprising means for encrypting all of said information.
521. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing information regarding said one or more constraints internal to the system, comprising means for encrypting all of said information.
522. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for processing at least a portion of any information regarding said one or more constraints internal to the system, comprising means for encrypting at least a part of said portion.
523. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for processing at least a portion of any information regarding said one or more constraints internal to the system, comprising means for encrypting at least a part of said portion.
524. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for processing at least a portion of any information regarding said one or more constraints internal to the system, comprising means for encrypting at least a part of said portion.
525. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for processing at least a portion of any information regarding said one or more constraints internal to the system, comprising means for encrypting at least a part of said portion.
526. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for processing at least a portion of any information regarding said one or more constraints internal to the system, comprising means for encrypting at least a part of said portion.
527. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for cooperation with means external to the system for processing information regarding said one or more constraints, comprising means for encrypting all of said information.
528. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for cooperation with means external to the system for processing information regarding said one or more constraints, comprising means for encrypting all of said information.
529. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for cooperation with means external to the system for processing information regarding said one or more constraints, comprising means for encrypting all of said information.
530. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for cooperation with means external to the system for processing information regarding said one or more constraints, comprising means for encrypting all of said information.
531. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperation with means external to the system for processing information regarding said one or more constraints, comprising means for encrypting all of said information.
532. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for cooperation with means external to the system for processing at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
533. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for cooperation with means external to the system for processing at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
534. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for cooperation with means external to the system for processing at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
535. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for cooperation with means external to the system for processing at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
536. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for cooperation with means external to the system for processing at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
537. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, information regarding said one or more constraints, comprising means for encrypting all of said information.
538. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, information regarding said one or more constraints, comprising means for encrypting all of said information.
539. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, information regarding said one or more constraints, comprising means for encrypting all of said information.
540. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, information regarding said one or more constraints, comprising means for encrypting all of said information.
541. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, information regarding said one or more constraints, comprising means for encrypting all of said information.
542. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
543. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
544. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
545. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
546. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for internal processing of, and for cooperation with means external to the system for external processing of, at least a portion of any information regarding said one or more constraints, comprising means for encrypting at least a part of said portion.
547. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for communicating information regarding said one or more constraints to or from the system, comprising means for encrypting all of said information.
548. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for communicating information regarding said one or more constraints to or from the system, comprising means for encrypting all of said information.
549. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for communicating information regarding said one or more constraints to or from the system, comprising means for encrypting all of said information.
550. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for communicating information regarding said one or more constraints to or from the system, comprising means for encrypting all of said information.
551. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for communicating information regarding said one or more constraints to or from the system, comprising means for encrypting all of said information.
552. An advanced asset management system according to claim 333 wherein said data and/or code includes provisions for communicating at least a portion of any information regarding said one or more constraints to or from the system, comprising means for encrypting at least a part of said portion.
553. An advanced asset management system according to claim 334 wherein said data and/or code includes provisions for communicating at least a portion of any information regarding said one or more constraints to or from the system, comprising means for encrypting at least a part of said portion.
554. An advanced asset management system according to claim 335 wherein said data and/or code includes provisions for communicating at least a portion of any information regarding said one or more constraints to or from the system, comprising means for encrypting at least a part of said portion.
555. An advanced asset management system according to claim 336 wherein said data and/or code includes provisions for communicating at least a portion of any information regarding said one or more constraints to or from the system, comprising means for encrypting at least a part of said portion.
556. An advanced asset management system according to claim 337 wherein said data and/or code includes provisions for communicating at least a portion of any information regarding said one or more constraints to or from the system, comprising means for encrypting at least a part of said portion.
557. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one communications device and said at least one repository, wherein said at least one communications channel is/are a public network(s).
558. An advanced asset management system according to claim 1 further comprising or connecting at least one communications channel between said at least one communications device and said at least one other communications device, wherein said at least one communications channel is/are a public network(s).
559. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one repository and at least one other repository, wherein said at least one communications channel is/are a public network(s).
560. An advanced asset management system according to claim 557 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s) and said repository/repositories.
561. An advanced asset management system according to claim 558 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications devices.
562. An advanced asset management system according to claim 559 in which one or more clearinghouses act(s) as an intermediary/intermediaries one or more clearinghouses act(s) as an intermediary/intermediaries between said repositories.
563. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one communications device and said at least one repository, wherein said at least one communications channel is/are a private network(s).
564. An advanced asset management system according to claim 1 further comprising at least one communications channel between said at least one communications device and at least one other communications device, wherein said at least one communications channel is/are a private network(s).
565. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one repository and at least one other repository, wherein said at least one communications channel is/are a private network(s).
566. An advanced asset management system according to claim 563 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s) and said repository/repositories.
567. An advanced asset management system according to claim 564 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s).
568. An advanced asset management system according to claim 565 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said repositories.
569. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one communications device and said at least one repository, wherein said at least one communications channel is/are a private-over-public network(s).
570. An advanced asset management system according to claim 1 further comprising at least one communications channel between said at least one communications device and at least one other communications device, wherein said at least one communications channel is/are a private-over-public network(s).
571. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one repository and at least one other repository, wherein said at least one communications channel is/are a private-over-public network(s).
572. An advanced asset management system according to claim 569 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s) and said repository/repositories.
573. An advanced asset management system according to claim 570 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s).
574. An advanced asset management system according to claim 571 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said repositories.
575. An advanced asset management system according to claim 1 further comprising at least one repository and at least one communications channel between said at least one communications device and said at least one repository, wherein said at least one communications channel is/are some combination of public, private, and/or private-over-public network(s).
576. An advanced asset management system according to claim 1 further comprising at least one communications channel between said at least one communications device and at least one other communications device, wherein said at least one communications channel is/are some combination of public, private, and/or private-over-public network(s).
577. An advanced asset management system according to claim 1 further comprising at least one repository and said at least one communications channel between said at least one repository and at least one other repository, wherein said at least one communications channel is/are some combination of public, private, and/or private-over-public network(s).
578. An advanced asset management system according to claim 575 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s) and said repository/repositories.
579. An advanced asset management system according to claim 576 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said communications device(s).
580. An advanced asset management system according to claim 577 in which one or more clearinghouses act(s) as an intermediary/intermediaries between said repositories.
581. An advanced asset management system according to claim 1 comprising at least one communications channel, 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 constraints restricting or granting access to a particular communications channel(s) and/or sub-component(s) thereof.
582. An advanced asset management system according to claim 581 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate one or more constraints restricting or granting access to a particular communications channel(s) and/or sub-components) thereof only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating tokens) signifying an entity/entities owning or having a right to control said constraint(s).
583. An advanced asset management system according to claim 1 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 sub-accounts, wherein said sub-account(s) is/are the primary accounts) within a particular domain(s).
584. An advanced asset management system according to claim 1 in which the system comprises one or more primary accounts, and 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-accounts, wherein said sub-account(s) is/are related, but subordinate to, said primary account(s).
585. An advanced asset management system according to claim 1 in which the system comprises one or more first sub-accounts, and 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 other sub-accounts, wherein said other sub-account(s) is/are related, but subordinate to, said first sub-account(s).
586. An advanced asset management system according to claim 583 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a primary account(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said primary account(s).
587. An advanced asset management system according to claim 584 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a sub-account(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said sub-account(s).
588. An advanced asset management system according to claim 585 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a sub-account account(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said sub-account(s).
589. An advanced asset management system according to claim 1 comprising means for dynamically generating said token(s) for said account(s).
590. An advanced asset management system according to claim 589 comprising means for said dynamic generation upon request, wherein said request is made by an authorized entity/entities.
591. An advanced asset management system according to claim 589 in which said at least one data processor is configured to accept one or more commands to dynamically generate said token(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating tokens) signifying an entity/entities owning or having a right to control said account(s).
592. An advanced asset management system according to claim 1 in which the system further comprises one or more provisions for maintaining the account(s) in a hierarchy, said hierarchy having one or more levels wherein at least one account is the head of each level so maintained.
593. An advanced asset management system according to claim 592 in which said hierarchies can have zero, one or more additional accounts subordinate to said at least one account serving as the head account.
594. An advanced asset management system according to claim 592 in which said hierarchies can have zero, one or more branches per level.
595. An advanced asset management system according to claim 594 wherein 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 branches.
596. An advanced asset management system according to claim 1 in which the system further comprises one or more provisions for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating one or more classes of said one or more sub-accounts.
597. An advanced asset management system according to claim 596 including provisions for activating, authenticating, creating, deactivating, destroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, andlor otherwise manipulating a plurality of classes of said one or more sub-accounts that differ from one another in their primary function or quality.
598. An advanced asset management system according to claim 596 wherein said one or more sub-accounts comprise a first sub-account(s) and at least one other sub-account of the same class/classes as said first sub-account(s).
599. An advanced asset management system according to claim 596 wherein said one or more sub-accounts comprise a first sub-account(s) and at least one other sub-account of the same class/classes as said first sub-account(s) and wherein at least said first and second sub-accounts are selected from the group consisting of child, peer, escrow, bid, gaming and proxy accounts.
600. An advanced asset management system according to claim 596 in which said one or more classes of sub-accounts comprise a child account(s).
601. An advanced asset management system according to claim 596 in which said one or more classes of sub-accounts comprise a peer account(s).
602. An advanced asset management system according to claim 596 in which said one or more classes of sub-accounts comprise an escrow account(s).
603. An advanced asset management system according to claim 596 in which said one or more classes of sub-accounts comprise a bid account(s).
604. An advanced asset management system according to claim 596 in which said one or more classes of sub-accounts comprise a gaming account(s).
605. An advanced asset management system according to claim 596 in which said one or more classes of sub-accounts comprise a proxy account(s).
606. An advanced asset management system according to claim 602 in which said escrow account(s) includes an obligation account(s), constituting a sub-class of escrow account(s).
607. An advanced asset management system according to claim 602 in which said escrow account(s) includes a credit account(s), constituting a sub-class of escrow account(s).
608. An advanced asset management system according to claim 602 in which a said escrow account(s) includes a reserve account(s), constituting a sub-class of escrow account(s).
609. An advanced asset management system according to claim 605 comprising means for dynamically generating said proxy account(s).
610. An advanced asset management system according to claim 1 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 bid pools.
611. An advanced asset management system according to claim 610 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a bid pool(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said bid pool(s).
612. An advanced asset management system according to claim 1 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 gaming/gambling pools.
613. An advanced asset management system according to claim 612 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a gaming/gambling pool(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said gaming/gambling pool(s).
614. An advanced asset management system according to claim 1 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 labels for one or more accounts.
615. An advanced asset management system according to claim 614 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate said one or more labels only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said account(s).
616. An advanced asset management system according to claim 614 comprising means for dynamically generating said one or more labels.
617. An advanced asset management system according to claim 1 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 domain constraint pools, wherein said domain constraint pool(s) contain(s) the set(s) of all allowed attributes that may be contained within or used by:

A. one or more account(s), and/or a B. at least a portion of the content of said account(s);
and the set(s) of allowed constraints that may be used on or by:

C. one or more account(s), D. at least a portion of the content of said account(s), E. one or more attributes of said account(s), and/or F. one or more attributes of said portion of the content of said account(s);
wherein said account(s) is/are located within the domain(s) governed by said one or more domain constraint pools.
618. A virtual labeling system according to claim 617 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate one or more domain constraint pools only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more domain constraint pools.
619. An advanced asset management system according to claim 617 in which said domain constraint pool(s) contain(s) an allowed range of values and/or limit(s) for each constraint(s) included therein.
620. An advanced asset management system according to claim 617 in which said domain constraint pool(s) contain(s) an allowed range of values and/or limit(s) for each attribute(s) included therein.
621. An advanced asset management system according to claim 315 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) 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, 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.
622. An advanced asset management system according to claim 326 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) 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, modifying, processing, registering, and/or otherwise manipulating one or more constraints on a domain constraint pool or group of domain constraint pools.
623. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain, for making available to a submitting entity one or more command functions, exercisable by the submitting entity, for establishing one or more accounts.
624. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) 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 one or more accounts to one or more other accounts.
625. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain, for making available to a submitting entity one or more command functions, exercisable by the submitting entity, for transferring at least a portion(s) of the content of one or more accounts to one or more other accounts.
626. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain, for making available to a submitting entity one or more command functions, exercisable by the submitting entity, for closing one or more accounts.
627. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain(s), for making available to a submitting entity one or more command functions, exercisable by the submitting entity, for changing the type of a subordinate account from one type to another.
628. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain(s), for making available to a submitting entity one or more command functions, exercisable by the submitting entity, for the transfer of one or more subordinate accounts from at least one parent account within its/their domain(s) to at least one other parent account within its/their domain(s).
629. An advanced asset management system according to claim 628 wherein said transfer includes the transfer of all content of said transferred account(s).
630. An advanced asset management system according to claim 628 wherein said transfer includes the transfer of all account(s) subordinate to said transferred account(s).
631. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain(s), for making available to a submitting entity one or more command functions, exercisable by the submitting entity, for the transfer of one or more accounts to a domain(s) other than its/their domain(s).
632. An advanced asset management system according to claim 629 wherein said transfer includes the transfer of all content of said transferred account(s).
633. An advanced asset management system according to claim 629 wherein said transfer includes the transfer of all account(s) subordinate to said transferred account(s).
634. An advanced asset management system according to claim 1 comprising data and/or code responsive to the submission to the system of a PIN(s), password(s) or other authenticating token(s), including at least the public token(s) of a primary and/or subordinate account(s) in a virtual account domain(s), for making available to a submitting entity a plurality of command functions.
635. An advanced asset management system according to claim 1 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 agents.
636. An advanced asset management system according to claim 635 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate an alert(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more agents.
637. An advanced asset management system according to claim 1 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 alerts.
638. An advanced asset management system according to claim 637 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate an agent(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more alerts.
639. An advanced asset management system according to claim 1 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 triggers.
640. An advanced asset management system according to claim 639 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate an trigger(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more triggers.
641. A virtual labeling system, comprising:
A. a computer system having:
1) at least one data processor 2) at least one data storage device, and 3) at least one communications device through which the computer system can communicate with one or more entities that can connect with said computer system B. labeling system software stored in said computer system on said at least one data storage device 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, 1) said system comprising data and/or code that:
a) creates, stores, maintains and/or otherwise manipulates one or more lists of:
(1) account aliases, which differ from existing public and private tokens of said accounts (2) known labels, including all aliases and all public and private tokens of said account(s) b) ensures the uniqueness of at least all active labels among said known labels throughout all repositories with which it communicates 2) 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 whereby 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 token(s) for said accounts.
642. A virtual labeling system according to claim 641 in which said system comprises a plurality of computer systems.
643. A virtual labeling system according to claim 641 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 one or more virtual labeling systems, list(s) thereof, and/or label(s) thereof.
644. A virtual labeling system according to claim 641 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate one or more virtual labeling systems, list(s) thereof, and/or label(s) thereof, only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control, respectively said one or more virtual labeling systems, said list(s) thereof, and/or said label(s) thereof.
645. A virtual labeling system according to claim 641 comprising data and/or code for permitting access one or more virtual labeling systems, list(s) thereof, and/or label(s) thereof.
646. A virtual labeling system according to claim 641 in which said at least one communications device is configured to permit access to one or more virtual labeling systems, list(s) thereof, and/or label(s) thereof, based on receipt via said at least one communications device of a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities having authorization to access, respectively, said one or more virtual labeling systems, said list(s) thereof, and/or said label(s) thereof.
647. A virtual, labeling system according to claim 641 comprising data and/or code for ensuring uniqueness for all labels in said labeling system and all other labeling systems throughout all said repositories with which said systems(s) communicate(s).
648. A virtual labeling system according to claim 641 in which said symbol(s) is/are of a random nature.
649. A virtual labeling system according to claim 641 in which said symbol(s) is/are of a non-random nature.
650. A virtual labeling system according to claim 641 comprising means for selecting said symbol(s) in a random manner.
651. A virtual labeling system according to claim 641 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 label directories comprising a plurality of published account labels.
652. A virtual labeling system according to claim 651 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a label directory/directories only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said labeling system or list(s) thereof.
653. A virtual labeling system according to claim 641 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 digital certificates or list(s) thereof.
654. A virtual labeling system according to claim 653 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a digital certificate(s) only if said command(s) is/are received in conjunction with a P1N(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said labeling system or list(s) thereof.
655. A virtual labeling system according to claim 641 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 digital signatures or list(s) thereof.
656. A virtual labeling system according to claim 655 in which said at least one data processor is configured to accept one or more commands to activate, authenticate, create, deactivate, destroy, evaluate, generate, implement, maintain, modify, process, register, and/or otherwise manipulate a digital signature(s) only if said command(s) is/are received in conjunction with a PIN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said labeling system or list(s) thereof.
657. A virtual naming system according to claim 641 comprising means for encrypting said labeling system(s).
658. A virtual labeling system according to claim 641 comprising means for encrypting all information regarding said labeling system(s) and its/their comprised list(s), stored by said labeling system(s).
659. A virtual labeling system according to claim 641 comprising means for encrypting at least a portion of any information regarding said labeling system(s) and its/their comprised list(s), stored by said labeling system(s).
660. A virtual labeling system according to claim 641 comprising means for encrypting all information regarding said labeling system(s) and its/their comprised list(s), processed by said labeling system(s).
661. A virtual labeling system according to claim 641 comprising means for encrypting at least a portion of any information regarding said labeling system(s) and its/their comprised list(s), processed by said labeling system(s).
662. A virtual labeling system according to claim 641 comprising means for encrypting all information regarding said labeling system(s) and its/their comprised list(s), communicated to or from said labeling system(s).
663. A virtual labeling system according to claim 641 comprising means for encrypting at least a portion of any information regarding said labeling system(s) and its/their comprised list(s), communicated to or from said labeling system(s).
664. A method for managing and utilizing virtual accounts, comprising:
A. providing a computer system having:
1) at least one data processor, 2) at least one data storage device, 3) 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;
B. maintaining in said computer system on said at least one data storage device, data and/or code with respect to at least one virtual account and, optionally, with respect to one or more direct or indirect sub-accounts thereof, comprising:
1) providing at least one private token that is a confidential symbol(s) through which the virtual account(s) is/are recognizable by the system 2) providing at least one public token that is a confidential symbol(s) through which the virtual account(s) is/are recognizable by the system in communications via said at least one communications device between the system and said entity/entities, and 3) providing optionally, one or more additional public tokens through which said one or more direct or indirect sub-accounts is/are recognizable in communications via said at least one communications device between the system and said entity/entities;
C. via said at least one communications device, manipulating one or more of said accounts using said at least one public token or said one or more additional public tokens, and without furnishing the private token(s) of the virtual account(s), and;
D. preventing said entity/entities from obtaining said at least one private token(s) via said at least one communications device;
wherein the account(s) stored in said computer system comprise one or more virtual account(s), one or more direct or indirect public sub-accounts thereof, and token(s) thereof.
665. A method according to claim 664 wherein said manipulating of said one or more accounts comprises conducting transactions by transmitting assets to said account(s), and crediting said account(s) with respect to amounts of assets so transmitted.
666. A method according to claim 664 wherein said manipulating of said one or more accounts comprises conducting transactions by transmitting assets from said account(s), and debiting said account(s) with respect to amounts of assets so transmitted.
667. A method according to claim 664 comprising maintaining data in the system which is/are an asset(s).
668. A method according to claim 667 in which the asset(s) is/are a digital asset(s).
669. A method according to claim 667 in which the asset(s) is/are qualitative information about a digital asset(s).
670. A method according to claim 667 in which the asset(s) is/are information other than qualitative information about a digital asset(s).
671. A method according to claim 667 in which the asset(s) is/are a representation of a digital asset(s).
672. A method according to claim 667 in which the asset(s) is/are qualitative information about a representation of a digital asset(s).
673. A method according to claim 667 in which the asset(s) is/are information other than qualitative information about a representation of a digital asset(s).
674. A method according to claim 667 in which the asset(s) is/are a representation of a non-digital asset(s),
675. A method according to claim 667 in which the asset(s) is/are qualitative information about a representation of a non-digital asset(s).
676. A method according to claim 667 in which the asset(s) is/are information other than qualitative information about a representation of a non-digital asset(s).
677. A method according to claim 664 comprising storing account management software on said at least one data storage device and encrypting all said software and any code therein in said system.
678. A method according to claim 677 comprising maintaining all of the encrypted software in encrypted form throughout its storage by the system.
679. A method according to claim 677 comprising maintaining all of the encrypted software in encrypted form throughout its processing by the system.
680. A method according to claim 677 comprising maintaining all of the encrypted software in encrypted form throughout its communication to and from the system.
681. A method according to claim 664 comprising storing account management software on said at least one data storage device and encrypting at least a portion of said software and any code therein in said system.
682. A method according to claim 681 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its storage by the system.
683. A method according to claim 681 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its processing by the system.
684. A method according to claim 681 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its communication to and from the system.
685. A method according to claim 664 comprising encrypting all of the data in said system.
686. A method according to claim 685 comprising maintaining all of the encrypted data in encrypted form throughout its storage by the system.
687. ~A method according to claim 685 comprising maintaining all of the encrypted data in encrypted form throughout its processing by the system.
688. ~A method according to claim 685 comprising maintaining all of the encrypted data in encrypted form throughout its communication to and from the system.
689. ~A method according to claim 664 comprising encrypting at least a portion of the data in said system.
690. ~A method according to claim 689 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its storage by the system.
691. ~A method according to claim 689 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its processing by the system.
692. ~A method according to claim 689 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its communication to and from the system.
693. ~A method according to claim 664 comprising storing account management software on said at least one data storage device and encrypting all said software and any code therein, and all of the data, in said system.
694. ~A method according to claim 693 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their storage by the system.
695. ~A method according to claim 693 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their processing by the system.
696. ~A method according to claim 693 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their communication to and from the system.
697. ~A method according to claim 664 comprising storing account management software on said at least one data storage device and encrypting at least a portion of said software and any code therein, and at least a portion of the data, in said system.
698. A method according to claim 697 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their storage by the system.
699. A method according to claim 697 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their processing by the system.
700. A method according to claim 697 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their communication to and from the system.

12.2.2 Sixth Aspect
701. A method for transferring assets, comprising:
A. providing a computer system having 1) at least one data processor, 2) at least one data storage device, 3) 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, 4) virtual account data stored on said at least one data storage device, said virtual account data comprising one or more virtual accounts, and for each of said virtual account(s), respectively:
a) at least one private token that is a confidential symbol through which the virtual account(s) is recognizable by the system, b) at least one public token that is a symbol(s) through which the virtual account(s) is/are recognizable by the system in communications between the system and said entity/entities, c) optionally, one or more additional public token(s), through which one or more direct and/or indirect sub-accounts of said virtual account(s) is/are recognizable by the system, and 5) account management software stored on said at least one data storage device, said software comprising data and/or code:
a) making said virtual account(s) and/or one or more sub-accounts thereof accessible, at least in part, via said at least one communications device, b) through which the system to recognizes and manipulates a given account(s) upon receipt, via said at least one communications device, of a public token(s) of the given account(s) without receipt of a private token(s), and c) prevents said entity/entities from obtaining the private token(s) via said at least one communications device;
B. inputting into said computer, in respect to a given account or account set, asset data that 1) is an asset(s) and/or one or more quantities of an asset(s) and/or one or more representations of a quantity/quantities of an asset(s) with respect to one or more types of tangible and/or intangible asset(s), wherein the asset(s) quantity/quantities inputted may be the same or different for different accounts where data is inputted for more than one account, and 2) is logically linked to one or more of said tokens that designates) the given account or account set for which said quantity is inputted; and C. using one or more of said public tokens to designate the accounts) involved, and transferring an asset(s) and/or a quantity/quantities and/or a representation(s), comprising all or a portion of the asset(s) and/or quantity/quantities and/or representation(s) for which data has been inputted as to a given account or account set, from said given account or account set to another account or account set in said computer system and/or in another computer system(s) without requiring physical manifestation and transfer of the asset(s).
702. A method according to claim 701 wherein said transferring is carried out virtually instantaneously upon inputting of said data.
703. A method according to claim 701 wherein said transferring is carried out after retaining the data with respect thereto in storage in the system at least momentarily after the inputting of said data.
704. A method for transferring assets according to claim 701 comprising aggregating assets by moving all or at least a portion of said asset(s) and/or quantity/quantities and/or representation(s) present in a given plurality of source accounts into a lesser number of one or more target accounts.
705. A method for transferring assets according to claim 701 comprising distributing assets by moving all or at least a portion of said asset(s) and/or quantity/quantities and/or representation(s) present in one or more source accounts into a larger number of target accounts.
706. A method for transferring assets according to claim 701 comprising exchanging assets by moving all or at least a portion of the asset(s) and/or quantity/quantities and/or representation(s) present in a 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 asset(s) and/or quantity/quantities and/or representation(s) present in the second account or set of accounts into the first account or set of accounts.
707. A method for transferring assets according to claim 704 in which said aggregating includes the step of converting all or a portion of the content of at least one of the accounts into a different form.
708. A method for transferring assets according to claim 705 in which said distributing includes the step of converting all or a portion of the content of at least one of the accounts into a different form.
709. A method for transferring assets according to claim 706 in which said exchanging includes the step of converting all or a portion of the content of at least one of the accounts into a different form.

12.2.3 Seventh Aspect
710. A method of operating a virtual clearinghouse system for facilitating transactions in which the transaction participants respectively comprise a first participant which is at least one virtual 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-account(s) thereof, said method comprising:
A. providing a clearinghouse computer system having:
1) at least one data processor, 2) at least one data storage device, and, 3) 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;
B. maintaining in said clearinghouse computer system on said at least one data storage device 1) 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 2) data and/or code that represents the existence of direct or indirect trusting relationships between a) the clearinghouse system and one or more repositories and b) the clearinghouse system and the second participant;
C. receiving in said computer system virtual account repository connection requests respectively comprising data representing:
1) at least one virtual account transaction, comprising such information as is required to characterize the transaction 2) at least one address for a given repository/repositories in which the participating account(s) is/are situated and at least one public token of a participating account(s); and D. establishing, accepting, coordinating, and/or otherwise manipulating 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 transmitting the transaction information;
whereby the participants can conduct transactions with each other without requiring a direct trusting relationship between the participants.
711. A method according to claim 710 comprising data and/or code cause(s) said clearinghouse system to act as a third party intermediary for facilitating one or more escrow transactions.
712. A method according to claim 710 comprising data and/or code cause(s) said clearinghouse system to act as a third party intermediary for facilitating one or more bid transactions.
713. A method according to claim 710 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 bid pools.
714. A method according to claim 710 comprising data and/or code cause(s) said clearinghouse system to act as a third party intermediary for facilitating one or more gaming/gambling transactions.
715. A method according to claim 710 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~
gaming/gambling pools.
716. A method according to claim 710 comprising data and/or code cause(s) said clearinghouse system to act as an agent for one or more repositories.
717. A method according to claim 710 comprising data and/or code for calculating, collecting, disbursing, reporting, and/or otherwise manipulating taxes and/or fees.
718. A method according to claim 710 comprising data and/or code for calculating, collecting, disbursing, reporting, and/or otherwise manipulating information pertaining to at least in part taxes and/or fees.
719. A method according to claim 710 comprising data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating one or more credentials and/or licenses.
720. A method according to claim 710 comprising data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating information pertaining to at least in part credentials and/or licenses.
721. A method according to claim 710 comprising data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating one or more digital security certificates.
722. A method according to claim 710 comprising data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating information pertaining to at least in part digital signatures.
723. A method according to claim 710 comprising data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating one or more digital security certificates.
724. A method according to claim 710 comprising data and/or code for granting, revoking, reporting, validating, transmitting and/or otherwise manipulating information pertaining to at least in part digital signatures.
725. A method according to claim 710 comprising storing clearinghouse management software on said at least one data storage device and encrypting all said software and any code therein in said system.
726. A method according to claim 725 comprising maintaining all of the encrypted software in encrypted form throughout its storage by the system.
727. A method according to claim 725 comprising maintaining all of the encrypted software in encrypted form throughout its processing by the system.
728. A method according to claim 725 comprising maintaining all of the encrypted software in encrypted form throughout its communication to and from the system.
729. A method according to claim 710 comprising storing clearinghouse management software on said at least one data storage device and encrypting at least a portion of said software and any code therein in said system.
730. A method according to claim 729 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its storage by the system.
731. A method according to claim 729 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its processing by the system.
732. A method according to claim 729 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its communication to and from the system.
733. A method according to claim 710 comprising encrypting all of the data in said system.
734. A method according to claim 733 comprising maintaining all of the encrypted data in encrypted form throughout its storage by the system.
735. A method according to claim 733 comprising maintaining all of the encrypted data in encrypted form throughout its processing by the system.
736. A method according to claim 733 comprising maintaining all of the encrypted data in encrypted form throughout its communication to and from the system.
737. A method according to claim 710 comprising encrypting at least a portion of the data in said system.
738. A method according to claim 737 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its storage by the system.
739. A method according to claim 737 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its processing by the system.
740. A method according to claim 737 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its communication to and from the system.
741. A method according to claim 710 comprising storing clearinghouse management software on said at least one data storage device and encrypting all said software and any code therein, and all of the data, in said system.
742. A method according to claim 741 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their storage by the system.
743. A method according to claim 741 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their processing by the system.
744. A method according to claim 741 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their communication to and from the system.
745. A method according to claim 710 comprising storing clearinghouse management software on said at least one data storage device and encrypting at least a portion of said software and any code therein, and at least a portion of the data, in said system.
746. A method according to claim 745 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their storage by the system.
747. A method according to claim 745 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their processing by the system.
748. A method according to claim 745 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their communication to and from the system.
12.2.4 Eighth Aspect
749. A method of operating a virtual naming system, comprising:
A. providing a computer system having:
1) at least one data processor, 2) at least one data storage device, and 3) at least one communications device through which the computer system can communicate with one or more entities that can connect with said computer system;
B. maintaining in said computer system on said at least one data storage device naming system software for creating, storing, maintaining and/or otherwise manipulating data comprising a list(s) of at least one name and at least one address for each of a plurality of repositories;

C. receiving from said entity/entities via said at least one communications device one or more requests that respectively include 1) A name request, comprising an address(es) of and seeking a name(s) of one or more repositories, and/or 2) An address request, comprising a name(s) of and seeking an address(es) of one or more repositories; and D. in response to said request(s), causing said computer system to locate and to furnish to said entity/entities, one or more name(s) and/or address(es) sought by said request(s), whereby one or more entities other than naming system administrators, including persons, organizations and/or other computer systems, owning or having control of an account(s) 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 route(s) to such a repository/repositories without knowing the name or without knowing the address thereof.
750. A method according to claim 749 wherein said list(s) additionally comprise one or more repository aliases.
751. A method according to claim 749 wherein said list(s) additionally comprise one or more repository ownership certificates.
752. A method according to claim 749 wherein said list(s) additionally comprise known clearinghouses and clearinghouse addresses.
753. A method according to claim 749 wherein said list(s) additionally comprise one or more clearinghouse aliases.
754. A method according to claim 749 wherein said list(s) additionally comprise one or more clearinghouse ownership certificates.
755. A method according to claim 749 wherein said list(s) additionally comprise known labeling systems and labeling system addresses.
756. A method according to claim 749 wherein said list(s) additionally comprise one or more labeling system aliases.
757. A method according to claim 749 wherein said list(s) additionally comprise one or more labeling system ownership certificates.
758. A method according to claim 749 wherein said list(s) additionally comprise known naming systems and naming system addresses.
759. A method according to claim 749 wherein said list(s) additionally comprise one or more naming system aliases.
760. A method according to claim 749 wherein said list(s) additionally comprise one or more naming system ownership certificates.
761. A method according to claim 749 wherein said list(s) additionally comprise known devices and device addresses.
762. A method according to claim 749 wherein said list(s) additionally comprise one or more device aliases.
763. A method according to claim 749 wherein said list(s) additionally comprise one or more device ownership certificates.
764. A method according to claim 749 comprising storing naming system software on said at least one data storage device and encrypting all said software and any code therein in said system.
765. A method according to claim 764 comprising maintaining all of the encrypted software in encrypted form throughout its storage by the system.
766. A method according to claim 764 comprising maintaining all of the encrypted software in encrypted form throughout its processing by the system.
767. A method according to claim 764 comprising maintaining all of the encrypted software in encrypted form throughout its communication to and from the system.
768. A method according to claim 749 comprising storing naming system software on said at least one data storage device and encrypting at least a portion of said software and any code therein in said system.
769. A method according to claim 768 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its storage by the system.
770. A method according to claim 768 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its processing by the system.
771. A method according to claim 768 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its communication to and from the system.
772. A method according to claim 749 comprising encrypting all of the data in said system.
773. A method according to claim 772772 comprising maintaining all of the encrypted data in encrypted form throughout its storage by the system.
774. A method according to claim 772772 comprising maintaining all of the encrypted data in encrypted form throughout its processing by the system.
775. A method according to claim 772772 comprising maintaining all of the encrypted data in encrypted form throughout its communication to and from the system.
776. A method according to claim 749 comprising encrypting at least a portion of the data in said system.
777. A method according to claim 776 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its storage by the system.
778. A method according to claim 776 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its processing by the system.
779. A method according to claim 776 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its communication to and from the system.
780. A method according to claim 749 comprising storing naming system software on said at least one data storage device and encrypting all said software and any code therein, and all of the data, in said system.
781. A method according to claim 780 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their storage by the system.
782. A method according to claim 780 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their processing by the system.
783. A method according to claim 780 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their communication to and from the system.
784. A method according to claim 749 comprising storing naming system software on said at least one data storage device and encrypting at least a portion of said software and any code therein, and at least a portion of the data, in said system.
785. A method according to claim 784 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their storage by the system.
786. A method according to claim 784 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their processing by the system.
787. A method according to claim 784 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their communication to and from the system.

12.2.5 Ninth Aspect
788. A method of operating a virtual labeling system, comprising:
A. providing a computer system having:
1) at least one data processor, 2) at least one data storage device, and 3) at least one communications device through which the computer system can communicate with one or more entities that can connect with said computer system;
B. 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 1) said data being at least in part accessible via said at least one communications device, and 2) 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), and 3) said software including data and/or code that creates, stores, maintains and/or otherwise manipulates one or more lists of all known active labels of an account(s), which labels include the private token(s), the public token(s), if any, and account alias(es), if any, of said account(s), said account alias(es) differing from any existing public and/or private token(s) of the account() to which the alias(es) pertain;
C. through said data and/or code, barring from introduction into said list(s), 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;
D. via said at least one communications device, receiving from one or more repositories and/or one or more clearinghouses requests that respectively 1) include of least one alias of a given account and 2) seek a public token of the given account; and E. Via said at least one communications device, fulfilling said requests by transmitting the requested token/label to said repositories and/or clearinghouses whereby 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 communicate with such account(s) without knowing the public token(s) for said account(s).
789. A method according to claim 788 in which said symbol(s) is/are of a random nature.
790. A method according to claim 788 in which said symbol(s) is/are of a non-random nature.
791. A method according to claim 788 comprising means for selecting said symbol(s) in a random manner.
792. A method according to claim 788 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 label directories comprising a plurality of published account labels.
793. A method according to claim 788 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 digital certificates or list(s) thereof.
794. A method according to claim 788 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 digital signatures or list(s) thereof.
795. A method according to claim 788 comprising storing labeling system software on said at least one data storage device and encrypting all said software and any code therein in said system.
796. A method according to claim 795 comprising maintaining all of the encrypted software in encrypted form throughout its storage by the system.
797. A method according to claim 795 comprising maintaining all of the encrypted software in encrypted form throughout its processing by the system.
798. A method according to claim 795 comprising maintaining all of the encrypted software in encrypted form throughout its communication to and from the system.
799. A method according to claim 788 comprising storing labeling system software on said at least one data storage device and encrypting at least a portion of said software and any code therein in said system.
800. A method according to claim 799 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its storage by the system.
801. A method according to claim 799 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its processing by the system.
802. A method according to claim 799 comprising maintaining at least a portion of the encrypted software in encrypted form throughout its communication to and from the system.
803. A method according to claim 788 comprising encrypting all of the data in said system.
804. A method according to claim 803 comprising maintaining all of the encrypted data in encrypted form throughout its storage by the system.
805. A method according to claim 803 comprising maintaining all of the encrypted data in encrypted form throughout its processing by the system.
806. A method according to claim 803 comprising maintaining all of the encrypted data in encrypted form throughout its communication to and from the system.
807. A method according to claim 788 comprising encrypting at least a portion of the data in said system.
808. A method according to claim 807 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its storage by the system.
809. A method according to claim 807 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its processing by the system.
810. A method according to claim 807 comprising maintaining at least a portion of the encrypted data in encrypted form throughout its communication to and from the system.
811. A method according to claim 788 comprising storing labeling system software on said at least one data storage device and encrypting all said software and any code therein, and all of the data, in said system.
812. A method according to claim 811 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their storage by the system.
813. A method according to claim 811 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their processing by the system.
814. A method according to claim 811 comprising maintaining all of the encrypted software, and all of the encrypted data, in encrypted form throughout their communication to and from the system.
815. A method according to claim 788 comprising storing labeling system software on said at least one data storage device and encrypting at least a portion of said software and any code therein, and at least a portion of the data, in said system.
816. A method according to claim 815 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their storage by the system.
817. A method according to claim 815 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their processing by the system.
818. A method according to claim 815 comprising maintaining at least a portion of the encrypted software, and at least a portion of the encrypted data, in encrypted form throughout their communication to and from the system.
CA002416550A 2000-05-11 2001-05-11 Advanced asset management systems Abandoned CA2416550A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US56902300A 2000-05-11 2000-05-11
US09/569,023 2000-05-11
PCT/US2001/015283 WO2001084906A2 (en) 2000-05-11 2001-05-11 Advanced asset management systems

Publications (1)

Publication Number Publication Date
CA2416550A1 true CA2416550A1 (en) 2001-11-15

Family

ID=24273774

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002416550A Abandoned CA2416550A1 (en) 2000-05-11 2001-05-11 Advanced asset management systems

Country Status (3)

Country Link
AU (1) AU2001263068A1 (en)
CA (1) CA2416550A1 (en)
WO (1) WO2001084906A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016112923A1 (en) * 2015-01-14 2016-07-21 Corporaciónn Losabec, Estratégias Globales Srl. System for the digital payment of taxes
US11049178B2 (en) * 2017-12-22 2021-06-29 Mastercard International Incorporated Offer and acceptance matching to obtain physical cash

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2372344A (en) * 2001-02-17 2002-08-21 Hewlett Packard Co System for the anonymous purchase of products or services online
US7707121B1 (en) * 2002-05-15 2010-04-27 Navio Systems, Inc. Methods and apparatus for title structure and management
US7814017B2 (en) 2005-06-24 2010-10-12 Wells Fargo Bank, N.A. Simple on-line payments facility
EP1977381A4 (en) 2005-12-29 2014-01-01 Oncircle Inc Software, systems, and methods for processing digital bearer instruments
WO2007130502A2 (en) 2006-04-29 2007-11-15 Navio Systems, Inc. Enhanced title processing arrangement
US7844547B2 (en) * 2006-08-21 2010-11-30 Carl Raymond Amos Uncle gem IV, universal automatic instant money, data and precious metal and stone transfer machine
US10380621B2 (en) 2006-11-15 2019-08-13 Api Market, Inc. Title-acceptance and processing architecture
KR101189427B1 (en) * 2007-11-21 2012-10-10 알카텔-루센트 유에스에이 인코포레이티드 Rule based hierarchical account resource management system and method
US8628422B2 (en) 2008-10-14 2014-01-14 Wms Gaming Inc. Gaming system having virtual assets and achievements
US20120054096A1 (en) * 2009-05-11 2012-03-01 Burega John A System and method for intra- and inter-jurisdictional collection and distribution of funds
WO2013019519A1 (en) 2011-08-02 2013-02-07 Rights Over Ip, Llc Rights-based system
US20200311790A1 (en) * 2013-04-11 2020-10-01 Brandshield Ltd. System, Device, and Method of Protected Electronic Commerce and Electronic Financial Transactions
WO2015142765A1 (en) 2014-03-17 2015-09-24 Coinbase, Inc Bitcoin host computer system
CN105827497A (en) * 2015-01-05 2016-08-03 阿里巴巴集团控股有限公司 Network resource processing method, network resource processing device, and instant messaging system
JP6660062B2 (en) 2015-02-09 2020-03-04 ティーゼロ・グループ,インコーポレーテッド Cryptographic integration platform
US11704733B2 (en) 2015-05-01 2023-07-18 Tzero Ip, Llc Crypto multiple security asset creation and redemption platform
AU2016307202A1 (en) 2015-05-26 2017-12-07 Tzero Ip, Llc Obfuscation of intent in transactions using cryptographic techniques
AU2016389498A1 (en) * 2015-12-31 2018-07-12 Tzero Ip, Llc Crypto multiple security asset creation and redemption platform
EP3579518B1 (en) * 2017-03-13 2021-08-18 Huawei Technologies Co., Ltd. Payment method and device based on verification terminal
EP4007983A4 (en) 2019-08-01 2023-08-30 Coinbase, Inc. Systems and methods for generating signatures
WO2021076868A1 (en) 2019-10-16 2021-04-22 Coinbase, Inc. Systems and methods for re-using cold storage keys
US11477203B2 (en) 2020-07-16 2022-10-18 The Toronto-Dominion Bank Method and system for initiating a transfer of resources
CN113326027B (en) * 2021-05-12 2022-05-10 上海安畅网络科技股份有限公司 Domain-driven design tactical modeling method
CN113704067B (en) * 2021-09-09 2023-10-24 合肥新青罗数字技术有限公司 Intangible asset management system monitoring method
CN117291729B (en) * 2023-11-27 2024-02-20 深圳市易图资讯股份有限公司 Fixed asset investment management big data information system

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6112191A (en) * 1993-02-18 2000-08-29 Every Penny Counts, Inc. Method and system to create and distribute excess funds from consumer spending transactions
US5802499A (en) * 1995-07-13 1998-09-01 Cedel Bank Method and system for providing credit support to parties associated with derivative and other financial transactions

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016112923A1 (en) * 2015-01-14 2016-07-21 Corporaciónn Losabec, Estratégias Globales Srl. System for the digital payment of taxes
US11049178B2 (en) * 2017-12-22 2021-06-29 Mastercard International Incorporated Offer and acceptance matching to obtain physical cash

Also Published As

Publication number Publication date
WO2001084906A3 (en) 2002-12-05
WO2001084906A2 (en) 2001-11-15
AU2001263068A1 (en) 2001-11-20

Similar Documents

Publication Publication Date Title
US20220122062A1 (en) Systems and methods for facilitating transactions using a digital currency
CN109074580B (en) Method and system for secure transfer of entities over a blockchain
CA2416550A1 (en) Advanced asset management systems
Bollen The Legal Status of Online Currencies–Are Bitcoins the Future?
US6236972B1 (en) Method and apparatus for facilitating transactions on a commercial network system
AU2002250316B2 (en) Methods and systems for carrying out contingency-dependent payments via secure electronic bank drafts supported by online letters of credit and/or online performance bonds
TW381241B (en) Electronic wallet based on distributed network
KR101379168B1 (en) Multiple party benefit from an online authentication service
US8135650B2 (en) Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
US7747523B2 (en) Internet-based financial vehicles
US6529885B1 (en) Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
CN111316258A (en) Transaction privacy in public distributed ledger system
CN112912909A (en) System and method for facilitating transactions using digital currency
AU2002250316A1 (en) Methods and systems for carrying out contingency-dependent payments via secure electronic bank drafts supported by online letters of credit and/or online performance bonds
AU2001248198A1 (en) A method and system for a virtual safe
WO2001080190A1 (en) A method and system for a virtual safe
CN116472696A (en) Digital asset redemption system, digital wallet and digital asset redemption architecture
Tucker The digital currency doppelganger: Regulatory challenge or harbinger of the new economy
US20230162202A1 (en) Ownership restricted electronic ticketing system
JP2024501883A (en) Systems and methods for facilitating transactions using digital currencies
WO2001058242A9 (en) Electronic factoring
KR20040015637A (en) Real estate-transaction system capable of settlement using credit card and service method using it
Wafgaonkar Critical study of e-commerce in the pharmaceutical industry
Herpel 2011 Observations on the Digital Currency Industry
Singh The digital economy: An overview

Legal Events

Date Code Title Description
FZDE Discontinued