Personal information security and exchange tool5987440
Abstract
Utilization of the E-Metro Community and Personal Information Agents assure an effective and comprehensive agent-rule based command and control of informational assets in a networked computer environment. The concerns of informational privacy and informational self-determination are addressed squarely by the invention affording persons and entities a trusted means to author, secure, search, process, and exchange personal and/or confidential information in a networked computer environment. The formation of trusted electronic communities wherein members command and control their digital persona, exchanging or brokering for value the trusted utility of their informational assets is made possible by the invention. The present invention provides for the trusted utilization of personal data in electronic markets, providing both communities and individuals aggregate and individual rule-based control of the processing of their personal data.
Claims
We claim as our invention all such embodiments as may fall within the scope and spirit of the following claims and equivalents thereto:
1. An electronic bazaar for the purpose of facilitating electronic commerce by auction comprising:
an electronic bazaar electronic broker which securely processes a transaction to ensure that rules are satisfied before a transaction is processed;
an electronic personal information agent which securely encapsulates entities' personal information objects and rules governing processing;
a commercial activity dispatcher which handles all incoming transaction requests with said electronic bazaar electronic broker;
a public product database which persistently stores product information processed by said electronic bazaar electronic broker;
a trusted token processor which stores and processes public keys from said electronic personal information agents and issues and validates trusted tokens presented by said electronic personal information agents;
an advertiser directory which stores and processes orders, product information and order forms as initiated by transaction requests; and
a private activities database which stores advertiser pending orders, inventories, and information necessary to carry out transactions.
2. An electronic bazaar as in claim 1 which operates on a semi real-time basis.
3. An electronic bazaar as in claim 1, further comprising computer-implemented means for aggregating individual orders of the same product into bulk units, said individual orders received from a plurality of electronic personal information agents, and for facilitating a bulk unit transaction between a bulk unit buyer or seller and the individual orders from said electronic personal information agents.
4. A computer-implemented system for securely asserting and enforcing the informational privacy and informational self-determination rights and responsibilities of an entity by providing secure and private storage as well as secure and private information exchange via trusted processes and cryptographic mechanisms, the computer-implemented system comprising:
means to securely store an entity's personal information in the form of a self-determining digital persona such that it is accessible only to the entity or trusted processes, said personal information being stored in an encrypted manner;
trusted process means for securely and privately exchanging some or all the personal information between entities in a manner so as to prevent access by other processes to the personal information being exchanged as well as to the personal information not being exchanged;
wherein said trusted process means bases an exchange of personal information on personal privilege rules of each entity so as to permit an incremental exchange of personal information stored in the entity's self-determining digital persona as each individual or set of personal privilege rules are incrementally satisfied;
wherein said trusted process means further assures that entities involved in a potential or partially performed exchange are unaware of each other's identities unless information concerning their identities is intentionally exchanged, and are unaware of why specific personal privilege rules have failed, if any; and
means to assure that any exchanged personal data is delivered to the receiving entity privately in such a manner that the receiving entity can process only that data which the personal privilege rules allow it.
5. The computer-implemented system of claim 4, wherein the entity's personal information is encrypted by a key that is securely stored, said computer-implemented system having exclusive access to said key and, therefore, exclusive capability to decrypt said personal information for a trusted and secure process.
6. The computer-implemented system of claim 4, wherein the incremental exchange of personal information occurs within a single continuous exchange session between the entities.
7. The computer-implemented system of claim 4, wherein the incremental exchange of personal information occurs in multiple exchange sessions separated by arbitrary amounts of time, each of said exchange sessions independently initiated by one of the exchanging entities, and each exchange session involving the satisfaction of a different set of one or more personal privilege rules.
8. The computer-implemented system of claim 4, wherein said trusted process means for securely and privately exchanging some or all personal information between entities further comprises means for providing trusted exchange of an initiating entity's personal information with another trusting entity with which it has established, in a previous interaction, trust to exchange information at a different location or a future time.
9. The computer-implemented system of claim 4, wherein said means for providing trusted exchange at a future time further comprises means for the trusting entity to provide a trusted token that denotes trust in the initiating entity for future interaction and exchange of information.
10. The computer-implemented system of claim 9, wherein said trusted token is double encrypted, first by a private key of the initiating entity, and then with a public key of the trusting entity, so as to ensure that only the trusting entity can decrypt the trusted token with its private key and then use the initiating entity's public key to validate that the trusted token was in fact supplied to it earlier.
11. The computer-implemented system of claim 4, further comprising means for asserting and enforcing transitive trust to govern the onward transfer of exchanged personal information, said means for asserting and enforcing transitive trust comprising means to replicate the self-determining digital persona in one or more versions, each replicated version securely encapsulating personal information and privilege rules governing access to the personal information during exchange transactions, and each replicated version capable of interacting autonomously with other entities, but on behalf of the originating entity, with ongoing dynamic interactions or negotiations based on its personal privilege rules.
12. The computer-implemented system of claim 4, wherein said privilege rules are capable of performing general processing functions or requiring that arbitrary criteria be met, said general processing functions including the ability to exchange monetary value for permitting the receiving entity to have a privilege of processing transferred personal information.
13. The computer-implemented system of claim 4, wherein said means to securely store an entity's personal information in the form of a self-determining digital persona comprises means for securely authoring and encapsulating personal information electronically as secured personal information comprising informational assets of the entity, the personal information comprising one or more information objects and one or more personal privilege rules governing each information object's trusted brokering and its trusted onward utilization, said personal privilege rules comprising computer readable program code and collectively governing whether or not a self-determining digital persona will allow interaction with another self-determining digital persona and whether or not specific personal information will be exchanged with the other self-determining digital persona;
means for encapsulating one or more digital certificates along with said personal information to establish the originating entity as a non-reputiatable source of the personal information or to corroborate the reliability of the personal information objects.
14. The computer-implemented system of claim 13, further comprising means for asserting and enforcing transitive trust to govern the onward transfer of exchanged personal information, said means for asserting and enforcing transitive trust comprising means to replicate the self-determining digital persona in one or more versions, each replicated version encapsulating said one or more digital certificates, personal information objects and privilege rules governing access to the personal information objects during exchange transactions, and each replicated version capable of interacting autonomously with other entities, but on behalf of the originating entity, with ongoing dynamic interactions or negotiations based on its personal privilege rules.
15. The computer-implemented system of claim 14, further comprising means for maintaining a secured audit trail recording of each attempted and actual secured interaction and the information, if any, exchanged in each interaction.
16. The computer-implemented system of claim 14, further comprising means for securely and accountably commanding and controlling the replicated versions of the self-determining digital persona wherever they are currently located.
17. The computer-implemented system of claim 14, wherein said self-determining digital persona further comprises a plurality of interaction protocols governing specific secured personal behaviors or interactions with other self-determining digital personas.
18. The computer-implemented system of claim 17, wherein said interaction protocols each comprise:
computer readable program code representing specific personal behaviors;
one or more secured privilege rules which determine if the self-determining digital persona has the rights necessary to begin information processing; and
one or more transitive privilege rules governing onward transfer of any securely and trustfully exchanged personal data, whereby said self-determining digital persona defines what conditions its information objects, if passed onto another entity in the form of another version of the original self-determining digital persona, must maintain, protecting and enforcing the originating entity's command and control.
19. The computer-implemented system of claim 14, further comprising means for establishing a trusted network community that represents a secure and trusted environment for a plurality of electronic personal information agent members effectively maintaining shared informational privacy and informational self-determination rights and responsibilities individually and corporately as a group in order to assert and enforce the informational privacy and self-determination rights of the community, said trusted network community comprising:
a trusted network community name;
secured persistent storage for storing self-determining digital personas which are members of the trusted network community and their respective electronic manifestations, said electronic manifestations including the replicated versions associated with each self-determining digital persona, each replicated version functioning as an electronic personal information agent on behalf of its associated self-determining digital persona;
active electronic personal information agents whose self-determining digital personas desire secure, private, and trusted interaction with one or more members of the trusted network community; and
active visiting electronic personal information agents that do not belong to the trusted network community but which desire secure, private, and trusted interaction with one or more members of the trusted network community;
wherein said trusted process means comprises an electronic broker, said electronic broker constituting a specially trusted electronic personal information agent member of the trusted network community which acts as a third party on community members' behalf for secure, private, and trusted processing of privilege rules and interact protocols of electronic personal information agent members against active or visiting electronic personal information agents requesting interaction, said electronic broker further comprising:
privilege or exchange rules for visiting electronic personal information agent's eligibility for interaction with said trusted network community;
computer readable program code for implementing interact protocols, including means to securely and trustfully search and collect on active electronic personal information agent's request, a plurality subset of electronic personal information agent members according to:
a) said trusted network community exchange rules;
b) the personal privilege rules from each of the active electronic personal information agents; and
c) the privilege rules from the electronic personal information agent members;
an interact protocol directory comprising a list of public interact protocols offered by the community; and
means for maintaining a secured audit trail recording interactions that take place between active electronic personal information agents, whether members of the trusted network community or visiting from another trusted network community.
20. The computer-implemented system of claim 19, further comprising means for independently verifying said secured audit trail.
21. The computer-implemented system of claim 19, further comprising a computer network server, said computer network server connected to other trusted computer network servers so as to form a computer-networked system comprising the means for trusted and secured exchange of electronic personal information agents, said trusted network servers each comprising:
computer-implemented means for dispatching and packaging securely electronic personal information agents containing digital certificates representing the originating computer network server to allow confirmation that the electronic personal information agent originated from its computer network server; and
computer-implemented means for utilizing said electronic broker upon verification that said electronic personal information agent satisfies destination community network interaction rules.
22. The computer-networked system of claim 21, wherein said computer network is selected from the group consisting of the Internet, wireline telecomputing devices and wireless telecomputing devices.
23. The computer-implemented means of claim 19 wherein said trusted network community contains a plurality of additional contained trusted network communities wherein:
said trusted network community is a parent community to the contained communities;
said contained communities are each a child community;
said child community may contain their own plurality of child communities, forming a hierarchical trusted network community structure;
said child community membership requires membership in the parent community; and
secured and trusted interaction between electronic personal information agents in a child community requires all rules of the parent community to be met.
24. The computer-implemented system of claim 19, wherein said trusted computer network further comprises a trusted network utility, said trusted network utility comprising:
computer-implemented means for allowing entities to securely author and encapsulate personal information objects and processing rules governing the exchange and processing of personal information;
computer-implemented means for administrating personal information and rules governing said information;
computer-implemented means for empowering the entity to securely and accountably command and control all of said entity's personal information agents wherever they are located; and
computer-implemented means for securely browsing the audit trail of any or all of said entity's electronic personal information agent versions wherever they are located.
25. The computer-implemented system of claim 24, wherein said trusted network utility further comprises computer-implemented means for indicating to the author whether a particular search implied by privilege rules will be fast or slow, depending on whether the search is capable of being mapped to a database query.
26. The computer-implemented system of claim 14, wherein said self-determining digital persona further comprises one or more trusted tokens which may be delivered to another entity as a symbol of pre-established trust for a future interaction.
27. The computer-implemented system of claim 4, wherein the self-determining digital persona comprises an autonomous electronic personal information agent (Auto EPIA), said autonomous electronic personal information agent comprising one or more itineraries, each itinerary comprising interact instructions for directing actions of said autonomous electronic personal information agent.
28. The computer-implemented system of claim 27, wherein said interact instructions comprise:
a target or destination trusted network community name for interaction; a predefined interact protocol specifying the interaction;
a dictionary of parameters allowing invocation of said predefined interact protocol;
privilege rules which must be checked and satisfied on all interact instructions; and
transitive privilege rules related to the encapsulated information objects, said transitive privilege rules defining necessary conditions for the processing of said information objects by parties subsequent to the original receiving entity.
29. The computer-implemented system of claim 4, further comprising a forms repository for storing a plurality of information object templates and privilege rules templates, each privilege rules template comprising a default set of rules and corresponding to a predefined behavior type.
30. The computer-implemented system of claim 4, further comprising an electronic bazaar for conducting electronic commerce by auction or direct offer while asserting and enforcing participating entities' digital rights and responsibilities, said digital rights and responsibilities including informational privacy and informational self-determination rights and responsibilities, the electronic bazaar comprising:
an electronic personal information agent structure which provides member entity-merchants or entity-buyers with the ability to search, interact and collectively bargain collective and individual personal information processing privileges in exchange for value;
an electronic bazaar electronic broker which securely processes transactions to ensure that exchange rules are satisfied before a transaction is processed, while maintaining the privacy of personal information encapsulated in the electronic personal information agents during a processing transaction;
a commercial activity dispatcher for handling incoming transaction requests with said electronic bazaar electronic broker;
a public product database which persistently stores product information processed by said electronic bazaar electronic broker;
a trusted token processor which stores and processes public keys from said electronic personal information agents and issues and validates trusted tokens presented by said electronic personal information agents; and
an advertiser directory which stores and processes orders, product information and order forms as initiated by transaction requests; and a private activities database which stores advertiser pending orders, inventories, and information needed for carrying out transactions.
31. The computer-implemented system of claim 30, wherein the electronic bazaar operates on a semi real-time basis.
32. The computer-implemented system of claim 31, wherein the electronic bazaar further comprises computer-implemented means for aggregating into bulk units individual orders of same product, so that bulk unit buyers and sellers can transact without having to find a corresponding single bulk unit seller or buyer.
33. A trusted electronic exchange process operating on a programmable computer system, the process comprising the steps of:
receiving, at the computer system, a communication from an originating source, said communication comprising
a) a digital certificate binding a public key to the originating source;
b) information in the form of information objects relating to said originating source;
c) privilege rules associated with said information objects, said privilege rules defining if and under what conditions said information objects may be processed by a receiving electronic entity; and
d) one or more interaction instructions collectively defining a set of search criteria;
verifying, at the computer system, that said communication was originated by said originating source;
securely identifying, at the computer system, and without access to said originating source, home electronic personal information agents that satisfy said search criteria, said home electronic personal information agents encapsulating secured information and privilege rules governing access to said information;
securely executing privilege rules encapsulated within the home electronic personal information agents on the information objects from said originating source, so as to determine if the information objects encapsulated within said home electronic personal information agents meet the conditions for further processing;
replicating the home electronic personal information agents satisfying said criteria and having at least one information object whose privilege rule has been satisfied, thereby generating a plurality of autonomous electronic personal information agents; and
securely dispatching said autonomous electronic personal information agents to the originating source.
34. A distributed object resource management system for use in a personal security and exchange tool fixed in a computer readable medium, comprising:
a messaging subsystem which receives and dispatches electronic autonomous personal information agents, said electronic autonomous personal information agents comprising secured information and rules governing access to said information by other electronic autonomous personal information agents;
an electronic broker which securely intermediates between two or more electronic autonomous personal information agents;
an interaction processor which processes requests from said electronic autonomous personal information agents through said electronic broker;
a rules processor which processes rules from electronic autonomous personal information agents and determines that the rules are satisfied prior to permitting an exchange of information between the electronic autonomous personal information agents;
an object repository where the electronic brokers and the electronic personal agents are maintained persistently; and
a secure remote method invocation system and messaging system for permitting home electronic personal information agents to communicate with replicated electronic personal information agent counterparts.
35. An electronic bazaar for the purpose of asserting and enforcing digital rights and responsibilities of participating entities based electronic commerce by auction and direct offer, said digital rights and responsibilities including informational privacy and informational self-determination rights and responsibilities, the electronic bazaar comprising:
an electronic personal information agent structure which provides member entity-merchants or entity-buyers to search, interact and collectively bargain collective and individual personal information processing privileges in exchange for value;
a plurality of electronic personal information agents, each securely encapsulating personal information objects for a specific entity as well as exchange rules governing processing the personal information objects;
an electronic bazaar electronic broker which securely processes transactions to ensure that exchange rules are satisfied before a transaction is processed, the electronic bazaar electronic broker maintaining the privacy of the personal information objects encapsulated within said personal information agents during a processing transaction;
a commercial activity dispatcher for handling incoming transaction requests with said electronic bazaar electronic broker;
a public product database which persistently stores product information processed by said electronic bazaar electronic broker; and
an advertiser directory which stores and processes orders, product information and order forms as initiated by transaction requests; and a private activities database which stores advertiser pending orders, inventories, and information needed for carrying out transactions.
36. The electronic bazaar of claim 35 which operates on a semi real-time basis.
37. The electronic bazaar as in claim 36 further comprising
computer-implemented means for aggregating into bulk units individual orders of same product, so that bulk unit buyers and sellers can transact without having to find a corresponding single bulk unit seller or buyer.
38. The electronic bazaar of claim 35, further comprising a trusted token processor which stores and processes public keys from said electronic personal information agents and issues and validates trusted tokens presented by said electronic personal information agents.
39. A computer-implemented system for asserting informational privacy and self-determination rights and responsibilities of network members, comprising:
a plurality of electronic entities, each electronic entity comprising secured personal data and exchange rules governing access to said information; and
computer-implemented means for providing trusted processing between two interacting electronic entities such that only a trusted process is able to securely access each interacting electronic entity's personal data for the purpose of securely computing each entity's privilege rules and determining whether an exchange of some or all personal data will occur.
40. A computer-implemented system for asserting and enforcing transitive trust of information exchange between entities by way of their self-determining digital personas, the computer-implemented system comprising:
a plurality of self-determining digital personas, each self-determining digital persona securely encapsulating an entity's personal information and privilege rules governing access to said personal information;
means for securely determining whether some or all of an entity's personal information will be transferred to another entity or entities based upon the privilege rules governing access to the personal information; and
means for trusted onward transfer of the personal information to be transferred, said means for trusted onward transfer comprising means for transforming the personal information to be transferred into an automatically created new version of the self-determining digital persona encapsulating both the personal information and privilege rules governing the personal information, and for dispatching the new version of the self-determining digital persona to the receiving entity;
wherein a separate new version of the self-determining digital persona is created for each receiving entity;
wherein each new version of the self-determining digital persona is capable of acting autonomously but on behalf of the originating self-determining digital persona with ongoing dynamic interactions or negotiations based on its encapsulated privilege rules; and
wherein the personal information encapsulated within the new version of the self-determining digital persona can be onwardly transferred only when its encapsulated privilege rules are satisfied.
41. A computer-implemented system for representing an entity with its securely authored self-determining digital persona which allows assertion and enforcement of the entity's informational privacy and self-determination rights and responsibilities within a trusted community network, the computer-implemented system comprising:
means for securely authoring and encapsulating personal information electronically as secured personal data in the form of a self-determining digital persona representing informational assets of the entity, the personal information comprising one or more information objects and one or more personal privilege rules governing each information object's trusted brokering and its trusted onward utilization,
said personal privilege rules comprising computer readable program code and collectively governing whether or not a electronic personal information agent will allow interaction with another electronic personal information agent and whether or not specific personal information will be exchanged with the other electronic personal information agent;
means for providing both secure and private storage as well as secure and private information exchange for the entity's encapsulated personal information, said means comprising
means to securely store the entity's personal information such that only the entity or trusted processes have access to it, the information being encrypted using a key which is securely stored and accessible only to secured processes within the computer-implemented system;
means to securely exchange some or all of an entity's encapsulated personal information with another entity in a manner so as to ensure the encapsulated personal information, whether or not exchanged, is inaccessible to other processes, the exchange being based on the encapsulated personal privilege rules of each entity using a trusted process which securely accesses each interacting entity's personal information for the purpose of computing each entity's privilege rules, whereby the entities may incrementally exchange an increasing amount of personal information as an increasing number of privilege rules are satisfied;
means to ensure that entities involved in an attempted or partially performed exchange are unaware of each other's identities unless information concerning their identities is intentionally exchanged;
means to ensure that entities involved in an attempted or partially performed exchange are unaware of why specific privilege rules, if any, were not met; and
means to assure that any exchanged personal information is delivered as a replicated electronic personal information agent version to the receiving entity privately in such a manner that only the receiving entity can process that information allowed by the other entity's personal privilege rules;
means for providing trusted information exchange such that an initiating entity may exchange some or all of its personal information with another trusting entity that it has established, in a previous interaction, trust to exchange information at a different location or at a future time;
means for asserting and enforcing transitive trust to govern the onward transfer of exchanged personal information, said means for asserting and enforcing transitive trust comprising means to replicate the digital persona in one or more versions, each replicated digital persona encapsulating personal information and privilege rules governing access to the personal information during exchange transactions, and each replicated digital persona capable of interacting autonomously with other entities, but on behalf of the originating entity, with ongoing dynamic interactions or negotiations based on its personal privilege rules;
means for encapsulating one or more digital certificates in each replicated digital persona so that any further exchanges of the entity's personal information by one of its replicated digital personas is assured to have originated from the entity; and
means for corroborating the reliability of the encapsulated personal information objects.
Description
FIELD OF INVENTION
The present invention relates to the software management of information within a network computing environment. More specifically, the present invention relates to a software system operating on the Internet that creates a virtual private network where a user may author, secure, search, exchange and process personal information in a trusted and controlled manner. This software system encapsulates trusted communities and their members, where a trusted authority certifies the identity and the informational-self of community members. Once a user is registered with a trusted community, the user can author and secure at will the hypermedia content, command and control the rule-based presentation and processing of their personal information.
BACKGROUND OF THE INVENTION
The introduction and accelerating use of the Internet has resulted in an explosion of both the quantity and availability of personal information. Unfortunately, since the Internet is largely unregulated, there is no assurance that all this information is accurate or reliable, and often the source of the data is not even ascertainable. Additionally, unless particular precautions are taken, anything sent via the Internet is subject to interception and misuse. These joint concerns for data reliability and data protection can be combined into a multifaceted concept of a trusted information utility. Data reliability or trustworthiness is present if the data is accurate and can be authenticated and/or corroborated. Trusted utilization is when data is available for access or processing only by those approved by the owner of the data, and assurance of continued command and control according to rules established by the owner is present. Trusted utilization or trusted processing is especially critical when dealing with personal data. Personal information, such as an individual's credit worthiness, medical history, employment background, or lifestyle is now finding its way on to the Internet. It is likely that law enforcement agencies, credit bureaus, landlords, and others will be using this information to assist in making decisions. Since all these groups make decisions that dramatically impact an individual's life, using incorrect data, or information that they shouldn't even have, can be devastating.
Thus, people realize that something must be done to protect a person's personal information and as more individuals join the Internet, there will be more pressure to collect, use, and market the available personal information, and the individual will want to participate in, command, and control this activity. Collectively, these ideas cannot be properly implemented with the Internet tools presently available, and no tool can efficiently incorporate these ideas. Thus, there is a need to provide an Internet utility or tool for the security and exchange of personal information.
It is therefore an object of the present invention to assist in the trusted utilization of personal information on the Internet by 1) providing a mechanism for individuals or entities securely author and encapsulate personal data and processing rules governing the presentation and processing of personal information, while 2) empowering the individual or entity, at will, command and control of their personal information within network computing environments.
SUMMARY OF THE INVENTION
The present invention is a software system for operating on network servers, with supporting applications operating on an individual user's personal computer system, inclusive of wire-line and wireless tele-computing devices. This invention is directed to a system for allowing an individual or entity to protect, command, control, and process personal information on a computer network, including the Internet. Specifically, this invention facilitates the formation and use of networked Trusted Electronic Communities, hereafter referred to as E-Metro Communities, where each E-Metro Community comprises several members meeting common admission requirements. Preferably, it is the E-Metro Community that sets registration rules and verifies member identity itself or facilitates the use of other trusted Certificate Authorities. The informational identity of each member is encapsulated within the E-Metro Community as electronic personal information agents, hereafter referred to as E-PIAs, with each E-PIA representing a member's information and behavior, with some of the information supplied by each member and some of the information coming from trusted sources external to the member's E-Metro Community. By establishing and enforcing registration rules and performing accountable and audited verifications of member identity, and if so chosen, personal information certification, the E-Metro Community builds a community wherein each of its members can belong and participate in a electronic domain where the rights and responsibilities of privacy and informational self-determination are realized. Thus, it is through the association and certification by a trusted E-Metro Community that a member becomes trusted and reliable in other transactions, but more importantly gains control of their data.
Once a user is a member of an E-Metro Community, the member can assign access rules to each piece of personal information. These access rules set the requirements that must be met before an individual piece of information can be processed. Additionally, the E-Metro Community may get minimum standards for all transactions which must be met. When a request for a particular piece of information is received, E-Metro Community standards and the rule attached to that piece of information is checked by a processes specific to the E-Metro Community, hereafter referred to as the E-Metro Community's E-Broker. The E-Broker is the actual process that checks to see if the requester and the situation meet the requirement of the rule. If so, the E-Broker allows the requested information to be processed; if not, the E-Broker does not allow the information to be processed. Additionally, the information may be transport packaged with transitive privilege rules attached, that is, rules that define the requirements for processing by anyone other than the original member. Using these transitive privilege rules, a member can maintain command and control on third party dissemination and processing of their personal information.
A member may also create an agent, hereafter referred to as an E-AutoPIA, to interact with other members in any E-Metro Community, or even with data external to any E-Metro Community. This agent contains a subset of the personal information on the member, plus contains an itinerary that directs the activity of the agent. Thus, the agent is able to interact with the personal information of other members as directed in its itinerary.
BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing and other objects, features, and advantages of the invention will become more readily apparent upon reference to the following detailed description of a presently preferred embodiment, when taken in conjunction with the accompanying drawings in which:
FIG. 1 shows users connected to network servers accessing the Internet.
FIG. 2 shows how a user of the preferred embodiment views other E-Communities on the Internet.
FIG. 3 shows the components of a digital certificate, e.g., VeriSign's Digital ID.
FIG. 4 shows how RSA Public-key cryptography works and how a digital signature is created and attached to a document to assure authorship.
FIG. 5 shows an E-AutoPIA operating outside the E-Metro Community.
FIG. 6 shows an E-AutoPIA that has collected several informational E-PIAs from several E-Metro Communities.
FIG. 7 shows several network servers, a user's personal computer connected into the Internet plus a wireless communicator.
FIG. 8 shows several E-Metro Community systems along with other resources interconnected by the Internet.
FIG. 9 shows the architecture of the E-Metro Trusted Server.
FIG. 10 details the DORMS subsystem in the E-Metro Trusted Server, which is shown in FIG. 9.
FIG. 11a-d detail the storage mechanism for several objects used in the preferred embodiment.
FIG. 12 details the messaging subsystem used in the DORMS subsystem, which is shown in FIG. 10.
FIG. 13 is a Booch diagram of the E-Metro Community object.
FIG. 14 is a Booch diagram of the E-Broker object.
FIG. 15a is a Booch diagram of the E-PIA object.
FIG. 15b is a Booch diagram of the informational E-PIA object.
FIG. 16 is a Booch diagram of the E-AutoPIA object.
FIG. 17 is a Booch diagram of the itinerary object.
FIG. 18 is a Booch diagram of the Interact Instruction object.
FIG. 19 is a Booch diagram of the Interact Protocol object.
FIG. 20 is a Booch diagram of the rule object.
FIG. 21 is a Booch diagram of the parameter object.
FIG. 22 describes the relationship of the various classes of objects used within the preferred embodiment.
FIG. 23 shows the basic Booch symbols employed in the object model descriptions within the preferred embodiment.
FIG. 24 shows that the communication external to an E-Metro Community are all done with RSA-type security and encryption.
FIG. 25 is the user interface to the preferred embodiment showing the initial screen.
FIG. 26 is the user interface to the preferred embodiment showing the log-in screen.
FIG. 27 is the user interface to the preferred embodiment showing the community listings screen.
FIG. 28 is the user interface to the preferred embodiment showing how E-Metro Community members construct and execute searches displaying search results.
FIG. 29 is the user interface to the preferred embodiment showing the initial page of an E-Metro Community registration object being authored.
FIG. 30 is the user interface to the preferred embodiment showing the selected E-Being performing a trusted presentation of their personal information, with certain components and their attributes indicating secured or locked status because the requesting viewer does not meet the requirements set by the E-Metro Community and E-Metro Community member.
FIG. 31 is the user interface to the preferred embodiment presenting additional personal information indicating attributes with disclosed and undisclosed access-processing rules.
FIG. 32 is the user interface to the preferred embodiment presenting rule authoring and assignment of rules to both particular personal information attributes and particular groups or sub-communities of a community.
FIG. 33 is the user interface to the preferred embodiment presenting rule authoring governing what criteria a processor of information must meet to access-process the user's information.
FIG. 34 details the E-Bazaar E-Broker subsystem.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiment of the invention primarily operates on a network server, with supporting applications operating on the individual's personal computer system. To a user, the preferred embodiment appears as a Web site, so it may be accessed simply by knowing its Web site address, but it is a Web site with comprehensive security safeguards: firewalls, proxy servers, SSL enabled Web servers and clients, digital certificates, hardware tokens, security policies and procedures. Not only will the Web site typically require certificate-based identification for access, but all communications between E-Metro Communities and members and other E-Metro Communities will be encrypted. For additional assurance of user identification, an optional hardware token or secure card security system may be implemented. This security system will be discussed in a later section.
As discussed earlier, trusted processing of information has two components: reliability of content and controlled processing, and each is addressed by the preferred embodiment of the invention. It is easiest and most clear to discuss the preferred embodiment using a metropolis analogy. Just as in a city, the Internet provides an individual a place to meet others, share information, seek entertainment, do work, and shop. Likewise, every individual on the Internet has an address where correspondence may be sent. In the city, caution must be used when meeting someone for the first time as it may be unwise to give too much information to someone who is untrustworthy. Also, business transactions with a new person must be done carefully as the quality of goods, standard of support, or origin of the product is not known. These same concerns appear with new encounters and transactions on the Internet.
In the city, people use an unfamiliar person's associations to lower the risk of these new encounters and transactions. For example, if someone is wearing a police uniform, we will typically be more likely to give them our drivers license number, home address, and other personal information. If someone is seated in an attorney's office and hands us a business card with the title of "Attorney," we are more likely to expose confidential information. Also, if someone lives in our same community, maybe even our neighbor, we too will be more likely to share information and feel safe conducting a transaction. On the Internet, if a person has an address that ends in .gov, we may feel safer doing business with them, as some government agency has allowed them access to the Internet from a government network server, thus giving that user an air of trustworthiness. If that user conducts a bad transaction, the agency that allowed their access to the Internet can be contacted, and the agency is likely to sanction that user. However, the vast majority of users on the Internet will be from network servers that provide no hint as to their trustworthiness. Therefore, the preferred embodiment of the present invention provides a method to reduce the risk in new interactions, and increase the probability that the other user is who they say they are: the preferred embodiment creates agent-rule based trusted electronic communities.
In the city, citizens belong to several communities. Some communities are defined by geography, ethnic background, religion, alma mater, employment, or hobbies. Commonly, people get a great deal of self-identification and satisfaction from choosing the communities to which they belong. It is quite common for someone to refer to themselves as an employee of a company, as a member of a religion, or as an expert at a hobby. Belonging to a community is not only personally satisfying to the member, but allows the reputation of the E-Metro Community to lower the risk of dealing with any one of its members.
In the preferred embodiment, a user may join one or more E-Metro Communities. Each of these E-Metro Communities is independently operated by an administrator that sets admission requirements, authenticates membership, issues digital certificates, and sets the services available to members. The E-Metro Communities are actually implemented as Web sites on the Internet, but are special Web sites as they have a great deal of intelligence and utility. FIG. 2 diagrams a user's view of the Internet using the preferred embodiment. The user will be a member of one or more E-Metro Communities 11 and be aware there are several other E-Metro Communities 11 on the Internet. The user will use a Web Browser such as Netscape Navigator 15 running on their personal computer to access the Internet and attempt to become a member of one or more E-Metro Communities. When desiring to become a member of an E-Metro Community, it is possible to retrieve an unregistered or empty E-Being object from the E-Metro Community or from a public E-Being repository 13 that will need to be initialized with identity information and certified in order to become a member. An unregistered E-Being may be retrieved prior to visiting the E-Metro Community desired to be joined. Once a user is authorized to join an E-Metro Community, the user becomes a member of that E-Metro Community and can use the services the E-Metro Community administrator has provided. Services may include links to other E-Metro Communities, shopping, or access to information. Besides the standard Netscape Navigator 15, the member will also need some additional support programs at their local computer, the client subsystem 17. These client subsystem 17 support programs are processes that allow the Netscape Navigator to have specific functionality in support of specific E-Metro Communities. These programs will be provided as part of the preferred embodiment, but will be configurable by the E-Metro Community administrator or even the user to provide specific functionality. These programs could be created in any language, but Java is presently preferred. It should be a goal of each E-Metro Community, however, to not require additional software besides standards based browsers, as this maintains a much easier to support client software subsystem. Additionally, the member may desire to gain privilege or access to specific E-Metro Community services to which it does not have rights. The E-Metro Community may require further information to be filled out in forms that must be submitted for approval. These forms are stored in an E-Being repository 13, and can be set up as an independent Web site, an FTP site, or any other storage mechanism allowed on the Internet.
Remembering that trusted processing comprises reliability and controlled processing, in the preferred embodiment, trusted processing of personal data is improved by two means. First, the personal information that is processed is authored and monitored by the individual. The information can also be verified by third parties who issue digital certificates which corroborate the facts claimed by the individual. The information stored is transparent to the individual. Additionally, the users themselves can request trusted certificate authorities to verify and assert the reliability of the personal information. The Certificate Authorities issue digital certificates asserting the reliability of the data. An example would be a credit union, which will certify personal financial or loan data. As an E-Metro Community's reputation for reliability and user-centric control of personal information processing increases, the informational value and mutual trust of its users will also increase.
The other aspect of trusted processing, protection of data, is improved in two ways by the preferred embodiment of the present invention. First, the preferred embodiment uses state-of-the-art techniques, such as public-key cryptography, to securely store and transmit information. Public-key cryptography is discussed in more detail in a later section. These techniques assure that the data can not be deciphered if intercepted during transmission, and only the intended reader can decrypt and understand the information. The second security feature of the preferred embodiment is designed to place controls on the amount of information processed and to limit the utilization of data to recipients meeting criteria established by the user. This security feature allows the user to set rules that govern the processing and utilization of personal information. For example, one rule may state that it is acceptable to release legal history information to a user that is from the American Bar Association E-Metro Community. Another rule may state it is acceptable to utilize a home phone number by a user that is single, from a particular geographic area, and also agrees to have their home number utilized in a controlled manor. By setting sufficient rules, an individual can control the utilization of personal information by only trusted users. Additionally, the user may set transitive rules that attach to information that control electronic distributed processing of the information. Thus, when a user authorizes trusted remote processing of personal information, the information is utilized in a manner that allows the user to maintain command and control of how the information is subsequently utilized.
The preferred embodiment additionally allows an individual to set rules for processing personal information for money or other value. An individual's preferences, physical characteristics, and buying habits have value to those selling products. Traditionally, marketing firms would collect and organize such information and sell those mailing lists to businesses that had a product that may appeal to those on the list. Using the preferred embodiment, an individual can "license" their own personal information to a business directly or to a marketing firm, thus sharing in the value created by the trusted processing of reliable personal information.
Referring now to FIG. 25, an example of what a user may see when accessing an E-Metro Community Web site is shown. Here, the computer user is running Netscape Navigator on their personal computer, and the standard Netscape Navigator menu items 501 can be seen. To get to this point, the user had to tell the Netscape Navigator the address of the E-Metro Community Web site, and the Netscape Navigator, through the user's network server, connected to the remote network server where this E-Metro Community Web site is located. Once accessed, the E-Metro Community Web site sends this introductory screen 511 to the user, which contains a graphical logo 505 and title 503 specific to this E-Metro Community. The user can select one of three option buttons 507: get more information on this E-Metro Community, go to the services available in this E-Metro Community (will require a security check-in), or, if a new user, register for admission to this E-Metro Community. If the user selects to register, the registration objects will be supplied by the E-Metro Community or retrieved from a E-Being repository and the user will author their E-Being, similar to filling out a standardized form.
If the user selects the services option, the user will be asked for security information and/or hardware tokens. In FIG. 26, the E-Metro Community only asks for a certificate-based identification 523 and a security code or challenge response 515. Once the user selects "OK" 517, and the user is allowed into the E-Metro Community, the user can utilize the available services. In this example, the member is presented with the communities available screen 521 shown in FIG. 27, which is made of the graphical logo 505 and the community links 523. Services available in this E-Metro Community include search and selection, registration updates, advertising, shopping, customer support and other services selected by the E-Metro Community administrator. Search services provided in this E-Metro Community is the availability to perform parametric queries. FIG. 28 shows a partial view of the members who met a specific search request in this E-Metro Community, allowing the searching member to select particular E-PIAs by selecting a picture-link 527. Provided the requesting member has the proper qualifications as set by the interrogated member, the interrogated member's information can be seen by the requester.
The preferred embodiment is premised on a user's membership in at least one E-Metro Community, with the E-Metro Community defining the member's duties and rights. In the preferred embodiment, the E-Metro Community has three primary responsibilities. First, the E-Metro Community sets admission requirements that produces a high probability that the applicant for admission is who they say they are. Second, the E-Metro Community has security measures in place to reasonably assure that a member's identity can't be appropriated by someone else. Third, the E-Metro Community sets standards that place a high probability that the member is transacting business and disclosing accurately and in good faith.
The first responsibility for assuring the applicant is who they say they are is met in the preferred embodiment in a two step process. In the first step, an applicant, using the Netscape Navigator 15 accesses the Web site for the E-Metro Community 11 they wish to join. This user selects the registration object from an E-Being repository 13, fills it out and submits it to the E-Metro Community administrator. The E-Metro Community administrator reviews the application to assure that the applicant meets the E-Metro Community qualifications. If the applicant meets the qualifications, the application process moves to step two. In step two, the applicant/user appears in-person to the E-Metro Community administrator or another trusted authority or entity, such as a Certificate Authority or notary, to verify the user's identification. The applicant can present one or more pieces of identification, such as birth certificates, drivers' licenses, passport, social security card or other reliable means of identification. Once the applicant is personally identified and a key pair generated, they are issued a digital certificate binding the public key and both member and E-Metro Community information. A security code or challenge response access method is chosen and hardware token if requested. At a minimum the member will have a digital certificate and access method to fully use the selected and approved E-Metro Community services. The E-Metro Community is now reasonably assured that the person is who they say they are and has accounted for the processing of the registrant's application.
The second responsibility of the E-Metro Community is to assure that only the original applicant can use that member's identity. The digital certificate and security code or challenge response described above will assist in assuring the security of an individual's identity, but new technology allows for even greater security. For this advanced security, the E-Metro Community may issue the user a hardware token or secure-card, such as those sold commercially by Gemplus, Schlumberger, and Spyrus corporation. Although the LYNKS secure card from Spyrus has several options as to what information it can hold, three particularly useful items are 1) the basic information about the user, 2) a digital certificate, and 3) E-Metro Community digital certificate digitally signed by the certifying E-Metro Community. The first item may contain several pieces of information, including passwords, security codes, and particular challenges or code phases that can be used by the preferred embodiment to verify the identity of the user. For this challenge security, the user loads the security card with challenge response pairs that only the user will know. When the user wants to access an E-Metro Community, the security card "challenges" the user by presenting a challenge phrase that must be answered precisely. The second item, the digital signature, is an advanced security mechanism that allows the sender to attach a digital signature to a document that gives an assurance that a specific document was actually originated by that sender. The digital signature will be discussed in more detail in a later section. Those skilled in the art will recognize other alternatives to assure on-going security of a user's identity such as biometrics. The third item possibly held in the card stores information on the authority that certified this particular member. This authority could be the government, an E-Metro Community administrator or surrogate, or a commercial business. The more accountable, diligent and exhaustive the security policy and procedures are of the certifying agency, the higher the assurance that the member is also trustworthy.
The third responsibility for the E-Metro Community is to assure that the member properly transacts business and discloses personal information accurately and in good faith. This is mostly a policing process for the E-Metro Community, where those who violate the interaction policies for ethical interaction are removed from the E-Metro Community. Stricter enforcement of the rules will lead to a better E-Metro Community reputation for trustworthiness and accuracy.
Once there is assurance of the member's identity, the next level of security is to assure that the member can communicate with the E-Metro Community without messages and information being intercepted and interpreted by unauthorized individuals. This security level has two main components. First, the preferred embodiment uses security protocols approved by Netscape for commerce transactions, including purchases made on the Internet with a credit card. Second, the Netscape Navigator web browser has built in cryptography techniques, called public-key cryptography, that can assure the communication from the member to the E-Metro Community is secure from outside interception and interpretation. The preferred embodiment uses the public-key cryptography techniques supplied by RSA Data Security, Inc, but those skilled in the art will recognize alternatives.
Public-key cryptography is one method currently known for secure transfer of information. A diagram on the operation of 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 called keys, so each user has a public key and a private key. The public key list 25 is widely distributed to anyone that may need to send the user information. However, the private key is kept secret by the user. For example, if "A" wants to securely send a file to a "B," A will encrypt the file using the Bs public key 19. This key is publicized and available to anyone who wants it. After encryption, the file 21 can be deciphered only by using Bs private key 23, which is known only to B. Thus, if B has properly secured the private key, only B will be able to receive and interpret the encrypted file. It doesn't matter if the file is sent via an unsecured transmission method such as the mail, Internet, or phone lines, since no one that intercepts the message can interpret it, unless they have somehow appropriated Bs private key 23.
A second security mechanism is the previously introduced digital signature, and assures the receiver that the message was actually sent by the stated sender. As briefly discussed above, a member can use a digital signature to "sign" files so to give a high degree of assurance that it was the owner of the signature that sent the message. FIG. 4 will assist in explaining the use of the digital signature. To add a digital signature to a file, the member passes the file 27 through a mathematical formula 31 that produces a digital pattern, or message digest 33, that is unique to that file. This message digest 33 is then encrypted using the members private key 23 as discussed above, creating the digital signature 29. This digital signature, then, can tie a particular file to a particular owner of a private key. The member then attaches the digital signature 29 to the file 27 and sends both to the receiver. In this example, the file 27 is sent unencrypted, but if the file must be securely sent, the member can use the method describe in the previous paragraph to encrypt the file with the receivers public key. When the file and signature are received, the receiver deciphers the digital signature 29 using the senders public key 19, revealing the digital pattern 33 unique to the file 27. The public key, as before, is available from a published public key list 25. If the digital signature 29 was made using any other user's private key, the resulting pattern will not match the file, and the receiver will know the file was not sent by the named sender. Using this digital signature technique, the preferred embodiment can place a high assurance that a particular file was sent by a specific member.
Using the techniques described above, there is a high level of assurance that information and business transactions will be made securely and accurately. However, security is only one part of a successful Internet interaction. Presently, interaction on the Internet is an impersonal and often random experience. A common critique of using the Internet is that interacting on-line doesn't allow us to locate, understand and know with assurance the person behind the e-mail ID or message--to hear the voice, to see the face, to know a little about the senders personality, characteristics, and trustworthiness. Without these, the interaction is not only personally unsatisfying, but frustrating and useless.
Virtual communities are forming but people have little assertive control over their digital persona or interactions and much of the rationale behind these virtual communities is data gathering. This data gathering is performed by commercial entities seeking to track consumers, performing continuous and subtle surveillance of community members. Overwhelmingly consumers want control of their personal information and are demanding change as a backlash is mounting seeking legislation to circumvent this unbridled gathering, trafficking and processing of personal information. The present invention creates a trusted virtual community enforcing informational privacy and informational self-determination, wherein people can individually and corporately demand value in exchange for accessing and processing personal information controlling the many attributes which make up their informational existence.
A digital persona or Internet personality is determined by the personal information available for an individual. The more complete and reliable the information, the more accurately the Internet personality will reflect the real-life personality. This personal information is valuable not only to accurately define an on-line presence, but, as discussed earlier, has commercial value to others. Personal information may take many forms, including health, financial and legal records, school transcripts, employment history, or buying preferences. Each of these pieces of information, if accurate, is an asset that can make interacting on the Internet more effectual and enjoyable. In the preferred embodiment, these information assets are compiled and made available to others according to the desires of the individual E-Metro member. All the personal information, taken as a whole, makes up the electronic presence or digital persona of an individual. For purposes of clarity and ease of explanation, it is useful to think of this electronic presence in a Web site E-Metro Community as an electronic personal information agent or E-PIA, as introduced earlier.
Some of the informational assets of an E-PIA are created and held by others, but can be dispatched or processed in accordance with the rules embedded in the E-PIA, such as medical records and school transcripts. Other assets are those that can be authored by E-Metro Community members. The preferred embodiment allows a member to self-assure or collaboratively assure the information encapsulated within the E-PIA is accurate and reliable.
In FIG. 29 a user has accessed an E-Metro Community Web site using Netscape Navigator and is displaying the initial registration application 21. The standard Netscape interface 25 is near the top of the figure. Specifically, the user interface includes a menu bar 25, control buttons 27, quick access tree structure 37, and a communication activity indicator 31. Additionally, the key graphic 33 near the bottom of FIG. 29 tells us that security is in operation, so all communications with the E-Metro Community Web site are encrypted.
The registrant can navigate to other data subject areas (professional, financial, medical) within the notebook shown in the left most scrollable window. If the user selects the professional data area 37, the user will see the professional profile and begin data entry or update the information.
FIG. 30 is a dispatched E-PIA, which is displaying a portion of the personal profile. In FIG. 31 which is the continuation of Dieter's E-PIA the Home Address is not displayed and a closed lock icon accompanies the data attribute to the right. This indicates the person requesting to access this information did not meet his rules for access-processing and Dieter is unwilling to disclose what the rule is governing access-processing. When Dieter completed this personal profile, he authored rules FIG. 32 that determine who gets access to each item of information. The user accessing this personal profile does not satisfy these rules, so Home Address and other information is not available. In the preferred embodiment, if access to information is denied, there may be opportunity to see what the rule is and respond as indicated by the open key icon to the right of Home Phone, FIG. 31.
In this example Dieter has several options for rule processing depending upon Dieter's anticipation of rule interactions and the level of hands-on control he'd like to maintain or entrust to the E-PIA. Dieter may simply wish this requesting user to provide, in exchange, their Home Phone number and so a simple rule interaction will begin. Either processing of this rule will be done at the requesting client site confirming rule satisfaction or the messaging system will be activated with a message sent back to Dieter's Home E-PIA requesting his Home Phone be provided or a signal to his dispatched E-PIA be sent authorizing decryption and display of the encapsulated Home Phone data.
An automated rule-based response can be executed on the client-side given rule interactions are pre-defined and can continue the user-agent dialog or delayed interactions supported by the messaging system will continue the rule interactions. Dieter's Home E-PIA may already have a response established by a rule which says if your show me yours I'll show you mine and so the message response is semi-automatic.
In the case where Dieter has already defined a rule for processing his Home Phone data at the requesting client site the interaction is carried out and triggers a client-side message to Dieter's E-PIA. So, within the requesting user's E-Metro client-side application Dieter's dispatched E-PIA receives a signal to decrypt his Home Phone number for controlled access. The rule interaction Broker within the E-Metro client-side application checks to see if the Home Phone has been properly provided.
In the above case the E-Metro Community E-Broker has dispatched an already loaded E-PIA with encrypted data encapsulated which will save the messaging sending, rule-processing, and hands-on response some overhead by processing the rule right at the client-side. Dieter will decide how trusting he wishes to be in that he can rely upon the system to fetch data in return prior to releasing his data over E-Metro's virtual private network or have the data and rules dispatched within this E-PIA for processing right at the client station.
Rule response dialog boxes display rules and give the requesting person the option to respond. The rule may specify a financial transaction to occur. In this case the user authorizes a debit from their E-Metro wallet for the amount required by the rule.
Rule specifications are authored in FIG. 32. The figure depicts a dialog screen wherein Dieter navigates on the left his PIA's data attributes 545, specifying what kind of rules will govern that attribute or group of attributes. Access groups are a means to group rules by particular communities or sub-communities 540. Initial Contacts is a group Dieter has specified as a sub-community in which his Age attribute rule is not disclosed and this attribute in locked 550 i.e. not revealed in an initial contact scenario.
His other attributes: City, Date of Birth etc. are open and will be displayed upon processing. With this screen Dieter can create a "Need To Know" Prompting where in the requesting user is prompted for a need to know. Dieter will have to process this response himself via E-Metro's messaging system. Some message interactions will be automated by pre-built rule responses such as "I'll Show You Mine If You Show Me Yours rules." So Dieter's Home E-PIA can react to rule messages automatically.
Some data attributes will have Time Requirements in that the E-PIA will only allow so much time to pass for viewing or processing the E-PIA's data. A case in point is that Dieter will only allow 24 hours to pass and then his E-PIA locks itself up (encrypts) in order to prevent further processing.
As shown in FIG. 33 the sub-community Initial Contacts 555 must meet the above rules 565 and 560 in order to process Dieter's E-PIA. So Dieter is specifying the criteria other persons must meet prior to processing his E-PIA.
So community members will send queries to the E-Metro for processing and although a query may have several matches the decision to dispatch the E-PIA which meets the query requirements may not be sent due to the fact the requesting person may not meet the person's rule requirements. In the prior case Dieter's E-PIA was dispatched as the person requesting his E-PIA met the above criteria.
As shown in FIG. 2, the E-Being repository 13 may be anywhere on the Internet, that is, it may be on the same server where the E-Metro Community resides, or the E-Metro Community may use a E-Being repository residing somewhere else on the Internet. When a member joins an E-Metro Community, one of the first tasks will be to author, according to the users discretion, the personal profiles. These profiles, plus any information from outside sources, comprise the E-PIA representing an individual on the Internet.
A user can belong to several E-Metro Communities in the preferred embodiment. The user must, however, select one of the E-Metro Communities to be the home E-Metro Community. The selected E-Metro Community houses an E-PIA designated to be the "Home E-PIA" which keeps track of all the other E-Communities where the member resides. In this way, a change in the home E-PIA can be used to update the information in all the other E-Communities, if necessary. Once a member has joined an E-Metro Community and designated the E-Metro Community as its home, the member can join another E-Metro Community by simply meeting the admission requirements for the next E-Metro Community and then copying the E-PIA to the new E-Metro Community. As will be discussed in a later section, when a member desires to create a special E-PIA, called an E-AutoPIA, that is capable of moving to other E-Metro Communities and perform requested tasks, the E-AutoPIA can only be spawned from the home E-PIA. The E-AutoPIA, then, has a subset of the information contained in the parent home being, thus assuring anyone encountering the E-AutoPIA that the information it carries is related to a home E-PIA.
A member defines rules for the access-processing of their personal information to assure the information is processed appropriately. When a user tries to access the personal information of a member, the preferred embodiment checks to see if the user meets the requirements for trusted processing of the information. The preferred embodiment only dispatches an E-PIA to the requesting user containing information, which the user is authorized and qualified to process. These rules define the limitations on information processing and form the basis for interaction between E-PIAs in the E-Metro Communities. That is, when a member, represented by an E-PIA, contacts another member's E-PIA, the two E-PIAs can determine what, if any, information can be exchanged without any concurrent input from the represented humans. The specifics of this rule checking is described in a later section.
To this point the E-PIA in the E-Metro Community has been described as simply a storage repository for personal information with the ability to selectively release information according to rules, and acting only within one E-Metro Community. In the preferred embodiment, however, the E-PIA may also take the form of a more active entity, called an E-AutoPIA, capable of substantial unsupervised activity with other E-Metro Communities and E-PIAs in other E-Metro Communities on the Internet in general. The E-AutoPIA contains a subset of the personal information and rules of the full E-PIA, plus an itinerary that directs its activities. The itinerary tells the E-AutoPIA what E-Metro Communities to visit, what information to collect, and, in conjunction with the rules, what information may be processed. Using an itinerary, then, an E-AutoPIA will "move" about the Internet, visiting other E-Metro Communities where it can interact with the E-PIAs in each E-Metro Community.
In the preferred embodiment, the E-AutoPIA does not directly interact with other E-PIAs. Instead, each E-Metro Community has at least one process that acts as a brokering agent between an E-AutoPIA and the E-PIA members of the E-Metro Community. This brokering agent is the E-Broker presented earlier. When two E-PIAs or an E-PIA and an E-AutoPIA desire to interact, both present the E-Broker with their respective rules, and the E-Broker determines what, if any, information may be exchanged. Additionally, the E-Metro Community administrator may set minimum rules that apply to all the E-Broker mediated transactions to occur in that E-Metro Community, assuring that only transactions that meet minimum E-Metro Community standards will occur.
As alluded to, there are two modes of E-PIA Interaction. A user, electronically represented by his member E-PIA within an E-Metro Community, may invoke a single Interaction for an E-Metro Community via his Netscape Browser and the appropriate HTML document. This is known as Online Interaction Mode. When an E-AutoPIA invokes Interactions within an E-Metro Community, this is called Batch Interaction Mode.
FIG. 5 conceptually shows a Web site E-Metro Community 35 containing several E-PIAs (members) 37. For any interaction, the members 37 must use the services of an E-Broker 39. The E-AutoPIA 41 can operate external to the E-Metro Community, and as shown in FIG. 6, the E-AutoPIA 41 can have an itinerary that directs it to interact with the E-Brokers 39 in several other Web site E-Communities 35.
The E-Broker has three main functions within the E-Metro Community. First, the E-Broker has been defined by the E-Metro Community administrator to check the credentials of any E-PIA that wants to enter an E-Metro Community. In this policing role, the E-Broker checks certification, verifies identity, and inquires into the purpose of any approaching E-PIA. After applying the rules set by the E-Metro Community administrator, the E-Broker will either deny access to the E-PIA or allow it into the E-Metro Community. Second, the E-Broker acts to search for members that meet the criteria designated by an E-PIA during its request for interaction. For example, if an E-PIA enters an E-Metro Community to find members who are interested in purchasing a car, the request is given to the E-Broker. The E-Broker, using several subsystems available in the preferred embodiment, then searches all the members to find those that have expressed an interest in purchasing a car and creates a list of all members meeting the necessary criteria. Third, the E-Broker acts as an intermediary between the E-AutoPIA and the E-Metro Community E-PIAs. In the above example, even after the E-Broker has created the list of members that express an interest in purchasing a new car, the E-Broker still acts as a mediator. The E-AutoPIA presents its rules for collecting information, and each member E-PIA presents its rules for disclosure, and the E-Broker determines what information, if any, will be exchanged. Of course, even if the two beings agree to exchange information, the E-Metro Community administrator may have set a more stringent rule that will not allow the E-broker to finish the transaction.
One of the possible tasks that an E-Broker may negotiate is the controlled processing of a member's personal information. Provided both the E-Metro Community administrator and the user want to process personal information, the E-Broker can be instructed to collect money from a visiting E-PIA that wants personal information. In the preferred embodiment, the money collected may go to the E-Metro Community, the member, or split between them. An E-Metro Community with a substantial membership may find this an attractive way to finance other E-Metro Community services.
The E-Metro Community may provide several services to its members. Services may include intra-community functions such as collaboration groups, consensus building or voting systems, capital disbursement systems to manage the community revenues generated from services, on-line customer satisfaction databases to protect consumers promoting accountability and just resolution of customer complaints, or community subsidized provision of advanced wireless communicators to promote `equal access` policy objectives. The E-Metro Community may also provide extra-community services, such as access to cross-community mobilization efforts for philanthropic or political purposes, joint electronic commerce services, sharing of communication infrastructure costs to facilitate cross-community advanced or newly introduced wireless networks and technology for all community members.
A typical physical arrangement for the preferred embodiment is shown in FIG. 7 where a user 43 accesses the Internet 1 by using a personal computer 45 to connect to a network server 11, and the network server 11 makes the connection to the Internet 1. Both wire-line and wireless connections will be supported with where more than one E-Metro Community can reside on one network server 11, and E-Metro Communities may even form a hierarchical relationship. That is, an E-Metro Community may contain not only members, but may contain other sub-communities as well. FIG. 7 shows network servers 11 with one, two, or three E-Metro Communities on each server. Additionally, E-Being objects for authoring member information for the particular E-Metro Communities may be requested from the E-Metro Community E-Broker or, if made available publicly, in the E-Being repositories 13. The preferred embodiment allows any public storage subsystem for E-Being objects. Two possible storage subsystems are an FTP site or a Mail server which is simply a file storage and communication system holding assorted file types and is available off the shelf from Netscape or other vendors. These E-Being repositories may be on any server 11 or 13, or the E-Being objects may even be held by user at their personal computer 45 or a wireless Communicator device 42.
We now turn to the specific software implementation for the preferred embodiment. The preferred embodiment is a modularized application, that is, the application is divided into several parts, with each part, or module, assigned specific functions. Some of these modules are designed to operate on one or more network servers, while other modules are designed to operate on a user's local computer system. The user and server processes necessary to the preferred embodiment are shown in FIG. 8, and are associated with the physical devices shown in FIG. 7. Referring to both diagrams, the user 43, from their personal computer 45, runs the Netscape Navigator Web Browser 49, a commercially available application. The Netscape Navigator 49 allows the user to conveniently access any E-Metro Community Web site. Also, the Netscape Navigator provides compatibility with other Netscape products that bring specific tools to the preferred embodiment. Besides the Netscape Navigator, the user locally runs several utilities 55 in support of E-Metro Community activities. These specific applications may be DLLs (Dynamic Link Libraries), Java applications, applets and scripts, or some other code of a similar nature that supports specific E-Metro Community activities. As mentioned earlier, however, in almost all cases, additional subsystems and DLLs should not be necessary.
The heart of the preferred embodiment is the Web site E-Metro Community system 47, which operates on the network servers 11. A top level view of the Web site E-Metro Community system 47 architecture is shown in FIG. 9. The system comprises the Distributed Object Resource Management System (DORMS) 57, which is shown in more detail in FIG. 10, a Netscape Enterprise Server 59, the Netscape Application Programming Interface 67, a LivePayment payment card transaction processor 61, an FTP server 65, and an FTP client 63. Each of these system components will be individually discussed below, and then their interaction explained, but first the important consideration of security will be addressed.
Strict security is necessary in order to ensure that only intended communications and information dissemination occurs. Security can be divided generally into two categories: 1) security mechanisms to assure that eavesdroppers or accidental recipients cannot access information, and 2) security measures to assure that information is only released to a trusted entity. The first type of security is accomplished by using cryptographic techniques to transfer data between entities. Referring to FIG. 24, several Web site E-Metro Community systems 47 and a user accessing the preferred embodiment with the Netscape Browser are shown. Each Web site E-Metro Community system 47 is operating on a network server as a secure process. It is expected that anyone skilled in the art of process security can create a local secure process for each Web site E-Metro Community system 47. For inter-community communications, each Web site E-Metro Community system 47 maintains its own private key and public key for encryption use.
When a source E-Metro Community wants to communicate with another target E-Metro Community, such as when an E-PIA is transferred, a double encryption technique is employed. The source E-Metro Community encrypts the message using the public key of the target E-Metro Community. The source E-Metro Community then encrypts the now encrypted message again, but this time with its own private key. Each E-Metro Community is aware of all other E-Communities and their public keys. When the target E-Metro Community receives a message, it first decrypts the message with the public key of the source E-Metro Community and then it decrypts the message with its own private key. This "double" encryption assures the target E-Metro Community that the source E-Metro Community was indeed the source E-Metro Community mentioned in the message and also assures the source E-Metro Community that only the target E-Metro Community will be able to decrypt the message intended for it. Similar security measures are used for communications from an E-Metro Community 47 to a user.
Another important security aspect concerns assuring the source of an E-PIA or E-AutoPIA. This assurance of origin is shown through the use of a Certificate 150 and TrustedToken 159. Certificates are held by all E-PIAs and E-AutoPIAs, and contain the name of the person or entity represented and their associated public key. Since the personal information held by an E-PIA or E-AutoPIA has been encrypted by the private key of the person or entity represented, if the public key in the certificate matches the published public key, and the personal information correctly deciphers, then there is certainty that the E-PIA or E-AutoPIA originated from the stated source. The Certificate, then, is to assure that a being represents who they say they represent and the information was originally encrypted by that representative. The TrustedToken represents a necessary privilege to perform an Interaction, given by an E-Broker at E-PIA or E-AutoPIA authoring time. Each Interaction that needs to be secured will require that a TrustedToken be issued. Before an E-Broker will act on a requested Interaction, it will check to see that the requesting E-PIA has the necessary to assure that the E-Broker had granted privilege to perform the Interaction previously. Each TrustedToken will be associated with a specific Interaction and will be encrypted by the requesting E-PIA's private key. By using the requesting E-PIA's known public key, the TrustedToken can be decrypted and compared to the expected value, thus giving assurance that the ability to request the Interaction was actually granted specifically to the requesting E-PIA.
The second security mechanism assures that information is only released to trusted entities. When an E-PIA gives some of its personal information to another, the personal information given is still secured and owned by the original E-PIA, so subsequent dissemination can be controlled. The mechanisms concern initial release of information and subsequent dissemination by others. The initial release of information is controlled by having both the Web site E-Metro Community administrator and the individual set rules which must be met before information can be released. The E-Metro Community administrator can set rules that generally apply to all potential exchanges in the Web site E-Metro Community, allowing the E-Metro Community to maintain control on the types of acceptable transactions. Also, the individual can assign a rule to each piece of personal information in their E-PIA. By setting these rules, the E-PIA will only share information in a trusted environment with a trusted being. A more difficult issue relates to control over subsequent dissemination of information. In fact, if the receiver of the information, in turn, passes the information on to a third E-PIA, the preferred embodiment still retains knowledge of the original owner of the personal information and continues to police access to the information. This subsequent security is set by Transitive Privilege Rules declared by the original E-PIA. The transitive privilege rules create a transitive trust such that: If A trusts B with information X, and B trusts C with information X, then A trusts C with information X. This important concept assures to A that its information is never passed on to an entity which it does not trust according to the Transitive Privilege Rules it has declared for the data it has submitted. Information is always passed as a version of the E-PIA which submitted its information. For example, suppose an E-PIA contains a rich set of information which includes birth date, address, phone number, etc. Further, suppose it wishes to release only its phone number to another during an interaction. The receiving entity will actually receive an E-PIA object informational E-PIA, which contains only the phone number. More specifically, the E-PIA object received is a version of the original E-PIA which represents how the submitting E-PIA wishes to be perceived by the receiving entity. FIG. 6 depicts the collection of versions 40 of E-PIAs by a traveling E-AutoPIA. The versions of E-PIA objects is the only manner in which information is exchanged in the preferred embodiment.
The Distributed Object Resource Management System (DORMS) is central to the operation of the Web site E-Metro Community system 47. As shown in FIG. 9, the DORMS 57 handles several core activities for the system, including storing of E-Metro Communities, E-Brokers, and members, E-PIAs maintaining a directory of all E-Metro Communities on the Internet, holding auto beings, and handling the interaction between E-PIA and between E-PIAs and E-AutoPIAs. Each of these activities will be discussed below.
The activities of the DORMS 57 are implemented with a series of interrelated subsystems, as diagrammed in FIG. 10. The interaction processor 73 is the key subsystem for the DORMS 57, and is responsible for all external communication and most internal decisions. Once the interaction processor 73 decides on a particular course of action, the action is implemented by the use of an E-Broker process. There are several E-Brokers available to do specific, reoccurring tasks. The operation of the interaction processor is discussed in detail in a later section, but first the other DORMS functions and individual subsystems will be addressed.
The DORMS is responsible for the storage of the E-Metro Communities, E-Brokers, and E-PIAs. Although each of these items is quite different, they are all stored in a common structure within the Object Repository 75. The Object Repository 75 employs a simple object oriented interface over a relational database. The relational database can be any that operates on the network server, such as the popular Oracle Database system.
E-Metro Communities, E-Brokers, and E-PIAs are all objects in the preferred embodiment, with each instance of an E-Metro Community, E-Broker, or E-PIA assigned a unique Object Identifier, or OID 91. The characteristics are then stored with the OID 91 in the form shown in FIG. 11a. This figure shows the structure of each row of a table within a relational database. Referring to the figure, the OID 91 is in the first field. The next field, the CollectionOID 93 identifies if this object is included in any other object, allowing for the creation of relationships between objects. Using a common CollectionOID 93, for example, several E-Brokers, E-PIAs, or even other E-Communities can be associated with a single E-Metro Community. The CollectionOID 93, then, is the preferred embodiment's method for tracking the hierarchical relationships between E-Communities, and the method for tracking E-Broker and E-PIA assignment within a particular E-Metro Community. Following the CollectionOID 93 are several key fields 95 that contain selected information about the object. These fields are "keys" that may be used for search and selection criteria by the database program. In the preferred embodiment, six key fields 95 are allowed for each row in the database table. Of course, more or fewer keys could be used, or alternate search techniques are clear to those skilled in the art. The specific identity of the keys is left to the E-Metro Community administrator to assign, thus allowing E-Metro Community needs to direct the most effective fields for efficient searching. The last item in the row is the object itself, which is stored in BLOb (Binary Large Object) format. BLOb format is a standard database storage structure that allows a single field in a database to hold multiple pieces of discrete information and is unaffected by the content of each piece of information. Thus, the DORMS can search the key fields 95 in the object repository 75 to quickly select appropriate objects, then extract and view the objects themselves from the BLOb format, a much slower operation.
As stated above, E-Metro Communities, E-Brokers, and E-PIAs use this common row structure. Each, however, uses a slightly different naming convention. The convention used by the E-Metro Community is shown in FIG. 11b. Notice the CollectionOID 93 references a parent E-Metro Community by the ParentOID 99, if any. In this manner the preferred embodiment maintains the hierarchical structure for the E-Metro Communities. The only additional difference is that the first key field 95 is assigned to hold the name of the E-Metro Community. Since the database engine often will use the name of the E-Metro Community for searching, it is appropriate that the name be a dedicated key for all E-Metro Community objects.
The row structure for an E-Broker is shown in FIG. 11c. Just as with the E-Metro Community, the first key field 95 is a name, in this case it is the name of a specific E-Broker. However, the CollectionoID 93 field contains the OID of the E-Metro Community that "owns" this E-Broker, thus associating a particular E-Broker with a specific E-Metro Community using a CommunityOID 101. This association method allows an efficient method to know which E-Brokers are allowed to operate in an E-Metro Community. Additionally, this same association method is carried through with the row structure for the E-PIA, which is shown in FIG. 11d. In the E-PIA, the CollectionOID field contains the Metro CommunityOID 101, thus associating a particular E-PIA with a specific E-Metro Community. As can be seen in FIG. 11d, all six keys are undefined in the E-PIA row structure, allowing the E-Metro Community administrator the flexibility to define each field to meet specific E-Metro Community needs.
Referring again to FIG. 10, the DORMS 57 also maintains a current directory of all E-Communities on the Internet. This directory is maintained by a special E-Broker in the E-Metro Community called the Directory Broker 77, with every E-Metro Community having a Directory Broker 77. The Directory Broker 77 tracks all E-Communities on the Internet and their address. Additionally, the Directory Broker 77 holds information on all other E-Brokers in all other Internet E-Communities. Information held includes the E-Broker's name, rules, and other information the E-Metro Community administrator desires to keep about other Internet E-Brokers. To keep the directory information current, an E-Metro Community's Directory Broker 77 will periodically inquire to see if its E-Metro Community has added, deleted, or changed any E-Brokers or E-Communities, and if so, the directory E-Broker 77 will launch an E-AutoPIA. This E-AutoPIA will be sent to all other E-Communities to interact with their Directory Broker, updating each E-Metro Community with the changes. The frequency of this update will vary, but most likely a schedule of once-per-day updating will be sufficient to support accurate E-Metro Community interaction.
The DORMS 57 also contains a Messaging system 71 that allows the E-Metro Community to send an E-AutoPIA to another E-Metro Community. As can be seen from this figure, the DORMS 57 communicates with other remote E-Communities through the FTP client 63 and the FTP server 65. Although the FTP processes are shown connected directly with the Messaging subsystem 71, all actual communication is controlled by the interaction processor. A more detailed diagram of the Messaging Subsystem is shown in FIG. 12. As discussed earlier, the Messaging subsystem 71 uses the FTP protocol to conveniently send and receive messages from or to the Web site-based E-Communities. This Messaging subsystem is employed exclusively for transporting E-AutoPIAs from one E-Metro Community to another. When an E-AutoPIA is sent to another remote E-Metro Community, the interaction processor 73 first retrieves the address of the remote E-Metro Community using the directory E-Broker 77. The interaction processor 73 then bundles the E-AutoPIA with the remote address and forwards the bundle to the sender dispatcher 105. The sender dispatcher 105 places the message in the message queue 109 and notifies the FTP client 65 that a message (an auto-being bundled with an E-Metro Community address) is ready to be sent. At a convenient time, the FTP client 65 sends the message (the auto being bundled with the address) to the FTP server of the receiver E-Metro Community and subsequently erases the outgoing message for the message queue 109. For an in-coming E-AutoPIA, FTP server 63 accepts the message and places the message in the message queue 109. The receiver dispatcher 107 monitors the message queue 109, and when a new message is seen, it unbundles the message, revealing an E-AutoPIA. The receiver dispatcher 107 then notifies the interaction processor 73 that a new E-AutoPIA has arrived, and the interaction processor 73 determines what next to do with the E-AutoPIA. The incoming message in the message queue 109 is not deleted until the E-AutoPIA in that message has completed its tasks within the E-Metro Community and has left the E-Metro Community. Saving the incoming messages assures that the E-AutoPIA's assigned tasks will be completed, even if the DORMS server should shut down in error and lose the E-AutoPIA currently active in the network server. When the network server is restarted, the E-AutoPIA can be restarted from the original message and its tasks completed. The message queue 109 itself is a standard FTP file system which may comprising an incoming message file and an outgoing message file. It will be clear to those skilled in the art that other transfer methods may be substituted for the FTP process described above.
The Virtual interpreter 81 is a software subsystem that provides the ability to execute the script language and rules language of the preferred embodiment. The Virtual Interpreter 81 plays a major part in the use of the rules processor 79 and the Itinerary processor, both which are discussed in a following section.
The DORMS 57 contains a Rules processor 79, which is an important subsystem for ensuring that information is securely distributed. A member or the E-Metro Community administrator uses rules to set the limitations and controls on the distribution of personal information. The rules are actually a series of strings, written in the programming language chosen for the preferred embodiment, that defines the requirements under which information will be released. It is possible to make the rules as simple or as complex as needed. The E-Metro Community administrator may provide minimum rules that will apply to all transactions, and allow the member to adjust rules for their particular needs. Although the preferred embodiment uses an application to set rules, those skilled in the art will recognize several alternative methods for a user or administrator to input rules.
As discussed earlier, requests for a member's personal information may come from either of two sources: another E-PIA member or an E-AutoPIA via Online Interaction mode or Batch Interaction Mode, respectively. If an E-AutoPIA enters an E-Metro Community and requests a member's information, the interaction processor 73 will start an E-Broker process to handle the request. The process to handle such a request is detailed in a later section after all subsystems have been describe, but generally, the E-Broker takes the rules that define the E-AutoPIA's request criteria and sends them through the virtual interpreter 81 and into the rules processor 79. The rules processor 79 converts the request into a standard database query request, such as a standard SQL SELECT command, and runs the query to select E-PIAs from the object repository 75. The E-Broker then accesses each selected E-PIA's rules, sends then through the virtual interpreter 81, to the rules processor 79, and the rules processor 79 compares the requirements set by the member E-PIA to the characteristics of the E-AutoPIA, and if the requirements are met, the E-Broker sends the requested information from the E-PIA to the E-AutoPIA.
If another member of the same E-Metro Community requests information on another member, the process is similar, although much simpler. In this case the interaction processor 73 again starts an E-Broker process, and the E-Broker sends each E-PIAs' rules through the virtual interpreter and finally to the rules processor 79. The rules processor compares the rules for each member and determines what, if any, information may be disseminated.
As previewed earlier, an E-AutoPIA is instantiated from a user's E-PIA and includes an itinerary. The itinerary is a set of instructions that direct the activity of the E-AutoPIA. Thus, the E-AutoPIA acts as an agent for the user. The itinerary, like the rules, can be a program written in Java, or other convenient language chosen for the preferred embodiment. As with the rules, those skilled in the art will recognize several alternative methods to creating an itinerary to direct an E-AutoPIA.
The Virtual Image 85 is used to improve the performance of the preferred embodiment by placing selected information in local RAM (Random Access Memory) for quick access. Since the system can access information in RAM much faster than it can retrieve information from a data base located on a hard drive, such as the Object Repository 75, the system runs more efficiently. Once an E-Metro Community, E-Broker or E-PIA is needed by the preferred embodiment, an E-Broker selects the needed entity from the object repository 75 and places a copy of the entity in the virtual image 85. From then on, the system uses the copy in the virtual image 85 rather than the original in the object repository 75.
As can be understood from a previous discussion, E-Brokers are processes that execute on the network server and are used within an E-Metro Community to assist in the orderly and efficient functioning of that E-Metro Community. Each E-Metro Community has at least one E-Broker, but may have more. Two special E-Brokers exist in the preferred embodiment, but there may be more. The first one is the mandatory directory E-Broker 77 and was discussed earlier. The second one must be present in E-Communities that require secure modification access to the E-PIAs and is called the Home E-Broker 87. The home E-Broker is responsible for assuring that only the owner of an E-PIA has edit access to his home E-PIA. The home E-Broker may be set to require very strict security access, such as having the member use a secure card, passwords, and challenge system, or may be set up with weak security, such as just having the member supply a proper member identification name.
Each E-Broker is a custom built executable that runs in the Web site. Each E-Broker executable 76 implements a specific set of E-PIA interaction choices provided by the E-Metro Community it resides in. When an E-PIA requests a specific interaction, the Interaction Processor 73 invokes the E-Metro Community's E-Broker and tells it to attempt the requested interaction. In order for the Interaction Processor 73 to communicate with each E-Broker executable with a unified communication protocol, E-Broker Adaptors 74 are employed. Thus, the Interaction Processor 73 actually communicates with an E-Broker Adaptor 74 specially built for the E-Broker executable which, in turn, communicates with the E-Broker executable 76. Thus, the E-Broker Adaptor 74 acts as a "bridge" for communication between the Interaction Processor 73 and an E-Broker executable. This adaptor mechanism is necessary since E-Brokers constructed from C, C++, Java, Visual Basic, PowerBuilder, or other development environment may require different means for invocation and information transfer.
As a means to assist the construction of all necessary activities that an E-Broker executable may need to perform, the E-Broker Service API DLL is provided as part of the DORMS server subsystem. E-Brokers must be capable of calling APIs in a DLL to employ these helpful services. Some services that have been identified are: 1) input a set of rules and output a list of E-PIAs in the current E-Metro Community that satisfy the rules; 2) interact with the Transaction Server to perform credit card processing; 3) bill a credit card; 4) validate a Security Card that is entered on-line. It should be clear to those skilled in the art that other APIs may be added as needed.
Referring to FIG. 9 again, so far the DORMS 57, FTP client 63, and FTP server 65 portions of the Web site E-Metro Community System 47 have been discussed, with the LivePayment Server 61, Netscape Enterprise Server 59, and Netscape API 67 yet to be detailed.
The LivePayment Server 61 is a commercially available application from Netscape that handles payment card transaction processing, event logging, and settlement. The LivePayment Server 61 will be customized to handle E-Metro payment card transactions. Anytime a transaction by an E-Broker involves the transfer of money or value, the E-Broker sends the information to the Interaction Processor 73, and the Interaction Processor 73 forwards the data to the customized LivePayment Server 61. Additionally, when the customized LivePayment Server 61 needs to send information to an E-Broker, as for credit card approval notification, the customized LivePayment Server 61 sends the data to the Interaction Processor 73, and the customized LivePayment Server 61 forwards the information to the proper E-Broker. Individual E-Brokers and E-PIAs can define their own billing policies, allowing a member or the E-Metro Community administrator to collect fees for the release of information. As an example, the E-Metro Community administrator could set a charge of $1.00 per name and telephone number released, but an individual could add a requirement that they receive $0.25, too. This raises the cost to $1.25 if an E-AutoPIA wants to utilize that user's name and phone number. Since the customized LivePayment Server 61 is aware of all financial transactions in the E-Metro Community, it can easily create accurate billing and financial summaries.
The Netscape Enterprise Server 59 is also a part of the Web site E-Metro Community system 47. This server is a standard commercial offering from Netscape, and when run on a network server allows that network server to be a Web site, communicate over the Internet, and efficiently interact with the Netscape Navigator. The Netscape Navigator, as discussed earlier, operates on a user's personal computer and is a client to the Netscape Enterprise Server 59.
The standard Netscape Enterprise Server 59, while providing the basic tools for allowing a network server to be a Web site and gain access to the Internet, must be enhanced to provide the services and tools necessary to support the E-Communities of the preferred embodiment. The Netscape Enterprise Server 59 can be modified using the Netscape API 67 (Application Programming Interface). The Netscape API 67 is a set of commands that can be accessed from any program to perform modified Enterprise Server 59 functions. In the preferred embodiment, the Netscape API 67 is used to modify the standard security measures and method for responding to requests, for example.
Now that all the 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 created an E-AutoPIA to enter the example E-Metro Community to retrieve information on selected members of the E-Metro Community. Refer to FIGS. 7, 8, 9, 10, and 12 for the following procedure sequence. For convenience, the steps are organized into preliminary steps that will only be done once to initialize the E-Metro Community, and request handling steps that are repeated each time an E-AutoPIA requests E-Metro Community information.
Preliminary steps:
1. An E-Metro Community administrator loads the preferred embodiment on a network server 11. This administrator employs an E-Metro Community administration tool to install the E-Metro Community. The administrator also creates several E-Brokers for handling tasks such as requests from E-AutoPIAs or transacting financial business. The E-Brokers may be constructed by modifying an existing E-Broker or by writing a new E-Broker process in any programming environment that can be "adapted" with the E-Broker Adaptor mechanism. The administrator additionally defines what services (interactions) to make available to members and creates the screens to present the information to the members. The latter is done with the standard Netscape Enterprise Server 59 or any other tool that can create Web site pages. The administrator either creates or modifies existing admission forms and places the forms in a forms-object repository 13. The forms repository 13 can be on the same network server 11 as the E-Metro Community, or may be placed on any available remote network server 11. Finally, the E-Metro Community administrator brings the E-Metro Community on-line and begins announcing the presence of a new E-Metro Community. The E-Metro Community is now ready for members.
2. Internet users or members of other E-Communities become aware of the new E-Metro Community and access the E-Metro Community's Web site address to get more information. Using the Netscape Navigator 49 Browser on their personal computer 45 they join an E-Metro Community. They can access admission forms and submit the requested information. At this point, the administrator may manually check the admission forms for completeness and minimum E-Metro Community requirements, or more likely, the administrator will have an E-Broker automatically check the form for the minimum requirements and set an in-person appointment with the user if the forms are acceptable. Depending on other requirements set by the E-Metro Community Administrator, the user may then be notified to come down to the E-Metro Community administrator's office or some other trusted authority and present sufficient identification and records to convince the administrator that the user is who they say they are. If E-Metro Community requirements dictate that security measures be maintained, then the user may be issued passwords, a secure-card, or other security mechanism. If all is in order, the user will become a member of the E-Metro Community. If the member has chosen the E-Metro Community to be his/her Home E-Metro Community, they must input a complete personal and professional profile, including compiling records held by others, such as medical and legal records. When the E-Metro Community is not the member's Home E-Metro Community, only a subset of information needs to be submitted and should be directly derived from the new member's Home E-PIA wherever it may reside. Several other users may also become members of this E-Metro Community.
3. At this point there is a going-concern E-Metro Community with active members. Members can take advantage of E-Metro Community services, communicate with other members, or create an E-AutoPIA that can go out and browse other E-Communities. The member may also define the rules for releasing personal and professional information, including the ability to charge for such release, or even require that the other side release similar information. There is such flexibility because the member creates the rules by writing a program in a language compatible with the E-Metro Community. Forms are available in the forms repository 13 to assist in the creation of rules, and the E-Metro Community administrator may even provide a default set of rules that simply need to be modified. Also, the E-Metro Community administrator is likely to create a set of minimum rules that will apply to all transactions to assure that an E-AutoPIA meets certain minimum standards and all transactions within the E-Metro Community are conducted in a proper manner. These minimum rules that apply to everyone can be called the E-Metro Community rules.
Request Handling:
4. Suppose that at this point an E-AutoPIA arrives at the FTP server 65 from another E-Metro Community. The server places the message in the Message Queue 109 and subsequently the Receiver dispatcher 107 recognizes that a message was received. The receiver dispatcher 107 notifies the interaction processor 73 that an E-AutoPIA message is waiting in the message queue 109 and retrieves the message containing the E-AutoPIA, but does not erase the original copy from the message queue 109. The Interaction Processor will retrieve the message from the receiver dispatcher and unbundle the E-AutoPIA from the message. The interaction processor 73 then starts an E-Broker process to handle the interaction requested by the E-AutoPIA. Since the E-AutoPIA is encrypted, the E-AutoPIA must be decrypted using the public key of the source DORMS server and private key for the local DORMS server. If the E-AutoPIA was intended for this E-Metro Community, it will properly decipher. Each E-AutoPIA also contains a Certificate to assure that the owner of the E-AutoPIA actually initiated the sending of the E-AutoPIA, which was discussed in an earlier section.
While the E-AutoPIA is present in the E-Metro Community, the E-Broker places it in the virtual image 85 for easy access. The E-Broker then collects the rules from the E-AutoPIA, and using the virtual interpreter 81 and the rules processor 79 checks the rules against the E-Metro Community rules to see if this E-AutoPIA should be allowed to interact with members. If not, the E-Broker will send the E-AutoPIA to the sender dispatcher 105, and the sender dispatcher 105 will send the E-AutoPIA back to its Home E-Metro Community. However, if the E-AutoPIA satisfies the E-Metro Community rules, the E-AutoPIA will be allowed to interact with member E-PIAs. Additionally, the E-AutoPIA may be holding E-PIA data that is intended to be B Communicated or shared. If so, the transitive privilege rules of each E-PIA is checked in a similar manner, assuring that the E-PIA will only be shared if the transitive privilege rules taken from the original E-PIA are met.
5. If the transaction has progressed to this point, the E-AutoPIA has a high probability of originating from where it says it does, and the E-AutoPIA meets the general rules for further engagement. Now, the preferred embodiment begins to analyze each requested interaction. The E-AutoPIA sends its first request and a TrustedToken to the E-Broker, where the E-Broker verifies that the E-AutoPIA holds the TrustedToken for the specific requested interaction. If the TrustedToken passes this test, the request is retained and moves on to step six; if not, the request is discarded.
6. The E-Broker takes the request and again processes the rules for the E-AutoPIA with the rules processor 79, but this time to create a query into the object repository 75 to find E-PIAs that meet the criteria set by the E-AutoPIA. Once the rules processor 79 develops this search, a SQL query, the E-Broker process runs the query on the object repository 75 and places the selected E-PIAs in the virtual image 85.
7. The E-Broker now collects the rules from each E-PIA, sends the rules through the virtual interpreter 81 and to the rules processor 79. The rules processor 79 then compares the E-PIA's rules and characteristics, the E-AutoPIA's rules and characteristics, and the E-Metro Community's rules and reports to the E-Broker what, if any, information can be exchanged between the E-AutoPIA and the E-PIA. Once notified, the E-Broker then sequentially collects the necessary information, including any transitive privilege rules and billing information, from each E-PIA, and creates an informational-being. Each E-PIA contains the certificate from the original being, the selected personal information, and the transitive privilege rules. The informational beings are then passed to the collecting being. If any billing information is collected, or credit card authorization is needed, the E-Broker interacts with the LivePayment Server 61 to satisfy these needs. The above process is repeated for each selected E-PIA, or, if the E-AutoPIA has a rule that only allows a set number of interactions, until that number is met.
8. After collection of the information, the E-AutoPIA's tasks at this E-Metro Community are completed, so the E-Broker removes the selected E-PIAs from the virtual image 85. The E-Broker looks at the itinerary from the E-AutoPIA, and using the itinerary interpreter 83 and the virtual interpreter 81 determines the E-Metro Community where the E-AutoPIA should next be sent. The Interaction Processor contacts the directory E-Broker 77 to find the address associated with the next E-Metro Community, and the directory E-Broker 77 retrieves the address from the E-Metro Community directory in the object repository 75, and answers the address to the Interaction Processor. The Interaction Processor then bundles the E-AutoPIA and the address into a message. The Interaction Processor passes this message to the sender dispatcher 105, and the sender dispatcher 105 places the message in the message queue 109 and notifies the FTP client 65 that there is a message waiting to be sent. The FTP client 65 retrieves the message form the message queue 109 and sends the message. Since the E-AutoPIA has been sent out of the E-Metro Community, the sender dispatcher 105 now removes the original incoming message from the message queue 109. With the E-AutoPIA successfully handled, the Interaction Processor's current session ends.
Now that the interactions of all processes and objects in the preferred embodiment are understood, it is important to describe a specific and important example of an implementation of a type of E-Metro Community known as the "E-Bazaar." The focus of the example is the E-Broker implementation because it is an E-Broker that contains all of the machinery and maintains the behavior of an E-Metro Community. This E-Bazaar E-Broker maintains unique properties that are original to the extent that they are included in the claims of the invention.
E-Broker Example: The E-Bazaar
The E-Bazaar is a type of E-Metro Community that offers three useful commercial scenarios or case studies. While serving as an example E-Broker, the E-Bazaar E-Broker is also very complex. The three case studies are general privacy enabled commerce, semi real-time auction, and large quantity sales. In all three cases, the salient objects are E-PIAs acting as sellers, E-PIAs acting as buyers, and an E-Broker. Note that an E-PIA may also be an E-AutoPIA in this context. The E-Broker handles various public services and Interactions directly on behalf of the E-Bazaar, as well as mediate the Interactions between E-PIAs. An important purpose of the E-Broker is to validate that commercially interacting parties satisfy each others privilege rules for interacting. In the context of this document, the term trade shall be used to refer to a generic notion of either "buy" or "sell." Additionally, the term advertiser shall be used to refer to someone who publicizes a desire to trade. The term shopper shall be used to refer to someone who browses advertisements and who may eventually place an order to trade.
The privacy enabled commerce case provides a means for both buyers and sellers to:
advertise a desire to trade
actively place an order for a trade
fulfill an order for a trade.
When the trading interaction occurs, it is guaranteed to be performed securely and in privacy between buyer and seller according to all the privilege rules configured by both parties. The actual trade activity is what is privacy enabled.
The semi real-time auction case is the same as the privacy enabled commerce case except that a seller or buyer has decided to advertise an electronic auction. In this case, the goods or services are typically advertised along with the current bid so other potential bidders know what to beat. However, auctions may be performed with secret bid.
The large quantity of sales case is also the same as the privacy enabled commerce case except that a seller or buyer has decided that it won't trade unless it can trade a certain quantity of goods or services. Therefore, a placed order may not be fulfilled immediately.
It will be shown that the E-Bazaar is able to perform each of these three case studies with the identical framework in the invention, the subject of a later discussion. It will be shown that the primary distinguishing feature between each scenario is the manner in which an order for buying or selling is fulfilled.
E Bazaar Activity Model
An overview of E-Bazaar activities is best described by presenting the activities lifecycle of an E-Bazaar when employed in E-PIA Online Interaction mode. An enumeration of the Online mode activities in the lifecycle are listed below.
Refer to FIG. 201.
1. An Internet Client 303 (as E-PIA) interested in buying or selling a product interacts with the E-Bazaar E-Broker 301 by submitting all of the information about the product so that the E-Bazaar can make the information public to other buyers and sellers.
2. An Internet Client 303 (as E-PIA) browses the product and service offerings at the E-Bazaar.
3. ProductInfo 317 for a specific E-PIA advertiser's product can be obtained upon request.
4. An Internet Client 303 (as E-PIA) obtains the OrderForm 315 for a product it is interested in from the E-PIA advertising the product.
5. An Internet Client 303 (as E-PIA) fills out the OrderForm 315 and submits the filled out form to the E-PIA advertising the product.
6. The filled out form is processed by a process designated by the advertising E-PIA known as the OrderProcessor 319. The process may or may not complete the order immediately. The client E-PIA is either immediately notified of a fulfilled order or notified of an order which is in progress. Such an order is said to be fulfilled asynchronously at some later point in time.
7. For asynchronous order fulfillment, the client E-PIA is notified of a fulfilled order or otherwise when the client E-PIA requests order status later, or receives e-mail regarding status.
For E-AutoPIA Batch Interaction mode, the activities are identical except that the sequence of Interaction activities would be performed according to the E-AutoPIA's Itinerary. For an E-AutoPIA advertiser, the E-AutoPIA would submit product information to the E-Bazaar E-Broker as part of its Itinerary and typically proceed to another E-Metro Community. However, for an E-AutoPIA shopper, the Interaction sequence in the E-Bazaar would typically be quite different. Since E-AutoPIAs tend to automate Interactions, it would be most likely that it already has a copy of order forms it needs. It just needs to submit filled in order forms. Thus, the E-AutoPIA would avoid browsing and a request for an order form and simply place orders. For asynchronous fulfillment orders, the E-AutoPIA can check on status in its Itinerary later, or the person representing the E-AutoPIA can wait for Internet e-mail.
E-Bazaar E-Broker Administration Tool
The E-Bazaar Administration Tool primarily provides the following "birth" features:
1. The E-Bazaar Administration Tool is used to deploy an empty E-Metro Community representing the E-Bazaar in a WebServer containing the preferred embodiment.
2. The E-Bazaar Administration Tool is used to configure the empty E-Bazaar. |
