EP1008084A1 - Systeme et procede pour la recherche, l'exploitation et la publication protegees d'informations - Google Patents

Systeme et procede pour la recherche, l'exploitation et la publication protegees d'informations

Info

Publication number
EP1008084A1
EP1008084A1 EP98935494A EP98935494A EP1008084A1 EP 1008084 A1 EP1008084 A1 EP 1008084A1 EP 98935494 A EP98935494 A EP 98935494A EP 98935494 A EP98935494 A EP 98935494A EP 1008084 A1 EP1008084 A1 EP 1008084A1
Authority
EP
European Patent Office
Prior art keywords
facts
entity
fact
user
publication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP98935494A
Other languages
German (de)
English (en)
Inventor
Philippe J. M. Coueignoux
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/001,778 external-priority patent/US6092197A/en
Application filed by Individual filed Critical Individual
Publication of EP1008084A1 publication Critical patent/EP1008084A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the invention relates to a system and method of discovering and exploiting information such as private or confidential information from a user, while securing the information from unauthorized publication.
  • Consumer research has focused on discovering user information such as demographic, personal or identifying information and using this information to provide the user with products or services tailored to his geographic area, age, gender, nationality or preferences.
  • user information such as demographic, personal or identifying information and using this information to provide the user with products or services tailored to his geographic area, age, gender, nationality or preferences.
  • information can be obtained through the use of cash-registers, kiosks, telephones, televisions and computers. While information is often obtained for marketing purposes, such information is also useful for other purposes.
  • a system for obtaining demographic information is described in U.S. Patent No. 5,369,571 to Metts, in which a store clerk enters data relating to consumer socio-demographic characteristics while ringing consumer's purchases at a cash register.
  • U.S. Patent No. 5,237,157 to Kaplan discovery of marketing information relative to the tastes of music buyers is carried out while a user interacts with a music sampling kiosk in a music store.
  • U.S. Patent No. 5,515,098 to Carles marketing data previously obtained and recorded on a central database is used to target specific commercial messages to on-demand television subscribers.
  • the operation of a central database is a common characteristic of the above systems. Personalized interactions based on user-dependent data, if present, require a user to provide user information for this database as a condition to obtaining the benefit of any privileges provided thereby.
  • U.S. Patent No. 4,899,373 to Lee a system providing personalized, location- independent telephone services is disclosed, in which user-dependent data is transmitted from a credit card and temporarily stored on the local exchange that services the telephone picked up by the user.
  • U.S. Patent No. 5,552,586 to Kalman a memory card is used to store user data relative to the interactions of the user with a plurality of social agencies. While this system provides access codes to allow for the protection of confidential data against disclosure to an unauthorized agency, when access is granted to an authorized agency, user data is unprotected as data is recorded in the computer of this case worker.
  • Hypertext markup language HTML and Java applets can be used in a discovery phase to report their findings to a central database.
  • cookies and executable code for push technology can record user- dependent data locally to avoid repetitive data entry by the user.
  • Such processes can be thought of as a local extension of the central server, as typically they provide no privacy protection besides a possible declaration of intent to preserve information in confidence.
  • the proposal by Firefly, Inc. for an "Open Profiling Standard” (OPS) presents a framework for such "before disclosure” user control.
  • OPS Open Profiling Standard
  • the OPS describes how an entity may negotiate access to confidential information on a party for the sake of offering a personalized service to this party. While the OPS gives an excellent description of the disclosure process and allows for party-dependent data to be kept locally under the party's control, its spirit is still to trade disclosure for personalization. It would be advantageous to break this link so as to reduce the need for disclosure while potentially increasing its economic value.
  • the present invention is directed to a system and method for the disclosure and controlled publication of information.
  • the system and method requests disclosure of information and publishes such information only when consent for publication is affirmatively given.
  • the present invention is further directed to a system and method for the controlled publication of information.
  • stored information is published only when consent for publication exists.
  • the system includes a sender in communication with a transmission medium, comprising a processing module transmitting a request for publication of a fact over the transmission medium; an agent in communication with the transmission medium, receiving said request for the fact from the sender, and a user in communication with the agent over the transmission medium.
  • the agent requests that the user disclose facts, referred to herein as "private facts” and provide indicia relating to authorization for publication of the disclosed facts. Facts having indicia relating to positive authorization for publication are referred to herein as "public facts”.
  • the agent receives the facts and determines whether such facts are to be made available to the sender, referred to herein as "published”.
  • the agent can include a memory module storing a plurality of facts and the indicia of authorization for publication; a processing module in communication with the memory module for determining whether the indicia of authorization for the facts disclosed by a user permits publication of the facts to the sender, and providing the facts to the sender when said indicia of authorization permits publication of the facts, that is, when the facts are considered public facts.
  • the system is implemented using one or more rule engines, and a plurality of dialog classes that control the strategy of the interaction between the agent and the user such that the goals of the sender are carried out while the confidentiality of private facts disclosed by the user is maintained.
  • the rule engine can prompt the user to disclose private facts and provide indicia of authorization for publication of such facts to the sender.
  • the dialog classes further use the private and public facts associated with the user along with known facts about the sender, referred to herein as "inbound public facts", to determine the content of additional prompts provided to the user, as well as to make suggestions to the user.
  • the dialog classes can include a plurality of rules, each of which is accorded a priority to aid in the process of rule selection.
  • the rules can include pure rules and interactive rules that require interaction with the user for an action to be executed.
  • Each rule typically includes a condition and an action that is carried out when the condition is satisfied.
  • the sender provides to the agent a publishing request list representing the facts desired to be known by the sender in response to the sender's interaction strategy.
  • the publishing request list can comprise a plurality of name and value pairs, each pair representing a category of fact desired by a sender.
  • Private facts authorized for publication to the sender can be implemented in a hash table, which can include a fact and an authorization for publication, referred to herein as "permission status".
  • a plurality of interaction rules can be used to determine the action to be accorded to a sender's publishing request.
  • a pure rule can determine the action to be accorded to a sender's publishing request.
  • a user can be provided with a questionnaire asking for a plurality of private facts, which result in a score that, if authorized for publication, can be published to the sender in response to a publishing request.
  • the agent can receive a special request from the sender, such as, for example, a special product or price offering that should be made known to the user immediately because of its temporal nature.
  • the agent can receive a special request from the user, such as, for example, a request for cancellation of an authorization for publication.
  • a plurality of senders can share one or more agents and public facts.
  • an agent can serve a plurality of senders using a common set of public facts, private facts and dialog classes, as well as sender-specific sets of public facts, private facts and dialog classes.
  • the sender and the user can exist as automated processing units, both having rule engines operating on specific dialog classes to obtain facts about the other party, provide facts, and authorize for publication certain facts which can be made known to the other party.
  • a method of providing secure discovery and publication of facts about an entity comprises; receiving at an agent, a publishing request from a sender; prompting a user for disclosure of facts; requesting authorization for publication of the facts disclosed; and providing only those facts that include an authorization for publication to the sender.
  • a method of providing controlled publication of facts to an entity comprises; transmitting from a sender to an agent a publishing request; retrieving from storage a fact relating to the publishing request and information relating to an authorization for publication associated with the fact; determining whether the authorization for publication indicates a grant of authorization; and providing the fact to the sender when a grant of authorization exists.
  • FIG. 1 is a block diagram of the system according to one embodiment of the present invention for discovering, exploiting and publishing facts.
  • FIG. 2 is a block diagram illustrating the interface computer of Fig. 1.
  • FIG. 3 A illustrates the rules used in the discovery and publication of information according to one embodiment of the invention.
  • FIG. 3B illustrates the rules used in the discovery and publication of information according to another embodiment of the invention.
  • FIG. 4 is a flow chart describing a method of discovering and publishing facts according to one embodiment of the present invention.
  • FIG. 5 A is a flow chart illustrating rule selection in the discovery, exploitation, and publication process.
  • FIG. 5B is a flow chart illustrating rule selection in the discovery, exploitation, and publication process.
  • FIGS. 6 A, 6B and 6C illustrate rules used by the system according to one embodiment of the present invention for determining whether private facts are to be published.
  • FIGS. 7 A, 7B and 7C illustrate rules used by the system for external prompting of the discovery and exploitation process according to one embodiment of the present invention.
  • FIG. 8 illustrates rules for interpreting user-completed questionnaires according to another embodiment of the present invention.
  • FIG. 9 is a block diagram illustrating another embodiment of the invention in which resources are shared by a plurality of senders.
  • FIG. 10A is a block diagram illustrating an alternative embodiment of the system of the present invention in which the operations carried out by the sender and receiver are automated.
  • FIGS. 10B, IOC, 10D, 10E and 10F illustrate rules for carrying out the discovery and exploitation process according to the embodiment of Fig. 10A.
  • FIG. 11 A is a block diagram illustrating another embodiment of the system of the present invention in which the sender and receiver are automated.
  • FIG. 1 IB is a block diagram illustrating yet another embodiment of the system of the present invention in which the sender and receiver are automated.
  • FIG. 12 is a block diagram illustrating an example of a sender and receiver carrying out automated processing using the system of the present invention.
  • FIG. 1 shown is a block diagram of a system according to one embodiment of the present invention, for discovering, exploiting and publishing user information, hereinafter referred to as "facts".
  • the system of the present invention is described for purposes of illustration only, as being implemented on a software-programmable computer system using an object- oriented programming language such as Sun Java.
  • the software-programmable computer system is preferably disposed on a network, such as the Internet.
  • a network such as the Internet.
  • the present invention can be implemented in the context of other networks such as, for example, wide area networks WAN, local area networks LAN, intranets and on other computer systems known to hardware designers skilled in the art and using other computer languages known to software programmers skilled in the art.
  • a site desiring to acquire information about users is in communication with a distribution computer 2 and a memory module 1.
  • the sender 4 can be, for example, a site on the world wide web (WWW) representing a vendor.
  • WWW world wide web
  • the user 7 can be a person or entity that interacts with an interface computer 5 to communicate with the sender 4.
  • the memory module 1 associated with the sender 4 stores dialog classes created by or developed for the sender 4. Classes, in object oriented programming, refer to a collection of data and method declarations, and can be used to encode facts and business rules that apply problem-solving knowledge to facts.
  • dialog classes 1 can be programs that control the interaction between the sender 4 and the user 7, particularly executable programs that seek to obtain from the user 7, information that is of interest to sender 4.
  • the memory module 1 is in communication with a distribution computer 2 which transmits copies of the dialog classes to a distribution network 3. Typically, such a transmission from the memory module 1 occurs in response to a command from a sender 4.
  • the distribution computer 2 upon obtaining the dialog classes, transmits them to the distribution network 3 which can broadcast identical copies of the dialog classes to the memory module 1' via an interface computer 5.
  • the interface computer 5, as further described herein, can comprise, for example, a personal computer, a digital television, or a cable television digital interface that is local to the user 7. It is to be appreciated however, that in alternate embodiments of the present invention, the interface computer 5 need not be local, and can be disposed on a network that services a plurality of senders 4 and a plurality of users 7.
  • the sender 4 further is in communication with a transaction computer 11 and a transaction network 12.
  • the transaction computer 11 can comprise, for example, a remote server or a server at the sender's 4 internet site.
  • the transaction network 12 is in communication with the interface computer 5, thereby enabling the user 7 to interact with the sender 4 via the interface computer 5.
  • the transaction computer 11 further is in communication with a transaction information memory module 10 that stores transaction information, such as, for example, information provided by the user 7 and/or the sender 4, such as, comments, questions, purchase units, quantities and dates of delivery, prices and availability. The user 7 can therefore exchange with the transaction computer 11, transaction information.
  • the transaction information provided by the user 7 as described above may further include personal information about the user 7 as sought by the sender.
  • the distribution network 3 and the transaction network 12 can be implemented on the same logical and/or physical network, such as the Internet, a WAN or LAN, an intranet, or an EDI network.
  • the transaction network 12 is essentially a two-way network, that enables the user 7 and the sender 4 to exchange information.
  • the distribution network 3, as will be further described, can be a two-way network, that is, communication is typically carried out from the sender 4 to the interface computer 5, with signals transmitted from the interface computer 5 that request dialog classes, as further described herein.
  • the distribution network 3 can be a one-way network.
  • the distribution network 3 can include, for example, a distribution of CD-ROMs in which communication is carried out through direct mailing or stores.
  • the dialog classes stored in memory module 1 are transmitted over the distribution network 3 to the memory module 1 '.
  • the dialog classes are transmitted in response to a decision by the sender 4 to publish the dialog classes, that is, to make the dialog classes available to the user 7 in memory module 1 ' so that the user 7 can interact with the dialog classes on the interface computer 5.
  • the dialog classes can be provided in response to the decision by the sender 4 to publish the dialog classes, and a corresponding decision by the user 7 to receive the dialog classes.
  • the sender 4 can initiate transmission of the dialog classes to the memory module 1' and provide for additional updates of the dialog classes.
  • the interaction between the sender 4 and the user 7 is known in Internet jargon, as push-pull technology or simply push technology.
  • the interface computer 5 can locally execute the dialog classes stored in memory module 1'.
  • the dialog classes are programs that automate the logic of the sender 4 and control the strategy of the interaction between the sender 4 and the user 7.
  • the dialog classes can thus prompt the user 7 to provide information, such as personal, secret or confidential information, "private facts," and upon receiving such private facts, determine whether additional prompts should be provided to the user 7 to obtain additional private facts, and what the content of such additional prompts should be. Therefore, during the execution of the dialog classes, as further described, the user 7 can be asked to disclose certain private facts, such as, for example, date of birth, social security number, annual income, mother's maiden name, other family information, eye and hair color, and user-preferences.
  • Execution of the dialog classes enables the user 7 to authorize certain private facts to be made available and published as public facts.
  • Public facts are thus private facts made available to the sender 4 only in response to authorization by the user 7.
  • public facts can further comprise sender-related data such as, for example, service messages.
  • the interface computer 5 can therefore store, modify and retrieve private and public facts relative to the user 7 as well as public facts relative to the sender 4.
  • the interface computer 5 receives the dialog classes from memory module 1', executes the dialog classes and interacts with the user 7. Any information provided by the user 7 in response to such interactions is stored in the memory module 6 as private facts. These private facts remain in the memory module 6 and are copied as outbound public facts only in response to authorization by the user 7 for disclosure to the sender 4, as will be further described.
  • the outbound public facts are stored in memory module 8. As described above, system information or public facts previously provided by the user 7 to the sender 4, or simply provided by the sender 4, are stored in memory module 9 as inbound public facts, and are transmitted to the interface computer 5 to aid in allowing appropriately tailored prompts to be directed to the user 7.
  • a multitasking operating system 13 such as, for example, a Java virtual machine running on Microsoft Windows 95, controls the operation of the interface computer 5.
  • the operating system 13 runs the discovery and exploitation engine 14, hereinafter referred to as the "DEP" 14, which can transmit local copies of the dialog classes to the memory module 1 ' and execute local copies of the dialog classes stored in the memory module 1 '.
  • DEP discovery and exploitation engine 14
  • the DEP 14 is lmplemented as a rule engine operating with a knowledge base
  • the knowledge base comprises the dialog classes in memory module 1 ' and the public and private facts in memory modules 6, 8, 9
  • each specific fact in object-oriented programming is represented as an object which is an instance of the relevant generic fact class For example, looking at the object "sports practiced golf, note that "golf is a specific instance of the class "sports practiced”
  • the DEP 14 as a rule engine, thus interprets the dialog classes in the storage module 1' by determining which class is the most relevant to the fact objects held in the storage modules 6, 8 and 9
  • the DEP 14 then creates new objects or updates existing objects according to the user 7 responses obtained via a user interface 15
  • the DEP 14 thus creates, writes, updates, and reads the public facts held in memory module 8 and the private facts held in memory module 6
  • the DEP 14 further determines which private facts are to become outbound public facts, and stores such facts in memory module 8 so that they are available for further processing by both the DEP 14 and the external process 16 hereinafter referred to as the "EPR" 16
  • the EPR 16 communicates with the user 7 through the user interface 15, to enable the user 7 to communicate transaction information with the sender 4 over the transaction network 12
  • private facts cannot be accessed by a system element other than the DEP 14, and can be discovered by the DEP 14 during a single user-interaction session or during multiple user-interaction sessions
  • the inbound public facts in memory module 9 can further be read by the DEP 14 as transmitted to by the EPR 16
  • DEP 14 can, in other embodiments, be configured using other elements while retaining the functionality described herein in connection with a rule engine
  • the basic rule engine design described herein can be coupled with free form ancillary modules limited to the computation of some derived facts added to the list of private facts
  • the operating system 13 also runs the EPR 16, a rule engine that interacts with the sender 4 and the user 7 via the user interface 15
  • the EPR 16 can be a local agent of the sender 4, such as a local server or an applet
  • the EPR can simply be a local application programming interface (API) remotely accessible from the transaction computer 11 over the transaction network 12
  • API application programming interface
  • the EPR 16 allows the DEP 14 to interact with the transaction computer 11
  • the EPR 16 can access the outbound public facts in storage module 8 as generated by the DEP 14, and transmit such facts to the sender 4 over the transaction network 12.
  • the EPR 16 can receive inbound public facts from the transaction network 12, and store the inbound public facts in memory module 9, to be retrieved by the DEP 14.
  • the EPR 16 can be used to process independent commands received via the user interface 15.
  • the system can comprise a plurality of EPRs 16, each with its own set of inbound public facts. As further described in FIG. 9, where multiple senders 4 are disposed on a network and share the private and public facts, a plurality of EPRs 16 can be desirable.
  • the dialog classes stored in memory modules 1 and 1 ' generally comprise at least two types of rules known as pure rules 150 and interaction rules 152.
  • pure rules 150 and interaction rules 152 are characterized by a priority value, such as, for example, an integer from 1 to 11, given by R-p. It is to be appreciated that any method of assigning differing values to a plurality of rules can be used, as the priority value is simply a value that can be ranked against the priorities of other rules to determine the order in which the rules are selected.
  • Both the pure rules 150 and the interaction rules 152 further include a condition, given by R-c. A condition is a Boolean operation that results in an output that is either true or false.
  • Both types of rules are configured in accordance with the objectives of the sender 4 in determining when the user 7 should be prompted for facts, what strategy should be employed in prompting a user 7 for facts and what suggestions should be made to the user 7 on the basis of such facts.
  • Pure rules 150 further include a body, given by R-b, within which a conclusion, RR-c is found. Pure rules 150 incorporate the logic of the sender 4 using information already available to the DEP 14. That is, pure rules 150 are executed on the basis of existing private and public facts and do not rely on direct interaction with the user 7 for their execution. For example, a pure rule 150, can include a timer, and include the condition that if more than a month has passed without effective interactions with the user 7, the user 7 is no longer of interest to the sender 4.
  • the interaction rules 152 incorporate the logic of the sender 4 to prompt the user 7 for information, elicit and record private facts, such as, requests for orders or comments, or present information to the user 7.
  • an interaction rule 152 can propose to the user 7 that she order a toy truck. After an answer is given, the private facts derived from the answer can then be stored in memory module 6. As a further example, if a user 7 has expressed her interest in buying some products, an interaction rule 152 can present the user 7 with a request to disclose such a fact to the sender 4 or provide the user 7 with the necessary information to procure the goods independently of the system
  • Interaction rules 152 are similar to pure rules 150, with the exception that the body Rl-b of an interaction rule 152 is further divided into a display list, given by Rl-d, and an action, given by Rl-a A display list Rl-d defines the query presented to the user 7 through the user interface 15.
  • the action Rl-a is a function that is carried out after obtaining a response from the user 7 through the user interface 15
  • a response can include a final decision to proceed, such as yes, no, or time-out, as well as a list of data items
  • Data items can include orders, order requests, information and comments
  • An order is a contract between the user 7 and the sender 4, and because it requires mutual agreement, requires use of the transaction network 10 and the transaction computer 11 On the contrary, the order request is presented to the user 7 and can be elicited by the DEP 14 without requiring any knowledge by the sender 4 Transforming an order request into an order can be done with proper disclosure by the user 7
  • Another example of a data item can include a comment such as, "I'm done” or "Show me model xyz "
  • the action Rl-a of an interaction rule 152 explicitly defines a list of possible outcomes, indexed by the user decision, and for each outcome, can make changes to private and public facts based on the decision and the data items collected Examples
  • condition R-c again reflects the appropriateness of posing the question to the user 7
  • a typical condition will include a check as to whether the result of the question is not known and the action Rl-a for the question will include recording the answer to the question provided by the user 7 If the user 7 refused to answer explicitly, or implicitly via the time out 32, the action Rl-a for the question will include recording a "no answer" response
  • the DEP 14 commences execution of the dialog classes in main loop 36 hereinafter "ML" 36
  • the dialog classes 1' are executed in response to the start up sequence of the interface computer 5 or in response to an explicit request from the user 7 who desires to interact with a sender 4.
  • the DEP 14 then proceeds in step 18, to load existing data objects.
  • the data objects can include private facts previously discovered by the DEP 14, along with a version of previously disclosed private facts that are now considered public facts. Additionally, the data objects can include inbound public facts associated with the sender 4, as described above.
  • the DEP 14 further proceeds in step 19 to update the local copies 1 ' of the dialog classes 1 with copies of the dialog classes 1 transmitted over the distribution network 3.
  • the manner in which the update is implemented can depend upon the characteristics of the distribution network 3. Two-way networks such as the Internet allow the distribution to be on- demand and under the control of the DEP 14, whereas with one-way networks, such as a digital television broadcast, the interface computer 5 can be used to provide a buffer.
  • step 20 the DEP 14 enters an execution loop 36 by selecting the next rule to execute, if a next rule exists.
  • pure rules 150 and interaction rules 152 are characterized by a priority value, such as, for example, an integer from 1 to 1 1.
  • the priorities can be used by the DEP 14 to determine in step 20 which rule to select for initial processing.
  • the process of rule selection in step 20 can be performed by the DEP 14 in a variety of ways, as further described in Fig. 5.
  • the DEP 14 proceeds out of the ML 36, to step 21.
  • the DEP 14 stores updates for existing data objects representing the private and public facts. Control is then routed to step 22 where the DEP 14 terminates execution.
  • the DEP 14 determines whether the rule selected is an interpretation rule 152. Use of object-oriented language features such as the Java "overriding" feature can make step 23 implicit. If the rule selected in step 20 is a pure rule 150 RR, the DEP 14 executes the rule in step 24 and processes the conclusion RR-c of the rule. If it is an interaction rule 152 RI, the DEP 14 activates, in step 25, the display list Rl-d of the rule, which makes information available to a user interface processing loop 37, referred to as the "UIP" 37, as provided in step 38. The UIP 37 increases the reliability of the ML 36 by shielding the ML 36 from the user 7 and the user interface 15.
  • the UIP 37 is initially in a waiting period, in step 30, until information is made available in step 25 for display to the user 7 by the UIP 37 in step 31
  • the ULP 37 processes the interaction rules 152 in step 31, and provides prompts to the user 7 in a format that is acceptable for display 39 at the user interface 15
  • the ULP 37 then waits until either a set amount of time has elapsed, i.e., a time-out 32, or until the user data 40 comprising a user response and optionally, a plurality of data items, is received by the UIP 37 in step 33
  • the time-out parameter in step 32 is taken as an implicit decision by the user 7 to avoid responding and is encoded with a value of "0 "
  • a response provided by a user 7 can include selecting a preference from the display list, completing a form provided to survey sociodemographics, providing a yes or no response to a proposal to access the sender 4, or indicating authorization of a request by the sender 4 to publish private facts
  • User responses for a given interaction are typically indexed by strictly positive integers
  • the DEP 14 waits, in step 26, until the expiration of a predetermined time period, or alternatively, the DEP 14 waits, in step 27, until a response from the user 7 is received
  • the expiration of a predicted time period in step 26 is taken by the DEP 14 as an implicit decision by the user 7 to not respond to the display list, and a time-out parameter is encoded accordingly, and is given a value of "0"
  • the response is transferred from the UIP 37 to the DEP 14 in step 41
  • the DEP 14 Upon transfer of the response to the DEP 14, the DEP 14 calls, in step 29, the action Rl-a of the associated interaction rule 152 (or rules), to perform the action that results from the user 7 response
  • the action performed can be, for example, recording a data item associated with the response as a private fact in memory module 6 or setting a flag for prompting the user 7 with a an appropriate suggestion.
  • control is passed again to step 20, and the DEP 14 selects the next rule to execute
  • the UIP 37 will report a time out in step 32 Similarly if an error occurs between the user interface 15 and the ULP 37, or between the ULP 37 and the ML 36, the ML 36 will experience a time out in step 26 In both cases, a user response is reached lmp citly, as the lapse of time or a user response triggers an outcome for which an interaction rule 152 provides a conclusion Furthermore, upon reaching a time out in step 26, the ML 36 can check the continuing availability of the UIP 37 and restart the ULP 37 without losing any data, except possibly the user data for the interaction rule 152 where the error occurred In the event that a user response is received before the time out period has expired, the ULP 37 processes the user data in step 40 into a format acceptable by the ML 36 and reports it to the ML 36 in steps 35 and 41 The UIP 37 then returns to step 30 and enters into a waiting period until
  • the particular values of the time out periods given in steps 26 and 32 can be arrived at in a variety of ways, taking into consideration such variables as the amount of time the sender 4 wishes to allow the user 7 to respond, the typical response time of a user 7 generally, or the typical response time for answering certain questions
  • the value of time out for step 26 can be determined as a constant of the ML 36 and the value of time out in step 32 or can be a variable dependent on an interaction rule 152
  • the value of the time out for step 32 can be determined by the sender 4 and passed to the UIP 37 within the display information in step 38 It is preferred that the time out in step 26 be greater than the time out in step 32 with added processing time
  • the ML 36 allows at least the same amount of time that the ULP 37 allows for the user 7 to respond, such that the ML 36 does not ignore a response reached by the user 7 and accepted by the ULP 37
  • the UIP 37 can further display a "waiting" screen to alert the user 7 when no response is requested During such time, the ML
  • the DEP 14 has access to the private facts and the public facts throughout the execution of the ML 36
  • the creation and updating of public facts, I e , writing can be restricted in a number of ways
  • the ML 36 can write the outbound public facts only through a number of fixed rules, which, in the Java language, are referred to as "final classes " Final classes cannot be superseded by subsequent updating of dialog classes, such as the updating that occurs in step 19 when the DEP 14 receives from the operating system 13, the dialog classes from storage module 1
  • the number of such fixed rules can vary depending on the particular application
  • public facts that are considered inbound public facts are further restricted, and cannot be written by the DEP 14, but rather originate from the EPR 16 and the sender 4.
  • the DEP 14 can act as an engine that limits outgoing information to facts explicitly approved by the user 7 for publication or acknowledgment signals responsive to external events, such as special requests originating from the user 7 or the sender 4, as will be further described. Protection mechanisms of object-oriented languages, such as Java's "final”, “protected” and “private” attributes, and its "package” feature, can aid in preventing the unauthorized disclosure of private facts. These mechanisms separate the rule engine such as the DEP 14, together with a set of bundled rules from a sender-dependent rule set with restricted privileges.
  • Such protections can be used in conjunction with methods known to the expert in the art, such as encryption, to further prevent the unauthorized use of local recording of data objects including the private facts, the unauthorized listening of interactions with the user, and the unauthorized access to private facts due to implementation flaws in the protections provided by the languages used to encode the DEP 14 and UIP 37, and the OS 13, the user interface 15 and the distribution network 3.
  • the user interface 15 can be a browser such as Netscape Navigator and the DEP 14 can be implemented as a trusted Java applet.
  • a local Internet server can be associated with the interface computer 5 such that the DEP 14 is implemented as a stand-alone Java application running behind the server.
  • the user interface 15 can functionally be the combination of a local server and a browser.
  • the Internet can be used for the distribution network 3 only and the DEP 14 and the user interface 15 can be implemented as stand alone Java applications.
  • the system of the present invention can be implemented independently of the exact nature of the memory modules used to record the private and public facts.
  • a removable, portable medium such as a 3.5 floppy disk or a "smart card" can be used.
  • the user 7 can interact with the sender 4 or an agent for the sender 4 using any computer.
  • the DEP 14 can positively identify one representing the user 7.
  • the smart card can include part of the interface computer 5 functionality, such as, for example, the smart card can store and run the classes defining the DEP 14 to the exclusion of the UTP 37, reducing the steps 18 and 21 to trivial steps, while the computer 5 would run the UIP 37 and the external processes 16.
  • the DEP 14 initially sets the "current selection” to "none” and the "current priority” to "-1". By initializing the current selection in this manner, the DEP 14 can determine, based on priorities, whether other rules are available for selection, as in the present embodiment, the priorities of the rules can be integers between 0 and 11. The DEP 14 then checks, in step 52, whether there is another rule to select from, assuming all rules comprising the dialog classes are being held in an ordered list. If no other rule is available, that is, the selection has been completed, the DEP 14 checks, in step 53, if the "current selection" is a rule.
  • step 23 If the "current selection” is a rule, the DEP 14 selects it and proceeds to FIG. 4, step 23. If the "current selection” thus remains “none”, the DEP 14 proceeds to FIG. 4, step 21 and existing data objects are stored. If, in step 52, another rule is available, the DEP 14 sets in step 54, the "current rule” to it and proceeds to compute the priority R-p of this rule in step 55. The DEP 14 then compares in step 56, the computed priority R-p to the "current priority” to determine whether the "current rule” should be selected first for processing. If the computed priority R-p is not higher than the "current priority”, the DEP 14 loops back to step 52 and the DEP 14 determines if there is another rule to select from. Of course, upon initial processing through the loop, all rules will have a priority higher than -1, the initially set "current priority".
  • the DEP 14 checks, in step 57, the condition R-c of the "current rule", to determine whether the condition holds, that is, whether it can be satisfied, as given in step 58. For example, if the rule has a condition, such as, "the user enjoys reading,” the condition is satisfied if "user preference: reading” appears in the private facts currently held in the memory module 6. If reading does not appear in the list of private facts, then the condition cannot be satisfied, and is considered false. If the condition is true, the DEP 14 sets the "current selection" to the current rule and the "current priority” to the priority of the current rule in step 51.
  • the DEP 14 notes that this rule is the best candidate for execution because the rule's condition is satisfied and the rule has the highest priority of the rules encountered thus far.
  • the DEP 14 then loops back to step 52, and the entire process is repeated again to determine the priority and conditions of other rules compared to the "current selection" to determine the rule that should be selected for initial execution. If the condition is false however, the DEP 14 immediately loops back to step 52 to determine whether another rule is available to select.
  • script rules 151 include a body, given by R-b, within which a rule list, RS-1 is found. Script rules 151 can be used to structure the set of interaction and pure rules into small related subsets, as defined by their rule lists. In this manner, step 20 of Fig. 4 can process the related subsets rather than process the entire rule set at once. As further illustrated in Fig. 5B, step 52 of Fig. 5 A is shown now as step 552, which restricts the selection of a rule to the list of the current script rule 151.
  • Fig. 3B script rules 151 include a body, given by R-b, within which a rule list, RS-1 is found. Script rules 151 can be used to structure the set of interaction and pure rules into small related subsets, as defined by their rule lists. In this manner, step 20 of Fig. 4 can process the related subsets rather than process the entire rule set at once. As further illustrated in Fig. 5B, step 52 of Fig. 5 A is shown now as step 552, which restricts
  • 5B further includes the selection of the current script rule.
  • the rule list of a script rule 151 can contain other script rules 151 and that all rules belong to the list of some script rule to the exception of a unique hierarchical "top script rule”
  • steps 153 to 157 implement a stack-driven selection algorithm, which can be implemented with programming techniques available to those of ordinary skill in the art.
  • a publishing request list 60 representing the results desired by the sender 4 in response to the sender's interaction strategy.
  • the publishing request list 60 is created by the ML 36 during execution of the dialog classes, and can comprise an auxiliary data structure having an ordered sequence of requests that comprise name 61 and value 62 pairs.
  • Each individual publishing request represents an attempt by the sender 4 to obtain a fact previously discovered about the user 7, that is, to obtain a publication of a private fact 6.
  • a publishing request list 60 can include, a request by a sender 4 that the user 7 disclose a hair color, where the sender 4 is a hair dye company conducting a market research, or a request to disclose a book preference sought by a book publisher.
  • a publishing request list can be created where name 61 can be "hair color” or “hair- coloring products,” whenever values 62, such as "brown” or “highlights” are discovered as a result of a user 7 disclosing a private fact.
  • the publishing request list 60 acts as a buffer between the dialog classes 1, 1 ' described above, that govern the discovery of private facts from the user 7, and the system's pure 150 and interaction rules 152 that control the granting of disclosure, that is, the publication of the private facts as public facts to the sender 4.
  • Private facts can be designated as outbound public facts that are available to the sender 4 generally only when the user 7 so authorizes.
  • These private facts are implemented, for example, as a hash table 63.
  • each private fact is cataloged by the name of the fact 64, referred to as the 'key' of the hash algorithm, and parameters 68 of the hash algorithm.
  • the parameters 68 comprise a permission status 65, which can take the values of "authorized", “denied” or "system". In the present embodiment, authorization to publish cannot be obtained without an explicitly positive, informed decision by the user 7.
  • the parameters 68 further include the date of last access 66, that is, the date that the user 7 last decided whether to publish the private fact 6, and a value 67, that is, the content of the private fact 6.
  • the name can be "hair color”
  • the permission status can be "authorized”
  • the date of last access of the publication request by the DEP 14 can be "1/1/97 at 2 p.m.”
  • the value can be "brown.”
  • the outbound public fact 8 is shown by the hash table 63 as a private fact that was previously discovered and made available for publication to the sender 4.
  • FIG. 6B One of the fixed rules determining the action to be accorded to a sender's 4 publishing request is shown in FIG. 6B.
  • the rule described in this embodiment can be when a publication of a private fact is requested for the first time.
  • this rule has a priority R-p 200 of integer 11, which, in the present embodiment is one higher than the priorities given to other rules, which typically have a maximum priority of 10.
  • the condition 202 R-c requires that the publishing request list 60 is not empty, that is, the sender 4 is requesting disclosure and publication by the user 7.
  • An additional condition is that the name 61 of the first element of the list 60 is not listed in the hash table 63, that is, an attempt to publish the private fact 6 has never been made.
  • This rule is an interaction rule 152 whose display list Rl-d 204 comprises a fixed screen layout asking for permission to publish this fact by referencing the name 61 and the value 62 of the element.
  • the name 61 can be "hair color” and the value 62 can be "brown.”
  • a publishing request provided on a display list can ask: “Do you want to disclose that "your hair color” is “brown”?"
  • a “no” answer would mean that the user 7 does not want the sender 4 to know her hair color and that hair color is to remain a private fact 6.
  • a “yes” answer means that the hair color will now be a public fact 8, as well as a private fact 6.
  • the action Rl-a 206 thus accepts three decisions as an outcome: "time out”, "no” and "yes".
  • the action Rl-a 206 further creates a new entry in the hash table 63 with the name 64 equal to the name 61 in the publishing request list 60 and the date of last access 66 equal to the current date as given by the interface computer 5.
  • the action Rl-a 206 fills in the permission status 65 with "denied”, while in the case of "yes", the action Rl-a fills in the permission status 65 with "authorized” and sets the value 67 in the outbound public facts table 63 as equal to the value 62 of the publishing request list.
  • the action Rl-a 206 a further removes the first element of the request list 60 such that the next request can be processed.
  • FIG. 6C another interaction rule that can be used to carry out a publishing request is shown.
  • This rule can be used when a request to publish a private fact has previously been denied, but the sender 4 still wishes to obtain knowledge of this private fact.
  • This rule has a priority R-p 208 of 11, which again, is one higher than other rule priorities.
  • the condition R-c 210 associated with this rule requires that the publishing request list 60 is not empty, that is, the publishing request list comprises a public fact 8 to be updated, and the name 61 of the first element in the list 60 is listed as the name 64 in an entry in the hash table 63, that is, some attempt to publish it has already been made and the permission status 65 corresponding to the name 64 is equal to "denied," that is, the attempt was unsuccessful.
  • Its display list Rl-d 212 is provided to the user 7 and seeks to overturn a prior refusal to publish a certain fact.
  • Two parameters are provided to the user 7, that is, the name 61 and the value 62 of the first element of the list 60.
  • a third parameter can be the date of last access 66, which is the date of last refusal.
  • its action Rl-a 214 accepts three decisions as an outcome: "time out", "no" and "yes”. The action Rl-a 214 thus updates the entry in the hash table 63 with the name 64 equal to the name 61 by setting the date of last access 66 equal to the current date as given by the interface computer 5.
  • action Rl-a 214 is nothing, while in the case of "yes”, the action Rl-a 214 is to fill in the permission status 65 with "authorized” and set the value 67 equal to the value 62 as described above. Finally, the action RI- a 214 removes the first element of the list 60 so that the DEP 14 can process the next request.
  • this rule is a pure rule 150, that is, the request is automatically fulfilled without requiring user authorization.
  • authorization is not required because the fact has previously been published by the user 7, and execution of this rule simply fulfills the publishing request by providing the most recent value of the public fact 8 to the sender 4.
  • the condition R-c 218 associated with this rule requires that the publishing request list 60 comprise a public fact 8 to be updated, and that the name 61 of the first element of the list 60 is listed as the name 64 in an entry in the hash table 63 As described above, this signifies that some attempt to publish it has already been made Additionally, the permission status 65 corresponding to the name 64 must be equal to "authorized," that is, the user 7 previously authorized disclosure of the public fact to a sender 4
  • the conclusion RR-c 220 associated with this rule updates the entry in the hash table 63 with the name 64 equal to the name 61 in the publishing request list 60 by making the conclusion date of last access 66 equal to the current date of the interface computer 5 Then the conclusion RI-c 220 sets the value 67 equal to the value 62 in the publishing request list 60 Finally, the conclusion RI-c 220 removes the first element
  • rule-selection process As provided by the rule-selection process described in FIG 5, rules having high priorities are processed ahead of rules with lower priorities Each time a request to publish a private fact 6 is placed in the request list 60, the request is immediately examined using one the three rules described in FIG 6B, 6C and 6D Moreover, assuming the selection of one of the three rules in step 51, the rule cannot be surpassed by another rule in step 56 due to the high priority of 1 1 accorded to each of the three rules Additionally, where a rule has not yet been selected upon initial processing by the DEP 14, at least one of the above described three rules examined in step 57 satisfies step 58 In this step, a determination is made as to whether the rule holds, that is, whether the action or conclusion associated with the rule can be executed because the condition associated with the rule is satisfied If the rule holds, the rule is then selected m step 51, and the "current priority" is set to the priority of the rule
  • the EPR 16 determines the name 61 of the fact as it was placed in the publishing request list In this regard, the EPR 16 first determines whether the DEP 14 is running For example, if no rules are available for execution, the DEP 14 is inactive and the sender 4 cannot obtain publication of the fact 8 If the DEP 14 is running, the EPR 16 then determines whether the name 61 is present as the name 64 of an entry in the hash table 63 If a name 64 is present, the EPR 16 obtains the date of last access 66, which is the date that the entry was last updated by the DEP 14 and, if the permission status 65 is "authorized", the EPR 16 obtains the value 67 for the entry.
  • date of the last update may be a useful tool in providing context to time-sensitive facts. For example, if the user previously provided a public fact "I'll buy stock ABC" the sender 4 would want to know whether this public fact was last made available before or after a rise in stock price.
  • the names 61 and 64 can be best represented as a text string and the values 62 and 67 can be limited to simple data types, such as a number or a text string.
  • the values 62 and 67 can further be represented by more complex objects.
  • a sender 4 can use a complex object to encompass a number of private facts that are of interest to the sender 4.
  • the user interface 15 can provide in the display information 39, the inner content of the value 62, that is, the information within the object. For example, if the object is "address," the values obtained can include the street, the house number, the city, the state, and the postal code.
  • the UIP 37 can transform the value 62 from a complex object received within the display information 38 into a series of text strings in step 31.
  • Such algorithms are known to those of ordinary skill in the art as a common function of object oriented languages.
  • the EPR 16 can be granted permission to load and read existing data objects representing the outbound public facts into a hash table (not shown) similar in structure and purpose to the hash table 63.
  • the rules can take the current date from the distribution network 3 rather than the interface computer 5, as the distribution network 3 can often carry a more accurate current date and can deliver a date on demand.
  • the outbound public facts table 63 includes a copy 69 of the data objects including a name 64, date of last access 66 and a value 67. The copy 69 is made in the present embodiment only for those names 64 for which permission status 65 is not denied.
  • authorization cancellation can be implemented by a fourth pure rule with the DEP 14
  • a rule having a priority R-p 222 of 11 allows a user to cancel previously given authorizations to publish private facts
  • the condition R-c 224 associated with the rule can be that a time period has elapsed or that a special request has been set
  • a time period can be, for example, a month or a quarter of the year
  • the time period can be significantly shorter, such as, for example, a week
  • the expiration of the time period can be measured through the use of a clock or "chronometer" object which can access the current date with the desired accuracy and determine the amount of time that has elapsed since initialization of the date In this manner, regular checks can be made on a user's authorization to disclose a private fact 6
  • a special request can be, in the present embodiment, an affirmative step taken by the user 7 to initiate cancellation of previously given authorizations An affirmative step can be signaled for example
  • the value 67 that is the private fact, remains in the outbound public facts table 63, and thus is still available to the EPR 16 for publication to the sender 4 Although the value is available to the sender 4, publication of the current version of the fact is not breached, that is, as the value 67 is no longer guaranteed to be current
  • the EPR can be restricted to the copy 69 as described above
  • suggestions in the form of interaction rules 152 RI can be made to the user 7 based on private facts known to the DEP 14, and inbound public facts sent by the sender 4.
  • a suggestion is simply the exploitation of the discovery of private facts.
  • a suggestion uses existing private facts to prompt the user into entering into a transaction with the sender, either through the disclosure of a certain important public fact to be relayed by the EPR 16 for publication to the sender 4, or through independent channels such as provided by e-mail, telephone, mail, shops.
  • the display list Rl-d associated with the interaction rule Rl-a 152 is directed to the user 7 when the condition R-c is met.
  • the condition R-c of the interaction can be a compound statement including checks on past interaction history by reviewing the outbound public facts table, current circumstances known to the DEP 14 such as the date, time of the day, private facts and inbound public facts.
  • the priority R-p of the suggestion can vary according to the importance of the outcome, positive or negative, taken by the user 7.
  • a typical action Rl-a for the suggestion includes making entries into the publishing request list 60 to finalize disclosure and storing private facts associated with the user's reaction to the suggestion for future reference.
  • interaction rules 152 Before making suggestions, it is often necessary to execute additional interaction rules 152 that ask a series of preliminary questions. Such questions are embodied in interaction rules 152 RI presenting a display list Rl-d of one or more questions that are asked of the user 7 when a condition R-c is met. The questions thus allow for the discovery of private facts that can lead to suggestions. For example, suppose the dialog classes include the following interaction rules 152:
  • attribute A color of one's hair and is not known, ask about attribute A;
  • attribute B hair color products used and is not known, ask about attribute B.
  • attribute A is brown and if attribute B is Clairol® highlights, then suggest to the user that he buy sender's highlighting products for brown hair.
  • the priority R-p for the interaction rule again reflects the importance of asking this question, and the priority of such an interaction rule 152 can vary in response to learning additional private facts about the user 7.
  • the priority of a particular interaction rule can rise as the answer to the question embodied in the interaction rule becomes the last unknown fact discovered before an important suggestion can be made.
  • the priority of obtaining attribute B may rise, as the only condition left to satisfy before making the suggestion, is whether the user 7 uses Clairol® highlights.
  • the priority of obtaining attribute B could be lowered if attribute A is unknown.
  • a derivation is a subset of pure rules RR, whose conclusion RR-c expands on the knowledge that can be obtained from a condition RR-c. For example, if the user likes mountain biking and reading, put “Best Mountain Bike Trails in Switzerland” in a suggestion entitled "Reading Recommendation List".
  • the use of a derivation is typical of expert systems built on rule engines and is well known to the person expert in the art. It is a characteristic of this invention, earlier mentioned, that lengthy chains of derivations can be avoided when the user 7 is known to be present in front of the user interface 15. That is, pure rules 150 need not be processed to such an extent that interaction with the user 7 is absent for prolonged periods of time.
  • the user 7 can be represented by a plurality of users 7.
  • a rule can be configured to include an action that requests positive identification against a previously initialized private fact list asked each time a "time-out" occurs or after a given period of time has elapsed. The occurrence of a "time out” or the expiration of a period of time can be checked as part of the condition R-c of the interaction rule 152.
  • the rule executing such a question can be given a high priority relative to the remaining rules. More stringent security measures can be developed to ensure that one user 7 cannot publish another user's 7 private facts.
  • positive identification is requested only as a condition for making certain important questions or suggestions. In this manner, initialization is not needed and the positive identity of the plurality of the users 7 is itself discovered by asking questions and making some derivations to verify the answers obtained from the questions. For example, a typical question might ask for the first names of the members in the household, followed by a question on the specific role of the current user 7. Moreover, a key suggestion might not be put to the user 7 unless the user 7 has identified him or herself as a parent or a known adult.
  • the present invention provides both the sender 4 and the user 7 with a process to effectively exploit the user's 7 information and for the user 7 to maintain control over confidentiality.
  • the user's control is maintained because no information relating to the private facts can be published without the user 7 giving an informed consent.
  • consent to publication can be granted or denied at any time, per fact disclosed, or per number of facts disclosed, thereby enabling the user 7 to exhibit control over the disclosure and publication of private facts.
  • the sender 4 can control the interaction, through the dialog classes 1, 1 ', configured to implement the communication strategy of the sender 4 and having unrestricted access to a user's private facts.
  • the sender 4 can further use the dialog classes 1, 1 ' to query the user 7 for increasing levels of publication, settling for the highest level of publication with which the user 7 agrees.
  • each sender 4 can seek varying levels of publication from different users 7.
  • a sender 4 can, for example, pursue maximum publication until the sender has gathered in central memory 10 a statistical representation of the types of users 7 and their interests, thereby avoiding the need to obtain further disclosure and thus minimizing data warehouse expense.
  • the EPR 16 can be an optional component of the system or need only be used to convey special requests originating outside of the interaction between the DEP 14 and the user 7, as further described in FIG. 7A.
  • the outcome of the suggestions associated with the pure rules 150 and interaction rules 152 can therefore be limited to a potential future decision by the user 7 to interact with the sender 4 directly, rather than disclosure of public facts to the sender 4.
  • the EPR 16 can be configured with rules that further utilize the private facts listed as authorized in the outbound public facts table 63. For example, in one embodiment, the EPR 16 can find the appropriate entry in the outbound public facts table 63, and initiate a transaction with the sender 4 through the transaction network 12 with the transaction computer 11. The transaction can simply be the recording in the memory module 10 of the outbound public fact. It can also be a more complex transaction such as order placement, necessitating interaction with a user 7.
  • a special request is typically an event received by the EPR 16 that originates outside of the interactions between the DEP 14 and the user 7, such as, for example, a cancellation of previously given authorizations, as described above in FIG. 6E, or the notification of product specials by the sender 4.
  • Both the EPR 16 and the DEP 14 can be configured to recognize such events as instances of the same "special request" class.
  • the EPR 16 can receive a special request from a sender 4 via the transaction network 12, or from a user 7 via the user interface 15, and mediate between the originator of the special request and the DEP 14 to present the special request to the DEP 14.
  • a sender 4 can include an EPR 16 configured to communicate to the DEP 14, a plurality of differing sender-specific special requests.
  • a special request can result from the receipt of a request from a user 7 to cancel previously given authorizations.
  • a user 7 can initiate other special requests, such as, for example clicking on an icon indicating that the user 7 would like to place an order with a sender 4, or that the user 7 wishes to communicate directly with the sender 4.
  • a sender 4 can initiate a special request to make the user 7 aware of a special product offer, special times to purchase, or certain product features. Such a request is typically determined after the sender 4 learns some private facts about the user, that is, has received outbound public facts corresponding to the publishing request list 60, and in turn has determined that the user 7 is of interest to the sender 4.
  • a special request value 70 is initially reset, along with an inbound public fact SIG 71, and an outbound public fact ACK 72.
  • the inbound public fact SIG 71 represents a special request from the EPR 16 to the DEP 14.
  • the outbound public fact ACK 72 represents an acknowledgment of receipt of the inbound public fact SIG 71, and is sent by the DEP 14 back to the EPR 16.
  • the associated parameter 70 is used internally by the DEP 14 to avoid delaying its acknowledging the receipt until after its taking the request into consideration.
  • outbound public fact ACK 72 is initially reset and the permission status in the outbound public facts table 63 is initialized to "system” such that the DEP 14 is set up to transmit such an outbound public fact ACK 72 when appropriate Setting the permission status to "system” in the outbound public fact list reflects that this outbound public fact 72 is simply a message from the DEP 14, rather than a user-generated outbound public fact 8
  • two pure rules 74, 76 can be used by the DEP 14 to execute a special request typically sent by the user 7 or the sender 4 through the EPR 16
  • a pure rule 150 has a priority associated therewith, which can be an integer
  • the priority 228, 234 of the pure rules 74, 76 is not given, but it is to be appreciated that the priority can be computed according to the intent of the request, for example, a special request seeking cancellation of previously given authorizations can be accorded a priority of 11, while a special request from a sender 4 can be accorded a similarly elevated priority or a lower priority, depending on the urgency of the request, as further described
  • the first rule as described in FIG 7B allows a special request to be taken into consideration while acknowledging its receipt immediately As shown, it includes the condition R-c 230 that the inbound public fact SIG 71 is set and that the outbound public fact ACK 72 is reset As for a conclusion RR-c
  • the EPR 16 in response to the initiation of a special request, the EPR 16 first sets the inbound public fact SIG 71 in the memory 9.
  • the special request may be processed by the DEP 14 according to the dialog classes in memory module 1 '.
  • the execution of rule 74 is necessary for the DEP 14 to acknowledge the interruption, that is, to acknowledge receipt of the special request.
  • the EPR 16 can then reset the inbound public fact SIG 71 when the outbound public fact ACK 72 in memory 8 is set.
  • execution of rule 76 by the DEP 14 can restore initial conditions as it resets the outbound public fact ACK 72.
  • the creation and initialization of objects for the public SIG facts 71 and ACK 72 and the rules shown in FIG. 7B and 7C are part of a fixed "special request" class bundled with the EPR 16 and DEP 14.
  • the inbound SIG 71 is a signal that allows the EPR 16 to originate communication with the DEP 14.
  • the DEP 14 simply sends back an acknowledgment signal ACK 72 to indicate receipt of the special request. Thereafter, the DEP 14 processes the request, and the EPR 16 has no further involvement.
  • the outbound public fact ACK 72 cannot be used to secretly publish the private facts without the user's 7 consent, as the outbound public fact ACK 72 would only be sent in response to the inbound public fact SIG 71 comprising the special request.
  • a sender 4 can offer a product at a certain special price each month, and the user 7, when interacting with the DEP 14, can be prompted to determine the user's interest in the special.
  • Interaction rules 152 can therefore be configured with reference to an inbound public fact representing the product price of the month.
  • interaction rules 152 can include conditions such as if the user 7 is of interest to the sender 4, and a special, but temporal, product offer is available by the sender 4, then make such an offer to the user 7.
  • the EPR 16 can, at the beginning of a given month, trigger rule 74 such that the DEP 14 is contacted and the user 7 is prompted.
  • interaction rules 152 can be used to compile in the hash table 63 all public facts associated with the sender's questions
  • a questionnaire can be used to implement intermediate levels of disclosure
  • interaction rules 152 can further be used to create an entry in the hash table 63 comprising outbound public facts in the form of a score obtained in response to a user's answers to a questionnaire
  • a questionnaire is a private fact class made of a fact list 80 and of a total score to date 86
  • the questionnaire can prompt the user 7 with a series of questions, and rate the answers provided and compute a score representing a desirability index The score can then be compared to one or several given thresholds
  • the fact list 80 is made of an elementary private fact name 81, a list 82 of value 83 and note 84 pairs, and a note to date 85
  • the sender 4 is an electric utility company and the user 7 uses gas for heating and is probably likely to change his source of heat
  • the following questionnaire can be provided with the following thresholds and values
  • the user 7 can provide information relevant to a questionnaire and a score can be given The score can be compared by the sender 4 to a threshold indicative of whether the user 7 should be pursued Moreover, the private facts can be saved and updated by the DEP 14. For example, should the conclusion RR-c or the action Rl-a of a rule modify a particular elementary private fact associated with the questionnaire, an update method 87 associated with this questionnaire is called by the DEP to ensure this private fact has been modified on the questionnaire. Referring to the example above, should the user 7 indicate that his source of heat is electric, the system would note the change from gas to electric in the fact list, proceed to update the note to date for "source of heat" from 3 to 5 and recompute the score to date.
  • the questionnaire can be retrieved with the name 81, and value pair list 82 of the elementary private fact list 80.
  • the update method 87 proceeds to look up the name in the list 80 and, if the name matches name 81, to look up the value into the list 82. If the value matches the value 83, the note to date 85 is saved in a temporary value 88, replacing the note to date 85 with the note 84 corresponding to the name 81 and the value 83.
  • the total score to date 86 is further updated by adding to it the algebraic difference between the note 85 and the temporary value 88.
  • the update method 87 can be implemented such that it is called periodically, for example, in response to a chronometer-based pure rule, and proceeds to check the current value, if available, of all the facts of the list 80, and revise the notes to date 85 and the total score to date 86.
  • the publication of the total score to date 86 of a particular questionnaire can provide the sender 4 with a useful piece of information while, for the sake of the user's 7 privacy, the most sensitive private facts, those being the elementary facts making up the questionnaire are kept confidential.
  • the efficiency of the discovery process is improved by the use of questionnaires as in FIG. 8A.
  • the total score to date 86 for a particular questionnaire may have more meaning for the sender 4 than any single elementary private fact 81.
  • the discovery of the value of one elementary private fact 81 can be reused in multiple questionnaires without having to involve the user 7 again.
  • the total score to date 86 can be used by the DEP 14, for instance, by being compared to certain predetermined thresholds in the condition R-c of relevant rules.
  • a further improvement can be made by providing a special version, such as, for example, a Java extension, to the rules described in FIG. 6B through FIG. 6D.
  • a pure rule 90 that can be used to determine whether the total score to date 86 can be sent to the sender 4 and written as an outbound public fact 8.
  • a publishing request is received, as shown in FIG. 6A, comprising a name 61 and value 62 pair.
  • the rule 90 has a priority RI-p 240 of 11 and includes the conditions RI-c 242 that the publishing request list is not empty, that the name of the publishing request is not found in the outbound facts table, and that the value 62 associated with the publishing request is an object of a questionnaire class, that is, the value 62 is associated with the name 61 in a questionnaire.
  • the display list 244 Rl-d presented to the user 7 discloses the total score to date 86 to the user 7 for securing approval for publication, and also the content of the questionnaire list 80. In this manner, the user 7 understands the manner in which the scoring operation has been carried out by the sender 4 and that the action Rl-a 246 only publishes the total score to date 86.
  • the action 246 Rl-associated with this rule 90 is to obtain the current date and create an entry in the outbound public facts table with the name of the publishing request and the current date.
  • the user's 7 response determines how the permission status will be completed. As described above in FIGS. 6B - 6D, a "time out” or a “no” response will cause the permission status to read “denied”, while a “yes” response will cause the permission status to read "authorized.” Where the permission status indicates that the user 7 has authorized publication of the score, the DEP 14 transfers the score to the memory module 8 containing the outbound public facts and the EPR 16, which then transmits the score via the transaction network 12 to the sender 4.
  • the user can be questioned as to whether the private facts underlying the score should be transmitted to the memory module 8 containing the outbound public facts.
  • this embodiment is similar to the embodiment of Fig. 6B.
  • the rule described in Fig. 6C can further be applied to the questionnaire of Fig. 8 A, that is, a prior refusal to publish can be presented again to the user with a request to publish.
  • the rule described in Fig. 6D can further be applied to the questionnaire of Fig. 8 A, that is, a score that has been authorized for publication can be sent to the sender 4.
  • a plurality of senders 4 are configured to share certain system resources.
  • the distribution network 3, the transaction network 10, the interface computer 5, the multitasking operating system 13, the user interface 15, and the DEP 14 can be shared by a plurality of senders 4, given by SA, SB and SC.
  • only the distribution network 3 and the transaction network 10 can be shared.
  • the DEP 14 can be apprised of the senders 4 with which the user 4 wishes to interact, as well as the dialog classes 1 to execute, the private and public facts and the EPRs 16 associated with each sender.
  • the system of the present invention can comprise a plurality of EPRs 16, each of which can be associated with a different sender 4.
  • a group of senders SA, SB, SC can agree to share the definition and usage of some or all of the private 6a and public 8aa, 8ba facts.
  • a standard setting committee can publish a collection of base dialog classes (not shown) that the senders 4 agree to implement.
  • steps 18 and 21 can be used in such an embodiment, to ensure sharing of the data objects created from the common data class definitions.
  • a private fact can be discovered from the user 7 once, but disclosed or published to a plurality of senders after authorization has been given.
  • certain senders can have only limited access to shared data classes, such as, for example "readonly" classes for less trusted senders.
  • each sender 4 can have sender-specific class definitions, and objects can be created for higher security data items, such as private facts 6b, inbound public facts 8bb, and outbound public facts 8ab.
  • Sender-specific private facts 6b can be private facts disclosed by the user 7 that are applicable to a specific sender 4. For example, where a sender is an automobile dealer, the user's color preferences may be different from the user's color preferences for a sender providing women's apparel.
  • These facts, 6b, 8bb and 8ab can exist for each sender SA, SB, SC, although are shown in this figure for purposes of illustration only, as existing for sender SA 4.
  • the publishing request list 60 can further be augmented to include an attribute indicating whether the name/value pair 61, 62 is shared or not shared. In this manner, the requesting rules of FIG. 6B and 6C make the user 7 aware via the display list, that whenever authorization is granted with respect to shared private facts 6a, all senders SA, SB, SC have access to such private facts 6a.
  • the role of the sender 4 and the user 7, hereinafter referred to as sender 44 and receiver 77 can be automated, both having a pair of rule engines similar to the DEP 14 and the UIP 37.
  • the UIP 37 interacts with the user 7 via the user interface 15
  • the receiver "RX automatic answering process" RX-AAP 102 shown in the lower right quadrant
  • the RX - AAP 102 interacts with the SA - DEP 124 (shown in the lower left quadrant), which is similar to the DEP 14 of FIG. 2.
  • the RX - AAP 102 and the SA - DEP 124 provide for an automatic exchange of facts about the receiver 77 and the sender 44 to ensue.
  • Both the RX - AAP 102 and the SA - DEP 124 are implemented as a rule engine, as each instantiates and calls dialog classes in a manner as similarly described in connection with FIG. 2.
  • the RX - AAP 102 calls RX - AAP dialog classes 105
  • the SA - DEP 124 calls SA - DEP dialog classes 131.
  • the RX - AAP 102 manages hidden facts 104, which are facts relating to the receiver 77. Hidden facts 104 are typically preprogrammed by the receiver 77 and can include hidden facts to be discovered, as well as ancillary facts such as facts specifying cut-off dates or times at which the hidden facts will no longer be available for discovery as an outbound answer lOl to the SA-DEP 124.
  • the RX - AAP 102 interacts with the SA - DEP 124 in much the same manner as the UIP 37 interacts with the ML 36 in FIG. 4.
  • the RX - AAP 102 operates on the RX - AAP dialog classes 105, and using inbound questions 103 from the SA - DEP 124, determines which hidden facts 104 to supply as outbound answers 101 to the SA - DEP 124.
  • the RX-AAP 102 determines which hidden facts are to be discovered to become private facts, and which authorizations are to be given in request for publication of private facts.
  • the RX - AAP dialog classes 105 include pure rules 150 configured to permit discovery and ultimately, publication of certain hidden facts 104 in response to certain inbound questions 103 from the senders 44. Additionally, the AAP dialog classes 105 can be configured to interact in a different manner with different senders SA. For example, where a plurality of senders are disposed on a network as discussed in FIG. 9, each sender can have a SA - DEP 124, and the RX - AAP dialog classes 105 can be configured such that discovery and publication are more limited when the interaction is with a certain sender as opposed to other senders.
  • the RX - AAP 102 can flirther receive outbound public facts 110 relating to the sender S A and can use such outbound public facts in the interaction with the SA - DEP 124 to determine which hidden facts 104 should be discovered and which hidden facts 104 should be published.
  • the SA - DEP 124 executes the SA - DEP dialog classes 131 in a manner similar to the DEP 14, and receives inbound public facts 128 comprising information about the sender 44 described above.
  • the SA - DEP 124 manages private facts 132 and an outbound public fact list 130 comprising a hash table 63.
  • private facts 132 are, in the present embodiment, private facts obtained from the hidden facts 104 sent by the RX- AAP 102 as outbound answers 101 to the SA - DEP 124.
  • the outbound answers 101 are determined in response to the interactive rules in the SA - DEP 124, to be facts available for discovery in accordance to the rules associated with the RX-AAP dialog classes 105.
  • the rules associated with the RX-AAP 105 dialog classes like those described in connection with the sender 4 above, control the strategy of the receiver 77 in the interaction between the SA-DEP 124 and the RX-AAP 105.
  • the dialog classes 105 must be configured to permit such to occur.
  • outbound public facts 130 those being private facts obtained from the RX-AAP 102 as outbound answers 101 resulting from a publishing request by the SA - DEP 124, are listed in the hash table 63 with a permission status set as a yes or no outbound answer 101 to the SA - DEP 124.
  • Such an outbound answer 101 is determined, in response to the interactive rules of FIG. 6B and 6C of the SA - DEP 124, to be facts available for disclosure in accordance to the rules associated with the AAP dialog classes 105.
  • the outbound public facts 130 are made available to the SA - AAP 112, shown in the upper left quadrant, to aid the SA - AP 112 in determining which of its SA - hidden facts 115 should be discovered and published.
  • the SA - AAP 112 shown in the upper left quadrant, operates in a similar manner as the RX - AAP 102 described above. Like the RX - AAP 102, the SX - AAP 112 operates on SA - AAP dialog classes 114 and answers inbound questions 113 from the receiver 77. The answers are provided to the RX - DEP 107 in the form of outbound answers 111, and are determined using the sender's hidden facts 115 and the outbound public facts 130 that relate to the receiver 77, sent to the SA - AAP 112 from the SA - DEP 124.
  • the RX - DEP 107 shown in the upper right quadrant, operates in a similar manner as the
  • the RX-DEP 107 uses the RX - DEP dialog classes 106 and the outbound answers 111 to determine which inbound questions 1 13 should be presented to the SA - AAP 112 to obtain further hidden facts 115 about the sender 44 that are of interest to the receiver 77.
  • the RX - DEP 107 receives inbound public facts 109 relating to the receiver 77, manages private facts 108 and outbound public facts 110 about the sender 44.
  • a central database can be used to store the electronic addresses of all participating or registered sending and receiving parties.
  • the purpose of the database is to trigger the initialization of the process described in FIG. 10B, that is, an encounter, for any two registered parties and record the occurrence of such encounters.
  • Another implementation is to rely on the initiative of the parties to contact one another independently of any third user organization.
  • a central computer can be used for all data definition sharing, data objects storing and retrieval, dialog class and external process management.
  • This embodiment of the invention can be implemented for example with an object database coupled to the interface computer 5, having stored therein, RX and SA hidden facts, dialog classes and public facts
  • the interface computer 5 can act as a central marketplace where senders/receivers gather to exchange information, and the database administrator can act as the market organizer Relying on the database administrator to keep all data in confidence, especially from other registered parties
  • the receiver RX - AAP dialog classes 105 can reference the private facts 108 on the sender 44 along with the outbound public facts 110 on the sender 44
  • the sender SA - AAP dialog classes 114 can reference the private facts 132 on the receiver 77 along with the outbound public facts 130 on the receiver 77
  • Encounters can be provided for example by systematically matching any newly registered user in succession with all parties already registered in the opposite category The result for the user can be a qualified list of opposite parties appropriate for further consideration The exact nature and significance of such consideration can depend on the user organizing the market and on the parties' business objectives
  • a reference provider can be added to respond to employers looking for recommendations on job seekers and job seekers seeking information about prospective employers
  • the SA - DEP 124 and the RX - AAP 102, as well as the RX - DEP 107 and the SA - AAP 112 interact using rules having a similar format as the special request as described in FIG 7A, 7B and 7C
  • the interaction between the SA - DEP 124 and the RX - AAP 102 is described herein
  • signal QUE 126 associated with inbound question 103 is signal QUE 126, similar to inbound signal 71, which is set by the SA-DEP 124 and transmitted from the SA - DEP 124 to the RX - AAP 102
  • the inbound question 103 comprises a list of ordered sequence of name 116 and value 117 pairs.
  • the RX - AAP 102 Based on inbound question 103 and the QUE signal, the RX - AAP 102 sets a special request, the DEP interaction 125 and proceeds to provide an outbound answer as a list 101 of ordered name 118 and value 119 pairs using the RX - AAP dialog classes 105.
  • the RX - AAP 102 resets the DEP interaction 125 and sets signal ANS 127, similar to outbound acknowledgment 72.
  • the SA - DEP 124 resets signal QUE and proceeds to analyze the outbound answer list 101.
  • the RX - AAP 102 resets the acknowledgment signal ANS 127 such that a new question/answer cycle can occur.
  • the information 38 produced in step 25 by the display list Rl-d of an interaction RI 152 is formatted as the list of inbound question 103, using name 116 and value 1 17 pairs where the value 117 is left blank.
  • the inbound question list 103 is transmitted together with the signal QUE 126 having a value indicating that it is "set”.
  • the condition R-c of the interaction RI -a can further include a check that the acknowledgment ANS 127 is "reset".
  • the display list Rl-d further compiles a decision record 120 comprising a name 121, which corresponds to the name 116 of one of the inbound questions 103, and a decision list 122 comprising value 123 and code 124 decision pairs.
  • the decision list 122 must correspond to the list of possible outcomes expected by the action Rl-a of the interaction RI 152 and the codes to the indices for the user decision.
  • the decision record 120 can be ⁇ "decision", ⁇ ("yes",2), ("no",l), ("time-out", 0) ⁇
  • step 27 is formatted as a list of outbound answers 101, each comprising a name 118 and value 119 pair, together with the acknowledgment signal "ANS” 127 having a value indicating that it is "set”.
  • the information asked for by the SA - DEP 124 in the form of the question list 103 is received by the RX - AAP 102 and responded to by the RX - AAP 102 as the list of outbound answers 101 such that, for each question in the question list 103, one outbound answer exists whose name 118 matches the-name 116 of the question. This includes an answer whose name 118 matches the name 121 of the decision record 120, and whose value 119 matches the value 123 of a value code pair 122 in the decision list 120.
  • the SA - DEP 124 takes the code 129 of this code pair for the decision expected by the interaction RI. Following the above example, if the list 101 includes the pair ("decision","yes”), the decision index '2' is passed to step 28.
  • step 28 resets the signal QUE 126.
  • rules 74 and 76 are processed by the DEP 14, to allow interruption by the ERP 16, while rules 401, 402, 403 are processed by the RX-AAP 102, to allow interruption by the SA-DEP 124.
  • the rule 401 initializes the RX-AAP 102 to provide an outbound answer 101 as triggered by the signal QUE 126 from the RX-AAP 102.
  • the conditions R-c 250 associated with rule 401 are that the QUE 126 is set, the DEP interaction 125 is reset and the answer ANS 127 is reset, that is, the RX - AAP 102 is ready to process an inbound question list 103.
  • the conclusion 252 RR-c is that the DEP interaction 125 is set, the inbound question list associated with signal QUE 126 is copied into the display information 39, and the chronometer is initialized for a time-out, should the RX - AAP 102 not have an appropriate response to the question.
  • the rule 402 shown in FIG. 10E describes the acknowledgment given to the SA - DEP 124 when the RX - AAP 102 has completed responding or has failed to respond.
  • the conditions 256 R-c associated with this rule are such that the display information 39 has been emptied or cleared by the execution of appropriate pure rules included in the dialog classes 105, or a time-out has elapsed.
  • the conclusion 258 RR-c associated with this rule is that the DEP interaction parameter 125 is reset and the outbound answer ANS 127 is set. Additionally, the display list 39 is again cleared. It is to be appreciated that replacing rule 74 by rules 401 and 402 the acknowledgment signal ANS 127 acknowledges having both received and taken the signal QUE 126 into consideration, i.e. processed or ignored the question 103, while corresponding signal ACK 72 is sent immediately upon receipt, before any substantive consideration.
  • the rule 403 shown in FIG. 10F describes the resetting of parameters by the RX - AAP 102 after an outbound answer 101 has been sent and received by the SA - DEP 124.
  • the condition 262 R-C associated with this rule includes that the signal QUE 126 is reset and the acknowledgment signal ANS 127 is set.
  • the conclusion RR-c 264 associated with this rule resets the signal ANS, such that the RX - AAP 102 is ready to provide another answer when prompted again with signal QUE 126.
  • the sender 544 need only have an SA - DEP 524, and the user or receiver 577 need only have an RX - AAP 502.
  • the system of the present invention is similar to the portion of the system embodied in the lower left and right quadrants of FIG. 10 A.
  • This embodiment can be further considered an automated version of the embodiment of FIG. 2.
  • the sender 544 provides inbound public facts 528 and uses the SA - DEP 524 to generate inbound questions 503 to the RX -AAP 502, to which outbound answers 501 are provided by the RX - AAP 502 using the RX - AAP dialog rules 505 and the hidden facts 504.
  • the outbound answers are processed by the SA - DEP 524 to determine private facts 532 and outbound public facts 530 relative to the receiver 577.
  • the present embodiment can be useful in a situation, such as, for example where the sender is a corporate headquarters and the receivers are employees reporting to the headquarters. In this way, employees are responsible for providing the hidden facts and the headquarters staff determine the facts to be discovered locally and the facts to be disclosed back to headquarters.
  • a sender 344 can simply dispense information to a user or receiver 377. This embodiment corresponds to the upper left and right quadrants of the system of FIG. 10 A.
  • a receiver 377 having an RX - DEP 307 can obtain certain hidden facts 315 in the form of outbound answers 311 from the SA - AAP 312.
  • This embodiment can be used where the sender 344 is a government agency providing hidden facts 315 in the form of outbound answers 31 1 to certain users 377 having varying levels of authorization. For example, where a user 377 is a government official, the dialog classes 314 of the sender 344 would elicit different outbound answers 311 than they would for a civilian. In both the embodiment of FIG.
  • the interaction of the SA - DEP 524 and the RX - AAP 502, as well as the interaction between the RX - DEP 307 and the SA - AAP 312, can be similar to the interaction described between the DEP and the AAP, above in FIGs. 10A, 10B, 10C, 10D, lOE and lOF.
  • Fig. 12 shown is an example of the automatic answering process of the present invention, in which the sender is a prospective employer having a sending agent, hereinafter “employer's agent” and the employee is a prospective employee having a receiving agent, hereinafter “employee's agent”.
  • the SA-AAP and the SA- DEP are the employer's agent
  • the RX-AAP and the RX-DEP are the employee's agent.
  • each of the DEP and AAP units rely on dialog classes to determine which questions to ask of an opposing unit, and which answers to provide.
  • the employer's agent will ask job sought and years of experience offered, if these facts are not known. These questions can be provided as inbound questions to the RX - AAP, whose dialog classes are configured such that the RX - AAP can provide without condition, as outbound answers, the job sought, the years of experience offered and the willingness to travel.
  • the SA-DEP dialog classes can then ask other questions and inbound questions, depending on what the RX-AAP has provided as outbound answers. It is important to note that if a match is not found in both categories, job and years, future communication between the employer's agent and employee's agent can be terminated by the employer's agent and/or the employee's agent, on the basis that the other party is not of interest to the party. As shown, the SA-DEP dialog classes can ask the RX-AAP if the employee is interested, when it is found that the conditions of job sought and job offered match, and when the condition of years of experience is greater than the number of years required.
  • the RX-AAP dialog classes are configured to express interest if indeed the employee is interested.
  • hidden facts such as the job sought, the years offered, a general willingness to travel, the salary desired if travel is about 5% of the job, the salary desired if travel is about 20% of the job, geographic location desired, contact information, and resume. It is to be appreciated that such hidden facts can be given as outbound answers to the SA-DEP, as discovery of such facts. As for publication of such facts, further RX-AAP rules can decide whether publication of these facts as outbound public facts to the SA-AAP, will be granted based upon the requests made by the SA-DEP according to further SA-DEP rules.
  • the SA-DEP dialog classes can ask willingness to travel if the RX-AAP returns as an outbound answer that the employee is interested, and the willingness to travel has not yet been provided as an outbound answer. Additionally, if the employee's agent has indicated interest and a willingness to travel, the SA-DEP can ask if the employee is ready to deal, that is, whether the employee is ready to schedule a face to face meeting, disclose identity, contact information and/or a resume.
  • the RX-AAP dialog classes are configured to provide a willingness to deal when asked by the SA-DEP and there exists a willingness to deal. Finally, if the employer's agent has determined interest, the SA-DEP can ask the employee for the relevant contact information if not yet known. The RX-AAP will provide it, assuming the employee is ready to deal.
  • Pure rules associated with the SA-DEP dialog classes can determine which questions are to be provided to the RX-AAP and in what sequence they are to be provided. For instance a pure rule can determine whether the employee is of interest to the employer's agent, or whether communication should be terminated. Similarly, pure rules associated with the RX-AAP dialog classes can determine additional hidden facts, and which answers are to be provided to the SA- DEP. For instance a pure rule can determine whether the employee is interested in the employer's proposal, or whether communication should be terminated. As shown, after the SA-AAP gives out information on the job and the salary offered, a pure rule can determine if the employee is interested when jobs offered and sought match, and when the salary offered is greater than the minimum salary sought for travel about 5% of the job. Furthermore, in receipt of the amount of travel involved, another pure rule can determine if the employee is ready to deal if the salary offered is greater than the minimum salary sought, after having considered the amount of traveling required.
  • the RX-DEP executes dialog classes associated therewith to determine if the prospective employee is interested in the employer or even ready to deal. For instance, the employee's agent can ask without condition as inbound questions, the job offered, years experience required and salary offered. Additional rules can ask the percentage of travel that is required and the geographic location of the position, when the job offered matches the job desired and the salary offered is greater than the salary desired. Similarly, if the employee's agent has determined a willingness to deal, the RX-DEP can ask whether the employer is interested and for employer or company information. As similarly described above, pure rules associated with the RX-DEP dialog classes can determine whether the employee is interested in or even ready to deal with, the prospective employer.
  • the SA-AAP dialog classes can determine the appropriate response, that is, which hidden facts, can be provided as outbound answers.
  • the hidden facts associated with the SA-AAP dialog classes are the job offered, year experience, salary, percentage travel, location offered, company information and contact information.
  • the SA-AAP can provide, without condition, the job offered by the employer and number of years of experience required. Salary information can be given only if the job offered and the years of experience offered is greater than the years required, according to the dialog classes.
  • the percentage of travel can be given when the employee's agent indicates an interest and a willingness to travel of the prospective employee.
  • the location-can be given when the employee's agent indicates interest of the prospective employee.
  • the fact that the employer is interested can be given if it is indeed the case according to the same rule used by the SA-DEP.
  • the prospective employer and prospective employee can determine their respective interest without having to provide their identity to each other. If interest exists, contact information can be published to the party requesting it, however, if no interest exists, communication can be terminated, and the confidentiality and anonymity of both the prospective employee and the prospective employer is preserved. It is to be appreciated that the example provided in Fig. 12 is simply one implementation of the present invention, and that other, more complex communication strategies and tactics can be designed. Additionally, other businesses, persons or entities can be provided to replace the prospective employer's agent and the prospective employee's agent, to discover facts about each other, determine interest, and publish only those facts for which authorization has been given.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système et un procédé pour la recherche et l'exploitation d'informations auprès d'un utilisateur (par exemple, données privées ou confidentielles), qui permet simultanément d'empêcher la publication non autorisée des informations. Une unité d'émission à module de traitement envoie une demande de publication d'informations concernant un utilisateur; un agent en liaison avec l'unité d'émission reçoit la demande, et un utilisateur en liaison avec l'agent répond aux sollicitations émanant de l'agent. Les sollicitations invitent l'utilisateur à divulguer les éléments liés à l'information recherchée par l'unité d'émission et fournissent les indications relatives à l'autorisation de publication, pour l'unité d'émission, des éléments qui seront divulgués. L'agent reçoit les éléments et détermine si ces éléments doivent être mis à la disposition de l'unité d'émission. L'agent peut comporter un module de mémoire, et un module de traitement du type moteur à base de règles utilisant des classes de dialogue, afin de communiquer avec l'unité d'émission et l'utilisateur, de déterminer si les indications relatives à l'autorisation qui porte sur les éléments concernés permettent la publication de ces éléments pour l'unité d'émission, et de publier les éléments pour les besoins de l'unité d'émission lorsque les indications correspondent bien à une autorisation de publication.
EP98935494A 1997-07-02 1998-06-30 Systeme et procede pour la recherche, l'exploitation et la publication protegees d'informations Ceased EP1008084A1 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US5158797P 1997-07-02 1997-07-02
US51587P 1997-07-02
US1778 1997-12-31
US09/001,778 US6092197A (en) 1997-12-31 1997-12-31 System and method for the secure discovery, exploitation and publication of information
PCT/US1998/013405 WO1999001834A1 (fr) 1997-07-02 1998-06-30 Systeme et procede pour la recherche, l'exploitation et la publication protegees d'informations

Publications (1)

Publication Number Publication Date
EP1008084A1 true EP1008084A1 (fr) 2000-06-14

Family

ID=26669460

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98935494A Ceased EP1008084A1 (fr) 1997-07-02 1998-06-30 Systeme et procede pour la recherche, l'exploitation et la publication protegees d'informations

Country Status (2)

Country Link
EP (1) EP1008084A1 (fr)
WO (1) WO1999001834A1 (fr)

Families Citing this family (136)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000060435A2 (fr) * 1999-04-07 2000-10-12 Rensselaer Polytechnic Institute Systeme et procede d'acces a des donnees personnelles
WO2001033936A2 (fr) * 1999-10-29 2001-05-17 Privacomp, Inc. Systeme base sur un consentement informe dynamique de donnees assurant la confidentialite des donnees et la securite dans les systemes de base de donnees et dans les communications sur reseau.
US8645137B2 (en) 2000-03-16 2014-02-04 Apple Inc. Fast, language-independent method for user authentication by voice
US7177798B2 (en) 2000-04-07 2007-02-13 Rensselaer Polytechnic Institute Natural language interface using constrained intermediate dictionary of results
US6678516B2 (en) * 2001-05-21 2004-01-13 Nokia Corporation Method, system, and apparatus for providing services in a privacy enabled mobile and Ubicom environment
US8677377B2 (en) 2005-09-08 2014-03-18 Apple Inc. Method and apparatus for building an intelligent automated assistant
US9318108B2 (en) 2010-01-18 2016-04-19 Apple Inc. Intelligent automated assistant
US8977255B2 (en) 2007-04-03 2015-03-10 Apple Inc. Method and system for operating a multi-function portable electronic device using voice-activation
US9053089B2 (en) 2007-10-02 2015-06-09 Apple Inc. Part-of-speech tagging using latent analogy
US9330720B2 (en) 2008-01-03 2016-05-03 Apple Inc. Methods and apparatus for altering audio output signals
US8065143B2 (en) 2008-02-22 2011-11-22 Apple Inc. Providing text input using speech data and non-speech data
US8996376B2 (en) 2008-04-05 2015-03-31 Apple Inc. Intelligent text-to-speech conversion
US10496753B2 (en) 2010-01-18 2019-12-03 Apple Inc. Automatically adapting user interfaces for hands-free interaction
US8464150B2 (en) 2008-06-07 2013-06-11 Apple Inc. Automatic language identification for dynamic text processing
US20100030549A1 (en) 2008-07-31 2010-02-04 Lee Michael M Mobile device having human language translation capability with positional feedback
US8768702B2 (en) 2008-09-05 2014-07-01 Apple Inc. Multi-tiered voice feedback in an electronic device
US8898568B2 (en) 2008-09-09 2014-11-25 Apple Inc. Audio user interface
US8676904B2 (en) 2008-10-02 2014-03-18 Apple Inc. Electronic devices with voice command and contextual data processing capabilities
WO2010067118A1 (fr) 2008-12-11 2010-06-17 Novauris Technologies Limited Reconnaissance de la parole associée à un dispositif mobile
US8862252B2 (en) 2009-01-30 2014-10-14 Apple Inc. Audio user interface for displayless electronic device
US10255566B2 (en) 2011-06-03 2019-04-09 Apple Inc. Generating and processing task items that represent tasks to perform
US9858925B2 (en) 2009-06-05 2018-01-02 Apple Inc. Using context information to facilitate processing of commands in a virtual assistant
US10540976B2 (en) 2009-06-05 2020-01-21 Apple Inc. Contextual voice commands
US10241644B2 (en) 2011-06-03 2019-03-26 Apple Inc. Actionable reminder entries
US10241752B2 (en) 2011-09-30 2019-03-26 Apple Inc. Interface for a virtual digital assistant
US9431006B2 (en) 2009-07-02 2016-08-30 Apple Inc. Methods and apparatuses for automatic speech recognition
US8381107B2 (en) 2010-01-13 2013-02-19 Apple Inc. Adaptive audio feedback system and method
US10705794B2 (en) 2010-01-18 2020-07-07 Apple Inc. Automatically adapting user interfaces for hands-free interaction
US10679605B2 (en) 2010-01-18 2020-06-09 Apple Inc. Hands-free list-reading by intelligent automated assistant
US10276170B2 (en) 2010-01-18 2019-04-30 Apple Inc. Intelligent automated assistant
US10553209B2 (en) 2010-01-18 2020-02-04 Apple Inc. Systems and methods for hands-free notification summaries
WO2011089450A2 (fr) 2010-01-25 2011-07-28 Andrew Peter Nelson Jerram Appareils, procédés et systèmes pour plateforme de gestion de conversation numérique
US8682667B2 (en) 2010-02-25 2014-03-25 Apple Inc. User profiling for selecting user specific voice input processing information
US8719014B2 (en) 2010-09-27 2014-05-06 Apple Inc. Electronic device with text error correction based on voice recognition data
US10515147B2 (en) 2010-12-22 2019-12-24 Apple Inc. Using statistical language models for contextual lookup
US10762293B2 (en) 2010-12-22 2020-09-01 Apple Inc. Using parts-of-speech tagging and named entity recognition for spelling correction
US9262612B2 (en) 2011-03-21 2016-02-16 Apple Inc. Device access using voice authentication
US10057736B2 (en) 2011-06-03 2018-08-21 Apple Inc. Active transport based notifications
US10672399B2 (en) 2011-06-03 2020-06-02 Apple Inc. Switching between text data and audio data based on a mapping
US8994660B2 (en) 2011-08-29 2015-03-31 Apple Inc. Text correction processing
US10134385B2 (en) 2012-03-02 2018-11-20 Apple Inc. Systems and methods for name pronunciation
US9483461B2 (en) 2012-03-06 2016-11-01 Apple Inc. Handling speech synthesis of content for multiple languages
US9280610B2 (en) 2012-05-14 2016-03-08 Apple Inc. Crowd sourcing information to fulfill user requests
US10417037B2 (en) 2012-05-15 2019-09-17 Apple Inc. Systems and methods for integrating third party services with a digital assistant
US9721563B2 (en) 2012-06-08 2017-08-01 Apple Inc. Name recognition system
WO2013185109A2 (fr) 2012-06-08 2013-12-12 Apple Inc. Systèmes et procédés servant à reconnaître des identificateurs textuels dans une pluralité de mots
US9495129B2 (en) 2012-06-29 2016-11-15 Apple Inc. Device, method, and user interface for voice-activated navigation and browsing of a document
US9576574B2 (en) 2012-09-10 2017-02-21 Apple Inc. Context-sensitive handling of interruptions by intelligent digital assistant
US9547647B2 (en) 2012-09-19 2017-01-17 Apple Inc. Voice-based media searching
US8935167B2 (en) 2012-09-25 2015-01-13 Apple Inc. Exemplar-based latent perceptual modeling for automatic speech recognition
WO2014124332A2 (fr) 2013-02-07 2014-08-14 Apple Inc. Elément déclencheur vocal pour assistant numérique
US10642574B2 (en) 2013-03-14 2020-05-05 Apple Inc. Device, method, and graphical user interface for outputting captions
US10652394B2 (en) 2013-03-14 2020-05-12 Apple Inc. System and method for processing voicemail
US9977779B2 (en) 2013-03-14 2018-05-22 Apple Inc. Automatic supplementation of word correction dictionaries
US10572476B2 (en) 2013-03-14 2020-02-25 Apple Inc. Refining a search based on schedule items
US9733821B2 (en) 2013-03-14 2017-08-15 Apple Inc. Voice control to diagnose inadvertent activation of accessibility features
US9368114B2 (en) 2013-03-14 2016-06-14 Apple Inc. Context-sensitive handling of interruptions
US10748529B1 (en) 2013-03-15 2020-08-18 Apple Inc. Voice activated device for use with a voice-based digital assistant
WO2014144949A2 (fr) 2013-03-15 2014-09-18 Apple Inc. Entraînement d'un système à commande au moins partiellement vocale
WO2014144579A1 (fr) 2013-03-15 2014-09-18 Apple Inc. Système et procédé pour mettre à jour un modèle de reconnaissance de parole adaptatif
CN105190607B (zh) 2013-03-15 2018-11-30 苹果公司 通过智能数字助理的用户培训
KR101904293B1 (ko) 2013-03-15 2018-10-05 애플 인크. 콘텍스트-민감성 방해 처리
WO2014197334A2 (fr) 2013-06-07 2014-12-11 Apple Inc. Système et procédé destinés à une prononciation de mots spécifiée par l'utilisateur dans la synthèse et la reconnaissance de la parole
WO2014197336A1 (fr) 2013-06-07 2014-12-11 Apple Inc. Système et procédé pour détecter des erreurs dans des interactions avec un assistant numérique utilisant la voix
US9582608B2 (en) 2013-06-07 2017-02-28 Apple Inc. Unified ranking with entropy-weighted information for phrase-based semantic auto-completion
WO2014197335A1 (fr) 2013-06-08 2014-12-11 Apple Inc. Interprétation et action sur des commandes qui impliquent un partage d'informations avec des dispositifs distants
US10176167B2 (en) 2013-06-09 2019-01-08 Apple Inc. System and method for inferring user intent from speech inputs
KR101922663B1 (ko) 2013-06-09 2018-11-28 애플 인크. 디지털 어시스턴트의 둘 이상의 인스턴스들에 걸친 대화 지속성을 가능하게 하기 위한 디바이스, 방법 및 그래픽 사용자 인터페이스
KR101809808B1 (ko) 2013-06-13 2017-12-15 애플 인크. 음성 명령에 의해 개시되는 긴급 전화를 걸기 위한 시스템 및 방법
JP6163266B2 (ja) 2013-08-06 2017-07-12 アップル インコーポレイテッド リモート機器からの作動に基づくスマート応答の自動作動
US10296160B2 (en) 2013-12-06 2019-05-21 Apple Inc. Method for extracting salient dialog usage from live data
US9620105B2 (en) 2014-05-15 2017-04-11 Apple Inc. Analyzing audio input for efficient speech and music recognition
US10592095B2 (en) 2014-05-23 2020-03-17 Apple Inc. Instantaneous speaking of content on touch devices
US9502031B2 (en) 2014-05-27 2016-11-22 Apple Inc. Method for supporting dynamic grammars in WFST-based ASR
US9760559B2 (en) 2014-05-30 2017-09-12 Apple Inc. Predictive text input
US10170123B2 (en) 2014-05-30 2019-01-01 Apple Inc. Intelligent assistant for home automation
AU2015266863B2 (en) 2014-05-30 2018-03-15 Apple Inc. Multi-command single utterance input method
US10289433B2 (en) 2014-05-30 2019-05-14 Apple Inc. Domain specific language for encoding assistant dialog
US9785630B2 (en) 2014-05-30 2017-10-10 Apple Inc. Text prediction using combined word N-gram and unigram language models
US9734193B2 (en) 2014-05-30 2017-08-15 Apple Inc. Determining domain salience ranking from ambiguous words in natural speech
US9715875B2 (en) 2014-05-30 2017-07-25 Apple Inc. Reducing the need for manual start/end-pointing and trigger phrases
US10078631B2 (en) 2014-05-30 2018-09-18 Apple Inc. Entropy-guided text prediction using combined word and character n-gram language models
US9430463B2 (en) 2014-05-30 2016-08-30 Apple Inc. Exemplar-based natural language processing
US9633004B2 (en) 2014-05-30 2017-04-25 Apple Inc. Better resolution when referencing to concepts
US9842101B2 (en) 2014-05-30 2017-12-12 Apple Inc. Predictive conversion of language input
US9338493B2 (en) 2014-06-30 2016-05-10 Apple Inc. Intelligent automated assistant for TV user interactions
US10659851B2 (en) 2014-06-30 2020-05-19 Apple Inc. Real-time digital assistant knowledge updates
US10446141B2 (en) 2014-08-28 2019-10-15 Apple Inc. Automatic speech recognition based on user feedback
US9818400B2 (en) 2014-09-11 2017-11-14 Apple Inc. Method and apparatus for discovering trending terms in speech requests
US10789041B2 (en) 2014-09-12 2020-09-29 Apple Inc. Dynamic thresholds for always listening speech trigger
US10074360B2 (en) 2014-09-30 2018-09-11 Apple Inc. Providing an indication of the suitability of speech recognition
US9668121B2 (en) 2014-09-30 2017-05-30 Apple Inc. Social reminders
US9646609B2 (en) 2014-09-30 2017-05-09 Apple Inc. Caching apparatus for serving phonetic pronunciations
US9886432B2 (en) 2014-09-30 2018-02-06 Apple Inc. Parsimonious handling of word inflection via categorical stem + suffix N-gram language models
US10127911B2 (en) 2014-09-30 2018-11-13 Apple Inc. Speaker identification and unsupervised speaker adaptation techniques
US10552013B2 (en) 2014-12-02 2020-02-04 Apple Inc. Data detection
US9711141B2 (en) 2014-12-09 2017-07-18 Apple Inc. Disambiguating heteronyms in speech synthesis
US9865280B2 (en) 2015-03-06 2018-01-09 Apple Inc. Structured dictation using intelligent automated assistants
US9721566B2 (en) 2015-03-08 2017-08-01 Apple Inc. Competing devices responding to voice triggers
US9886953B2 (en) 2015-03-08 2018-02-06 Apple Inc. Virtual assistant activation
US10567477B2 (en) 2015-03-08 2020-02-18 Apple Inc. Virtual assistant continuity
US9899019B2 (en) 2015-03-18 2018-02-20 Apple Inc. Systems and methods for structured stem and suffix language models
US9842105B2 (en) 2015-04-16 2017-12-12 Apple Inc. Parsimonious continuous-space phrase representations for natural language processing
US10083688B2 (en) 2015-05-27 2018-09-25 Apple Inc. Device voice control for selecting a displayed affordance
US10127220B2 (en) 2015-06-04 2018-11-13 Apple Inc. Language identification from short strings
US10101822B2 (en) 2015-06-05 2018-10-16 Apple Inc. Language input correction
US11025565B2 (en) 2015-06-07 2021-06-01 Apple Inc. Personalized prediction of responses for instant messaging
US10186254B2 (en) 2015-06-07 2019-01-22 Apple Inc. Context-based endpoint detection
US10255907B2 (en) 2015-06-07 2019-04-09 Apple Inc. Automatic accent detection using acoustic models
US10671428B2 (en) 2015-09-08 2020-06-02 Apple Inc. Distributed personal assistant
US10747498B2 (en) 2015-09-08 2020-08-18 Apple Inc. Zero latency digital assistant
US9697820B2 (en) 2015-09-24 2017-07-04 Apple Inc. Unit-selection text-to-speech synthesis using concatenation-sensitive neural networks
US10366158B2 (en) 2015-09-29 2019-07-30 Apple Inc. Efficient word encoding for recurrent neural network language models
US11010550B2 (en) 2015-09-29 2021-05-18 Apple Inc. Unified language modeling framework for word prediction, auto-completion and auto-correction
US11587559B2 (en) 2015-09-30 2023-02-21 Apple Inc. Intelligent device identification
US10691473B2 (en) 2015-11-06 2020-06-23 Apple Inc. Intelligent automated assistant in a messaging environment
US10049668B2 (en) 2015-12-02 2018-08-14 Apple Inc. Applying neural network language models to weighted finite state transducers for automatic speech recognition
US10223066B2 (en) 2015-12-23 2019-03-05 Apple Inc. Proactive assistance based on dialog communication between devices
US10446143B2 (en) 2016-03-14 2019-10-15 Apple Inc. Identification of voice inputs providing credentials
US9934775B2 (en) 2016-05-26 2018-04-03 Apple Inc. Unit-selection text-to-speech synthesis based on predicted concatenation parameters
US9972304B2 (en) 2016-06-03 2018-05-15 Apple Inc. Privacy preserving distributed evaluation framework for embedded personalized systems
US10249300B2 (en) 2016-06-06 2019-04-02 Apple Inc. Intelligent list reading
US10049663B2 (en) 2016-06-08 2018-08-14 Apple, Inc. Intelligent automated assistant for media exploration
DK179588B1 (en) 2016-06-09 2019-02-22 Apple Inc. INTELLIGENT AUTOMATED ASSISTANT IN A HOME ENVIRONMENT
US10509862B2 (en) 2016-06-10 2019-12-17 Apple Inc. Dynamic phrase expansion of language input
US10067938B2 (en) 2016-06-10 2018-09-04 Apple Inc. Multilingual word prediction
US10490187B2 (en) 2016-06-10 2019-11-26 Apple Inc. Digital assistant providing automated status report
US10192552B2 (en) 2016-06-10 2019-01-29 Apple Inc. Digital assistant providing whispered speech
US10586535B2 (en) 2016-06-10 2020-03-10 Apple Inc. Intelligent digital assistant in a multi-tasking environment
DK179049B1 (en) 2016-06-11 2017-09-18 Apple Inc Data driven natural language event detection and classification
DK201670540A1 (en) 2016-06-11 2018-01-08 Apple Inc Application integration with a digital assistant
DK179415B1 (en) 2016-06-11 2018-06-14 Apple Inc Intelligent device arbitration and control
DK179343B1 (en) 2016-06-11 2018-05-14 Apple Inc Intelligent task discovery
US10593346B2 (en) 2016-12-22 2020-03-17 Apple Inc. Rank-reduced token representation for automatic speech recognition
DK179745B1 (en) 2017-05-12 2019-05-01 Apple Inc. SYNCHRONIZATION AND TASK DELEGATION OF A DIGITAL ASSISTANT
DK201770431A1 (en) 2017-05-15 2018-12-20 Apple Inc. Optimizing dialogue policy decisions for digital assistants using implicit feedback

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5794210A (en) * 1995-12-11 1998-08-11 Cybergold, Inc. Attention brokerage

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9901834A1 *

Also Published As

Publication number Publication date
WO1999001834A1 (fr) 1999-01-14

Similar Documents

Publication Publication Date Title
US6092197A (en) System and method for the secure discovery, exploitation and publication of information
WO1999001834A1 (fr) Systeme et procede pour la recherche, l'exploitation et la publication protegees d'informations
US11797698B2 (en) Decentralized consent network for decoupling the storage of personally identifiable user data from user profiling data
US6697824B1 (en) Relationship management in an E-commerce application framework
US9984252B2 (en) Methods and systems for facilitating personal data propagation
US6904449B1 (en) System and method for an application provider framework
US8296323B2 (en) Personal data subscriber systems and methods
US7930411B1 (en) Network-based verification and fraud-prevention system
CA2753977C (fr) Systemes et procedes d'utilisation de cartes d'informations verifiees dans un reseau de communication
CN100565448C (zh) 用于提供电子中间平台的计算机实施的方法
US20140372176A1 (en) Method and apparatus for anonymous data profiling
US20100082652A1 (en) Method and system for managing user interaction
US20110244833A1 (en) Telephone Service Logic and Control
US20120084349A1 (en) User interface for user management and control of unsolicited server operations
US20120084151A1 (en) Facilitation of user management of unsolicited server operations and extensions thereto
US20120084348A1 (en) Facilitation of user management of unsolicited server operations
WO2013003316A2 (fr) Facilitation de gestion d'utilisateur d'opérations de serveur non sollicitées par modification de celles-ci
CN101099172A (zh) 使用用户的资格以便于用户执行任务
TW491972B (en) System, method, and article of manufacture for electronic merchandising in an e-commerce application framework
Zibuschka et al. Users’ preferences concerning privacy properties of assistant systems on the internet of things
US20040111347A1 (en) Methods and systems for business-to consumer marketing to promote and execute e-commerce transactions
US7363245B1 (en) Electronic product packaging and distribution for e-Commerce
WO2001016851A2 (fr) Systeme, procede et article manufacture d'aide a la decision dans le cadre d'une application de commerce electronique
US7093281B2 (en) Casual access application with context sensitive pin authentication
EP1247203A2 (fr) Procede pour un cadre de fournisseur de services applicatifs

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20000202

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 20010404

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20071025