WO2001084906A2

WO2001084906A2 - Advanced asset management systems

Info

Publication number: WO2001084906A2
Application number: PCT/US2001/015283
Authority: WO
Inventors: John V. Zambrzycki; Christopher K. Jackson; Carolyn H. Choie; Kevin W. Layman; Edward J. Newman, Jr.; David E. Richardson, Jr.
Original assignee: Virtual Assets Incorporated
Priority date: 2000-05-11
Filing date: 2001-05-11
Publication date: 2001-11-15
Also published as: CA2416550A1; WO2001084906A3; AU2001263068A1

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

2 Technical Field

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.

3 Background of the Invention

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 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, 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. 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 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 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 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 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 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 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 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. 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. 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. 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 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 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 unaware 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. I-n either situation, it is very easy to create fraudulent charges using a stolen account number because the account number changes only when the account is closed and reopened 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 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 are 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 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 may be unwittingly exposing 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 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 l/20^th 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 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 security and personal freedom.

Two technologies previously offered to provide some measure of security while maintaining a desired level of anonymity are 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 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 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. 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 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. 4 Summary of the Invention

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 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 token(s) stored in the computer system. These token(s) are symbols through said one or more accounts is/are recognizable by the system. The first mentioned token(s) affords at least one account of said one or more accounts to be recognizable by the system in communications between the system and said entities. Optionally, there may be one or more additional token(s) through which the system can recognize one or more direct and/or indirect sub-account(s) 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 receipt, via said at least one communication device, of said at least one token or said one or more additional tokens. Thus, the account(s) stored in the computer system comprise one or more account(s), one or more direct or indirect sub-accounts(s) thereof, and token(s) thereof. 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).

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 card 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 one embodiment of the foregoing general method, the advanced asset management system comprises a plurality of computer systems.

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 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 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). In still another embodiment the 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 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 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 record(s) pertaining to one or more completed transaction(s) of said account(s). hi yet another embodiment the advanced asset management system has storage device(s) which contain(s) historical record(s) 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 account(s) of the advanced asset management system may comprise a savings account(s), a checking account(s), a money-market 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] In another embodiment said virtual account(s) at least one private token, stored in said computer system, that is/are a confidential symbol(s) through which said virtual account(s) is/are recognizable by the system, 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 said virtual account(s) is/are recognizable by the 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 account(s) 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 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 prevents said entities from obtaining said at least one private token via said at least one communications device.

4.1.1.8 [Claims 22]

In another embodiment 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).

4.1.1.9 [Claims 23-28]

In other embodiments ownership or 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; identified, in that sufficient information for 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 further comprises data and/or code for managing, respectively, said anonymous, identified, and/or masked account(s).

4.1.1.10 [Claims 29-30]

In another embodiment the advanced asset management system comprises a plurality of account(s) in which ownership or control of a given account(s) differs from at least one other account(s) as to whether said account(s) are anonymous, identified, and/or masked. In one form of this embodiment the advanced asset management system comprises 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. 4.1.1.11 [Claims 31-50]

In other embodiments the advanced asset management system may comprise data and/or code that cause(s) the system to recognize one or more logical connections between accounts. These connections can be between accounts, between sub-accounts, from an account(s) to a sub-account(s), and/or from a sub-account(s) to an account(s). In various optional forms of these embodiments, the first mentioned account(s) in each of the foregoing types of combinations of accounts may be anonymous, identified, or identified, but with their true identity masked, to the account(s) 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 account(s) involved therein is/are anonymous, identified, and or masked.

4.1.1.12 [Claims 51-62] In other embodiments the advanced asset management system may comprise 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, 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 or control of said account(s), the content of said account(s), the logical connection(s) in which said account(s) are involved, any transactions in which said account(s) is/are involved, and/or any transaction historyhistories in which said account(s) have been involved.

4.1.1.13 [Claims 63-78] In yet 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), serving as a parent account(s) 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 embodiments, the parent account(s) 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. 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 account(s) 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.

4.1.1.14 [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, and/or otherwise 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 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). 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, h still another particular form of 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 domain(s) 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- 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 domain(s) 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 account(s) that is: stored by the system, processed by the 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 connection(s) of said account(s), the transactions involving said account(s), and the transaction histories in which said account(s) 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 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).

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

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 commumcations 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 an open group and may not be subject to any restriction(s) against an interaction(s) 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 interaction(s) with one or more repositories and/or their respective account(s) outside of said group, or against a specific type(s) of interaction(s) with one or more repositories and/or their respective account(s), or against an interaction(s) with other than approved communications device(s). In still other forms of the foregoing particular set of respective embodiments, the restrictioιι(s) to the controlled group may be dynamically selected and applied, based on data received via said communications device(s). In yet other forms of the foregoing particular set of respective embodiments, the last mentioned restriction(s) may be enforced or abrogated based on the character of, and in response to receipt of, a PIN(s), password(s) or other authenticating token(s). 4.1.1.20 [Claims 141-153]

In one form of these embodiments 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) 5 to, the other repositories in said group(s). In another form of these embodiments 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 code that represents a condition of trust with respect to transactions within and between repositories in said group(s). In yet o another form of these embodiments, there is a plurality of said repositories representing a distributed-federated group(s) having controlling software and/or hardware programmed with information identifying each of the other repositories in the group(s), communications route(s) to the other repositories in the group(s), and code that represents a condition of trust with respect to transactions within and 5 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 group(s) in which 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; and/or a communications connection(s) between repositories in the group(s) is/are not required 0 to be known in advance, but can be discovered; and/or a route(s) between repositories in the group(s) is/are not required to be known in advance, but can be determined; and/or 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; and/or the 5 communications connections between repositories in the group(s) may be intermittent or permanent; and/or and communications connection(s) between repositories in the group(s) 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 0 that exist in an inter-networked group(s) 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 group(s) are not required to be known in advance, but can be determined; routes between repositories in said group(s) 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 group(s) 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- 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 comprises means for encrypting all or at least a portion of any information regarding 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-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. 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 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 given repository/repositories in which the participating account(s) is/are situated, and at least one public token(s) 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 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. 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 accept one or more commands to perform these functions 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 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, based on receipt via said at least one communications device of a PIN(s), ρassword(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. In another embodiment the virtual clearinghouse system may comprise data and/or code that cause(s) said clearinghouse system to act as a third party intermediary for facilitating one or more

.- ^• J -- A- — _-_ . : 1 1.1-

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) and/or said gaming/gambling pool(s).

4.1.2.3 [Claims 185-204] In one other embodiment, the virtual clearinghouse system may comprise data and/or code that cause(s) 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, 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 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 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 confrol 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 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 5 about account(s) and participant(s) 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 confrol of said account(s), at least a portion of the content of said account(s), a logical connection(s) of an account(s), a transaction(s) involving an account(s), and a o transaction history/histories in which an account(s) 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 5 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 0 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 and/or code that creates, stores, maintains, and/or otherwise manipulates a list(s) of known repositories and repository addresses. Said naming system allows one or more entities other than naming system administrators, including persons, organizations, 5 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, to locate and discover a communication route(s) 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 list(s) thereof. Said list(s) 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 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 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. 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 list(s) 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 and/or 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.

4.1.3.3 [Claims 262-268] 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 system(s) 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 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).

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 account(s) independently from one another. In other forms of the foregoing embodiments the advanced asset management system comprises 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

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 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 asset(s) of an account(s) 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 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. In another form of these embodiments, the advanced asset management system may comprise data and/or code that comprise(s) conversion routine(s) 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(s) of at least one of said other type(s) 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 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, thus chmmishing the current available balance by the amount placed on reserve, without debiting the account(s). In still other embodiments 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 account(s) 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.

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 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 account(s) 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 multi-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. In 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 multinational 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 account(s) tangible or intangible non-monetary asset(s) 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 account(s) from containing, an asset(s) in a particular form of currency, an asset(s) in the currency of a particular national and/or multi-national jurisdiction, a particular tangible or intangible non-monetary asset(s) of measurable value, a particular tangible or intangible non-monetary asset(s) of measurable quantity but no measurable value, and/or a particular tangible or intangible non-monetary asset(s) of no measurable quantity. 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, 5 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 command(s) is/are received in conjunction with a PIN(s), password(s) or other o authenticating token(s) 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 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.

4.1.4.7 [Claims 319-325]

In one form of the foregoing embodiments, the attributes are user-defined, in 0 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 confrol said account(s). In another form, the 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 5 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. In yet another form the attributes are user-determinable, in that the value(s) for an attribute(s) 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 0 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 command(s) is/are received in conjunction with a PLN(s),

or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more constraints. In still another embodiment the advanced asset 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), password(s) or other authenticating token(s) signifying an 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 consfraints 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). In another embodiment, the 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 confrol said account(s) may select and apply one or more of said user-selectable constraints, hi yet another embodiment the 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). 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 and/or 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 consfraints on all or at least a portion of any repository/repositories, and/or content held within or controlled by a repository/repositories, and/or account(s) 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 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 consfraints exists/exist as an integral part(s), or external to, or as integral part(s) of and also external 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 account(s) containing or controlling said content, an attribute(s), a repository/repositories containing an attribute(s), a repository/repositories containing an account(s) containing an attribute(s), an account(s) 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 constraint(s) 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 account(s) containing or controlling said content, an attribute(s), a repository/repositories containing an attribute(s), a repository/repositories containing an account(s) containing an attribute(s), an account(s) 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 constraint(s) 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 constraint(s) constitute a set(s) of rules or controls applicable 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, and/or 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 constraint(s) on an at least one account wherein said constraint(s) 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 constraint(s) 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 consfraint(s) are not less restrictive than the consfraint(s) applicable to the larger inter-networked group of repositories. In still other embodiments, said constraint(s) 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 consfraint(s) are not less restrictive than the consfraint(s) applicable respectively to the larger inter-networked group of repositories or the larger distributed-federated group of repositories, respectively. In still other embodiments, said constraint(s) on a federated group of repositories 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 with which said federated group of repositories interacts, wherein said constraints) are not less restrictive than the consfraint(s) applicable respectively to the larger inter-networked group of repositories or the larger distributed-federated group of repositories, respectively. In yet other embodiments, 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, and/or a larger federated group of repositories with which said repository interacts, wherein said constraint(s) are not less restrictive than the constraint(s) 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 consfraint(s) on at least one account) maybe an extension or augmentation of rules or controls applicable to an inter- networked group ofrepositori.es 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 account(s) interact(s), wherein said constraint(s) are not less restrictive than the consfraint(s) 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 consfraints 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 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 network(s) or some combination of public, private, and/or private- over-public network(s). In each of the foregoing embodiments, one or more clearinghouses may act(s) as an intermediary/intermediaries between said device(s) and said repository/repositories, 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 manipulating one or more constraints, restricting or granting access to a particular communications channel(s) and/or sub-component(s) 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 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 consfraint(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-account(s) is/are the primary account(s) within a particular domain(s). In a further embodiment, the advanced asset management system may comprise one or more primary account(s), 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-account(s), wherein said sub-account(s) 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 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-account(s) is/are related, but subordinate to, said first sub-account(s). In certain forms of each of the foregoing embodiments the advanced asset management system data processor(s) may, if desired, be configured to accept one or more commands to perform the foregoing steps 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) and/or said sub-account(s), respectively. 4.1.4.17 [Claims 589-591]

In a particular preferred embodiment, the token(s) for any account(s) 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 processor(s) may, if desired, be configured to accept one or more commands to perform the foregoing dynamic generation 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).

4.1.4.18 [Claims 592-595]

In another preferred embodiment the advanced asset management system has 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. In additional forms of this embodiment the hierarchies can have: zero, one or more 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 branches.

4.1.4.19 [Claims 596-609]

In a particular embodiment the advanced asset management system may comprise one or more provision(s) 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. In other forms of this particular embodiment the advanced asset management system may comprise one or more provision(s) 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 particular embodiment said one or more sub-accounts may comprise a first sub- account(s) and at least one other sub-account(s) 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 account(s) 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 system may, if desired, be configured to accept one or more commands to perform these step(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, respectively, said bid pool(s), and/or said gaming/gambling pool(s).

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 for one or more accounts. In certain forms of this embodiment the advanced asset management system data processor(s) may, if desired, be configured to accept one or more commands to perform these step(s) to create, implement, modify, deactivate, destroy, evaluate, and/or otherwise manipulate a label(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 confrol said account(s). In another preferred form of this embodiment, the label(s) 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 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 of all allowed attributes that may be contained 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 account(s) is/are located within the domain(s) 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 step(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 domain constraint pools. In other forms of the foregoing embodiments said domain constraint ρool(s) contain(s) an allowed range of values and/or limit(s) for each constraint(s) and/or for each attribute(s) 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), 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 attribute(s) 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), 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 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 constraint(s) 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), 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.

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), 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, or at least a portion(s) of the content of, one or more accounts, to one or more other account(s).

4.1.4.25 [Claims 626] 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), 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 command functions, exercisable by the 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), password(s) or other authenticating token(s), including at least the public 5 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.

4.1.4.27 [Claims 628-633] o 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), 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 5 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), and/or the transfer of one or more accounts to a domain(s) 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 0 foregoing embodiments said transfer includes the transfer of all account(s) subordinate to said transferred account(s).

4.1.4.28 [Claims 634]

In one 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), 5 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.

4.1.4.29 [Claims 635-640]

