WO2002005153A2 - Systeme, procede et support facilitant des transactions sur un reseau - Google Patents

Systeme, procede et support facilitant des transactions sur un reseau Download PDF

Info

Publication number
WO2002005153A2
WO2002005153A2 PCT/IB2001/001471 IB0101471W WO0205153A2 WO 2002005153 A2 WO2002005153 A2 WO 2002005153A2 IB 0101471 W IB0101471 W IB 0101471W WO 0205153 A2 WO0205153 A2 WO 0205153A2
Authority
WO
WIPO (PCT)
Prior art keywords
realme
user
information
database
suppliers
Prior art date
Application number
PCT/IB2001/001471
Other languages
English (en)
Other versions
WO2002005153A3 (fr
Inventor
Colin Frost
Original Assignee
2020Me Holdings Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 2020Me Holdings Ltd. filed Critical 2020Me Holdings Ltd.
Priority to AU2001277638A priority Critical patent/AU2001277638A1/en
Publication of WO2002005153A2 publication Critical patent/WO2002005153A2/fr
Publication of WO2002005153A3 publication Critical patent/WO2002005153A3/fr

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/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to a system, method and medium for network-based transactions, and more particularly to a system, method and medium for creating and utilizing a virtual representation of a real user to facilitate consumer-to-business and business-to-business transactions on networks and other electronic media such as interactive digital television, personal digital assistants, and mobile phones.
  • Prior-art systems have been created to collect information on the preferences and tastes of individual consumers in order to sell the information on to advertisers to support highly targeted advertising. Examples include win-win.com. The consumer is in some cases offered a small financial reward in return for viewing the advertisements. These systems support a traditional ad-hoc business-to-consumer advertising model, instead of using the information to support a consumer-to-business model, wherein suppliers use the information to support the servicing specific consumer requirements. The consumer is asked to give up a lot of information about himself or herself, without necessarily securing any significant direct benefit.
  • the user can only use the information to interact with web sites that are compliant with these systems (i.e. have themselves installed corresponding software to receive the information from the consumer).
  • these systems i.e. have themselves installed corresponding software to receive the information from the consumer.
  • the consumer is highly constrained by the fact that he or she must use the system on which the software was installed, and upon which he or she has stored their information, and which are rendered useless when the user is remote from the system or is mobile.
  • affiliate programs Prior art systems do exist today to support information exchange between affiliated companies, however these systems focus on revenue sharing rather than profile sharing.
  • affiliate programs include DoubleClick and Amazon.com.
  • These systems seek to increase the number of visitors to affiliated web sites, perhaps because they are not being visited frequently or because they are new sites.
  • the systems support partnerships between Internet-based retailers (merchants) and the webmasters of other web sites, whereby the merchants offer the webmasters commissions for promoting their products and services on their sites.
  • the affiliate program itself is the technology that the merchant uses to track the sales and leads that the webmasters bring, in order to pay the webmaster a commission for converted sales leads and/or to pay a click-through revenue fee.
  • Such systems are designed to benefit merchants by bringing more customers to their sites, and the webmasters by offering them additional revenue channels.
  • the customer's experience is not particularly enhanced; he or she merely sees advertising banners which encourage him or her to visit certain sites.
  • advertising banners are not a novel aspect of affiliate programs; they may be viewed as well on web sites which are not part of an affiliates program. The effect for the consumer is to have their choice limited with no overall benefit to them, as the choice offered to them tends not to be governed by the suppliers' price-performance capabilities, but whether or not the supplier happens to be part of the affiliate network and how much the supplier is willing to pay to the webmaster for being publicized to the consumer.
  • shop bots such as mySimon.com which search for a particular item or service on the Internet at the expressed request of a user.
  • shop bots In response to a request, shop bots typically retrieve from a database a collection of currently available offers related to the request. The user must then sort through the offers to determine which, if any, is suitable.
  • shop bots may also compile and store profile information on users derived typically from brief, standardized questionnaires and/or user purchasing history. Such profile information is usually limited in scope and used only to identify general areas of interest to the user. The user typically receives offers solely from Internet-based merchants based on such profile information and must sort through a large number of offers of little or no interest to him or her.
  • auction and reverse auction sites which are an increasingly popular means of purchasing by consumers, do not reflect the consumer's own requirements at a given time. It is left to the consumer to determine whether or not ongoing or anticipated auctions and reverse auctions are addressing a good or service that he or she is interested in purchasing. In addition, the complexity of the auction mechanisms has resulted in persistent apprehension surrounding their use. Consequently, a large number of consumer needs which could be satisfied through electronic commerce remain unserved by the methods available today.
  • the requirements are not stored on a profile, but only with the pertinent request, such that if the consumer wants to make a subsequent request, e.g. another hotel room in Washington but later than month, the preferences are lost (even if the second hotel room is requested before logging out).
  • Prior art systems tend to be inefficient in the way they hold data, in the sense that many systems often hold the same data on a group of people, thus using resources that would not have to be used if the data on an individual were held in one place that could be accessible, subject to access rights and verification, by many systems contemporaneously.
  • This arrangement would be particularly beneficial to systems which serve the public, such as those of medical establishments, libraries, social services, tax services etc.
  • An object of the present invention is to provide a method and system that overcomes the drawbacks, deficiencies, and disadvantages of the prior art.
  • a method to facilitate transactions over a network comprises creating a virtual representation of a user and managing the virtual representation to perform communications over the network on behalf of the user based on predefined information.
  • the managing of the virtual representation satisfies user desires.
  • the method further comprises gathering information about the virtual representation, storing the gathered information as a data source, receiving a request from the user, accessing the data source to retrieve at least a portion of the gathered information, and correlating the request to the at least a portion of the gathered information.
  • the method further comprises requesting suppliers to respond to the request of the user, generating an order based on the at least a portion of the gathered information and the request to satisfy the user desires, and submitting the order to a supplier that can accommodate the user desires.
  • the method further comprises calculating a fee for the order based on the at least a portion of gathered information and the request and obtaining authorization for payment of the fee from the user.
  • the method further comprises determining a time duration for gathering information about the user and presenting questions to the user during the time duration and partially derived from information stored about the virtual representation.
  • the method further comprises determining an end time based on the time duration and information stored about the virtual representation, ending a learning session for the user, and indexing the end of the learning session for subsequent resumption.
  • the method further comprises gathering information about the virtual representation and determining a level of completeness for the virtual representation. In a further aspect of the present invention, the method further comprises presenting questions to the user based on the level of completeness of the virtual representation.
  • the method further comprises gathering information about the virtual representation from the user, storing the information about the virtual representation in a database, and updating the information stored in the database about the virtual representation in order to better represent the user via the corresponding virtual representation.
  • the method further comprises classifying information about the virtual representation by determining for each piece of information at least one of the following: a unique identification code of an attribute, a value of the attribute, a date and time stamp for the attribute, a date and time indicating an optimal duration of validity of the attribute value, a confidentiality of the attribute, an indication of the degree of implicitness of the attribute, and a ratification value of the attribute.
  • the method further comprises determining an interruption in the communication between the user and at least the virtual representation, and re-establishing the communication.
  • the method further comprises enabling the user to select the method of re- establishing the communication.
  • the communication resumes from the point of interruption.
  • the interrupted communication is stored and a new communication commences.
  • a system to facilitate communications over a network.
  • the system comprises a database including a virtual representation of a user, and a host communicating with the database for managing the virtual representation and performing communications over the network on behalf of the user based on predefined information.
  • the system further comprises a user interface providing selective access by the user to the database, and a processor responsive to the host for processing a communication between the user and a supplier wherein at least one party to the communication is selected by the other party via the user interface.
  • the processor comprises a central server for processing the communications on behalf of users and suppliers.
  • the processor comprises a remote server for processing at least a portion of the communications at the remote terminals.
  • system further comprises a storage responsive to the processor for validation and storage of information generated during the communications.
  • the system further comprises a statistical server responsive to the processor and database to process, retrieve and update statistical information regarding communications and user information.
  • the user interface further comprises an interactive conversational application for providing direct communications between a plurality of users and the system.
  • the system further comprises a learning manager gathering information on the virtual representation and storing the gathered information as a data source, a conversation manager managing interaction with the user, a processor accessing the data source to retrieve at least a portion of the gathered information, and a recipe database correlating the request to the at least a portion of the gathered information.
  • a method of communicating on a network comprises gathering information from a source that conveys future intention, and disseminating information derived from the gathered information throughout a supply chain, based on an aggregation of the gathered information and a probability of completion of the future intention.
  • the information is disseminated simultaneously and is appropriate for the recipient of the derived information.
  • the information being gathered also conveys confirmed transactions.
  • a system for managing communications over a network comprises a server connected to the network, a user interface for interacting with the server over the distributed network through multiple channels, a channel monitor for monitoring the channels and determining the strength of each of the channels and a communications monitor for monitoring communications between the user interface and the server, the communications monitor informing the user of available channels based on the monitored strength of the channels.
  • a method for managing communications over a network comprises establishing communications over one of a plurality of channels between a user interface and a server, monitoring the communications between the user interface and the server, determining the strength of each of said plurality of channels between the user interface and the server and recommending a suitable one of the plurality of channels to the user based on the determined strengths of the plurality of channels between the user interface and the server.
  • the method further comprises receiving a channel selection from the user, and establishing communications between the user interface and the server over the selected channel. In another aspect of the present invention, the method further comprises detecting a failure of the established communications channel, and re-establishing communications between the user interface and the server over one of the plurality of channels.
  • a method of communication over a network comprises conversing over multiple channels in the network concurrently, and monitoring each of the multiple channels in order to maintain a dialogue across the multiple channels.
  • the method further comprises establishing communications over the network between a user interface and a server, monitoring content of the communications between the user interface and the server to determine the context of the content, and presenting information about the content to the user based on the context of the content.
  • the method further comprises detecting a failure of the communications between the user interface and the server, and re-establishing communications between the user interface and the server such that the communications resume at the point of failure.
  • the method further comprises detecting a change in the context of the content of the communications and presenting information to the user based on the change in the context of the content.
  • at least one channel is a fixed channel, and at least another channel is a mobile channel.
  • a system for managing communications over a network comprises a server connected to the network, a user interface for interacting with the server over the network, a conversation manager for monitoring content of communications between the user interface and the server, and a conversation manager for maintaining an integrity of communications between the user interface and the server.
  • a system for facilitating a user's ⁇ se of a distributed network comprises a server, a channel monitor for controlling a plurality of communication channels between a user and the server, a conversation manager in communication with the channel monitor for managing communications between the user and the system, wherein the conversation manager is connected to a presentation application for formatting outgoing dialogue and content, and interpreting ' and formatting incoming dialogue and content appropriate to each communication channel, an encryption application in communication with the conversation manager for encrypting communications, a tracking application connected to the channel monitor for monitoring a position of the user, a learning manager in communication with the conversation manager for acquiring and modifying user attributes, wherein the learning manager is connected to an attributes database for storing the user attributes and a maturity monitor for ascertaining a degree of completeness of the user attributes, a recipe database connected to the learning manager for storing at least one recipe comprising information to support the acquisition of a product or service, a recipe workflow application connected to the recipe database for creating the at least one recipe,
  • the product and supplier identification data indicates a product and service relevance for each product and service based on the user attributes and the relevance of the at least one recipe is a sum of the product and service relevance of each product and service associated with the at least one recipe.
  • the system further comprises a statistical information application in communication with databases to gather statistical information related to future intentions, wherein the statistical information application is connected to a database to store the gathered statistical information, and a demand pull application in communication with the statistical information application to facilitate dissemination of the gathered statistical information to suppliers in a supply chain, wherein the demand pull application is connected to a demand pull definition database to store information relating to the supply chain.
  • a system for facilitating use of a network comprises a server, a channel monitor to control a plurality of communication channels between a user and the server, a conversation manager, in communication with the channel monitor, to monitor communications between the user and the system, wherein outgoing dialogue is formatted appropriately to each communication channel and incoming dialogue is interpreted, a learning manager in communication with the conversation manager for acquiring and modifying user attributes, a recipe database to store at least one recipe comprising information to support the acquisition of a product or service, an inquiry application to accept a request for a product or service from the user, wherein the inquiry application is connected to an inquiry database for storing unfulfilled inquiries, a response processor to present user requests to suppliers and to receive and filter offers from the suppliers based on the user attributes, wherein the response processor is in communication with at least one database containing potential responses to the requests and to a commerce engine to process transactions between the suppliers and the user, and a product and service database to store product and supplier identification data, wherein the product and
  • the system further comprises a presentation application to format the dialogue, an attribute database to store the user attributes, and a maturity monitor to ascertain a degree of completeness of the user attributes.
  • the system further comprises a recipe workflow application to create the at least one recipe, a recipe maturity monitor to ascertain a degree of completion of the at least one recipe, and a recipe relevance application to determine a relevance of the at least one recipe to the user.
  • the system further comprises an encryption application in communication with the conversation manager for encrypting communications, and a tracking application connected to the channel monitor to monitor a position of the user.
  • a system for communicating on a network comprises a learning manager to gather information from a source that conveys future intention, and a host server disseminating information derived from the gathered information throughout a supply chain, based on an aggregation of the gathered information and a probability of completion of the future intention.
  • a method of creating a market comprises providing users to create corresponding profiles, providing suppliers to meet the requests of the users based on the profiles, and managing the requests of the users to facilitate transactions between users and suppliers.
  • the method further comprises receiving a request from at least one of the users, processing the request based on the user profiles and presenting the processed request to at least one supplier, and performing a transaction between the at least one supplier and the at least one user to fulfill the request.
  • the processing further comprises managing the request based on the corresponding user profile, prior to reaching the at least one supplier, to target appropriate suppliers.
  • the method further comprises gathering data from the profiles, aggregating the data for a large number of users, analyzing the aggregated data to derive statistical information, storing the derived statistical information, and presenting the derived statistical information to suppliers and users.
  • a method of creating a market place to facilitate transactions comprises creating user profiles, providing suppliers to meet user requests based on the profiles, and managing the user requests to match the suppliers with users.
  • the managing comprises correlating the user requests with corresponding user profiles in order to determine the desires of a user, such that the correlated user requests and user profiles define the desires and the suppliers and users are matched accordingly.
  • a method to facilitate transactions over a network comprises creating a virtual representation of a user, gathering information from the user that conveys future intention, managing the virtual representation to perform transactions over the network on behalf of the user based on at least the future intention, and disseminating information derived from the gathered information throughout a supply chain, based on an aggregation of the gathered information and probability of completion of the future intention.
  • the method further comprises collecting information from the user that conveys personal information representative of the user, and disseminating information derived from the gathered information and the collected information, based on the aggregation of the gathered information and the collected information.
  • FIG. 1 A shows a schematic of the system architecture of the system of the present invention.
  • FIG. IB shows the correspondence between an exemplary RealMe and CyberMe according to the present invention.
  • FIG. 2 A shows a functional overview of the system of the present invention.
  • FIG. 2B shows an exemplary diagram of a layer of the system of FIG. 2 A.
  • FIG. 2C shows an exemplary set of externally administered information sources with which the External Interface Manager of FIG. 2B may be in communication.
  • FIG. 2D shows an exemplary diagram of a layer of the system of FIG. 2 A.
  • FIG. 2E shows an exemplary diagram of a layer of the system of FIG. 2 A.
  • FIG. 2F shows an exemplary diagram of a layer of the system of FIG. 2 A.
  • FIG. 2G shows an exemplary diagram of a layer of the system of FIG. 2 A.
  • FIG. 2H shows an exemplary diagram of a layer of the, system of FIG. 2 A.
  • FIG. 21 shows an exemplary diagram of a layer of the system of FIG. 2 A.
  • FIG. 2 J shows a schematic of an exemplary planned journey.
  • FIG. 2K shows a schematic of an exemplary MicroCosm tunnel for one stage of a planned journey.
  • FIG. 2L shows a functional overview of the components of the universal system of the present invention which are replicated on a local level in an exemplary MicroCosm.
  • FIG. 3 shows an exemplary process whereby the Movement Assimilation feature of the present invention is activated.
  • FIG. 4 shows an exemplary interaction session between RealMe and the system of the present invention.
  • FIG. 5A shows an exemplary process whereby a new RealMe logs in to the system of the present invention.
  • FIG. 5B shows exemplary processes whereby a new RealMe may establish various preferences for interacting with the system of the present invention.
  • FIG. 5C shows an exemplary process whereby a previously registered RealMe logs in to the system of the present invention.
  • FIG. 6A shows an exemplary process whereby the system of the present invention solicits RealMe's current feelings.
  • FIG. 6B shows an exemplary process whereby the system of the present invention solicits RealMe's current focus.
  • FIG. 7 shows an exemplary process whereby RealMe submits a new request to the system of the present invention.
  • FIG. 8 shows a schematic of an exemplary theoretical framework incorporated into the functioning of the Learning Manager of FIG. 2E.
  • FIG. 9A shows an exemplary process whereby a focused or open learning session in initiated.
  • FIG. 9B shows an exemplary process whereby a focused or open learning session in completed.
  • FIG. 10 shows an exemplary process whereby the system of the present invention determines the products or services requested by a RealMe, completes associated recipes, and creates a list of potential suppliers.
  • FIG. 11 A shows an exemplary process whereby the system of the present invention acquires immediate responses to RealMe requests.
  • FIG. 11B shows an exemplary process whereby the system of the present invention prepares and submits to potential suppliers dynamic requests corresponding to RealMe requests.
  • FIG. 11C shows an exemplary process whereby the system of the present invention acquires and processes supplier responses to dynamic requests.
  • FIG. 12A shows an exemplary process whereby the system of the present invention gathers and prioritizes available responses to RealMe requests.
  • FIG. 12B shows an exemplary process whereby the system of the present invention submits responses gathered in FIG. 12A to RealMe for possible action.
  • FIG. 13 shows an exemplary process whereby the system of the present invention solicits feedback from RealMe regarding supplier performance.
  • FIG. 14 A shows an exemplary process whereby the Movement Assimilation feature of the present invention may be invoked to assist RealMe in optimizing a route.
  • FIG. 14B shows an exemplary process whereby the Movement Assimilation feature of the present invention assists RealMe in optimizing a route.
  • the system and method of the present invention combines novel consumer to business (C2B) and business to business (B2B) methods in an integrated consumer to business to business (hereinafter “C2B 2 ”) system to overcome many of the problems inherent in today's business to consumer business environment as facilitated by the Internet and through other electronic media.
  • C2B 2 integrated consumer to business to business
  • the present invention provides an artificial intelligence based processor, hereinafter “Learning Manager”, to allow a user, hereinafter “RealMeTM”, to create and update a virtual representation, hereinafter “CyberMeTM”, which corresponds uniquely to the user.
  • a user is an individual, for example a person or business entity, who may wish to execute transactions over a distributed network, where the individual creates a virtual representation (CyberMe) of himself, herself, or itself.
  • RealMe shall be referred to hereinafter as "he or she”, “him or her”, etc., it is to be understood that RealMe may be a business entity, for example a small to medium enterprise or multinational corporation.
  • a user may be a consumer or supplier.
  • FIG. IB The correspondence between an exemplary RealMe 95 and CyberMe 96 pair is shown in FIG. IB, where "x" denotes a portrait of a real user (RealMe) 95 and "y” denotes a virtual image, for example a computer-generated image, of CyberMe 96.
  • "x" denotes a portrait of a real user (RealMe) 95
  • "y" denotes a virtual image, for example a computer-generated image, of CyberMe 96.
  • a real user may have multiple corresponding CyberMes 96.
  • CyberMe serves as an interface between RealMe and other aspects of the C2B system and represents RealMe in transactions facilitated and/or carried out by the system.
  • Each CyberMe is based on a personalized set of data, attributes 231, which describe RealMe, including data relating to, for example: identity and appearance, e.g. name, age, date and place of birth, nationality, physical attributes, preferred virtual image, etc.; environment, e.g. physical address(es) (domicile), virtual address(es) (e.g. internet address, mobile telephone number, etc.), work site location, etc.; employment details, for example occupation, position, salary, etc.; relationships, e.g. marital status, details regarding family members and friends (which may serve as links to the attributes of family and friends), etc.; services used, for example electricity, gas, and telephone service providers, etc.; things
  • RealMe needs, e.g. major anticipated purchases or new services, etc; possessions, for example automobile, house or apartment, appliances, clothes, etc.; how RealMe manages money, e.g. credit card accounts, bank accounts, mortgage, financial instruments, etc.; interaction preferences, for example communication style, team working style, etc.; Internet preferences, e.g. web sites visited by RealMe, time spent at each site, areas of interest, etc.; hobbies and tastes, for example favorite beverages, fashion preferences, sports events typically watched or attended, favorite vacation destinations, favorite color, etc.; and current communication channel(s) in use or preferred by RealMe, e.g. Wireless Application Protocol (WAP)- enabled mobile phone or PDA, personal computer (PC), pager, interactive digital television, and game stations.
  • WAP Wireless Application Protocol
  • the C2B process of the present invention empowers RealMe to define his or her requirements and seek a response directly back from suppliers who have an interest in meeting those requirements. Responses are filtered based on relevance to RealMe's known preferences and dislikes, as defined by RealMe's attributes. RealMe is guided through a workflow which provides CyberMe with sufficient information to present a detailed request to suppliers and simultaneously nurtures CyberMe by augmenting the number of attributes which define and give depth to RealMe's virtual counterpart.
  • a request is an explicit statement on the part of RealMe of current or future intent to purchase a product or service or of need for information.
  • the terms “request”, “requirement”, “wish” and “demand” as used herein may be considered synonymous.
  • a desire, as used herein, may be an explicit or implicit statement of RealMe's preferences, likes, and/or needs, where an implicit statement is based on RealMe's Icnown characteristics as communicated to CyberMe, or derived therefrom by the C2B 2 system of the present invention.
  • CyberMe represents RealMe in a number of network- based activities.
  • CyberMe undertakes tasks on behalf of RealMe, for example gathering information or interest to RealMe or finding products and services desired immediately or within a time period specified by RealMe, whether a definite or merely probable or possible requirement.
  • RealMe may be interested, for example, in learning how his financial portfolio, insurance coverage, etc. compares to that of other RealMes.
  • CyberMe also receives prospective offers for products and services from potential suppliers, filtering those offers according to the expressed wants and needs of
  • RealMe as specified by RealMe's attributes.
  • the system of the invention filters offers for products and services which are pertinent to RealMe, presents those offers in the format, at the time, and in the medium that RealMe wants to receive them.
  • RealMe can choose to accept an offer from a supplier and conduct the transaction to obtain the good or service in question.
  • the requests of a number of RealMes for the same product or service may be aggregated so as to obtain a volume price for the group.
  • RealMes and suppliers may also participate in other forms of transactions, including reverse auctions and brokered agreements.
  • the system facilitates highly targeted advertising by certified suppliers.
  • the invention also permits tracking of the location of RealMes, allowing them to receive constantly updated location- and time-specific information regarding their environment and any transactions they might wish to make in that environment.
  • the C2B system supports simultaneous interaction of a plurality of users with the system.
  • advantages and capabilities afforded by the system are the following: simplification of Internet transactions to save time; aggregation of requests for a good or service to lower cost to the consumer; facilitation of access to the best available discount on commonly used services; provision of a single place for users to store data that can be accessed at any time and any place via the Internet; aid to managing financial health; allows benchmarking among peers; allows anonymous or named contact with suppliers; helps others communicate with RealMe in a manner RealMe likes; enables virtual fitting of clothes; enables sharing of wish list with family, etc.; and allows sharing of information with other CyberMes.
  • An object of the B2B aspect of the C2B 2 system and method of the invention is to service the supply chain of products and services, from retailers to wholesalers and distributors to manufacturers to component and raw material suppliers.
  • Prior art business to business methods have been limited in their effectiveness due to their inability to accurately predict future needs for products and services and also by inherent delays in transmitting orders for component parts sequentially down the supply chain.
  • the business to business method of the present invention gathers and presents simultaneously to all suppliers in the supply chain information regarding actual and/or potential consumer desires and intended and/or potential purchases as derived from the attributes of a large number of RealMes. In this way, the present invention overcomes this critical inadequacy of the prior art.
  • a certain number of residents of a given geographical region may indicate through their attributes an interest in purchasing an automobile in the next three months.
  • the system of the invention periodically extracts from the attributes, inquiry, and request databases of individual RealMes information relating to this intended purchase, among others, and places this information anonymously in a database. This information is then used to prepare standardized reports regarding demand for specified products and services. Suppliers are also given access to the database through a browser which allows them to mine the database for information of particular interest to them.
  • a demand pull engine in cooperation with a demand pull definition database permits data representing future demand to be transmitted to all levels of the supply chain, for example to a registered retailer, the retailer's suppliers, the suppliers' component suppliers, etc. etc.
  • the method of the present invention assists companies in the supply chain to better understand and anticipate demand; aids smaller to medium sized enterprises to participate in a market with lower cost entry barriers, and hence enhances choice to the consumer; and permits rich data mining on changing anonymous consumer preferences and tastes in order to aid product and service development.
  • the present invention permits the creation of a market wherein users and suppliers are matched based on users' characteristics and requirements as expressed through each user's virtual representation, created and updated by the user, and information by suppliers to the C2B 2 system of the present invention.
  • Users are provided to the market through the fact of each users' creating and maintaining their virtual representation.
  • Suppliers are provided to the market through the registration of suppliers with the C2B system of the present invention.
  • the C2B 2 system operates to provide suppliers matched to the users and vice versa within the market so created.
  • FIG. 1A Shown in FIG. 1A is a schematic of a preferred embodiment of the system architecture of the C2B 2 system of the present invention.
  • the system is comprised of three tiers of servers. At the lowest tier are two database servers 10, which may be, for example,
  • the database servers 10 support structured database management.
  • the database servers 10 are connected to the four application servers 20 of the middle tier.
  • the application servers may be, for example, Sun Enterprise 420R Workgroup Servers with a Solaris 2.7 operating system, and associated storage elements (not shown).
  • the application servers support 20 the various applications of the present invention as described below.
  • the application servers 20 are connected to the eight http servers 30 of the highest tier.
  • the http servers 30 may be, for example, Sun Enterprise 220R Workgroup Servers with a Solaris 2.7 operating system, and associated storage elements (not shown).
  • the http servers 30 support communication with individual electronic devices including personal and laptop computers 50, interactive Digital Television 60, mobile phones 70, personal digital assistants 80, pagers 90, etc., over a variety of network connections 40, including Internet, electronic mail, WAP (for mobile phones and PDAs), SMS, etc.
  • the individual electronic devices may be operated by a RealMe 95 and or a supplier 98.
  • the system supports all currently operable communication standards and languages, including SMTP, IMAP4, POP3; SMB, FTP; HTTP; WAP, GPRS, SMS; XML, WML; Java (JDBC, JSQL, JSP, EJB, CORBA, Servlets); TCP/IP; SSL, Encryption; and MAPI, DCOM, CGI.
  • FIG. 2 A shows a functional overview of the C2B 2 system 100 of the present invention.
  • the system may be broken down conveniently into seven layers, with each layer performing a group of functions within the system.
  • Layer 110 is the foundation upon which the entire system is built. This layer 110 assures the integrity and security of the C2B system and the interface between the C2B system and individual RealMes 95. All interactions between RealMes 95 and the system involve this layer 110 (or a replication of all or a portion of this layer on a local level, in the context of certain MicroCosms 286, as described below).
  • Layer 120 identifies and supports RealMe 95 requirements at a given time, and provides status information, both at a headline level and on work-in-progress.
  • Layer 130 acquires, stores and processes RealMe 95 attributes in order to form and nurture CyberMe.
  • Layer 140 defines and obtains from RealMe 95 the data and information that is necessary to service the requirements and desires of RealMe and secures and filters responses from suppliers to meet those requirements.
  • Layer 150 completes and stores commercial transactions and supports a full range of commercial processes.
  • Layer 160 carries out aggregation and presentation of meta data (statistical data) gathered anonymously from the attributes of a large number of RealMes 95, and the dissemination of consumer demand data down the supply chain.
  • Layer 170 supports the provision of location-specific responses to RealMe 95 requirements and current preferences.
  • Layers 110-150 form the core of the C2B system of the invention but also includes certain elements of the B2B system as well.
  • Layer 160 forms the core of the B2B system of the invention while including certain elements of the C2B system
  • Layer 170 is a MicroCosmTM or smaller-scale version the system represented by Layers 110-160, applying the functionality of the first six layers to the subset of situations in which the needs and requirements of RealMe are location-specific, or in which responses to the needs and requirements have been requested from a specified group of product/service providers that are affiliated in some declared way (e.g. an association of nationwide discount warehouses).
  • Full integration of layers 110-170 into a cohesive whole as described herein results in an integrated C2B 2 system which overcomes the inadequacies of the prior art.
  • the individual layers and their components will now be described in detail. The functionality of the various layers will also be described in the context of various examples provided hereinafter.
  • Layer 110 shown in FIG. 2B, comprises the Human-to-Network Interface 200 (HNI), Conversation Management 202 (CM), Presentation 204 (P), Movement Assimilation 208 (MA), External Interface Manager 210 (EJ ), and Security and Controls Manager 206 applications.
  • the HNI application 200 is resident on the servers 20 which manages the physical communications interface between a RealMe and his or her CyberMe. (Unless specifically noted otherwise, each application described hereinafter should be understood to be resident on the application servers 20.)
  • HNI 200 supports two- way interaction between RealMe and CyberMe over a variety of available channels, for example Internet, WAP-enabled mobile phone or PDA, SMS messaging, interactive TV, and electronic mail. It supports communication over more than one channel simultaneously (e.g.
  • RealMe may advise RealMe to access the Internet channel through a PC, to access more complete information, e.g. the web sites of suppliers for the item in question.
  • the HNI assesses channel availability and strength at any given location of RealMe 95 (as supplied by Movement Assimilation 208) and accordingly makes recommendations on channel suitability to RealMe 95. If a channel fails unexpectedly (e.g. mobile phone goes out of range), the HNI may attempt to reconnect over the failed channel. If reconnection is not achieved within a reasonable time frame, it will try another channel. If successful in securing another channel, then it informs the CM 202 and P 204 accordingly.
  • the 200 HNI monitors the performance levels of each of the current channels being used by RealMe 95, and passes the performance level information on to P 204 and CM 202.
  • RealMe can input information in any appropriate format over any open channel, for example typing text on the Internet channel through a PC, for example, or speaking via mobile phone to a voice recognition processor.
  • the Conversation Manager (CM) 202 is an application which enables and manages conversations between RealMe and CyberMe and maintains the integrity of those conversations.
  • CM 202 can determine the difference between responses or inputs related to in progress inquiries and a totally new line of inquiry or context change. New lines of inquiry or context changes are passed on to the RealMe Inquiry Processor 220 for interpretation.
  • CM 202 monitors the state of ongoing conversations and, in the case of unexpected channel failure in the middle of a conversation, it attempts to resurrect the in-progress dialogue exactly at the stage it was interrupted once a channel is recovered by the HNI 200.
  • CM 202 supports multi-channel conversations (simultaneous conversations over more than one channel), and thus when outputting a conversation item from CyberMe to RealMe specifies to the HNI 200 and Presentation 204 applications which channel is to be used. For example, complex graphics may be sent over the Internet channel rather than over the WAP-enabled mobile phone channel with its more limited bandwidth (until such time as technological advances increase the latter channel's bandwidth sufficiently to support complex feature-rich graphics).
  • CM 202 monitors the data which has been communicated between RealMe and
  • CyberMe over each channel and maintains synchronization of data among the various channels. For example, if RealMe has responded to a question from CyberMe on one channel, that information is used in subsequent communication on all channels; CyberMe does not make another request for the same information over a different channel.
  • CM 202 is able to understand the context of the current conversation and enrich the conversation by presenting related facts of interest (e.g. if RealMe wants car insurance, then a statistic on the number of car accidents in RealMe's locality over the last year may be presented).
  • the system 100 of the present invention uses fuzzy logic and pattern matching techniques to interpret language from RealMe and respond accordingly.
  • Fuzzy logic is a superset of conventional (Boolean) logic that has been extended to handle the concept of partial truth - truth values between "completely true” and “completely false”. (Fuzzy logic was introduced by Dr. Lotfi Zadeh of the University of California at Berkeley in the 1960's as a means to model the uncertainty of natural language.
  • Fuzzy logic has been adapted by the Information Technology industry as an approach to computing based on "degrees of truth” rather than the usual “true or false” (1 or 0) Boolean logic on which the modern computer is based.) Natural language is not easily translated into the absolute terms of 0 and 1, and so fuzzy logic techniques are particularly adept at analyzing and interpreting natural language. Fuzzy logic includes 0 and 1 as extreme cases of truth (or “the state of matters” or “fact”) but also includes the various states of truth in between so that, for example, the result of a comparison between two things could be not “tall” or “short” but “.38 of tallness.” Fuzzy logic seems to be close to the way the human brain functions (e.g.
  • Pattern matching is the process of searching for patterns which match each other wherein one pattern is provided by one source (e.g. RealMe) and the other by another source (e.g. CyberMe).
  • Such patterns can include the sequencing of key words in a natural language sentence.
  • fuzzy logic By combining fuzzy logic with pattern recognition (fuzzy pattern recognition) the present invention seeks to compare RealMe natural language input with language patterns held in the system in order to derive meaning and relevance. Though a relatively new science, the methods are known to people familiar in the art. The present invention incorporates the capabilities of some aspects of fuzzy pattern recognition functionality to support language interpretation as provided by third party applications such as AutonomyTM and NCORPTM (both based in Cambridge, England).
  • CM 202 monitors the duration of each interaction session between RealMe and CyberMe and stores total session time in the Attributes database 230. CM 202 also monitors a "rate of RealMe interaction", a measure of the responsiveness of RealMe during the session, for example, the number of learning questions, such as those listed above, to which RealMe responds in a given amount of time. The point of termination of a session as well as the thread of questions is recorded by CM 202 to enable the session to resume at a later time at the point of termination without repetition of questions previously answered by RealMe.
  • the Presentation application (P) 204 receives infonnation from CM 202 intended for RealMe and formats the information before passing it on to HNI 200 for communication to RealMe. P 204 also presents inbound information from RealMe to CM 202, as well as outbound information from CM 202 to RealMe. All interactions between CyberMe and RealMe are undertaken through P 204. P 204 is sensitive to the constraints and requirements of the different HNI 200 channels, and also the interaction preferences of RealMe. For example, messages to be displayed on PDAs or mobile phones may be brief instructions, while information displayed on RealMe's PC may be multimedia presentations including, for example, graphics (text), video and sound.
  • P 204 will aim to enrich presentation, e.g. by using multimedia features, as much as possible without impacting channel performance. If CM 202 does not specify a channel for a conversation item, and more than one channel is open, then P 204 selects the channel according to information format and current channel performance. For inbound communication from RealMe to CyberMe, P 204 converts input into a standard text format which can then be interpreted by CM 202. For example, it would convert voice input to text input through the use of a voice recognition processor, before passing on the text to CM 202 for interpretation.
  • the Movement Assimilation application (MA) 208 monitors and logs RealMe's physical location, in order to allow CyberMe to offer journey 284 and/or location-related
  • MA 208 can receive position-indicative information from different sources and in different formats, but converts and stores such infonnation a standard format.
  • MA 208 may be turned on or off at will by RealMe. (Interaction between RealMe and his or her CyberMe is at all times at the option of RealMe, and RealMe may, at any point in a conversation with CyberMe, either terminate the conversation or decline to review the suggestions or options presented by CyberMe.)
  • FIG. 3 shows an exemplary process whereby RealMe registers for Movement Assimilation services, thereby activating MA 208.
  • RealMe requests Movement Assimilation (300).
  • RealMe selects and prioritizes MA sources, e.g. mobile phone cell triangulation, GPS service, or any other service (302).
  • polling mechanisms are initiated for Active channels (304), and listener mechanisms are initiated to support Passive channels (306).
  • the location of RealMe is stored as an attribute characterized as either slowly varying or quickly varying, as will be discussed in greater detail below in connection with the volatility of Attributes 230.
  • RealMe's location may be determined in a number of ways. RealMe may instruct CyberMe as to his or her location by inputting relevant information.
  • RealMe may enter a plain language comment such as, "At home today".
  • the RealMe Inquiry Processor 220 interprets the comment, identifying the key words as "home” and "today", and transmits this information to MA 208, which stores the information in Attributes 230.
  • MA 208 may rely on data from positioning services known in the art to ascertain the instantaneous position of RealMe and store this information in RealMe's attributes.
  • MA 208 may rely on a positioning service provided by cellular phone air time providers which identifies the location of a subscriber by comparing the signal propagation delay between the subscriber's mobile phone, pager, or WAP -enabled PDA and the transmitter in three neighboring transmission cells.
  • MA 208 may alternatively rely on information derived from a Global Positioning Satellite System receiver in RealMe's mobile phone, pager, or WAP PDA. Still other positioning means will be evident to those skilled in the art. Information regarding the position of RealMe will be used, in conjunction with information in RealMe's attributes and the Product and Services Universe database 255 to offer location-based services to RealMe. For example, a first RealMe may communicate to his CyberMe, using a plain language instruction (e.g. "Is John Doe, Yale class of 1987, in this shopping mall?") that he wishes to be notified if a second RealMe corresponding to the description RealMe has provided (e.g. name, address, occupation, university attended, etc.) is in the vicinity. If the second RealMe corresponding to the description RealMe has provided (e.g. name, address, occupation, university attended, etc.) is in the vicinity. If the second RealMe corresponding to the description RealMe has provided (e.g. name, address, occupation
  • RealMe is in the vicinity and has expressed a desire to his own CyberMe to know the location of the first RealMe, then each will be notified by his CyberMe of the location of the other.
  • the process whereby RealMes are placed into contact through their CyberMes is an example of a location-based service called CyberGroups, discussed in greater detail below in the context of MicroCosms 286.
  • the operation of MA 208 will be further discussed below in conjunction with Movement Assistance 284.
  • the External Interface Manager application (EIM) 210 controls all interfaces between the C2B 2 system and external third parties and sources of data.
  • EIM External Interface Manager application
  • EIM 210 manages transmission of XML purchase orders to a third party supplier, as well as interfacing with a source such as a BluetoothTM enabled weighting machine in RealMe's home that feeds weight data via, for example, RealMe's home-based PC into the attributes database 230 of the universal C2B 2 system 100.
  • ELM 210 also provides a cross-referencing facility against externally administered databases. Information entered by RealMe into his or her own attributes, for example academic qualifications or credit history, may be ratified by an independent third party database.
  • Ratified qualifications may carry more weight in the marketplace, for example with prospective respondents to attribute-based requests.
  • sources of information with which ELM 210 may be in communication are shown in FIG. 2C.
  • Such sources include, for example: Attribute Source 210a, for example a bank, which may supply information about RealMe which may be stored directly as attributes 231 in Attributes database 230 of Layer 130; Supplier 210b, for example a retailer; Ratification source 210c, for example a credit agency, which may provide validation of information stored in RealMe's attributes 231, in a manner described below; Supplier rating source 210d, for example consumer associations which monitor supplier performance; MicroCosms 286, discussed in connection with Layer 170; and Movement Assimilation information sources 21 Oe, for example tracking information provided by mobile phone service providers.
  • Attribute Source 210a for example a bank, which may supply information about RealMe which may be stored directly as attributes 231 in Attributes database 230 of Layer 130
  • Supplier 210b for example a retailer
  • Local databases 210j represents a set of local databases owned by a MicroCosm 286, for example Supplier Push 254', Brokered Responses 251', Dynamic Responses 252', Recipes 260', Product and Service Universe 255', Supplier
  • the Security and Controls Manager application 206 maintains the security and integrity of data and communications throughout the C2B 2 system. For example, when a RealMe connects to or touches base with, i.e. accesses or "logs in" to, his or her CyberMe, the Security and Controls Manager application 206 verifies the identity of RealMe through, for example, CyberMe tag (user name) and password verification; when RealMe logs in for the first time their attributes database is set up and initialized. Furthennore, all communications between a RealMe and his or her CyberMe are encrypted using encryption algorithms such as, for example, SSL.
  • encryption algorithms such as, for example, SSL.
  • FIG. 4 provides an outline of an exemplary sequence of events in a typical interaction session of a RealMe with the C2B system.
  • the HNI 200 detects the incoming RealMe on one of its incoming channels and invokes the CM 202 to set up a conversation session (400).
  • the CM 202 presents RealMe with the option (402) of either creating a CyberMe or touching base with his or her CyberMe if RealMe has previously registered and created a CyberMe. If the former option is chosen, the CyberMe creation sequence is invoked at 404; the CyberMe creation sequence is further described in FIG. 5A. If the latter option is chosen, a connection sequence, as described further in FIG. 5B, is invoked to connect RealMe with CyberMe (406), and CM 202 looks for any other active channels for RealMe. If other channels are active, CM 202 asks RealMe to choose between making the new channel part of a multi-channel dialogue or replacing the previously opened channel or channels by the new channel (407).
  • a RealMe feelings and focus session (described in FIGS. 6 A and 6B) is subsequently invoked at 408 in order to assess RealMe's current desires and priorities.
  • RealMe may end his or her interaction with CyberMe, thereby ending the session (418).
  • RealMe and/or third parties known to RealMe may engage in a number of activities including: teaching CyberMe about himself or herself (including preferences, feelings, focus, tastes, etc.) (409), telling CyberMe a new request (414), get responses to new request (416), view responses to inquiries and/or supplier advertisements selected based on information already provided by RealMe (as will be described in greater detail below) (410), select one or more responses (412) from those presented in 410 or 416, and receiving feedback on goods/services delivered to RealMe, for example promptness of delivery, quality of service, courteousness, satisfaction with product or service provided, etc. (417).
  • RealMe may end the session (418), interrupt the session or continue with the same exercise within the session.
  • CyberMe may present RealMe with the option of resuming the session at the point of interruption and/or allow RealMe to begin a new exercise.
  • CM 202 retains the thread of the conversation with RealMe up until the point of interruption and stores the thread and its point of interruption as an attribute 231 in the 1 st Person partition 235 of Attributes 230.
  • CyberMe may ask RealMe, via CM 202, if he or she wishes to resume the previous thread.
  • RealMe may be teaching CyberMe that he or she is interested in acquiring a product or service, e.g.
  • CM 202 when RealMe is interrupted, for example by a phone call, with the result that there is no interaction between RealMe and CyberMe for, say, several minutes.
  • CM 202 Upon resumption of the session by RealMe, CM 202 asks RealMe whether he or she would like to pick up where he or she left off in the auto insurance inquiry.
  • RealMe having heard during his phone call, for example, that his or her favorite musician is coming to town for one show only, tells CyberMe that he would prefer to get tickets for the musician's concert.
  • RealMe may then interact with CyberMe, for example, until the tickets have been purchased, and then terminate the session.
  • CM 202 retains the thread of the auto insurance inquiry and the point at which the inquiry was interrupted, so that upon subsequently touching base with his or her CyberMe, RealMe is reminded of the auto insurance query and asked if he or she wishes to resume that inquiry.
  • RealMe may select a response at 412.
  • the selection at 412 invokes a response selection process governed by the CyberMe Response
  • RealMe may choose to submit a request for a product or service at 414. Subsequently RealMe may either terminate the session at 418 or allow the system to attempt to obtain a response to the inquiry at 416 which is then presented to RealMe for consideration at 410. It is to be noted that RealMe is not required to be "on-line", that is interacting with CyberMe, in order for the C2B 2 system of the present invention to seek, obtain, and filter response to RealMe requests. Rather, the C2B 2 system of the present invention may begin processing RealMe requests immediately upon submittal by RealMe and continue processing these requests while RealMe is interacting with CyberMe concerning other matters and/or not in contact with CyberMe.
  • the system 100 presents to the incoming RealMe the option of creating a CyberMe or logging in if RealMe has previously registered at 402.
  • An exemplary sequence of events for the case where RealMe chooses the former option is shown in FIG. 5A, which shows an exemplary registration of a new RealMe.
  • the Security and Controls Manager 206 prompts CM 202 to ask RealMe, through P 204, to enter a user name, hereinafter "CyberMe tag", and password at 500.
  • the Security and Controls Manager 206 verifies that the CyberMe tag is unique, i.e. that it is not already assigned to another RealMe.
  • the Security and Controls Manager 206 also prompts RealMe to enter the password a second time for verification. Subsequently, the Security and Controls Manager 206 prompts RealMe to enter additional information such as security fields, e.g. mother's maiden name, RealMe's date of birth, address and postal code, memorable address, memorable date, place of birth, etc, at 502. In 502, the Security and Controls Manager 206 verifies that the security fields and data entered previously in 500 will describe a unique CyberMe, i.e. that no existing CyberMes have the same identification and security data. At this point, Security and Controls Manager 206 creates and initializes all CyberMe-specific databases (504), for example Recipe Maturity for all recipes is set to 0%, CyberMe maturity is set to 0%, etc.
  • Recipe Maturity for all recipes is set to 0%
  • CyberMe maturity is set to 0%, etc.
  • Security and Controls 206 may offer RealMe several different methods of authenticating himself or herself. Examples include the following:
  • RealMe 95 uses CyberMe 96
  • RealMe and CyberMe will "share" different experiences (e.g. RealMe uses CyberMe to purchase a ticket to a sporting event; RealMe uses CyberMe to find out how good his or her pension is compared to peers, etc). CyberMe can randomly select such events and question RealMe as to what he or she has done recently in order to verify his or her identity.
  • Mobile-phone key - this method is a bi-level method, only available to RealMes who use at least both their mobile phone and the Internet to access CyberMe.
  • the mobile phone is a personal, portable device whose use tends to be reserved for only one person (its owner); the owner keeps the device with him or her most of the time; the owner tends to report the loss, damage or theft of the device, if and when this occurs, to the relevant mobile phone service provider.
  • the loss of the mobile phone as a security control device can be detected and reported quickly.
  • the mobile phone provider could automatically inform Security and Controls 206 via ELM 210 of the universal C2B 2 system 100 such that the coreesponding channel is disabled, and RealMe is contacted directly in order to agree on security procedures while the mobile-phone key method is disabled.
  • Such devices tend to be password accessed themselves when powered up.
  • This method requires the user to log-in to touch base with CyberMe via the Internet, in which case security details are requested as described previously in 500.
  • CyberMe sends an SMS message to RealMe communicating a dynamic password, which RealMe must enter on the Internet channel within 60 seconds of receiving the SMS message.
  • the system 100 initiates a learning session, in which it presents RealMe with a number of opportunities for defining various fundamental RealMe preferences and provides the system with basic information regarding RealMe (506).
  • the system may present RealMe with channel options (e.g. Internet via PC, WAP-enabled mobile phone, etc.) and various interaction styles, e.g.
  • the system 100 will ask RealMe to select his or her preferences from among those presented, whereupon RealMe selects his or her prefereed channel(s) and interaction style (508).
  • the system 100 may present RealMe with an example of a three-dimensional (3D) image of a well-known and respected personality at 510, and ask RealMe if he or she would like to create a 3D image of himself or herself for personal use at 512. It is known in the art to create such a 3D digital image by manipulating digital photograph data for photographs taken at right angles to each other, for example front view and profile.
  • Such a 3D image may be used subsequently in a manner known in the art to simulate the "fit" or appearance of clothes on RealMe, thereby permitting RealMe to shop for clothing on the Internet in an effective manner.
  • a 3D image recipe is initiated (514) through the Recipe Workflow engine 263.
  • Recipe Workflow is discussed in detail below.
  • the system 100 may also present RealMe with a voice "tag line", i.e. an audibly spoken user name, recorded, for example, by a well-known and respected personality (516) and ask RealMe if he or she would like to create a customized voice tag line for personal use (518).
  • a voice tag line recipe is initiated through the Recipe Workflow engine 263 at 520.
  • the system 100 may also present RealMe with several images of well-known characters and personalities (522) and ask RealMe if he or she would like to convey his or her personality to his or her CyberMe so that CyberMe's personality will be a reflection of RealMe's (524).
  • a RealMe Personality Recipe is initiated through the Recipe Workflow engine 263 at 526.
  • the system may present to RealMe, in a manner well known in the art, an example of a 3D representation of a home of a well- known and respected personality (528), and ask RealMe if he or she would like to create a 3D image of his or her own home, including garden, cars, etc, as applicable at 530. If RealMe responds positively, a RealMe Home 3D image recipe is initiated through the Recipe Workflow engine 263 at 532.
  • CM 202 monitors the duration of each interaction session between RealMe and CyberMe as well as the rate of RealMe interaction. Based on how long RealMe has been interacting with CyberMe, or how much "work" RealMe has done (i.e. how many questions RealMe has answered), the system will periodically ask RealMe whether or not he or she would like to take a break or partake in a "diversion", for example a feelings and focus session such as that shown in FIGS. 6 A and 6B.
  • CM 202 stores session duration in the Attributes database 230 and also calculates and stores average session time for up to the last five sessions. Session duration and average session duration are calculated and stored separately for each channel.
  • RealMe Assistance in interacting with the system is provided to RealMe through the following mechanisms: fixed-content searchable help text screens of a type well known in the art; an expert system based on an artificial intelligence processor which interprets plain language queries from RealMe and provides information tailored to RealMe's query; discussion with a system service representative via telephone or video link; and visit to RealMe's home for discussion.
  • Help screens may be accessed at any time by RealMe and exist for all features of the system, while expert systems may be accessed for a predetermined number of system features. Help screens and expert systems may be accessed at any time. RealMe must request a discussion via telephone or video and must additionally make an appointment if a personal visit is desired.
  • FIG. 5C shows an exemplary log-in sequence for a previously registered RealMe.
  • Security and Controls Manager 206 application instructs CM 202 to ask RealMe to enter his or her CyberMe tag and password, and the Security and Controls Manager 206 verifies RealMe's password at 534.
  • Security and Controls Manager 206 then instructs CM 202 to request a random selection of security fields (as described above in FIG. 5 A) in random order at 536. For example, RealMe may be asked to enter his or her mother's maiden name on one occasion, social security number on another occasion, personal identification code on a third occasion, etc.
  • CM 202 retrieves from the History section 240 of the Attributes database 230 (discussed in connection with Layer 120) information regarding the integrity of, for example, the last five sessions on the current channel in order to verify that no connectivity problems have been experienced in recent interactions between RealMe and CyberMe (538). It is readily appreciated that more or less than five sessions may be used. In 538, if, for example, recent sessions have been very short (e.g. less than two minutes duration for the WAP-enabled mobile phone channel and less than five minutes duration for the Internet channel), then RealMe is asked if connectivity problems have occuned, and CM 202 responds with advice accordingly.
  • Layer 120 Personal Wealth/Inquiry Engine
  • Layer 120 comprises the Personal Wealth 215 application and associated modules, RealMe Inquiry Processor 220 and Memory 221, CyberMe Maturity application 222, and Low Integrity Detection application 223.
  • the Personal Wealth application 215 periodically assesses and conveys summary status infonnation to RealMe, making use of attributes stored in Attributes 230.
  • Such status information is presented under, for example, the following four headings: benchmarking 216, value extraction 217, liabilities 218, and assets 219.
  • Benchmarking 216 is a comparison, in subject areas selected by RealMe, of data in the Attributes 230 of a RealMe against anonymous peers.
  • the definition of RealMe's peers may be obtained explicitly from RealMe, as discussed below, or implicitly from attributes already stored by RealMe.
  • the benchmarking application 216 is highly flexible, covering all reasonable and meaningful benchmarks requested in any format, for example a plain language format: 'How well do I manage my money compared to other people of my age / profession"; "Am I fashionable”; "How healthy am I”.
  • Peer data may be derived from other RealMe attributes stored anonymously in the Meta Data database (see below) or obtained from external statistical databases, e.g.
  • actuarial databases which may be accessed through the ELM 210.
  • Value Extraction 217 which provides an indication to RealMe in response to requests of the total value realized through interaction with his or her CyberMe, in terms of money saved, improvement in quality of life, improvement in fitness and/or health, etc.
  • An assessment of total value may be achieved by analyzing attributes acquired over time and stored in Attributes 230 (see “History” 240 below).
  • Total value may also be derived by comparing RealMe attributes to data acquired from external databases through ELM 210, for example comparing weight loss against a database which indicates optimal weight for RealMe's age group.
  • Liabilities 218 provides a summary of RealMe's current liabilities, including, for example, financial (e.g. money owed to creditors), time-based (e.g. time pre-allocated to employers and/or others) and health-related (e.g. aspects of health and/or fitness that should be improved).
  • Assets 219 provides a summary of RealMe's cunent assets including, for example, financial (e.g. share portfolios and performance), time-based (e.g. leisure time and/or holidays booked) and health related data (e.g. a list of vital statistics that are above or at norm).
  • Queries may be submitted in a variety of formats, including plain language. Queries may be submitted in a variety of formats, including plain language. Queries are stored in the RealMe Inquiry Memory until they have been responded to successfully by CRP 250 and/or cancelled by RealMe.
  • RealMe inquiries are received by RIP 220 from CM 202 and may range in complexity from simple search engine queries, for example the plain language command, to statements implicitly requesting help, for example, "I am thinking of moving!, or "My furnace broke ! "My furnace broke ! is in fact an event, or incident, that RealMe is reporting to their CyberMe and RealMe is thereby implicitly requesting a response to the event.
  • RD? ' 220 is able to detect such reported 'events' and store them in the Attributes database for later retrieval.
  • RLP 220 might identify the following key words: “find”; “Thai”; “restaurant”; “near”; and "web site”.
  • the system of the present invention after interpreting the query, requests information from RealMe regarding what their main selection criteria will be regarding the request (e.g. save money; long wananty; reputable supplier; reputable product etc).
  • the selection criteria for a given request are stored in the conesponding record in RLM 221.
  • the system then generates coreesponding responses from the CyberMe Response Processor 250 which elicit more details from RealMe in an effort to guide him or her to desired information, such as rental or real estate agencies, moving services, moving insurance, etc.
  • RealMe may also be asked his or her level of interest in the information sought or purchase being contemplated as well as RealMe's estimated likelihood of making a purchase within a certain time period.
  • RealMe may be asked, for example, how likely RealMe is to move and when, and how likely RealMe's selection of a particular moving service may be.
  • the CyberMe Maturity & Health (CMH) application 222 provides RealMe with a measure of how well CyberMe has been defined and is a function of the number of attributes RealMe has defined about himself or herself, and how astutely RealMe is maintaining and updating his or her attributes.
  • CyberMe maturity increases as RealMe visits and interacts with CyberMe, thereby increasing the amount and breadth or range of coverage of personal preference information imparted to CyberMe and subsequently stored in Attributes 230.
  • CyberMe health increases each time RealMe touches base with CyberMe and updates time-varying or volatile attributes such as employer, hobbies, taste in music, etc., thereby keeping CyberMe cunent with respect to RealMe's preferences and personal details.
  • a purely graphical representation of CyberMe maturity might include a three-dimensional image of RealMe progressing from “baby” to "adult” to indicate richness of attributes, with an indication of "wellness” superimposed to indicate how well RealMe is keeping dynamic attributes up to date plus also an indication of "loneliness” to convey how often RealMe is "visiting" his or her CyberMe.
  • CyberMe maturity and health could be displayed through raw text, voice download (speaking text), music download (e.g. simple glockenspiel for immature CyberMe and full orchestra for mature CyberMe, with wellness indicated by how well (e.g. in tune) the musical excerpt is rendered, and loneliness indicated by the sadness of the music), etc.
  • the Low Integrity Detection application (LLD) 223 is responsible for detecting behaviors in RealMe's that are not in the interest of the perfect market environment that the system is seeking to create. Such behaviors would include, but are not limited to,: suppliers consistently and frequently masquerading as RealMe's in order to solicit responses from the market for products and services which they themselves sell, in order to reposition their own pricing tariffs, and bombarding the system with incredulous numbers of requests in order to handicap the system.
  • LID 223 Upon detecting low integrity users, LID 223 talks to the Security and Controls Manager 206 to log the incident, and depending on the severity of the low integrity activity and/or previous warnings submitted to the conesponding RealMe will request the Security and Controls Manager 206 to do one of the following: (a) talk to CM 202 to submit a warning to RealMe through P 204, or (b) disable the conesponding RealMe account.
  • FIG. 6A shows an exemplary flow for ascertaining RealMe's feelings.
  • FIG. 6B shows an exemplary flow for ascertaining RealMe's focus or priorities.
  • FIG. 6A an example of a recipe workflow (a sequence in which information is gathered to populate a recipe) for determining RealMe's cunent feelings
  • CM 202 through P 204, presents to RealMe .
  • images and/or text conveying examples of different feelings and moods, e.g. happy, excited, tired etc. (600), and asks RealMe if he or she would like to convey his or feelings at this stage (602).
  • CyberMe explains to RealMe that the purpose of the session is to educate CyberMe concerning RealMe and to obtain information allowing CyberMe to interact with RealMe in a manner which is sympathetic to RealMe's mood at this time.
  • RealMe if RealMe has previously completed a feelings session, the information provided by RealMe during the last session is retrieved from the Attributes database 230, and RealMe is asked if he or she wishes to update them. If RealMe responds affirmatively, then the CM 202 application, through the P 204 application, presents RealMe with a selection of icons and/or images which represent different moods and feelings (604). RealMe may select any combination of moods and feelings which are not mutually exclusive, e.g. the combination "happy and energetic" is permitted while the combination "sad and happy" is not. If RealMe responds negatively, RealMe's feelings are assumed to be neutral (606).
  • LM 225 then stores RealMe's cunent feelings in the Attributes database 230, assigning to the conesponding records a "best use by" date and time of no more than several hours hence, since generally an individual RealMe's feelings can change after a short period of time (608).
  • CM 202 presents to RealMe an illustrative selection of images and/or text conveying examples of different focus areas, e.g. save time, save money, have fun, learn about, etc. (610), and asks RealMe if he or she would like to convey his or her priorities at this stage (612).
  • RealMe has not previously completed a focus session, as determined by a check of the Attributes database 230, then CyberMe explains to RealMe that the purpose of the session is to educate CyberMe concerning RealMe and to obtain information allowing CyberMe to interact with (e.g. present supplier offers to) RealMe in a manner which is consistent with RealMe's priorities at this time.
  • the priorities provided by RealMe during the last session are retrieved from the Attributes database 230, and RealMe is asked if he or she wishes to update them.
  • RealMe responds to the query at 612 in the affirmative, then the CM 202 application, through the P 204 application, presents RealMe with a selection of icons and/or images which represent different focus areas (614).
  • RealMe may select more than one focus area and indicate relative prioritization, for example the primary objective may be to save/make money, and a secondary objective may be to save time, etc.
  • RealMe's priorities are assumed not to have changed (previously identified priority settings are retained) or, if RealMe is new, RealMe's priorities are assumed to be neutral (616). Regardless of whether RealMe updates RealMe's priorities, at 618 LM 225 stores RealMe's cunent priorities in the Attributes database 230, assigning to the conesponding records a "best use by" date and time of no more than several hours hence, since generally an individual RealMe's priorities can change after a short period of time.
  • RLP 220 retrieves any postponed inquiries which have become "active", the period of postponement having come to an end, and calls the CM 202 application to ask RealMe, through the P 204 application, to confirm reactivation of the inquiries at 620. If RealMe responds in the affirmative, the RLP 220 application marks the reactivated inquiries as "new" in RLM 221 at 622. Subsequently, or if RealMe responds in the negative, the CM 202 application asks RealMe what he or she would like to do next at 624, for example, suggesting options such as: submit a new wish (a need or desire), check responses to previous wishes, teach their CyberMe, etc.
  • the CM 202 application responds with an appropriate action, for example: gathering responses obtained by CyberMe in the background (while RealMe and CyberMe are interacting regarding some other subject) or during periods when RealMe is not interacting with CyberMe (626), as shown in FIGS. 12A and 12B; capturing a new RealMe wish 628, as shown in FIG. 7; and asking Learning Manager 225 to invoke an "open" learning session 630, as shown in FIG. 9 A.
  • an appropriate action for example: gathering responses obtained by CyberMe in the background (while RealMe and CyberMe are interacting regarding some other subject) or during periods when RealMe is not interacting with CyberMe (626), as shown in FIGS. 12A and 12B; capturing a new RealMe wish 628, as shown in FIG. 7; and asking Learning Manager 225 to invoke an "open" learning session 630, as shown in FIG. 9 A.
  • FIG. 7 shows an exemplary flow in which the CM 202 captures and interprets input from RealMe as being a request.
  • RealMe submits a request, for example, a plain language request "Fix my insurance", to the system 100 over the channel cunently in use at 700.
  • the request is received by P 204, converted into a text string by Presentation 204 and passed as 'raw' input to CM 202 for processing.
  • CM 202 uses intelligent pattern mapping provided by bespoke software in addition to commercially available language interpretation engines, such as AutonomyTM or Artificial LifeTM to identify the statement structure, extracts the key words from the raw text, and interprets them accordingly at 702. For example, “fix” is a verb in the imperative mood and so indicates urgency, "my” indicates pertinence to RealMe, and "insurance” is the product/service type or category.
  • the CM 202 captures and interprets input from RealMe as being a request.
  • RealMe submits a request, for example, a plain language request
  • 202 application having identified raw input, for example, as a request, then converts the raw input into a new request, which is in a structured form understood by CRP 250, described in FIG. 2F in connection with Layer 140, and stores it in RLM 221 at 704.
  • REP 220 then asks RealMe, through CM 202 and P 204, to provide information, if not already provided explicitly or implicitly as part of the raw input, regarding the probability of the purchase or other requirement (e.g. a need for information) and anticipated timeframe of the purchase or other requirement, which are stored with the new request at 706.
  • RLP 220 asks RealMe to prioritize his or her selection criteria, e.g., price, delivery date, warranty coverage, independent endorsements, etc. at 708. RLP 220 then calls CRP 250, which executes the resolve wish, gets attributes and shortlist suppliers functions, detailed below in FIG. 7 at 710. Through the CM 202 and P 204 applications, RLP 220 asks RealMe to confirm that CyberMe is to investigate any Demand Aggregation 250a or Reverse Auction 250b opportunities for the requested product/service at 712.
  • CRP 250 which executes the resolve wish
  • RealMe may indicate that Demand Aggregation 250a and/or Reverse Auction 250b should always be investigated, never be investigated, or investigated only after explicit assent has been given for each inquiry; this indication on the part of RealMe would be stored in Attributes 230 and checked by RD? 220.
  • a default mode may alternatively be set in which Demand Aggregation 250a and/or Reverse Auction 250b are always investigated. Subsequently, the system 100 will obtain at 714, and present responses at 716 to RealMe's request, as will be described in detail below and in FIGS. 12A and 12B.
  • Layer 130 shown in FIG. 2E, comprises the Learning Manager application 225, the Attributes database 230 and the Attributes Definition Directory 227.
  • the Attributes database 230 stores personal information, e.g. characteristics, preferences, identification data, etc. about RealMe, as well as personal information about other people known by RealMe.
  • the Attributes Definition Directory (ADD) 227 defines how personal information is stored in the Attributes database 230.
  • ADD 227 comprises Attribute Definition Records (ADRs) 228, each of which is a template, i.e. a definition, for a piece of information about RealMe or a person or other entity known to RealMe.
  • ADRs Attribute Definition Records
  • ADD 227 contains one ADR 228, for each discrete piece of information that can be stored as an attribute 231 in the Attributes database 230, although more than one attribute 231 can be based on the same ADR 228. This is expanded upon in the following text.
  • Each attribute 231 is directed to one of many different types of information about RealMe, including, for example:
  • Basic Details e.g. name, date of birth, place of birth, country or countries of citizenship, etc.
  • Communication channels e.g. mobile phone, e-mail address, pager address, etc.
  • Appearance e.g. 3-D image, digital photograph, caricature, etc.
  • Cunent mood e.g. happy, sad, tired, etc.
  • RealMe lives, stays, works, • Family - e.g. RealMe's marital status, number and names of children, their birthdays, their likes and dislikes, etc.
  • Personal Inventory e.g. car, TV, refrigerator, satellite, mobile phone, PC, game station, four-poster bed, etc. • Personality traits - e.g. gregarious, caring, natural leader, etc.
  • RealMe has with others e.g. friends, dentist, doctor, attorney, etc.
  • Medical infonnation e.g. medical records, fitness levels, vaccinations, cholesterol level, etc.
  • Services RealMe uses - e.g. gas, electricity, telecommunication service providers, water suppliers, etc.
  • Financial information e.g. account details, bank balance, credit history, salary, mortgage details
  • Dislikes - e.g. noisy people, loud shirts, seventies fashion, cold weather
  • Each attribute 231 represents a discrete piece of information concerning RealMe or concerning a person or other entity known to RealMe. However, attributes 231 are not created in the Attributes database 230 until populated with information as a result of RealMe's interaction with the system 100 by the various methods described herein.
  • the Attributes database 230 of the universal system 100 may be sectioned into a number of partitions 232, for example 1 st person 235 and 3 rd person 236, peer definition
  • non-standard personal information 23 non-standard personal information 238, movement assimilation data 239, and history
  • Attributes held in different partitions 232 can be accessed simultaneously by the Learning Manager 225.
  • Attributes 231 stored in 1 st person 235 are those entered by RealMe 95 and/or implicitly derived by Learning Manager 225 and/or received from an external data source through ELM 210 and which concern RealMe's own personal characteristics.
  • Attributes 231 stored in 3 rd person 236 are personal characteristics entered by RealMe and/or received from an external data source through ELM 210 about- other people he or she knows (e.g. friends and family). If an attribute 231 contains information about a 3 rd Person, then RealMe is requested to identify the relationship of the attribute holder to RealMe (e.g. mother, father, child, spouse, friend, colleague, etc.).
  • CM 202 may determine from the context of the interaction between CyberMe 96 and RealMe 95 that the populated attribute should be stored in either 1 st person 235 or 3 rd person 236, as appropriate, and subsequently ask RealMe for confirmation thereof.
  • Data from attributes 231 in 3 rd person 236 may be used along with attributes 231 in 1 st person 235 to provide relevant information to RealMe 95.
  • RealMe 95 For example, if on the one hand RealMe is married and has indicated in an attribute 231 that his wedding anniversary is on a certain date, and on the other hand has indicated that his wife's preference in gifts tends toward flowers and art work, then CyberMe 96 may prompt RealMe 95 as the anniversary date approaches with, for example advertisements, deals, etc. regarding florists and art dealers, filtered and sorted according to the attributes 231 stored in 3 rd person 236 describing RealMe's wife. Advertisements regarding jewelry and clothes, in this example, would not be shown to RealMe as a result of his anniversary date approaching, because a preference for jewelry and clothes was not part of RealMe's rendering of his wife.
  • the attributes 231 that RealMe can populate and store about themselves or others comprise a default set of pre-defined global attributes within the universal C2B 2 system 100; however, the system 100 is designed to be flexible such that RealMe 95 can define new attributes not in the default set. For example, if RealMe is a keen ornithologist, he or she could define a new, local attribute to hold the rarest species of bird that he or she has spotted to date.
  • MetaEngine 275 (described in greater detail in connection with Layer 160) analyses all of the local attributes set up by all RealMes, and, if it concludes that the same or very similar local attributes are being set up by multiple RealMe's to the extent that a certain level of interest has been attained (e.g. > 5% of the population want to store their golf handicap), then the local attribute may be converted to a global attribute and stored as part of the default set or pre-defined global attributes.
  • Each attribute 231 has a conesponding data record 228 in the Attributes Definition
  • Directory 227 comprising a plurality of data fields, including for example: unique attribute id 228a; description 228b; request conversation pieces 228c; presentation conversation pieces 228d; confirmation conversation pieces 228e; data type 228f; value range type 228g; value range 228h; set of links to multimedia aids 228i; date and time stamp 228j;; characteristics 228k-228p; relationships with other attributes 228q; and associated keywords 228r.
  • unique attribute id 228a including for example: unique attribute id 228a; description 228b; request conversation pieces 228c; presentation conversation pieces 228d; confirmation conversation pieces 228e; data type 228f; value range type 228g; value range 228h; set of links to multimedia aids 228i; date and time stamp 228j;; characteristics 228k-228p; relationships with other attributes 228q; and associated keywords 228r.
  • Unique Attribute ID 228a is a unique identification code used to identify and access the conesponding attribute 231.
  • Description 228b is text which describes the purpose or function of the attribute definition (e.g. "favorite color”)
  • Request Conversation Pieces 228c are discrete instructions to enable CM 202 to request from RealMe the information required to create the attribute 231 (as described in connection with conversation pieces and CM 202).
  • Presentation Conversation Pieces 228d are discrete instructions to enable CM 202 to present the information stored in the conesponding attribute 231 to RealMe.
  • Confirmation Conversation Pieces 228e are discrete instructions to enable CM 202 to confirm with RealMe the infonnation stored in the conesponding attribute 231 to RealMe.
  • Data Type 228f is the type of data being stored e.g. text string up to 256 characters; numeric, to two decimal places; date DDMMYYYY; custom (according to value range and type, as described below), Boolean (true, false) etc.
  • Value range type 228g can take one of three values: analogue; standard discrete; defined discrete:
  • the value range type is analogue
  • the value range is a continuous range.
  • the continuous range must be consistent with the data type 228f and can be described using generic terms e.g. "positive” is a valid analogue value range for numeric data types but not for date data types, and "between 1/1/2000 and 31/12/2000" is a valid analogue value range for date data types but not for numeric data types.
  • the value range type is discrete, the value range is restricted to one of a defined contiguous set of sub-ranges.
  • Standard discrete value ranges additionally must not exceed the maximum number of permitted sub-ranges, as defined by a conesponding overall system parameter within the universal C2B 2 System. Taking an example where a maximum of 5 sub-ranges is permitted, the standard discrete value range could comprise between 1 and 5 sub ranges. Thus the attributes with a standard discrete value range type could not take on more than one of five different sub-range values.
  • value ranges that would meet this requirement are ⁇ on, off ⁇ (which constitute 2 contiguous subranges in the overall range), ⁇ "cold", “cool”, “tepid”, “warm”, “hot” ⁇ (which constitute 5 contiguous subranges in the overall range), or ⁇ "not at all", “sometimes", “always” ⁇ (which constitute 3 contiguous subranges in the overall range).
  • Another condition is that if fewer than the maximum number of subranges are used then they must be mapped onto the maximum number of ranges (this is important because, as discussed below, it allows maximum flexibility in permitting linked attributes to take on implicit values based on the conesponding value range of another attribute).
  • the value range must be an explicitly defined set of possible values, which do not have to adhere to the standard discrete template or be a contiguous range.
  • the associated defined discrete value range might be ⁇ Donald Duck; Mickey Mouse; Tom; Jerry; Droopy; Penelope Pitstop; Bart Simpson etc ⁇ .
  • Multimedia Aids 228i relevant to discrete value ranges, are links to multimedia illustrations of the values that RealMe 95 can select, to inform his or her decision making process, and/or to make presentation of the attribute value to RealMe more interesting.
  • Such links may for example include picture files (e.g. .GIF or JPG files), sound files (e.g. .WAV), video (e.g. .AVI or MPG files), etc.
  • picture files e.g. .GIF or JPG files
  • sound files e.g. .WAV
  • video e.g. .AVI or MPG files
  • a link to .GIF picture files showing waving flags; the respective colors may be used.
  • a plurality of .WAV files may be used to respectively illustrate music being played smoothly and roughly.
  • Date and time stamp 228j is the date and time of the last update of the ADR 228.
  • the term "characteristics" as used herein defines a collection of fields which hold additional information about the information that is associated with an Attribute Definition Record 228.
  • the characteristics include fields 228k-228r as defined below:
  • the Global/Local 228k characteristic indicates whether the attribute definition record 228 has been created by the universal system 100 (global) or has been created by RealMe (local), as described above.
  • Volatility 2281 suggests the propensity to change or frequency of change of the information in the conesponding attribute 231.
  • a spectrum of volatility is taken into account, ranging for example from static (e.g. date of birth) through slow (e.g. what RealMe is thinking of buying in the next 6 months) through fast (e.g. where RealMe is physically located at a given moment in time).
  • the volatility is fixed (e.g. date of birth is always static) while for others, for example tastes in fashion or instantaneous position, the volatility is initially set to a default value according to a predetermined propensity to change, but can be manually changed by RealMe, and/or continually re-evaluated to reflect the actual frequency of change of the attribute value 231b.
  • the MetaEngine 275 facilitates the continual evaluation and updating of volatility 2281, through statistical analysis of the past frequencies of change of the attribute in question both a) across a population of RealMe's in order to define pre-set values and b) for the specific RealMe in question once he or she has defined and started updating the attribute.
  • the volatility 2281 of an attribute definition record 228 is used in conjunction with the date and time stamp 231c of an attribute 231 to determine the "best use by" date and time 231d of an absolute value 231b entered by RealMe.
  • CyberMe 96 can better judge the appropriateness of products and services to RealMe at a given time.
  • certain products and/or services are associated with a relevance rating, which is a way of defining the relevance of the product or service according to the cunent values of RealMe's attributes 231.
  • Confidentiality 228m is a characteristic which indicates the system default level of restriction on access to and distribution of conesponding attributes 231 within the universal system 100. Confidentiality is also stored as a field 231 e within the conesponding attributes 231, in order to permit RealMe to change the confidentiality to suit their needs.
  • confidentiality 228m is set to a predetermined value for all global attributes the default value may be modified as a result of statistical analysis by MetaEngine 275 of a large number of populated RealMe attributes 231, which indicates, for example, that the majority of the cunent population of RealMe's are changing the default value to something else.
  • confidentiality is set by RealMe for local attributes.
  • Confidentiality 228m may take on one of a range of values , e.g. 0 - 100, wherein subranges conespond to one of the following levels of restriction on access to the attribute 231: Private (i.e. access restricted to RealMe only, e.g. 81 - 100); Known RealMes (i.e.
  • Limbic and Cortical Relevance 228n and 228o express a weighting or relevance of the attribute to emotional and rational thinking.
  • the initial values for the limbic 228n and cortical 228o characteristics of global attributes are set to default values and may be subsequently updated through statistical analysis by MetaEngine 275, in the same way as the confidentiality characteristic 228m.
  • MetaEngine 275 This approach is modeled on the human mind, where the Cortical system is responsible for rational aspects of thought (e.g. fact-based and logical thinking), and the Limbic system is responsible for emotional aspects of thought (e.g.
  • the human brain arbitrates decisions between the limbic and cortical systems, the arbitration being influenced to some extent by the strength of emotional or rational thought drivers (criteria which influence a decision) at the time.
  • the limbic 228n and cortical 228o ratings of attributes 231 enable LM 225 to be responsive to the mood that RealMe is in, and to focus in on limbic-biased or cortical-biased attributes accordingly when conducting a Learning Session with RealMe 95.
  • CyberMe may target limbic-biased attributes 231 rather than cortical-biased attributes 231.
  • the value range of both characteristics 228n and 228o may be from 0 - 10, where 0 is the lowest rating and 10 is the maximum rating.
  • the rating system does not preclude an attribute from having the same rating for both Limbic and Cortical relevance (e.g. an attribute could have high limbic relevance and high cortical relevance).
  • Ratification 228p indicates whether an attribute can be independently confirmed by a third-party externally administered database through ELM 210, and, if so, the identification of the external data sources that can be used for ratification, e.g. credit agencies. For example, if RealMe enters his or her academic qualifications, the relevant academic institution or an independent qualifications database can be asked to confirm the accuracy of the RealMe's entries. Ratification is typically requested for explicitly defined attributes but may also be requested for implicitly defined attributes. Attributes 231 have a conesponding field Ratified 23 lg which, for a given attribute, indicates whether the absolute value has been ratified by an external source.
  • this field is relevant only to ADRs 228, refened to herein as "source attributes", which have a standard discrete or defined discrete value range type 228g. It defines relationships with and links to other discrete value range attributes which are contextually related (e.g. all discrete value range attributes relating to sport), and enables the linked attributes to be given implicit values based on the value of the source attribute. For example, let us consider the exemplary attributes "Listens to music”, “Extent to which likes listening to music” and “How frequently listens to music”. All three are contextually related to music, and so a linkage between all of them is wananted. Knowing the explicit value of the source attribute permits an implicit value to be derived for the other attributes.
  • source attributes which have a standard discrete or defined discrete value range type 228g. It defines relationships with and links to other discrete value range attributes which are contextually related (e.g. all discrete value range attributes relating to sport), and enables the linked attributes to be given implicit values based on the value of the source attribute.
  • LM 225 The implicit values assigned by LM 225 can be determined in one of two ways: a) Equivalence: standard discrete value ranges 228g can have equivalent subranges linked directly. Using the attributes above as an example, "Listens to music” and "How frequently listens to music” would be treated as follows by LM 225:
  • mappings that would be selected would conespond to, for example, the "lowest” equivalent value subrange in the linked attribute, i.e. if "Listens to Music” had an explicit value of False then the equivalent implicit value of "How frequently listens to music” would be None. Similarly, if "Listens to music” had an explicit value of True then the equivalent implicit value of "How frequently listens to music” would be "sometimes".
  • conesponding attribute definition IDs 228a are Bl, B2, and B3, respectively.
  • the value ranges 228h for each of these attributes is as follows:
  • value range ⁇ false, true ⁇ B2.
  • value range ⁇ not at all, a little, it's OK, quite a lot, very much ⁇ B3.
  • value range ⁇ never, a little, sometimes, quite a lot, very much ⁇
  • a three-dimensional matrix is created which shows the probability of each of the possible values for each linked attribute for a given value of the source attribute.
  • An example of the data that such a matrix could contain for each of the aforementioned attributes is shown in
  • the probabilities that are used to populate these matrices are set to default values, which may be entered manually, when the universal C2B 2 system 100 is initialized. Thereafter, however, the MetaEngine 275 monitors and updates the Learning Manager's 225 success at deriving implicit values, by statistically observing across a population which implicit values are actually converted to explicit values and updating the probabilities accordingly.
  • Associated key words 228r are words associated with an attribute definition record 228, but not part of the description 228b of the attribute, which further enable LM 225 to identify attributes relevant to a particular context. For example, if RealMe 95 is having a conversation with CyberMe 96 and asks CyberMe "How do you think I relax ?” then Conversation manager would pick out the key word "relax" from RealMe's input, identify the attributes which have the keyword "relax" present in either their description 228b or their associated key words 228r, and would then use the presentation conversation pieces 228d and multimedia aids 228i associated with each attribute to present the attribute's value 231b to RealMe.
  • An exemplary attribute record 231 comprises the following fields: Unique Attribute ID 231a is a unique identification code used to identify and access the conesponding attribute 231.
  • Absolute value 231b is the value allocated to the attribute 231 itself.
  • the absolute value 231b meets the conditions set by data type 228f and value range 228h in the conesponding attribute data definition record 228. For example, an absolute value 231b for the attribute "favorite color" might be "blue”.
  • Date and time stamp 231c is the date and time of the last update of the attribute. 231. Best use by date and time 23 Id is an indication of the optimal period of accuracy of the information held by an attribute 231, similar in concept to the "best use by date" of an item in a supermarket: the "best use by" date indicates that the item is of optimal quality and should be used or consumed on or before the stated date, as beyond that date there is no guarantee of the freshness and/or quality of the item.
  • the "best use by" date and time is calculated as a function of the date and time stamp 231c and volatility characteristic 2281, and is used by Learning Manager 225 to ensure that RealMe is prompted at the appropriate time to update attributes 231 which are approaching their "best use by" date and time. This ensures that RealMe 95 is given the opportunity to keep his or her attributes 231 up to date.
  • Confidentiality 231 e is a field which indicates the' proper level of restriction on access to and distribution of an attribute 231 within the universal system 100.
  • the confidentiality field 23 le within an attribute 231 is initially set to a predetermined value as defined by the conesponding Confidentiality field 228m in the ADD record 228.
  • the value stored in the confidentiality field 231e may be modified by RealMe to reflect their personal confidentiality requirements for this attribute.
  • Confidentiality 231 e may take on one of a range of values , e.g. 0 - 100, wherein subranges conespond to one of the following levels of restriction on access to the attribute 231: Private (i.e. access restricted to RealMe only, e.g.
  • Known RealMes i.e. access permitted to declared known RealMe's, e.g. 61 - 80
  • Universal C2B 2 System 100 i.e. access given to CyberMe for distribution as an anonymous attribute 231, that is, with data identifying RealMe stripped from the data record, to secure from third parties products and services tailored to RealMe's express and implied wants and desires, as expressed through his or her attributes 231, e.g. 41 - 60
  • MicroCosm i.e. access given to Universal and MicroCosm C2B 2 systems 100 and 286, respectively, to be described below e.g. 21 - 40
  • Public i.e. no restrictions on access e.g. 0 - 20).
  • Explicit, Implicit 231f For attributes 231 for which RealMe 95 has not yet indicated the absolute value 231b, and for which the value has not been ratified (see
  • LM 225 may make judgements on likely values based on the values of related attributes 231, as discussed above in the 'Relationships with other attributes' field 228q, in the ADD 228. For example, if RealMe has populated a number of attributes indicating that he or she is an art lover but hates arithmetic, LM 225 might surmise that RealMe likes sculpture. Thus the binary attribute "likes sculpture" (where the value can be true or false) may be set to true on the basis of the fact that RealMe likes art.
  • the degree of implicitness or explicitness is expressed using a single measure in the range 1 - 100, where values in the range 1-99 indicate that the attribute value is implicit with increasing probability from 1 to 90, and 100 indicates it is explicit (i.e. 100% certain since entered by RealMe).
  • Clearly implicit values that are allocated to attributes are not certain, and the probability rating stored in field 231f is designed to reflect the Learning Manager's level of uncertainty.
  • An implicit value is derived from another attribute which has an explicit value, the mechanism for which is described above in links to other attributes 228q. Since more than one other linked attribute could provide an implicit value for this attribute, the implicit value actually selected is the one with the highest probability.
  • Ratified 23 lg indicates whether an attribute has been independently confirmed by a third-party externally administered database through ELM 210, according to one or more of the external data sources that can be used for ratification (as specified in the conesponding ADD 228 record in the ratification characteristic field 228p). For example, if RealMe enters his or her academic qualifications, the relevant academic institution or an independent qualifications database can be asked to confirm the accuracy of the RealMe's entries. Ratification can be requested by Learning Manager 225 for all attributes which have an explicit or implicit value. If ratification is successful then the status is changed to ratified.
  • Ratification is typically requested for explicitly defined attributes, but may also be requested for implicitly defined attributes in which case if ratification is successful the attribute's explicit/implicit indicator 231f is changed to 100 (explicit). If unsuccessful with all possible ratification sources and the value entered was explicit, as indicated by the value in the explicitness indicator field 231f, then the Learning Manager may prompt RealMe to re-confirm the value entered, and may attempt to ratify again at a later point in time (to cater to the cases where external ratifications are not up to date, especially if the absolute value is changed by RealMe or another ratification source becomes available for the attribute, as defined in ADD ratification field 228p).
  • An attribute 231 would be created in the 1 st person partition 235 of the attributes database 230 as follows (comments in parentheses): 231a: TV101
  • Ratified N/A (cannot be ratified)
  • Another example is an attribute 231 that holds RealMe's musical tastes.
  • 228g Value range type analogue 228h Value range: "any combination of classical, jazz, dance, house, garage, chart music, rap, classical rock, progressive rock, reggae"
  • An attribute 231 would be created in the 1 st person partition 235 of the attributes database 230 as follows (comments in parentheses):
  • Ratified N/A (cannot be ratified).
  • information relevant to RealMe 95 may also be stored in the following sections of Attributes 230: Peer Definition 237; Non-standard Personal
  • the Peer Definition section 237 of the Attributes Database contains RealMe's definition of his or her peers (e.g. people of same age, profession, interests, etc.). RealMe can store more than one way of defining their peers. RealMe can select pre-defined "classes" of RealMe, held in the "relevance classes" database 255b (attached to the PSU 255 and discussed in more detail below), or customize his or her own definition. Each definition has a conesponding record, where each record holds a combination of attributes, and each attribute is given a value or value range.
  • RealMe may decide to define his or her peers as "those people aged between 30 and 34, whose profession is “systems analyst”, whose domicile region is Northern Virginia".
  • the conesponding record would use the attributes with description 228b equal to "cunent job", "age”, and "domicile region”.
  • RealMe may wish to define his or her peers as "non- smokers", in which case the attribute description 228b is “smoker” and the value 231b is "false”.
  • RealMe's own definition of his or her peers would be used by the MetaEngine 275 to respond to RealMe's request for benchmarking information (i.e. comparative information between RealMe and his or her peers), as discussed previously.
  • benchmarking information i.e. comparative information between RealMe and his or her peers
  • RealMe requests benchmarking information he or she can select any combination of peer definitions. For example, RealMe might choose to define his or peers using the definition in the first example above and/or that in the second example.
  • Bespoke information that RealMe wants to store, but which cannot easily be stored in a single attribute (whether global or local) in 1 st person 235 may be stored in the Non- standard Personal Information section 238 of Attributes 230.
  • an ornithologist wishing to access via CyberMe 96 a spreadsheet which contains all the bird- watching sites visited to date, and the birds seen at each of them, he or she may do so by storing the spreadsheet as a Non-standard Personal Information populated attribute 238a.
  • the storage mechanism may be one of file transfer from a PC or other device that RealMe 95 can use to connect to CyberMe 96 and simultaneously hold or access the personal information that he or she wishes to store in the Attributes database 230.
  • RealMe may connect to CyberMe and request the associated data. If RealMe were using an appropriate device (as defined in the characteristics of the cunent channel), the associated data could be transfened to that device.
  • the system 100 may provide application services, in accordance with an application service provider model, as will be known to those familiar in the art, in order to enable an application to run locally on system 100 resources, such that RealMe can view and process their bespoke information without having to have the pertinent software application loaded on to the device they are using to access their CyberMe.
  • Information on RealMe's cunent location, projected location, regular journeys, projected journeys, etc., is stored in the Movement Assimilation section 239 of Attributes 230. This is addressed more fully below.
  • the History section 240 of the Attributes database 230 is an archive of all attributes pertaining to RealMe. Each attribute 231 can be archived whenever it is changed by some action on the part of RealMe. Archiving attributes allows a full history of changing preferences and characteristics to be obtained, which may be accessed, for example, by MetaEngine 275 or Personal Wealth 215 to analyze and present RealMe's changing preferences over time.
  • RealMe's attributes database 230 are catalogued and stored in a manner that is designed to encourage development of CyberMe and to be highly flexible. These attributes are consistent with information RealMes want to store about themselves, contain infonnation responsive to what product and service providers need to know about RealMes in order to service them, and allows RealMe to store data in a way which is unique to him or her (e.g. an ornithologist may hold data in a unique way which is then used by him or her personally to make decisions on travel anangements for the next field trip).
  • Attributes 231 about a given RealMe may be populated with information provided by the RealMe themselves or from “other" sources.
  • Other sources comprise “external” sources (which are accessed by the system 100 via the External Interface Manager 210) and “internal” sources (accessed from elsewhere within the system 100).
  • RealMe can request information from other sources (e.g. to ratify RealMe's academic qualifications), and, equally, other sources can offer RealMe information (e.g. a relative of RealMe could offer information about himself or herself via his or her own CyberMe, to help RealMe understand his or her relative's preferences and requirements).
  • other sources can offer RealMe information (e.g. a relative of RealMe could offer information about himself or herself via his or her own CyberMe, to help RealMe understand his or her relative's preferences and requirements).
  • the default position is for RealMe to check and approve the information before it can be stored in Attributes 230. This default can be over-ridden by RealMe, by changing the value of an associated interaction preference (stored as an attribute 231 in its own right), to indicate that automatic updates, without checking or approval, are permitted from "trusted" external sources.
  • SD 256 Since all suppliers in SD 256 have a supplier rating, as described below, this rating may be used as a parameter referenced by RealMe to define which external sources he or she is willing to receive information from, without approval (e.g. only from 5-star external sources). Examples of external sources of information are shown in FIG. 2C.
  • the case where attributes are accepted from another source by RealMe, either after manual checking and approval, or by automatic acceptance, which are subsequently found to be inaccurate (e.g. because the originator made an inaccurate entry, but did not notice) is now considered. Such an occunence could lead to an event, such as the major purchase of a product or service, that was consequently found to be based on inaccurate information, and therefore not to meet the intended requirements.
  • the audit trail stores a record of the information provided by any source other than RealMe and the time and date at which the information was provided. This audit trail is maintained by Security and Controls 206.
  • the Learning Manager 225 application gathers attributes from RealMe. It is sensitive to RealMe's needs and desires at a given time and secures attributes according to recipes, stored in Recipes database 260, that conespond to those needs.
  • Learning Manager 225 employs advanced psychometric profiling and video game techniques to secure data in an unobtrusive and engaging manner.
  • An example of psychometric profiling includes soliciting responses from RealMe to a series of questions specifying a variety of scenarios, images, sounds, etc., and analyzing the responses to determine information regarding RealMe's personality.
  • An example of video game techniques includes, for example, a video game played by RealMe wherein psychometric analysis of RealMe's actions at decision points in the game is used to derive information regarding RealMe's preferences and/or personality, which may then be confirmed by RealMe subsequent to the game.
  • Attributes 231 are gathered by Learning Manager 225 in a manner which appeals to RealMe, is easy for the RealMe to assimilate, and makes clear to RealMe the purpose for the gathering of the information.
  • the Learning Manager 225 algorithm incorporates a theoretical framework such as Maslow's Hierarchy 800 as a fundamental guide in structuring the sequence of questions asked to obtain RealMe's attributes.
  • Maslow's Hierarchy 800 is illustrated schematically in FIG. 8.
  • Basic needs 808 of the individual form the base of a four-tier pyramid in which needs of increasing sophistication occupy progressively higher positions (nearer to the peak) in the pyramid.
  • Basic needs include, for example, shelter, food, clothing, transportation.
  • Discretionary needs 806 include, for example, consumer goods and services frequently purchased and used by RealMe.
  • Lifestyle and Entertainment needs 804 reflect, for example, RealMe's lifestyle, leisure, and entertainment preferences.
  • Emotional needs 802 reflect, for example, RealMe's spiritual, aspirational, philosophical, and philanthropic preferences.
  • the Learning Manager 225 structures questions conesponding to these needs, and solicits responses thereto from RealMe.
  • the Learning Manager 225 may invite RealMe to create a three-dimensional image of himself or herself to be stored as part of his or her attributes. It is known in the art to produce a three-dimensional image of a person or object by taking two digitized photographs at right angles to each other (for example, front view and profile) and manipulating the digitized data. The three-dimensional image, once stored in the Attribute
  • Database 230 may be used subsequently to respond to other offers, for example offers from on-line clothing suppliers.
  • the three-dimensional image facilitates virtual "trying on” of clothes, in a manner known in the art, enables one to assess appearance, quality of fit, etc.
  • the three-dimensional image of the RealMe may be used in the context of other offers, for example to see how one would look at the wheel of a particular car.
  • the RealMe may also choose to make his or her own three-dimensional image his or her virtual image in the context of the system. In other words, CyberMe may take on the appearance of RealMe in this manner.
  • RealMe may be invited to respond to an offer wherein a professional photographer or videographer prepares images of a RealMe's domicile and scans them into a digital format suitable for storage in the RealMe's attributes in Attributes Database 230. These images may be used subsequently in responding to other offers, for example for furniture.
  • a professional photographer or videographer prepares images of a RealMe's domicile and scans them into a digital format suitable for storage in the RealMe's attributes in Attributes Database 230.
  • These images may be used subsequently in responding to other offers, for example for furniture.
  • LM 225 When RealMe first starts to interact with their CyberMe, LM 225 initially targets basic information about RealMe, and then tries to secure information on RealMe's likes, dislikes, and immediate requirements. LM 225 then attempts to gather information that is most useful for securing products and services that are known to be relevant to RealMe (relevance having been determined by RealMe's likes, dislikes, and/or expressed requirements). Clearly when RealMe first starts to interact with CyberMe, CyberMe does not know much about RealMe and so cannot respond as effectively as when RealMe and CyberMe have interacted over a long period of time and CyberMe has thereby learned about RealMe's likes and dislikes. LM 225 is often "guided" as to what information it should target in support of acquiring required products and services by recipes which are defined sets of information relating to specific products and services, and which are discussed in detail in Layer 140 below.
  • FIGS. 9 A and 9B show an exemplary learning session, which enables CyberMe to learn more about RealMe in support of RealMe's cunent focus and in a manner consistent with RealMe's feelings and time constraints.
  • FIG. 9A which describes initialization of the learning session, whether an OPEN session is initiated at the request of
  • RealMe as indicated in FIG. 6B or a FOCUSED session is initiated by the CRP 250 application, as described in FIG. 9A (900). If a FOCUSED session is initiated, then the Recipe Queue is preloaded by the CRP 250 application, and the system proceeds to 906. If an OPEN session is initiated, LM 225 obtains the maturity of all recipes for this CyberMe from Recipe Maturity 261, described below, at 902. The LM 225 application calls Recipe Workflow to select and prioritize recipes based on Recipe Relevance 262, Recipe Maturity 261, and recipe size (i.e. a count of the number of attributes in a recipe) in order to create a Recipe Queue at 904. The various recipe modules are described fully in connection with Layer 140 below.
  • Recipes with the highest relevance and maturity are assigned high priority, since they are more important and/or closer to completion than less relevant or mature recipes, and smaller recipes may be assigned high priority since they may be completed more quickly than larger recipes. If a number of recipes are determined to have equal priority rankings, their relative order is preferably randomized, although an order may be chosen. Subsequently (or if a FOCUSED session was initiated), LM 225 calls the CM 202 application to check whether any connectivity problems have been experienced in, for example, the last five sessions on the cunent channel at 906.
  • CM 202 retrieves from the History section 240 of Attributes Database 230 information regarding the integrity of last five sessions on the cunent channel for the RealMe in question; if RealMe is a new user, information on sessions is not found.)
  • the LM 225 application retrieves average session time and rate of RealMe interaction from the History section of 240 Attributes 230. LM 225 then asks CM 202 to inform RealMe that CyberMe wants to learn more about him or her, presents to RealMe the average session time, and asks how long RealMe would be willing to spend "teaching" (providing additional personal information to) his or her CyberMe at 908.
  • CM 202 may at this point present to RealMe related facts, held in the conversation enrichment database 202e, for example, "It took Michelangelo three years to sculpt his famous 'David'".
  • RealMe does not specify a time limit for the session in response to CyberMe's question, then the session time is set to the average session time unless RealMe is a new user, in which case a default session time is set according to the channel in use.
  • TAA Target Attributes Algorithm
  • the TAA is used by the LM application 225 to select attributes within the target recipes on the recipe queue that are to be targeted, i.e. identified and populated, and to specify the recipes on the recipe queue that are being targeted, i.e. identified, retrieved from the recipe database 260, and worked on, as well as conesponding target maturity, during a learning session.
  • Inputs to the TAA include, for example, expected session duration, recipe queue, and CyberMe ID.
  • Outputs from the TAA include, for example, an attributes queue, target recipes, and target maturity for each target recipe.
  • the TAA takes recipes from the recipe queue, and working top down identifies the attributes in each recipe record that are cunently unpopulated.
  • the TAA takes account of the attributes that are shared by more than one recipe in the queue and compiles a prioritized list of the attributes according to the following goals: given a CyberMe tag, complete and/or achieve the highest maturity possible of as many recipes as possible in the recipe queue while limiting the number of dialogue questions to that which can be reasonably answered in the expected session duration, according to the rate of RealMe interaction (average number of learning questions answered per unit time).
  • LM 225 instructs CM 202 to list the targeted recipe(s) and associated icons, the benefits to RealMe of completing the targeted recipes, the target maturity for each recipe, and an estimate of the number of questions it wants to ask RealMe and the time required to answer all questions at 912. In 912, the TAA insures that the time estimate does not deviate significantly from the requested session time. LM 225 then instructs Conversation Manager 202 to ask RealMe to confirm he or she wishes to proceed at 914.
  • CM 202 takes note of any time constraints with a view to monitoring elapsed time during the learning session at 922, after which LM 225 conducts a learning session (924), as described fully in FIG. 9B. Subsequently LM 225 closes down the learning session at 926.
  • LM 225 instructs CM 202 at 916 to ask RealMe whether he or she wants to target different recipes than those suggested and/or re- prioritize those suggested. The full list of recipes may be browsed by RealMe. If RealMe responds negatively to the question posed by CyberMe in 916, LM 225 closes down the learning session at 926.
  • the LM 225 instructs CM 202 to ask RealMe to indicate which recipes he or she wants to target and the desired order of presentation at 918.
  • LM 225 then rebuilds the recipe queue accordingly and calls the TAA to reselect attributes being targeted in the learning session at 920.
  • CM 202 then takes note of any time constraints with a view to monitoring elapsed time during the learning session at 922, after which LM 225 conducts a learning session, as described in FIG. 9B. Subsequently LM 225 closes down the learning session at 926.
  • LM 225 Upon closure of the learning session at 926, LM 225 instructs CM 202 to ask RealMe what they want to do next if the learning session was OPEN; if the learning session was FOCUSED, LM 225 hands control back to the CRP 250.
  • CM 202 enables, constructs and manages conversation between CyberMe and RealMe.
  • Inputs to the CM 202 include a dialogue identification code (dialogue ED) conesponding to a dialogue pattern, where each dialogue pattern supports a different type of dialogue, for example learn, tell, answer question, alert, and/or embellish, etc., associated parameters, and a CyberMe LD.
  • CM 202 outputs include, for example, a conversation piece (item of conversation output to RealMe) from the conversation pieces database 202b and an invocation of some aspect of the functionality of the system 100 in response to RealMe input.
  • a conversation piece is a sentence that is output by CM 202 to support a conversation with RealMe.
  • a conversation piece can be obtained from an ADR 228 from any of the conversation piece fields 228c, 228d and 228e held within it (as discussed previously), or the conversation piece database 202b which is connected to the conversation manager.
  • a conversation piece can be provided in an explicit or a constructive form. If it is in an explicit form then the exact words that CM 202 needs to present to RealMe are provided (e.g. "do you like listening to music"). E.g. an exemplary explicit conversation piece would be stored as follows:
  • Conversation piece type explicit 1 st person text: "how much do you like playing football?”
  • CM to enable a sentence to be constructed, i.e. completed.
  • Constructive forms are defined by templates according to the different kinds of sentence being constructed.
  • the construction templates seek to store the grammatical and syntactical rules which can be used to form a sentence.
  • An exemplary construction template for a question of the form "do ... ?” is as follows: Conversation piece id: CDO1232
  • Conversation piece description - do question e.g. do you like playing golf?; do you listen to music?.
  • Conversation piece type question (as opposed to statement or exclamation)
  • Permitted construction forms do:subject: ⁇ qualifying verb according to subject+main verb in -ing form ⁇ or ⁇ main verb according to subject ⁇ :object, only if qualifying verb present ⁇ :? If another module in the system 100 is using CM 202 to converse with RealMe, then that module must pass conesponding parameters to the conversation manager CM 202 in order for the sentences to be constructed from the construction templates.
  • the Learning Manager 225 is an example of such a module
  • the ADD 227 is an example of a database whence LM 225 obtains the parameters it needs; they are stored in ADD 227, in fields 228c, 228d and 228e in an ADR 228.
  • the subject is not stored, since this will be provided to CM 202 by LM 225 depending on who the subject of the question is. If the attribute 231 is in the first person partition 235 of the attributes database 230 (i.e. conesponding to infonnation about RealMe) then the subject parameter passed to CM 202 will be "you". If it is in the third person partition 236, then it will depend on the gender of the third person in question e.g. if is RealMe's sister then it will be "she” whereas if it is RealMe's father then it will be "he”.
  • the CM 202 application has built within it the capability to derive the conect form of the verbs required in order to construct the sentence conectly.
  • CM 202 needs rules to follow in order to change the form of verb.
  • the rules that it uses do to this are held in the Language Rules database 202d.
  • CM 202 automatically converts the verb form from "do" to "does” if the subject is third person rather than first person.
  • CM 202 would choose the conect form of the verb (e.g. 2 nd or 3 rd person indicative vs. participle) based on context, and in this case the form of the main verb selected by CM 202 would be "playing".
  • Both the explicit and constructive forms are stored in the conversation piece database accessible by the conversation manager CM 202 CM 202 is prepared to accept a natural language response from RealMe at any time
  • CM 202 uses fuzzy logic to analyze natural language input in order to identify known patterns of words which it can use to interpret the sentence submitted by RealMe, as described previously. These patterns are stored in the Language Rules database 202d. The words used by RealMe may not be the ones that are stored within a known pattern, however CM 202 uses the dictionary and thesaurus database 202c in order to cross reference words appropriately and thus identify relevant patterns. If CM 202 does not identify a direct match, it uses the principles of fuzzy logic to select the pattern most likely, to be the one that matches RealMe's input. Once a pattern is identified in this way CM 202 then derives meaning according to the pattern and the words used by RealMe within the pattern, and again uses fuzzy logic in order to select the next response appropriate to RealMe's input.
  • CM 202 uses specialized software which is to be the subject of another patent to do this, but also utilizes some functionality offered by artificial language interpretation software such as AutonomyTM and Artificial LifeTM.
  • the CM 202 accepts an interaction request from a calling application, for example
  • LM 225 which includes a dialogue pattern LD and associated parameters, e.g. cunent RealMe interaction preferences, recipe LD, identification codes of attributes being targeted by the LM 225, etc.
  • the CM 202 then constructs a dialogue with RealMe by retrieving from the Dialogue Patterns database 202a a dialogue pattern indicated by the dialogue ID.
  • the dialogue pattern defines the conversation thread, i.e. the sequence and nature of questions in the dialogue with RealMe.
  • the dialogue may start with a question, and therefore require a response from RealMe, which may in turn lead to another question depending on the response given. All possible routes through the dialogue will be accounted for within the dialogue pattern, including unsolicited and/or unexpected responses.
  • CM 202 may embellish the dialogue by retrieving from a conversation enrichment database in communication with CM 202 related facts or multimedia presentations, which have previously been associated with the attribute and/or recipe that is the subject of the dialogue cunently in progress.
  • CM 202 seeks to construct and maintain a sensible dialogue to support the calling application in such a way that the same form of question and/or response is not repeatedly used, and different techniques are randomly used, for example mixing multiple choice responses with free text responses, response icons, etc.
  • interactions with RealMe are typically undertaken through Presentation 204.
  • LM 225 passes the attributes queue generated by the TAA, as discussed above, as well as the recipe queue to CM 202 with an instruction to request attributes from RealMe at 928.
  • CM 202 selects the "learn" dialogue pattern from the Dialogue Patterns Database 202a at 930, and calls the Attributes Grouping Procedure (AGP) to group successive attributes where possible at 932.
  • AGP Attributes Grouping Procedure
  • the AGP groups attributes of similar context or data type, thereby making it easier for RealMe to answer questions relating to similar attributes since their context is similar.
  • Inputs to the AGP include attributes, recipe queue and CyberMe LD.
  • the AGP outputs a prioritized list of grouped attributes and contexts.
  • the AGP accepts a prioritized list of attributes and attempts to logically group successive attributes in some way, typically based on context
  • the AGP groups attributes by examining successive attributes and determining, by examining first the recipes on the recipe queue to which each attribute is related and, second, the products and services linked to those recipes, whether or not their is a common context for the attributes. If a common context exists, e.g. "utilities" (e.g. electricity, telephone, gas), the context is stored with the attributes group, and the AGP passes the prioritized, grouped attributes back to CM 202.
  • a common context e.g. "utilities" (e.g. electricity, telephone, gas)
  • the context is stored with the attributes group, and the AGP passes the prioritized, grouped attributes back to CM 202.
  • CM 202 After completion of the AGP, CM 202 receives the attributes and attribute groups and identifies the context of the first attribute and grouped data type, if applicable at 934.
  • the CM 202 selects a conversation piece from the database 202b based on context and data type to construct a question and select a presentation method (e.g. text-only question, selectable icon, multiple choice question, etc.) at 936.
  • a conversation piece is one part of a dialogue pattern. For example, if the conversation piece is "learn", then the overall question and answer sequence is the dialogue pattern, but an individual question or answer within the sequence is a conversation piece.
  • CM 202 may invoke the conversation enrichment function at 938.
  • the conversation enrichment function is undertaken by CM 202 which is supported by the conversation enrichment database 202e in communication with the CM application. If appropriate, Conversation Enrichment selects a dialogue embellishment from the conversation enrichment database 202e based on context at 940, where the context is determined by the AGP and/or is explicitly suggested in the associated ADR 228, in the fields 228c, 228d, or 228e.
  • the CM 202 then presents the conversation piece to RealMe with or without conversation enrichment, as appropriate, and receives a response from RealMe at 942.
  • the CM 202 checks the attribute queue to determine whether the cunent attribute or attribute group is the last to be considered at 944.
  • CM 202 If yes, CM 202 returns control to LM 225 and LM 225 closes the cunent learning session, as described in FIG. 9A at 946. If no, CM 202 returns to 934 to retrieve the next attribute or attribute group.
  • Layer 140 Recipes/Products and Services/Response Engine
  • Layer 140 shown in FIG. 2F, comprises the following elements: Product & Service Universe database (PSU) 255, Supplier Directory database 256, Supplier Adoption & Hosting application 257, Recipes database 260, Recipe Maturity application 261, Recipe Relevance application 262, Recipe Workflow application 263, CRP 250 application and associated databases 251-254, and Consumer Feedback application 258.
  • the Recipes database 260 stores the recipes 260a associated with registered products and services in PSU 255.
  • Each registered product and service has a conesponding recipe 260a. This conespondence may be one to many, i.e. a single recipe may be shared among more than one product and/or service.
  • Each recipe data record contains an indication of the product(s) and/or service(s) to which it conesponds.
  • a recipe is a unique set of attributes, with a unique identifier (a "recipe ID") required to enable RealMe to explore and secure a conesponding product or service.
  • a unique identifier For example, if the product or service is "home insurance", then the conesponding recipe specifies all data required to enable RealMe to explore and complete the purchase of a home insurance policy. All attributes in a recipe are rated according to necessity as mandatory, prefened or optional and may in addition be conditional on the value of one or more other attributes. For example, a car insurance recipe may specify that if the value of the attribute "age” is over 70, then the presence of the attribute "date of last eye test" is mandatory. Recipes are designed in conjunction with different suppliers of products and services with a view to standardizing consumer-related electronic transactions.
  • Recipes are flexible, supporting non traditional product and service categories, including location-sensitive services. For example, as described in greater detail below in connection with Movement Assistance 284, if analysis of the movements logged by the Movement Assimilation application 208 by an artificial intelligence based processor internal to MA 208 indicates that RealMe is making the same journey regularly, for example to commute to the workplace, and there is an opportunity for saving time through using a different route, then CyberMe will populate a journey routing service recipe with details of the existing journey and present the recipe to a journey routing service provider to proactively secure suggested improvements to the route, or adjust ETAs of the respective journey stages to look for better routing suggestions, and, if found, suggest them to RealMe through P 204 and CM 202.
  • the Learning Manager 225 secures RealMe attributes according to the recipes that conespond to RealMe's stated needs. As RealMe enters or updates his or her attributes in the Attributes database 230, the product and service recipes are simultaneously accessed from the Recipes database 260 in Layer 140 (discussed below). The Learning Manager 225 solicits information from RealMe to acquire the data required to complete recipes relevant to RealMe, as discussed below.
  • the Recipe Maturity application 261 measures the degree of maturity of a given recipe when attributes are being entered or updated by RealMe.
  • the maturity 261a of a recipe 260a is a reflection of the percentage of attributes that are populated.
  • RMAT 261 weights mandatory attributes more heavily than prefened attributes, which in turn are weighted more heavily than optional attributes.
  • recipe maturity as determined by RMAT 261 is one of the factors used by the Learning Manager 225 in conjunction with Recipe Workflow 263 to determine recipe prioritization.
  • the Learning Manager 225 will solicit responses from RealMe to complete first those recipes which are the most mature since these recipes are easiest to complete.
  • a recipe is rated as "mature" when all mandatory and prefened attributes are present.
  • Recipe maturity is also partially dependent on the size of the recipe, which is the total number of attributes within the recipe.
  • the degree of maturity of a recipe can be conveyed to RealMe on request. RealMe may at any time instruct CyberMe to submit a request to the market based on an incomplete recipe. However, in such a case it is likely that a large number of responses of limited relevance will be returned because of the lower degree of specificity of the request.
  • the Recipe Relevance application (RR) 262 calculates and stores a measure 262a of the relevance of each recipe to RealMe based on RealMe's known attributes. Recipe relevance 262a is calculated as the sum of the relevance of each individual product or service in PSU 255, described below, which owns this recipe, and is stored in a separate field within the conesponding recipe record 260a. In the case of contemporaneous requests from RealMe, such that more than one recipe has been activated, recipe relevance is one of the factors used by Learning Manager 225 to determine recipe prioritization.
  • the Recipe Workflow application (RW) 263 guides RealMe through a process to secure a particular product or service (e.g. renew homeowner's insurance, find a piano teacher). It follows two main stages, the first of which is clarification of need (e.g. if RealMe enters "new insurance" as a request, RLP 220 analyzes the request, and subsequently the RW 263 works in conjunction with PSU 255 to determine what kind of insurance is required e.g. personal, house contents, auto, etc). In essence, clarification of need enables identification of a product or service at the lowest level (greatest specificity) in the PSU 255 hierarchy. Once identified, Recipe Workflow 263 selects the appropriate recipe(s).
  • the Recipe Workflow engine 263 is an application which, in cooperation with the RealMe Inquiry Processor 220 and Learning Manager 225, guides RealMe through a series of directed questions to obtain information necessary to identify, assess the completion of, and complete a recipe to a level of detail sufficient to fulfil a requirement put to CyberMe.
  • a recipe is the definition of the data that is required to specify a RealMe requirement for a product or service to a sufficient level of completeness such that a supplier can respond in a meaningful way.
  • An example of a recipe for a television set might include type of use (e.g.
  • RealMe screen dimension, projection technology, analogue or digital, sound specifications, etc; and communication channel cunently prefened or in use by RealMe, e.g. mobile phone, pager, PC, etc.
  • the requirement might be, for example, securing a good or service that RealMe is seeking (e.g. . renew homeowner's insurance, get a physical exam, buy a new car or appliance).
  • RealMe may also be asked to specify whether the desired good or service is intended for personal use or for presentation, for example, as a gift to a third party.
  • RealMe will be invited to provide information in the form of attributes regarding the third party, if the third party has not previously been described to LM 225, which is stored in Attributes 230 in the 3 rd person 236 and subsequently used by CRP 250 in filtering offers from suppliers in response to this particular inquiry, as described in greater detail below.
  • the process is of course dependent on the nature of the good or service sought.
  • Recipe Maturity 261 When the recipe conesponding to RealMe's requirement attains a degree of completion judged by Recipe Maturity 261 to be sufficient to obtain relevant information from suppliers, Recipe Workflow 263 presents the requirement and populated recipe to CRP 250 for presentation to suppliers and subsequent gathering and processing of responses from suppliers.
  • RealMe can specify a deadline by which he or she wants to receive all responses to a request. This is discussed in more detail in connection with Dynamic Responses 252.
  • RealMe's requirements themselves can be definite or probable.
  • "Definite” means that RealMe is certain that he or she has a requirement and is about to purchase the good or service to meet the requirement.
  • "Probable” means that there is a degree of uncertainty in RealMe's mind as to whether or not he or she will purchase the good or service selected. The uncertainty relates to either a function of (a) need, i.e. uncertainty as to the actual need or desire to purchase the good or service in question (e.g. "I'm not sure I really want this, but I'll check it out anyway"), and/or (b) time scale, e.g. certain of need but uncertain of when (e.g.
  • a RealMe in category (a) requires more information on the good or service in question (e.g. the options available relating to product features and benefits and/or service levels), and any additional information on the benefits or value of the good/service in question.
  • a RealMe in category (b) requires assistance on choosing an optimal time to buy.
  • a RealMe in category (c) requires assistance in prioritizing their requirements against their financial means and capabilities.
  • the C2B process of the invention seeks to deliver the information required to properly service consumers in categories (a), (b) and (c).
  • an indication of the status of "need” and "time scale” is provided by the system 100, based on input from RealMes, to suppliers such that they can make a more informed response.
  • the requirement is processed by the CyberMe Response Processor 250 and the type of product or service that RealMe has described in his or her requirement is matched against a central registry of product and supplier types (see Product and Service Universe database 255 below) in order to identify known products and/or services which match or may match RealMe's requirements.
  • RealMe may at any time present a request to his or her CyberMe for information on a given product or service, as discussed previously in connection with the Recipe Workflow engine 263.
  • the Learning Manager 225 will then work, in cooperation with the Recipe Workflow engine 263, Recipe Maturity 261, and Recipe Database 260 to complete the recipe conesponding to the request or inquiry.
  • the Learning Manager is responsible for securing information from RealMe in order to populate attributes.
  • Recipe Workflow seeks to secure attributes in order to mature a specific Recipe - held in the Recipe Database - and interacts with the Learning Manager in order to do so.
  • the Recipe Workflow Engine 263 updates the status of the unfulfilled inquiry in the RealMe Inquiry Memory 221 as being "recipe maturity in progress".
  • the RealMe inquiry Processor 220 checks the RealMe Inquiry Memory (RLM) 221 for unfulfilled inquiries whose recipes require more maturing.
  • RLM RealMe Inquiry Memory
  • the Recipes for products and services associated with the unfulfilled inquiries are retrieved in turn, and the Recipe Maturity 261a for each recipe 260a is retrieved. Accordingly Recipe Workflow 263 is called to interact with the Learning Manager 225, which prompts RealMe for information responsive to the missing data required to mature the recipe conesponding to the inquiry.
  • the Learning Manager 225 hands the inquiry and completed recipe to the Recipe Workflow Engine 263, which presents the inquiry and recipe to the CRP 250, which then presents the inquiry and recipe to the market and updates the status of the inquiry on RIM 221 to "responses requested”.
  • the Product and Service Universe database (PSU) 255 is a directory of products and services that are recognized by CyberMe.
  • the PSU may be implemented as a hierarchical data structure or a non-hierarchical structure, in a manner well known in the art. A description of a hierarchical data structure embodiment of the PSU database will be provided herein.
  • the PSU 255 defines a multi-tiered top-down hierarchy of product and service categories, e.g. "financial services” at level 1, "insurance” at level 2, "car insurance” at level 3, etc.
  • Each product or service in the PSU 255 has a text description, associated key words and multimedia descriptions associated with it, e.g., diagrams, photographs, video stream, sound stream.
  • Associated key words are important in that they enable natural language queries to get a match from the PSU 255 (e.g. a sporting event ticket supplier will have "soccer" listed as a keyword).
  • Relevance of a given product and service can either be calculated "on the fly” (in real time) as RealMe enters or updates his or her attributes or by a background job which runs while RealMe is not interacting with CyberMe.
  • relevance ratings are constantly updated as a function of the RealMe's time-variant attributes.
  • the PSU may refer to "classes" of individual which are pre-defined e.g. "twenty-somethings" are people aged between 20 and 29.
  • Such classes are stored within the relevance classes database 255b which can be referenced by the PSU in this way.
  • the levels within the PSU 255 are sufficiently flexible for new levels to be added and for different numbers of levels to be assigned beneath a top level entry (e.g.
  • “financial services” may have four levels, whereas “automotive” may only have three).
  • the PSU 255 permits assignment of products and services to more than one higher level category (for example, "MiniDisc Player” would be found under “consumer electronics” as well as under “entertainment”). Not all products and services offered by CyberMe to RealMe need be in the PSU 255. If RealMe requests a product or service not cunently defined in the PSU 255 then the requirement will still be serviced: the new product or service requested will be logged under the category "new" for subsequent consideration by the Supplier Adoption and Hosting application 257. Both manual workflow and artificial intelligence driven workflow will be used to conectly categorize the new product or service.
  • Each product or service recorded in the PSU database 255 has associated with it one or more supplier records in the supplier directory 256, indicated by pointers in the PSU record.
  • the Supplier Directory database (SD) 256 is a directory of known suppliers of products and services held in the PSU 255. Suppliers are registered as direct or indirect suppliers to RealMe. Indirect suppliers are suppliers further down the supply chain than direct suppliers, as discussed in greater detail below. Direct Suppliers are suppliers at the top level on the supply chain, and supply products and services directly to RealMe consumers. Direct suppliers have a supplier rating according to several factors including past performance in servicing RealMe's, trading history, turnover, profitability, credit rating, brand recognition, responsiveness, lead times, consumer feedback, etc. This supplier rating approach is analogous in concept to the five star rating system by which hotels are rated. Suppliers are generally promoted or demoted through the action of the
  • Each record 256a in SD 256 includes supplier-specific details such as registered company address and other contact information,
  • IP address IP address
  • file format preference e.g. XML, EDI
  • the locality represents the region in which the supplier operates for a given product/service. For example, a given supplier might supply sugar to anywhere in the world, but only supply fresh vegetables to the east coast of the United States.
  • the default locality for each supplier and product combination is "global".
  • a more specific locality for the supplier/product combination is specified in the supplier data record by the presence of flags indicating supplier operation in conesponding predetermined grids on a map which is stored in SD 256, thereby defining the shape and expanse of the supplier's area of coverage for the product.
  • Each record 256a in SD 256 contains an indication of whether a supplier 98 is a collection point, CyberVendor 296, and/or MicroCosm.
  • the Supplier Adoption and Hosting application (SAH) 257 supports a highly flexible and automated process for adopting new suppliers. For example, if the Reconnaissance Manager 283 finds on the Internet a new supplier of a new or requested product or service, and it detects an e-mail address for the supplier, then it will attempt to initiate a dialogue with the supplier by an automatically generated e-mail message, to introduce the supplier to the C2B 2 system of the invention and invite the supplier to formally register and begin servicing RealMe requests.
  • SAH Supplier Adoption and Hosting application
  • SAH 257 owns and manages a Supplier Escalation application 257a.
  • This application can have a direct impact on suppliers' ratings through the supplier rating scheme described previously.
  • Supplier Escalation 257a is invoked in the case where an incident (such as delivery of a faulty product) or a lack of action (e.g. delivery of a product is not completed by the requested delivery date - as in the example above) is raised with the supplier to incite the supplier to rectify the situation and to improve its internal processes to prevent the same situation's arising in the future.
  • Supplier Escalation 257a manages what is commonly known as an escalation procedure because the supplier is first given the opportunity to immediately rectify the shortcoming, and ideally to explain the cause of the shortcoming and the steps that will be taken to prevent its happening in the future. If the supplier does not respond satisfactorily (i.e. the shortcoming is not dealt with and/or the situation worsens) then the matter is escalated beyond the level of administration to a higher management level within the supplier organization, which is again given the opportunity to immediately rectify the shortcoming and explain its cause and consequent steps that will be taken to prevent its happening in the future.
  • One or more such escalation levels may be put in place, and this may be a function of the size of the supplier organization.
  • the supplier's rating may be demoted, such that the supplier may eventually be given a 'negative" rating on the Supplier Directory 256 (effectively putting them on a supplier 'blacklist" - a list of suppliers who are unreliable, and therefore strongly recommended as one to avoid).
  • a list will serve to identify unreliable suppliers who dynamically respond to RealMe requests through the Market Interactor 282, and will permit RealMe to be warned of the supplier's substandard reputation.
  • RealMe will be able to define an attribute 231 indicating that he or she wishes all such responses from negatively-rated ('blacklisted') suppliers to be eliminated from the list of responses that are presented to them by the CRP.
  • the CyberMe Response Processor (CRP) 250 is an application which responds to inquiries analyzed by and received from the RealMe Inquiry Processor 220. It obtains relevant responses from all or any of the Brokered Response 251, Dynamic Response 252, Spidered Response 253 or Supplier Push 254 databases.
  • CRP 250 When servicing a specific inquiry, CRP 250 first conducts intelligent searching of product and service records in PSU 255 and associated keywords from the analyzed inquiry, drawing up a short list ranked according to relevance to RealMe, where the relevance rating is based on the values of RealMe's attributes rather than the keywords used in the inquiry. CRP 250 then draws up a short list of prospective registered suppliers by identifying local and global suppliers associated with the product/service short list.
  • the Brokered Response database (BR) 251 stores the details of brokered agreements formed with suppliers of products and/or services based, for example, on the analysis of RealMe requirement trends noticed by analyzing meta data collected by Meta Engine 275 and stored in Meta Data 276.
  • An example of a brokered response includes an attractively discounted deal on domestic electricity supply in response to significant expressed interest from RealMes in saving money on home energy costs.
  • Each brokered response record 251a in BR 251 contains a pointer to a conesponding product or service record in the PSU 255 as well as a pointer to a supplier record in SD 256. It also has a relevance rating for RealMe, defined by a Boolean combination of attribute values.
  • a particular car insurance offer may be relevant only to female drivers over the age of 25 with seven years of driving experience, while another offer may only be relevant to male drivers under the age of 21.
  • CRP 250 first filters out all brokered responses not associated with shortlisted suppliers and products/services before filtering the remaining responses according to the specific relevance of each offer. After this filtering process, the resultant offers are ranked in order of relevance or timeliness (offers about to expire may be presented prior to those which have longer validity) and presented accordingly to RealMe through CM 202 and P 204.
  • the Dynamic Response database (DR) 252 stores dynamic response records 252a conesponding to responses obtained in real time from suppliers in the market by Market Interactor 282. Such suppliers can be registered or unregistered.
  • the Spidered Response database (SR) 253 stores spidered response records 253a conesponding to responses obtained from, for example, the Internet through web crawlers submitted by the Reconnaissance Manager 283, which searches the Internet for deals on products and services already defined by records in the PSU 255 or indeed products and services described by RealMe but not yet registered in the PSU 255.
  • Suppliers newly identified in this way i.e. those who have not already been adopted and rated
  • the Supplier Push database (SP) 254 stores supplier push records 254a conesponding to advertisements of products and services or suppliers, which can be independently presented to RealMe by CRP 250 if the conesponding product/service relevance rating is sufficiently high, or if an explicit request received from RealMe is for an associated product, where two products are defined as associated (and interpreted as such by CRP 250) if they are both registered within the same category in the PSU 255. For example, if RealMe is interested in buying climbing equipment, then CRP 250 may submit to RealMe an advertisement for camping equipment at the same time that it submits the responses relating to climbing equipment.
  • An example of a brokered agreement or supplier push offer includes an offer valid for a specific duration by a professional photographer to develop a three-dimensional (3-D) image of the RealMe from standard two-dimensional at a specified price which may be stored as part of the RealMe's profile. It is known in the art to produce a three-dimensional image of a person or object by taking two photographs at right angles to each other (for example, front view and profile). The 3-D image, once stored in the Attributes database
  • the 3-D image may be used subsequently to respond to other offers, for example offers from on-line clothing suppliers; the 3-D image facilitates virtual "trying on” of clothes, in a manner known in the art, so as to assess appearance, quality of fit, etc.
  • the 3-D image of the RealMe may be used in the context of other offers, for example to see how one would look at the steering wheel of a particular car.
  • the RealMe may also choose to make his or her own three-dimensional image his or her virtual image in the context of the system. In other words, the CyberMe may take on the appearance of the RealMe in this manner.
  • Another example of a brokered agreement or supplier push offer includes an offer valid for a specific duration by a professional photographer or videographer to photograph images of a RealMe's domicile and scan them into a digital format suitable for storage in the RealMe's profile in Attributes database 230. These images may be used subsequently in responding to other offers, for example for furniture.
  • CFM Consumer Feedback application 258 manages the consumer feedback process and the storage and retrieval of feedback data.
  • the objective of CFM 258 is to secure as much feedback as is reasonable on all product and services acquired by RealMe's through CyberMe. However it is only done if an individual RealMe has given permission, and then only in line with RealMe's interaction preferences.
  • Invocation of the feedback process can be stimulated in a number of ways. For those products and services ordered by RealMe for which status updates are being received from suppliers, it is the delivery confirmation status which triggers the feedback process. For those where no status updates are available from suppliers, the feedback process can be invoked either by RealMe confirming delivery, or alternatively the expected delivery date elapsing which stimulates a request for delivery confirmation prior to the feedback process being invoked.
  • Feedback from RealMe is not necessarily requested immediately after delivery confirmation.
  • the exact elapsed time between delivery confirmation and feedback request depends on the product/service type(e.g. feedback on a coat may be requested immediately after purchase / delivery, whereas feedback on a car may be requested four weeks later).
  • Such elapsed times are defined in the PSU 255, and can be held at any level in the PSU 255, but values held at higher levels are overridden by those at lower levels.
  • Feedback is typically requested by the CFM 258 via the Learning Manager 225, CM 202 and P 204.
  • Feedback is sought on both the product and service (e.g. useful to people to judge new products and services which have just been launched) and the associated supplier (e.g. useful to gauge the suppliers' capabilities from a service perspective).
  • Feedback templates which specify the information to be fed back are stored separately for different product and service types, so that the feedback requested can be varied to reflect the different nature of products and services.
  • the amount of feedback requested will be in line with interaction preferences (e.g. if RealMe is in "give it to me straight mode" on the WAP channel, they may simply be asked to give a satisfaction rating out often).
  • feedback can be analyzed in a variety of ways. For example feedback is aggregated, and statistical analysis can be undertaken. Feedback can be analyzed either on a product/services-basis for multiple suppliers, or on a supplier-specific basis for multiple products. Such analysis can be undertaken in real time by users, or by the MetaEngine 275 itself in background jobs. In both cases reports are generated by MetaEngine 275 which can be stored in MetaData 276 and subsequently retrieved at any time by a user for historical analysis through the MetaData Browser 277. Such reports can be sent through MetaData Pusher 278 to third parties, such as the suppliers themselves, consumers, publishing houses, market research companies, consumer associations, etc.
  • Supplier-specific feedback is used to monitor suppliers' performance over time, and ratify their supplier rating with a view to promoting, sustaining or demoting their rating, or indeed removing them from the SD 256 altogether if that is wananted.
  • Supplier-specific feedback is used to monitor suppliers' performance over time, and ratify their supplier rating with a view to promoting, sustaining or demoting their rating, or indeed removing them from the SD 256 altogether if that is wananted.
  • said product or service can be removed from the range of offers available from that supplier.
  • FIG. 10 shows an exemplary process by which the C2B 2 system of the invention determines the product or service indicated by a request expressed by RealMe and second those suppliers from which offers will be solicited.
  • CRP 250 retrieves the next (in order of submission by RealMe) new inquiry from RLM 221, for example the new inquiry conesponding to the raw inquiry "Fix my insurance" described in FIG. 7.
  • RLM 221 for example the new inquiry conesponding to the raw inquiry "Fix my insurance" described in FIG. 7.
  • CRP 250 conducts an intelligent search of PSU 255 for a match to a product or service, and for each successful match determines whether further resolution of the product/service type is required.
  • "insurance" was identified as the product/service; however, more information is necessary in order to determine which type of insurance is required.
  • the CRP's 250 objective is to get to the lowest level of the PSU 255, at which point the CRP 250 determines that no more information is necessary to define the product or service type.
  • the CRP 250 If the CRP 250 is unable to identify any product or service in the PSU 255 conesponding to that in the new inquiry, the CRP 250 logs the product/service as a nominated new product/service in the PSU 255, and the PSU initiates a process to identify, validate and subsequently confirm the nominated new product/service to the PSU.
  • the inquiry is logged as an unknown product / service, and at 1015 a specific request is put out to Reconnaissance Manager (REC) 283 to search for appropriate suppliers who are not cunently registered in the Supplier Directory 256 in order to get a Spidered Response 253a.
  • REC Reconnaissance Manager
  • a request for an unknown product/service is put out to Market Interactor 282 which puts the request out to the open Extranet site which registered suppliers can access to view requirements and respond to them - in this case no formal recipe is populated, since none can exist at this stage, however basic details about RealMe, as defined in a "Generic Recipe" (which applies to those products and services where a recipe does not exist), will be anonymously included with the request.
  • REC 283 spiders the Internet in search of potential suppliers, compiles a list of potential suppliers, including contact and product information where possible, and passes this list on to SAH 257.
  • SAH 257 contacts potential suppliers, for example via e-mail, and invites them to use the extranet site of the C2B2 system 100 to respond to RealMe's anonymous request (which is accompanied by attributes specified by a generic recipe in the absence of a specific one) and to formally register as a supplier 98.
  • shortlisted products and/or services, recipes, or suppliers are passed on to an appropriate calling procedure (e.g. Get Response, described in FIGS. 11 A and 11B.).
  • CRP 250 asks Recipe Workflow (RW) 263 to determine what resolution is required. For example, for insurance, RealMe may need to qualify if it is a car
  • RW 263 matches words and patterns of words in the description text and associated keywords fields in candidate PSU records 255a against words and patterns of words used in RealMe's request 221a in order to further qualify appropriateness of products and services to the request. In addition RW 263 considers the stored relevance of candidate products and services to RealMe as held in the conesponding PSU record. At 1030, RW 263 invokes CM 202 to construct a product / service resolution dialogue pattern to draw up a product/service shortlist (RealMe is allowed to select more than one by the Resolution process).
  • the constructed dialogue pattern comprises a series of questions which guide RealMe through the list of possibilities in order to target one or more type of product or service.
  • the dialogue pattern may result in one multiple choice question being asked to seek clarification on whether the insurance type is car / home / personal (more than one can be selected). If personal were selected then at least one more multiple choice question would be asked to clarify the type of personal insurance required, whereupon RealMe could again select more than one. The process would continue until all such required questions were answered or the selection process were cancelled or the cunent conversation postponed by RealMe. The result would be a partially completed or wholly completed product/service shortlist.
  • CRP 250 ranks product/service shortlist by relevance to RealMe. CRP 250 goes from 1005 directly to 1035 if no resolution is needed for a successful match.
  • CRP 250 searches SD 256 for suitable suppliers associated with the target products/services (e.g. local suppliers who are not local to RealMe's cunent, commonly visited or known planned locations will not be selected) and constructs a Supplier Shortlist.
  • the supplier shortlist is a temporary entity which is stored by the CRP 250 and uniquely relates to an individual request in the RLM. Thus there is one supplier-short list for each request in the RLM.
  • CRP 250 considers the immediacy of RealMe's requirement, as passed to it by RLP 220, and looks at individual supplier response lead times on PSU 255, and forms a judgement on whether obtaining a dynamic response 252a is feasible. If a dynamic response is feasible CRP 250 sets a Dynamic Response Indicator which indicates that a Dynamic Response is feasible in the time frame, and is held by the CRP 250 as relating to a specific request in RLM 221. hi addition, if CRP 250 finds a previously obtained dynamic response 252a conesponding to RealMe's requirement, CRP 250 will it to RealMe.
  • CRP 250 identifies associated recipe(s) and retrieves their maturity from RMAT 261.
  • CRP 250 invokes RW 263 to load the relevant recipe(s) onto a Recipe Queue held within RW 263, first in order of the product/service shortlist, then in order of the RR, as retrieved from RR 262, and requests LM 225 to do a focused learning session (FIG. 9B).
  • LM 225 matures recipe(s) on the queue as much as possible in the time available as indicated at the beginning of the session by RealMe at 908 in FIG. 9A.
  • CRP 250 filters out any identified suppliers for whom all associated product/service recipe(s) being targeted in the cunent learning session have not yet reached maturity.
  • FIGS. 11A-11C illustrate the process flows for the Get Response activities.
  • Get Response activities which include gathering immediate responses, issuing dynamic response requests, and processing dynamic responses, are designed to get responses to
  • immediate responses may be gathered for known products and services.
  • the objective is to gather immediate responses to get brokered, supplier push, and spidered responses that are immediately available and match RealMe's requirements.
  • CRP 250 determines if the request involves a known product or service. If the request involves a known product or service, CRP 250 proceeds to 1102.
  • CRP 250 searches brokered responses 251 for relevant deals, first by supplier shortlist, then by product/service shortlist, and finally by brokered response relevance.
  • Brokered Responses 251 and Supplier Push sources 254 relate to a known product/service in the PSU.
  • the description and associated key words fields are searched, e.g. a brokered deal for a chess course would relate to a product description "chess course” but would also have related key words such as "game”, "education”, “course” etc.
  • CRP 250 searches supplier push 254 and spidered responses 253 for relevant deals, in the same way that it does for brokered responses.
  • the Response Presentation function (as described in FIGS. 12A and 12B) run by CRP 250 is called to collate and present selected Brokered Responses 251a, Spidered Responses 253 a, and
  • FIG. 11B illustrates activities involving issuing dynamic response requests.
  • the Dynamic Response Request is designed to get a Dynamic Market Response for a new or extended inquiry in the RealMe inquiry memory within the time period that RealMe is seeking responses.
  • the CyberMe Response Processor ascertains whether or not the time scale stipulated by RealMe is long enough to secure a meaningful dynamic response from the market, as defined by the PSU for the associated product / service. If this is the case then the Dynamic Response Indicator is set.
  • CRP 250 adds the inquiry to a Dynamic Request Queue 252c, specifying whether it is new or extended, the probability of purchase and expiration date, and whether RealMe is to be proactively informed (alerted) when responses arrive, and passes it to Market Interactor (MI) 282.
  • MI Market Interactor
  • the MI 282 aggregates the request with other equivalent requirements (taking into account their respective probability of purchase and likely time frame of purchase). Such aggregation can take place at many levels e.g. Product type (e.g. insurance); specific product (e.g. Sun
  • Auction application 250b which is an application which can run a process whereby suppliers are given the opportunity to respond to a given aggregated demand within a defined time period. At the end of said time period the lowest-cost bidder who also met certain other stipulated criteria (e.g. product/service specification ; delivery methods etc) would win the auction and the right to supply the product/service to the RealMe's requesting it.
  • stipulated criteria e.g. product/service specification ; delivery methods etc
  • the Reverse Auction process could be invoked when a sufficient level of probably future demand for a specific product/service had been reached. For example, let us consider the case where the Demand Aggregation application has identified 1276 different RealMe's all saying that they want to buy a sports utility vehicle within the next three months, and that the probability of purchase averages out at 83% . If the Reverse
  • RA may also be used to create a brokered deal. Any bid submitted by a supplier participating in a reverse auction, whether or not the bid is good enough to win the reverse auction itself, may be asked by the Reverse Auction application if they would like to extend the validity of said supplier's bid to beyond that of the immediate terms and conditions of the reverse auction such that the associated offer, or an amendment of it, may be stored on the brokered deals database such that it can immediately be presented to RealMe's requesting the associated product or service.
  • RA 250b interacts closely with Market Interactor 282 to secure relevant responses from suppliers.
  • the Reverse Auction process is a well understood process, and cunently supported in certain forms by prior art systems, but an aspect of the present invention is the ability to dynamically create a reverse auction directly as a result of changing in real time actual and future intent as stipulated by a multitude of RealMes. Thus rather than having to search for an auction that meets their requirement, a RealMe can actually contribute to the invocation of one.
  • MI 282 Relevant Summary details of RealMe requestors are compiled by and stored in MI 282 (e.g. 10% are aged 20-30, 40% are 31-40 etc) according to the associated recipe requirements (all RealMe attributes that could reveal individual RealMe identities are stripped off).
  • a summary of selection criteria (the criteria that RealMe's have stated they will use to accept the responses received) is compiled by MI 282 (e.g. 70% want to save money, 20% want to acquire quickly, 10% want a long wananty).
  • RealMe 95 expresses a requirement to CyberMe 96
  • CyberMe asks RealMe to specify the probability of purchasing the conesponding product or service, the urgency of the purchase, and the most important selection criterion or criteria, i.e. selection drivers, for example price, service, wananty.
  • selection drivers are stored as part of the requirement 221a in RLM 221 and used by CRP 250 to prioritize responses from suppliers in a way that reflects what is important to RealMe.
  • MI strips off any attributes that could uniquely identify RealMe.
  • MI 282 puts the requirement with unique Dynamic Request ED 252d out to Shortlisted suppliers (who by definition are registered) in a format which meets Suppliers' individual requirements (e.g. XML, EDI etc), as stored in their conesponding supplier record 256a. Registered suppliers are reminded that they should respond in a specific format, to reflect the key details associated with the requested product/service.
  • Shortlisted suppliers who by definition are registered
  • Suppliers' individual requirements e.g. XML, EDI etc
  • MI 282 puts more limited details of the requirement with unique Dynamic Request ID 252d out to an Open Market Extranet site via the External Interface Manager (e.g. using HTTP) ready for responses from unregistered suppliers (from there opportunistic unregistered suppliers can make an offer).
  • suppliers are asked to respond in a specific format, reflecting the key details required in their response according to the product/service type being requested, unless the product/service type is unknown, in which case the response will be in a generic format, largely free form text.
  • Unregistered Suppliers who respond through the Open Market Extranet Site are asked to register a minimum number of details about themselves, so as to qualify as a one star supplier (e.g. company name, address, etc) - this information will be used to vet or validate the company, e.g. against credit rating records, from external data sources, e.g. Dunn and Bradstreet, accessed through ELM 210 (could be one such external source) or internal data sources held by SAH 257.
  • the system processes dynamic responses, as shown in FIG. 1 lC.
  • the processing of dynamic responses is shown in FIG. 11C and is designed to receive dynamic responses to RealMe request(s), screen them and communicate them back to RealMe, as appropriate.
  • Responses can be received from (i) registered suppliers for the product/service in question, (ii) suppliers who are registered for different products/services than the one in question, and/or iii) unregistered (i.e. as yet unknown suppliers).
  • suppliers submit their response in an agreed format, for example a response template 255d.
  • Each response template 255d has fields which must be filled in (e.g. if the product requested is a TV then the supplier must confirm the screen size in their response, amongst several other details).
  • Response template definitions are held in the PSU 255.
  • Each product and service in PSU 255 has at least one associated response template 255d.
  • the Response can be submitted via a variety of routes (e.g. Open Market
  • MI 282 receives incoming responses, checks their format against the relevant response template, validates their content, and then passes them to CRP 250 which vets each response against product/service requirement, RealMe selection criteria, etc. and stores the vetted responses 252a in Dynamic Response 252.
  • CRP 250 which vets each response against product/service requirement, RealMe selection criteria, etc. and stores the vetted responses 252a in Dynamic Response 252.
  • any RealMes for whom this Response is valid, and for whom dynamic response was requested are informed via their prefened alert channel(s) (e.g. SMS, email, fax, pager etc).
  • Response details are placed on CyberMe Response Database 250c with original inquiry ED 221b (assigned by and held in RIM 221) and are identified as a new Dynamic Response.
  • RealMe can set up a default time period for responses to be received from the time the inquiry is made (e.g. one week). This default time is stored as an attribute 231 in Attributes 230. PJP 220 uses the default time period for responses, if specified, to calculate the date by which responses should be received. This date is presented to RealMe, who is asked to confirm the date by which he or she would like to receive all responses. If RealMe specifies a new date, it is stored as the expiry date of the inquiry, else the default date is sustained. The expiry date is cross referenced against the lead time for responses for the associated product/service as stored in the PSU 255.
  • the lead time is set to a default value. If the requested date by which responses should be received is not compatible with the lead time, then RealMe is advised of this and told the earliest possible date by which responses can be reasonably expected and is given the opportunity to change the date. If the date is not changed then RealMe can elect to still submit their request to the market, such that the request would be marked as an urgent one, however one to which suppliers are not obliged to respond within the requested time period (i.e. responses provided later than the desired date would not affect the supplier's rating within the system 100).
  • inquiries are submitted to suppliers by MI 282, either by automated feed (for example, XML files obtained through the supplier's Internet provider network, EDI, or value-added network) or an extranet site, on the understanding that the date is one by which suppliers can be reasonably expected to submit a response, and is also specified with the request on the extranet site.
  • automated feed for example, XML files obtained through the supplier's Internet provider network, EDI, or value-added network
  • extranet site on the understanding that the date is one by which suppliers can be reasonably expected to submit a response, and is also specified with the request on the extranet site.
  • Interactor 282 from the extranet site (those submitted to suppliers who receive automated feeds via ELM 210 will be expected to observe the expiration date, and to cease responses and cancel the request on their systems after that date).
  • the status of the RealMe inquiry record 221a in RIM 221 is also changed to "expired", however responses that arrive subsequent to the expiry date may be accepted, if RealMe has stated, as an attribute 231, that this is acceptable. If this is not a stated preference and a late response arrives, then RealMe will be alerted and be asked if he or she would like to retain late responses generally.
  • Any late responses that are received and are acceptable to RealMe will be marked as being late on the CyberMe Responses database 250c and subsequently shown as being late when presented to RealMe.
  • the promptness of responses from suppliers will be monitored by the CRP 250, and those suppliers who submit late responses will be warned by SAH 257, either by email or some other prefened method of interaction. Consistent late submissions may result in the supplier's rating being downgraded by SAH 257.
  • FIGS. 12A and 12B illustrate exemplary processes whereby the CRP 250 presents responses to RealMe 95 when RealMe selects a View Responses menu option or asks CyberMe to view responses using, for example, natural language, through the conversation manager.
  • the CRP 250 gathers the responses that have been received since last session between CyberMe and RealMe 95.
  • CM 202 instructs RD? 220 to call CRP 250 to present Responses.
  • RIP 220 first asks RealMe to confirm that they are still interested in in-progress inquiries by retrieving in progress inquiries from RLM 221 and asking CM 202 to ask RealMe 95 if he or she wishes to cancel or postpone any of them.
  • Rff 220 also retrieves any inquires which have expired since the last session.
  • RIP 220 cancels or postpones inquiries in the RLM 221, by changing the status of the conesponding inquiry record, as appropriate, and CRP 250 deletes responses to cancelled inquiries (1204), and MI 282 cancels requests on extranet or submitted to suppliers via XML.
  • RIP 220 then ranks cunent inquiries according to RealMe's cunent focus and feelings as determined, e.g., by a feelings and focus session of the type described in FIGS. 6 A and 6B (e.g. if cunent focus is save money, rather than save time, then discounted deals are given a higher priority) (1206).
  • CRP 250 retrieves conesponding completed or in progress Responses and ananges them, according to the prioritization determined at 1206, in the CyberMe Response Database 250c.
  • FIG. 12B illustrates an exemplary process whereby CRP 250 shows responses gathered since the last interaction session between RealMe 95 and CyberMe (depending on the cunently active channel(s), a list of responses may be shown proactively (e.g. on part of a web page when RealMe is accessing CyberMe through the Internet) or may only be shown when requested by RealMe (e.g.
  • CM 202 selects a "Response Presentation" Dialogue Pattern from the database 202a.
  • P204 shows RealMe 95 the gathered responses, according to channel constraints, and CM 202 asks RealMe to select any of interest.
  • RealMe uses his or her CyberMe to select a response for purchase, RealMe is given the option of having it delivered in the normal way or, alternatively, having it collected. If collection is the prefened method, then a selection of one or more associated collection points will be offered, in the "cunent" and "likely future" vicinity of RealMe. Information from the Movement Assimilation module, discussed later in this document, if active for RealMe, will provide data on RealMe's cunent location. The "likely future" vicinity of RealMe is based on a combination of known frequently visited locations (as collected by the MA 208 and statistically analyzed by the MetaEngine 275) and RealMe's attributes such as home address and work address.
  • Collection points for a given product or service in the PSU 255 are stored in SD 256.
  • Supplier records in SD 256 have a field whose value indicates whether or not the supplier 98 is a collection point. (All collection points are suppliers.)
  • the locality information of all possible collection points for the supplier is retrieved (as described in the section on the SD within this document).
  • an appropriate selection list of collection points can be constructed and presented to RealMe. RealMe can at this point "nominate" a collection point or leave the collection point "open”.
  • RealMe is asked to specify a time window within which they plan to collect the product, such that the nominated collection point can ensure that the relevant product or service is reserved for RealMe for collection during the specified time period.
  • CRP 250 takes selected responses and invokes Commerce Engine 265 to complete the transaction, if appropriate - some Responses, e.g. free information found on theatres in London, may not require a commercial transaction to take place.
  • FIG. 13 shows an exemplary process, managed by Consumer Feedback Application 258, by which the C2B2 system of the invention acquires feedback from RealMe regarding products and services acquired by RealMe through the C2B2 system of the invention.
  • CyberMe responses in the CyberMe Response Queue which are at status "transacted", and which have delivery dates which are prior to the present date, are retrieved (1300). Records conesponding to suppliers who are registered to provide direct- feed status updates are then passed on to the Supplier Escalation Procedure 257a (1302), as discussed above. The remainder of the CyberMe Responses (i.e. those responses which have delivery dates prior to the cunent date and are from suppliers who do not have automated (e.g. XML) feeds to automatically update response status) have their status changed to "delivery due” (1304). The CM 202 is then called to ask RealMe to confirm delivery of products/services whose status is "delivery due” (1306).
  • CM 202 uses a Delivery Confirmation dialogue pattern and updates the response status to "delivery confirmed” accordingly (1308). Any remaining delivery due orders are passed to Supplier Escalation Procedure 257a (1310). "Delivery confirmed” responses, including those updated directly by feeds from suppliers, are passed to the Consumer Feedback application CFM 258 and associated database 258a to get feedback from RealMe (1312). CFM 258 interacts with CM 202 which selects a "Feedback" dialogue pattern. This pattern first asks RealMe whether or not they would like to give feedback on the relevant product or service for which they have just taken delivery and accordingly gets a Feedback Template from the conesponding product/ service record in PSU 255 (1314).
  • CM 202 then calls P204 to present feedback templates in sympathy with RealMe's cunent interaction preferences (1316).
  • Supplier specific feedback is stored in CFM database 258a and subsequently analyzed by MetaEngine 275.
  • the resultant analyzed data is stored in a supplier-specific part of MetaData 276 (1318).
  • General feedback is added to the product/service part of MetaData 276, described in detail below.
  • Layer 150 (Commerce Engine)
  • Layer 150 shown in FIG. 2G, comprises the Commerce Engine application (CE)
  • the Commerce Engine application (CE) 265 carries out core transaction processing within the C2B system and supports the various business models and revenue streams, both consumer and supplier-related, employed by the system, as discussed below.
  • the Volume Rider database (VR) 268 holds details of volume rider anangements with suppliers which are used by CE 265 to controls volume rider transactions through CE 265, where "volume rider" indicates a transaction in which the pertinent supplier pays a previously agreed upon volume based rebate to the owner/licensee of the C2B 2 system 100, e.g. via CH 270, upon delivery or refenal of a specified number of customers to the supplier by the C2B system.
  • the Clearing House application (CH) 270 facilitates payment between RealMe and the supplier of a product or service for which a transaction has been completed.
  • CH 270 A variety of payment methods from RealMe to a supplier are supported by CH 270, including direct funds transfer, credit card payment, direct debit of RealMe's account by the supplier (whereby RealMe authorizes their bank to accept direct debit requests from the supplier), standing order (whereby RealMe instructs their bank to submit periodic payments, such as monthly payments, to the supplier), and other payment methods as requested by RealMe and/or as different methods arise.
  • CH 270 supports payment from different bank accounts and through different financial service providers, such as credit card companies, as used by RealMe from time to time, and the pertinent account details are held in RealMe's Attributes. Generic details on banks and financial service providers are held in SD 256.
  • CH 270 also supports interfaces via ELM 210 to electronic wallets used by RealMe, such that pertinent information can be maintained within the payment wallets themselves but exchanged with RealMe's attributes 231 held in the system 100. While CH 270 supports many different payment methods, and supports payments through many different financial services companies, the funds transfer itself requires invocation through an extant financial clearing house network or method, and thus CH 270 provides for interfaces to one or more such clearing house networks or methods, known in the art, including but not limited to SWIFT, CHAPS, BAGS, EDI etc).
  • CH 270 also facilitates payment to the owner / administrator of the C2B system by third parties for services rendered, including but not limited to revenue shares from licensees or the C2B 2 system, volume rebates from suppliers, and click-through advertising revenues from suppliers.
  • a variety of transaction processing methods known in the art may be used to request and account for such payments, including but not limited to self- billing by third parties, and invoicing of the third parties as instigated by the Back Office System 271 on behalf of the owner / administrator of the system 100.
  • the exchange of such transactions and payments may also be supported by a variety of methods, including EDI (Electronic Data Interchange) and EFT (Electronic Funds Transfer).
  • CH 270 also facilitates payment from the owner / administrator of the system 100 to suppliers of goods and services to said owner / administrator. This is facilitated in the same way as described in the previous paragraph, but in this case payments are in the opposite direction, and are invoked.by the Back Office (BOF) 271, for example, as a result of self billing or receipt of an invoice from the pertinent supplier.
  • Back Office (BOF) 271 represents business support applications for the C2B 2 system, including, for example, accounting systems and ledgers, order status, procurement and sales systems, and management information systems.
  • the functionality required in BOF 271 can be, and is likely to be in most cases, provided by one or more "off-the-shelf enterprise resource planning systems such as SAP, Oracle financials, Baan etc. However, it can equally well be supported by bespoke application if needed.
  • BOF 271 interacts closely with CH 270 to facilitate payments to and from the owner/administrator of the system 100, as described in the preceding paragraphs.
  • CRM 272 Customer Relationship Management (CRM) 272 is a system which helps support the relationship between the owner/administrator of the system 100 and customers whether they be RealMe consumers, strategic alliance partners (e.g. entities with which the owner of the system 100 is in partnership to deliver at least a portion of the services made available through the system) or third party suppliers. It does so by monitoring all interactions with said customers whether the interactions be general inquiries about the service, requests for assistance or advice, complaints, transactions through the system 100, etc.
  • the functionality required in CRM 272 is likely to be provided in the most part by "off-the- shelf Customer Relationship Management systems such as Siebel, Vantive etc. Layer 160 (B2B System and Market Interactor)
  • Layer 160 shown in FIG. 2H, comprises the following elements: Meta Engine 275, Meta Data database 276, Meta Data Browser 277, Meta Data Pusher 278, Demand Pull Mentor 280, Demand Pull Definition Data 281, Market Interactor 282, and Reconnaissance
  • the Meta Engine application (ME) 275 uses data warehousing and mining techniques, as known to those skilled in the art, in order to obtain, aggregate, and analyze meta data ("data derived from data", i.e. statistical data) based on attributes defined for and populated by RealMes 95 and on other information provided to the system be RealMes and suppliers 98, e.g. customer feedback.
  • data derived from data i.e. statistical data
  • ME 275 periodically, for example as a daily batch ⁇ job during low-use hours, collects unrestricted data from the Attributes database 230 of a large number of RealMes updated since the previous database sweep, strips all such data of identifiers linking the data to a RealMe, analyses the data and stores the results of its analysis (its conclusions and summaries about the data which it has analyzed) in Meta Data 276.
  • attributes 231 which are restricted include those attributes characterized by RealMe as "private".
  • This application has extremely high flexibility in its ability to sort and collate such data and thus permits the early detection of new trends or behaviors. For example, this application may report on the number of 25 year olds looking to buy a new house in a specified region over the next three months.
  • the MetaEngine works in the background copying data from the rest of the system, and analyses it using a multitude of statistical and other analytical methods, from a multitude of perspectives, in order to derive trends, patterns and conclusions which may be useful.
  • Some analyses are pre-set, i.e. the MetaEngine always seeks to analyze the data of the system in some predefined way. Such pre-set analyses can be changed, added to and subtracted from.
  • Some analyses can be requested in real time, e.g. to service a benchmarking request from RealMe (benchmarking is term used to describe the process whereby RealMes can compare themselves against metadata derived from a plurality of RealMes, e.g. their peers, in a multitude of ways.
  • MetaData (MD) 276 is a database for storage of meta data obtained by ME 275.
  • MetaData 276 is a data warehouse which contains "data about data" held within the system 100. The data within it is harvested directly from other parts of the system 100 or, as in the most part, derived by the MetaEngine 275.
  • MetaData Browser (MDB) 277 is an application which enables authorized users, e.g. registered suppliers, to submit real time inquiries regarding meta data and receive responses based on meta data in MD 276 in any form, for example spreadsheet, printed report, graph, or word processed document through any appropriate medium, e.g. real time on-screen presentation, e-mailed response, etc.
  • MetaData Pusher (MDP) 278 is an application which allows the Demand Pull Mentor 280 and authorized third parties to receive reports electronically on a regular basis regarding selected topics of interest in a defined format, e.g. XML.
  • the format prefened by a supplier may be indicated by a field in the supplier record 256a in SD 256.
  • a clothing manufacturer may receive a weekly report on the recent buying behaviors of different demographic sectors, and also the expressed intent to buy apparel products in the near future.
  • suppliers can get to know much more about their end customers' behavior, since they are getting the information directly sourced in real time from consumers and in particular incorporating an articulation of future intent to buy, and not indirectly through retailers or intermediaries. Across a population of many consumers the value of this information becomes significant.
  • DPD 281 is a database which defines the "pull- through" between suppliers at successive levels within the supply chain of a given product or service, and spans all levels of the supply chain. DPD's 281 purpose is to enable the impact of the sale of one unit of a product or service to a consumer to be defined for all registered suppliers in the associated supply chain. All strategic suppliers (i.e. suppliers that are not changed regularly) at the different levels in the supply chain are defined by data records in DPD 281, along with the different "components" and/or raw materials and associated quantities that they provide to the next level up the supply chain for each completed unit sold.
  • DPM 280 takes projected demand levels of a given product or service, as provided by MDP 278, and uses DPD 281 to forecast and communicate pull-through demand for specific raw materials and/or components for suppliers situated at all levels in the supply chain.
  • DPM 280 supports numerous communication methods and media for disseminating such information, e.g.
  • the Market Interactor application (MI) 282 manages interaction with suppliers relating to consumer pull, demand aggregation and reverse auction processes.
  • RealMe requests (inquiries) and associated recipe data are communicated by CRP 250 to MI 282, which in turn presents the requests to the market. All the data presented to the market are stored in the RLM 221.
  • CRP 250 strips RealMe requirements of identifying data linking the requirement to the conesponding RealMe prior to communicating the requirements to MI 282, unless RealMe explicitly requests to be identified.
  • CRP 250 attaches to the outgoing request a dynamically created, random and unique identification code which will be used by suppliers to identify responses to the original request. The request is thereby presented, (according to RealMe's preferences) anonymously to suppliers. The CRP 250 stores the unique identification code in RLM 221. Responses from suppliers use the same identification code, which the CRP 250 uses as a key to reattach the personal data conesponding to the appropriate RealMe.
  • the default mode is for requirements to be presented anonymously to the open market through MI 282, which then obtains and pre-filters responses for obvious nonconformities, as determined through a comparison with the conesponding response template.
  • Valid responses are passed to CRP 250, which filters and ranks the responses according to relevance before presenting them to RealMe through CM 202 and P 204.
  • Responses are received from suppliers in response templates 255d which conespond to the product/service in question.
  • Response templates 255d are held in a Response Template database 255c linked to the PSU at the relevant level of the PSU hierarchy, and define a combination of data fields which when populated will fonn a specification of the product/service on offer, and associated terms and conditions.
  • the Response Templates are similar in principle to Recipes, only Recipes describe the information required to secure a response from suppliers, and Response Templates describe the information required to specify the product or service and associated terms and conditions in the actual response secured.
  • MI 282 interacts with both registered and as yet unknown suppliers (i.e. the open market) in order to secure dynamic response or "offers", which are then stored in DR 252.
  • Registered suppliers may view demand through several means including, for example, on their local systems via an XML feed and on an Extranet via an HTTP feed, as indicated by their record in SD 256, and are presented with more information than unknown suppliers.
  • Unknown suppliers may view more limited demand information through a public web site, through which they register with the C2B 2 system before viewing data.
  • the infonnation provided by a supplier registering through the public web site is communicated to SD 256 as well as the SAH application 257 for onward promotion within the supplier rating scheme.
  • MI 282 performs validation and checks the completeness and conectness of data in a received response according to the conesponding response. If such checks are not successful then MI 282 invokes the Supplier Escalation application 257a to inform the supplier that its response has been rejected.
  • MI 282 passes the response to the dynamic response database 252 (whose records bear a close resemblance to brokered response database records 251a) before invoking CRP 250 to filter and prioritize the response with respect to other responses to the same request.
  • the CRP 250 checks the response against the original requirement of RealMe. More exact matches are prioritized higher in importance than less exact matches. So, for example, if RealMe requests a wide-screen digital TV, and a response is received from each of two different suppliers, one for a wide-screen digital TV, and the other for a standard screen digital TV, then the former will receive a higher ranking than the latter. Responses with varying degrees of detail may be prioritized according to selection criteria specified by RealMe.
  • the CRP 250 filters replies to CyberMe by comparing information in each data field in each response record and/or offer from suppliers against submitted request records in the RFM 221, recipes in the Recipe Database 260, and information in RealMe's profile (and against the profiles stored in 3 rd person 236) in Attributes 230 so as to assure that offers relevant only to RealMe's outstanding requests and/or interests as specified in RealMe's profile are presented to him or her.
  • Data specified in attributes 231 stored in the 3 r person section 236 of Attributes 230 will also be used to determine the relevance of offers where RealMe has indicated as part of the inquiry completion process that the item desired is intended for a third party.
  • RealMe is provided with a list of queued responses (in a format which is determined by the P204 in cooperation with the CM 202, as described previously) which are categorized first by urgency of need, secondly by cunent focus, thirdly by product and service type, fourthly by suppliers and finally in the order in which responses were received from suppliers.
  • the presentation of responses will be possible over a variety of channels including Internet, interactive TV, SMS messaging, WAP, etc. in accordance with the user's prefened channel at a given time (which is stored in Attributes 230 as an attribute 231 characterized as having a "fast" volatility 231m).
  • the Reconnaissance Manager application (REC) 283 spiders the Internet, in a manner known in the art, for suppliers of new products and services or for new suppliers of existing products and services. Any new suppliers identified by REC 283 are made known to the SAH application 257 for formal automated or manual initial contact, subsequent supplier registration and onward promotion through the supplier rating scheme.
  • the washing machine is a unique product with a conesponding unique product ED listed in the PSU Database 255 and conesponding suppliers listed in the Supplier Directory 256. It is within the conesponding record 255a within the PSU 255 that the product is marked as being supported by Demand Pull Mentor 280.
  • the Demand Pull Mentor 280 checks the Demand Pull Definition Database 281 to confirm that there is a Demand Pull matrix conesponding to the unique product ED and the given geographic region of the intended delivery point of the product (as specified by RealMe, and if not specified assumed to be the default delivery address of RealMe, as stipulated within their Attributes).
  • the Demand Pull Mentor does so as a background job within the system. If no matrix yet exists for the product, then the product will not be marked in the PSU 255 as being supported by Demand Pull Mentor, and Demand Pull Mentor won't attempt to do anything.
  • the Demand Pull Definition Database 281 in this example identifies the companies in the washing machine supply chain, their relative position in the chain, and each company's respective supplier or suppliers. At the highest level (tier 1) is a specific retailer.
  • the retailer is supplied by a single washing machine manufacturer at the next lower level (tier 2).
  • the manufacturer is supplied by a number of component suppliers (for, e.g. chassis, washer drum, motor, control unit, etc.) at the next lower level (tier 3).
  • component suppliers for, e.g. chassis, washer drum, motor, control unit, etc.
  • tier 3 Each component supplier at tier 3 relies on a certain number of subcomponent suppliers at the next lower level (tier 4), and so on down through the chain. Note that not all suppliers will be defined in the supply chain - it is likely that they will mostly be strategic suppliers (i.e. regular suppliers), rather than inegular suppliers (who are sometimes used and sometimes not).
  • dummy suppliers can be set up, to emulate the presence of a regular supplier, when in fact the exact choice of supplier is made close to the point of purchase (this is particularly true of price- volatile commodities, where the exact supplier is not necessarily important - more the price and specification of the product in question at the time of purchase).
  • the information provided to the next supplier up the chain details the number of components / amount of raw material that is needed from the dummy supplier in the level below and the decision to select or nominate a specific supplier or suppliers to meet the required volume of components/raw material can be made nearer to the point in time of the purchase by the buying company.
  • Each registered supplier in the supply chain will have a conesponding record 256a stored in the Supplier Directory 256 - even though it may not itself be likely to be a direct supplier to consumers.
  • the Supplier Directory contains details of all suppliers, independent of their level(s) in the supply chain.
  • the manufacturer's (tier 2) component matrix identifies the finished washing machine as the item to be provided and the type and number of component parts to be ordered from the suppliers in tier 3 as well as expected time of anival of those components.
  • a tier 3 control unit supplier receives information identifying the type and number of control units to be supplied as well as the type and number of subcomponents (e.g. LCD display, dials, switches, etc.) to be ordered from tier 4 suppliers, along with lead time for each subcomponent.
  • the Demand Pull Mentor 280 having retrieved the Demand Pull matrix, makes available, either by providing proactively in secure electronic form to an agreed file format (e.g.
  • XML, EDI via a third party value added network or other means of electronic file transfer, or alternatively by physical media such as a DVD, which would be physically sent to the supplier. It can also be provided through other media such as in a written report or spreadsheet format by fax or email attachment.
  • information can be submitted by said means to an industry -vertical B2B portal, rather than directly to the relevant supplier itself.
  • Such vertical B2B portals, or "vortals" as they are sometimes refened, are becoming a popular means of conducting business-to-business transactions between companies in the same or associated industry sector (e.g. automotive) of which the supplier may be a member, such that the information can be subsequently transfened to the supplier by the said portal.
  • Suppliers can also gain access to their Demand Pull information via a secure extranet interface that permits them to securely browse and print said information over the Internet.
  • this information be conveyed (in as wide as range of methods and means as is practicably possible in order to meet the different capabilities and requirements of different suppliers).
  • the conesponding infonnation to suppliers in the matrix which are thereby notified immediately and simultaneously of the demand for all components in their respective component matrices and the delay that can be expected at each point in the supply chain.
  • the latter information is critical to determining how far in advance of demand the various points of the supply chain must be in order to satisfy the expressed future demand for the washing machines.
  • Layer 170 (MicroCosms, e.g. CyberMall) Layer 170, shown in FIG. 21, comprises two main components, Movement
  • Movement Assistance 284 and MicroCosms 286. Movement Assistance 284 will be described first.
  • Movement Assistance 284 provides advice and guidance to RealMe when moving from one location to another. For example, if analysis of the movements logged by the MA application 208 and stored in the Movement Assimilation Data section (MAD) 239 of Attributes 230 indicates that RealMe is making the same journey regularly, and there is an opportunity for saving time through using a different route then CyberMe will use a
  • RealMe's specific co-ordinates and journeys are stored in MAD 239.
  • Generic movement information such as the average speed of traffic through a particular point on a motorway or freeway (as can be commonly obtained from traffic management services), is stored within the Generic Movements database 285a attached to the Movement Assistance 284 module. This type of information is useful if it is known that RealMe has embarked on a journey during which they are likely to pass through a certain location.
  • Products and services can be offered to RealMe by CyberMe either proactively or reactively during the course of a Journey.
  • services will be proactively offered in line with Health and Safety guidelines, e.g. drivers of road vehicles may be advised to take at least one 15 minute break every 4 hours.
  • RealMe's own preferences which may ovenide the defaults, e.g. "give me a break every 2 hours, and get me somewhere where I can have a tall skinny decaf latte.”
  • RealMe is able to define dynamic attributes concerning how CyberMe is to deliver journey assistance services, which include the type of journey being undertaken (e.g. leisure/business) and the main routing drivers, e.g.
  • MA 208 anticipates the arrival of RealMe at MicroCosms 286, and depending on RealMe's preferences, will transmit (the default is anonymously) attributes
  • MAD 239 is partitioned into four main sections: My movements 239a, My journeys 239b, Journey plan 239c, and Microcosms within range 239d.
  • My movements 239a stores RealMe's co-ordinates in real time.
  • My journeys 239b stores journey plans that RealMe has previously embarked upon.
  • Journey Plan 239c stores details of a journey that RealMe is cunently embarking upon.
  • a journey comprises a sequence of one or more journey stages, each of which has a starting point and destination point.
  • MicroCosms within range 239d stores details of Microcosms which may be cunently within range of RealMe.
  • FIG. 14A shows an exemplary process for periodically checking RealMe's position and detecting movement. Movement information is periodically gathered through cunently active channels (as described in FIG. 3) and stored in the "My Movements" part of MAD
  • the Journey Detector process continually runs in the background and uses statistical analysis, pattern matching and fuzzy logic to analyze RealMe's movement information in database 239a, comparing it to known journey patterns in the My Journeys database 239b to detect journey commencement and likely mode of transport (based on average speed on location) (1404). Once journey commencement has been detected, "My Journey's" log referenced and possible known journeys are retrieved and the probability of a previous known journey being the same as the cunent in progress journey is assessed (1406). RealMe is then asked to confirm if he or she is on a journey, and is presented with a "pick list" of possible known journeys and likely transport mode, in addition to the option of defining a new journey (1408).
  • RealMe is then asked if he or she would like help in planning the journey (1410). If yes, LM 225 is called to complete a Journey Recipe 260b.
  • the Journey Recipe 260b is held in the Recipes database 260 and is a template for holding details of a journey.
  • RealMe creates a Journey Plan that is stored in the Journey Plan database 239c while the journey is in progress, and subsequently is stored in the My Journeys database 239b for referencing later.
  • Journey templates are referenced and presented, and RealMe selects a route (1412).
  • RealMe is asked if he or she wants to describe his or her own route to CyberMe using, for example, plain language, which is then interpreted and cross-referenced against known journey and routing templates stored in database 285b (1414). If yes, the journey details are stored in the Journey Plan in the Journey Plan database 239c. If not, the movement assimilation process ends (1420). Having defined a Journey Plan, RealMe is asked if he or she wishes to enable the Journey Mentor 285, an application which serves to assist RealMe while the journey is in progress, as described more fully below, to help them en route (1416). If yes, Journey Mentor 285 is enabled (1418). If not, the movement assimilation process ends (1420).
  • FIG. 14B shows in exemplary fashion the operation of the Journey Mentor 285.
  • the Journey Mentor 285 first checks to see if a Journey Plan is available (1430). If yes, the
  • Normal Mode is set (1432) and details of the first stage of the Journey are retrieved from the Journey Plan (1434).
  • the RealMe position sampling rate is set to a default value, unless the ETA and expected average speed demand a higher sampling frequency.
  • the Predictive Mode is set (1436) and, based on cunent direction, a notional cunent stage is created in the Journey Plan, with a predicted destination and ETA, against which journey progress can be measured (1438).
  • channels that will provide information on trouble spots for current and subsequent journey stages are selected from the Journey Assistance services part of PSU (1440).
  • the most recent time-stamped coordinates are then retrieved from the "My Movements" log stored in MAD 239 (1442).
  • a stage transition flag is also stored in the Journey plan 239c database, which indicates whether or not RealMe is approaching the end of a journey stage.
  • the Stage Transition Flag is then checked to see if it is set (1444). If not, the cunent average speed and direction are ascertained (1456). If yes, it is further checked whether RealMe is at the end of the final journey stage (1446). If yes, then the Journey Plan is deleted and, if not already present is moved to the My Journeys database 239b (1448) and the Journey Mentor ends (1468). If not, then the cunent co-ordinates are checked to see if they are in line with next stage (1450), the next stage is set to cunent stage (1452), and the stage transition flag is turned off (1454).
  • the cunent average speed and direction are ascertained (1456). If direction is not in line with cunent stage of Journey Plan, RealMe is asked to confirm if the cunent journey is still in progress (1458). If not, then Journey Mentor ends (1468). If yes, then the ETA at the end of the cunent stage is calculated, and if there is a deviation beyond a certain tolerance, then RealMe is asked to report the reason (e.g. an as yet unreported trouble spot, or RealMe wants to slow down a bit, etc.) (1460). Any problem reported by RealMe is stored on a Generic Movements database 285a connected to the Journey Mentor application 285, if the problem has not already been registered e.g. by an external source.
  • reason e.g. an as yet unreported trouble spot, or RealMe wants to slow down a bit, etc.
  • a new ETA is stored at end of the cunent stage, and ETAs of subsequent stages are recalculated (1464). If the ETA is within X minutes of the cunent time, where X is dynamically calculated to reflect the cunent speed of approach, then the Stage Transition flag is set (1466), and the process repeats, beginning at 1442.
  • a Journey Plan stored in database 239c comprises several Journey Stages.
  • FIG. 2J shows an example of a planned journey, the example comprises four stages from, for example, location "a" to location "e". Each stage is a subsection of the overall journey, from one known en-route location to a successive known en-route location.
  • the route taken from the start to the end of a given stage will not necessarily be in a straight line, as illustrated by stage 2, and indeed is unlikely to be.
  • different stages are unlikely to be the same distance. They tend to become shorter at parts of a route which change direction frequently, or are renown for trouble spots or congestion.
  • FIG. 2K is an illustration of the MicroCosm tunnel which has been constructed for a journey stage from X to Y. MicroCosms A, B, C, D and E have all been identified as members of the MicroCosm Tunnel for this journey stage. Although MicroCosm E does not directly lie on the journey stage X->Y it is within an acceptable distance ("tunnel range") of the stage route and therefore is included.
  • the tunnel range can be set as an attribute 231 by RealMe in the attributes database 230.
  • MicroCosms 286 will now be described.
  • MicroCosms 286 are, for example, localized market hubs which may have been specifically built or modified to detect the anival of a RealMe and to enable dynamic responses from the localized market in response to the needs and wants of CyberMe.
  • Exemplary MicroCosms 286 include the following: CyberMall 295, a shopping mall, compliant with the C2B 2 system of the invention, which hosts multiple CyberVendors 296; CyberRegion 299, a C2B 2 -compliant geographic region, which encompasses multiple CyberVendors 296, CyberMalls 295 and/or CyberBuildings 297; CyberBuilding 297, a C2B 2 -compliant building, which is responsive to the attributes of RealMe (e.g. a hospital, a museum, an office etc); CyberVendor 296 a C2B 2 -compliant retailer; and CyberTrans 298, a C2B 2 -compliant means of transportation (e.g. car, train, bus, aircraft, etc.).
  • CyberMall 295 a shopping mall, compliant with the C2B 2 system of the invention, which hosts multiple CyberVendors 296
  • CyberRegion 299 a C2B 2 -compliant geographic region, which encompasses multiple
  • MicroCosms 286 have several common characteristics, including the following: by using CyberMe Movement Assimilation technology (as embodied in MA 208) they may detect the arrival of a RealMe, for example by detecting their CyberLD tag, mobile phone, PDA, or other C2B 2 -enabled channel equipment; upon anival, RealMe is invited through his or her CyberMe to interact with the MicroCosm.
  • Some MicroCosms 286 have "Landing Points" 289, such as an Internet cafe or kiosk, which enable RealMe's to interact via a high bandwidth channel (e.g. Internet) upon arrival, rather than having to use more restricted channels (e.g. WAP-enabled mobile phone).
  • Some MicroCosms 286 may offer high bandwidth Portable Service Assistants (PSA) 290 to RealMe's during the period of their stay, specialized PDA's enabling rich mobile interaction and barcode reading capability and also high-resolution movement assimilation, whereby the location of the PSA 290 can be determined to within a few centimeters using one of variety of techniques known in the art including triangulation radio signals and global positioning systems.
  • PSA Portable Service Assistants
  • a PSA may convey a multimedia map of a CyberMall 295, show shopping items acquired at any point in the visit, compare prices between different CyberVendors 296, as well as being able to "scan in" details of purchased products, e.g.
  • MicroCosms 286 make use of detection means known in the art to detect the movement of RealMe throughout their vicinity to a high level of accuracy.
  • the location of Global Positioning System (GPS) devices can determined to a high level of accuracy, e.g. to within a few meters. GPS devices are small enough to be incorporated into other devices such as mobile phones and/or PDA's.
  • GPS Global Positioning System
  • Radio transmission devices such as mobile phones and/or PDA's
  • the position of Radio transmission devices can be determined to within less than a meter by triangulation methods, whereby the difference in time of receipt of a given "signature" signal from the transmission device to at least three disparate radio receivers, which themselves are in a known position - such methods would be particularly suitable for controlled MicroCosm environments such as C2B 2 -compliant CyberMalls 295 wherein the required technology and equipment can be installed.
  • a MicroCosm 286 can be a MicroCosm in its own right.
  • CyberVendors 296 may have C2B 2 -compliant Electronic Point of Sale (EPOS) systems 288 which are connected to CH 270 and CE 265 of the C2B 2 system 100.
  • EPOS Electronic Point of Sale
  • a MicroCosm 286 may have its own MetaEngine application 275' and MetaData database 276' for servicing its own CyberVendors 296. Larger MicroCosms 286 may have a local Routing Engine 287 which is tasked with scheduling visits to different CyberVendors 296 on behalf of RealMe and optimizing the routing.
  • a MicroCosm 286 functionally replicates and effectively overrides a subset of the C2B 2 system functions when RealMe is in the vicinity of the MicroCosm and gives the MicroCosm 286 permission to do so.
  • a functional overview of an exemplary MicroCosm 286 showing those aspects of the universal system 100 which are replicated on a local level may be seen in FIG. 2L.
  • MicroCosm 286 Interaction between RealMe 95 and the MicroCosm 286 may be secured through the MicroCosm's own local ELM 210', Security and Controls 206', P 204', CM 202', MA 208', and HNI 200' applications (in particular, a MicroCosm 286 which supports PSAs 290 will have the latter four applications on a local level.)
  • a MicroCosm 286 typically has its own local PSU database 255', Supplier Directory database 256', Supplier Adoption and Hosting service 257', Brokered Response 251', Dynamic Response 252' and Supplier Push 254' databases for its participant CyberVendors 296.
  • a MicroCosm 286 may also have its own Recipes database 260', in order to facilitate variations in the Recipes used by the universal C2B 2 , in which case it will have the capability to securely download RealMe's pertinent attributes 231 from the universal C2B 2 system 100 via EIM 210' in order to support a specific requirement from RealMe.
  • a MicroCosm does have its own recipes it will determine locally the recipe relevance and recipe maturity for the duration of the visit of RealMe, and in addition will interact with RealMe via CyberMe through local recipe workflows to get additional attributes as required.
  • the universal C2B system 100 has access to the MicroCosm recipes 260a', recipe relevance 262a', etc., so as to permit updates when appropriate into the conesponding universal databases (e.g. Recipes database 260 and Recipe Relevance 262).
  • Full information exchange capabilities are provided between the universal system 100 and a MicroCosm 286, as well as other MicroCosms of which it may be a part, above it, below it or at the same level according to the MicroCosm hierarchy, such that, for example, MicroCosms 286 can first be initialized and primed with relevant recipes etc., from the databases in the universal system 100, but also such that if a MicroCosm alters such recipes or other information, the altered recipes 260a', etc.
  • the Supplier Directory 256 of the universal C2B 2 system 100 holds details of MicroCosms within it, which in turn can hold details of MicroCosms within it, thus enabling nested MicroCosms to any number of levels.
  • a MicroCosm can be registered within the Supplier Directory 256' of more than one MicroCosm and/or the universal C2B 2 system 100. This allow the relationships between MicroCosms to be reciprocal (i.e. two different MicroCosms can be registered with each other). This anangement allows for full flexibility in the relationships between different MicroCosms and/or the universal C2B 2 system.
  • the SD stores the locality of a given MicroCosm.
  • the locality of a MicroCosm may by three dimensional, in the sense that it is not just the two dimensional foot print that is important for some types of MicroCosm.
  • CyberVendors 296 within a CyberMall 295 could co-exist on the same 2-D foot-print (the physical area of the surface of the Earth covered) but be situated on different stories of the CyberMall 295. This becomes significant when Movement Assimilation seeks to detect the arrival of RealMe within a particular MicroCosm.
  • CRP 250 processes supplier push offers 254a', brokered responses 251a', and dynamic responses 252a' which are restricted to the suppliers within the MicroCosm 286 cunently selected by RealMe (which may or may not include the universal C2B 2 system 100); no spidered responses from the Internet are sought or processed, as these are dealt with by the universal C2B 2 system.
  • Dynamic responses 252a' offered by a MicroCosm 286 are secured through the MicroCosm's own Market Interactor 282' which interacts solely with CyberVendors 296 within the MicroCosm itself (registered within the MicroCosm's own Supplier Directory).
  • MicroCosm 286 is nested within another, for example a CyberVendor 296 could constitute a MicroCosm in its own right, which sits within a CyberMall MicroCosm 295, then RealMe is given the option of interacting with one or the other or both.
  • the present invention enables the CyberVendor 296 to make a tactical decision not to register all its products and services on the CyberMall PSU 255' - but instead a reasonable subset thereof - such that the full product and service set offered by the CyberVendor 296 would only become available to RealMe when RealMe enters the CyberVendor and agrees to interact with it.
  • CyberVendor 296 it is noted, however, that for the CyberVendor 296 to qualify as a CyberVendor within the overarching MicroCosm they are likely to be have to offer some minimum limit of their product and service range in the wider MicroCosm in order that the unique market dynamics of the C2B 2 model are naturally preserved to some acceptable extent.
  • CyberVendor 296 within CyberMall 295 as nested MicroCosms
  • RealMe while RealMe is in a CyberVendor store, he or she may choose to interact with the CyberVendor 296 rather than the CyberMall 295 in which the CyberVendor is physically located, thereby overriding the CyberMall MicroCosm 295.
  • RealMe can elect to "zoom in” on products and services in their immediate environs, and “zoom out” again as and when they choose.
  • the universal C2B 2 system 100 maintains a directory of MicroCosms within the universal Supplier Directory 256. Therein MicroCosms are registered as a supplier of type MicroCosm, with the conesponding MicroCosm type also being stored, e.g. CyberMall 295, CyberVendor 296, etc. MicroCosms equipped with their own SD 256' (which replicates the function of SD 256) can also have MicroCosms registered within them in the same way. However, unlike the universal SD 256, a Microcosm's SD 256' does not keep a record of all MicroCosms.
  • RealMe can interact with a MicroCosm by proactive selection e.g. by selecting it formally from a list of MicroCosms derived from the SD 256 of the universal C2B 2 system or on SD 256' of a MicroCosm with which they have already engaged. Such a list would be accessible by request from their CyberMe, e.g. by using natural language such as "show me
  • MicroCosms By selecting from a MicroCosm option accessible when interacting with CyberMe. In the case where RealMe is not in the vicinity of the MicroCosm, they may well choose this option if they know they are going to be visiting a MicroCosm in the near future.
  • CyberMe can offer RealMe interaction with a MicroCosm whether or not RealMe is in the vicinity of the MicroCosm. In the former case the near proximity of RealMe to the MicroCosm must be detected, and consequently trigger the offer of interaction with the relevant MicroCosms.
  • the position of RealMe can be assimilated by the universal C2B 2 system 100 as described previously in connection with Movement Assistance 284.
  • a locality can be stored which defines the geographic coverage of the MicroCosm. The overall effect is that a logical list of MicroCosms, including their locations, is stored and maintained by the universal C2B 2 system.
  • the location of RealMe is continually monitored by Movement Assimilation 208, and checked against the MicroCosm directory. Any MicroCosm with which RealMe comes into close proximity is thus immediately identified.
  • the co- incidence of RealMe and the MicroCosm causes the MicroCosm identified to be stored in a list in the "MicroCosms within Range" section 239d of the MAD 239 section of Attributes 230.
  • the identity of the MicroCosm and a short description are included in the list (e.g. "Bluewater: largest shopping mall in Queensland”). If alerts are enabled by RealMe, and RealMe has specified that they want to be alerted of MicroCosms within range, and an alert chamiel (e.g.
  • SMS text messaging to their mobile phone, or a perhaps a pager is cunently available
  • an alert message is sent to RealMe to inform them that they have entered a MicroCosm.
  • RealMe wants to interact with the MicroCosm, then they connect to their CyberMe and instruct it to "engage" with the MicroCosm.
  • RealMe after having engaged with a MicroCosm when in the vicinity of a MicroCosm, RealMe subsequently strays away from the locality of the MicroCosm, as detected by Movement Assimilation, then CM will warn RealMe that they are getting out of range of the MicroCosm. RealMe can at that point formally disengage from the MicroCosm.
  • RealMe can interact with a MicroCosm without being near to it, RealMe can continue interaction with it, even if RealMe strays a significant distance away from it (e.g. by getting on a train and traveling to another location altogether).
  • RealMe is proactively alerted that a MicroCosm in within range, then in order to connect to their CyberMe, RealMe must use an interactive channel such as a WAP phone or the Internet.
  • the channel used to alert RealMe of the fact that they entered a MicroCosm would not necessarily be interactive (SMS text phones or pagers are transmit channels only). If, for example, RealMe is canying a WAP-enabled mobile phone with SMS capability, by which they received the original MicroCosm alert message by SMS, then they can use the same phone to connect to their CyberMe in order to register with the MicroCosm over WAP.
  • the MicroCosm itself may offer "Landing Points" 289, as described above, which provide Internet-channel interaction facilities to enable RealMe to connect with their CyberMe, register with the MicroCosm and plan their time within the MicroCosm. The registration process is quick and simple to complete.
  • RealMe connects their CyberMe is aware of the "MicroCosms within range", and through Conversation Manager offers RealMe the option of connecting to one or more of them.
  • MicroCosms can nestle within other MicroCosms, so it will not be uncommon to come into range of several MicroCosms at the same time.
  • MicroCosms In this case the hierarchy of MicroCosms will be described to RealMe such that they can select one or more of them. It is anticipated that most RealMe's will want to initially register with the overarching MicroCosm, and then register with "child" MicroCosms if and when they want to "zoom in” on them. Registration simply involves RealMe selecting one or more MicroCosm displayed in the "MicroCosms within Range” list, and identifying whether the selected MicroCosms are to be joined with or replace the cunently active MicroCosm(s) and/or the universal C2B 2 system 100 (if cunently active).
  • CM 202 asks RealMe how much time they are planning to spend in the MicroCosm . If RealMe is in the vicinity of the MicroCosm it is more than likely to be as from the cunent time. However if RealMe is not in the vicinity, then it is assumed that RealMe is planning a future visit, and the intended duration of the visit is requested.
  • RealMe is in the vicinity of the MicroCosm, and they have a vehicle with them they can declare the identify and position of the veliicle. This information can be used by RealMe to nominate their parked vehicle as a delivery point for goods and services during their visit. If RealMe's vehicle is a CyberTrans 298 then this information can be automatically acquired by the MicroCosm when the vehicle is parked (discussed later in CyberTrans section).
  • RealMe's can declare themselves part of a CyberGroup comprising more than one RealMe, who are effectively to be treated as one virtual group. This enables the MicroCosm to identify common interests and requirements to make the visit as rewarding as possible for every member of the group.
  • RealMe's may become part of a CyberGroup as part of the initial engagement sequence between the MicroCosm and RealMe.
  • One member of the group will be permitted to create the CyberGroup and give it a pseudonym (e.g. "Yale on tour"). If other members of the group, or in deed people out side the group try to create a CyberGroup with the same pseudonym then they will be prevented from doing so as long as this CyberGroup exists.
  • pseudonym e.g. "Yale on tour”
  • the maximum length of time that a CyberGroup can exist will be set as a default value by the MicroCosm owner/administrator (e.g. one day, or one week).
  • the default length of time chosen is likely to be a function of the type of MicroCosm that it is. If it relates to a ski resort for example, then a CyberGroup may be permitted to exist for weeks or months at a time. However if it relates to a CyberTrans 298, e.g. a train, for which the maximum length of any journey in any single direction is one hour, then the maximum lifetime that the CyberGroup can exist may well be set to one hour.
  • CyberVendors 296 within a CyberMall 295 may be affiliated to one or more suppliers in the universal system 100, as indicated by data in the conesponding records in SD 256.
  • the relationship between the CyberVendor 296 and the supplier may be such that the CyberVendor acts as a "collection point" on behalf of the supplier, i.e. where RealMe's can collect the product or service being offered by the supplier.
  • RealMe registers with a MicroCosm RealMe's "open collect” list of products / services is downloaded to the MicroCosm.
  • the MicroCosm presents back to RealMe via CM 202 potential collection points for the relevant products and services that are proposed to RealMe such that RealMe can nominate collection points within the MicroCosm.
  • RealMe Prior to a visit to a MicroCosm, RealMe may nominate a collection point within it for a particular purchase, such that when RealMe does visit, CyberMe reminds RealMe and asks RealMe if they want to collect the product/service during the cunent visit.
  • Any collection points nominated and/or confirmed are temporarily stored such that when the Routing Engine in invoked, which creates a route plan for RealMe's visit, it incorporates the collection points into the route plan (see below).
  • the Routing Engine in invoked, which creates a route plan for RealMe's visit, it incorporates the collection points into the route plan (see below).
  • RealMe is asked by CM 202 to enter any new wishes or requirements that they want to be considered during their visit to the MicroCosm.
  • CRP 250 securely connects with the MicroCosm 286 to intenogate the MicroCosm's Brokered Deal database 251' in order to secure immediate responses to RealMe's current requirements, as held by RIM 221.
  • Brokered responses 251a' and dynamic responses 252a' may be acquired which are not in direct response to the RealMe's current requirements, but are deemed to be high in relevance to RealMe according to RealMe's attributes by the CRP.
  • RealMe can enter wishes at any time during their visit, however they are encouraged to do so at or before the time of entry such that all RealMe's requirements can be taken in to account if and when an optimal plan/route is requested by RealMe to make their visit to the MicroCosm as productive as possible (discussed below).
  • CM 202 uses a MicroCosm Routing and
  • the CRP 250 presents RealMe with brokered responses 251a' and any received dynamic responses 252a' from member CyberVendors 296 within the MicroCosm (filtered and prioritized according to RealMe's preferences). Responses not directly conesponding to RealMe wishes (held in RLM 221), but gathered as a result of the relevance of products and services to RealMe, are also presented, however they are shown lower down the list of responses, since they are of lower relative priority.
  • RealMe is asked to action any responses they are interested in.
  • the actions possible are a) normal selections, as available through the universal C2B 2 system or b) request a visit to the relevant CyberVendor 296 a) RealMe can treat all responses received from the MicroCosm in the same way that they treat those received through the universal C2B 2 system (i.e. select them and confirm purchase and specify delivery or collection; or ignore/delete them).
  • RealMe In the case of purchases, most are likely to be for collection since RealMe is by definition either within or planning to be within the vicinity, although delivery may also be possible either to RealMe's vehicle within the parking lot, if they have one with them (as confirmed during the registration process), in addition to a delivery address specified by RealMe (the delivery options will be clear in the details of the response and will depend on the supplier's capabilities/scope of service)).
  • RealMe can instead select and prioritize any such response for a "formal” or "informal” visit.
  • a "formal” visit is one where RealMe makes an appointment to see a sales assistant (i.e. a member of staff) for discussion / demonstration of one or more products and services being offered by the relevant CyberVendor 296.
  • An informal visit is one where RealMe does not specifically want to see a member of staff but would like to visit the CyberVendor 296 to examine the product / service on offer. If RealMe selects one or more products/services for a formal or informal visit from a particular CyberVendor, but there are other products and services from the same CyberVendor 296 (in the list of Responses received from the MicroCosm in response to RealMe's requirements) which RealMe has not selected, then RealMe may be asked by the Conversation Manager (either of the global system 100 or of the MicroCosm 286) as a normal part of the Routing and Scheduling dialogue pattern and dependent on RealMe's interaction preferences at the time) to confirm whether or not they want to take the opportunity to also view said other products and services while they visit the CyberVendor 296.
  • the Conversation Manager either of the global system 100 or of the MicroCosm 286
  • CM asks RealMe at what pace they would like to move around the MicroCosm (e.g. "brisk” or “leisurely”). This information can be used by the Routing Engine to forecast the amount of time it will take RealMe to get from one shop to another, and how much time they will spend on each product/service that they are interested in.
  • CM asks RealMe what "style” they are taking to the visit. E.g. is it a "window-shop” when RealMe has come to browse the offerings of the CyberVendors 296 within the CyberMall 295, and almost as a side activity pick up any products and services that are on their requirements list, or "focused” where RealMe wants to focus on a particular selection of products and services with very limited browsing of other products and services.
  • the MicroCosm's Routing Engine 287 operates on the same principle as that described earlier under Journey Mentor 285. That is to say various journey stages are constructed to form a Journey Plan, which is based on a Journey Recipe 260b. Each journey stage is a route from one point in the MicroCosm to another.
  • MicroCosm is a CyberMall 295, for example, then each journey stage is likely to start and end with a different retail outlet (CyberVendor 296) within the CyberMall 295.
  • CyberMall 295 the selection of the sequencing of different shops will be a function of the products and services that RealMe is interested in (as communicated to the MicroCosm's Routing Engine), and the relative importance of those products and services to RealMe, and in addition the amount of time that RealMe has to spend within the CyberMall 295.
  • the journey recipe associated with a MicroCosm allows for the fact that RealMe spends time at the end of given Journey Stage before commencing on the next one, to the extent that more time is typically spent by RealMe between stages than actually in transit on the stages themselves.
  • the way the routing algorithm is designed in the Routing Engine 287 is such that the time spent by RealMe at the end of each journey stage before commencing the next one is a parameter that can be set from 0 to some other period of time.
  • this parameter is set to 0 for each journey stage, unless the journey stage ends at a location where a break in the journey is scheduled (e.g. to visit a service station or take a break).
  • this parameter is set separately for each journey stage and is a function of the sophistication of the products or services that RealMe is interested in seeing at the CyberVendor 296 at the end of the Journey Stage in question.
  • each product and service held in the PSU of a MicroCosm has two associated parameters which describe the amount of time that reasonably needs to be spent in order for a typical RealMe to fully assimilate said product a) for a formal visit and b) for an informal visit.
  • the exact length of time set for a product or service may initially be defined by the conesponding supplier/CyberVendor 296, however in recognition of the fact that suppliers tend to want people to spend more time than less time examining their products, the invention incorporates the capability for this FIG. to be ratified and amended by expert third parties, such as consumer associations, who may give a more objective view of the specified time.
  • the Consumer Feedback module incorporates into its feedback templates optional questions which enable RealMe's to report back whether they felt they spent enough or too much time examining a product or service prior to purchase. If they felt that they spent not enough or too much time, then they are given the option of suggesting what the ideal period of time would have been. This serves two purposes a) enables fine tuning of a default FIG. in the PSU, b) permits RealMe's preferences to be factored in by the Routing Engine.
  • the MetaEngine 275 in the universal system 100 examines this information over time, and updates conesponding product/service records in the central PSU, which in turn can provide downloads to MicroCosms in order that their local Routing Engine can subsequently create routes and schedules which are better optimized.
  • an adjustment factor is stored as part of RealMe's attributes, which downloaded to a MicroCosm's Routing Engine as part of the registration process, such that the default FIGS, can be adjusted to reflect RealMe's needs.
  • the MetaEngine uses historical analysis of crowdedness of a given MicroCosm and the ability of people to move through it at pace. This enables it to create an adjustment factor for a given level of crowdedness which will be applied to the requested pace (e.g. RealMe may have expressed "brisk" as their planned pace through the mall, however if the mall is crowded clearly the pace will need be reduced by virtue of the sheer number of people in the way).
  • the Routing Engine used the appropriate adjustment factor to further optimize the route and schedule it creates for RealMe.
  • each CyberVendor 296 has its own "formal visit" schedule which shows available visit slots at any given time. The availability is a function of the number of staff available to service a RealMe at a given time.
  • the MI interacts with the relevant CyberVendors' visit schedules to identify available formal meeting slots.
  • Each RealMe has a reliability factor associated with him or her which is a measure of his or her track record of keeping appointments for Formal Visits, assessed in a manner which is discussed below.
  • the CyberVendor' s visit schedule can adjust its tolerance to the reliability of RealMes according to how full the visit schedule is. If the schedule is relatively empty then RealMes who have a high incidence of missing their formal visits may be accepted, however if it is nearly full, the remaining slots may be reserved for high-reliability RealMes.
  • the CyberVendor' s visit scheduler may use statistical analysis and probability calculation techniques to "hedge" two or more unreliable RealMe's against each other (similar to the technique used by passenger airlines who consistently overbook their planes in the knowledge that not all booked passengers will turn up). Thus requests for formal visits by an individual RealMe may not always be fulfilled.
  • the Routing Engine 287 uses this information plus the parameters passed to it earlier by RealMe (see above) the Routing Engine 287 creates an optimized routing schedule, and where possible reserves tentative slots in the CyberVendor 's "formal meeting" schedule (slots with individual CyberVendors 296 are "booked” in a similar style to the way meetings are requested for multiple users within email systems such as MicroSoft Outlook).
  • the MicroCosm Routing Engine produces an optimized routing schedule for RealMe in accordance with the stipulated parameters.
  • the schedule is communicated back to the universal C2B 2 system for onward communication and presentation to RealMe by presentation and conversation manager, continuing the MicroCosm Routing and Scheduling dialogue pattern.
  • RealMe can accept the schedule or amend it. If amendments are made, then the Routing Engine is called again to re-optimize the schedule and change "tentative slots". When RealMe accepts a schedule such slots are converted to "reserved slots".
  • CyberVendors 296 can view or print schedules and expect RealMe to anive at the appointed time. At this point the registration sequence with the MicroCosm is complete, and
  • RealMe can start to commence their route around the CyberMall 295.
  • the Landing Point may also provide Personal Service Assistants (PSA) 290, as discussed earlier, to RealMe's to provide their main means of communicating to their CyberMe during their tour of the CyberMall 295,.
  • PSA Personal Service Assistants
  • RealMe may use an alternative device, such as a WAP-enabled mobile phone to interact with their CyberMe during their visit.
  • CyberMall 295 is responsive to any changes to the cunent channel of RealMe at all times during the visit - e.g. may start out on the Internet at the landing point, but then move to PSA 290 before moving back to Internet.
  • RealMe may deviate away from plan if something grabs their attention in a particular shop. If RealMe starts getting behind schedule, then they are alerted, and any formal visits to CyberVendors 296 which are at risk of being missed by RealMe, are identified. RealMe may cancel any formal visits at this point, or submit a request for a later visit.
  • new dynamic and/or brokered responses may be received by RealMe's CRP from CyberVendors 296 within the MicroCosm, during the course of their visit.
  • RealMe will be alerted of the new responses in the normal way, and be given the opportunity to select one or more of them for formal or informal visits.
  • the Routing Engine can in both cases be invoked by RealMe to re-calculate and optimize the remainder of their schedule, incorporating the new factors (i.e. running late, or new products/services to see).
  • RealMe's reliability in keeping appointments for formal visits is monitored by the MetaEngine 275' which ascertains RealMe's track-record of keeping to schedule based on information provided by CyberVendors 296.
  • CyberMe will keep RealMe informed of their reliability in terms of keeping appointments for Formal Visits through alert messages as required (e.g. if they are consistently behind schedule, then they will be told this by their CyberMe).
  • RealMe's reliability rating in terms of keeping Formal Visit appointments can be used by CyberVendors Visit' Scheduling systems to accept or reject a request for a Formal Visit, as mentioned above.
  • Each CyberVendor 296 has a product/service map showing how individual products and services are set out in their store.
  • the product/service map is set out in the PSU 255' of the CyberVendor, where each product/service, and/or their parent categories within the PSU hierarchy, has a locality associated with them (note this is a variation from the PSU 255 used by the universal C2B 2 system, where, by definition, no locality information is stored).
  • the locality is defined by a series of co-ordinates that define the outer limit of the locality (in the same way as a MicroCosm's locality is defined), however, in addition, it also can contain levels to uniquely identify the story upon which the products and services are located in a multi-story store).
  • This type of service is supported by PSAs 290 and other mobile equipment RealMe may cany with them during the course of their stay within the MicroCosm, such as a WAP- enabled mobile phone.
  • Some MicroCosms e.g. CyberMalls 295, will provide PSAs 290 to RealMe to continually update them with their cunent location, perhaps superimposed on to a displayed map and indicating where they need to go next to complete the next stage of their schedule.
  • Such devices as applied by the invention can support RealMe while they move around a CyberVendor 296, so that they can be shown details of the products/services available immediately around them.
  • the close proximity of a RealMe to a given product/service within a CyberVendor 296 for greater than a stipulated period of time, which is held in the PSU 255' and can be defined differently for each product/service, may be symptomatic of RealMe showing an interest in that product / service, and if the product or service is not one that is already in RealMe's requirements list, as stored in RIM 221, then RealMe is prompted by CM 202' in conjunction with P 204' through RealMe's cunent channel, such as their PSA 290 or other handheld device, in which case CM 202' uses a "product/service interest query" dialogue pattern, to convey the level of interest, from no interest to extremely interested. If a high level of interest is expressed, then the product or service will be added to
  • CRP can seek responses from within the cunent active MicroCosm(s) (conditions may be set such that CRP can't seek responses until they are in the vicinity of the MicroCosm).
  • This additional information ⁇ is provided as an aid to RealMe, but also represents an incentive for RealMe to register their interest rather than browse a product/service passively.
  • the information provided via the PSA 290 can be content-rich (multi-media), depending on the bandwidth capabilities of the MicroCosm.
  • the information shown will be obtained from the multimedia aids (stored in database 202f ) associated with the PSU 255' record held by the MicroCosm itself and will be transmitted by the MicroCosm to RealMe via the connection set up when RealMe registered, and using the most appropriate available channel for the content to be delivered, which will be the PSA 290 if RealMe has one.
  • the time spent receiving "informal, unassisted” information is measured e.g. from the time that RealMe confirms their interest in a product or service to the time they leave the vicinity of the product/service, as detected by Movement Assimilation 208'.
  • Sales assistants may, for example, be provided with a BluetoothTM- enabled device (where BluetoothTM allows for the replacement of cables to connect one device to another with one universal short-range radio link.
  • BluetoothTM radio technology built into both the cellular telephone and the laptop would replace the cumbersome cable used today to connect a laptop to a cellular telephone.
  • Printers, PDA's, desktops, fax machines, keyboards, joysticks and virtually any other digital device can be part of the BluetoothTM system) to communicate with RealMe's PSA 290 such that the required identification information is transmitted rather than manually entered into
  • CFM 258' then gets CM to prompt RealMe for feedback on the service provided by the sales assistant using a "sales assistant feedback" template in the CFM.
  • This infonnation is analyzed by MetaEngine 275' and MetaData 276' reports and analysis can be provided to the relevant CyberVendor 296.
  • the CyberVendor id, date and time, time spent and nature of information received is stored on the supplier assistance list associated with the relevant entry on RIM.
  • RealMe In the case of dispute, RealMe is asked to enter the reason for the dispute and an entry is made on a Supplier Escalation database 257a' held by the MicroCosm (and subsequently exchanged with the Supplier Escalation database 257a of the universal system 100 as a background job), which is discussed elsewhere in this document. RealMe asked to enter the conect infonnation as they see it, and this is accepted as the actual FIG.. However, Supplier Escalation collates such disputes with a given supplier and requests the supplier to respond using a standard response template - this time for feedback on a this particular issue rather than in response to a RealMe request.
  • the CyberVendor 296 is requested to provide feedback within a certain period of time, in line with the tenns and conditions of being a CyberVendor 296.
  • the purpose of this process is to identify and rectify problems rather than apportion blame.
  • a RealMe or CyberVendor 296 is found to consistently abuse the system, then their respective integrity ratings may be affected, and they may ultimately be banned from using the C2B 2 service.
  • MetaEngine 275' collates and analyses all information regarding the amount of time and interest shown in products and services, and the resulting MetaData 276' can be made available to the relevant suppliers through the MetaData service. The data so collected may subsequently be transfened to Metadata 276 of the universal system 100.
  • RealMe makes a purchase, it is registered through the CyberVendor' s own
  • the Supplier Assistance information becomes significant when RealMe decides to purchase the associated product/service, because all suppliers associated with providing RealMe with a product/service will qualify for a service fee, which will be a function of the time spent with RealMe and the type of assistance provided.
  • the Commerce Engine (CE) 265 and Clearing House (CH) 270 modules within layer 150 are invoked, and the cost of the purchased product or service, is retrieved by CE and CH from RealMe via their cunent channel, and at the same time the Supplier Assistance record associated with the requirement is accessed by CE and CH and the service fee for each calculated, appropriate entries added to the ledgers within CE, and the funds transfer initiated from RealMe to the CyberVendor 296
  • CE Commerce Engine
  • CH Clearing House
  • RealMe can access the Supplier Assistance list at any time and view the aggregated cost of services provided to date.
  • This model is advantageous to cunent retail models, because retailers are susceptible to consumers who use sales assistants and displays to gather information on products during a product selection/decision making process, particularly in shops which have made an investment in providing a superior service and buying environment for the consumer, but who subsequently buy the product elsewhere e.g. on the Internet. This situation leads to low cost (particularly Internet-based) retailers leveraging the service delivered by others and leaving service-oriented retailers lacking remuneration for the service that they provided to such consumers.
  • This C2B 2 model preserves a revenue stream for service, discrete for the sale of the product/service itself.
  • this model encourages vendors to focus on service to the customer, and the cost associated with it, at a time when retail outlets, particularly large department stores, are being put under mounting pressure to reduce costs due to mounting competitive pressures.
  • CyberVendor 296 can arrange for the purchased product to be sent to a central goods collection point within the MicroCosm. Alternatively, if RealMe registered their vehicle, and its location, when they first engaged with the cunent or a parent
  • MicroCosm (example of a parent MicroCosm is a CyberMall 295 related to a CyberVendor
  • CRP 250 will offer RealMe value added information.
  • CRP 250 will monitor sales of all products and services to them during the shopping trip - effectively operating a virtual shopping cart across all shops with a running total of spend and the impact on their bank account / credit card statement.
  • CyberMe can act as RealMe's virtual "friend", telling them about their changing preferences and asking them if they agree.
  • CyberVendor 296 MicroCosms there are also CyberTrans 298 and CyberBuilding 297 MicroCosms that have a slightly different emphasis.
  • CyberTrans 298 is a MicroCosm which can respond to RealMe's preferences.
  • CyberTrans can also be a channel to connect to RealMe's CyberMe at the same time as being a MicroCosm (the communications capability within some vehicles can be used in this way).
  • the description below gives an example of how a CyberTrans car could interact with RealMe.
  • RealMe enters the CyberTrans 298 and registers their CyberMe tag either manually or automatically, e.g. through an ignition key which has their CyberMe tag encoded within it or manually by typing into an on-board keyboard with an associated display. Relevant information about RealMe's preferences are downloaded to the CyberTrans 298 from
  • RealMe's Attributes 230 in the universal system 100 This results in customization features of the CyberTrans being adjusted to reflect RealMe's preferences, which for example could result in their favorite radio stations are set-up on the in-car stereo, or their favorite music being downloaded through broadband transmission techniques perhaps in MP3 format, or the climate control setting being automatically adjusted to RealMe's preferences, or cruise control being set a certain level etc. If more than one RealMe gets into a CyberTrans 298 then they can register as a CyberGroup, in which case all their relevant preferences are pooled and analyzed such that the customizable features of the CyberTrans can be optimized to reflect all preferences.
  • MicroCosms such as CyberMalls 295 and CyberBuildings 297 have the option of installing CyberTrans-compliant car lots, which permit the automatic detection of CyberTrans 298, through connection to third party vehicle tracking service providers (e.g. GPS-enabled services as offered by some security companies).
  • vehicle tracking service providers e.g. GPS-enabled services as offered by some security companies.
  • MicroCosms can be alerted through their connection to the Global C2B 2 system of the anival of RealMe's or conesponding CyberGroups, by means of Movement Assimilation (discussed in pervious section), which can in turn initiate the registration sequence with the CyberMall MicroCosm 295 through the CyberTrans channel.
  • RealMe is detected by one of various means available (e.g.
  • the vehicle itself is a CyberTrans 298 wherein RealMe has registered, and which is equipped with tracking equipment which enables the vehicle's position to be monitored to within a few meters, wherein the tracking service provider has an interface into the universal C2B 2 system and has enabled the tracking information to be stored as attributes 231 in the Movement section 239 of Attributes 230, which can then be fed through to the MicroCosm automatically or upon registration. Since the location of the CyberTrans 298 vehicle and a RealMe within it have been associated, the point at which the vehicle then becomes stationary in a defined car lot location for a certain period of time can signify that the car is parked, and can its location be automatically registered on behalf of RealMe to the MicroCosm. This would enable, for example, RealMe to select it as a delivery point when within a CyberMall 295.
  • CyberBuilding
  • CyberBuilding 297 is a MicroCosm which can respond to RealMe's preferences. Registration with a CyberBuilding would be similar to that of a CyberMall 295. The description below gives an example of how a CyberBuilding could interact with RealMe.
  • RealMe enters the CyberBuilding 297, which for the purposes of example might be a hospital, and registers. Relevant information from RealMe's Attributes are downloaded to the CyberBuilding from RealMe's Attributes. The specification of relevant attributes to be downloaded from the global system 100 would be held locally in the MicroCosm itself, but ⁇ independently ratified. In this example RealMe has entered an eye specialist hospital. The registration sequence, which exchanges information between the MicroCosm and the global C2B 2 system has identified RealMe as an outpatient, who has come for an appointment with an eye surgeon for a post-operative examination. The MicroCosm has authority to gain secure access to RealMe's medical attributes.
  • RealMe's attributes have been set up to hold all medical information on RealMe, precluding the need for the information to be stored manually on the hospital's file or electronically on hospital's own systems. This is advantageous since it means that the data is fully portable with RealMe, and is held in one place and one place only.
  • RealMe can authorize the hospital to gain access to any of his medical attributes at any time. When RealMe had surgery on his last visit, his dietary requirements were downloaded. Since in a hospital environment mobile phones are not permitted, RealMe can be offered a specially adapted device which enables them to be given assistance without compromising the hospital's systems - a safe equivalent to a PSA 290.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Preparation Of Compounds By Using Micro-Organisms (AREA)
  • Telephonic Communication Services (AREA)
  • User Interface Of Digital Computer (AREA)

Abstract

L'invention concerne un système, un procédé et un support permettant de créer et d'utiliser une représentation virtuelle d'un utilisateur réel, par exemple une personne ou une entreprise, afin de faciliter des transactions consommateur-entreprise et entreprise-entreprise sur des réseaux et sur d'autres supports électroniques tels que la télévision numérique interactive, des assistants numériques personnels et des téléphones mobiles. Le système peut être commodément réparti en sept couches, chacune réalisant ultérieurement un groupe de fonctions dans le système. Une première couche permet d'assurer l'intégrité et la sécurité du système consommateur-entreprise-entreprise (C2B2) de l'invention et de l'interface entre le système C2B2 et des utilisateurs individuels. Une deuxième couche permet d'identifier et de supporter des besoins utilisateur à un moment donné, et d'obtenir une information d'état. Une troisième couche permet d'acquérir, de stocker et de traiter des attributs utilisateur de façon à former et à entretenir la représentation virtuelle de l'utilisateur. Une quatrième couche permet de définir et d'obtenir d'un utilisateur les données et l'information nécessaires afin de répondre à ses besoins et de sécuriser et de filtrer des réponses de fournisseurs destinées à correspondre à ces besoins. Une cinquième couche permet de compléter et de stocker des transactions commerciales et de supporter un plein domaine de processus commerciaux. Une sixième couche réalise l'agrégation et la présentation de données statistiques collectées anonymement à partir des attributs d'un grand nombre d'utilisateurs, ainsi que la dissémination des données de demande consommateur vers la chaîne d'approvisionnement. Une septième couche sert de support à des services spécifiques d'emplacement et à des réponses aux besoins et aux préférences utilisateur. L'intégration complète de ces sept couches en un ensemble concerté mène à un système C2B2 intégré.
PCT/IB2001/001471 2000-07-07 2001-06-27 Systeme, procede et support facilitant des transactions sur un reseau WO2002005153A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001277638A AU2001277638A1 (en) 2000-07-07 2001-06-27 System, method and medium for facilitating transactions over a network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US61255200A 2000-07-07 2000-07-07
US09/612,552 2000-07-07

Publications (2)

Publication Number Publication Date
WO2002005153A2 true WO2002005153A2 (fr) 2002-01-17
WO2002005153A3 WO2002005153A3 (fr) 2004-04-15

Family

ID=24453650

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2001/001471 WO2002005153A2 (fr) 2000-07-07 2001-06-27 Systeme, procede et support facilitant des transactions sur un reseau

Country Status (2)

Country Link
AU (1) AU2001277638A1 (fr)
WO (1) WO2002005153A2 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008088903A2 (fr) * 2007-01-19 2008-07-24 Webgen Corporation Outil de conseil expert communautaire
WO2020063875A1 (fr) * 2018-09-28 2020-04-02 北京三快在线科技有限公司 Détermination de plage de livraison
US10783457B2 (en) 2017-05-26 2020-09-22 Alibaba Group Holding Limited Method for determining risk preference of user, information recommendation method, and apparatus
US20210256446A1 (en) * 2018-02-26 2021-08-19 Coupa Software Incorporated Automated information retrieval based on supplier risk
CN116186351A (zh) * 2023-04-23 2023-05-30 武汉想不到网络科技有限公司 一种基于加密传输的数据优化系统
CN117495435A (zh) * 2023-12-29 2024-02-02 国网浙江省电力有限公司营销服务中心 基于fig-irelm的售电量区间预测方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784565A (en) * 1995-05-01 1998-07-21 Lewine; Donald A. Server for either anonymous or pre-authorized users to order goods or services on the world-wide web computer network
WO1999033293A1 (fr) * 1997-12-23 1999-07-01 Global Mobility Systems, Inc. Systeme et procede de commande d'informations personnelles et de transmission d'informations a destination et en provenance d'un dispositif de telecommunication
US6003020A (en) * 1997-10-30 1999-12-14 Sapient Health Network Intelligent profiling system
WO2000020962A2 (fr) * 1998-10-02 2000-04-13 International Business Machines Corporation Informatique conversationnelle par machine virtuelle conversationnelle

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784565A (en) * 1995-05-01 1998-07-21 Lewine; Donald A. Server for either anonymous or pre-authorized users to order goods or services on the world-wide web computer network
US6003020A (en) * 1997-10-30 1999-12-14 Sapient Health Network Intelligent profiling system
WO1999033293A1 (fr) * 1997-12-23 1999-07-01 Global Mobility Systems, Inc. Systeme et procede de commande d'informations personnelles et de transmission d'informations a destination et en provenance d'un dispositif de telecommunication
WO2000020962A2 (fr) * 1998-10-02 2000-04-13 International Business Machines Corporation Informatique conversationnelle par machine virtuelle conversationnelle

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008088903A2 (fr) * 2007-01-19 2008-07-24 Webgen Corporation Outil de conseil expert communautaire
WO2008088903A3 (fr) * 2007-01-19 2008-10-23 Webgen Corp Outil de conseil expert communautaire
US10783457B2 (en) 2017-05-26 2020-09-22 Alibaba Group Holding Limited Method for determining risk preference of user, information recommendation method, and apparatus
US20210256446A1 (en) * 2018-02-26 2021-08-19 Coupa Software Incorporated Automated information retrieval based on supplier risk
WO2020063875A1 (fr) * 2018-09-28 2020-04-02 北京三快在线科技有限公司 Détermination de plage de livraison
CN116186351A (zh) * 2023-04-23 2023-05-30 武汉想不到网络科技有限公司 一种基于加密传输的数据优化系统
CN117495435A (zh) * 2023-12-29 2024-02-02 国网浙江省电力有限公司营销服务中心 基于fig-irelm的售电量区间预测方法和装置
CN117495435B (zh) * 2023-12-29 2024-05-28 国网浙江省电力有限公司营销服务中心 基于fig-irelm的售电量区间预测方法和装置

Also Published As

Publication number Publication date
WO2002005153A3 (fr) 2004-04-15
AU2001277638A1 (en) 2002-01-21

Similar Documents

Publication Publication Date Title
US20190340622A1 (en) Enhanced customer interaction
US7630986B1 (en) Secure data interchange
US10078696B1 (en) Relevant social searching and user centric data analysis via user and peer group parameters via a dynamic interface
US20160343037A1 (en) Method and system for the creating, managing, and delivering of enhanced feed formatted content
US8799220B2 (en) Content creation, distribution, interaction, and monitoring system
US7603292B1 (en) Methods and systems for providing a gift registry
US7788212B2 (en) System and method for personalization implemented on multiple networks and multiple interfaces
TWI393064B (zh) 行動裝置使用者之事件通訊平台之裝置、方法、系統以及處理器可讀媒體
US8676615B2 (en) Methods and systems for computer aided event and venue setup and modeling and interactive maps
US7480627B1 (en) System and method for extension of group buying throughout the internet
US20090248516A1 (en) Method for annotating web content in real-time
US20030040946A1 (en) Travel planning system and method
US20070204308A1 (en) Method of Operating a Channel Recommendation System
US20090248635A1 (en) Method for providing credible, relevant, and accurate transactional guidance
TW200945077A (en) Systems and methods of ranking attention
US20070244769A1 (en) User interaction for trading system and method
JP2012519926A (ja) マネタイズプラットフォームを用いるコンテンツのコンテキスト情報によるターゲティング
US20040107180A1 (en) Delivery-information management process and information management server
JP2002271855A (ja) 広告提供装置
WO2002005153A2 (fr) Systeme, procede et support facilitant des transactions sur un reseau
US11205209B2 (en) Methods for searching and obtaining clothing designs while discouraging copying
Alghafli Electronic commerce: A study to develop a general model for the cyber-mediaries during the electronic commerce age
Gilly Mary Finley Wolfinbarger, California State University, Long Beach
WO2002001450A2 (fr) Systeme de communication en reseau pour des personnes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2001277638

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2001955478

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20030787

Country of ref document: UZ

Kind code of ref document: A

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2001955478

Country of ref document: EP

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP