HK1065616B - Personal information security and exchange tool - Google Patents

Description

Personal information safety and exchange tool

Technical Field

The present invention relates to software management of information in a networked computer environment. More particularly, the present invention relates to a software system operating on the internet that can create a virtual private network where users can author, protect, search, exchange and process personal information in a trusted and controlled manner. The software system includes trusted communities and their members, where a trusted right guarantees the identity and personal information of those community members. Once a user has registered with a trusted group, the user is free to produce and protect hypermedia content, and to govern and control the presentation and processing of their underlying rules of personal information.

Background

The introduction and accelerated utilization of the internet has led to a rapid growth in both the quantity and availability of personal information. Unfortunately, however, because the internet is generally unlimited, there is no guarantee that all information is accurate and reliable, and that the data source is often indeterminate. In addition, unless special precautions are taken, any information transmitted over the internet is subject to theft and abuse. These concerns for data reliability and data protection can be combined into a multi-faceted concept common to trusted information. Data has reliability and trustworthiness if it is accurate and can be authenticated or determined. The exploitation of trust is approved by the owner of the data when the data is suitable for access or processing, and continued governance and control exists according to rules established by the owner. The exploitation of trust or the handling of trust is particularly critical when handling personal data. Personal information, such as a person's credit, medical history, professional background, or lifestyle, can now go through the internet in a variety of ways. Law enforcement agencies, credit departments, landlords, and others can use this information to help them make decisions. Because all of these groups utilize incorrect data, or they utilize information that they should not have to make decisions that significantly affect private life, can be devastating.

Thus, it is recognized that something must be done to protect an individual's information and to try to join the Internet for as many individuals as possible, which will be more compelling to gather, use and sell the available personal information, and the individual will wish to participate in, govern and control such activities. In general, these ideas cannot be fully implemented with the tools available on the existing internet, and there are no tools that can effectively embody such ideas. Therefore, there is a need to provide an internet utility or a tool for the secure and exchange of personal information.

Disclosure of Invention

It is therefore an object of the present invention to facilitate the exploitation of the trust of personal information on the internet by 1) providing some individuals or organizations with a structural way to securely write and seal personal data and handle rules governing the presentation and processing of personal information, while 2) permitting individuals or organizations to have arbitrary governance and control over their personal information within a network computing environment.

The present invention is a software system for operating on a network server with applications that support running on a personal computer system of an individual user, including wired and wireless remote-computing systems. The present invention is applied to a system that allows individuals or entities to protect, administer, control, and process personal information on a computer network, including the internet. In particular, the present invention facilitates the construction and use of network-trusted electronic communities, which thereafter become electronic metropolitan communities, each of which includes several members that meet common administrative needs. Preferably, it is this electronic metropolitan group that establishes registration rules and verifies the identity of the member itself or facilitates the use of other trusted certification authorities. The information identity of each member is encapsulated as an electronic personal information agent, hereinafter referred to as E-PIA (electronic personal information agent), with each E-PIA representing a member's information and behavior, with some information being provided by each member and some information from an external source of creditability to the member's electronic metropolitan area. By establishing and enforcing registration rules and performing verification of responsible and vetted member identities, the electronic metropolitan area, if selected, is certified by personal information, to establish a group in which each of its members can belong to and participate in an electronic domain in which personal rights and responsibilities and self-determination of information can be implemented. Thus, it is through the association and certification of a trusted electronic metropolitan area that a member becomes trusted and reliable in other transactions, but more importantly, increases the control of their data.

Once a user is a member of an electronic metropolitan area, the member can assign access to each piece of personal information. These access rules set the requests that must be satisfied before a piece of personal information can be processed. In addition, the e-metro group may obtain minimum criteria that must be met for all transactions. When an electronic metropolitan area standard and rules are accepted for a particular information request, the electronic metropolitan area standard and rules attached to the information are checked by an electronic agency (E-Broker) that is specific to the electronic metropolitan area, hereinafter referred to as the electronic metropolitan area. If so, the electronic proxy allows the requested information to be processed; if not, the electronic proxy does not allow the requested information to be processed. In addition, the information may be packaged for delivery with additional transmission priority rules, which are determined by anyone other than the original member for handling the request in short. With these transmission priority rules, a member can maintain control and control over the processing of third party destinations and their personal information.

A member may also create an agent, hereinafter referred to as an E-AutoPIA (electronic autonomous personal information agent), to interact with other members in any electronic metropolitan area, or even with external data to any electronic metropolitan area. The agent contains a subset of the member's personal information, additionally containing a route that guides the agent's activities. Thus, the agent can interact with personal information of other members in a guided route.

Drawings

The foregoing and other objects, features and advantages will be apparent from the following detailed description of preferred embodiments, which proceeds with reference to the accompanying drawings, in which:

fig. 1 shows some users connected to a web server accessing the internet.

FIG. 2 shows how a user of the preferred embodiment views other electronic groups on the Internet.

Figure 3 shows the digital identification of an element of a digital certificate, namely VeriSign (an authority that provides digital identification).

Fig. 4 shows how an RSA (RSA laboratory in the united states, well known for studying cryptographic algorithms) public key works and how a digital signature is generated and appended to a document to confirm authorship.

FIG. 5 shows an E-AutoPIA operating outside of the electronic metropolitan area (E-Metro Community).

FIG. 6 shows an E-AutoPIA that has gathered several information from several electronic metropolitan groups.

Figure 7 shows several network servers with a user's personal computer connected to the internet and attached to a wireless communication device.

Figure 8 shows several electronic metropolitan area systems with other resources interconnected by the internet.

Figure 9 shows the architecture of an electronic metropolitan trust server.

Figure 10 shows in detail the subsystem (distributed object asset management system server) in the electronic metro trust server shown in figure 9.

11a-d are detailed memory structures used in the preferred embodiment for several purposes.

FIG. 12 shows in detail an information subsystem for use in the server subsystem of the distributed object resource management system of FIG. 10.

FIG. 13 is a Booch diagram of an electronic metropolitan object.

FIG. 14 is a Booch diagram of an electronic proxy object.

FIG. 15a is a Booch diagram of an E-PIA object.

FIG. 15b is a Booch diagram of an information E-PIA object.

FIG. 16 is a Booch diagram of an E-AutoPIA object.

FIG. 17 is a Booch diagram of a route object.

FIG. 18 is a Booch diagram of an interacting instruction object.

FIG. 19 is a Booch diagram of an interactive protocol object.

FIG. 20 is a Booch diagram of a rule object.

FIG. 21 is a Booch diagram of a parameter object.

FIG. 22 depicts the relationships of various categories of objects used in the preferred embodiment.

FIG. 23 shows basic Booch symbols described using object schemas in the preferred embodiment.

Fig. 24 shows communication external to all electronic metropolitan groups using RSA-like security and encryption.

FIG. 25 is a user interface showing an initial screen for the preferred embodiment.

FIG. 26 is a user interface showing an entry to the system screen for the preferred embodiment.

FIG. 27 is a user interface displaying a population inventory screen for the preferred embodiment.

FIG. 28 is a user interface showing how a search is built and executed to display search results for the preferred embodiment.

FIG. 29 is a user interface showing an initial page for the preferred embodiment in which an electronic metropolitan area registration has been composed.

FIG. 30 is a user interface to the preferred embodiment showing selected electronic personas (E-Beam) implementing a trusted representation of their personal information with elements and distributions representing security and lock status because the required viewers are not compliant with the requirements set by the electronic metropolitan groups and the electronic metropolitan group members.

FIG. 31 is a user interface illustrating the distribution of additional personal information via disclosed and non-disclosed access processing rules for the preferred embodiment.

FIG. 32 is a user interface showing rule writing and arrangement of rules for both a particular personal information distribution and a particular group or sub-population of a population for the preferred embodiment.

FIG. 33 is a user interface showing the management rules writing and the arrangement of rules for both a particular personal information distribution and a particular group or sub-population of a population for the preferred embodiment.

Fig. 34 details the e-collective sub-agent subsystem.

Detailed Description

The preferred embodiment of the present invention operates primarily on a web server and supports applications operating on respective personal computer systems. For a user, the preferred embodiment appears as a website so it can be accessed simply by knowing the website address, but it is a website with integrated security protection: firewalls, proxy servers, SSL (secure sockets layer) authorization web servers and clients, digital certificates, hardware tokens, security policies and procedures. Not only will the network site typically need to verify basic identity for access, but the electronic metropolitan group and communications between members and other electronic metropolitan groups will also be encrypted. An optional hardware token or a secure card security system may be implemented for additional assurance of the user's identity. This security system will be discussed later.

As previously mentioned, the trusted processing of information has two parts: the reliability of the content and the control of the processing and each is addressed by the preferred embodiment of the present invention. This is the preferred embodiment to be discussed first and most clearly using a large city simulation. Just as in a large city, the internet provides an individual with a place to satisfy others, share information, seek entertainment, do work, and shop. Similarly, each individual on the internet has a corresponding address with which to communicate. In cities, a cautious attitude must be adopted when you meet someone for the first time and may not want to give too much information to someone who is not trustworthy. Also, a commercial transaction with a stranger must carefully examine the quality of the goods, the standards of support, or the unknown product origin. These are also emerging with new encounters and transactions on the internet.

In cities, people use an unfamiliar personal association to reduce the risk of new deals and trades. For example, a person wearing a police uniform would typically prefer to provide them with our driver's license number, home address, and other personal information. If someone sits in a lawyer's office and presents a business card that we have printed the lawyer's title, we generally would like to state secret information. Also, if someone lives in our same group, perhaps our neighbors, we would be very willing to share information and consider it safe to handle a transaction. On the internet, if someone has an address with a ". gov" end, we consider it safe to buy and sell with them, which gives the user a measure of confidence when some government agencies have allowed them to access the internet from a government server. If the user handles a bad transaction, agents that allow them to access the internet may be contacted. However, a large number of major internet users will not have their trustworthiness cues from web servers. Thus, the preferred embodiment of the present invention provides a way to reduce the risk in new interactions and increase the likelihood of other users saying who they are: the preferred embodiment creates a proxy rule based on a trusted electronic community.

In cities, citizens belong to several groups. Some groups are divided by region, ethnic background, religion, maternity, employment, or custom. Generally, people receive a great deal of acceptance and satisfaction from a select group to which they belong. It is common for an employee, a religious apprentice, or an amateur expert to be applied by a person as a company. Belonging to a group is not only personally satisfied to the member, but also allows consideration of the honor of the electronic metropolitan group to reduce the risk of involving any of its members.

In this embodiment, a user may join one or more electronic metropolitan groups. Each of these electronic metropolitan groups is independently operated by an administrator who sets a meeting request, identifies membership, issues digital certificates, and sets appropriate membership services. These e-metro groups are actually implemented as a network site on the internet, but they are some special network sites with a lot of intelligence and practicality. Figure 2 shows a view of an internet user using the preferred embodiment. The user will be a member of one or more electronic metropolitan groups 11 and he will be aware of several other electronic metropolitan groups 11 on the internet. The user will use a web browser such as that running on a personal computerNavigation of network scene15 visit toAsking the internet and attempting to become a member of one or more electronic metropolitan groups 11. When it is desired to become a member of an electronic metropolitan area, it is possible to find an unregistered or empty electronic character from the electronic metropolitan area or a public electronic character repository 13 that will need to be authenticated with identity information. An unregistered electronic persona may be retrieved prior to accessing the desired electronic metropolitan area to join. Once a user is approved for joining an electronic metropolitan area, the user becomes a member of the electronic metropolitan area and can use the services provided by the electronic metropolitan area administrator. These services may include connecting to other electronic metropolitan groups, shopping, or accessing information. Other than standardNet scene guide Aircraft riderIn addition to 15, the members will also need some additional support software, client subsystem 17, on their local computers. These client subsystem 17 support programs are some of the permissionsNavigation of network sceneA process with special functionality in a special electronic metropolitan group support. These programs will be provided as part of the preferred embodiment, but they will be configurable by an electronic metropolitan administrator or user to provide special functionality. These programs may be written in any language, but Java (an OOP language widely used on the Internet) is currently the most desirable. However, the objects of the e-metro group should not require additional software other than the standard base browser, thus keeping the client software subsystem very easily supported. In addition, members may require increased priority or access to some special electronic metropolitan group service without permission. The e-metro community can need further rich information that must be applied for approval in a form. These forms are stored in an electronic character repository 13 and can be established as a separate web site, an FTP site, or any other storage structure that allows for the internet.

Keeping in mind that trust processing includes both reliability and controllable processing, in the preferred embodiment trust processing of private data is improved by two means. First, the personal information that is processed is written and supervised by the individual. This information can also be calibrated by a third party who is the person who issues a digital certificate confirming the fact requested by the individual. The stored information is transparent to the individual. Furthermore, the user himself can request trust authentication in order to calibrate and claim the authenticity of the personal information. These accreditation authorities issue digital certificates claiming the authenticity of the data. One example is a credit organization, which will certify private financial or loan data. As the reputation of an e-metro group reliability and user-centric control of personal information processing grow, so will the information value and mutual trust of its users.

Other aspects of trust handling, the protection of data is improved in two ways by the preferred embodiment of the present invention. First, the preferred embodiment employs the latest techniques, such as public key encryption methods, to securely store and transmit information. Public key encryption methods will be discussed in more detail in later sections. These techniques ensure that data is not decrypted if intercepted during transmission, but only a particular reader can decrypt and obtain the information. A second security feature of the preferred embodiment is designed to arrange for some control over the amount of information processed to limit the amount of information that can be made available to only recipients meeting certain criteria. This security feature allows the user to set rules governing the handling and use of personal information. For example, a rule may be expressed as: legal historical information may be published to users from the american lawyer association e-metropolitan community. Another rule may be expressed as: a user who is single, from a particular region, and agrees to have their home phone number available within a controlled area may be permitted to utilize a home phone number. By establishing satisfactory rules, individuals can increase the control of the use of personal information by the most trusted users. Further, the user can establish an electronic distribution process of control information in which a transmission rule is attached to information. Thus, when a user approves the remote processing of trusted personal information, the information is used in a manner that allows the user to maintain control and control over how the information is subsequently utilized.

The preferred embodiments additionally allow individuals to establish rules for personal information that deals with money or other valuable items. Personal preferences, physical characteristics, and purchasing habits are purchasing power for those products sold. Traditionally, sales companies would gather and organize such information and buy these mailing lists to merchants who have an interest in some users of a product list. With the preferred embodiment, an individual may allow their own personal information to be provided to a merchant, either directly or through a sales company, thus sharing the value resulting from the trusted processing of reliable personal information.

Referring now to FIG. 25, a user may see an example of a display when accessing an electronic metropolitan area network site. In this case, a computer user is running on their personal computerNavigation of network sceneAnd can be seen as standardNavigation of network sceneA menu item 501. To do this, the user must provide the web site of the e-metropolitan groupNavigation of network sceneTo do soNet Navigation person of sceneConnected to a web server at a remotely located e-metropolitan network site via the user's web server. Once the access is successful, the electronic metropolitan area network site sends the user this guide screen 511, which contains a geographic logo 505 and a title 503 specific to the electronic metropolitan area. The user may select one of three optional buttons; obtain more information on this electronic metropolitan area, enter the appropriate service for the electronic metropolitan area (which requires confidential registration), or if a new user is registered as a recognized user for the electronic metropolitan area. If the user chooses to register, the registration items will be provided by the e-metropolitan community or retrieved from an e-persona repository, and the user will create their e-persona, similar to filling out a standard form.

If the user selects the service option, the user will be queried for security information and/or hardware tokens. In fig. 26, the e-metro group only asks for a basic certification identity and a security code or password answer 515. Once the user selects "OK" 517, the user is allowed to enter this e-metro group and the user can utilize those available services. In this example, the members are presented in the group available screen 521 shown in FIG. 27, which is comprised of a logo 505 and group links 523. Those services available in this e-metro group include retrieval and selection, registration updates, advertising, shopping, customer support and other services selected by the e-metro group administrator. The search service provided in the electronic metropolitan community is useful for implementing parameter queries. FIG. 28 shows a partial view of members of the E-metropolitan area that satisfy a particular query request, allowing selected members to select a particular E-PIA by selecting a graphical connection 527. The requesting member is provided with an appropriate qualification set by the inquiring member, and the information of the inquiring member can be seen by the requester.

The preferred embodiment is premised on the user having at least one qualification of an electronic metropolitan area, a membership obligation and a right determined by the electronic metropolitan area. In a preferred embodiment, the e-metro group has three basic responsibilities. First, the e-metro group establishes a request to admit a person who has a high probability of who they say they are applying for admission. Second, e-metro groups have security tests in place to properly ensure that the identity of a member cannot be stolen by others. Third, the e-metro community establishes some criteria of being business and accurately disclosing honest members with a high probability.

The first responsibility for ensuring that the applicant says who they are is satisfied in the preferred embodiment in a two step process. In the first step, one applicant utilizesNavigation of network scene15 access the network site of the electronic metropolitan group they want to join. The user selects a registration object from an electronic personality repository 13, fills it out and submits it to the electronic metropolitan group administrator. An electronic metropolitan group administrator reviews the application to ensure that the applicant satisfies the qualifications of the electronic metropolitan group. If the applicant satisfies the qualification, the application process proceeds to step two. In step two, the applicant-The user's individual is presented to an electronic metropolitan group administrator or other trusted authority or institution (e.g., a certification authority or a fair) to verify the identity of the user. The applicant may present one or more identification tags such as a birth certificate, driver's license, passport, social security card or other authentic means of identification. Once the applicant is identified and a pair of keys is generated, they are issued a digital certificate in conjunction with the public key and the membership and e-metro group information. A secure password or challenge response access method is selected and a hardware token is selected if necessary. At least one digital certificate is provided to a member and access methods are fully utilized with selected and approved e-metro group services. Electronic metropolitan groups now reasonably guarantee who they say they are and have resolved the process of the registrant application.

A second responsibility of the e-metro group is to ensure that only the original applicant can use the member's identity. The digital certificate and secure password or challenge response described above will help to ensure the security of an individual's identity, but new technologies allow for even greater security. For such advanced security, the e-metro group may issue a hardware token or security card to the user, such as a commercial hardware token or security card sold by Gemplus, Schlumbarger, and Spyrus corporation. Although there are several options for the security card from Spyrus regarding being able to hold information, three particularly useful items are: 1) basic information about the user, 2) a digital certificate, and 3) an electronic metropolitan group digital certificate digitally signed by the verifying electronic metropolitan group. The first item may contain several pieces of information, including: passwords, security passwords, and special challenges or passphrases that can be used by the preferred embodiment to verify the identity of the user. For the security of this challenge, the user loads the security card with a challenge-response pair known only to the user. While the user is waiting to access the electronic metropolitan area, the security card queries the user by providing a query phrase that must be answered accurately. Second, digital signatures are an advanced security architecture that allows a sender to attach a digital signature to a specific document that is guaranteed to be created by the sender. A more detailed description of digital signatures is discussed below. Those skilled in the art may employ other options for ensuring the present security of a user's identity, such as biometrics. A third item, which may be contained in the card, stores information about the authority certifying this particular user. The authority may be a government agency, an electronic metropolitan administrator or agent, or a business. The higher his confidence in the credit guarantee for the member is if the security policies and procedures that warrant the agent have more liability, greater investment, and a more careful plan.

A third responsibility of the e-metro group is to ensure that members are properly transacting and that personal information is accurately and honestly disclosed. One major task for e-metro populations is to eliminate those who violate the interaction policy from the e-metro population. Strict enforcement of regulations will ensure that e-metro populations have better reputations in credibility and accuracy.

The next level of security is to ensure that members can communicate with electronic metropolitan areas without being able to intercept and obtain messages and information for authorized individuals, as long as there is a guarantee of membership. There are two main parts of this security level. First, the preferred embodiment employs a transaction security protocol approved by the netscape, including purchases over the internet with credit cards. In the second place, the first place is,navigation of network sceneWeb browsers have established encryption techniques, known as public key cryptography, which secure communications from members to electronic metropolitan groups without being externally intercepted and obtained. The preferred embodiment uses public key cryptography provided by RSA data security limited, usa, but other options are available to those skilled in the art.

Public key cryptography is a method currently well known for the secure transmission of information. A block diagram of the operation of a public key cryptography is shown in fig. 3. In this method, each user has a code pair, where one code is public and one is private. These codes are commonly referred to as keys, so each user has a public key and a private key. The public key list 25 is widely distributed to any user who may need to transmit information. However, the private key is kept secret by the individual. For example, if "A" wants to send a file to "B" in secrecy, A will encrypt the file with B's public key 19. This key is public and available to anyone who needs it. After encryption, the file 21 can only be decrypted with the private key 23 of B, which is known only to B. Thus, if B has an appropriately encrypted private key, only B will be able to receive and interpret the encrypted file. It does not matter if the file is sent via a transmission method without encryption, such as e-mail, the internet, or a telephone line, because nobody can intercept the information and interpret it unless they somehow misappropriate the private key 23 of B.

The second security mechanism is the digital signature previously described which ensures that the recipient information is indeed sent from the sender indicated by the information. As can be seen from the brief discussion above, a member can sign a document using a digital signature, giving a high degree of assurance that the information was sent by the signer. Fig. 4 will help describe the use of digital signatures. To apply a digital signature to a document, the member transmits the document 27, or a message digest 33 unique to the document, through a mathematical formula 31 that generates a digital pattern. This message digest 33 is then encrypted with the member private key 23 described above to generate a digital signature 29. This digital signature may then bind a particular file to a particular owner of a private key. The member then attaches a digital signature 29 to the document 27 and sends both to the recipient. In this example, the file 27 is sent unencrypted, but if the file must be sent encrypted, the member can encrypt this file using the public key of the recipient using the method described in the previous paragraph. When the file and signature are received, the recipient interprets this digital signature 29 using the sender's public key 19, resulting in a digital pattern 33 unique to the file 27. As previously mentioned, the public key is from a publicly available public key list 25. If the digital signature 29 is made with the private key of any other user, the resulting pattern will not match the file, and the recipient will know that the file was not sent by the intended sender. Using digital signature techniques, the preferred embodiment is highly assured that a particular document is being sent by a particular member.

By adopting the technology, the safety and the accuracy of information and commercial transaction are reliably ensured to a great extent. However, security is only part of a successful internet interaction. Currently, interaction over the internet is a person-independent and often random experience. One common evaluation of using the internet is that online interaction does not allow us to locate, understand and know the identity or message of an email behind a guarantor-hear it, watch it's appearance, know some personality, characteristics, and reliability about the sender. Without this, the interaction is not only personally unsatisfactory, but also frustrated and useless.

Virtual groups are forming but people rarely control their digital characters or interactions with certainty, and most of the theoretical basis behind these virtual groups is the concentration of data. This data set is searched by business entities to track customers, enabling constant and granular group membership surveillance. Customers strongly demand control over their personal information and they demand legislative return to prevent such concentration, tracking and processing of unconstrained personal information. The present invention creates a trusted virtual community that enables the privacy of information and the self-determination of information where people can individually and collectively request ratings to exchange access and process personal information to control the attributes that make up their information presence.

A digital character or internet personality is determined by personal information appropriate for the individual. The more complete and reliable the information, the more accurately the internet character reflects the character of the real life. This personal information can be used not only to accurately determine the presence of an online, but also, as previously mentioned, has commercial value to others. Personal information can take many forms, including health, financial and legal records, school achievements, employment history, or purchasing preferences. Each of these pieces of information, if accurate, is a resource that can interact efficiently and pleasantly with others over the internet. In a preferred embodiment, these information resources are compiled and tailored to others according to the desired gathering of members of the individual e-metropolitan population. All the personal information, as a whole, constitutes an electronic character or digital character of an individual. For purposes of clarity and ease of description, such an electronic character is considered useful as an electronic personal information agent or E-PIA at a network site electronic metropolitan area, as previously described.

Some of the information resources of the E-PIA are created and maintained by others, but may be scheduled and processed according to rules inserted in the E-PIA, such as medical records and school transcripts. Other sources are some that may be written by members of the e-metro group. The preferred embodiments allow one member to guarantee by itself or collaboratively that the information sealed in the E-PIA is accurate and reliable.

In FIG. 29, one user usesNavigation of network sceneAn electronic metropolitan area network site has been visited and the initial registration application form 21 is displayed. A standard netscape interface 25 is located near the top of the figure. In particular, the user interface includes a menu bar 25, control buttons 27, quick access tree structure 37, and a communication activation indicator 31. In addition, the key graphic 33 located near the bottom of FIG. 29 tells us that security is in operation, so all communications with the electronic metropolitan site are encrypted.

The registrar may locate other data item areas (professional, financial, medical) shown in the left most scrolling window notebook. If the user selects the professional data area 37, the user will see the professional side and start data entry or update information.

FIG. 30 is a calling E-PIA showing a portion of a personal profile. In fig. 31 is a continuation of the chapter not shown by the E-PIA home address of Dieter, and a close lock icon is distributed along with data on the right. This means that the person requesting access to this piece of information does not satisfy his access processing rules and the Dieter does not want to publicly manage what the access processing is. When the Dieter completes this personal profile, he creates a rule graph 32 to determine who has access to each item of information. Since the user's access to the profile does not satisfy these rules, neither the home address nor other information is appropriate. In the preferred embodiment, if the access information is denied, this gives the opportunity to see what the rules are and to respond to the right panel 31 indicated to the home phone by the open key icon.

In this example, Dieter has several options for rule processing based on the anticipation of Dieter rule interaction and the level of sequential control he wants to maintain and delegate to E-PIA. Dieter simply wants the requesting user to exchange their home phone number and a simple rule exchange will start. Either the processing of this rule will be done at the requesting client site that determines that the rule is satisfactory, or the information system will be activated with a message that is his home phone provided by the master E-PIA request sent back to the Dieter or a signal to his E-PIA dispatch to send a display approving decryption and encapsulation of the home phone data.

An automatic ground rule response can be executed on the client site that presents the predetermined rule exchange and can continue the user service conversation or delay the interaction supported by the messaging system that will continue the rule interaction. The Dieter's home E-PIA may already have a response established by a rule that indicates that if you show me your, i will show me to you, so this informational response is semi-automatic.

In case the Dieter has determined a rule at the requesting client site for processing his home phone data, the exchange is performed and a client side information is raised to the Dieter's E-PIA. So, in the requesting user's E-metro client application, Dieter's dispatch E-PIA receives a signal to encrypt his home phone number for control access. The rule interaction agent in the e-metro client application checks to see if the home phone is already fully provisioned.

In the above case, the E-city group electronic agent has scheduled a ready-to-load E-PIA with sealed encrypted data that will preserve the transmission of information, rule processing, and sequential responses, etc. governed by the rules rights at the customer's side. Before releasing his data to the E-metro virtual private network, or dispatching the data and rules within this E-PIA for processing, the Dieter will decide on the client how he will trust that he can rely on the system to fetch the data in return.

The rule response dialog displays some rules and gives the requestor the choice to respond to. The rule may specify a financial transaction to occur. In this case, the user approves a debit from their e-metro purse for demand with rules.

The rule details are set forth in fig. 32. The chart depicts a dialog screen in which Dieter is positioned to the left of his PIA data distribution 545 and the listing lists which rules will govern this distribution or group of distributions. An access group is a tool that groups rules by a particular group or sub-group 540. The initial contact is a column Dieter that has specified it as a sub-group in which his age attribute rules are not disclosed and this attribute is in lock 550, i.e., not shown in the initial contact summary.

His other attributes: city, birthday, etc. are public and will be displayed on the process. With this screen pointer, a "know needed" prompt can be created, here a user who needs to know the prompt request. Dieter must also process his own response via the electronic metropolitan information system. Some information interactions are automatic by pre-establishing rule responses such as "i will show you my if you show your rules". The home E-PIA of Dieter is able to automatically reflect the dominance information.

Some data attributes will have time to request that the E-PIA allow a significant amount of time to pass for viewing and processing the E-PIA's data. A related situation is that Dieter only allows 24 hours to pass and then his E-PIA locks itself to avoid further processing.

The initial association 555 of the sub-population as shown in FIG. 33 must satisfy the above rules 565 and 560 in order to handle Dieter's E-PIA. Dieter is specifying the criteria that others must meet before processing his E-PIA.

The group members will send requests to the E-city for processing and there may be several decisions to invoke the E-PIA for a query that may not be sent due to the fact that the requestor does not comply with the individual's rules. The E-PIA of Dieter in the previous case was sent as a personal request meeting the above criteria.

As shown in fig. 2, the electronic character repository 13 may be anywhere on the internet, i.e., it may be on the same server where the electronic metropolitan area is located, or the electronic metropolitan area may exist elsewhere on the internet with an electronic character. When a member joins an electronic metropolitan area, one of the first tasks based on user judgment and profile should be authoring. These profiles, plus any information from outside sources, constitute an E-PIA representation of an individual on the internet.

In this embodiment a user may belong to several electronic metropolitan groups. However, the user must select an e-metropolitan group that should be the main e-metropolitan group. The selected electronic metropolitan group houses a "master E-PIA" designated to keep all members tracked by other electronic groups. In this approach, changes in one master E-PIA can be used to update information in all other populations if needed. Once a member has joined an electronic metropolitan group and designated the electronic metropolitan group as his main group, the member can simply satisfy the request to allow entry to the next electronic metropolitan group and then copy this E-PIA to the new electronic metropolitan group. As will be discussed in a subsequent section, when a member desires to create a particular E-PIA, referred to as E-AutoPIA, which has the ability to move to other electronic metropolitan areas and perform the requested task, the E-AutoPIA can only be derived from the master E-PIA. The E-PIA then has a subset of the information contained in the original host, so that any encountered E-AutoPIA is guaranteed to carry information that is relevant to a host E-PIA.

A member defines rules for the access process of their personal information to ensure that the information is properly processed. When a user attempts to access personal information of a member, the present embodiment checks whether the user meets the requirements for trust processing of information. This embodiment only delivers an E-PIA containing information to the requesting user, which information user has the right and is entitled to processing. These rules define some constraints on information processing and form the basis for interactions between some E-PIAs in the E-metro community. That is, when a member represented by one E-PIA contacts another member's E-PIA, the two E-PIAs can determine what information can be exchanged, even if at all, without any simultaneous input from the representative persons. The details of this rule check are discussed in the next section.

The E-PIA in an E-metro group has been briefly described in this regard as a personal information repository with the ability to selectively publish information according to rules, and only functions within a unique E-metro group. However, in a preferred embodiment, the E-PIA may also take a more active form of structure, referred to as an E-AutoPIA, that is generally not capable of managing the behavior of other E-PIAs and other E-PIAs of other E-Metro populations. The E-AutoPIA contains a subset of the personal information and the rules of the full E-PIA, with an additional route guiding his behavior. The route tells the E-AutoPIA which electronic metropolitan group to visit, what information to gather, and what information to process in conjunction with the rules. Then, using one route, the E-AutoPIA will "move" to the nearby Internet, accessing other electronic metropolitan groups that can interact with the E-PIA in each of the electronic metropolitan groups.

In a preferred embodiment, the E-AutoPIA does not interact directly with other E-PIAs. Instead, each E-metropolitan group has at least one process that acts as an agent between the E-AutoPIA and the E-PIA of the E-metropolitan group. This agent was an electronic agent that appeared in the early days. When two E-PIAs or one E-PIA and one E-AutoPIA desire to interact, both parties introduce the electronic proxy with their respective rules and the electronic proxy determines what information, if any, can be exchanged. In addition, an electronic metropolitan group administrator may set a minimum rule to appear on this electronic metropolitan group that applies to all electronic agent intermediary transactions, ensuring that only transactions that meet the minimum electronic metropolitan group criteria appear.

As implied, there are two modes of E-PIA interaction. A user, having his member E-PIA electronically represented within an electronic metropolitan area, may activate a single interaction for the electronic metropolitan area via his web browser and appropriate HTML files. This is known as Online Interaction Mode (Online Interaction Mode). When the E-AutoPIA activates some interaction within an E-metropolitan population, this is called a batch interaction Mode.

Figure 5 conceptually illustrates a network site E-city group 35 that includes several E-PIA (members) 37. For any interaction, member 37 must use the services of electronic proxy 39. The E-AutoPIA 41 may be outside the community of the electronic metropolitan, as shown in fig. 6, and the E-AutoPIA 41 may have a way to direct him to interact with electronic agents 39 in the electronic community 35 of several other network sites.

This electronic proxy has three main functions within the electronic metropolitan area. First, the electronic proxy has been determined by the E-city group administrator to check the credentials of any E-PIA that wants to enter the E-city group. In this monitoring role, the electronic agent checks for proof of identity, approves identity, and queries for entry purposes near the E-PIA. After applying these rules set by the E-city group administrator, the E-agent will either deny access to the E-PIA or allow him to enter the E-city group. Second, the electronic agent acts as a member seeking to satisfy the criteria specified by one E-PIA during its request interaction. For example, if an E-PIA enters an electronic metropolitan area to find members interested in buying a car, the request is passed to the electronic agency. Then, using several subsystems suitable for the preferred embodiment, the electronic agency queries all members for those who have indicated an interest in buying a car and establishes a list of all members that meet the necessary criteria. Third, the electronic proxy acts as an intermediary between the E-AutoPIA and the E-PIA of the E-City group. In the above example, the electronic proxy may act as a mediator even after the electronic proxy has established a list of members that indicate an interest in purchasing new vehicles. E-AutoPIA introduces his rules for gathering information and, if so, determines what information is to be exchanged. Of course, even if two people agree to exchange information, the e-metro group administrator may set a more strict rule that will not allow the e-broker to complete the transaction.

One of the logical tasks that an electronic agent can negotiate is the controlled processing of member personal information. In the event that both the E-metropolitan group and the user wish to process personal information, the E-agency is notified to collect money from an E-PIA accessing the desired personal information. In a preferred embodiment, the money charged may be distributed to electronic metropolitan groups, members, or between them. An electronic metropolitan group with substantial membership may find an attractive way to provide funding to other electronic metropolitan group services.

An electronic metropolitan group can provide several services to its members. These services may include functions within the group such as collaboration groups, consensus combining or election systems, basic payment systems to manage group revenues generated from the services, online customer satisfaction databases to protect the customer's promotional responsibilities and reasonable resolution of customer opinions, or specialized subsidies provision of advanced wireless communication devices to facilitate ' equal access ' policy objectives. The e-metro group may also provide external group services such as mobilization to access cross-communities for charitable or political purposes, common e-commerce, and sharing of communication infrastructure costs for all members of the community using superior or newly introduced wireless networks and technologies for cross-communities.

A typical physical structure of the preferred embodiment is shown in fig. 7, in which a user 43 accesses the internet 1 using a personal computer 45 to connect to a web server 11, and the web server 11 connects the connection to the internet 1. Both wired and wireless connections will be supported by more than one electronic metropolitan group that can belong to the network server 11 and the electronic metropolitan groups may even form a hierarchical relationship. That is, an electronic metropolitan group may contain not only members, but also other sub-groups. Fig. 7 shows one, two or three e-metro group network servers 11 on each server. Further, electronic character objects that write personal information for a particular electronic metropolitan area may be requested from an electronic metropolitan area electronic agency or, if publicly available, in the electronic character repository 13. The preferred embodiment allows any common storage subsystem for the eCommunity objects. Two possible storage subsystems are an FTP site or a mail server that is simply a file storage and communication system that maintains the categorized file types, and may be adapted to depart from this framework from the internet scene or other buyer. These eCommunity repositories may be on any server 11 or 13, or the eCommunity home phone may even be held by the user on his personal computer 45 or wireless communication device 42.

We now turn to the specific software implementation for the preferred embodiment. The preferred embodiment is a modular application, i.e. the application is divided into several parts, each part or module being assigned a specific function. Some of these modules are designed to operate on one or more servers while others are designed to operate on the user's local computer system. The users and servers necessary for the preferred embodiment are shown in fig. 8 and are associated with the physical devices shown in fig. 7. Referring to the two figures, with their personal computers 45,user 43 runsNavigation of network sceneA web browser 49, a commercially available application.Navigation of network scene49 allow the user to conveniently access any electronic metropolitan area site. In addition, the optical fiber is provided with a plurality of optical fibers,navigation of network sceneOther netscape product compatibility with special tools for the preferred embodiment is provided. Except thatNavigation of network sceneThe user runs several utilities locally that support the electronic metropolitan organization. These special applications may be DDLs (dynamic link libraries), Java applications, applets and procedures, or some other code similar to the nature of supporting a special electronic metropolitan entity. However, as previously mentioned, in almost all cases, no additional subsystems or DDLs would be necessary.

At the heart of the preferred embodiment is a network site electronic metropolitan area system 47, which operates on a network server. The top level of the website electronic metropolitan area system 47 architecture is intended to be shown in fig. 9. The system includes a distributed object resource management system (distributed object resource management system server) 57, shown in greater detail in fig. 10, a netscape enterprise server 59, a netscape application programming interface 67, a pay-on-site payment card transaction processor 61, an FPT server 65, and an FPT client. Each of these system elements will be discussed individually below and then their interactions will be described, but an important consideration of security is addressed first.

It is necessary to ensure that only strict security is required for communication and information dissemination to occur. Security can generally be divided into two categories: 1) security structures ensure that eavesdroppers or casual recipients cannot extract the information, and 2) security measures ensure that the information is only distributed to trusted entities. The first type of security is accomplished by using encryption techniques to transfer data between multiple entities. Referring to FIG. 24, several Web site electronic metropolitan area systems 47 are shown with a preferred embodiment of user access with a Web browser. Each web site electronic metropolitan area system 47 operates in a secure process on a web server. Anyone skilled in the art of dealing with security would like to be able to create a local security process for each web site e-metro group system 47. For intra-population communications, each website e-metro group system 47 maintains its own private key and public key for encryption.

A dual encryption technique is used when a source electronic metropolitan group wants to communicate with another destination electronic metropolitan group, such as when an E-PIA is transmitted. The source electronic metropolitan group secrets this information with the public key of the destination electronic metropolitan group. The source electronics metropolitan group then re-encrypts the now encrypted information, but this time with his own private key. Each electronic metropolitan group is aware of all other electronic groups and their public keys. When the destination e-metro group receives a message, it first decrypts the message with the public key of the source e-metro group and then decrypts the message with its own private key. This "double" encryption guarantees to the destination electronic metro group that this source electronic metro group is indeed the source electronic metro group mentioned in the information and also guarantees to the source electronic metro group that only this destination electronic metro group will be able to decrypt the desired information for it. Similar security checks are used for communication from an electronic metropolitan area 47 to a user.