In other embodiments the advanced asset management system may comprise 0 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 processor(s) may, if desired, be configured to accept one or more commands to perform these steps 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 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 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 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 or by an entity/entities having ownership or confrol 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 token(s) 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, desfroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating one or more virtual labeling systems, list(s) thereof, and/or label(s) thereof, hi 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 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, one or more virtual labeling systems, list(s) thereof, and/or label(s) thereof. In still another embodiment the virtual labeling system comprises data and/or code for permitting access to one or more virtual labeling systems, list(s) thereof, and/or label(s) 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, 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, list(s) thereof, and/or label(s) 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 labeling systems throughout all said repositories with which said system(s) communicate(s). In yet another embodiment, said symbol(s) is/are random in nature. In still another embodiment, said symbol(s) is/are non-random in nature. In still another embodiment, the virtual labeling system may comprise data and/or code for selecting said symbol(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 list(s) thereof; and/or one or more digital signatures or list(s) thereof. In certain forms of the foregoing embodiments the virtual labeling system data processor(s) may, if desired, be configured to accept one or more commands to perform these step(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 virtual labeling systems and/or said list(s) thereof.

4.1.5.5 [Claims 657-663] According to other embodiments of the virtual labeling system, the labeling system(s) 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 system(s) 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 symbol(s) through which the virtual account(s) is/are recognizable by the system, at least one public token that is a symbol(s) through which the virtual account(s) is/are recognizable by the system in communications via one or more of the communications device(s) 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 account(s) and said entity/entities is/are prevented from obtaining the private token(s) via said at least one communications device, and 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.

4.2.1.2 [Claims 665-676]

In certain embodiments of the foregoing general method, the manipulating of the account(s) includes conducting fransactions in which said account(s) 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 asset(s) may be, respectively, a digital asset(s) and/or qualitative information about a digital asset(s) and/or information other than qualitative information about a digital asset(s) and/or a reρresentation(s) of a digital asset(s) and/or qualitative information about a representation(s) of a digital asset(s) and/or information other than qualitative information about a representation(s) of a digital asset(s) and/or a representations) of a non-digital asset(s) and/or qualitative information about a representation(s) of a non-digital asset(s) and/or information other than qualitative information about a representation(s) 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 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 symbol(s) through which the virtual account is recognizable by the system in communications between the system and said entity/entities and, optionally, 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 account(s) and/or one or more sub-accounts thereof accessible, at least in part, via at least said at least one communications device and enables the system to recognize and manipulate 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) while also preventing said entity/entities from obtaining the private token(s) via said at least one communications device. The method includes the step of inputting into said computer, in respect to a given account or account set, asset data that 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. In accordance with the method, said asset data is logically linked to one or more of said tokens that designate(s) 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 account(s) involved, of 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 that 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).

4.2.2.2 [Claims 702-703] In certain embodiments of the transfer method, the asset(s) and/or quantity/quantities and/or representation(s) 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.

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 asset(s) 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 method comprises distribution of assets, including 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. Yet another embodiment of the transfer method comprises exchange of assets, including moving all or at least a portion of the asset(s) and/or quantity/quantities and/or representation^) 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. 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 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. 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 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 account(s) 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 device(s) 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 fransaction 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 cause(s) said clearinghouse system to act as an agent for one or more repositories; 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; 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 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 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 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 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. The method further includes receiving from said entity/entities via said at least one communications device one or more requests that respectively include: a name request, comprising an address(es) of and seeking a name(s) of one or more repositories; and/or an address request, comprising a name(s) of and seeking an address(es) of one or more repositories. The method causes 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). 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.

4.2.4.2 [Claims 750-763]

Included among the embodiments of this method are those in which the list(s) 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, 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] 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 and/or 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 alias(es) differ from any existing public and/or private token(s) of the account(s) to which the alias(es) pertain. Additionally, said software, including data and/or code, can bar 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. 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 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 communicate with such account(s) without knowing the public token(s) for said account(s). 4.2.5.2 [Claims 789-794]

According to other embodiments of the foregoing method, the symbol(s) can be of a random or non-random nature. In another embodiment the method further comprises means for selecting said symbol(s) in a random manner. In other embodiments the method 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 label directories comprising a plurality of published account labels, one or more digital certificates or list(s) thereof, and/or one or more digital signatures or list(s) thereof.

4.2.5.3 [Claims 795-818]

5 Advantages of the Invention

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 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 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 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-fransaction basis. 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 confrol for current asset and fransaction management systems, they fall short of offering the fullness of advantages to be found when combined with a virtual account. 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- 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 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 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. 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 advanced asset management system, transactions have attributes and consfraints independent of the source or target virtual accounts. Thus, a fransaction 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 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., cards, 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 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 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 fransactions, gaming/gambling transactions, and escrow transactions. Additionally, virtual escrow accounts can be used to enhance the security of traditional retail or service fransaction where the buyer lacks confidence in the seller.

One advantage offered by some embodiments are mechanisms allowing for the transfer, fransmittal, receipt, aggregation, distribution, and exchange of cash and 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 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 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 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 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 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 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 attributes and constraints on objects 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 additional embodiments, this invention allows various 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 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 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 fransactions between two or more parties. Virtual clearinghouses can also render tax and fee services, credential and license services, and digital security certificate and digital 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 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 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. 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 fransactions with any desired level of privacy and security.

6 Brief Description of the Drawings

Each of the figures is a schematic diagram more fully described below.

Figure 1 shows a computer system containing a data processor (CPU), 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 (CPU), multiple communications devices, and multiple storage devices, each with an operating system, virtual account management software, and multiple virtual 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 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. 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 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 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 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. 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 multiple subordinate public accounts. 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. 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 28 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. 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 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. 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 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 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 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 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. 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 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. 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 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. 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 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. 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 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. Figure 78 shows a virtual account: multiple public domains, some nested, each with one or more public accounts, and a single shared public/private 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 interfaces. Figure 85 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 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 (CPU), 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 (CPU), 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 device(s) contain(s) an integrated encryption engine, communicating with one or more entities.

Figure 88 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 multiple virtual accounts, wherein said data processors(s) contain(s) an integrated encryption engine, communicating with one or more entities.

Figure 89 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 multiple virtual accounts, wherein said communications device(s) contain(s) an integrated encryption engine, communicating with one or more entities.

Figure 90 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 multiple virtual accounts, wherein said communications device connects to other communications device(s) and entity/entities outside of said computer system.

Figure 91 shows a virtual account repository (referred hereafter as "repository"), containing multiple virtual accounts.

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

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

Figure 94 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 other repositories external to said computer system.

Figure 95 shows a computer system containing at least one data processor (CPU), at least one commumcations 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 (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 repositories through one or more external communications devices.

Figure 97 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 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. 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 within 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. 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 108 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, repository encryption engine, and 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 (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.

Figure 110 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 storage device(s) contain(s) 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) contain(s) an integrated encryption engine.

Figure 112 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 communications device(s) contain(s) an integrated encryption engine.

Figure 113 shows a computer system containing a data processor (CPU), a communications device, and a storage device with an operating system, virtual clearinghouse software, and a virtual clearinghouse (referred hereafter as

"clearinghouse"), used to facilitate virtual account transactions, escrow transactions, bid pools, gaming/gambling pools, and containing tax 8c fee, digital signature, digital certificate, credential & license, and agent services engines (as a group referred hereafter as "clearinghouse components") communicating to fransaction participants. Figure 114 shows a computer system containing multiple data processors

(CPU), multiple commumcations devices, and multiple storage devices, each with an operating system, clearinghouse software, and a clearinghouse with its components, communicating to fransaction participants.

Figure 115 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, clearinghouse software, and one or more clearinghouses each with its components, communicating to fransaction participants.

Figure 116 shows a virtual clearinghouse system acting as in intermediary to transactions within a discrete repository, as well as to transactions wit-hin individual repositories which are members of distributed-federated, distributed, federated, and/or inter-networked groups of repositories. Figure 117 shows a virtual clearinghouse system acting as in intermediary to fransactions between various discrete repositories, as well as distributed-federated, distributed, federated, and inter-networked groups of repositories.

Figure 118 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 ofrepositori.es from and to non- repository entities.

Figure 119 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, 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 (CPU), at least one commumcations device, and at least one storage device with an operating system, clearinghouse software, and one or more clearinghouses, communicating to transaction participants.

Figure 121 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, clearinghouse software, and one or more clearinghouses, wherein said storage device(s) contain(s) an integrated encryption engine, communicating to transaction participants.

Figure 122 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, clearinghouse software, and one or more clearinghouses, wherein said data processors(s) contain(s) an integrated encryption engine, communicating to transaction participants.

Figure 123 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, clearinghouse software, and one or more clearinghouses, wherein said communications device(s) contain(s) an integrated encryption engine, communicating to fransaction participants.

Figure 124 shows a computer system containing a data processor (CPU), 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 list(s) of naming system objects and list(s) 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 (CPU), 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

(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 127 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, and additionally containing a list(s) of object aliases, communicating with one or more entities.

Figure 128 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 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 (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, including a virtual naming system encryption engine, communicating with one or more entities.

Figure 130 shows a computer system containing a dedicated encryption 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 device(s) contain(s) 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) contain(s) an integrated encryption engine.

Figure 133 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 communications device(s) contain(s) 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. 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 (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 (CPU), 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, 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 (CPU), 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. Figure 141 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, 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 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 (CPU), 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.

Figure 143 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, 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 device(s) contain(s) an integrated encryption engine. Figure 144 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, 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 data processors(s) contain(s) an integrated encryption engine. Figure 145 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, 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 commumcations device(s) contain(s) an integrated encryption engine.

Figure 146 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 constraints, communicating with one or more entities.

Figure 147 shows a computer system containing multiple data processors (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 constraints, communicating with one or more entities.

Figure 148 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, asset management software, attribute management software, and accounts with zero, one, or more constraints, communicating with one or more entities.

Figure 149 shows the possible constraints for a generic object from a system having system required consfraints 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 (CPU), 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 consfraints, and/or user-determinable constraints, communicating with one or more entities.

Figure 151 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, asset management software, attribute management software, and accounts with zero, one, or more consfraints, including user-defined constraints, user- selectable consfraints, and/or user-determinable consfraints, including an account/constraint management system encryption engine, communicating with one or more entities. Figure 152 shows a computer system containing a dedicated encryption engine, at least one data processor (CPU), 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 consfraints, and/or user- determinable constraints, communicating with one or more entities.

Figure 153 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, asset management software, attribute management software, and accounts with zero, one, or more consfraints, including/ user-defined constraints, user- selectable consfraints, and/or user-determinable constraints, communicating with one or more entities, wherein said storage device(s) contain(s) an integrated encryption engine.

Figure 154 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, asset management software, attribute management software, and accounts with zero, one, or more consfraints, including user-defined consfraints, user- selectable constraints, and/or user-determinable consfraints, communicating with one or more entities, wherein said data processors(s) contain(s) an integrated encryption engine. Figure 155 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, asset management software, attribute management software, and accounts with zero, one, or more constraints, including user-defined consfraints, user- selectable constraints, and/or user-determinable constraints, communicating with one or more entities, wherein said communications device(s) contain(s) an integrated encryption engine. Figure 156 shows examples of attributes and consfraints for repositories, accounts, and the contents of repositories and accounts.

Figure 157 shows examples of the flow of consfraints 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 consfraints 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 consfraints 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 consfraints from an individual repository downward to: the component parts of a virtual account.

Figure 161 shows examples of the flow of consfraints from a virtual account 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 consfraints 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 consfraints 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 consfraints from the largest set, an inter-networked group ofrepositori.es, to the smallest, an individual account. Figure 165 shows examples of the common fransaction 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 168 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 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 VINs, and labeled subordinate accounts, and a subordinate account domain.

Figure 173 shows an example of a primary account domain containing only 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. 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 consfraints 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 consfraints 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, and the evaluation of consfraints 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 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 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 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, consfraints, and agents, alerts, and triggers, in the creation and operation of a gaming account established to facilitate wagers. 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 consfraints 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 192 shows an example of the flow of assets, consfraints, 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, consfraints, 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, consfraints, 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, 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, consfraints, 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, consfraints, 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. 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 VIN.

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 (CPU), 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, communicating with one or more entities.

Figure 206 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, 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

(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, including a digital certificate engine, communicating with one or more entities. Figure 208 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, 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 (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, including a virtual labeling system encryption engine, communicating with one or more entities.

Figure 210 shows a computer system containing a dedicated encryption 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 (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, wherein said storage devices contain an integrated encryption engine.

Figure 212 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, 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 (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, wherein said communications devices contain an integrated encryption engine.

Figure 214 shows the selection of an attribute and a constraint from the available attributes and consfraints contained within a domain consfrain 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 fransferred 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 fransferred as a child account. Figure 219 shows an example of a subordinate account fransferred between virtual accounts including a change in account type, in this instance a fransferred 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. 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 fransferred between virtual accounts, including all subordinate accounts, as well as a change in account type, in this instance a primary-child pair transfened 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. 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 228, 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 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, 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 (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 communications devices contain an integrated encryption engine.

Figure 235 shows a computer system containing a data processor (CPU), a 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 (CPU), multiple communications devices, and multiple storage devices, each with an 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 contaimng 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 238 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, 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 engine, at least one data processor (CPU), at least one commumcations 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 (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, wherein said storage devices contain an integrated encryption engine.

Figure 241 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, 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. Figure 242 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, hierarchy management software, and accounts with various numbers of hierarchies, communicating with one or more entities, wherein said communications devices contain an integrated encryption engine.

Figure 243 shows a computer system with six modular software subsystems including modules necessary to support functionality for communications, transaction coordination, user interaction, cryptographic processing, records management, and application logic. For each subsystem, commercially available protocols and/or 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. 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 and 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. 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 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 ofrepositori.es, clearinghouses, naming systems, and labeling systems existing in an inter-networked configuration using bridges, routers, and concenfrators for networked communications.

7 General Embodiments

7.1 Overview

The present invention provides systems and methods for the management of cash and/or non-cash asset accounts, and includes associated access, security, and fransaction 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, fraveler's checks, electronic funds fransfer (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: • 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), • 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-fransferable, and/or expiring/non-expiring, or any combination of 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 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 fransaction were inseparable. An AAMS 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 fransaction 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 confrol. Thus, system security can be offered in addition to account level security, regardless of the ownership and confrol of an individual 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 fransaction. However, this approach, by its very nature, is 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 AAMS, 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 fransactions) is the default condition. 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 fransaction 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, 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- accounts, each designed with user-determined and/or 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 for 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 confrol a specific account, any account can take part in a transaction of any type. Additionally, other account types available with predefined sets of features allow for the creation of other specific use accounts, for example escrow accounts and bid accounts facilitating person-to-person commerce. 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 accounts is the ability of hierarchically arranged 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.

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 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, 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 AAMS, 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 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 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 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. 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 fransferred 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 fransaction occurs when one party transfers an asset to another party, with or without a requirement that something of value be given in return. Those fransactions in which assets are offered in return for currency, goods and/or services represent the family of commercial fransactions. Historically, the choice of asset, and of the associated asset management system, limited the fransactions in which an individual could participate. Person-to-person noncommercial fransactions have been typically conducted using cash or checks. Person- to-business (commercial) fransactions have been conducted using a variety of asset types, including credit and debit cards. However, all of these fransactions have the limitation that the asset must physically be fransferred 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 AAMS disposes of this overwhelming limitation by allowing the ownership and control of an asset to be fransferred without requiring the physical fransfer 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, 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 fransaction(s) 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 confrol of the asset, and the ownership or control of the access/delivery method. Thus the system allows for real-time, fransaction-by- fransaction 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 consfraints, which can be independently manipulated by the fransactor.

In one embodiment, the transaction can be elected by the fransactor to be anonymous, identified, or masked, with the fransaction election independent of the ownership or control of the account used in the fransaction. 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 fransaction, as recorded in the target account's transaction history. This allows for some unique combinations of accounts and fransactions. Consider for example, an account having anonymous ownership and control, engaged in an anonymous fransaction 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 fransaction originated, or to where it went.

In particularly preferred embodiments, other consfraints can also be placed on fransactions at the discretion of the fransactor. These consfraints 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 consfraints can be preset for all fransactions, for a particular type of transaction (e.g., a purchase at a registered merchant), or for a particular account. Alternately, they can be dynamically determined before or during a fransaction. 7.2 System Elements

In certain embodiments, the system elements of this invention relate to specific types of attributes and consfraints incorporated into fraditional 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 AAMS, virtual accounts offer certain advantages over fraditional 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, fraditional accounts when incorporated as part of an AAMS that are readily apparent to those skilled in the art. 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 called the public/private account connection interface (PPACI). Through this oneway 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 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 AAMS 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. 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 fransaction. 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. A VIN is used to associate a transaction(s) with a particular public account(s) 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, under the control of an end-user. Thus, the virtual account 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 AAMS. 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 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 fransaction 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 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 account(s) 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. 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 own 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 account(s)

Cargo bay = Public portion

Package = Public account(s) A package in the back of the truck exists as a conditionally independent entity, just like the public account(s) 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 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 account(s) can confrol its/their subordinate account(s).

7.3.2 Account Creation

Most preferred embodiments of the AAMS share common steps with regard to creating accounts, with differences dependent on whether the account is a fraditional account or a virtual account. Traditional accounts even when enhanced with certain features found in various embodiments in this invention, are 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 adminisfrators 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 AAMS systems administrators. For those embodiments in which zero private accounts are used, the private token(s) 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 fransfer 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:

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:

10 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 membership in a particular domain. For both primary and subordinate accounts, the AAMS then completes their creation by performing the following steps, as necessary:

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 AAMS 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 confrol of a particular account. Thus, even if a fransaction were traced back to its source, and the account uniquely identified, the ownership or confrol of that account would remain anonymous.

In most preferred embodiments, ownership and control of any private accounts and their VANs (the private token(s) 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 VIN) 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 standard 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 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 account(s) 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 public account, or other variations wherein a private account(s) has/have 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 public/private account interface, particularly when the concept of domains is introduced. For the public accounts of an AAMS, 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 internal to a single virtual account or between multiple virtual accounts.

Independent of both the ownership and confrol 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 Relationship to Target Relationship to Source

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 class(es) of account(s) 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 fransaction is given, although the occurrence of a transaction can be inferred from changes to the contents, attributes, or consfraints of an account

• Identified or masked relationships: a fransaction is referred to as originating from an "anonymous" account, e.g., "$100 was added to your account from an anonymous source" Identified account:

• Masked relationship: a transaction is referred to as originating from "an account masked as XXXX", where XXXX is the number or label used to mask the account, e.g., "$100 was added to your account from an account masked as XXXX"

• 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 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, although the occurrence of a transaction can be inferred from changes to the contents, attributes, or consfraints of an account • Masked relationship: a fransaction is referred to as originating from "an account masked as XXXX", where XXXX 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 confrol 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 "XXXX" where "XXXX" is new the transaction specific token • Identified relationship: a transaction is refened 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 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 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 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 confrol of the account, for the content of an account, for the connections that the account makes, for its fransactions, for its fransaction history, and for other end-user and system specified objects. For each particular object, the account owner can designate an extent of information release ranging from none to complete disclosure.

A trivial example is relationships, wherein an identified account can be 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 AAMS 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, 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.

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 accounts bound within a particular domain(s) can be established by the AAMS, 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: Number of Domains Domain Tvpe Allowed Account Tvoes

One Inclusive All

Multiple 1-nclusive All

One Private Private

Multiple Private Private

One Public Public

Multiple Public Public

Note: use of a particular domain type(s) does not preclude the simultaneous use of another domain type(s) 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 pubhc 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 object whose purpose is to allow command and confrol activities on a "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 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 domain(s) selected, one account within a domain should be designated as the domain controller. The domain controller account is allowed to confrol the operations and operational configuration(s) of accounts within its domain. For those instances wherein the domains are nested (e.g., one domain completely contained internal to a larger domain), the domain controller of a higher level domain can exercise confrol 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- 5 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 o 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 encrypted decrypted prior to its transmission, storage, and/or processing. In certain particular forms of these embodiments, multiple layers of encryption, e.g., stored 0 encrypted data that is encrypted a second time during transmission, are also supported. AAMS 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 5 AAMS computer system, or may be included within one or more of its various subsystems, such as its data processor(s), storage device(s), communications device(s) 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 0 systems.

The AAMS data encrypted can be all inclusive or, more often, specifically applied to particular subject matter or objects within the system, e.g., account 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 AAMS 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 within 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 fransactions. 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 confrol 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. The rules and confrols for subordinate accounts are preferably inherited automatically from the parent's account upon creation of the child account. Inherited rules and controls provide a skeleton for the attributes, consfraints, 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 confrols "as is" or modify them in any way the parent sees fit, including adding rules and confrols. Should the ownership or confrol of the subordinate account later be fransferred to another person or entity, the transferee can modify the rules and controls, and/or can add new rules and controls to the consfraint 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 consfraints: 1) that the account has an outbound cash fransaction limit of $50 per day, and 2) that the account's outbound transfers are restricted to US dollars. These consfraints: • Only pertain to cash fransactions

• Only cover transactions that are outbound, and does not place any constraints on in-bound fransactions

• Specifies that the total amount of all outbound cash fransactions, including all purchases, transfers, etc., can not exceed $50 daily • Does not specify a maximum or minimum fransaction 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 fransferred to another person or entity, who attempts to impose a spending limit of $400 per week on the transferred account. Various embodiments of the AAMS allow for different configurations of the internal consfraint engine. Thus, depending on the programming of the consfraint 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 consfraints could be imposed, with the outcome that the second consfraint could never be reached since the initial constraint ($50/day) yields a maximum possible weekly spending limit of only $350.

In the second instance, the AAMS could alternately be configured to review consfraints 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 consfraints contain the following identical dimensions: 1) content (US 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 consfraint. As a result the system would determine that the second consfraint is less restrictive than the inherited constraint (a $400/week limit vs. the maximum possible limit of $350/week) and thus, reject 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 confrols added by the first subordinate account owner, are in turn inherited by its subordinate accounts. The combined set of rules and confrols subsequently inherited by these "grandchild" accounts represent maximum values that cannot be surpassed, although more restrictive rules and confrols 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 confrols 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 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 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 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 fransferred from the parent account to the child accounts. An AAMS can, if desired, be configured and established such that child accounts have one-time, sporadic, or automated asset transfers. 7.3.9.2 Peer Accounts

Primary and subordinate accounts within certain embodiments of the AAMS 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 fransactions 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 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 confrols 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 place more restrictive rules and controls on its own account or on any child account(s) 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 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 the AAMS overcome this limitation by allowing the creation of same-party escrow accounts to facilitate the fransfer of assets. These and other embodiments can also be configured for third-party escrow fransactions.

An escrow account within an AAMS will ordinarily require the creation and maintenance of at least two unique authenticating tokens, one for a first party, and at least one other authenticating token for a second party to the transaction. Use or emplacement of the second authenticating token causes the AAMS to restrict access to and manipulation of the escrow account by any party, regardless of account 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 fransaction.

Virtual escrow accounts can be created to accommodate fransactions 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 multi-party locks on the escrow accounts.

In addition to the placement of multi-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 consfraints are: delivery date, acceptance date, rejection/return date, expiration date, shipping ticket confirmation, and certification of goods/services.

Thus, in a typical scenario, two parties wishing to conduct a fransaction will first agree to a set of conditions, implemented through incorporation of a specific set of attribμtes and consfraints 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 authenticating token on the account and transfers confrol 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 further manipulation until the agreed terms are met, until such time as they expire, or through the cancellation of the escrow 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 fransferred 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 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. 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 I.O.U. Additionally, escrow/obligation accounts may require that the receiver meet certain preset criteria prior to the fransfer 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. 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 specific government accounts only as needed, and automatically transferring them as appropriate, based on attributes and consfraints 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 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 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 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 not 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 fransactions, 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 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 AAMS, 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 accounts without undue end-user input. Additionally, use of escrow/reserve accounts for reserve fransactions can be automated, such that any time an account is to partake in such a fransaction, an escrow reserve account is created, and funded with the amount appropriate for that particular transaction.

no 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 fransaction), an escrow/credit account simply guarantees that the assets are available in the quantity required to complete the transaction. Based on certain consfraints established by the parties to the fransaction, and the acceptance of the transaction by all parties concerned, the AAMS, at the appropriate time, automatically transfers the requisite assets into the escrow/credit account from the designated source(s) for 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 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 fransaction 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 fransaction. Bid accounts are 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 consfraints include: current bid price, maximum allowed bid price, bid price increase/decrease increment, and bid account life span. 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 for permission to raise or lower a bid. Bid accounts can be secured by dynamically created escrows or obligations than insure that a bidder(s) is/are sincerely intending to settle the offer placed if their bid(s) is/are deemed a winner.

Bid accounts work in conjunction with a bid pool. A request account establishes the constraints required for fransactions 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 fransaction 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. Additionally, the bid pool manages the creation of alerts, agents, and triggers, coordinated with the consfraint 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 maximum/minimum 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 several bidders to several items. It is also possible to create embodiments in which the type of asset(s) offered to pay for the bid can be a determining factor in the acceptance of the bid. With this facility, barter fransactions 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 bid/bid 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 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 consfraints, 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 AAMS offers a predefined class of accounts 5 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 o 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 I.O.U., or 5 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 fransactions 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 0 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 arrives, 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. 0 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 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 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 notification/confirmation of receipt and/or 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 in transactions and other operations. Proxy accounts can be created for any class of virtual account, including other proxy accounts.

In a fransaction 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 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 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. hi 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 account(s) 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 fransaction, set of fransactions, 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 task(s) that require an interface to 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 for each distribution.

A second example involves the use of a dynamic proxy account for performing a purchase fransaction 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 confrols another virtual account. The buyer and seller have come to 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 fransaction.

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- 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 fransaction, the host system sends a challenge to the access device, which must respond with the correct response before the fransaction is authorized. In most typical 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 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 with the local cable, electric, and phone companies to provide consolidated account transaction histories for all clients. Every outbound transaction from the bank is 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 5 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 fransfer from the bank in a sum o 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 Modifications

Accounts and sub-accounts, particularly those based on virtual accounts, once initially configured, are not limited to a single permanent configuration. Rather, 0 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 5 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 confrol of the account may pass to another individual and the frequent flyer number attribute deleted. 0 Virtual accounts and sub-accounts can have constraints which are dynamically managed. For example, a consfraint 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 consfraint 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 consfraints, 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 constraints which may limit changes due to inheritance conflict, a condition where consfraints 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 fransfer 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, 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 consfraint 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 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 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 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 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 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 entity/entities authorized to perform actions on or to this account. Depending on the type of content contained, additional actions may be available, included user-defined actions. 7.6.2 Content Security

Accounts within an AAMS offer a number of advantages over fraditional financial instruments in terms of their ability to protect the content of their accounts. Most preferred embodiments offer two separate protection mechanisms: account and content level constraints, and account and content level encryption (including consfraint 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 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 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 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 fransfer the credential, authenticate the credential, or perform 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 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, 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, 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 prefened embodiments. The representation may be a 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, 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 confrol 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 cunency participates in the purchase of an item costing US$20. If the seller also has a virtual account, the ownership and confrol of US$20 of the US$50 is simply changed to point to the second account. The account records for the fransaction will show a debit of the first accoimt 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: cunencies and non- currencies. Cunencies are further categorized as national, multi-national, and private cunencies. Examples of national cunencies include US dollars, British pounds, and Japanese Yen. The Euro is an example of a multi-national cunency. In some countries, such as China (in particular, Hong Kong), cunency 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 government. In the 19^th century, private cunencies flourished in US, and even today, there are no prohibitions in the US against the printing or use of private cunencies.

Non-cuxrency 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 still have worth such as coupons, software licenses, subscriptions, credentials, government issued licenses, security keys, and incentive points like frequent flyer miles. Possession and confrol of the asset, i.e., the ability to use, is the key differentiator for items without intrinsic value.

Examples of non-cunency assets that are quantifiable and have intrinsic value include event tickets, entitlements, phone minutes, and securities such as stocks, bonds, futures, and options contracts. Examples of non-cunency 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 cunencies that are not pegged or exchangeable with any publicly recognized cunency.

Examples of non-cunency assets that are not quantifiable but have intrinsic value include deeds, titles, memberships, insurance policies, annuities, and perpetuities.

Examples of non-cunency assets that are not quantifiable and have no intrinsic 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 confracting, government issued, non-government issued, and other information. Confracting 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 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 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 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. I-n 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 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 cunency conversions from US dollars to Euros, Pounds, Yen, or any other cunency. It can also be used to convert cunencies and non-cunencies. For example, currency can be converted into telephone minutes, or frequent flyer miles exchanged for transit tokens. 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 fransactions 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 fransaction 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 Quantifiable assets held in virtual accounts, whether tangible like cunency 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 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 removed from virtual accounts.

Accounts also can be configured such that only certain kinds of assets are allowed. These limits can be applied to cunencies, national cunencies, 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 such that certain cunencies 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 AAMS can be configured so that a single system could contain all known accounts, this represents only one possible alternative. In certain prefened 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 confrol 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 intermediary communications device(s) which permit(s) an account owner to conduct fransactions without a direct connection to a repository.

A repository governs the operations and fransactions of the accounts within it. Likewise, the accounts are "members" of a particular repository, and inherit some minimum attributes, consfraints, and other rules and controls, as applicable, depending on account type. In a prefened embodiment virtual accounts can add or otherwise modify rules and controls inherited from a repository, but they can not make the rules and confrols less restrictive.

7.7.1 Repository Content hi several prefened embodiments repositories are not restricted to containing 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 confrol 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. Additionally, repositories can contain profiles and other analytical structures which 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 confrol 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 cunency 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 fransactions. 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 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 conesponding activities. They can be used in either an identified or anonymous fashion to target advertising and forward offers to qualified accounts for specific coupons or discounts. For example, an anonymous profile might track the average daily balance, cunent 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 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 cunent account status to check balances, adjust account features (e.g., constraints), or account structure (e.g., establishing or desfroying 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 cunent 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 confrols, 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, hi such an example, a visitor with a account held in Caesar's Atlantic City repository could 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 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. 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 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

5 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 fransaction from any of the members. o 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 5 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 0 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 5 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; 0 • 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 connection(s) established between two or more repositories must traverse the same path as their first communications comiection route;

• connection(s) 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, fransfer, manage, and manipulate assets and asset information at any property. 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 AAMS. Repositories, as a unifying 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 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 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.

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 fransactions. Clearinghouse fransactions allow virtual accounts to safely interact with other virtual accounts, regardless of repository location or type, and support 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 fransfer and settlement systems, the Automated Clearing House (ACH) and other similar financial systems. A clearinghouse can if desired facilitate fransactions in which the transactions take place between virtual accounts in the same repository and/or in which the fransactions are between a physical device(s) and an account(s) within a repository. Clearinghouses can also facilitate fransactions between multiple physical devices in which the physical devices are operating as stand-alone virtual accounts.

Clearinghouses may have pre-established and/or dedicated communications 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). Clearinghouses can if desired be used to improve financial fransaction 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, fransfer, and funds reservation. A clearinghouse can facilitate any account manipulation fransaction supported by a repository, including for example activation, authentication, creation, deactivation, destruction, evaluation, generation, implementation, maintenance, modification, processing, or registration. This may include fransactions that require performance of aggregations, distributions, conversions, and/or exchanges. 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 fransaction 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 fransaction and actually becomes an integral part of the fransaction. 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 fransactions 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 fransactions 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 fransactions between repositories and various devices connected either directly or indirectly to the clearinghouse. Like the repositories, 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 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 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 notification of a change in the conditions. A typical example might be a person-to- person commerce fransaction 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 fransactions 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 fransaction 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 fransaction. For 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 offerer would have the option to contact the remaining bidders, in order, and try to complete their fransaction.

For many-to-many fransactions, bid pools can organize, sort, and determine 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 gaming/gambling services. A gaming/gambling transaction holds a conditional obligation to pay based upon successful transaction settlement after resolution of a wager. Gaming/gambling fransactions may also optionally be guaranteed by an escrow account. The clearinghouse holds gaming/gambling fransactions until settlement and resolves winning and losing wagers. Like bid pools, clearinghouses also offer gaming/gambling pools. Using a gaming/gambling pool, wagers and associated gaming/gambling 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 fransactions, 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 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 fransfer of collected sales taxes from tax escrow accounts to the 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 prefened embodiment, a clearinghouse can collect taxes and fees on fransactions. Each fransaction 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 fransactions include the collection of a renewal fee on the registration of a motor vehicle, and the explicit capture and collection (including calculation) of tax amounts as identified by the retailer for 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 fransaction to determine appropriate taxes and fees, add them to the fransaction 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 fransaction for retail goods, taking into account the location of the purchaser, the cunent 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 prefened 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 fransaction 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 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 fransactions between the accounts of the issuer and vehicle owner.

The identification of target accounts (even across entire groups of repositories) 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 fransactions 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 transfened, a clearinghouse can automatically 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 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 fransaction participant using a digital certificate(s) without exposing or sharing that identity with the other transacting party/parties. This can be used to facilitate auditing of fransactions and inevocable 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 transfened 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 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 refened to as a message digest, which is typically a 160-bit string of digits that is unique to the original message. The 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 fransactions. 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 fransactions and inevocable binding contracts without sacrificing the anonymity of fransaction 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 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 fransmission, 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 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, and/or conesponding aliases, with a digital certificate. In this manner, the digital certificate can be referenced in a fransaction 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 fransaction 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 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. 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 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 prefened 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, desfroying, evaluating, generating, implementing, maintaining, modifying, processing, registering, and/or otherwise manipulating a list(s) of one or more system or device ownership certificates. Using this mechanism, the naming 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, 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 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, 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 conesponding information. Similar to a DNS, a naming system can automatically propagate entries and conesponding 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.

7.9.4 Naming System Encryption & Security fti 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, 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 for those tokens. The labeling system creates a list(s) 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 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 account token in fransactions with a repository. When aliases are 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 conesponding aliases, with digital certificates or digital signatures. In this manner, a digital certificate or digital signature can be referenced in a fransaction to automatically lookup the underlying VIN or alias. Alternately, the validity of a VIN, of another account token, or an alias for use in a particular fransaction 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 fransaction participation information; and the inclusion of multiple layers of aliases that can substitute for any portion of the underlying information, ha particular, a virtual labeling system provides an additional layer of indirection for the manipulation and reporting of an underlying account's 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 descriptive information associated with the label, or conesponding 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. 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 objects, 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 requestor, but confrol 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 and/or digital signatures such that a change might require a specialized authenticating token such as a fingerprint or other biometric scan.

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 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 conditions set up within the label generator, without revealing whether a label is cuπently 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 function(s) or computerized algorithm(s). Alternately, a random number generator can be used as an integral part of the label generation mathematical function(s) 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 mechanisms, such as First h , 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 function(s) 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.

7.10.2 Account Identification & Directories

In prefened embodiments, a labeling system can be used by inquirers to search for an appropriate VIN, and where necessary, repository fransaction 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, 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 outbound fransfers (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 labels, to name a few. 7.10.3 Digital Certificates & Digital Signatures

In other prefened embodiments, a labeling system can participate in electronic commerce activities by verifying the identities of the fransaction participants using digital certificates and digital signatures. Using these objects, the labeling system can facilitate electronic confracts. 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 fransacting 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 confirming the identity/identities of a fransacting 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. 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 revocation list, and has no direct confractual 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 for authenticity and confirmed as valid and not expired.

In certain fransactions, 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 prefened 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 fransaction 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 conesponding 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. 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 cunent 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 repository and/or clearinghouse. In this instance, the labeling system is eliminated as an independent system, and becomes a subsystem of the repository and/or clearinghouse. In other implementation, the labeling system may be co-located on the same computer system which simultaneously houses a repository and/or clearinghouse. 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 communication channel to the labeling service, speeding processing time. When both the labeling system and the repository and/or 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 Labeling 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- 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 multi-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 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 fransacting 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. 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 pubhc 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 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 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 for customer self- service access and information distribution. The advantages of public communications networks are easy access from many locations, standard communication protocols, and distributed confrols without any cenfral 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-Over-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 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, cash registers, billing systems, collection systems, banking systems, government 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, elecfronic wallets, memory sticks, and secure device memory cards (SDMC)

Closed system devices include private buying networks, micropayment systems, digitized cash, and elecfronic coins. Other external system devices include the banking system, the interbank fransfer system (such as S.W.I.F.T.), private wire services (such as MoneyGram and Western Union), the Federal Reserve and other cenfral banking systems (such as FedWire), credit card networks (such as AmEx, Visa, MasterCard, Discover/Novus, and DinersClub), and the Automated Clearing House networks (for processing of paper and elecfronic 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 prefened embodiments, account and system owners can place constraints on both access methods and access devices. Like consfraints in general, access method consfraints 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 objects, 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 system and/or device, and/or a particular type of fransaction. 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 consfraints might be invoked such that:

• the ATM can only communicate through a private network, i.e., other systems will 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, concenfrators, 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 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. 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, 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). hi 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 numerical ratings that facilitate quantitative comparisons. Metrics may be based upon simple counts, complex formulas, grades, or flow rates. Most metrics describe the 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 cunent price of a security in dollars per share.

This invention includes both general and special attributes in two classes of 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 fransactions 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 are listed in the table below.

Referring 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 confrol 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 accoimt, or the locations in which 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 As expressed in several embodiments, the cunent invention allows for advanced end-user confrol of the attributes of their accounts, the content of their accounts, and their fransactions, both in fraditional 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 fransaction total

• Running weekly fransaction 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 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 cunent amount spent, by month, in thousands of US dollars. Expanding on the preceding example:

• Running fransaction total . . . by day or by week

Peak fransaction total . . . by day or by week

• Peak fransaction total . . . by merchant or by fransaction type

Thus, instead of being restricted to the menu of the cafeteria, user-determined attributes allow an account owner the ability to confrol 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 confrol over the constitution of the attribute to the account owner. Whatever information the system can frack 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 fransactions, 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 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- actively manage their accounts.

With these newfound attribute types, end-users can for the first time grade their systems by the information that they can frack, 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 cunencies 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 conective 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. 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 cunencies, and a list(s) of acceptable exchange mechanisms and reporting requirements by country.

7.13 Constraints A consfraint 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 consfraint. 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 consfraints are less obvious but of a 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 objects, 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 without a working speedometer, the driver of which could still be given a ticket if caught speeding. A consfraint may be enforceable but enoneous 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 consfraint 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 cases, the constraints described are not the trivial consfraints 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 fransactions with these assets.

7.13.1 Traditional Asset Management System Constraints Present-day financial systems and their concomitant financial media have minimal consfraint 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 and a different daily purchase limit when used through the credit card network. Both of these consfraints are typically set as system limitations that apply to all accounts of the same type, and often cannot be overridden even by customer service representatives.

Additional constraints may be placed because of requirements for a specific equipment infrastructure that must be established to facilitate merchant participation, h some cases, consfraints may exist as a result of policies, regulations or laws such as the limitation of a single personal loan outstanding against a 40 IK 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. These consfraints 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 fransaction 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, conespondingly saving both the time and trouble associated with reviewing possible fraudulent fransactions, 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 Consfraints, 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 consfraints 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, as they determine their own individual level of comfort with the risks inherent in conducting fransactions in which assets and information must be exchanged.

These consfraints are not restricted to the static IF-THEN-ELSE logic of fraditional software systems, but can be dynamically constructed and evaluated using data instead of just coded rules. Additionally, they can be incorporated into individual objects within the systems themselves, enabling the consfraints to fravel system to system with the objects that they impact.

User-selected consfraints 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 system adminisfrators, account owners have the option of which consfraints 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 consfraint, among the group of constraints provided by the system.

User-determined consfraints, a second, more flexible and comprehensive type of consfraints covered in several embodiments, allow account holders to determine specific values for the consfraints 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 consfraints. Systems offering user-defined consfraints afford sole control over the constitution of the consfraints to the account owner. Expanding again on the previous example, an account holder could implement a user-defined consfraint 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 contents and assets within, to suit their needs. They can also limit use of and access to their accounts in ways not offered in fraditional systems. For the first time, they can pro-actively manage their accounts, allowing them to confrol the level of risk.

7.13.3 Hierarchies of Constraints

In certain embodiments, consfraints can be applied to objects in a hierarchical, layered fashion. In these cases, a consfraint applied to a superior object would be inherited by every subordinate object beneath it. In one example a consfraint imposed on a repository would be inherited by every account in that repository. A consfraint 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 consfraint would 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 consfraints 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 member of a larger group of repositories must abide by any consfraints 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 consfraints, plus any new or more restrictive consfraints from the distributed-federated group, plus any new or more restrictive consfraints from its federation. Likewise an individual account within this repository would inherit all of these consfraints, plus any new or more restrictive consfraints imposed by its repository.

Consfraints 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 consfraint 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. individual repositories can define additional constraints to further restrict activities of accounts contained in the repository. For example, a repository may define a consfraint that limits the type of cunency assets that can be stored in accounts or that restricts the maximum amount of an individual fransaction.

Each account can have its own consfraints, with virtual accounts offering a greater degree of granularity than other fraditional account types. Virtual account consfraints can apply to the virtual account overall, and be inherited by every public and private sub-account of the virtual account, or it consfraints can be applied to groups or classes of sub-accounts accounts including primary accounts. Consfraints can be applied separately to both private and public accounts. An account owner who confrols an individual account can, to the extent the system configuration allows, add or subtract consfraints from the account at will.

Account consfraints 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, consfraints on an account that limit the geographic region where the account may be used, restrict the types of merchants accepted for fransactions, or cap the dollar amount of fransactions 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. Consfraints can be applied to such pools of accounts regardless of the relationships of accounts in the pools to each other. For example, a virtual account with a large hierarchical free 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 consfraints 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 consfraint would be a consfraint restricting withdrawals from accounts deemed to hold savings, such as a child's college fund.

Consfraints can also be created on specific content held inside a virtual 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. Cunency can be constrained, for example, such that it cannot be exchanged for certain other cunencies. Securities may be constrained, for example, to be restricted from sale during a company quiet period.

7.13.4 Collections

Embodiments in which consfraints exist in various levels of objects, or in some hierarchy, are typically collected in a top-down fashion starting with the topmost set of consfraints. First the consfraints of the inter-network (if any) are collected. Then any additional consfraints are collected from the distributed and federated group and so on through the hierarchy. As each consfraint is collected it is combined with any already collected constraints using a mathematical union set operation.

7.13.5 Contradictory Constraint Resolution In most prefened embodiments, constraints that are more restrictive than existing constraints are allowed, but constraints that are less restrictive are invalid. For example, a first consfraint is collected that indicates that the maximum purchase transaction amount is US$10,000 for the repository. At the account level, a consfraint exists which indicates that the maximum purchase fransaction 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 consfraint on the maximum purchase fransaction 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 consfraint for a maximum purchase transaction amount of US$7,500, it would be an invalid consfraint 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 consfraints may exist, but cannot be enforced. Within certain embodiments unenforceable consfraints are considered invalid and are disabled. Consider consfraints added at different dates. If a newer consfraint would cause other 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 would be in violation. Depending on the system configuration the consfraint may be completely invalid and disallowed, may be disabled until the violation comes into compliance, or may be imposed on all accounts which are cuπently in compliance, but not imposed on out of compliant accounts until such time as they come into compliance.

7.13.6 Deferred Constraints

Consfraints may be created that might be invalid if they were immediately enforced, but can be created for defened 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 consfraint violation. For example, an account with a cunent balance of US$18,000 is subject to a defened consfraint specifying a maximum cunent balance of US$10,000. Upon arrival of the specified date, the account owner would have to transfer or otherwise reduce funds to comply with the new constraint prior to commencing other account activity.

7.13.7 Boolean Operators and Precedence

Consfraints may be simple expressions that can be evaluated with a simple IF- 5 THEN test condition or more complex expressions that require two or more constraints to be combined together at the time of evaluation. Complex consfraints 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 if both inputs are true. An OR is a Boolean o 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 consfraints that are interpreted differently depending on the Boolean logic operators. The first constraint is that the 5 purchase transaction amount not exceed US$500. The second consfraint is that the purchase fransaction 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:

The NOT Boolean operator can be used to invert any condition, such as:

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

Parenthesis and other grouping and precedence operations can be nested several times to create very complex conditions.

7.13.8 Integral Constraints

Consfraints can be integral parts of objects, such as repositories, accounts, content, or attributes. These built-in consfraints are parts of the object's structure. Integral consfraints can be processed internally to determine validity and address activity that applies to defened consfraints. When consfraints are evaluated at runtime in response to a fransaction, agent, alert, or trigger, the evaluation engine can be internal to the object being evaluated. Integral constraint engines are the prefened solution because they are tightly integrated with the storage of the data. 7.13.9 External Constraints

Consfraints can be stored, processed, and evaluated external to repositories, accounts, content, or attributes they reference. These external constraints may be part of an independent consfraint engine. External consfraints can be processed externally to determine validity and address activity that applies to defened consfraints. When consfraints are evaluated at run-time in response to a fransaction, agent, alert, or trigger the evaluation engine can be external to the object being evaluated.

Some consfraints, particularly those related to proxy accounts for which a connection to an external system is required, cannot even be tested for validity until the consfraint is evaluated. In this case, the processing and evaluation can occur simultaneously.

External constraint engines are prefened when some or all of the data necessary to evaluate a consfraint resides external to the object being evaluated. For example, when processing an interaction with a proxy account interfaced to a credit card network, the consfraint 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 consfraints. For example, a proxy account for a credit card may have integral consfraints that limit the maximum purchase transaction amount and limit the valid list of merchants as well as an external set of consfraints that include a fraud detection filter consfraint 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 consfraint.

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 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 consfraints requiring that they not be separately transfened, the consfraints must be able to survive a change in the ownership and confrol of the asset or the account. This will be of use in enforcing securities trading laws and securing documents that retain their carried consfraints despite changes in ownership and confrol.

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 consfraints 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 consfraints that cannot be overcome.

7.14 Agents, Alerts & Triggers In prefened embodiments, agents, alerts and triggers are available to all systems, and to certain objects 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 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 fransaction 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 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 fransaction, 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 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 sfream 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 arrive 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 updating would be the replacement of a due-in notification (indicating the imminent arrival of previously ordered items) by an arrival notification (indicating actual receipt of the items). Another example might be a notification of a cunent 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 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 occuπed, 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 subcomponents 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 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 fransaction which violates a constraint condition, or a potential security violation.

A VCHS alert typically would indicate an attempt to commence or complete a fransaction; an attempt to initiate or close contact with a repository, with a labeling system, with a naming system or with another clearinghouse; or the occunence of fransactional activity, bid or bid pool activity, or wager or gambling/gaming pool 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 alias, an attempt to improperly access a label or alias, a change in status of a digital 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, cunency, commodity, or futures markets.

Proxy accounts and the fransactions they interact with can be a frequent source of alerts. Proxy alerts often state the cunent 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, fransaction approval/denial, establishment of holds on funds, and changes in account status or ownership.

External systems may provide alerts that establish a sfream of data such as 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.I.F.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 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 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 propagation that moves account, repository, or clearinghouse alerts directly to an account management device. Some external systems such as cunency 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 realtime 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, 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 networks. Most often when fravelling over external or public networks, the alert will take the form of a packet-based commumcation 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 cunent proprietary protocols. 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. 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 account(s) 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 fransactions.

Other useful triggers include those that automatically respond to conditions 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 fransactions. 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 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 condition(s) that include(s) 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. 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. 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 fransfer 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 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 detection of specific kinds or types of alerts such as an overdraft, fransaction 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 (e.g., market open, 10AM, midnight), at specific dates (e.g., January 1^st, April 15^th, December 25^th), 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 different fonns. 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 consfraints 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 fransaction 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 fransaction 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 fransactions.

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 subcomponents 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 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 confrols 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 confracts, bartering for goods and services, finding the best odds for a gambling/gaming wager, and automating the placing of wagers. 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 fransactions. Agents can use alerts to request authority to proceed with specific lines of inquiry, negotiations, or fransactions.

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 fransactions 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 confrols 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, 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 cunency exchange services for the lowest conversion rates, interacting with external systems such as credit card systems to coordinate batch settlement processes, evaluating escrow conditions, and automating the release of held funds when a hold has expired.

Naming systems may 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.

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.

8 Specific Embodiments

Certain unique features and advantages afforded by advanced asset management systems and virtual account-based systems are most readily understood when multiple embodiments are considered together. A first set of embodiments involves the advantages afforded by this invention to seven basic pricing mechanisms and attendant fransfers 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 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 of the fransaction, while a fraditional account (e.g., checking, savings, loan, credit card) 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., cunency, frequent flyer miles, tickets, and subscriptions), digital goods (e.g., digital music, video, and 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 fransfer 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 inevocable 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 fransfers, or some sort of C.O.D. anangement, 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 will a valid credit/debit 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 fransfers 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 their accounts for use in a particular fransaction, or to create elecfronic 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 cunent credit limit has been reached, can still participate in these systems.

Additionally, a number of patents assert that they allow anonymous fransactions for one or more participants. As has been documented earlier however, these claims are misleading. At best, prior inventions afford only conditional, oneway anonymity, i.e., fransaction participants must identify themselves to the system, although that identification may be masked during a fransaction. 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-One 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 fransactions, 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 fransaction may be coordinated by an agent or take place in a marketplace. Barter transactions can also 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 fransaction allows buyers and sellers to negotiate the criteria for an exchange and then consummate the deal. The fransaction 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 fransactions with individual buyers. Optionally, the buyer and seller may agree to use an escrow account to coordinate the appropriate settlement of the fransaction. The escrow account may be managed by either the buyer or the seller, or by a third party escrow service.

Barter fransactions 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 • 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 transfened 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 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 transfened between the two accounts

• Seller offers a new late-model sedan with full dealer wananty which the buyer barters for the exchange of a used vehicle plus fifteen-thousand US dollars; they agree on delivery aπangements and the assets are transfened 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 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 • 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 8.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 fransactions, 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 fransaction may be coordinated by an agent or take place in a marketplace.

Haggle fransactions 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 for an exchange and then consummate the deal. The fransaction 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 fransactions with individual buyers. Optionally, the buyer and seller may agree to use an escrow account to coordinate the appropriate settlement of the fransaction. The escrow account may be managed by either the buyer or the seller, or by a third party escrow service.

Haggle fransactions using virtual accounts may take many forms, including these examples: • 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 sunound-sound speakers and a ten percent off coupon which reduces the purchase price by one hundred and fifty US dollars • 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 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 transfened 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 transfened between the two accounts

• Seller offers a new late-model sedan with full dealer wananty for twenty thousand US dollars; the buyer haggles the price down to eighteen thousand US dollars plus an upgrade to the stereo system; they agree on delivery anangements and the assets are transfened 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 transfened between accounts, and a schedule is agreed upon 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 ananged using an obligation account with 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

8.1.3 One-to-Many (and Many-to-One)

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.

8.1.3.1 Fixed Price

Fixed price fransactions represent the typical retail fransactions 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 fransactions include offers by sellers to supply goods or services under terms determined by the seller, which may include such factors as volume and delivery commitments.

Using virtual accounts, fixed price fransactions can be executed wherein assets and cunencies are exchanged to complete a purchase between a buyer and seller. A virtual account fixed price fransaction allows the buyer to conduct the purchase transaction and then consummate the deal. The fransaction 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 of vendors (sellers) who advertise their goods and then enter into specific fixed price fransactions with individual buyers. Optionally, a buyer and a 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.

Fixed price fransactions 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 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 fransfer between the buyer's and seller's accounts, and the goods are delivered • 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 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 hundred US dollars which the buyer agrees to purchase at the stated price; the assets are transfened 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 transfened between the two accounts

• Seller offers a new late-model sedan with full dealer wananty for twenty thousand US dollars, which the buyer accepts; they agree on anangements for delivery, and the assets are transfened 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 transfened 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 ananged using an obligation account with multiple escrows, one for each milestone • 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 Auction fransactions 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 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. Auction fransactions can be executed using virtual accounts to exchange assets and complete a purchase between a buyer and seller. A virtual account auction fransaction allows the buyer to conduct the purchase fransaction and then consummate the deal. The fransaction 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 fransaction. The transaction may take place in a marketplace of vendors (sellers) who advertise their goods and then enter into specific auction bid fransactions 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 fransaction. 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 reserve price, complete the purchase and the payment is made by fransfer 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 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 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 transfened 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 bidder, provided the bid was above the reserve price, completes the purchase and the assets are transfened between the two accounts

• Seller offers twenty new late-model sedans with full dealer wananty 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 are sold; each winning bidder (buyer) pays the seller by transferring assets to the seller, subject to appropriate delivery anangements, 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 fransfer 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 cunency; the buyers place bids in various cunencies, with the wining bid compared to the cunency exchange rate tables as published in the Wall 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

8.1.3.3 Reverse auction

Reverse auction fransactions are used in buyer-dominated marketplaces to pit 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 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 fransactions can be executed using virtual accounts to exchange assets and complete a purchase between a buyer and seller. A virtual account auction fransaction allows the buyer to conduct the purchase fransaction 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 fransaction. The fransaction may take place in a marketplace of purchasers (buyers) who advertise their requirement specifications and then enter into specific auction bid fransactions with individual sellers willing to meet the conditions of the requirements specifications. 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 fransaction. The escrow account may be managed by either the buyer or the seller, or by a third party escrow service.

Reverse auction fransactions 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 conesponding 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 fransfers the miles into the seller's account, and the seller provides the appropriate ticket vouchers • An individual buyer desires to purchase a new late-model sedan with full dealer wananty, 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 fransfers assets to the sellers' account and the seller provides the deed of the vehicle to the buyer

8.1.3.4 Demand aggregation

Demand aggregation fransactions 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 more buyers are aggregated to qualify for volume discounts.

Demand aggregation fransactions 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 fransaction allows the buyer to negotiate for a purchase fransaction 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 fransaction. 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 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 fransactions 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 fransaction with several sellers directly 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 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 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 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 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 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 fransactions 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 fransactions especially for commodity goods. Exchanges work for consumers and businesses in such examples as stock and bond markets.

Exchange fransactions can be executed using virtual accounts wherein assets 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 fransaction allows the buyer to initiate the purchase fransaction and then consummate the deal. The fransaction 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 fransaction. 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 cunent market price (which floats). Purchasers may be required to escrow or obligate a specified maximum amount of funds at the time of initiating the fransaction. Optionally, the winning buyer and seller may agree to use an escrow account to coordinate the appropriate settlement of the fransaction 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 stereo elecfronic 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 transfened 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 themselves to be bound. In order to understand the requirements necessary to form binding confracts through electronic commerce, a review of the cunent state of confract 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 confract 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 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 for $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 confrols the person or 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 elecfronic commerce. 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 confract is of a certain type, for example, a confract 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 construing the Statute nanowly 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 fraditional confract principles, which are premised on personal contact and paper confracts. Thus, some legal issues in the field of elecfronic commerce remain unresolved.

One such technology is known as EDI, or electronic data interchange. It is known that, using EDI, one party can fransfer information and legally relevant "documents" electronically to another for direct processing in the other party's information systems.

Most EDI environments involve ongoing relationships between companies engaged in a supply or similar confract that extends over time. In cunent practice, many EDI exchanges occur under broader confracts regulating the terms of the relationship between the two parties. These may be in the nature of requirements or 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 fransactions between people who have no direct prior dealings, it has not been used for global/non-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 confract development, seeking an optimal contract structure for EDI use. Little reported litigation deals with EDI relationships. Thus, the legal issues raised by this technology are largely unresolved.

When an exchange occurs in a purely elecfronic 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 in the automated exchange. The exchange of elecfronic messages that offer and accept a contractual relationship should form a confract 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 elecfronic message may constitute the necessary 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 confract offer be in writing or that there be a conscious, immediate intent to make a binding commitment.

Confract 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 elecfronic message should be valid.

The Statute of Frauds also impacts fransactions 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 confract 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 confract 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 elecfronic 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 elecfronic confract depends on how the computer system retains records of the transmitted offer (or acceptance) and whether 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 confracts. 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 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 elecfronic contracts. One such method of authenticating electronic confracts 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 elecfronic confracts.

As discussed above, attribution via authentication is extremely important to creating binding confracts in a buyer-driven system of elecfronic 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 confract 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 Cunent 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 fransactions. However, submission of the device does not guarantee that the holder of the device is authorized to conduct the fransaction. Device-less account access and fransaction activity can be achieved by substituting something in place of the physical device. This can be a piece of information known only to the fransactor 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 fransaction 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 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 fransaction 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.

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 consfraints that proscribe or otherwise limit the 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 limited number of fransactions. Account holders can configure specific consfraints on individual accounts or sub-accounts, or may pick from pre-built suggested templates.

Account holder-specified constraints help reduce the risk of fraud because they consfrain activities to certain times, locations, or pre-selected activity types. The account can be configured to automatically deactivate itself or respond with an alert 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 incoφorated in accounts, whether virtual or not, as dynamic VINs that can act as temporary account numbers for the purpose of completing fransactions 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 fransaction. hi either case, even if the token for a given fransaction were printed on a fransaction receipt, that token would be worthless in the hands of a thief.

8.4.1 Just-In-Time Requested VINs

Consumers will need a mechanism for retrieving a cunent dynamic token so that an account can be used for purchases and other fransactions. 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 cunent dynamic token. The Palm 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 cunent dynamic token may be encrypted. The wireless device can display the dynamic token to the consumer for use in manual fransactions. However, instead of using the token manually, e.g., by transmitting it to a merchant verbally or by hand-writing, the consumer could retransmit 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 Using algorithms responding to synchronized stimuli such as timers or fransaction event counters, user-carried dynamic devices and cenfral 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 a cenfral 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 cunent dynamic token is generated. For security purposes, the communications and storage of the cunent dynamic token could be encrypted. The dynamic token could be displayed to the consumer for manual fransactions.

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.

8.4.3 Pay on Behalf Of hi 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 fransaction, or alternately decline the fransaction. 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 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 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 cunent merchant point- of-sale technology. Merchants, and the card processing firms that process their fransactions, 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 prefened embodiment, the smart card would include a wireless receiver for receiving from a cenfral office the data needed to supply or generate 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 conesponding synchronized generators. When an appropriate account is selected, the smartcard would generate the conect conesponding dynamic VIN 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 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 Residents of the United States do not have official national ID numbers, but the Social Security Number (SSN) 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 cunent 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 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 cunent "balance" of their SSA accounts because it is not easy to view the history for accuracy and 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 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 cunent SSN format or a new, more secure format with additional digits and/or characters. The individual would then be 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 Adminisfration (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 funds, 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 Detailed Description of the Drawings

9.1 Figures 1 and 2

Figures 1 and 2 show one of the many prefened 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 device(s) 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 confrol 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 figures, these modules are illusfrated 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 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 prefened 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. 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. 9.3 Figures 11-48

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 accoimt, 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 adminisfrators may logically connect private accounts or entire virtual accounts, although these actions are unknowable to end- users.

Logical connections between accounts are ^respective 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 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

5 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 o offered that show public and private sets of domains. These drawings can be combined in a Mr. Potato Head™ 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-51 5 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.

0 9.4.3 Figures 55-58

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

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 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 standard mathematical notation, e.g., "m" and "n".

These figures are also useful in illustrating the ability of a computer system(s) 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 entities 1001, directly or indirectly through its own 1201 or external 1202 communications devices.

9.8 Figures 98-102

Repositories can be grouped in various configurations, which may afford 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 anangement 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.

9.8.2 Figure 99

Figure 99 documents the anangement 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 drawing scale.

9.8.3 Figure 100

Figure 100 depicts an anangement 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 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 anangement 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 figure. Additionally, other objects are typically part of or connected to such a group, including, but not limited to, inter-network connection equipment (the internetwork 3410, routers 3420, concenfrators 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 fransactions 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 AAMS can be configured in both hardware, software, or some combination of hardware and software when the AAMS supports repositories. The possible encryption engines include the AAMS Repository Encryption Engine 1511 (Fig. 108), a dedicated encryption engine 1505 (Fig. 109), storage device encryption engines 1502 (Fig. 110), data processor encryption engines 1503 (Fig. Ill), 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 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 objects, a few examples of which include account fransactions 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.

9.11.2 Figures 116-118

As detailed in figures 116-118, clearinghouses can participate in fransactions involving many types of objects, including fransactions 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 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 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.

9.12 Figures 124-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 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 AAMS.

9.14.1 Figures 136-138 Figures 136-138 show the use of attribute management system software 1910, an optional addition to the AAMS. 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 5 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 o capabilities of a Account/ Attribute Management System could be configured in both hardware, software, or some combination of hardware and software. The possible encryption engines include the A/AMS Encryption Engine 1551 (Fig. 141), a dedicated encryption engine 1505 (Fig. 142), storage device encryption engines 1502 (Fig. 143), data 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 146-155

These figures detail the creation and operation of an constraint management subsystem, which can be included as an enhancement to certain legacy account 0 management systems, or as an integral part of an AAMS.

9.15.1 Figures 146-148

Figures 146-148 show the use of consfraint management system software module 1920 as an optional but prefened addition to the AAMS. Additionally, various consfraints 1921 are shown for various accounts 1901.

5 9.15.2 Figures 149-150

Figure 149 illustrates several types of consfraints that may be provided in various embodiments of the invention, including system consfraints, and user- selected, user-determined, and user-defined consfraints. 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 consfraints that an account can contain, incorporating some of the additional types of constraints 1922, 1923, and 1924 illusfrated 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/Consfraint Management System could be configured in both hardware, software, or some combination of hardware and software. The possible encryption engines include the A/CMS Encryption Engine 1561 (Fig. 151), a dedicated encryption engine 1505 (Fig. 152), storage device encryption engines 1502 (Fig. 153), data processor encryption engines 1503 (Fig. 154), and communications device encryption engines 1504 (Fig. 155). Each of these encryption engines can be used alone, or in combination with some or all of the other engines.

9.16 Figure 156

Figure 156 depicts some of the possible attributes 1911, 1912, 1913, and 1914, and consfraints 1921, 1922, 1923, and 1924, that can be found in certain prefened 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 constraints on repositories, virtual accounts, various sub-accounts within the virtual account, and on the domains.

9.17 Figures 157-164

Figures 157-163 show the impact of consfraints from higher level objects down through lower level objects. Lower level objects collect consfraints from higher level before adding or modifying consfraints. The build-up or collection of consfraints 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.

5 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 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 illusfrated 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 0 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 ananged in hierarchical fashion. Figure 174 incorporates an additional domain 2520 that extends across hierarchies.

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 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 consfraint set skeleton 2631 from a primary accoimt. The consfraint set skeleton can be used as is, or modified to produce the escrow consfraint 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 consfraints from the buyer and seller 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, 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 confract 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 confract 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 accoimt 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 frack and record bids 2471 made in response to the offer contained in 2700 as detailed in 2730.

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

9.21.6.3 Figure 183

Figure 183 shows bids 2741 coming from two separate bidders, Bidder 1 and 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 frack such things as timestamps for bid receipts, and the closing of 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 consfraint set skeleton 2831 from a primary account. The constraint set skeleton can be used as is, or modified to produce the gaming consfraint set 2830 shown. Also shown is a gaming pool 2840, used to frack 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 Bettor 2, responding to a game offered by a gaming house. Additional consfraints

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.

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 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 consfraint set skeleton can be used as is, or modified to produce the proxy consfraint set 2930 shown. The relationship of the proxy account to the primary account is shown in Figure 190, while Figure 191 shows proxy accounts with various consfraint 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 fransfened between the conventional and proxy accounts can be contained within the proxy accoimt, or as shown in Figure 193, can be used in fransactions with other accounts.

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 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 fransactions to these accounts, used as to determine which conventional account or group of accounts the proxy will interact 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 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 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 fransaction in which it takes the place of the credit card account. 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 VINs. 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 fransaction. As assets are fransfened to other accounts, in this case another virtual account, the dynamic proxy account generates a new Dynamic VIN to record its participation in the second fransaction.

9.23 Figure 203

Figure 203 shows multiple child accounts each using a different version of a label in place of their normal VIN: 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 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 consfraint 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 entire group of accounts is fransitioned 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).

9.27.1 Figure 223

Figure 223 shows a multi-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/O) devices are shown, including the display, a keypad, a biometric scanner, and elecfronic 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 elecfronic contacts and magnetic stripe, along with a standard computer-style I/O 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 prefened 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 source(s) available including possible confrol 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 port(s) 9405.

9.27.3 Figure 225

Figure 225 contains examples of devices cunently 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 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 illusfrated by ovals in Figure 227 are represented by circles and ovals, respectively, in Figure 228.

9.28.2 Figures 230-234

Figures 230-234 detail some of the possible ways in which the encryption capabilities of an Account/Token Management System could be configured in both hardware, software, or some combination of hardware and software. The possible encryption engines include the A/TMS Encryption Engine 1571 (Fig. 230), a dedicated encryption engine 1505 (Fig. 231), storage device encryption engines 1502 (Fig. 232), data processor encryption engines 1503 (Fig. 233), and communications device encryption engines 1504 (Fig. 234). Each of these encryption engines can be used alone, or in combination with some or all of the other engines.

9.29 Figures 235-242

These figures detail the creation and operation of an hierarchy management subsystem, which can be included as an enhancement to certain legacy account 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 prefened addition to the AAMS. Additionally, various hierarchies 1941 are shown for various accounts 1901. The downward-projecting branches of the inverted frees 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 both hardware, software, or some combination of hardware and software. The possible encryption engines include the A/HMS Encryption Engine 1581 (Fig. 238), a dedicated encryption engine 1505 (Fig. 239), storage device encryption engines 1502 (Fig. 240), data processor encryption engines 1503 (Fig. 241), and communications 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 queuing and distribution system such as IBM MQ-Series 1202 BE A MessageQ 1203.

The fransaction coordination subsystem 1300 can be implemented using message broadcasting, routing and distribution software from Talarian 1301 or more fraditional fransaction process monitors such as BEA Tuxedo 1302.

The user interaction subsystem 1400 includes the user interfaces required for an individual or corporate user to perform actions such as inquiries as to account balances, manipulation of account structures, and the initiation of fransactions 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 commercially available from SI corporation including their SI Retail Banking 1401, and (b) from a touch tone, voice recognition, cell phone or wireless device, are commercially available from SI, 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 symmetric and split key cryptography toolkits from TecSec CKM 1501.

The records management subsystem 1600 can be implemented using any commercially available database including products such as Oracle RDBMS 81 1601 or IBM DB2 1602. The records management subsystem includes an on-line fransaction processing (OLTP) component operating in conjunction with a data 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 accoimt 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, fransactions 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), CPU(s) 1020, memory 1030, network interfaces 1040, input/output (I/O) controller 1050, and internal data storage 1060.

9.31 Figures 244-247

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 fransactions and interact with users. In Figure 247, the software configuration is shown with the various subsystems operating in a coordinated fashion 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 251-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. hi 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 Systems Architecture

10.1 Architecture 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, cunently available hardware and software components are available that allow the creation of a highly reliable, 99.95% available, serviceable, highly secure, and top performing set of systems. The architect must make frade-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. 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 minors 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 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 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 commands from other systems (both trusted and untrasted). Security can be enhanced with tripwires and other intrusion detection mechanisms that act as alarms. System security is a combination of protection against elecfronic incursion, physical barriers, policies, procedures, and controls that minimize the threat from outside and inside, including sabotage. 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 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 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 plaintext through the application of a cipher key. Modem 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. 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. 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 source other than a holder of the private key conesponding 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 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 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 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 adminisfrators. The access parameters of each object may be determined without access to content. This enables flow confrol of objects by network routing and other smart confrol devices. Flow confrol thereby enforces end-to-end traffic within the network. Proportional access to the content of each object is cryptographically enforced. 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, minoring existing organizational 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 applied to data-at-rest and data-in-fransit. In addition, the CKM process can be part of the key and attribute exchange process for data fransmission.

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, and or while it is at rest. Encryption is a key component of the prefened 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 Architecture

To implement the functionality of the repositories, clearinghouses, naming 5 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.

o 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- 0 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 5 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 consfraints, 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 fransactions that might otherwise be limited or baned 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 configuration) to exchange transactions and publish information. This is accomplished by communicating over pathways using standard protocols such as TCIP/IP and SNA through a series of consolidators, routers, and bridges. Clearinghouses, naming systems, and label systems can further support the internetwork by providing components needed by repositories to discover each other, to 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 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. 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- 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 fransaction 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 fransaction monitor capabilities to coordinate fransactions, 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 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 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. 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 fransactions, 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. SI 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. SI also 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 SI 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, 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 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 RAID 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 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 anay, 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 anay with the addition of Sun Cluster 2.2 operating system software.

10.6 Clearinghouses

10.6.1 Clearinghouse Software Integration

Each clearinghouse is comprised of subsystems: e.g., communications, fransaction coordination, records management, cryptographic processing, application 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 TCP/IP network fransport 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 fransport 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. Talarian SmartSockets provides naming service, dynamic fransaction routing, and shortest-path route discovery. BEA Tuxedo provides fransaction monitor capabilities to coordinate fransactions, 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 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 Infrasfructure (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.

5 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. SI has developed a Retail o Banking portal that provides a web browser-based implementation of banking software suitable for the basic presentation of a virtual assets account. SI also manufactures the Edify IVR products for integration with voice and wireless devices that is integrated with the Retail Banking portal. The SI Vertical One products allow for account aggregation from multiple repositories and extemal 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, fransaction coordination, records management, cryptographic processing, application logic, and 0 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, I/O controllers, and network 5 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 concuπent transactions, one can use a mid- range enterprise server such as the Sun E4500 with one or more UltraSparc 0 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 anay, 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 anay 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-8500 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 anay 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 anay 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, fransaction 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 fransport 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 fransport 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 records management subsystem provides a persistent data storage capability with a high degree of fransactional 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 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 Infrasfructure (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. Apphcation logic can be built using languages such as Java and C. Custom naming system logic will include name, alias, and address management 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 disk controller, and four Seagate ST39103LC Ulfra2 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 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 anay, 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 anay with the addition of Sun Cluster 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, fransaction 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 commumcations 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 fransport 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 fransaction 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 fransaction routing, and shortest-path route discovery. BEA Tuxedo provides fransaction 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 fransactional 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 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 5 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. o 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. 5 Custom labeling system logic will include label, alias, and address management functionality.

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 0 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 5 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 0 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 Ulfra2 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 anay, 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 anay 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.

Changes and Corrections

The following changes and corrections to typographical enors were made in Patent Application No. 09/569,023 "Advanced Asset Management Systems". No substantive conections were made.

In the Specification:

1) Pg 61, line 16

"... and determined..." to "... and NLete:m^*-ined..."

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

5) Pg 125, line 12

"(e.g. music ...", to "(e.g., music ..."

6) Pg 132, line 2

"(e.g. frequent flyer miles)" 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. ..." [single 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 185, 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\

"not 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 publfc accounts"

In the Claims;

14) Pg 261, lines 10, 12, 14, 16, 18, 20, and 22

"An advanced asset management system having according to claim 1 in" to "An advanced asset management system according to claim 1 in"

15) Pg 262, lines 1, 3, and 5

In the Drawings:

16) Figure 16

Missing object callout, LHS, in Virtual Account One, Private Account NAN(1,1) Add -[ 2210

17) Figure 28

Missing object callout, LHS, in Virtual Account One, Private Account VAN(1,1) Add -[ 2210

18) Figure 98

Object callout 3100 (Distributed Group) 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 172

Under the RHS Escrow Account ("Obligations"), the second subordinate Proxy account

"Dyamic"_.to "Dynamic" 22) Figure 179

In the Escrow Account (object = 2630) "Delivery Reciept" to "Delivery Receipt''

23) Figure 180

In the Escrow Account (object ^*=^** 2630) "Delivery Reciept" to "Delivery Receipt''

24) Figure 181

In the Escrow Account (object = 2630) "Delivery Reciept" to 'Oelivery Receipt''

25) Figure 192

External Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

26) Figure 193

External Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

27) Figure 194

External Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

28) Figure 195

Extemal Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

29) Figure 196

External Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

30) Figure 197

External Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

31) Figure 202

RHS, External Stimuli (object = 2470) "Withdrawl" to "Withdrawal"

32) Figure 205 Four places "Labelinging" to "Labeling" Virtual Assets Inc.

U.S. Patent Specification Entitled "Advanced Asset Management Systems"

VIRTUAL ASSETS, INC.

10387 Eclipse Way

Columbia, MD 21044

(443) 414-8580

1 ABSTRACT 1

2 TECHNICAL FIELD 2

3 BACKGROUND OF THE INVENΗON 3

4 SUMMARY OF THE INVENTION 9

4.1 APPARATUS CLAIMS: 9

4.1.1 First Aspect: 9

4.1.2 Second Aspect: 19

4.1.3 Third Aspect: 22

4.1.4 First Aspect, continued: 24

4.1.5 Fourth Aspect: 39

4.2 METHOD CLAMS: 41

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

5 ADVANTAGES OF THE INVENTION 50

6 BRIEF DESCRIPTION OF THE DRAWINGS 57

7 GENERAL EMBODIMENTS 86

7.1 OVERVIEW 86

7.1.1 Account Management 87

7.1.2 Content Management. 88

7.1.3 Transaction Management 90

7.2 SYSTEM ELEMENTS 92

7.3 VIRTUAL ACCOUNTS 92

7.3.1 Virtual Accounts: An Analogy 94

7.3.2 Account Creation 95

7.3.3 Account Ownership & Control. 97

7.3.4 Relationships & Identification 97

7.3.5 Information Disclosure 100

7.3.6 Parent-Child Relationships 101

7.3.7 Domains 101

7.3.8 Account Encryption 103

7.3.9 Account Classes 104

7.4 DYNAMICTOKENS 118

7.5 ACCOUNT MODIFICATIONS 119

7.6 ACCOUNT CONTENT 121

7.6.1 Content Manipulation 121

7.6.2 Content Security 122

7.6.3 Digital Assets 122

7.6.4 Non-digital Assets 123

7.6.5 Changing Ownership and Control 124

7.6.6 Asset Types 124

7.6.7 Document Types 125

7.6.8 Converting Content 126

7.6.9 Asset Reservations 127

7.7 ACCOUNT REPOSITORIES 128

7.7.1 Repository Content. 128

7.7.2 Distributed Repositories 130

7.7.3 Federated Repositories 130 7.7.4 Distributed-Federated Repositories 131

7.7.5 Repositories: Inter-networked Repositories 131

7.7.6 Repository Encryption & Security. 132