Another important security aspect relates to ensuring a source of E-PIA or E-AutoPIA. The assurance of this origin is shown through the use of a proof 150 and trust token 159. The certificate is held by all E-PIA and E-AutoPIA and contains names representing people and entities and their associated public keys. Because the personal information held by the E-PIA or E-AutoPIA has been encrypted with the private key of the individual or representative entity, if the public key in the certificate matches the public key and the personal information is decrypted correctly, this must be the E-PIA or E-AutoPIA from the specified source. Each interaction that must be kept secret will require an issued trust token. Before an electronic agent acts on a request interaction, it will look at the requesting E-PIA to ensure that it has authorized the pre-interaction. Each trust token must be associated with a particular interaction and must be encrypted with the private key of the requesting E-PIA. By using a public key known to the requesting E-PIA, the trust token can be decrypted and compared with the expected value, so that for this requesting E-PIA the ability to request the guaranteed interaction is actually obtained specifically.

The second security structure ensures that this information is only issued to trusted entities. When one E-PIA gives some of his personal information to another E-PIA, the given personal information is also secure and owned by the original E-PIA, so that subsequent dissemination is controllable. This structure involves the initial distribution of information and subsequent dissemination by other E-PIAs. The initial publication of information is controlled by both the metro group administrator with the web site and the personally set rules that must be satisfied before the information can be published. An e-metropolitan administrator may set some rules that apply generally to all potential exchanges of the e-metropolitan group of the network site, allowing the e-metropolitan group to maintain control over the types of transactions that may be accepted. Also, the individual can arrange a rule for each of their personal information in the E-PIA. By setting these rules, the E-PIA will only share information with one trusted principal in one trusted environment. One more difficult problem relates to the subsequent dissemination of control information. In fact, if the recipient of the information in turn transmits the information to a third E-PIA, the preferred embodiment still retains the information of the original owner of the personal information and continues to police access to the information. This subsequent security is set by the transmission priority rule declared by the original E-PIA. The transport priority rule creates a transport trust such as: if A believes B has information X and B believes C has information X, then A believes C has information X. This important content guarantees to a that its information is never transferred to an entity that it does not trust, according to the transmission priority rules that have been announced for submitting data. The information is always transmitted as a text of the E-PIA that submitted its information. For example, assume that an E-PIA contains a rich set of information including date of birth, address, phone number, etc. Also, assume that it wishes to only publish its phone number to another in one interaction. The receiving entity will actually receive an E-PIA reported by an E-PIA object that contains only the telephone number. In particular, the received E-PIA object is the original E-PIA text that represents how the submitted E-PIA expects to be received in advance by the receiving entity. Fig. 6 depicts the receipt of text 40 by one propagating E-PIA of some E-PIAs. The text of the E-PIA object is merely the way in which information is exchanged in the preferred embodiment. The distributed object resource management system is the work center of the network site electronic metropolitan area system 47. As shown in fig. 9, the distributed object asset management system server 57 keeps track of the core behavior of several systems, including electronic metropolitan/storage, electronic agents, and affiliates, E-PIA keeps a directory of all electronic metropolitan groups on the internet, keeps automatic personas, and keeps track of the E-PIA's interactions with E-PIA and E-AutoPIA. Each of these actions will be discussed below.

The behavior of the distributed object asset management system server 57 is implemented with a series of interrelated subsystems, as depicted in FIG. 10. The interaction handler 73 is a key subsystem of the distributed object asset management system server 57 and is responsible for all external communication and most internal decisions. Whenever the interaction handler 73 decides on a particular course of action, the action is implemented by the use of an electronic agent process. There are several electronic agents that are adapted to accomplish a particular, ongoing task. The operation of the interaction handler is discussed in detail in a later section, but first other distributed object asset management system server functions and respective subsystems will be addressed.

The distributed object asset management system server is responsible for the storage of electronic metropolitan groups, electronic proxies, and E-PIA. Although each of these items is different, they all exist in a common structure within object store 75. Object store 75 uses a simple object oriented interface on a relational database. This relational database may be any database operating on a web server, such as a common Oracle database system.

The electronic metropolitan group, the electronic proxy, and the E-PIA are all objects in the preferred embodiment, and for the electronic metropolitan group, the electronic proxy, and each instance of the E-PIA are assigned a unique object identifier, or OID 91 (original identifier). These features are then stored with the OID 91 in the form shown in fig. 11 a. This diagram shows the structure of each row of a table within a relational database. Referring to the diagram, the OID 91 is located in the first field. The next field collects the original identifier 93(CollectionOID 93) identifying whether this object is included in other objects, e.g. several electronic agents, E-PIA, or even other electronic groups may be related to a single electronic metropolitan group. Thus, collecting the original identifiers 93 is a method for tracking hierarchical relationships between electronic populations and a method for tracking electronic agents and E-PIA assignments within a particular electronic metropolitan population. Following the collection origin identifier 93 are several public key fields 95 containing information about the object selection. These fields are some "public keys" that can be used to make queries and selection criteria through the database program. In the preferred embodiment, six public key fields 95 are provided for each row of the database table. Of course, more or less public keys may be used, or alternative querying techniques will be apparent to those skilled in the art. The special nature of the public key is left to the electronic metropolitan group administrator, so allowing the electronic metropolitan group to control some of the fields that are most efficient for efficient queries. The last item in this line is the item itself, which is stored in the format of BLOb (binary Large object program). The BLOb format is a standard database storage structure that allows a single field in the database to hold multiple discrete pieces of information and is not affected by the content of each piece of information. Therefore, it is a slow operation for the distributed object asset management system server to be able to search the object store 75 for the public key field 95, typically to quickly select the appropriate object, and then to extract and view the object itself from the BLOb format.

As described above, the electronic metropolitan group, the electronic proxy, and the E-PIA all use this common row structure. However, each uses a slightly different naming convention. The convention used by the E-City group is shown in FIG. 11 b. Note that the collection origin identifier 93 is located as a master metro group by a master origin identifier 99 (parenthoid 99), if desired. In this manner the preferred embodiment maintains a hierarchy for the e-metro population. The only difference is that the first public key field 95 is arranged to hold the name of the e-metro group. Since database engines often use the names of electronic metropolitan areas to search, it is appropriate to have a private public key as the name for all electronic metropolitan area items.

The row structure for an electronic proxy is shown in fig. 11 c. Like an e-metro group, the first public key field 95 is the name, which in this case is the name of a particular e-agent. However, the Collection origin identifier 93 field contains the OID of the electronic proxy's "own" electronic metropolitan group, so that a particular electronic proxy is integrated with a particular electronic metropolitan group using the group origin identifier 101. This integration method allows an efficient way to know which electronic agent is allowed to operate within an electronic metropolitan area. Furthermore, this same bonding method is implemented with a row structure of E-PIA, as shown in FIG. 11 d. In the E-PIA, the Collection origin identifier field contains the metropolitan group origin identifier 101, so that a particular electronic agent is associated with a particular electronic metropolitan group. As seen in fig. 11d, all six public keys are uncertain in the E-PIA row structure, allowing the electronic metropolitan area administrator the flexibility to define each field to meet the needs of a particular electronic metropolitan area.

Referring to fig. 10, the distributed object asset management system server 57 also maintains a current directory of all electronic parties on the internet. This Directory is maintained by special electronic agents called Directory agents 77(Directory Broker 77) within an electronic metropolitan area, each with a Directory agent 77. The directory agent 77 keeps track of all electronic groups on the internet and their addresses. In addition, the directory agent 77 keeps information on all other electronic agents in all other electronic groups on the Internet. The information maintained includes the names of the electronic agents, rules, and other information that the electronic metropolitan group administrator wishes to maintain about other electronic agents on the internet. To maintain current directory information, a directory electronic agent 77 of an electronic metropolitan area will periodically query to see if its electronic metropolitan area has been added, deleted, or changed for any electronic agents or electronic groups, and if so, the electronic agent 77 of the directory will issue an E-AutoPIA. This E-AutoPIA will be sent to all other electronic communities for interaction with other directory agents, updating each electronic metropolitan community with changes. The number of this update must be variable, but most likely the schedule updated once per day will be sufficient to support accurate e-metro group interactions.

The distributed object asset management system server 57 also contains an information system 71 that allows an electronic metropolitan area to send one E-AutoPIA to another electronic metropolitan area. As can be seen from the graph, the distributed object asset management system server 57 communicates with other remote electronic metropolitan groups through FTP clients 63 and FTP servers 65. Although the FTP process is shown as being directly connected to the information subsystem 71, the actual communication is controlled by the interaction processor. FIG. 12 shows a more detailed information subsystem diagram. As previously discussed, the information subsystem 71 utilizes the FTP protocol to conveniently send and receive information from web-site based electronic communities. This information subsystem is dedicated to the transmission of E-AutoPIA from one electronic metropolitan group to another. When an E-AutoPIA is sent to another remote electronic metropolitan area, the interaction handler 73 first retrieves the address of the remote electronic metropolitan area using the directory electronic agent 77. Interaction processor 73 then packages the E-AutoPIA with this remote address and forwards this package to sender dispatcher 105. The sender dispatcher 105 places a message in the message queue 109 and notifies the FTP client 65 that a message to be sent (automatically packaged with the e-metro group address) is ready. When convenient, the FTP client 65 sends the information (automatically packaged with the electronic metro group address) to the recipient's electronic metro group's FTP server and thereafter erases the output information to the information queue 109. The receiving dispatcher 107 monitors the information queue 109 and when a new message is seen, he unpacks the message and presents an E-AutoPIA. The receiving dispatcher 107 then informs the interaction processor 73 that a new E-AutoPIA has arrived and the interaction processor 73 decides what to do with the E-AutoPIA next. The information entered in the information queue 109 is not deleted until the E-AutoPIA has completed the task within the electronic metropolitan area and is left for the electronic metropolitan area. Storing the entered information ensures that the tasks specified by the E-AutoPIA will be completed even if the distributed object resource management system server is erroneously shut down and the current activity of the E-AutoPIA is lost on the network server. When the web server reboots, the E-AutoPIA can reboot from the original information and complete its task. The message queue 109 itself is a standard FTP file system that may consist of an input file and an output file. It will be clear to those skilled in the art that other transmission methods may be substituted for the FTP process described above.

The virtual interpreter 81 is a software subsystem that provides a text language and a rule language that can perform the preferred embodiment. The virtual interpreter 81 plays a major role in the use of the rule processor 79 and the route processor, both discussed in the following section.

The distributed object asset management system server 57 contains a rule processor 79, which is an important subsystem to ensure that information is distributed securely. These rules are used by a member or electronic metropolitan group administrator to set limits and controls for personal information distribution. These rules are actually a series of strings written in the programming language selected for the preferred embodiment, which determines the requirements at which the information is to be released. Which can make these rules simple or complex as required. The electronic metropolitan group administrator may provide minimal rules to be applied to all transaction processing and allow members to adjust these rules for their particular needs. Although the preferred embodiment utilizes an application to set the rules, those skilled in the art will appreciate that several alternative methods are available for entering rules for a user or administrator.

As previously mentioned, a request for personal information of a member may come from either of two sources: and the other E-PIA member or one E-AutoPIA respectively adopts an online interaction mode or a batch interaction mode. If an E-AutoPIA enters an electronic metropolitan area and requires information from a member, the interaction handler 73 will initiate an electronic agent to handle the request. The processing to control this request is described in detail below for all subsystems in the next section, but in general the electronic proxy accepts these rules defining the request standard for E-AutoPIA and sends them to the rule handler 79 via the virtual interpreter 81. Rule processor 79 transforms this request into a standard database query request, such as a standard SQL (structured query language) select command, and runs the query to select E-PIA from object store 75. The E-broker then accesses the rules for each selected E-PIA and sends them via the virtual interpreter 81 to the rule handler 79, and the rule handler 79 compares the request set by the member E-PIA with the characteristics of the E-AutoPIA, and if the request is satisfied, the E-broker sends the request information from the E-PIA to the E-AutoPIA.

If another member of the same e-metro group requests another member's information, the process is similar, albeit very simple. In this case the interaction handler 73 again initiates the electronic proxy process, and the electronic proxy sends the rules for each E-PIA through the virtual interpreter and finally to the rule handler 79. The rules processor 79 compares the rules for each member and decides what information to propagate satisfactorily if necessary.

As with the earlier previews, an E-AutoPIA is instantiated from the user's E-PIA and includes a route. This route is a set of instructions that direct the E-AutoPIA activity. Thus, the E-AutoPIA acts as a proxy for the user. The route, like a rule, may be a program written in Java, or other convenient language chosen for the preferred embodiment. As with these rules, those skilled in the art will understand the methods of directing an E-AutoPIA to have a centralized alternative to creating a route.

The virtual image 85 is used to improve the performance of the preferred embodiment by placing a selected piece of information in local RAM (random access memory) for quick access. The system operates more efficiently because it can read information in RAM much faster than it can recover information from a database on a hard disk, such as object store 73. Whenever the preferred embodiment requires an electronic metropolitan area, electronic proxy or E-PIA, an electronic proxy selects the required entities from object store 75 and places a copy of the entities in virtual image 85. From this point forward, the system uses the copy in image 85 without the original in object store 75.

As is apparent from the foregoing discussion, electronic agents are processes that are performed on a network server and are used within an electronic metropolitan area to assist in the orderly and efficient operation of the metropolitan area. There is at least one electronic agent per electronic metropolitan area, but there may be more than one. In the preferred embodiment there are two special electronic agents, but there may be more. The first is the hosted directory electronic agent 77 and discussed previously. The second must exist in the electronic community that requests secure modified access to the E-PIA and is referred to as the master electronic agent 87. The master electronic agent 87 is responsible for ensuring that only the owner of one E-PIA has written access to his master E-PIA. The master electronic agent may be configured to request very strict security access, such as having a member use a security card, password, and challenge system, or may be established with poor security, such as just having a member provide a proper member identity name.

Each electronic agent is a client that is built to run executable on a web site. Each executable electronic agent 76 implements a special set of E-PIA interaction choices provided by the electronic metropolitan group to which it belongs. When an E-PIA requests a particular interaction, the interaction handler 73 activates the electronic proxy of the electronic metropolitan area and tells it to try the requested interaction. In order for the interaction processor 73 to communicate with each executable electronic agent using a unified communications protocol, an electronic agent adapter 74 is used. Thus, the interaction processor 73 actually communicates with an electronic agent adapter 74 specifically established for the executable electronic agent, which in turn communicates with the executable electronic agent 76. Thus, the electronic proxy adapter 74 acts as a "bridge" for communications between the interaction processor 73 and an executable electronic proxy. The structure of such adapters is necessary because electronic agents constructed from C, C + +, Java, Visual Basic, PowerBuilder, or other development environments may require different means for invocation and information transfer.

As a means to help all executable electronic agents may need to execute the necessary active structures, an electronic agent service API DLL (application programming interface dynamic link library) is provided as part of the distributed object resource management system server subsystem. The electronic proxy must be able to call the APIs in one DDL to use these useful services. Some services have been defined as: 1) inputting a set of rules and outputting a list of E-PIAs within the electronic metropolitan population that currently satisfy the rules; 2) interacting with a transaction server to implement credit card processing; 3) filling a credit card bill; 4) a security card for online access is authenticated. Those skilled in the art will appreciate that other APIs may be added as needed.

In reference to fig. 9, the DORNS 57, FTP client 63, and FTP server 65 of the website e-metropolitan area system have been discussed so far, and the field payment server 61, netscape enterprise server 59, and netscape API67 are described in detail later.

The on-site payment server 61 is a suitable for commercially applying payment card transaction processing, event logging, and settlement from the netscape control. The live payment server 61 will customize to control payment card transactions. At any time a transaction is invoked by an electronic agent for the transfer of money or price, the electronic agent sends the information to the interaction processor 73, and the interaction processor 73 forwards the data to the user live payment server 61. Further, when the user's live payment server 61 needs to send information to an electronic agent, as for a credit card approval use notification, the user's live payment server 61 sends the data to the interaction processor 73, and the user's live payment server 61 forwards the information to an appropriate electronic agent. The respective electronic agents and E-PIA may define their own billing policies that allow a member or electronic metropolitan administrator to charge a fee for the delivery of information. As an example, an e-metro group administrator can set a cost of $ 1 per name and issued telephone number, but an individual may also attach a request to charge $ 0.25. The cost rises to $ 1.25 if an E-AutoPIA wants to use a user name and phone number. Because the customer live payment server 61 is aware of financial transactions within all electronic metropolitan groups, it can very easily build accurate bills and financial summaries.

The netscape enterprise server 59 is also part of the website electronic metropolitan group system 47. The server is a standard commercial offering from a netscape and when operating on a web server allows the web server to be a web site, communicating over the internet, effectively communicating withNavigation of network sceneAnd (6) interacting.Navigation of network sceneAs previously described, work on a user's personal computer and is a client to the netscape enterprise server 59.

The standard netscape enterprise server 59, while providing basic facilities to allow the web server to be a web site and access the internet, must be enhanced to provide the necessary services and facilities to support the electronic community of the preferred embodiment. The netscape enterprise server 59 may be modified with a netscape API67 (application programming interface). Netscape API67 is a set of commands that are fetched from any program to implement the functionality of modifying enterprise server 59. In a preferred embodiment, for example, the netscape API67 is a security measure and method for modifying standards in response to a request. Now that all systems and subsystems have been described, a specific example will be used to demonstrate system interaction. For this example, assume that a remote user has established that an E-AutoPIA is to enter a prototype electronics metropolitan area to retrieve information on selected members of the electronics metropolitan area. Reference is made to fig. 7, 8, 9, 10, and 12 for the following process sequence. For convenience, these steps are configured as preliminary steps that will be done exclusively once the E-AutoPIA is initialized, and the request control step is repeated each time an E-AutoPIA requests the E-AutoPIA for information about the E-metro group.

The preparation method comprises the following steps:

1. an electronic metropolitan administrator loads the preferred embodiment on a web server 11. The administrator installs the electronic metropolitan group using an electronic metropolitan group management tool. The administrator also creates several electronic agents for holding requests or transacting financial transactions, such as from E-AutoPIA. The electronic agent may be a software module that consists of modifying an existing electronic agent or by writing a new electronic agent that adapts to the electronic agent adapter structure in any programming environment. The administrator, in turn, defines which services (interactions) are appropriate for the member and creates a screen display for the member. The latter is done using a standard netscape enterprise server 59 or any other tool capable of creating web site pages. The administrator either creates or modifies the presence admission form and places the form in a form object store 13. The table store 13 may be on the same web server 11 as the metro group or on any suitable remote web server 11. Finally, the electronic metropolitan administrator introduces an online electronic metropolitan group and immediately announces the appearance of a new electronic metropolitan group. The electronic metropolitan group is now ready for members.

2. Internet users or members of other electronic groups are beginning to know this new electronic metropolitan area and access the electronic metropolitan area network site address for more information. Using their personal computer 45Navigation of network scene49 they join an electronic metropolitan group. They can take the admission form and submit the request information. In this regard, the administrator may manually review these admission forms for the complete and minimal e-metro group request, or perhaps the administrator will automatically review the forms for the minimal e-metro group request and the administrator will review the forms for the minimal e-metro group requestIf the form is accepted, a private appointment with the user is scheduled. Upon other requests set by the e-metro group administrator, the user may be notified to come to the e-metro group administrator's office or some other trusted agent authority and provide sufficient identification and documentation to prove to the administrator that the user is what they are. If the e-metro group requests that the reserved security measures be indicated, a password, a security card, or other security technique is issued to the user. If all are in good condition, the user will become a member of an electronic metropolitan group. If the e-metro group that the member has selected will be his/her main e-metro group, they must enter a complete personal and professional profile, including written records, such as medical and legal profiles, maintained by others. When the e-metropolitan group is not the member's main e-metropolitan group, only a subset of the information needs to be submitted and it will be directly obtained from the main e-metropolitan group to which the new member belongs. Several other users may also become members of this e-metropolitan group.

3. At this point there is a main metropolitan group of electrons currently associated with the active member. The member may use the services of the main electronics metropolitan group to communicate with other members or create an E-AutoPIA that can go out and browse the children's electronics group. The member may also define rules for releasing personal and professional information. Some adaptability exists because members create rules by writing a program in a language compatible with the e-metro community. Tables can be used in the table store 13 to assist in the creation of rules, and the e-metro group administrator can even provide a set of default rules that need to be easily modified. Also, the E-metropolitan group administrator may create a minimum set of rules that will be applied to all transactions to ensure that one E-AutoPIA meets certain minimum criteria and that all transactions within the E-metropolitan group are conducted in an appropriate manner. These minimal rules that apply to everyone may be referred to as e-metro group rules.

Request processing:

4. assume at this point that one E-AutoPIA arrives at FTP server 65 from another E-metropolitan group. The server places the information in an information sequence 109 and the receiver dispatcher 107 subsequently identifies a received information. Receiver distributor 107 informs interaction processor 73 that an E-AutoPIA message is waiting in message sequence 109 and recovering the message containing the E-AutoPIA, but without erasing the original copy from message sequence 109, the interaction processor will recover the message from the receiver distributor and unpack the E-AutoPIA from the message. Because the E-AutoPIA is encrypted, it must be decrypted with the public key of the source distributed object resource management system server and the private key of the local server. If this E-AutoPIA group intends for the E-AutoPIA, it will be distributed appropriately. Each E-AutoPIA also contains a certificate to ensure that the owner of the E-AutoPIA actually initiated the transmission of the E-AutoPIA, as discussed in the previous section.

While the E-AutoPIA appears in this electronic metropolitan area, the electronic agent places it in the virtual image 85 for easy access. The E-proxy then collects the rules from this E-AutoPIA and uses virtual interpreter 81 and rule processor 79 to keep track of the E-AutoPIA rules as to whether this E-AutoPIA should be allowed to interact with the attendees. If not, the electronic proxy will send the E-AutoPIA to sender dispatcher 105, and sender dispatcher 105 will send the E-AutoPIA back to his main electronic metropolitan area. However, if the E-AutoPIA satisfies the rules of the electronic metropolitan group, the E-AutoPIA will be allowed to interact with the affiliates. In addition, the E-AutoPIA may hold data intended to be electronic communications or shared. If so, the transmission priority rules of each E-AutoPIA are checked in a similar manner to ensure that the E-PIA will only be shared if the transmission priority rules taken from the original E-PIA satisfy the E-PIA.

5. If the transaction has progressed to this point, the E-AutoPIA has a high probability that he says where he came from, and the E-AutoPIA satisfies the general rules of further engagement. The preferred embodiment now begins analyzing each requested interaction. The E-AutoPIA sends his first request and a token to the electronic proxy, where the electronic proxy verifies that the E-AutoPIA holds an interactive token for the particular request. If the token passes the verification, the request is retained and moved to step 6; if not, the request is deleted.

6. The electronic agent accepts the request and processes the rules for E-AutoPIA using rules processor 79, but this time builds a query into object store 75 to find an E-PIA that meets the criteria set by the E-AutoPIA. Once rule processor 79 develops this search, an SQL query, electronic proxy processing runs the query on object store 75 and places the selected E-PIA within virtual image 85. Because the E-AutoPIA has been sent out from the E-metropolitan community, transmitter dispatcher 105 now moves the original input information from information sequence 109. With the successful control of the E-AutoPIA, the active session of the interaction handler ends.

All process and purpose interactions in the preferred embodiment are now understood, and it is important to describe an example of one type of implementation of a particular and important electronics metropolitan population, referred to as an "electronics mart (E-Bazaar)". The focus of this example is the implementation of an electronic proxy because it is an electronic proxy that contains all methods and retains an electronic metro group behavior.

Examples of electronic agents: electronic marketplace

An electronic marketplace is one type of electronic metropolitan population that offers three useful business scenarios or situation studies. While electronic brokers are an example, electronic brokers are also very complex. The three cases of research are typically privately allowed trading, semi-real time auctions, and mass sales. In all three cases, these salient objects are that the E-PIA acts as some seller, the E-PIA acts as some buyer, and an electronic proxy. Note that an E-PIA may also be an E-AutoPIA in this range. The electronic agent keeps track of the wide variety of public services and interacts directly on behalf of the electronic marketplace, as does the interaction between E-PIAs. An important objective of electronic agents is to verify that business interaction partners mutually satisfy franchise rules for interaction with each other. Within the scope of this document, the term deal must often refer to a common concept of either "buying" or "selling". Furthermore, the term advertiser must often refer to those who advertise and want to go to buy and sell. The term buyer must often refer to those who view the advertisement and those who may ultimately place an order to buy.

The secretly allowed trading situation provides a means for both buying and selling:

wanting to trade in advertising

Actively placing an order for a transaction

An order is fulfilled for a transaction.

When this transaction interaction occurs, it is guaranteed that the secret between the buyer and the seller is securely achieved according to all the specific rules set by both parties. The actual transaction activity is secretly allowed.

The semi-real time auction scenario is the same as the scenario for a secretly allowed transaction, except that a seller or buyer has decided to advertise for an electronic auction. In this case, the goods or services are typically advertised along with the current bid so other potential bidders know how to bid. However, these auctions can be conducted with secret bids.

A large number of sales scenarios are the same as a secretly allowed transaction scenario except that a seller or buyer has decided that no transactions will be made unless a certain amount of goods or services are available. Thus, an placed order may not be fulfilled immediately.

This will show that the electronic marketplace is able to carry out each of these three case studies with the same framework (subject matter discussed later) in the present invention. This will show that the main distinguishing feature between each scheme is the manner in which an order is fulfilled for buy or sell.

Electronic market activity model

An overview of an electronic marketplace activity model is given by giving the best description of an electronic marketplace activity lifecycle when used in the E-PIA re-line interaction mode. The list of online mode activities during this life cycle is listed in the following table. Refer to fig. 34.

1. An internet client 303 (e.g., E-PIA) and an E-market subagent 301 that are interested in buying or selling a product provide all information about the product so that the E-market can make the information public to other buyers and sellers.

2. An internet client 303 (e.g., E-PIA) browses products and services offered in the electronic marketplace.

3. Product information 317 for a particular E-PIA advertiser's product can be obtained upon request.

4. An internet client 303 (e.g., E-PIA) obtains a purchase order 315 for a product of interest from the E-PIA.

5. An internet client 303 (e.g., E-PIA) fills out a purchase order 315 and submits the filled purchase order to the product advertising E-PIA.

6. The filled purchase order is processed by a program designed by the advertiser E-PIA referred to as the order processor 319. This process may or may not be done sequentially at once. The client E-PIA is notified either immediately by a fulfillment order or by an order in process. Such an order is not being reported to be fulfilled in a slightly later time than it was.

7. For fulfillment of different orders, the client E-PIA is informed of a fulfillment order or else the client E-PIA requests status of the order later, or receives an E-mail about the status.

For the batch E-AutoPIA interaction mode, these activities are the same except that the order of the interaction activities will be performed according to the tour of the E-AutoPIA. For an E-AutoPIA advertiser, the E-AutoPIA will submit product information to the electronic marketplace electronic agency as part of his tour and typically begin to conduct another electronic metropolitan group. However, the order of interaction in an electronic marketplace is typically very different for purchasers of E-AutoPIA. Since E-AutoPIA tends to interact automatically, it will likely that it already has a copy of one purchase order it needs. It simply needs to submit a filled purchase order. Thus, E-AutoPIA should avoid browsing and request for a purchase order and should simply sort through. For orders not fulfilled at the same time, the E-AutoPIA can check the status in its subsequent rounds, or a person representing the E-AutoPIA can wait for an E-mail from the internet.

Electronic agent management tool for electronic market

The electronic marketplace management tool mainly provides the following "provenance" features:

1. the electronic marketplace management tool is used to configure an empty electronic marketplace population that represents an electronic marketplace in a network server that contains the preferred embodiment.

2. An electronic marketplace management tool is for configuring an empty electronic marketplace.

The electronic marketplace administration tool assists an administrator in preparing for the transaction. The main task is to determine which attribute is most important for all goods and services to be traded in the electronic marketplace. These attributes are thus considered public attributes of the electronic marketplace. For example, some attributes such as trademark (name of advertiser E-PIA) and price are always of interest. The electronic mart management tool will always suggest including these attributes. Other attributes may only be of interest to a particular type of electronic marketplace. For example, an electronic marketplace dedicated to trading bottled red wine should typically include age as an open attribute. However, if the electronic marketplace is trading many products during the year it is not appropriate for all products, so a red wine product in the same electronic marketplace must use a specific attribute only for the red wine product. Note that all attributes may be any rule that represents a control type limit or other general limit such as price range.

The electronic marketplace may also assist in configuring the product inventory before the transaction begins. These products are organized by category and type. A category means a group of products with similarities. For example. One may find the same type of product in the "milk" category, such as quarter gallon milk, half gallon milk, one gallon milk, ice cream, or cheese. In this example, milk, ice cream, and cheese are all product types in the product category. Finally, each product has its own product ID, a number arranged by the electronic marketplace administration tool. An interactive protocol exists on the electronic marketplace electronic agent so that products can be added at runtime.

Electronic agent subsystem structure for electronic market

As previously described, executable electronic agent 301 may be any subsystem capable of executing in the preferred embodiment. In the case of an electronic mains subagent, the executable is made up of a very complex database, some documentation, and dynamically changing subsystems depending on the interaction with the E-PIA. In actual implementation, the subsystem may be an EXE file that activates several DDLs, a Java application, or any other alternative that preserves the structure of the subsystem as it appears below.

FIG. 34 generally depicts the subsystem architecture of an executable electronic marketplace. It also shows a view of a simple internet client/executable electronic marketplace interaction. The internet client in effect communicates with the distributed object asset management system server via HTTP (hypertext transfer protocol), which in turn, activates a series of rule processing and interactions, like security authentication. After so doing, the executable electronic agent is the last to be activated.