7.8 VIRTUAL CLEARINGHOUSES 133

7.8.1 General and Special Services 134

7.8.2 Escrow Services 135

7.8.3 Bid Services 136

7.8.4 Gaming Services 136

7.8.5 Agent Services 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 VIRTUAL NAMING SYSTEMS 141

7.9.1 Search Requests 142

7.9.2 Ownership Certificates 142

7.9.3 Naming Systems: An Analogy 142

7.9.4 Naming System Encryption & Security 143

7.10 VIRTUAL LABELING SYSTEMS 143

7.10.1 Label Generation & Selection 145

7.10.2 Account Identification & Directories 146

7.10.3 Digital Certificates & Digital Signatures 147

7.10.4 Labeling System Encryption & Security 149

7.11 ACCESS METHODS 149

7.11.1 Private Networks 150

7.11.2 Public Networks 151

7.11.3 Private-Over-Public Networks 151

7.11.4 Communications Devices 151

7.11.5 Access Constraints 152

7.12 ATTRIBUTES 153

7.12.1 Traditional Asset Management System Attributes 154

7.12.2 Improvements to the State of the Art 155

7.12.3 Content Attributes 158

7.13 CONSTRAINTS 158

7.13.1 Traditional Asset Management System Constraints 159

7.13.2 Improvements to the State of the Art 160

7.13.3 Hierarchies of Constraints 161

7.13.4 Collections 163

7.13.5 Contradictory Constraint Resolution 163

7.13.6 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.10 Integral and External Constraints 168

7.13.11 Constraint Security 168

7.13.12 Constraint Encryption 169

7.14 AGENTS, ALERTS & TRIGGERS 169

7.14.1 Alerts 169

7.14.2 Triggers 174

7.14.3 Agents 176 SPECIFIC EMBODIMENTS 179

8.1 PRICING MECHANISMS AND ASSET TRANSFER SYSTEMS: 179

8.1.1 The Advantages of Virtual Accounts 180

8.1.2 One-to-One Transactions 181

8.1.3 One-to-Many (and Many-to-One) 184

8.1.4 Many-to-Many 191

8.1.5 Basic Contract Law 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 DYNAMIC TOKEN GENERATION DEVICES 197

8.4.1 Just-In-Time Requested 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 Stripe Generation 200

8.5 SOCIAL BENEFITS 200 DETAILED DESCRIPTION OF THE DRAWINGS 203

9.1 FIGURES 1 AND 2 203

9.2 FIGURES 3-10 203

9.3 FIGURES 11-48 204

9.3.1 Figures 11-14 204

9.3.2 Figures 15-26 204

9.3.3 Figures 27-38 204

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 55-58 205

9.4.4 Figures 59-64 205

9.4.5 Figures 65-84 206

9.5 FIGURES 85-89 206

9.6 FIGURE90 206

9.1 FIGURES 91-97 206

9.8 FIGURES 98-102 207

9.8.1 Figure 98 207

9.8.2 Figure 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 Figuresl 13-115 209

9.11.2 Figures 116-118 209

9.11.3 Figures 119-123 209

9.12 FIGURES 124-133 209

9.12.1 Figures 124-128 210

9.12.2 Figures 129-133 210

9.13 FIGURES 134-135 210

9.14 FIGURES 136-145 210

9.14.1 Figures 136-138 210

9.14.2 Figures 139-140 211

9.14.3 Figures 141-145 211

9.15 FIGURES 146-155 211

9.15.1 Figures 146-148 211

9.15.2 Figures 149-150 211

9.15.3 Figures 151-155 212

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 173-174 214 9.21.4 Figures 175-176 214

9.21.5 Figures 177-180 214

9.21.6 Figures 181-184 215

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

9.22.4 Figure 202 219

9.23 FIGURE203 219

9.24 FIGURES 204-213 219

9.24.1 Figures 204-208 219

9.24.2 Figures 209-213 219

9.25 FK JRE214 220

9.26 FIGURES 215-222 220

9.27 FIGURES 223-226 220

9.27.1 Figure 223 220

9.27.2 Figure224 221

9.27.3 Figure 225 221

9.27.4 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 FIGURE243 223

9.31 FIGURES 244-247 224

9.32 FIGURES 248-250 224

9.33 FIGURES 251-255 224 SYSTEMS ARCHΓΓECTT RE 226

10.1 ARCHITECTURE CONSIDERATIONS 226

10.2 DISASTERRECOVERY 228

10.3 ENCRYPTION 228

10.4 SOFTWARE ARCHITECTURE 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 CLEARINGHOUSES 235

10.6.1 Clearinghouse Software Integration 235

10.6.2 Clearinghouse Hardware Architecture 237

10.7 NAMING SYSTEMS 238

10.7.1 Naming System Software Integration 238

10.7.2 Naming System Hardware Architecture 240

10.8 LABELING SYSTEMS 241

10.8.1 Labeling System Software Integration 241

10.8.2 Labeling System Hardware Architecture 242 DEFINITIONS 244 CLAIMS 249

12.1 APPARATUS CLAIMS: 249

12.1.1 First Aspect. 249

12.1.2 Second Aspect. 273

12.1.3 Third Aspect 283

12.1.4 First Aspect, continued 287

12.1.5 FourthAspect 343 2

APPENDLXA 1

The following table identifies the objects labeled in the included drawings.

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 token(s) thereof, and whereby one or more entities other than account admimstrators, 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 commumcations 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 commumcations 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 accounts) 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 transactions) 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 accounts) 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 connections) 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^) 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 commumcations 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 1 with a PIN(s), password(s) or other authenticating token(s) signifying an

2 entity/entities owning or having a right to control said repository/repositories.

3 127. An advanced asset management system according to claim 1 comprising any

4 number of account repositories respectively comprising one or more accounts,

5 and having one or more actual or potential communications connections with

6 one or more other repositories comprising one or more accounts, said

7 connection/connections affording the opportunity for interactions between the

8 repositories and/or their respective account(s).

9 128. An advanced asset management system according to claim 1 comprising any

I o number of account repositories respectively comprising one or more accounts,

I I and having one or more actual or potential communications connections with

12 one or more additional communications devices, said connection/connections

13 affording the opportunity for interactions within or between the

14 repository/repositories and/or its/their respective account(s).

15 129. An advanced asset management system according to claim 1 comprising any

16 number of account repositories respectively comprising one or more accounts,

17 and having one or more actual or potential communications connections with

18 one or more other repositories comprising one or more accounts, and having

19 one or more actual or potential communications connections to one or more

20 additional communications devices, said connection/connections affording the

21 opportunity for interactions within or between the repositories and/or their

22 respective account(s).