As shown in FIG. 34, the architecture of the executable electronic marketplace is such that there is an electronic marketplace population information encryption file 309, a commercial activity distributor 305, a trust token processor 307, a "public product database" 311, and other "runnable programs" (contained in the advertiser's catalog 313) for each advertiser, where each advertiser has its own order processor 319, product information 317, and a purchase order 315 containing the products to be traded. Finally, each advertiser will need to maintain its own "private campaign database" 321.

The electronic bazaar group information file 309 contains information to manage various aspects of the electronic bazaar. In a practical development, this file may be found convenient to arrange to store additional information.

Commercial activity distributor 305 is the primary subsystem of the electronic marketplace. It grasps all incoming interaction requests, activates the processing and control of the flow of information from and to all subsystems, documents, and if required databases. In particular, it handles many interactions with the electronic marketplace electronic agency 301 owner request, and it is also responsible for activating the necessary electronic agency service APIs 72 for special E-PIA interaction decisions.

The trust token processor 307 remembers the public key of the E-PIA visitor, issues a trust token, and verifies the trust token presented by those E-PIAs attempting to make a trade.

The public product database 311 is primarily composed of tables with one record per product that has been submitted for disclosure. The columns of the table correspond to common attributes in the electronic marketplace where all products have been configured by the electronic marketplace management tool. Also, there is a BLOb column in the table of the catalog that contains the respective attributes of each product. The form of the product has the meaning of being browsed and queried.

Three special executable programs are stored in a root document directory called the advertiser directory. The advertiser directory 313 also has a subdirectory for each advertiser. When one of the three needs to know, the advertiser is known so that the campaign distributor 305 knows which subdirectory to get the desired run. Electronic proxy 301, like it has its own subdirectory.

Private campaign database 321 provides an advertiser with means to store pending orders, such as inventory thereof, or whatever other information it needs to retain in order to perform business in the electronic marketplace. Such a private campaign database, whatever the advertiser requires, should be kept as much as possible. This means that the order processor 319 will need to access external information from the network server on which the electronic marketplace is running. Such external information must be able to reside in an external database server or even in a master frame. In either case, it should be able to reside locally or remotely to the external database as needed.

The electronic marketplace should provide a variety of simple order processors 319 such as product information 317 and purchase order 315 samples so that an advertiser can quickly and easily become an advertisement sharer in an electronic marketplace. With these simple order handlers, a simple database can also be configured with tables residing in a web server or even within the same database as the respective product database 311 (as long as the database provides security for each table).

Electronic agent interaction protocol for electronic mart

When an E-PIA Internet client communicates with a distributed object asset management system server via HTTP, these requests are transformed into interactive requests submitted to an electronic metropolitan group electronic agent. In this section, existing interactions that may be requested are described in detail. This complete list of descriptions of interactions with the electronic marketplace is intended to provide an overall standard of all possible and important activities that may occur in an entirely running electronic marketplace population.

It is evident from the discussion so far that the electronic marshal electronic sub-agent is the core of an operational electronic marshal electronic metropolitan group. The names of the interaction protocols provided by the electronic marketplace electronic agents are listed in the table below. These objects are useful at runtime. The "seller" list shows who the seller E-PIA interacts with when it initiates the interaction, while the "buyer" list shows who the buyer E-PIA interacts with.

Interactive protocol overview vendor

Obtain the abstract ()	Program body to obtain executable summary electronic mart code	w/electronic proxy	w/electronic proxy
					Obtaining an executable body summarizing a code for an advertiser-provided product	W/buyer	w/seller
Obtaining Attribute Unit of published products ()	Obtaining a directory of public attribute names associated with their rules	w/electronic proxy	w/electronic proxy
				Place product to transaction information ()	Placing a new product to advertise publicly in an electronic marketplace	w/electronic proxy	w/electronic proxy
Obtaining transaction information	Obtaining all information about a product present in an electronic marketplace	w/electronic proxy	w/electronic proxy
				Obtain the product ()	Querying listings for an E-PIA advertiser's electronic marketplace for product matching query terms	W/buyer	w/seller
Obtain secret product Properties ()	Given a product ID, a catalog of private attribute names associated with their value is obtained	W/buyer	w/seller
				Purchase order of the product ()	Providing a product ID, obtaining a program body operable to represent a code of a purchase order capable of being filled	W/buyer	w/seller
Purchase order for placing products	A filled purchase order is submitted to the advertisement E-PIA to obtain an order number indicating either an order acceptance or a "to be fulfilled" order	W/buyer	w/seller
				Canceling product transaction orders	Giving an order number for the order to be fulfilled, canceling the order so that it will not be fulfilled	w/buy	w/seller
Obtaining product transaction order status	Giving an order number, obtaining current status information about the order	W/buyer	w/seller
				Obtaining order history	Obtaining a list of all orders submitted to the E-PIA to satisfy a given query	w/electronic proxy	w/electronic proxy

The following table describes the precise subsystem activity implementations that must be implemented by each interaction protocol. This will help the reader to understand the relationship of the subsystems for various interactive requests.

Interactive protocol design

Obtain the abstract ()	A program executable to obtain "product information" from an electronic agent subdirectory presents an overview of the electronic marketplace to internet customers.
			This get summary () request is submitted with rules that specify a single E-PIA advertiser. When the advertiser is identified, its subdirectories are retrieved for the "product information" executable program to present a summary to the Internet client.
Obtaining Attribute Unit of published products ()	The electronic marketplace electronic metropolitan area information document is read to obtain public attribute information.
		Place product transaction information ()	A new record in the open products database table is inserted or updated. The executable program associated with the record is stored in the corresponding advertiser directory. If the product is new and there is a new advertiser, a new subdirectory must be created. In this case, the advertiser's name, in combination with the name of its subdirectory, must be stored in the electronic marketplace electronic metropolitan area information document.
Obtaining product transaction information ()	The record of the special product is read-its public and private attributes BLOb are read and its executable program is restored from its advertiser subdirectory. The disclosure attribute andthe runnable program is assembled into a single directory. The catalog may be presented to an internet client and the executable program executed on an as needed basis.
		Obtain the product ()	A submitted query is executed on the open products database form. The same two categories are returned for each product that satisfies the query.
Obtain secret product Properties ()	For a particular product, a BLOb base private properties horse directory is returned.
		Obtaining a purchase order for a product ()	Returning to the purchase order runnable program so that it can be presented to the internet client.
Place product order for trade ()	A catalog "fill in" price associated with their associated purchase order fields is submitted to the order processor executable program so that the order can be processed by the advertiser's personal order processing subsystem in whatever way he chooses. Returning to a boolean operation and string regarding the status of the direct order. The boolean operation value and string content may be presented to an internet client.
		Cancel product transaction order ()	The campaign distributor must determine which advertiser E-PIA is to submit a cancellation for the rule submitted with the request. When the advertiser is identified, the order number is submitted to the advertiser's private order processor. The string relating to the cancelled state is returned which can be presented to the internet client.
To obtain the productStatus of orders for goods transactions ()	The campaign distributor must determine which advertiser E-PIA is to submit a cancellation for the rule submitted with the request. When the advertiser is identified, the order number is submitted to the advertiser's private order processor. The string relating to the cancelled state is returned which can be presented to the internet client.
		Obtain product History ()	The campaign distributor knows that the request is a suspicion of an advertiser. The query is submitted to the advertiser's private order processor so that an order record containing orders satisfying the query may be returned. These are then presented to the internet client.

The interface of the interactive protocol will now be described. Before describing this interface in detail, it is important to introduce a basic purpose framework used by the interaction protocol. These basic objectives are represented below. After the basic purpose description, the interaction protocol is discussed in detail indicating those parameters are inputs, those parameters are outputs, and their types, which are based on what is described in the basic purpose framework. The reader should be provided with a maximum amount of information regarding the flow of data into and out of the electronic marketplace, how the data is used within the electronic marketplace to interact with advertisers and buyers, and when particular objects or data is presented to an internet client.

Runnable programs-a directory of names associated with the bodies of executable code that can themselves be instances of the runnable program. The directory includes all executable "slices" that must run a particular subsystem. Some useful subsets are ExeApp (executable application), D11 (dynamic link library), javaAppelet (Java applet), and Html (Hypertext markup language). The campaign distributor knows that any download of executable entities contained in a runnable program to an internet client can be performed properly. A single Html file executable is the simplest case.

Product information-a runnable program that is intended to present product information to a purchaser.

Query-represents a string of SQL (structured query language) choices.

Public property-a list of names associated with a price representing the public property of a product. An example is shown below.

Name rule example

Movement of	This.isKindOf(String)&&(this＝＝“buy”||this＝＝“sell”	Sale "
			Advertising customer	this.isKindOf(String)	“Dad’s”
Product classification name	this.isKindOf(String)	Soda "
			Name of product type	this.isKindOf(String)	“root beer”
Name of product example	this.isKindOf(String)	“Dad’s Root Beer”
			Product ID	this.isKindOf(String)	“D-RB10014”
Per unit product	this.isKindOf(Money)&&this＞0	.79
			Unit size	this.isKindOf(Integer)&&this＞0	48
Product information	this.isKindOf(Runnable)	Html file
			Purchase order	this.isKindOf(Runnable)	Html file
Order processor	this.isKindOf(Runnable)	Java application program

Private property-a list of names associated with a price representing the private property of a product.

Purchase order-an executable program that presents a purchase order for an individual to fill in fields with numerical values.

Filled purchase order-a list of purchase order field names associated with the filled field values.

Order processor-an executable program that processes purchase orders. Typically this executable program must perform processing on a private database.

Product ID-a string that uniquely defines a product.

Order number-a string that uniquely defines the purchase order that has been issued.

Order record-a structure with the format shown below. Note that it may be desirable to allow the structure of the order record to be written on a per advertiser E-PIA basis.

Name type

Product ID	Character string
		Number of units	Integer number of
When and when	Time of day
		Price	Money
Implementation of	Boolean operation
		Explanation of the invention	Character string

The interactive protocol interface illustrates how the interactive protocol is used and what data is desired to be input and output as described below.

Get summary (output runnable program-summary) -get summary that can be executed to give a summary of an electronic marketplace or a summary of an advertiser, depending on the selected rules.

Get public product attribute template (output a list of public attribute rules) -get a list of public attribute rules, a list of attribute names associated with their rules.

Put product transaction information (in string-a product ID, in a public attribute list directory, in a private attribute list directory) -add a new product to the public product database or modify an existing product. If a new product is attempted to be added, then the product ID must be 0, otherwise the product ID exists. The public attribute list and the private attribute list include all product attributes that need to be newly added or modified.

Obtaining product transaction information (in a character string of a product ID, a list of public attributes, a list of private attributes, and a character string of a general status) -obtaining all information about a product existing in a database of public products, a product ID being a character string indicating a product ID of an existing product. The normal state is a string of characters with some human-readable state information.

Obtaining products (in a string query, output a list of product IDs collected by order, output a list of public attributes collected by order, output a list of private attributes collected by order) -obtaining all information about more than one existing product. These products for which information is to be obtained are query-satisfying (one query). Three orders are collected at the output parameters: a product ID list, a public attribute list, and a private attribute list.

Get private product attributes (in string product ID, output list of private attributes list) -get private attribute value of all products with product ID (one product ID).

The private property is restored in a private property manifest.

Obtaining a purchase order (in the character string product ID, one purchase order of executable programs is output) -obtaining an executable program (one purchase order) having a product ID (one product ID) representing a purchase order of a product.

Place orders for products (in a filled order, output string-a purchase order number, output implemented boolean operations, output string-a status) -place an order with a filled order catalog. A character string and a purchase order number are restored to represent a unique order number for the placement order. The boolean operation of the implementation is resumed indicating whether the order is executed immediately (true) or whether it is to be executed with a delay (false). Also recovered is a general status string indicating any other fulfillment information.

Cancellation of product transaction order (in string-one purchase order number, output string-one status) -an order-one number that has not been previously executed is cancelled so that it will never be fulfilled. A state is restored to represent any other cancellation information.

Obtaining product transaction order status (output implemented boolean operations in string-order number, output string-status) -the order-order number is submitted to obtain current status information about the order. If the execution is true, the order has been fulfilled, otherwise it is not fulfilled. A state is a string containing further state information.

Order history (in a query, a listing of output orders to collect an order record) -all order records for some product orders are obtained from an E-PIA that is selected in line with a query. The order record is restored in a list of order records collected. A useful example of using a query is to use the description "full filed" TRUE "to obtain those subscription records corresponding to the transactions actually performed.

Business scheme using electronic marketplace framework

As described, any E-PIA can participate in the enhanced provisioning of its own order processor, product information, and execution of purchase order runnable programs in an electronic marketplace as an advertiser. This framework allows an advertising E-PIA to retain a very generic capability for implementing its necessary transactions. In addition, the framework provides a means for efficient transaction scenarios where it is not possible to have an electronic commerce system in the absence and without special attention to privacy, security and the priority afforded by the present invention. In addition, the E-PIA and the E-AutoPIA can also participate as buyers by utilizing the unified framework and obtain the same benefits of efficiency, confidentiality, safety, priority and the like. Efficiencies within this range will apply to efficiencies in working with trading partners as well as in fees for purchases and sales.

As discussed at the beginning of the electronic marketplace discussion, the primary difference between the three situation studies was the implementation of their order processor. This unique distinction is intended so that a single electronic marketplace framework can successfully implement all three cases. Three scenarios that can be mastered by the electronic marketplace are now discussed below.

The "secret authorization transaction" case allows secure and private participation for any desired transaction. This mode of ordering and fulfilling orders is intended to be generic. Therefore, because the frame itself is able to do this, nothing has been described in detail because of its intended generality. Thus, due to this generality, semi-real time auctions and mass sales scenarios are some part of the "secret authorization transactions" scenario. Note that internet email for asynchronously fulfilling orders to notify the purchaser can be a useful tool.

This "semi-real time auction" scenario requires some processing and functionality in the product information as if the ordering processor were able to run the program. The product information runnable program should not only advertise product information as normal, but should also form current bids and any other auction real-time parameters deemed necessary to be presented to the buyer.

The handling of the order is interesting because most will eventually be cancelled. However, the purpose of ordering all for fulfillment is possible if the order processor allows it to be coded. For example, it can allow the auctioneer to check the subscription history. The auctioneer can decide to extend the time of the auction, shorten it, fulfill non-top bids (orders), fulfill multiple bids (orders), or cancel all bids (some orders) at any time. The auction's behavior is controlled by the order processor.

Internet email is very useful in semi-real time auctions. For example, these subscriptions may be placed with a request to be notified of updates to important bids that may be requested in the future. However, it is possible to build a semi-real time auction system that allows re-connecting E-PIA clients to implement periodic updates due to the periodic listing of the electronic markets.

A "mass-market" situation typically requires some processing in the order processor runnable program. All orders for a product will typically remain in a "pending" non-fulfillment state. However, a real order processor for mass sales situations must allow premature fulfillment in the event that such a certain amount of orders to be handled takes too long. Premature cancellation of all or some of the subscriptions should also be possible.

It may also be desirable to allow for real-time price adjustment. In this case, an advertiser may find it desirable to maintain a mix of auctions with mass sales scenarios. The advertiser finds that he is able to trade a small number of products because there are enough orders and still obtain enough revenue, and should be able to continue and request order fulfillment rather than waiting and possibly leaving a large number of expensive inventory that is undesirable.

Some advertisers may wish to display real-time information in a product information runnable program such as the current order size and the total desired size.

Email can be used to notify about sudden changes in subscription status, as is the case with other transactions.

Special objects

Since the preferred embodiment is designed to be implemented in a programmable language that targets objects, we now turn back to the design of individual objects.

Before continuing with each object in the preferred embodiment, a list of basic object categories that will appear to constitute the preferred embodiment object is as follows. Most of these object classes are commonplace in a basic oriented object framework and should be familiar to those skilled in the art of object orientation. See fig. 22.

Type (B)	Description of the invention
		Object	The super classes in all classes are extracted as some listed below.
Species of	An exemplary presentation system defines the categories for each category.
		Integer number of	Number of
Character string	Character(s)
		Floating point	Number of
Boolean operation	Expression formula
		Collecting	The super classes in all classes of an extraction represent the collection of objects.
Order collection	A collection subset represents a list of ordered object lists in a set of sequences.
		Collection	A collection subset represents a column of the list of objects without special subscriptions.
Directory	List of public key objects
		File folder	Objects can be stored using a hierarchically arranged public key.
SQL description	Providing a quick lookup for information.
		Executable character string	A piece of code that can be transmitted as an object, interpreted when needed, and executed.
Compiler with a plurality of compiler modules	One category of examples each represents a subscription collection of a piece of executable code converting a string to a code interpretable by a runtime interpreter.
		Kind of extension	Other categories will need to be defined for the needs of the respective electronic metropolitan group, such as video, sound, etc.

E-PIA object 135, shown in fig. 15A. The E-PIA encapsulates personal data and data processing rules or an entity of real personal behavior or stored information resources and releases them under rules established by the owner of the E-PIA. Fig. 15B shows an E-PIA for the creation of an information resource to be transmitted. This resource folder should contain a subset of the approved information resources and these rules should contain the transmission rules (from the interaction protocol) of the original E-PIA, thus specifying a limit on the later distribution of the information resources in the folder. The proof can help ensure that subsequent information users originate from the original E-PIA information resource.

Item in E-PIA	Numbering	Type (B)	Description of the invention
				Object
Verification tracking	135	Order collection	An order collection for a logged event 154 is recorded in a history of E-PIA
				Resource(s)	155	File folder	All information resources about the E-PIA are stored in an unorganized folder. Information may be entered into the folder using the forms retrieved from the forms store.
Interaction protocol	143	Collection	An E-PIA may contain several interactive protocols stored in a collection.
				Trust token	157	Collection	The E-PIA hands the collection trust token to the electronic proxy to ensure the integrity of any transactions.
Priority rules		Collection	The E-PIA has a set of rules that must always satisfy any interaction to be performed.
				Certifying that	150	Certifying that	The certificate contains the name and a public key representing the E-PIA entity.

Interaction protocol object 141 is depicted in FIG. 19. The interaction protocol defines the name, input parameters, output parameters, and conditions that must be met in a subscription for an interaction to occur. An electronic agent actually performs this interaction. The interaction instruction causes the interaction protocol to be enabled. The interactive instructions are described in detail in the next section.

Items in an interactive protocol object	Numbering	Type (B)	Description of the invention
					141	Interaction protocol	Inheritance
Name(s)	191	Character string	Each protocol must have a name.
				Priority rules	185	Collection	As already described in the previous tables.
Maximum instruction	193	Integer number of	See the description in the interactive instructions above.
				Transmission priority rules	185	Collection	See description in the instructions for interaction.
Default map	197	Directory	Because the interactive instructions must be "filled in" before execution, the default map can provide default values to assist in completing the interactive instructions.
				Income (R)	197	Collection
Output of	198	Collection	Which information resources should be stored in the information E-PIA if the subsequent interactive instruction is successfully executed.

The rule object 201 is shown in fig. 20.

Items in rule objects	Numbering	Type (B)	Description of the invention
				A rule object is actually exactly an executable string object	201	Executable character string	An executable string represents a user-defined rule.
Compiler program	187	Character string	The name of the compiler is always the "rule".

The parameter object 151 is shown in fig. 21.

Items in a parameter object	Numbering	Type (B)	Description of the invention
				Name(s)	211	Character string	The name of the parameter.
Valid rules	187	Rules	An executable string his compiler is a "rule".

The E-AutoPIA 151 object is shown in fig. 16. The E-AutoPIA is an intelligent agent that performs the specific tasks scheduled by the owner using a route. The route is described in detail in the next section. Only the original E-PIA can be loaded into one E-AutoPIA, but the original E-PIA can be loaded into several E-autopias and allow them to be active at the same time.

Items in E-AutoPIA objects	Numbering	Type (B)	Description of the invention
				Route of road	161	Collection	An E-AutoPIA may have several route objects 163 that are hierarchically callable by routes.

The route object 163 is shown in fig. 17.

Items in a route object	Numbering	Type (B)	Description of the invention
				Name(s)	170	Character string	A route must have a name.
Instructions	171	Collection	The route contains several instructions of interaction. If there are several instructions and there is no script, the instructions are executed sequentially.
				Book correcting device	175	Dictionary	The script is stored in a directory object, which allows an executable reference string to be given by name.
Transmission priority rules	178	Collection	As already described in the previous tables.
				Priority rules	172	Collection	As already described in the previous tables.

The interactive instructions 173 object is shown in fig. 18. The interaction instruction causes an interaction between the E-PIA and the E-AutoPIA. Each interaction instruction specifies the interaction protocol to be performed and specifies the actual parameters for which interaction under the rules is likely to occur. The result of a successful interactive instruction is the creation of an information E-PIA as shown in fig. 15B. Each item of information held by the information E-PIA is encrypted with the private key of the original E-PIA, thus providing the authenticity of the subsequent user when using the public key of the E-PIA.

An interactive protocol essentially preserves a temporary relationship to the interactive instructions. An interactive protocol is represented by a signature of the parameters to be filled in, while the copy of the interactive instructions is identical except for the parameters to be filled in. The interaction protocol and the interaction instructions are two entities that write time. An interaction protocol represents some of the services provided by an electronic agent and is written together by the electronic agent. The instructions for interaction are written for an E-AutoPIA during construction of a route. Each interactive instruction represents a call requesting an interaction or an interaction protocol. When the corresponding interactive instructions are constructed, the inputs, outputs, and default maps are removed from the interactive protocol.

Interacting items in an instruction object	Numbering	Type (B)	Description of the invention
				Name of interaction protocol	181	Character string	Each protocol has a name.
Group names	131	Character string	Name of E-PIA resident electronics metropolitan group of E-AutoPIA.
				Priority rules	185	Collection	As already described in the previous tables.
Maximum instruction	183	Integer number of	There will be a maximum number of E-PIA on which instructions are used. This number may be infinite.
				Parameter allocation	182	Directory
Transmission priority rules	185	Collection	As already described in the previous tables.

The electronic metropolitan area object 130 is shown in FIG. 13. The electronic metropolitan area object 130 provides a set of content for the E-PIA and other electronic groups.

Items in electronic metropolitan objects	Numbering	Type (B)	Description of the invention
					135	E-PIA	The electronic proxy level inherits from the E-PIA level. Thus, an electronic proxy is a subset that contains all the items that an E-PIA contains, but includes:
name(s)	131	Character string	Each electronic metropolitan group has a name.
				Group of people	132	Collection	One e-metro group contains other e-populations in a hierarchical relationship.
Electronic proxy	133	Collection	Each electronic metropolitan group will require at least one, and possibly several, electronic agents 136 to perform a particular task. The electronic agents are arranged into a collection.
				Character	134	Collection	All of the E-PIA 135 in the E-metro group are kept in one set.

The electronic proxy object 136 is shown in FIG. 14. One electronic agent is required for the interaction of all E-PIA and E-AutoPIA. It is this electronic proxy that ensures release only to trusted entities that satisfy requests with personal settings.

Items in an electronic proxy object	Numbering	Type (B)	Description of the invention
					135	E-PIA	The electronic proxy level inherits from the E-PIA level. Thus, an electronic proxy is a subset that contains all the items that an E-PIA contains, but includes:
protocol directory	143	Collection	The electronic proxy may contain several interaction protocols stored in a collection.

Structure and design

The next section describes the structure and design of a personal and private information protection and commission system called an "electronic city".

Introduction-electronic urban world of users

The electronic metro world is a collection of all hardware and software that is used to store electronic metro logical objects and/or perform electronic metro logical activities. The user window of the electronic metropolitan world is obtained from an application program, primarily through a web browser, which is the one of many electronic groups all interconnected to each other via the internet, as shown in fig. 2. Finally, users are simply to interact with other E-PIAs of similar interest as a logical place, regardless of the physical location of the electronic community.

As a tool for building the structure of a person's information assets, the e-metro table repository is also applicable. According to one useful reuse structure, these forms can be recovered using the E-city customer editing tool and incorporated into existing or new E-PIA to which information is appended. A user may then store his E-PIA to one or more electronic groups.

Overview of System architecture

Electronic city world mechanical structure

In fact, each electronic community resides on an electronic metro web site server. More than one electronic community may reside on one such server, as depicted in fig. 7. Moreover, an electronic community residing on a single server may be configured to retain a hierarchical relationship to one another.

Two e-character-table repositories 13 are depicted in the figure. As indicated in the text of fig. 7, one electronic character form repository is implemented by an FTP site while the other is implemented by a mail server system. There may even be no table store present and the table is simply processed as a local document.

Electronic metropolitan world system processing architecture

The client and server processes in an electronic metropolitan world are shown in figure 8. The client workstation is encoded by a netscape browser and an e-metro specific DLL, JAVA text, or some similar feature to mean other clients that are susceptible to various e-metro client activities. FTP servers are considered the primary role on the internet while the netscape server system is discussing server files in the netscape. The focus of this file is the e-metro trust server system 47 in figure 8. While using an electronic metro, the customer always communicates with an electronic metro trust server. At the time of editing, the interactive protocols and instructions can only be obtained from the correct electronic agent (in fact, if the format to be established for the interactive protocols and instructions can only be obtained from the format store, but the request tokens for these activities can only be obtained from the electronic agent). In operation, the E-city client queries a user's master E-PIA within the electronic community, and the E-city server on which it resides, to see the latest results or status of the relevant E-AutoPIA. The e-metro server is actually made up of many processes that will be discussed in the next section.

Electronic city safety structure

Electronic cities emphasize the secure and trusted interaction of information resources. The electronic metropolitan ensures that all information entering the electronic metropolitan world system will be secure and that only those trusted people have the possibility to access the specific information. For a description of when and where encrypted transmissions occur in a "public" internal connection that is essentially an electronic metropolitan world system, the reader is referred to fig. 24. All security measures that need to be encrypted are handled by the SSL (secure socket layer) communication layer of the netscape. To maintain the described level of security, the following system attributes are retained:

1) each electronic metro trust server subsystem on a network site consists of a secure process that nobody can access when they are running. It is assumed that this runtime integrity can be achieved by an average person skilled in the art of process security on a stand-alone computer.

2) Each electronic metro trust server subsystem maintains its own private and public keys. The public key of a particular electronic metro trust server subsystem is known to all other electronic metro trust server subsystems through the directory server electronic proxy.

3) All E-PIA and E-AutoPIA are encrypted when transmitted between the E-metro trust server system network sites. Encryption is achieved using both the public key of the destination electronic metropolitan trust server subsystem of the transmission and the private key of the transmission source. This double encryption accomplishes a double guarantee:

a) only the electronic metro trust server subsystem (destination) with the correct private key will be able to encrypt this transmission.

b) It is also this metro trust server subsystem (destination) that will be guaranteed that the transmission is from the source metro server described in the transmission and is not a spoofing source.

4) All interactions between the E-PIA and the E-AutoPIA are performed privately on a single machine within the E-metro trust server sub-system.

5) When a client request message is contained in its master E-PIA, the electronic metro trust server subsystem that maintains the master E-PIA uses the master E-PIA client's public key for the purpose of transmitting encrypted messages so that only the receiving client can decrypt the message. When writing information to the master E-PIA, the information is encrypted with the public key of the destination E-metro trust server subsystem so that only the correct destination can decrypt the information. The information written also includes E-AutoPIA and associated routing. See fig. 24.