23 130. An advanced asset management system according to claim 125 in which said

24 repositories represent an open group not subject to any

against an

25 interaction(s) with one or more other repository/repositories or their respective

26 account(s).

27 131. An advanced asset management system according to claim 125 in which said

28 repositories represent an open group not subject to any restriction(s) against an

29 interaction(s) with one or more additional communications devices.

30 132. An advanced asset management system according to claim 125 in which said

31 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 commumcations 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 grouρ(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 connections) 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^) 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 grouρ(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. commumcations 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 account(s) 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 account(s) 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-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 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 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, 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 cause(s) 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 mampulating 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/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 taxes and/or fees.

1 188. A virtual clearinghouse system according to claim 172 in which the system

2 comprises data and/or code for calculating, collecting, disbursing, reporting,

3 and/or otherwise manipulating information pertaining to at least in part taxes

4 and/or fees.

5 189. A virtual clearinghouse system according to claim 188 in which said at least

6 one data processor is configured to accept one or more commands to calculate,

7 collect, disburse, report and/or otherwise manipulate information pertaining to

8 at least in part said taxes and/or fees only if said command(s) is/are received in

9 conjunction with a PIN(s), password(s) or other authenticating token(s)

I o signifying an entity/entities owning or having a right to control said

I I information pertaining to at least in part said taxes and/or fees.

12 190. A virtual clearinghouse system according to claim 172 in which the system

13 comprises data and/or code for granting, revoking, reporting, validating,

14 transmitting and/or otherwise manipulating one or more credentials and/or

15 licenses.

16 191. A virtual clearinghouse system according to claim 190 in which said at least

17 one data processor is configured to accept one or more commands to grant,

18 revoke, report, validate, transmit and/or otherwise manipulate said credentials

19 and/or licenses only if said command(s) is/are received in conjunction with a

20 PIN(s), password(s) or other authenticating token(s) signifying an

21 entity/entities owning or having a right to control said credentials and/or

22 licenses.

23 192. A virtual clearinghouse system according to claim 172 in which the system

24 comprises data and/or code for granting, revoking, reporting, validating,

25 transmitting and/or otherwise manipulating information pertaining to at least

26 in part credentials and/or licenses.

27 193. A virtual clearinghouse system according to claim 192 in which said at least

28 one data processor is configured to accept one or more commands to grant,

29 revoke, report, validate, transmit and/or otherwise manipulate information

30 pertaining to at least in part said credentials and/or licenses only if said

31 command(s) is/are received in conjunction with a PIN(s), password(s) or other

32 authenticating token(s) signifying an entity/entities owning or having a right to 1 control said information pertaining to at least in part said credentials and/or

2 licenses.

3 194. A virtual clearinghouse system according to claim 172 in which the system

4 comprises data and/or code for granting, revoking, authenticating, validating,

5 transmitting and/or otherwise manipulating one or more digital security

6 certificates.

7 195. A virtual clearinghouse system according to claim 194 in which said at least

8 one data processor is configured to accept one or more commands to grant,

9 revoke, report, validate, transmit and/or otherwise manipulate said digital

I o security certificate(s) only if said command(s) is/are received in conjunction

I I with a PIN(s), password(s) or other authenticating token(s) signifying an

12 entity/entities owning or having a right to control said digital security

13 certificate(s).

14 196. A virtual clearinghouse system according to claim 172 in which the system

15 comprises data and/or code for granting, revoking, authenticating, validating,

16 transmitting and/or otherwise manipulating information pertaining to at least

17 in part digital security certificates.

18 197. A virtual clearinghouse system according to claim 196 in which said at least

19 one data processor is configured to accept one or more commands to grant,

20 revoke, report, validate, transmit and/or otherwise manipulate information

21 pertaining to at least in part said digital security certificate(s) only if said

22 command(s) is/are received in conjunction with a PIN(s), password(s) or other

23 authenticating token(s) signifying an entity/entities owning or having a right to

24 control said information pertaining to at least in part said digital security

25 certificate(s).

26 198. A virtual clearinghouse system according to claim 172 in which the system

27 comprises data and/or code for granting, revoking, authenticating, validating,

28 transmitting and/or otherwise manipulating one or more digital signatures.

29 199. A virtual clearinghouse system according to claim 198 in which said at least

30 one data processor is configured to accept one or more commands to grant,

31 revoke, report, validate, transmit and/or otherwise manipulate said digital

32 signature(s) only if said command(s) is/are received in conjunction with a PIN(s), ρassword(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 infonnation 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 connection(s) 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 ρarticipant(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 connection(s) 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 transaction(s) 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 connections) 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 participants) 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 infonnation 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 list(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 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 list(s) 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, and/or 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 mampulating 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 system(s) 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. An 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 account(s) 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 winch 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 form(s) of currency. 306. 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 a particular form of cunency. 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 attribute(s) 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 ofrepositori.es. 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 mampulating 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 coristraint(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. attribute(s) 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 transfened, 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 transfened, 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.

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 systeni 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. 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). 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 part(s) of said repository/repositories. 351. An advanced asset management system according to claim 334 wherein said constraints) exists/exist as an integral part(s) of said account(s). 352. An advanced asset management system according to claim 334 wherein said constraint(s) 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) contaimng 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 constraint(s) 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 contaimng 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 contaimng 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 part(s) 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).

1 403. An advanced asset management system according to claim 334 wherein said

2 data and/or code includes provisions for cooperating with means external to

3 said account(s) for processing said constraint(s).

4 404. An advanced asset management system according to claim 334 wherein said

5 data and/or code includes provisions for cooperating with means external to a

6 repository/repositories containing said account(s) for processing said

7 constraint(s).

8 405. An advanced asset management system according to claim 335 wherein said

9 data and/or code includes provisions for cooperating with means external to

I o said content for processing said constraint(s).

I I 406. An advanced asset management system according to claim 335 wherein said

12 data and/or code includes provisions for cooperating with means external to an

13 account(s) containing or controlling said content for processing said

14 constraint(s).

15 407. An advanced asset management system according to claim 336 wherein said

16 data and/or code includes provisions for cooperating with means external to

17 said content for processing said constraint(s).

18 408. An advanced asset management system according to claim 336 wherein said

19 data and/or code includes provisions for cooperating with means external to a

20 repository/repositories containing or controlling said content for processing

21 said constraint(s).

22 409. An advanced asset management system according to claim 337 wherein said

23 data and/or code includes provisions for cooperating with means external to

24 said attribute(s) for processing said constraint(s).

25 410. An advanced asset management system according to claim 337 wherein said

26 data and/or code includes provisions for cooperating with means external to a

27 repository/repositories containing said attribute(s) for processing said

28 constraint(s).

29 411. An advanced asset management system according to claim 337 wherein said

30 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 account(s) 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 attribute(s) 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 constraints) 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 account(s) 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 wherem 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 commumcations 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 ofrepositori.es 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 constraints) 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 infonnation 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 infonnation 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 infonnation 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 infonnation. 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.

1 515. An advanced asset management system according to claim 336 in which at

2 least a portion of any information regarding said one or more constraints is

3 stored internal and external to the system, comprising means for encrypting at

4 least a part of said portion.

5 516. An advanced asset management system according to claim 337 in which at

6 least a portion of any information regarding said one or more constraints is

7 stored internal and external to the system, comprising means for encrypting at

8 least a part of said portion.

9 517. An advanced asset management system according to claim 333 wherein said

I o data and/or code includes provisions for processing information regarding said

I I one or more constraints internal to the system, comprising means for

12 encrypting all of said information.

13 518. An advanced asset management system according to claim 334 wherein said

14 data and/or code includes provisions for processing information regarding said

15 one or more constraints internal to the system, comprising means for

16 encrypting all of said information.

17 519. An advanced asset management system according to claim 335 wherein said

18 data and/or code includes provisions for processing information regarding said

19 one or more constraints internal to the system, comprising means for 0 encrypting all of said information. 1 520. An advanced asset management system according to claim 336 wherein said 2 data and/or code includes provisions for processing information regarding said 3 one or more constraints internal to the system, comprising means for

24 encrypting all of said information. 5 521. An advanced asset management system according to claim 337 wherein said 6 data and/or code includes provisions for processing information regarding said 7 one or more constraints internal to the system, comprising means for 8 encrypting all of said information. 9 522. An advanced asset management system according to claim 333 wherein said

30 data and/or code includes provisions for processing at least a portion of any 1 information regarding said one or more constraints internal to the system, 2 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.

1 544. An advanced asset management system according to claim 335 wherein said

2 data and/or code includes provisions for internal processing of, and for

3 cooperation with means external to the system for external processing of, at

4 least a portion of any information regarding said one or more constraints,

5 comprising means for encrypting at least a part of said portion.

6 545. An advanced asset management system according to claim 336 wherein said

7 data and/or code includes provisions for internal processing of, and for

8 cooperation with means external to the system for external processing of, at

9 least a portion of any information regarding said one or more constraints,

I o comprising means for encrypting at least a part of said portion.

I I 546. An advanced asset management system according to claim 337 wherein said

12 data and/or code includes provisions for internal processing of, and for

13 cooperation with means external to the system for external processing of, at

14 least a portion of any information regarding said one or more constraints,

15 comprising means for encrypting at least a part of said portion.

16 547. An advanced asset management system according to claim 333 wherein said

17 data and/or code includes provisions for communicating information regarding

18 said one or more constraints to or from the system, comprising means for

19 encrypting all of said information.

20 548. An advanced asset management system according to claim 334 wherein said

21 data and/or code includes provisions for communicating information regarding

22 said one or more constraints to or from the system, comprising means for

23 encrypting all of said information.

24 549. An advanced asset management system according to claim 335 wherein said

25 data and/or code includes provisions for communicating information regarding

26 said one or more constraints to or from the system, comprising means for

27 encrypting all of said information.

28 550. An advanced asset management system according to claim 336 wherein said

29 data and/or code includes provisions for communicating information regarding

30 said one or more constraints to or from the system, comprising means for

31 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 commumcations 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 commumcations 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 commumcations 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 commumcations 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-component(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 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 account(s) 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 token(s) 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, and/or 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 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) °f 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 transfened 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 transfened 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 transfened 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 transfened 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 PrN(s), password(s) or other authenticating token(s) signifying an entity/entities owning or having a right to control said one or more triggers.

12.1.5 Fourth Aspect 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 commumcate 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 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. 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).

12.2 Method Claims:

12.2.1 Fifth Aspect 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 fonn 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.

1 687. A method according to claim 685 comprising maintaining all of the encrypted

2 data in encrypted form throughout its processing by the system.

3 688. A method according to claim 685 comprising maintaining all of the encrypted

4 data in encrypted form throughout its communication to and from the system.

5 689. A method according to claim 664 comprising encrypting at least a portion of

6 the data in said system.

7 690. A method according to claim 689 comprising maintaining at least a portion of

8 the encrypted data in encrypted form throughout its storage by the system.

9 691. A method according to claim 689 comprising maintaining at least a portion of

I o the encrypted data in encrypted form throughout its processing by the system.

I I 692. A method according to claim 689 comprising maintaining at least a portion of

12 the encrypted data in encrypted form throughout its communication to and

13 from the system.

14 693. A method according to claim 664 comprising storing account management

15 software on said at least one data storage device and encrypting all said

16 software and any code therein, and all of the data, in said system.

17 694. A method according to claim 693 comprising maintaining all of the encrypted

18 software, and all of the encrypted data, in encrypted form throughout their

19 storage by the system.

20 695. A method according to claim 693 comprising maintaining all of the encrypted

21 software, and all of the encrypted data, in encrypted form throughout their

22 processing by the system.

23 696. A method according to claim 693 comprising maintaining all of the encrypted

24 software, and all of the encrypted data, in encrypted form throughout their

25 communication to and from the system.

26 697. A method according to claim 664 comprising storing account management

27 software on said at least one data storage device and encrypting at least a

28 portion of said software and any code therein, and at least a portion of the

29 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 designate(s) 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 account(s) 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 commumcations 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 mampulating 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 mampulating 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 mampulating 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 maintaimng 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 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. 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 accordmg 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 accordύig 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 maintaimng 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 maintaimng 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 maintaimng 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 namύig 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 maintaύiing 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 havmg: 1) at least one data processor, 1 2) at least one data storage device, and

2 3) at least one communications device through which the computer

3 system can communicate with one or more entities that can connect

4 with said computer system;

5 B. maintaining in said computer system on said at least one data storage

6 device labeling system software for storing and managing data comprising

7 at least one label for each of one or more accounts

8 1) said data being at least in part accessible via said at least one

9 communications device, and

I o 2) said labels respectively comprising data that is one or more symbols,

I I generated by the system or by an entity/entities having ownership or

12 control of said accounts, which signify said account(s), and

13 3) said software including data and/or code that creates, stores, maintains

14 and/or otherwise manipulates one or more lists of all known active

15 ^' labels of an account(s), which labels include the private token(s), the

16 public token(s), if any, and account alias(es), if any, of said account(s),

17 said account alias(es) differing from any existing public and/or private

18 token(s) of the account(s) to which the alias(es) pertain;

19 C. through said data and/or code, barring from introduction into said list(s), as

20 an active label, any label which is not unique among all known active

21 labels throughout all repositories with which said virtual labeling system

22 communicates;

23 D. via said at least one communications device, receiving from one or more

24 repositories and/or one or more clearinghouses requests that respectively

25 1) include af least one alias of a given account and

26 2) seek a public token of the given account; and

27 E. Via said at least one communications device, fulfilling said requests by

28 transmitting the requested token/label to said repositories and/or

29 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 maintaύiing 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 commumcation 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 sof ware, 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 theύ 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.