6) When a client is obtaining author information from an electronic proxy, the author information is encrypted with the client's public key, so only the client knows how to decrypt the information. Encryption is most important for the transmission of the trust token during editing that must be immediately encrypted by the client's private key upon receipt.

City trust server system

Figure 9 shows the top level subsystem of an electronic metro server. The core system that provides the main services of the e-metro is the distributed object resource management system server or DORM. Five other subsystems are an FTP server and FTP client process and three netscape website servers, which together implement the necessary functionality for a complete electronic metro server.

Distributed object resource management system server

As described above, the distributed object asset management system server is the heart of the electronic metro system architecture. It essentially manages the trust store and broker for all electronic metro objects and resources with the help of small unit objects (i.e. electronic group and electronic broker), which is an internal management. In particular, the distributed object resource management system server functions as follows:

D1. storing electronic populations

D2. Storing electronic agents

D3. An entire electronic metropolitan world directory is maintained with all electronic groups and electronic agents and the latest directory is maintained.

D4. Storage or "bank storage" E-PIA

D5. Reserving an information subsystem for E-AutoPIA transmission between electronic groups

D6. Reserved access E-AutoPIA

D7. Electronic agent arbitration using E-PIA interactive drive E-AutoPIA

D8. Priority rule processor for server guarantees for distributed object resource management systems with assisted security and trust interactions

Network scene business server

The network scene business server is a core subsystem for starting an electronic city server, a website and interacting on the Internet. Because it uses the open Secure Socket Layer (SSL) protocol, it provides full internet security. SSL uses techniques from RSA data security to provide encryption, server authentication, and information integrity. When the client makes a request, it allows initial communication with the netscape commerce server. The netscape business server will then cooperate with the distributed object asset management system server through a netscape server API (application programming interface). The communication between the network scene business server and the electronic city server isAllowing the client subsystem to be comprised primarily of an international wide area network-compliant browser such asNavigation of network sceneHTTP/HTML composition of (1). Details of such collaboration are discussed in the next section.

Network scene affair server

As shown in fig. 9, the netscape transaction server holds credit card processing, transaction records, and bill management. The distributed object asset management system server interacts with credit card processing functions when a person wishes to begin using the E-city service for the first time, or to add new capabilities to their E-PIA. Changes to the initial or new capabilities are automatically handled by the credit card functionality of the transaction server. The distributed object resource management system server also interacts with the transaction logging function to track what has happened at the e-metro site and who can also use the billing management function. This is precisely what one of ordinary skill in computer programming arts can easily follow the necessary landscape to manually configure the cooperation between the distributed object asset management system server and the transaction server.

An important electronic metro feature is that the personal electronic agent and the E-PIA can configure their own billing policies. The electronic proxy can require registration of credit card information so that it submits a request trust token for an interaction protocol or interaction instruction. The same can be done by E-PIA, but it should be appreciated that E-PIA can only do so by execution of an electronic agent. As will be discussed later.

Network scene server API (NSAPI)

The NSAPI works closely with the netscape commerce server to provide a means for a network site to control the processing when normal HTTP compliant requests enter the commerce server. To do this, the netscape has defined the following steps in the normal response process:

NS1 priority interpretation

NS2. name interpretation

NS3. Path checking

NS4. object types

NS5. response request

NS6. Login transaction

The NSAPI provides a process that can override the processing performed in any or all of these steps. This is exactly what is supposed to be the override required by the ordinary person skilled in computer programming technology to be able to easily manually initiate these steps following the necessary NSAPI. In particular, steps 1, 2, 3, and 5 would require special electronic metro replacement. Some implementations of an alternative summary are listed below:

in the case of the NS1, the location of the pin,

of the electronic group necessary for the requestPriority rulesCan be checked; and

the trust token necessary for the request can be checked.

In the case of the NS2, the location of the pin,

the paths may reference hierarchically distributed electronic agents or electronic communities.

For the NS3, an electronic agent or electronic community is checked to see if it exists. For the NS5, the requested distributed object resource management system server service is executed. There are several types of requests that are:

1) the client requests to browse the DORM directory.

2) The client requests edited time information from an electronic agent.

3) The client requests the recovery of the owning E-PIA information resource.

4) The client requests the resources to be updated on the client and then stores the E-PIA information resources.

5) The client requests to load an E-AutoPIA.

Note that this E-AutoPIA does not use encryption because the E-AutoPIA's activity is not a guest driven process.

FTP server and FTP client

As will be described later in the structure, the electronic agency requires a reliable information subsystem for transferring E-AutoPIA from electronic group to electronic group. Because the internet email is unreliable, FTP servers and FTP clients are used to effect the transfer. The E-AutoPIA is grouped into a BLOb and transmitted to the remote site via a file. The file is then loaded to the FTP server of one e-metro server via initialization of the FTP client of the other e-metro server. The next section discusses details of FTP usage for the information subsystem architecture.

Distributed object resource management system (distributed object resource management system server) service Device for cleaning the skin

FIG. 10 shows a complex layout of subsystems within a distributed object resource management system server. The remainder of this section is dedicated to the discussion of each of these component subsystems. However, it is to be appreciated that the interaction handler is the focus, since it is this driver subsystem that is invoked either because a client request is through the web-cam business server or because the E-AutoPIA arrives through the information subsystem. Another point that arises before continuing is that all service requests are executed in a manner that interacts with an electronic proxy.

Interactive processor

As described above, the interaction handler is the focus of the distributed object resource management system server and it satisfies all requests through one electronic agent. When the information subsystem submits an E-AutoPIA to the distributed object resource management system server, it is actually submitting it to the interaction handler which is the code initiating agent for the entire distributed object resource management system server. When the information subsystem does this, it is assumed that it has not grouped the E-AutoPIABLOb so that the E-AutoPIA is the rest of its processing in an appropriate form. As listed in tables 1 and 2 below, much of the processing is done for a client request as for an access E-AutoPIA. The service request controlled by the interaction handler is all the client requests listed below, as well as the interaction instructions into the E-AutoPIA. An overview of the full list of requests served by the interaction handler and any controls thereof is listed below.

Ip1. client requests to browse the distributed object resource management system server directory-the request is redirected to a special electronic agent known as a "directory server" electronic agent.

Ip2. client requests edited time information from an electronic proxy-the request is redirected to an electronic proxy that is scheduled to invoke one of its special edit time services (interactive protocols) such as "interactive protocol directory" or "get to interactive right protocol".

Ip3. client request for recovery of the resource holding the E-PIA information-the request is redirected to a special electronic agent that is considered the "master" electronic agent. This special service used is called "recovery resource". This special electronic agent must be present in every electronic community where the master E-PIA is to be allowed to reside.

Ip4. client request resource is updated on client to store E-PIA information resource-this request uses the "master" electronic proxy by invoking its "store resource" service.

IP5.E-AutoPIA requests interaction through the current Instructions of interaction within its way- -the request is

6	Electronic proxy adapter	Call execution ()
			7	Executable electronic agent	Invoking executable code execution services
8	Electronic proxy service API	May need to call a service API program
			9	Network scene business server	And returning the information. The encrypted information is sent back with the client's public key.

TABLE 1A request from a client application- -steps of an interaction handler

And distributing the use of subsystems within the object resource management system server.

	Subsystem usage	Function of
			1	Information subsystem	The E-AutoPIA is received and encrypted with the private key of the local E-metro trust server system.
2	Interactive processor and virtual image	The request is submitted to the distributed object resource management system server along with the E-AutoPIA.
			3	Virtual image with virtual interpreter	Searching interaction instructions appointed by electronic group in E-AutoPIA
4	Rule processor with virtual interpreter	Valid priority rules for electronic groups.
			5	Rule processor with virtual interpreter	The priority rules that any transitive exchange is to pass through E-PIA text as an input or output parameter are validated.
6	Electronic proxy	The E-AutoPIA is verified with the necessary trust token by encrypting it with the public key obtained from its certificate.
			7	Electronic proxy adapter	Invoking an executive () with the name of the "get trust token" service and interaction protocol as parameters.
9	Executable electronic agent	The executable program code is invoked to generate a unique trust token for the specified interaction protocol.
			10	Electronic proxy	Invoking an electronic proxy
11	Electronic proxy adapter	The executive () is called but only those inputs are allowed that satisfy the transfer priority to be transferred.
			12	Executable electronic agent	Invoking executable program code to perform a service
13	E-PIA read from object store by electronic proxy service API	Call Collection Trust E-PIA ()
			14	Executable electronic agent	Executing the remaining portion of executable program code in service execution by an electronic agent
15	Virtual images	The E-AutoPIA is updated with the output that the transmission priority is met.
			16	Route interpreter	Interpreting the current script and determining the next interactive instruction to be executed
17	Electronic proxy and virtual image for directory services	Looking up FTP address for next electronic group of next interactive instruction
			18	Information subsystem	The E-AutoPIA is submitted back to the information subsystem to be transmitted to the next electronic group. The information subsystem must encrypt the information to be transmitted with the public key of the destination.

Table 2 one request from E-AutoPIA-the steps of the interaction handler and the use of the internal subsystems of the distributed object resource management system server.

Rule processor

The rule processor is a critical security enforcement subsystem. It checksPriority rulesAnd additionally, the rule processor also controls changes to the SQL statement to be helpful in the E-PIA selection.Priority rulesRequires a rather complicated procedure for validation. In the case of E-AutoPIA,priority rulesMay refer to "i am self" and "you are self. Each one of which isPriority RulesAre a collection of rule objects. Each rule object must be initially inserted into some unique set of rules including "I am's ownReference is made to the sub-expressions of the data. These "unique-my-self" sub-expressions can be immediately reduced to true or false by executing a virtual interpreter on the E-AutoPIA of the current content.

The "yourself" sub-expression is kept in conjunction with the result to form a simplified expression. The expression, which remains simplified, is then parsed and transformed into an SQL selection description which may have a subscription if the rule language provides the pass term. This selection description is later used to collect E-PIA that satisfies all the rules estimated to reach this so far.

Since each E-PIA has its own for E-AutoPIA interaction with the current contentPriority rulesThe collected E-PIA from the above selection must be further filtered. This is done by taking each E-PIA one at a time from the collection and performing their actions with E-AutoPIA as "you 'own" and the current E-PIA as "I's ownPriority rulesTo complete. This execution requires a virtual interpreter. Note that this portion of the priority check may have poor performance because the database selection is not used. It is therefore important to construct the E-AutoPIASuperior food Priority rulesSo that the collection of E-PIA sets is as small as possible.

Virtual interpreter

The virtual interpreter is a simple structure that gives a programmable language that is dynamic in the e-metro. The programming language may be any language or even a new language, but it is suggested that it has similar properties for small-scale conversations. Such a programmable language must be used inPriority rulesAnd the exact nature of the route.

Virtual images

The virtual image is where all electronic metro specific types and objects being processed are stored in RAM. The virtual interpreter gives a dynamic program for these objects. As shown in FIG. 10, all electronic communities and electronic agents are kept in the virtual image as an implementation technique, although each is persistently stored in an object store.

When an E-AutoPIA or E-PIA is processed, they are brought into the virtual image with all their own objects. ThePriority rulesA virtual interpreter is then used to process some of the expressions. A special method on the class EPIA is able to check for the presence of a special trust token.

Electronic proxy object

Each electronic proxy object may represent an executable program that is substantially external to the software for transmission to the electronic metro to execute their interaction protocol on various routes. However, if all of this is desired to be information shared between the E-AutoPIA and the E-PIA then no external executable program is required by the electronic agent. Alternatively, ifPriority rulesIs executed, the interaction processor will only know that one data exchange is to take place. An E-AutoPIA interaction instruction should appear as if there is only one E-PIA script to be included in the interaction with the E-AutoPIA. The interaction processor will automatically construct a set for the output parameters equal to the maximum instruction length.

Electronic agent adapter and electronic agent executable program

All electronic proxy objects are accessed using a unified protocol with a virtual interpreter. However, each electronic agent executable may be different. An electronic agent may be a C or C + + executive (EXE), a C or C + + Dynamic Link Library (DLL), a Visual Basic program, an OLE 2 object program (object), an SOM, or other program. The process of activating an interactive protocol or executing programs for each case may be different. Thus, the new type of each executable requires an electronic proxy adapter that transmits unified protocol calls to and from the electronic proxy executable.

The adapter is always dynamically populated and always supports one DDL of the following APIs (with undefined signatures):

start () - - -invoked just after adapter DDL loads

Stop () - - -invoked just before the adapter DDL uninstalls

Execution () - - -this is the entry point for the main execution of the interactive instruction. The name of the interactive instruction must be transmitted along with a list of all parameters to which it is connected. The implementation of execute () is important because it must contain code that in combination with the interactive protocol name represents in some way the implementation of the interactive protocol to the executable program code body. The calling executable code body is then executed.

Electronic proxy service API

The electronic proxy executable may be any of the above-described executable types, as described. To facilitate the writing of this code to execute the service/interaction protocol that developers of electronic agents attempt to reach, some APIs are provided. The executable program must be able to call the C programs from a DDL of C to execute these programs.

Some programs that are definitely useful (with undetermined signatures) are:

collect trust E-PIA () — this API is only one that has to be called by each electronic proxy executable. The executable is the only way to obtain the "priority-adapted" holding of the E-PIA collection. This API takes the input and additional rules to be applied as a collection of E-PIAs. The rule processor is used to combine the input rules with the SQL description formed prior to entering the electronic proxy. This elicits the SQL select description to be used last. The selection description is executed to obtain a collection of E-PIAs that conforms to the selection. However, this collection is no longer returned until the individual who collected the E-PIAPriority rulesThe rule processor being executed checks.

Once the complete "priority adaptation" collection returns, the electronic agent executable can do whatever it wants to do with them before returning from the interaction. Note that for an interactive instruction is smallMaximum interactionIn the case of values, the "subscription pass" rule may be very important.

Process credit card () - -interact with the transaction server after obtaining credit card information in order to purchase something.

Form filling activity () - -interact with the transaction server to fill out an E-AutoPIA based on the name of an activity.

Authentication with a security card () - -a special electronic security card to enter a reader is required in order to return to reality. The special security card is defined by information and rules provided as parameters to the API.

Meta-electronic proxy

Because some suitable electronic metropolitan systems are implemented by electronic agents, these particular electronic agents are considered "meta" electronic agents. So far, only two have been defined. More may be required.

Master electronic agent

This electronic proxy first needs to authenticate a user who is editing or browsing the information resources of a particular host E-PIA that the person in fact owns. While this electronic proxy needs to be presented in perhaps many electronic groups, its implementation may be ignored. For example, a "master" electronic agent implementation may provide such stringent security that a security card is absolutely required. Other "master" electronic agents may only require one password. A casual electronic group may not have security.

Directory service electronic proxy

This electronic proxy attempts to retain up-to-date knowledge of the entire electronic proxy world. Only one directory services electronic agent is needed per top-level master electronic group at a site. In particular, it keeps track of each online electronic metropolitan trust server subsystem, all electronic groups and the internet addresses they are located at, as well as the electronic agents residing in them and each electronic agent's own name, etc. This directory information must be persisted so that it is stored in the object store.

To keep the directory information up to date, each directory services electronic agent periodically checks to see if there are any electronic groups or electronic agents scheduling changes. If so, the directory services electronic agent sends an E-AutoPIA with a route to each of the other directory services electronic agents to notify them of the changes. The frequency of the cycles may be once per day as such variations may be quite small. Note that a new electronic metro site must obtain a copy of the entire current electronic metro directory upon installation.

Route interpreter

A route understood by the route interpreter is selected in one of two forms. Either with or without a positive copy of the route. In either case, the route must have at least one interactive instruction inInstructionsIn a collection of subscriptions. In the case where there is no positive text,instructionsOrder collection is simply performed sequentially. In the case that the script exists, the interactive instructions do not have to actually have the parameters filled in because the script performs the call with those parameters. In this case, the ordered collection of instructions only represents instructions that can be invoked from the master. There is no reason to hold the copied interactive instructions for the case where the original exists.

For the case of no original, the route interpreter adds only oneInstruction pointerIn an E-AutoPIA to keep track of the instructions of interaction in the current route. When a positive copy exists, the route interpreter must be able to compile and execute the positive copy. It obtains this simply by using a virtual interpreter. Each script is as a programming language that can be used to executeWhat is generally a small conversation method to handle. These reference variables in the text are incorporated into the specification information in the E-AutoPIA. Within a home at any time, an interactive instruction or even a complete route can be called by the special variable "instruction" involved. The syntax for invoking an interactive instruction would be "some instructions are: one protocol name is implemented as: a list of parameters. "in this example, a protocol name is the name of the interactive protocol to be executed, while a parameter directory is a directory entered on the parameter name and priced on the value of the parameter.

Object repository

The object store is primarily meant to be where the E-PIA is persistently maintained. However, the electronic group and the electronic agent are also stored here. The object store is implemented on a relational database (i.e., Oracle) using a simple object primitive interface. Some of the features of the simple object designed for the relevant table column are as follows:

OR1. Each object is stored in a column of a database table using the column schema described in FIG. 11.

Or2. the object identifier or OID is an internet-wide unique numerical identifier that can be used to de-reference an object.

Or3. each object is considered to be stored in just one persistent multi-keyed collection of a set of many rows each with the same collection OID.

And 4. these public keys are actually an object of "public" information. When an object is stored in a row, the object data that has been defined to be published is copied into the appropriate column of the row. Because the database engine can be employed, only these defined public keys can be used for fast E-PIA selection and collection.

OR5. these actual objects are themselves stored in a BLOB column of a row.

An object repository is installed for each top-level electronic community residing in the electronic metro server. The database schema includes only three tables, one for the electronic community, one for the electronic agent, and one for the E-PIA. Persistent multi-click collection patterns for electronic groups, electronic agents, and E-PIA are shown in FIGS. 11b, 11c, and 11d, respectively.

In each of the three tables, collecting OIDs involves the concept of a different packet. In the electronic group table, the main OID is a collection OID that collects one main electronic group as his sub-electronic group. The electronic group OID is the Collection OID in the tables of the electronic proxy and the E-PIA. These public keys have been intentionally undefined. This is because these public keys should be determined by the needs of the electronic community and should be configured by the electronic community management tool.

It is important to note how access with a hierarchical electronic community is obtained. Suppose a query must allow any E-PIA that is a member of an electronic group or any of its sub-electronic groups as a result. First, OIDs that relate to all hierarchically accessible electronic populations must be discovered prior to querying and collecting. The selection query is then composed with a set of Ored "collect OID ═ X" expressions.

Remember that most electronic community and electronic agent processes are only intended to be done directly in the RAM in the virtual image. Only the E-PIA will be routinely accessed in the object store.

Information subsystem

Until related to the interaction handler, the information subsystem is a separate source and E-AutoPIA collection that will request the proxy service. When an E-AutoPIA service is completed, the interaction processor submits the E-AutoPIA to the route interpreter. This route interpreter interprets the current original until it can obtain that it is the next interactive instruction to enable. This would be straightforward if there were no originals and only one linear path of the interactive instructions. The interaction processor gets the E-AutoPIA return when the route interpreter is complete. The directory services electronic agent is then compared to see which site E-AutoPIA needs to proceed to the next step. The interaction handler then submits this E-AutoPIA back to the information subsystem so that he can be transferred to his next destination. Details of the information subsystem are presented in the next section.

Information subsystem

The information subsystem is dedicated to reliably transporting E-AutoPIA from a remote electronic group to another. The information structure depicted in fig. 12 is very simple. The information subsystem mainly depends on the arrival of E-AutoPIA and the sending of information inquiry assisted by an external FTP client and an FTP server. The E-AutoPIA dispatcher is the primary interface to the distributed object resource management system server. Note, however, that FTP need not be implemented as an information subsystem. Rather, means for transmitting information can be used. These subsystems will be described in detail below.

E-AutoPIA sender distributor

When an E-AutoPIA is being sent to a remote electronic group, its FTP internet address should have been looked up by the interactive processor. Note that each top-level electronic group has an internet address. The interaction handler invokes the E-AutoPIA sender dispatcher by grasping the free E-AutoPIA to be sent with its address.

The E-AutoPIA sender dispatcher places the E-AutoPIA into an outgoing message queue and then activates the FTP client to send the E-AutoPIA to its destination. If for any reason the FTP client cannot immediately send the E-AutoPIA, the FTP client will later read these entities from the output information queue and then attempt to send the output E-AutoPIA.

Information queuing

This queue of information is effectively exactly one FTP file system. There is a single queue of outgoing messages and a queue of incoming messages that may be two distinct FTP file directories.

E-AutoPIA receiver distributor

When the E-AutoPIA recipient dispatcher observes an arriving E-AutoPIA in the incoming information queue, it immediately invokes a new interactive processor process to process it without collating the E-AutoPIA from its file format. The E-AutoPIA files in the incoming information queue are not deleted until the E-AutoPIA is submitted to the outgoing information queue. Recovery is required in the event of a server-server collision of the distributed object resource management system. Since only so many such servers may be running simultaneously, a backup of E-AutoPIA can be built into the incoming queue of information. If the incoming message queue becomes empty, the E-AutoPIA receiver dispatcher may periodically sleep and wake up to check if anything has arrived. If there is a way for the FTP server process to notify the E-AutoPIA recipient dispatcher, the sleep process can be asynchronously woken up on an as-needed basis.

FTP client

This FTP client process actually needs to perform several more tasks than one vanilla FTP client does. It must delete the E-AutoPIA file in an outgoing queue once it has successfully transmitted the E-AutoPIA file to its next destination. Furthermore, FTP is used for transmission because it is reliable. If an error occurs during the transfer, the FTP client should know that the transfer is direct point-to-point. The FTP client should know that it must keep the failed E-AutoPIA queued for output and retry delivery later.

FTP server

The FTP server does not need to do anything special. It simply stores the incoming E-AutoPIA file for transfer to the desired directory. The FTP directory as specified above is queued for representing incoming information for one of the top level e-cities located at the local e-city site.

Object schema overview

This section describes a computer-to-population object model based on personal and private information protection and a proxy business system that becomes an "electronic metropolitan". This object mode focuses on the user perspective of objects in the electronic metro. This object schema provides a detailed description of how the objects behave and relate to each other at the user level. In some cases these objects and categories will not map to an object or category in the object programming language at the user level. However, the transition from an OOA object to an OOD object is mostly very smooth. The original Booch symbol object is used in the block diagram of the file as a means of communication relation to the real object. Fig. 23 depicts the prime notation symbols used and their meaning. The notation "for execution" is largely used to illustrate that a variable represents an object that a class needs to be in its execution.

Base object

At the highest level of description of the electronic metro objects, there are electronic characters, electronic groups and electronic agents. An electronic character is the computer-character concept previously referred to. This appears to be a virtual person because it is assumed to be the person to be represented, but in computer space. Electronic personas reside in an electronic community in order to keep their information resources secure. While the electronic agent is effectively a vehicle for all electronic character interactions in order to maintain the security provided by the electronic community as well as the security detection of any specified person (a particular electronic character).

An electronic community is a secure and trusted computer community. An electronic group ensures security that only electronic characters with appropriate electronic group priorities can enter or reside. Security is contained within one electronic group because the information resources of the electronic character residing therein can only be shared with those having the appropriate personal priority. An electronic group is trusted because it ensures that the electronic characters it contains and the electronic characters it visits will interact according to the rules established by each electronic character, thus maintaining "uniquely trusted" interactivity.

Each electronic group has at least one electronic agent, and the purpose of the electronic agent is to transmit priority information sharing and interaction. In fact, both electronic persona information sharing and interaction can only occur through one electronic agent.

Electronic character as agent of personal information

There are two main subsets of electronic personas in an electronic city-these are electronic persona information agents (E-PIA) and electronic autonomous persona information agents (E-AutoPIA). The item "personal information agent" exemplifies electronic characters for the purpose that they manage electronic information resources of a real person. An electronic collaboration information agent (E CIA) representing a true collaboration may also be a useful subset of electronic personas.

It is this E-PIA that shares its own information while residing in this electronic community. This "passive" sharing is only possible with one more "active" E-PIA that is considered to be the E-AutoPIA. One E-AutoPIA with the appropriate priority established by the seminar E-PIA can interact with this E-PIA and enjoy information sharing. An electronic agent 39 assigned to the electronic community 35 in which the E-PIA 37 resides transmits the priority information share as shown in fig. 5. Note that only the E-AutoPIA 41 can initialize an activity.

If an E-AutoPIA desires to initiate an interactive activity such as participating in other E-PIA secure information sharing, requests from other E-PIA secure services, or performs secure transactions with other E-PIAs, the E-AutoPIA must access the appropriate electronic agent for each particular activity. The list of interactions to be performed by an E-AutoPIA is considered its way. Just like the E-PIA residing in the electronic community, the E-AutoPIA is protected by one electronic agent and can only interact with other E-PIAs or E-autopias through one electronic agent. All information sharing and other common forms of interaction always occur through an interaction protocol. The E-AutoPIA shown in fig. 6 accesses several electronic agents each located in a different electronic community, and there may be multiple electronic agents in a single electronic community and each of them accessed by a single E-AutoPIA according to its desired activity.

Trusted security and transport

The reader should note the continued use of the qualifier "safety". Security is critical in electronic cities as a primary means of maintaining the integrity of the interactions that attempt between people represented by E-PIA. Strict privacy is necessary to ensure intentional E-PIA internal relationships and to maintain confidence in only those E-city users who are intended to view specific information and are able to view it.

When one E-PIA gives some of its personal information to another E-PIA, the given personal information is still protected and attributed by the original E-PIA. In fact, if this receiving E-PIA in turn transmits information of another E-PIA to a third E-PIA, the E-city also knows the original owner of the personal information and continues to regulate access to this information according to the transmission priority rules promulgated by the original E-PIA. This security paradigm created by electronic cities is considered trusted transport. Trusted transport means:

if a believes to have B of the information a',

while B believes that C possessing the information a',

then a believes to be C with the information a'.

This important concept guarantees for a that its information is never transmitted to an untrusted entity, according to the transmission priority rules for the already submitted data distribution.

This is an easy way to tell the E-PIA of the E-city which E-PIA owns the information, because the information is always transmitted in the text of the E-PIA that submitted its information. For example, assume that an E-PIA contains a rich set of information including date of birth, address, phone number, etc. Further, assume that it wishes to submit only its phone number to another E-PIA during the interaction. Receiving E-PIA will actually receive an E-PIA object that contains only phone numbers. In particular, the received E-PIA object is a text of the original E-PIA that is intended to be pre-received by the receiving E-PIA to indicate how to submit the E-PIA. FIG. 6 depicts the "collection" of text for E-PIA 40 by a mobile E-PIA 41. The text of the E-PIA object is simply the way information is retained by the E-PIA in the E-city. FIG. 6 also depicts text for a Mobile E-AutoPIA that has been given to a non-Mobile E-PIA 39 in one of the electronic communities.

Subsystem model

Before introducing details of object behavior and relationships, it is important to understand that various users know to use subsystems of the electronic metro simultaneously. This section describes the activities of the primary client and server subsystems.

Mode of use

Creation time

E-PIA

E-PIA has only two writeable items: their informationResource(s)And their ofInteraction protocol. These resources need to be created by using some kind of hierarchical GUI (graphical user interface). The GUI must consider any data to enter a field and give the field a name. This GUI must also provide a means to create a hierarchical structure by attaching the concept of a subfolder. Promising, such layered graphics may have some way of HTML formatting protocols.

The interaction protocol is strictly protected and may only be obtained from one of the electronic agents residing in the same electronic community of the E-PIA being written. One person can browse an electronic proxy in an electronic group to obtain its HTML formatProtocol directory. The returned HTML text includes a representation ofThe request obtains an HTML format listing the means of one or more of the interaction protocols. Indeed obtaining a particular agreement may require some approval and/or payment of a certain commission. When the interaction protocol has actually been obtained, it is stored in the E-PIA. However, the interaction protocol hasPriority rulesAnd one usable or modifiable by HTML formatLack of Province map。

E-AutoPIA

E-AutoPIA has only their creationRoute. This is because one E-AutoPIA is always instantiated from one E-PIA. To create a route to browse an electronic proxy for an interactive protocol is implemented in the same way, e.g. with E-PIA. However, instead of restoring an interactive protocol, an interactive instruction with parameters to be filled in is obtained.

Format repository

Because the structural summaries of the E-PIA information are reused repeatedly, the HTML format necessary to fill in the various E-PIA structures may be stored in a shared area called a format or electronic character repository. These repositories may be simple FTP sites or even possibly netscape server systems. It is also possible to store HTML format associated with the interaction protocol, the interaction instructions, and the route. However, as will be described later, the E-PIA using these objects must have a special trust token associated with each of these objects in order to actually perform their intended activities.

Run time

At runtime, a person owning the E-PIA or E-AutoPIA does not see anything happening because all interactions are handled by the E-metro server. However, to see the progress or up-to-date results of the interaction, an owner may revert his information resources to review the clues contained in his E-PIA(s) or E-AutoPIA(s). Note that a person may have multiple E-PIAs but only one is designated as a master E-PIA (more master E-PIAs will be described later). The representation uses HTML text whenever possible. In some cases, the status of the E-PIA may indicate that someone is waiting to further act on the owner portion to occur before the camper can proceed.

Electronic group management time

Electronic community administrators need to maintain, repair, and update electronic agents in an electronic community. Electronic community managers also need to be able to give priority to everything within an electronic community boundary (i.e., containing the electronic community) in order to ensure that everything runs smoothly or to locate problems. Backup and restore functions must also be performed.

Electronic city management time

An electronic metro manager simply having access to everything is not present. Each electronic community automatically maintains and manages its own resources according to rules established by the electronic community. This is the key to the concept of ownership in an electronic metro.

Client and server subsystem

The user's domain consists of only the electronic group and the electronic agent belonging to them, the format repository, and the world wide web browser of the netscape. The user understands that all electronic groups are connected to each other via the internet and that they are connected to via the internet to which an "http:// www. The previous section mentions how all data in the electronic metro is transformed to an HTML format before presentation to the user. This transformation occurs on the server so that only the netscape client and one of the existing HTML-aware client programming systems (e.g., C + + and NCAPI, or JAVA) are required on the client workstation. Note that separate electronic groups may or may not actually be located at the same site, but the considerations of their physical location are irrelevant to the user.

The user may also wish to use an electronic metro security card to store the information asset. In using some services this requires confirmation of the user, but there may be other ways in which one wishes to store his resources. There may only be one place where one wishes to save his resources at a certain time-where the overall decision of the person owning the E-PIA is, when, and how to store or share their information resources.

Respective group administrator

An electronic community manager uses an electronic community management tool to manage one or more electronic communities on a single electronic metropolitan world wide area network server. While each electronic community administrator is aware of his electronic community and their corresponding electronic agents created by the electronic community development group, an electronic community site administrator specified by an electronic community administrator is also aware of the electronic metropolitan and the processes of the netscape server that may need to be monitored and/or configured. Due to the stringent security requirements in electronic metro cities, the administrative tool client application requires a direct access to the electronic metro server instead of a direct login via any internet protocol. Note that this restriction does not deny telnet. An electronic community manager may also install a format repository on the server, if desired.

Detailed object model

One of the main features of the electronic metro object model is that the first class of objects, E-PIA, are not examples of categories (at the user level) but only a few. Instead, they dynamically assign behavior at any time through protocol assignments. This provides the convenience of adding behavior incrementally or subtracting behavior decrementally. It is believed that this convenience is essential to the changing needs of the day and the different activities one wishes to do or explore.

Electronic figure

B1. The purpose of an electronic character-an electronic character represents a "life" in the computer world of an electronic city. This life, or electronic character, must have a desire or an objective to interact with other electronic characters in order to be available in the electronic metropolitan area for re-wiring.

B2. An electronic character may represent life of anything-note that the life of a computer space may be given to objects that generally should not be considered "life". For example, a dead person can be indicated. The main purpose in an electronic metro is to have a real live person represented by an electronic character, which may also represent a real animal, a real company, a real organization, a real inanimate object, or even a knowledge object stored and saved in an electronic form outside the electronic metro. Dead figures all hypothetical (unreal) like above can also be represented.

B3. An electronic character is basically an abstract main category, and no direct instance of the electronic character exists.

Basic information object

I1. The purpose of the underlying information object-the information object holds data in the electronic city and is some example of a category. It is important to mention the basic data because users frequently interact with various basic data types.

I2. The basic categories are:

categories

Integer number of

Character string

Floating point

Boolean algebra

Order collection

Collection

Directory

SQL description

File folder

Executable character string

Compiler program

I3. Basic category with default protocol-the default protocol corresponds to the method of that category. For example, a method of obtaining the size of a subscription collection, aggregation, and inventory may be necessary as may a subscription collection of a particular index and a particular public key for an inventory.

I4. An executable string representation can be transmitted around as an object, interpreted when needed, and processed as a piece of code-the executable string requires some parameters to be entered. Zero, one and two parameter executable strings should be supported. Each executable string defines the name of its compiler/interpreter. This allows information in the executable string that reference names are to be aggregated to different content controlled by the compiler.

I5.SQL description wants to provide a carrier for quickly finding information while being able to refer to E-PIA information-since one E-PIA information reference is hierarchical, SQL is not fully supported by SQL description objects without SQL adaptation. These references obtain the patching of a particular compiler provided by the e-metro.

I6. A folder can employ hierarchically arranged public key storage objects.

I7. An extended set of classes should have to provide object protocols that support various standards-some examples are OLE objects, open file objects, and SOM objects. This is necessary because some information resource data is desired to be stored by a person in such a format.

I8. An extended set of categories should have to provide support for a variety of media-some examples being voice, video, and images.

I9. The very important directory objects are simply displayed to the user of a directory as a list of public key objects-these are often considered to be the "values" of the directory. A public key is used to look up a value or object in the directory. These public keys are some representative strings or symbols (as in small conversations) and are used as the names of such public key objects. But these public keys may be what the programmer would look like a useful one. These values may be any object. An example of a directory is shown below.

Public key	Value of
		'Ming'	A string object
Height "	A floating point object
		Street (street) "	A string object

Electronic personal information agent (E-PIA)

The purpose of PIA1. e-PIA-means that a real person and an electronic person keeping the information resources of the real person wish to be shared in a secure way.

PIA2. an E-PIA may be present on an electronic metro security card.

PIA each E-PIA consists of a folder created without structure and edited at the time of authoring-this editing is to be done in the more convenient HTML format changed from the E-metro client subsystem.

PIA4. each E-PIA may specify a set of interaction protocols at creation time by the owner of the E-PIA-the E-PIA only shares information at runtime by one interaction protocol and only one protocol at a time.

PIA5. an E-PIA contains a set of priority rules that must be checked and satisfied for all interactive protocol implementations.

PIA6. an E-PIA contains a set of trust tokens obtained from an electronic proxy at runtime-some or all of such trust tokens may be used at any time for E-PIA interaction.

PIA7. an E-PIA contains a audit trail with which all interactions take place — each recorded event stores information about the interaction of interest (e.g. start time, completion time, any access violations, etc.).

For an E-PIA, each time an interactive protocol is executed on it, a logging event object is attached to its audit trail. For an E-AutoPIA, each time an interaction protocol is executed on its way, a logged event object is appended to its audit trail. The content of the recorded event object needs to be determined according to the need to check the tracking during the development of the electronic metro. Furthermore, certain logging event filters may not be desired to be stored for performance or disk space reasons. Finally, the key to checking the trace is to allow the owner of the E-PIA or E-AutoPIA to recall what has been done.

The PIA8. one E-PIA may have multiple electron populations present simultaneously.

PIA9 if there is more than one E-PIA for a particular person, it is necessary to specify a master E-PIA that contains the names of the electronic groups where some other E-PIA is located.

PIA10. only the master E-PIA can be modified at creation time.

PIA11. each E-PIA contains a certificate with the name of its representative person and the person's public key-provided that at any time a process can check the name and public key pair by querying the appropriate certificate authority.

PIA12. when information from an E-PIA is provided in an information exchange, the text of an E-PIA is constructed at run-time-an E-PIA text contains only:

certifying that

Resource(s)

Priority rules

Comprises oneVerification trackingShould be considered. Note that the E-PIA text generally represents a subset of the information actually contained within the source E-PIA, soResource(s)May be the originalResource(s)A copy of a small portion of a folder. This isCertifying thatHelp verify that name descriptions actually coming from them are in thatCertifying thatThe information of E-PIA in (1). It is important that information can pass through the sharing of information by a third party, the "trust in transfer". Furthermore, in the original E-PIAResource(s)Each individual piece of information in the folder is encrypted with the E-PIA's private key when assembled at the E-PIA's own personal workstation. In the text of an E-PIACertifying thatWith the public key, another E-PIA may have encrypted data and indeed know the text of the E-PIA actually "signed" by the owner.

Tt1. purpose of trust token-a trust token is obtained at creation time from an electronic proxy together with some other objects to protect the usage of the objects, typically an interaction or service, the agents of those electronic proxies. The trust token grants the new owner a major and necessary priority (but not necessarily sufficient priority) to perform the security interaction.

Tt2. when a trust token is given to an E-PIA author, it is encrypted at his local machine using the E-PIA author's private key-then the electronic proxy remembers the E-PIA author's public key.

Tt3. when a secure interaction is requested, the electronic proxy must give the E-PIA name and the encrypted trust token. From this pair, the trust token can be encrypted with a public key obtained from a previous authoring period-the electronic proxy knows that the E-PIA's requesting interaction is trusted only if the trust token can be successfully decrypted.

Interaction protocol

SP1. purpose of Interactive protocol- -an interactive protocol object specifies specially named information and conditions that must be true for the special information to be shared. The shared information is packaged in the form of text of E-PIA. The text of the E-PIA is specifically defined by the output of the interactive protocol.

SP2. an interactive protocol must have a name.

SP3. an interactive protocol object consists of 5 tuples

1) Set of input parameters

2) Output parameter set defined by information stored with shared E-PIA text

3) Default parameter mapping

4) Set of priority rules for direct to-occur sharing

5) A set of transmission priority rules for which E-PIA text sharing is to occur by a third party (transmission sharing). At run-time, the rules are backed up and placed in the E-PIA text to be sharedPriority rulesIn (1).

6) Boolean operations are enabled- -one interaction may be disabled.

SP4. execution of an interactive protocol creates an E-PIA text based on the runtime output parameter values. This E-PIA text is what is given and shared with the interacting E-PIA-however, if all output parameter values are previously obtained E-PIA text, then no E-PIA text is generated. Instead the information is transmitted along the originally obtained E-PIA format.

Note that: considering that data is to be transmitted as line data in some situations, not always as a text of E-PIA, it should be studied. It may be an option to transmit data as an E-PIA text or line data, perhaps during the interactive protocol and interactive instruction writing.

SP5. the shared E-PIA text, each piece of its basic information has been encrypted with the private key of the E-PIA-this encryption takes place at the E-PIA's individual user workstation when the information of the master E-PIA is assembled. Subsequently, additional E-PIA or treatment can be utilized thereinCertifying thatThe public key decryption of the E-PIA text found in (1).

Note that because the private key is never on the server, the import or export parameters that are often used to transmit data in an E-PIA text may need to be strictly restricted to rich expressions, since typically an expression result will need to be re-encrypted with the private key.

SP6. A default parameter map for an interactive protocol is a directory that displays the names of zero or more parameters and a hierarchical name for each listed parameter associated therewith.

SP7. an interaction protocol can inherit an existing interaction protocol- -this subset interaction protocol inherits its 4-tuple which can add more parameters and rules.

SP8. an E-PIA can overwrite any or all of the interactive protocols assigned to itSuperior food Priority rulesThe time-of-creation E-PIA must offer this possibility.

SP9. Default image is intended to act as a helper for the construction of corresponding interactive instructions- -since interactive instructions must fill in parameters of an interactive protocol with expression strings, it may be good to fill in some or all of the parameters with general desired default values. The following table shows an example of a default map.

Parameter names	Default value
		'Ming'	Name (name)
Height "	Appearance, physical Property, height
		'street'	Address street

Simulations in the C/C + + language should be prototypes of functions:

handling special information (string name, float height, string street) will be automatically filled in with a default call: handling special information (name, shape, physical attributes, height, address, street)

These default parameters are implemented to locate those referenced variables that are aggregated into the folder of the E-AutoPIA.

Parameter(s)

P1. purpose of parameter-a parameter is an "information route" specified for an information object to be either input to or output from an interaction.

P2. each parameter is a 2-tuple (name, validity rule) -validity rule can be used at run-time to check type. For example, the expression "iskindof: a Class "determines whether the runtime parameter value is an instance of a Class or one of its subsets. A more complex example would be the combination of a type verification and a general expression such as: (myselfimberOf: Float) & (myself > 203500.00).

Rules

Purpose of a rule-a rule is assigned to some activity and describes the conditions under which the activity occurs. Otherwise the activity does not occur. It is important to note that the rule grammar must be multi-social centric.

R2. rules are executable strings that represent expressions that qualify for true or false.

R3. the regular expression syntax must identify multiple ranges-in most interesting cases, two E-PIAs may satisfy two ranges of our all interests. These two scopes are sharer and sharee.

R4. to facilitate reference for two object satisfaction, the public keys "i am themselves" and "you are" should be built in the syntax — i am themselves referring to the set of sharers (sharing E-PIA) and you are themselves referring to the set of sharees (meeting sharer E-PIA).

R5. to facilitate reference to be satisfied by more than one object, the public key "yourself" should be built in the syntax-yourself refers to the set of sharees (E-PIA where the sharee meets). The index may be used to indicate a particular sharee. You are always the same as you themselves indexing 0.

R6. these references are used to point to a piece of data hierarchically located within an object-a reference can be separated by name by a space that is accessed to point to the hierarchy.

Example (c): the rule to limit the activity of a sharer to only those who are more than 6 feet must be that your own physical profile height > 6

R7. these rules are intended to be interpreted at runtime-therefore, only some errors are expected to be discovered at creation time.

Electronic autonomous personal information agent (E-AutoPIA)

APIA1. purpose of E-AutoPIA-E-AutoPIA replaces main E-PIA to work as intelligent agent. An E-AutoPIA is an E-PIA that initiates tasks that desire to interact with other E-PIAs in a local or remote electronic community.

Apia2. an E-AutoPIA is an E-PIA with at least one route assigned to it.

Apia3. an E-AutoPIA can only be sent from a master E-PIA, i.e. a route is executed.

Apia4. one master E-PIA may send multiple E-autopias.

Route

I1. Route destination-a route consists of a list of some interactive instructions to be executed.

I2. A route must have a name.

I3. A route contains a set of priority rules-these rules must satisfy all the instructions of interaction and are in turn the priority rules defined for E-AutoPIA.

I4. A route contains a set of transmission priority rules that govern the transmission sharing of any E-PIA text (or E-AutoPIA text in this case) shared within the route by the instructions of interaction. The transmission priority rule is in turn any transmission priority rule defined for an individual interactive instruction itself. At run-time, the rules are backed up and placed in the E-PIA text to be sharedPriority rulesIn (1).

I5. A route contains a set of zero or more originals-an original is exactly one executable string written in some programming languages. These scripts are able to control when and how these interactive instructions are executed. Thus, these scripts are simply generic programmable encodings for whatever the programmer wishes to do. However, a positive instinct can call an interactive instruction with its name and transfer it as a variable within its parameters. Only the interactive instructions or the hyper-generic routes of a route can be called from the original that is added to the same route object. The network impact is that these instructions can be invoked in any order. The interactive instructions can only be invoked sequentially when no originals are present in the way.

I6. A route consists of one or more interactive instructions-if no originals exist, the interactive instructions are executed sequentially.

I7. A route may inherit an existing route-the subset routes inherit the rules, originals and routes of the primary route.

Interactive instructions

II1. purpose of Instructions- -Instructions are a single point in the overall system that causes interaction between E-PIAs (and, in effect, E-AutoPIAs and E-PIAs). Each interaction instruction describes the interaction to take place and the rules that may take place. It is also important to note that the execution of the instructions of interaction is only one way to exchange information resources.

II2. Each interactive instruction is a 5-tuple

1) Electronic group names

2) Name of interaction protocol

3) Distribution of parameters

4) Set of priority rules for direct to-occur sharing

5) A set of transmission priority rules for which E-PIA text sharing is to occur by a third party (transmission sharing).

6) Maximum number of interactive instructions

And II3. executing an interactive protocol to create an E-AutoPIA text according to the input parameter value of the running time. This E-AutoPIA text is what is given and shared with the interacting E-PIA-however, if all input parameter values are previously obtained E-PIA text, then no E-AutoPIA text is generated. Instead the information is transmitted along the E-AutoPIA format as originally obtained.

The shared E-AutoPIA text, each piece of its basic information has been encrypted with the private key of the E-AutoPIA-this encryption takes place at the E-PIA's individual user workstation when the information of the master E-AutoPIA is assembled. Subsequently, additional E-PIA or treatment can be utilized thereinCertifying thatThe public key decryption of the E-PIA text found in (1).

Note that because the private key is never on the server, the import or export parameters that are often used to transmit data in an E-PIA text may need to be strictly restricted to rich expressions, since typically, an expression result will need to be re-encrypted with the private key.

II5. thePriority rulesThe instructions of the interaction to be executed-they are in addition to the rule set for the route, the rule set for the execution of E-AutoPIA must be satisfied.

II6. theTransmission priority rulesBacked up and placed in shared E-PIA text due to execution of interactive instructionsPriority rulesIn (1).

II7. Only the largest inter-instruction of the E-PIA will participate in the execution of one inter-instruction- -this value may be infinite.

An interactive protocol must be able to produce an HTML format that represents interactive instructions with parameters already filled in.

And II9. a special 'update main' interactive instruction for updating the latest information in the E-AutoPIA to the main E-PIA thereof, namely an implicit 'update main' interactive instruction is executed at the route terminal.

Note that this special interactive instruction requires the E-AutoPIA to physically access its master E-PIA.

Clarifying the relationship between interaction protocols and interaction instructions

An interactive protocol basically maintains a temporary relationship to an interactive instruction. An interactive protocol is represented by a signature of the parameter to be "filled in", while the copy of the interactive instruction is identical except for the parameter to be "filled in".

The interaction protocol and the interaction instructions are two authoring time entities. The interaction protocol represents services provided by and is written with an electronic agent. The instructions for interaction are written for an E-AutoPIA during construction of a route. Each interactive instruction represents a "request interaction" or invocation of an interaction protocol.

Also, FIG. 19 shows the priority rules of a portion of the interaction protocol. Each priority rule is a set of rule objects. As previously mentioned, each rule is an expression string that is processed using a rule compiler. All priority rules must be true in order to accommodate an interaction protocol to be executed. As previously described, these rules can locate both me themselves (the provider of the interaction protocol interaction) and you themselves (the interaction requested by the E-AutoPIA). Parameter objects with valid rule objects may also be displayed. These rules can only be applied to the parameters that are actually transmitted.

FIG. 18 also shows some of the instructions for interaction, such as with priority rules. These sets of rules may be added by an E-AutoPIA editor when he is setting up a route and when he has decided that certain rules should be kept in the interaction protocol priority rules regardless of the interaction instructions involved.

Electronic group

C1. Purpose of electronic group-an electronic group provides a concept of grouping for E-PIA and other electronic groups. In this regard, one electronic community also provides security for grouped objects.

C2. An electronic group is an electronic character-an insight that an electronic group maintains an electronic city of life concept in which the purpose is to share information and interact with general electronic characters.

C3. An electronic group must have a name.

C4. An electronic community contains zero or more E-PIAs-these E-PIAs reside together because they share the same objects within the shared information. Thus, an E-AutoPIA seeking a particular E-PIA will know which electronic group to access.

C5. An electronic population may contain other electronic populations so that they can be arranged hierarchically-the contained electronic populations, in turn, each may contain one or more electronic populations. However, this hierarchy must be limited in that one electron population cannot be contained by multiple main electron populations.

C6. Each electronic group is made up of electronic agents that the electronic group has decided to make available.

C7. Each electronic community contains no instructions for interaction because they may not interact.

By subagent

BR1. purpose of electronic Agents- -one electronic agent is a request for all internal-PIA interactions. The electronic proxy ensures that all E-PIA's contained in an interaction have the right to interact in the way the interaction is to be performed according to the interaction protocol.

Br2. each electronic agent possesses one or more interaction protocols.

Br3. an electronic agent contains subsystems that execute all its own interaction protocols.

Br4. an E-AutoPIA can only interact with an E-PIA in an electronic community having electronic agents with interactive protocols determined by current interactive instructions.

Br5. an electronic proxy must generate a unique trust token for each of its interaction protocols.

Br6. the interaction command can only be written by obtaining the corresponding interaction protocol from an electronic agent.

BR7. the electronic proxy transmits the interaction between E-PIA and E-AutoPIA as follows:

1) confirming that E-AutoPIA satisfies the electronic groupPriority rules。

2) It is confirmed that the E-AutoPIA has a decryptable trust token corresponding to the interaction protocol being executed.

3) Confirmation of E-AutoPIAPriority rules。

4) Route to confirm E-AutoPIAPriority rules。

5) Validating current interactive instructions of E-AutoPIAPriority rules。

6) Confirming that any transmission exchanges E-PIA text to be an input or output parameterPriority rules。

7) Call entry point of electronic agent corresponding to interactive protocol implementation-only parameters of (6) of E-AutoPIA interactive instruction that pass the acknowledgement are entered.

8) Determine the special collection of E-PIA contained in the interaction-this is according to three conditions:

a) task 3 is confirmed by above 5.

b) An additional selection rule is provided through an electronic metro API call in the executable electronic proxy.

c) Of E-PIA selected according to a) and b)Priority rules。

9) The implementation of the electronic agent is performed-if any failure occurs, the interactive instructions do not complete successfully.

10) Only the E-PIA interaction protocol is output via the acknowledged parameters.

Br8. each electronic agent provides an "interactive protocol directory" service-this service replies to a generated HTML text describing all interactive protocols provided by the electronic agent.

Br9. each electronic proxy provides a get interactive rights protocol service-this service replies to the interactive protocol with a trust token. It is important to note that this service may be performed by the electronic proxy in any manner. For example, this service may be the right one desires for an interaction agreement having to confirm who it is and/or who is to pay for the right. The electronic proxy may reject a trust token for any reason.

Br10. electronic agents can interact directly regardless of their electronic group priorities belonging to an electronic group-however, interaction with an electronic agent does not require any electronic group priority to be obeyed.

Having described and illustrated the principles of our invention with reference to a preferred embodiment, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. Likewise, it should be recognized that the detailed embodiments are illustrative only and should not be taken as limiting the scope of our invention. Rather, we claim as our invention all embodiments falling within the scope and spirit of the following claims and equivalents thereto.

Claims (23)

1. An electronic marketplace, comprising:

a plurality of electronic personal information agents, each agent securely encapsulating a personal information object for a particular entity and exchanging rules that control processing of the personal information object; and

an electronic marketplace electronic agent that receives the electronic personal information agents over a distributed electronic network, the electronic marketplace electronic agent securely processing transactions between the electronic personal information agents to exchange personal information processing rights for value or benefit, the electronic marketplace electronic agent ensuring that the exchange rules are satisfied prior to conducting transactions and that the personal information objects encapsulated within the personal information agents are kept secret.

2. The electronic marketplace of claim 1, wherein the electronic personal information agents centrally negotiate their respective personal information handling rights for value or benefit.

3. The electronic marketplace of claim 1, further including a commerce distributor that processes all incoming transaction requests received from said electronic personal information agents with said electronic marketplace subagent.

4. The electronic marketplace of claim 1, wherein further comprising a public product database that persistently stores product information accessible by the electronic personal information broker.

5. A computer-implemented system for remotely controlling personal information resources over a distributed electronic network, comprising:

a plurality of electronic entities capable of being transmitted over a distributed electronic network, each electronic entity securely encapsulating a personal information resource of an owner of the electronic entity;

an electronic agent connected to a distributed electronic network, said electronic agent controlling the transfer of personal information resources from one electronic entity to another electronic entity; and

means for allowing a user to track access to and use of the owner's personal information resource after the personal information resource is transferred to the receiving electronic entity.

6. The computer-implemented system of claim 5, wherein the use of the owner's personal information resource is revoked at a future point in time after the transfer to the receiving electronic entity.

7. The computer-implemented system of claim 6, wherein after the transfer to the receiving electronic entity, the use of the owner's personal information resource is revoked after an optional time period selected by the owner.

8. The computer-implemented system of claim 6, wherein access or use of the owner's personal information resource is denied at the future point in time because one of the exchange rules is no longer satisfied.

9. The computer-implemented system of claim 5, further comprising a community manager entity for managing the electronic entity and the electronic agent.

10. The computer-implemented system of claim 5, further comprising means for allowing the owner to control access to or use of the personal information resource of the owner after the owner transfers the receiving electronic entity.

11. An electronic marketplace, which includes

A plurality of electronic personal information agents, each agent securely encapsulating a personal information object for a particular entity and exchanging rules controlling the processing of the personal information object, one or more of said electronic personal information agents recommending a quantity of a product or service for a transaction, and one or more of said electronic personal information agents configured to promote said product or service;

a community public product database for persistently storing product data accessible by said electronic personal information agency; and

an electronic marketplace electronic agent that receives the electronic personal information agents over a distributed electronic network, the electronic marketplace electronic agent securely processing transactions between electronic personal information agents seeking individual or centralized transactions for recommended products or services, the electronic marketplace electronic agent ensuring that the exchange rules are satisfied prior to conducting transactions and privacy of personal information objects encapsulated within the personal information agents.

12. The electronic marketplace according to claim 11, wherein the electronic marketplace allows one or more personal information objects to be transferred between personal information agents during a transaction according to the exchange rules.

13. The electronic marketplace according to claim 12, wherein the one or more personal information objects are transmitted to a receiving personal information agent in conjunction with an exchange rule that controls processing of the personal information objects, and thereafter the personal information objects are accessed by the receiving personal information agent or other personal information agents only in accordance with the exchange rule.

14. A computer-implemented system for the secure exchange of personal information resources over a distributed electronic network, comprising:

a plurality of standard templates for self-defining preferred items of information for the transaction of beneficial information;

means for selecting one of said templates to form an electronic entity for securely encapsulating the owner's personal information resource and for mastering rules governing the exchange and control of the owner's personal information resource;

means for securely storing the electronic entity; and

means for transmitting said electronic entity over a distributed electronic network according to said information customization preferences to perform a transaction for beneficial information.

15. The computer-implemented system of claim 14, further comprising an electronic agent for processing said information discretionary preferences and for securely arbitrating between electronic entities involved in the transaction of information benefits and maintaining privacy of the owner's personal information resources.

16. The computer-implemented system of claim 14, wherein the electronic entity includes one or more electronic certificates that authenticate the authenticity and accuracy of the owner's personal information resource.

17. A computer-implemented system for exchanging personal information with value over a distributed electronic network, comprising:

an electronic personal information broker securely encapsulating a personal information object for a particular owner entity; and

an electronic marketplace electronic agent that receives the electronic personal information agent over a distributed electronic network and securely processes transactions between the electronic personal information agent and another electronic entity seeking to exchange personal information processing rights with value or benefits.

18. The computer-implemented system of claim 17, wherein the electronic personal information agent securely encapsulates transaction rules that control the processing of personal information objects of the electronic personal information agent, the electronic agent ensuring that transactions are satisfied prior to processing the transactions and maintaining confidentiality of personal information objects encapsulated in the personal information agent.

19. The computer-implemented system of claim 17, further comprising a community manager entity for managing the electronic personal information broker, the electronic entity, and the electronic marketplace electronic broker.

20. A computer-implemented system for remotely commanding and controlling personal information resources over a distributed electronic network, comprising:

a plurality of electronic entities capable of being transmitted over a distributed electronic network, each electronic entity securely encapsulating personal information resources of an owner of the electronic entity and exchange rules controlling processing of the personal information resources of the owner, wherein each owner may control a plurality of electronic entities having different or alternative sets of personal information resources associated with the owner; and

an electronic agent connected to the distributed electronic network, the electronic agent controlling the transfer of personal information resources from one electronic entity to another and ensuring that the processing rules are satisfied prior to transaction processing and maintaining confidentiality of personal information objects encapsulated in the electronic entities.

21. A method for exchanging entities and personal information resources over a distributed electronic network, comprising the steps of:

establishing at least one network community;

allowing members of a network community to establish one or more electronic personal information agents, each electronic personal information agent securely encapsulating a personal information object for a particular network community member and a set of exchange and usage rules for controlling the exchange and prior use of the owner's personal information resources by other electronic personal information agents; and

an electronic agent is established that receives the electronic personal information agent over a distributed electronic network and securely processes transactions of personal information resources in the electronic personal information agent.

22. The method of claim 21, wherein the electronic agent ensures that the exchange and usage rules for the electronic personal information agent are satisfied before allowing the transfer of the owner's personal information resource to another electronic personal information agent.

23. The method of claim 22, further comprising: except under conditions that continue to satisfy the exchange and usage rules of the owner, the owner's personal information resources are prevented from being accessed by other electronic personal information agents after transmission.