US20210256539A1

US20210256539A1 - System and Method for Providing Requested Information to Thin Clients

Info

Publication number: US20210256539A1
Application number: US17/248,993
Authority: US
Inventors: John P. Volpi; Matthew N. Bowers; Kelly A. Hartley; Steven H. Roemerman; Jodi B. Rubin
Original assignee: Incucomm Inc
Current assignee: Incucomm Inc
Priority date: 2001-07-17
Filing date: 2021-02-16
Publication date: 2021-08-19
Also published as: US8301503B2; US20030018540A1; US20130054410A1

Abstract

A system for, and method of, providing requested information to a client. In one embodiment, the system includes: (1) a core information database that contains core information gleaned from the Internet and restructured according to a predetermined taxonomy and (2) a client communications interface, coupled to the core information database, that receives a request message from a client containing a request for some of the core information, derives a database query from the request message, causes the some of the core information to be retrieved from the core information database, formats the some of the core information into a response message according to display limitations of the client and transmits the response message to the client for display thereby.

Description

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. patent application Ser. No. 13/663,231, entitled “System and Method for Providing Requested Information to Thin Clients,” filed Oct. 29, 2012, which is a continuation of U.S. patent application Ser. No. 10/197,065, entitled “System and Method for Providing Requested Information to Thin Clients,” filed Jul. 17, 2002, now U.S. Pat. No. 8,301,503, which claims priority to U.S. Provisional Patent Application Ser. No. 60/306,127, entitled “System and Method for Providing a Range of Information on Demand for a Commercial Item, Identifiable Subsystem, Commodity or Individual,” filed Jul. 17, 2001, all of which are incorporated herein by reference.

TECHNICAL FIELD OF THE INVENTION

The present invention is directed, in general, to computer systems and, more specifically, to a system and method for providing requested information to thin clients.

BACKGROUND OF THE INVENTION

Presently, individuals seeking timely and relevant, decision quality product data are only able to get it by individually contacting providers of such products, physically traveling to multiple locations where the products are offered, scouring print advertising, and/or using the Internet. The Internet provides vast quantities of information, but requires some skill in fully using the present search capabilities. In addition, search results often overload the user with too much data while providing only limited viewing potential of a product. Physically visiting “brick-and-mortar” facilities allow the actual products to be viewed, but can be severely limited in detailed specification and alternative selections.
Recently, there has been much activity focused on enabling individuals to interface with the Internet via wireless devices in addition to wireline systems currently available. Wireless access can bring the power of the Internet to a user on a Wherever, Whenever, Whatever basis. While the concept is good, it is also fundamentally flawed, as the necessary limitations of wireless devices will only exacerbate the situation described above. This results in a substantial unmet need.
The systems presently in place, which connect the user directly with the Internet, are fundamentally flawed for several reasons. One reason is that the Internet, and many current data providers, have too much information. Users often find it difficult to find the specific desired items on the Internet because all of the information is there. For example, a simple query on an Internet browser can easily return several thousand responses. Advanced searches that are often used to reduce the number to a manageable level are time consuming, non-standard, difficult to use without considerable practice, and tend to be more art than science. In addition, none of this searching is compatible with spontaneous interaction and is aggravated when the interface medium is a mobile device connected by wireless means because of the bandwidth limiting nature of mobile wireless devices. Accessing the Internet through a mobile wireless device is analogous to the information traversing through “thin pipes.”
Another reason is that even though the information needed is on the Internet or in product and manufacturer database, the information is only useful when it is easily accessible, compatible with the capabilities (e.g., bandwidth) of the connection, compatible with the mobile device (e.g., Palm OS and others), accurate, and easily understandable by the user. Typically, searches on present systems, which only provide access to the Internet, result in the user getting a large amount of raw data. More recent systems do little more than provide a cross correlation table to existing URL pages and do not address the heart of the problem.
For example, a personal digital assistant (PDA) cannot view a web page that is normally intended for a conventional office computer system. One obvious reason is that the screen on the PDA cannot display as much information as on an office computer system. Also, typical search results can span hundreds of pages and each result can be wider that what can be displayed on a PDA. Another problem associated with a PDA is the size of the keyboard. PDA keyboards may not have a full keyboard and, as such, are harder to use. However, the need is no less, and may be greater as an individual in a non-office environment where there are fewer resources available. In this situation, the individual would have to relay mostly on what the single mobile device can effectively provide. Current systems don't effectively allow users of PDAs to find information while providing output consistent with the capabilities of the PDAs.
Similar needs beyond those for inanimate products also exist for individuals. These needs are exemplified, but not limited to medical records, insurance records, financial records and similar items. The needs for individuals can also be extended to agricultural items including livestock.
Correlation and quality of the data retrieved is not obvious nor is it uniform and little effort is made to make it so. Simply saying “It is on the Web” or “It is in a database” is not enough. Just setting up a direct relationship with the Internet is insufficient and can actually add to a confusing situation as it is prone to cause far too much, unsorted, unqualified and often incomprehensible data and options to descend upon the user and his limited handheld terminal causing delay, extraneous data, information deluge, and overload. The result is a frustrated user without the necessary information needed to perform a task.
Accordingly, what is needed in the art is a system to effectively provide quality information in a timely manner through a bandwidth limited transport path.

SUMMARY OF THE INVENTION

To address the above-discussed deficiencies of the prior art, the present invention provides a system for, and method of, providing requested information to a client. In one embodiment, the system includes: (1) a core information database that contains core information gleaned from the Internet and restructured according to a predetermined taxonomy and (2) a client communications interface, coupled to the core information database, that receives a request message from a client containing a request for some of the core information, derives a database query from the request message, causes the some of the core information to be retrieved from the core information database, formats the some of the core information into a response message according to display limitations of the client and transmits the response message to the client for display thereby.
The present invention therefore introduces the broad concept of an Internet intermediary that contains information selectively drawn from the Internet and intelligently organized and that interacts with clients to receive and grant requests for information in their native format. The present invention advantageously avoids the problems encountered when seeking pertinent information from the Internet, particularly when such seeking is performed with a thin, wireless client with limited display capability.
In one embodiment of the present invention, the client is selected from the group consisting of: (1) a wireless personal data assistant, (2) a cell telephone with display messaging capability, (3) a computer, (4) a supply chain system and (5) a wired messaging terminal. Thus, the present invention is employable with a wide variety of clients. These and any other conceivable conventional or later-discovered client fall within the broad scope of the present invention.
In one embodiment of the present invention, the system forms a part of a product purchasing system, the core information regards a plurality of products available for purchase and the predetermined taxonomy calls for the core information to be organized by model, source, price and availability. This e-commerce application, along with others, will be illustrated and described in the Detailed Description that follows.
In one embodiment of the present invention, the core information database is also configured to allow the client communications interface to obtain comparisons between at least a portion of the core information in a given classification of the predetermined taxonomy with which the core information is associated. In other embodiments, the present invention may obtain comparisons between any portion of the core information based on any criteria.
In one embodiment of the present invention, the request message is a natural language text message. Alternatively, the request may be embedded in a more computer-recognizable form, such as an Exchange Markup Language (XML) datagram.
In one embodiment of the present invention, the system further includes a search engine that, if the request is for information outside of the core information database, causes a search of the Internet to be performed in an effort to obtain further core information for inclusion in the core information database. In a more specific embodiment, the search engine comprises a web crawler. Thus, if a request goes unfulfilled, the system can advantageously make an effort to find the needed information on the Internet and filter, organize and store the information for later delivery to the client.
In one embodiment of the present invention, the system further includes a configuration database containing the display limitations along with display limitations of other clients. Thus, the system may have client-specific display limitation information for each of its clients, allowing the system to customize the format in which it is to deliver the information.
In one embodiment of the present invention, the client communications interface obtains a client type from the client and employs the client type to determine the display limitations of the client. Thus, the system can dynamically format responses specifically to the display characteristics of each client using the system without requiring a user to specifically indicate the type of client being used.
In one embodiment of the present invention, the client communications interface subsequently prompts the client for refining request messages. The refining requests may be for more information, pricing, related product or orders. Of course, the present invention is not limited to a particular type of refining request.
The foregoing has outlined preferred and alternative features of the present invention so that those skilled in the art may better understand the detailed description of the invention that follows. Additional features of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiment as a basis for designing or modifying other structures for carrying out the same purposes of the present invention. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a block diagram of an embodiment of a communication network for providing requested information to a client constructed in accordance with the principles of the present invention;

FIG. 2 illustrates an exemplary request display of a thin client constructed in accordance with the principles of the present invention;

FIG. 3 illustrates an exemplary results display of a thin client constructed in accordance with the principles of the present invention;

FIG. 4 illustrates an exemplary specification display of a thin client constructed in accordance with the principles of the present invention;

FIG. 5 illustrates an exemplary prices display of a thin client constructed in accordance with the principles of the present invention;

FIG. 6 illustrates an exemplary availability display of a thin client constructed in accordance with the principles of the present invention; and

FIG. 7 illustrates a flow diagram of an embodiment of a method of providing requested information to a client conducted according to the principles of the present invention;

FIGS. 8 and 9 illustrate system level diagrams of embodiments of communication systems constructed in accordance with the principles of the present invention;

FIG. 10 illustrates a system level diagram of an embodiment of an application component architecture constructed in accordance with the principles of the present invention;

FIG. 11 illustrates a flow diagram of an embodiment of a method of acquiring information from a client request constructed in accordance with the principles of the present invention;

FIG. 12 illustrates a block diagram of an embodiment of a portion of an application component architecture including a system health monitor application constructed in accordance with the principles of the present invention;

FIG. 13 illustrates a flow diagram of an embodiment of a load process constructed in accordance with the principles of the present invention;

FIG. 14 illustrates a flow diagram of an embodiment of an operation of a loader application constructed in accordance with the principles of the present invention;

FIG. 15 illustrates a flow diagram of an embodiment of an operation of a converter application constructed in accordance with the principles of the present invention;

FIG. 16 illustrates a flow diagram of an embodiment of a load flow detail;

FIG. 17 illustrates a block diagram of an embodiment of a data distribution subsystem constructed in accordance with the principles of the present invention;

FIG. 18 illustrates a block diagram of an embodiment of an error subsystem constructed in accordance with the principles of the present invention;

FIG. 19 illustrates a flow diagram of an embodiment of a follow me architecture constructed in accordance with the principles of the present invention;

FIG. 20 illustrates a block diagram of an embodiment of a database architecture constructed in accordance with the principles of the present invention;

FIG. 21 illustrates a block diagram of an embodiment of a hardware architecture constructed in accordance with the principles of the present invention; and

FIG. 22 illustrates a block diagram of an embodiment of a reporting architecture constructed in accordance with the principles of the present invention.

DETAILED DESCRIPTION

Referring initially to FIG. 1, illustrated is a block diagram of an embodiment of a communication network, generally designated 100, for providing requested information to a client constructed in accordance with the principles of the present invention. The communications network 100 includes the Internet 110 and a product database server 130 coupled to the Internet 110. The product database server 130 may be a conventional database server and includes a product database 135 that contains information for one or more vendor products or services. The product database server 130 provides information concerning products from the product database 135 via queries from a conventional web browser or from Exchange Markup Language (XML) queries. The communications network 100 also includes a conventional network server 140 coupled to the Internet 100. The network server 140 provides access to programs and a series of Web pages 145. The network server 140 may also host several Web sites for vendors of products, services or information. In other embodiments, the communications network 100 may have any number of product database servers 130 having any number of product databases 135, and any number of network servers 140 having any number of Web pages 145.
Within the environment of the computer network 100 is a personal computer system 120, a supply chain system 160, a wired messaging terminal 170 all coupled to the Internet. The personal computer system 120 may be a conventional computer system having the capability to access and search the Internet 110. The personal computer system 120 may also include a conventional Internet browser. The supply chain system 160 may include one or more computer systems configured to provide software services and data for a chain of suppliers of products or services. The wired messaging terminal 170 may be a conventional messaging terminal capable of sending and receiving messages via the Internet. The computer network 100 may also include a cell telephone with display messaging capability 182 and a wireless personal data assistant (PDA) 184 coupled to the Internet via a transmitter 180.
The computer network 100 also provides an environment for the present invention to operate. Included in the computer network 100 is an information system 150 that provides requested information to a client. The information system 150 may be a network server or a plurality of servers coupled to the Internet. The client may be selected from the group consisting of the wireless PDA 184, the cell telephone with display messaging capability 182, personal computer system 120, the supply chain system 160, and the wired messaging terminal 170. The information system 150 includes a core information database 156 that contains core information gleaned from the Internet 110 and restructured according to a predetermined taxonomy.
The predetermined taxonomy may include classifications such as computers, networking, electronics, software, medical products, medical procedures, medical history, agricultural products, financial information, and commodities. The core information contained in the core information database 156 may also include model information, specifications, detailed descriptions, source of suppliers, pricing, availability, and other information for the information gleaned from the Internet 110. Of course, however, the present invention is not limited to the classifications and types of information listed above, and are just examples of the type of information contained in the core information database 156. Other embodiments of the present invention may use different taxonomy, include additional and/or different classifications, and additional and/or different information gleaned for each classification.
The information system 150 also includes a client communication interface 152. The client communication interface 152 may be embodied in hardware, software, firmware or a combination thereof. In one embodiment, the client communication interface 152 may be an application service provider. The client communication interface 152 is configured to receive a request message from a client that contains a request for some of the core information in the core information database 156. In one embodiment, the request message is a natural language text message. For example, the natural language text message may be “Who makes digital cameras with 2.1 MegaPixel resolution?”.
The client communication interface 152 is further configured to derive a database query from the request message and cause some of the core information to be retrieved from the core information database 156. If the request message was the above natural language text message example, the derived database query would request a comparison across all of the camera vendors in the core information database 156 for the given criteria. In another embodiment, the core information database 156 is further configured to allow the client communication interface 152 to obtain comparisons between at least a portion of the core information in a given classification of the predetermined taxonomy with which the core information is associated with. In yet another embodiment, the client communication interface 152 can obtain comparison across all of the core information contained in the cored information database 156.
The client communication interface 152 is also configured to format the retrieved core information into a response message according display limitations of the client and transmit the response message to the client for display on the client's display. In one embodiment, the client communication interface 152 may obtain a client type from the client and employ the client type to determine the display limitations of the client. For example, the wireless PDA 184 may send a client type via the Internet 110 indicating that it is a PDA, such as Palm Pilot® or Blackberry®, the client communication interface 152 would format the response to accommodate the display of the PDA and the limited bandwidth of the wireless connection (also called a thin client). Thus, the information system 150 may have client-specific display limitation information for each of its clients, allowing the system to customize the format in which it is to deliver the information.
The client communication interface 152 may also employ a configuration database 158 in determining the display limitations for the client. The configuration database 158 may contain the display limitations for each client and/or type of client along with their display limitations. In another embodiment, the client communication interface 152 may employ the configuration database 158 to obtain a profile for the client. The client communication interface 152 may cause some of the core information to be retrieved from the core information database 156 in accordance with the obtained client profile. Thus, a client may receive only information to which it is entitled, or which it prefers.
After sending the response message to the client, the client communication interface 152 may prompt the client for refining the request message. For example, if the response message (results of the request message) did not provide the desired information or if the client would like to ask for related information, the client communication interface 152 allows the client to refine or change the request message. See FIGS. 2-6 for an example of refining request messages.
In the illustrated embodiment, the information system 150 may also contain a search engine 154. The search engine 154, in one embodiment, searches the product database server 130 and the network server 140 for core information based on the predetermined taxonomy and gleams the found core information. The gleaned core information is then restructured and stored in the core information database 156. In another embodiment, the search engine 154 may be a web crawler. If a client sent a request message for information that is outside of the core information contained in the core information database 156, the search engine 154 may cause a search of the Internet to be performed in an effort to obtain further core information associated with the requested information for inclusion in the core information database 156.
In a related embodiment, the client communication interface 152 may also be configured to ask the Client to rate the value of the information in the response message. For example, the Client could rate the information from 1 to 10, where 1 is less helpful and 10 is most helpful. The search engine 154 would maintain a database of the information requested and the corresponding ratings. If a request for particular type of information was rated low, the search engine would bump up the priority of that particular type of information and cause a search of the Internet to be performed to obtain more core information concerning that type of information for inclusion in the core information database 156.
Turning now to FIG. 2, illustrated is an exemplary request display of a thin client constructed in accordance with the principles of the present invention. As previously described, a thin client is a device that has limited communication bandwidth, such as mobile wireless communication devices similar to the wireless PDA 184 and the cell telephone with display messaging capability 182 of FIG. 1. A thin client typically also has limited display capabilities. For example, a wireless PDA may only be able to display 10 rows of 40 characters each. Of course, however, the principles illustrated for a thin client can be used on any type of client having a standard bandwidth or broadband connection to the Internet.
FIG. 2 and subsequent FIGS. 3-6 illustrate examples of a thin client submitting request messages requesting information from a core information database, such as the core information database 156 of FIG. 1, receiving responses and refining and/or requesting more specific information from the core information database. Illustrated in FIG. 2 is a display 200 of a thin client. The display 200 includes a request field 210 for a user to enter a request message to obtain some core information from the core information database. In the illustrated embodiment, the request field can accept a natural language text message. In this example, the user entered a natural language text message of “WHICH PRINTERS HAVE AT LEAST 600 times 600 DPI PRINT RESOLUTION.”
Once the user has entered the desired request message, the user would then press a send button 220 to send the request message. The request message may be sent to a client information interface similar to the client information interface 152 of FIG. 1 for processing. A database query is derived from the request message and executed on the core information database. The results are then obtained and sent back the display 200. See FIG. 3 for an example of the results. The present invention, however, is not limited to display arrangement nor to the fields illustrated in FIG. 2.
Turning now to FIG. 3, illustrated is an exemplary results display of a thin client constructed in accordance with the principles of the present invention. The display 200 illustrates exemplary results 310 to the request message sent in FIG. 2 and formatted to accommodate the display limitations of the thin client. The results 310 include the manufacturer and model of each printer matching the criteria specified in the request message. Each field of the results 310 may also include a specification button 320 and a price button 330. The specification button 320 allows the user to obtain the specification of a particular printer. The price button 330 allows the user to obtain prices from various vendors for that particular printer. Of course, however, the results 310, specification button 320 and the price button 330 may be used for any type of product or service.
The display 200 also includes a scrollbar to allow the user to scroll through the remaining portions of the results 310 if needed. The display also includes a back button 350 that allows the user to go back to the previous page. Thus, the present invention advantageously provides a history capability.
In this example we will assume the user desires to view the specification for the HP DESKJET XXX. The user would then press the specification button 320 next to the result entry for the HP DESKJET XXX. The thin client would then send a message request requesting the specification. A database query is derived from the request message and executed on the core information database to obtain the specification for the HP DESKJET XXX. The results are then obtained, formatted according to the display limitations of the client and sent back the display 200. See FIG. 4 for an example of the results. The present invention, however, is not limited to display arrangement nor to the fields illustrated in FIG. 3. In another embodiment, the user may request different types of information associated with the result entry, such as a summary or technical information.
Turning now to FIG. 4, illustrated is an exemplary specification display of a thin client constructed in accordance with the principles of the present invention. The display 200 illustrates an exemplary specification result 400 for the request message for the specification sent in FIG. 3. The specification result 400 illustrates an example of a specification for a HP DESKJET XXX. The display 200 also includes a scrollbar 410 to allow the user to scroll through the results 400. In the illustrated example, the display 200 also includes a price button 420 and an availability button 430. The price button 420 allows the user to obtain prices from various vendors for the product associated with the specification. The availability button 430 allows the user to obtain the availability of the product from various vendors.
In this example we will assume the user desires to view the prices for the HP DESKJET XXX. The user would then press the price button 420 on the display 200. The thin client would then send a message request requesting a comparison of prices from various vendors. A database query is derived from the request message and executed on the core information database to obtain the prices for the HP DESKJET XXX from vendors that carry that product. The results are then obtained, formatted according to the display limitations of the client and sent back the display 200. See FIG. 5 for an example of the results. The present invention, however, is not limited to display arrangement nor to the fields illustrated in FIG. 5.
Turning now to FIG. 5, illustrated is an exemplary prices display of a thin client constructed in accordance with the principles of the present invention. The display 200 illustrates an exemplary prices 510 for the request message for the prices sent in FIG. 4. The prices 510 illustrates an example of prices from various vendors for a HP DESKJET XXX contained in the core information database. The prices 510 include the vendor and that vendor's price. Each field of the prices 510 may also include a buy button 320 that allows the user to purchase that product from that particular vendor. The display 200 also includes a scroll bar 530 that allows the user to scroll through the prices 510. In addition, the display 200 may also include a location sorting field 540. The location sorting field 540 allows a user to enter criteria to limit the display of prices of the selected product from the various vendors. For example, the user may enter a zip code to limit the results to vendors within a geographic area. Of course, other limiting criteria are well within the broad scope of the present invention. In addition, the present invention is not limited to display arrangement nor to the fields illustrated in FIG. 5.
Turning now to FIG. 6, illustrated is an exemplary availability display of a thin client constructed in accordance with the principles of the present invention. If the user pressed the availability button 430 in FIG. 4, the thin client would send a request message for the availability of the HP DESKJET XXX and the results would be sent back to the thin client. The display 200 illustrates an example of availability results 610. The availability results 610 contain a vendor and an available quantity for that vendor. Each field of the availability results 610 also includes a buy button 620 that allows the user to purchase that product from that particular vendor. The display 200 also includes a scroll bar 630 that allows the user to scroll through the availability results 610. In addition, the display 200 may also include a location sorting field 640. The location sorting field 640 allows a user to enter criteria to limit the display of the availability of the selected product from the various vendors. For example, the user may enter a zip code to limit the results to vendors within a geographic area. Of course, other limiting criteria are well within the broad scope of the present invention. In addition, the present invention is not limited to display arrangement nor to the fields illustrated in FIG. 6.
Turning now to FIG. 7, illustrated is a flow diagram of an embodiment of a method, generally designated 700, of providing requested information to a client, such as a thin client conducted according to the principles of the present invention. In FIG. 7, the method 700 first performs initialization in a step 702.
After initialization, the method 700 loads a core information database with core information gleaned from the Internet and restructured according to a predetermined taxonomy in a step 704. In one embodiment, the method 700 may be employed to purchase products. In this embodiment, the core information regards a plurality of products available for purchase and the predetermined taxonomy would call for the core information to be organized by model, source, price and availability.
The method 700 may optionally load a configuration database in a step 706. In one embodiment the configuration database would contain display limitations for each client that would be employing the method 700. In another embodiment, the configuration database may contain a client profile that may be employed to cause some of the core information to be retrieved from the core information database according to a profile associated with the client. A client may be selected from the group consisting of a wireless PDA, a cell telephone with display messaging capability, a computer, a supply chain system, and a wired messaging terminal. Of course, however, other types of client may be employed by the present invention.
Next, the method 700 determines if a request message was received from a client containing a request for some of the core information in the core information database in a decisional step 710. If the method 700 received a request message, the method 700 then derives a database query from the request message in a step 720. In one embodiment, the request message may be a natural language text message. In other embodiments, the request message may be any type of request from the client to perform some action or function.
The method 700 then employs the database query to cause some of the core information to be retrieved from the core information database in a step 730. Next, the method 700 formats the core information that was received into a response message according to display limitations of the client in a step 740. The display limitations may include the display size, color capabilities, number of pixels of the display, the number of rows and characters per row, formatting codes, and bandwidth requirements. The method 700 may employ the optional configuration database to obtain the display limitations for that client. In another embodiment, the method 700 may obtain a client type from the client and employ the client type to determine the display limitations for that client. Next, the method 700 transmits the response message to the client for display in a step 750. The method 700 then returns to determine if it has received another request message in the decisional step 710.
If the request message was not received in the decisional step 710, the method 700 then determines if a search of the Internet is to be performed in a decisional step 760. If no search is to be performed, the method 700 returns to determine if it has received another request message in the decisional step 710. If a search is to be performed, the method 700 causes a search of the Internet to be performed in an effort to obtain further core information for inclusion in the core information database in a step 770. The search may be in response to the request message contains a request for information that is outside of the core information database. In another embodiment, the search may be performed at predetermined times or in a background mode in order to update the core information according to the predetermined taxonomy. The search may be performed by a web crawler or other Internet routines capable of examining and obtaining formation from devices connected to the Internet. The method 700 then returns to determine if it has received another request message in the decisional step 710.
Thus, the present invention introduces an improved method and system for providing reliable product information on a demand basis to a broad class of users using a multiplicity of means for query from simple personal digital assistants (PDAs) to full desktop computers, and across a multiplicity of transmission mediums from the bandwidth limitations of wireless to broadband wireline mediums. The method and system may provide a simple user input interface that uses universal product codes (UPCs) or other similar product identifiers. These can be directly scanned, manually keyed, or entered via other means such as voice into the PDA. Thus a single simple operation is all that is required to initiate the simplest query “What is this?”.
The method and system may provide a simple user interface that allows the user to select various comparisons and/or attributes of interest to him and defined by him for the product of interest. The method and system may provide a database that is optimized for variable queries from a PDA or other similar device and efficient responses over a bandwidth limited wireless network. The raw information to make up this database shall come from manufacturers, the Internet, and a multiplicity of other sources. The method and system may provide the specific format of the data presented as determined by the means available to present it and the queries, both past and present, entered by the user. This is in addition to certain fixed output formats. A means is provided for accepting a multiplicity of data from disparate sources and providing a consistent “look and feel” of information to the user independent of the source.
Some embodiments as disclosed herein will greatly facilitate, for instance, quality information in a retail and/or a commercial setting when available service personnel are only minimally familiar with the product and the necessary information is not otherwise readily available. The system may also facilitate specific, detailed and current specifications on demand, specific, detailed and current specifications on similar products or portions thereof on demand, specific, detailed information, to authorized personnel concerning an individual's medical history that is complete and updated as procedures are performed, specific, detailed information on commodities, and agricultural items including livestock, immediate information for comparison shopping and/or alternate suitability, immediate information related to product availability, both in time and geographically.
A key to this is a “Wireless Friendly” UPC based, or similar unique identifier, query system. The UPC codes, or their equivalents, exist for virtually all products marketed in the U.S., Europe and Asia. These codes are unique, standardized, maintained, and very specific to a particular product. Therefore, a database that provides 1:1 product mapping based on them will be comprehensive and standardized. The database structure shall be relational and/or object oriented (00) to allow dynamically generated queries, based solely upon a specific customer's real time product questions to be answered. Also, its structure shall be optimized for efficient query and response via wireless connections to a simple handheld device. Existing UPC databases do not satisfy these requirements both for query and response. The information must be timely, accurate and relevant. The inquiry is simple and easily defined by the customer. The information is available “On-Demand” independent of the customer's physical location.
A simple transaction might occur as follows. The customer scans or otherwise enters a UPC code, or other identifier, into a wireless, PDA. The customer then selects a type of inquiry or defines a unique one. The query is sent to a unique database with the personality of the information provider. The information provider logs the type of inquiry and the customer for his records. A response is generated within the unique database and sent back to the user. The sequence is repeated as often as desired by the customer who can change the specifics of the inquiry at will. Information is provided or denied to a user according to specific authorizations previously set up.
Thus, the system allows querying different databases for product information using PDAs such as Palm or “Palm Like” devices that are also equipped for wireless communications interfaces and/or laptop/desktop computers for wireline interfaces. Simplest query is scan or simple key entry (e.g., UPC based) for “What is it?” response. The responses can be either fixed format, or customizable based on the evolving dynamic requirements for a particular event. Other services are available such as comparison shopping, proximity shopping, detailed product features, detailed product specifications, availability, alternatives and other outputs such as may be useful. A secure mode is also available if desired by user.
The system can support multiple retailers, information providers, application service providers (ASPs), each one functioning as a friendly and information rich source to the end customer, and each one using the resources of the comprehensive core information database(s) for source material. Examples include Best Buy, Consumers Union, ZDNET, Buy.com, Amazon.com, and MyWedding.com. The system can add specific “look and feel” personality that is unique to each provider if desired. The system can learn customer profile as information is passed to customer, support multiple asynchronous queries with timely short and high quality responses, and provide options for the retailer/information provider to host regularly updated relevant portion of the database and become an information system (IS) manager of same or to outsource all or part of this task.
A maintained, high quality and comprehensive database is provided that maps products, as identified by UPC codes or other identifiers to their detailed features, characteristics, and specifications. Key portions can be parsed and copied for use at remote locations, and the database may be object oriented and/or relational. The database is capable of supporting relational constructs to allow easy sorts based on customer defined attributes to sort upon (e.g., manufacturer, product type, specific product feature). The data formatted for maximum efficiency through “thin pipes” to simple information appliances. The database can accept inputs from multiple sources of varying quality and integrate into a single known quality source (provide quality flag for all data). The data may come from multiple disparate sources of UPC, employer identification number (EIN), or other identifier linked data including graphics and multimedia where appropriate. The system may accept data in whatever form it is provided, and accommodate standardized storage formats, and/or differing standards and formats.
The system addresses both a business-to-business (B2B) and business-to-consumer (B2C) vertical market providers of products, identifier specific information, or applications that will collect, maintain and deliver accurate and up-to-date information in various vertical markets, It provides information such as marketing, product images, specifications, manufacturer's suggested retail price (MSRP), product reviews, and/or other key information as may be requested. It provides this information seamlessly via a real-time interface to a core database. These requests for data can be accessed via both low bandwidth “Thin Pipe” communication channels for wireless users, and the high bandwidth “Fat Pipe” communications channels for wireline users. Thus, this system and method enables users to obtain a multiplicity of information based on pre-approved authorizations from the Internet via their desktop, PDA, wireless application protocol (WAP) phone, or other “smart” device.
Turning now to FIG. 8, illustrated is a system level diagram of an embodiment of a communication system constructed in accordance with the principles of the present invention. The communication system includes a global database 810, which may be geographically distributed. The global database 810 receives information from, without limitation, client product databases 815 and manufacturer (MFR) product databases 820 via a business/application logic layer 822. The business/application logic layer 822 can, without limitation, provide quality and validation checks. The global database 810 is connected to web servers via a business/application logic layer 825. The web servers (e.g., web server 830) communicate via a communication network such as the Internet 835 with communication devices (one of which is designated 840). The global database 810 is also connected to web servers such as an extensible machine language (XML) server 845 that communicates via a communication network 850 with original equipment manufacturer (“OEM”)/private label user servers (one of which is illustrated and designated 855) such as a healthcare provider. The communication network 850 is also connected to store/warehouse private label server 860, which communicates with communication devices (one of which is designated 865). The OEM/private label user server 855 also communicates with communication devices (one of which is designated 870).
The communication system (or system) has the ability to create dynamic, personalized content. This is the “look and feel” of the requested data, based on the identified preferences of the individual customer. The example below is an illustration for an application involving a PDA. This example was chosen because the bandwidth limitations and display limitations of the PDA make it a very demanding environment. However, it is easy to extend this capability to more comprehensive systems such as, but not limited to, desktop and laptop computers.
The system will create a “wrapper” that will enable the data to be displayed in a manner that is unique to each user of the system. Elements that define the wrapper include, but are not limited to, the individual user's preferences, the individual user's granted access, the specific nature of the query, the subject matter of the response to the query, and specific applications, downloaded to service the query and its responses.
The database will be parsed via a specific vertical market or category, Examples which illustrate these categories include, but are not limited to, telecommunications, computer hardware, healthcare and hospitality. Each vertical market will have rules-based industry specific components. Within those rules will reside the client specific “look and feel” requisites. For example, if the client were an E-Tailer that sold computers, the portion of the database that would be accessed would be the computer hardware product information database. The next determination to be made would be within that vertical market. That is, the pre-defined areas (such as UPC, manufacturer ID, description, MSRP, image, reviews) that the user is authorized to view and query. Each individual user will have pre-defined access and access restrictions to the database. For example, a sales representative may have access to inventory, detailed product information, current promotions, etc., whereas the vice president (VP) of sales may have access to inventory, detailed product information, promotions, sales status per representative, sales status per region, etc. The system will provide dynamic creation of content based on the client's identified preferences. The “look and feel” or “wrapper” encapsulating data will be displayed in a manner that is especially unique to the user. No two users need to have the same “wrapper”.
The system will identify the client querying the database to retrieve the correct wrapper. The identification process will begin at the security layer. As an example, consider a user accessing the “NETDATA” system. First, the user logs into the system with a unique identifier such as an access identifier (ID). At this point, the system identifies the user and detects which device, by specific query, that is presently in use. For this particular example, it is a PDA. Specific brands and models of PDAs are specifically identified and the screens adjusted, accordingly. The access ID also provides information as to access privileges. For example, if a sales representative for a pharmaceutical manufacturer logs in via his/her WAP phone, the system identifies the device as well as the user's profile. The user profile will contain the pre-defined vertical market data that the client has licensed. The first screen shot displayed would be the login process. After the user has been identified, the second screen shot would begin the wrapper process. In the pharmaceutical example, the sales representative could be presented with a screen with a place to enter the national drug code (NDC) and obtain additional product information. The third screen would then present the user with a menu for navigating further within the database.
The system must identify the type of device querying the database to produce the correct data format. Such querying devices may include, but are not limited to, PDAs, 2-way pagers, personal computer (PC) tablets, cell phones, laptops, desktops, etc. The system also recognizes the user as being a wireless or wireline requestor, so the agent can pull the correct format onto the platform. For example, if a requesting user conducts a query via their cell phone, the database is aware that the data output needs to fit into the current restraints of 150 characters, as well as attaching the proper pre-identified wrapper to the data being output.
Turning now to FIG. 9, illustrated is a system level diagram of an embodiment of a communication system constructed in accordance with the principles of the present invention. The communication system includes a NDC global central database 910 that receives information from, without limitation, client product databases 915 and manufacturer (MFR) product databases 920 via a business/application logic layer 922. The business/application logic layer 925 can, without limitation, provide quality and validation checks. The NDC global central database 910 is connected to NDC web servers 930, which communicate via a communication network such as the Internet 935 with communication devices (one of which is designated 940). The global central database 910 is also connected to a NDC-XML server 955 via a replicator 945 and OEM databases 950. The NDC-XML server 955 communicates via a communication network 960 with OEM NDC servers (one of which is illustrated and designated 965). The communication network 960 is also connected to store/warehouse local NDC server 970, which communicates with a point of sale (POS) server 975 and communication devices (one of which is designated 980). The OEM/NDC server 965 also communicates with communication devices (one of which is designated 985). The lightest shaded arrows between subsystems, modules and communication networks represent end user queries; the darkest shaded arrows between subsystems, modules and communication networks represent input data flow from manufacturers/vendors; the medium shaded arrows between subsystems, modules and communication networks represent data flow within NDC database servers.
Turning now to FIG. 10, illustrated is a system level diagram of an embodiment of an application component architecture constructed in accordance with the principles of the present invention. Load balance web servers (generally designated 1030) are connected to a communication network 1010 such the Internet via a Ethernet interface 1020. The load balance web servers 1030 are connected to a transaction server 1050 (e.g., a Microsoft transaction server (MTS) via a local area network (LAN) 1040. The transaction server 1050 performs a multitude of functions including, without limitation, providing product information, security, customer information, web statistics, images, etc. To perform the aforementioned services, the transaction server 1050 is connected to external servers such as online analytical processing (OLAP)/datamining servers 1060, product servers 1065, customer information servers 1070, web statistic servers 1075, and image servers 1080, to name a few.
Turning now to FIG. 11, illustrated is a flow diagram of an embodiment of a method of acquiring information from a client request constructed in accordance with the principles of the present invention. The sequence numbers (SNs) indicate a sequence of the method calls and the blocks represent objects for the implementation. The method begins with an incoming request (SN 1) from a user via a web page 1105. A user (member) logs in (SN 2) through a security object (also referred to as a “component”) 1110. The security component 1110 calls a Profile Q component 1115 that identifies the authentication of the user (SN 3). The Profile Q component 1115 (coupled to a Microsoft message queue designated “MSMQ”) returns the authenticated information with profile information (SN 4) to the security component 1110. The security component 1110 then calls a customer information component 1120 for historical information regarding the user (SN 5). The customer information is returned (SN 6) to the security component 1110.
The user is redirected (SN 7) to a query page 1125. The user types in a query and submits the request, and the query page 1125 sends the request (SN 8) to an English query engine 1130. The English query engine 1130 calls (SN 9) a query handler 1135. The query handler 1140 sends information (SN 10) to a query builder object 1140, which will identify the natural language in the query. The query builder object 1140 then calls (SN 11) a catalog object 1145 (coupled to industry databases (DBs)), which will identify the industries possible from the query. The catalog object 1145 returns (SN 12) the information to the query builder object 1140. The query builder object 1140 then sends (SN 13) the information to the query handler 1135. The query handler 1135 will check (SN 14) that the user has permissions for the industry request via check Profile Q decisional object 1150. If the user does not have permission, the user will be redirected (SN 15) to the query page 1125 and given information that they do not have the necessary permission for the request. If the user does have permission, the query will be passed (SN 16) to a product ranger component 1155.
The product ranger component 1155 then sends (SN 17) a structured query language (SQL) to the appropriate industry components (generally designated 1160). The industry component 1160 then sends (SN 18) the request to a product database (DB) component 1165 for the requested result set. The product DB component 1165 sends (SN 19) the information requested to a response object 1170, which is forwarded (SN 20) to a Search Q component 1175 (coupled to a Microsoft message queue designated “MSMQ”). From the Search Q component 1175, data will be sent (SN 21) to a results web page 1180. If the result set has an image, an image server component 1185 will be sent the request (SN 21 a). The image server component 1185 will return the path to the image (SN 21 b). The records on the web page will have a detailed link that, if clicked, will call (SN 22) a product detail component 1190. The product detail component 1190 will send (SN 23) the request for detail to the response object 1170, which is forwarded (SN 24) to the Search Q component 1175 to see if there is data for the request. The results from the Search Q component 1175 will be sent (SN 25) to the results web page 1180 and the product detail component 1190 is invoked (SN 26). The product detail component 1190 will check (SN 27) the product DB component 1165 as well to see if additional information exists or if there was no information for the Search Q component 1175. The productDB component will send (SN 28) the detailed information to the response object 1170, which is forwarded (SN 29) to the Search Q component 1175 to add to the requested information. The results from the Search Q component 1175 will be sent (SN 30) to the results web page 1180.
In accordance with an embodiment of the log in procedure above, the user may log into the system site under a certain industry, specific application path or query type. The security component 1110 may be called, which checks the Profile Q component 1115 for permission. Once logged in, the user may be directed to a web page with a search box. The user types in “Products that are blue and weigh 10 oz.?” The request is sent to the English query engine 1130, which identifies key nouns of the question such as products, color, and weight. The information from the English query engine 1130 is passed to the query handler 1135, which routes the request to the query builder object 1140, which the sends the request to the catalog object 1145 to identify the request as possibly being in retail, grocery and medical industries. Next, the profile is checked against the Profile Q component 1115 for the user if the user has permission to see grocery, medical and retail. If so, the product ranger component 1155 is called, which sends a specific SQL query to each industry. If the user does not have permission to view the industry information, the information will not be sent to the product ranger component 1155 to process.
In an embodiment, the user is able to control whether the images are on or off depending on the preferences. This is managed by means of the components that are aware of the end user's device type while processing requests. Autodetection of a specific device is performed at the access layer. The implementation of XML interfaces will allow access to a multitude of mobile devices that include, but are not limited to, PDAs, WAP/lnternet phones, cellular phones, smart phones, 2-way pagers, ruggedized devices, POS devices, wearable computers, pervasive computers, laptop/notebook computers, desk top computers and tablet PCs. Appropriate device specific information will be delivered based on the requesting protocol. The browser is aware of the device because of hardware specific installation files. The identification will happen during the log-in process. The NDC system is permissions-based. There will be no un-authorized users. End users are registered and given security/pin codes to access the NDC information. Pursuant to the user's profile, the user will only be allowed access to information that has been authorized and approved for that individual.
Turning now to FIG. 12, illustrated is a block diagram of an embodiment of a portion of an application component architecture including a system health monitor application 1210 constructed in accordance with the principles of the present invention. The system health monitor application 1210 will use a server health component 1220 to communicate with each individual server machine, which maintains a client health component 1230. The client health component 1230 on each server will give the server health component 1220 all the statistics and statuses of the components running on the individual server. This will allow the application to monitor many machines at one time. The information will be available in three different formats, namely, system event log 1240, email 1250, web page 1260 or database 1270. This will assist in remote monitoring of applications and proactive steps in the event of any failures.
Turning now to FIG. 13, illustrated is a flow diagram of an embodiment of a load process constructed in accordance with the principles of the present invention. The sequence numbers (SNs) indicate a sequence of the method calls and the blocks represent objects for the implementation. The load process takes care of loading data received from data providers (manufacturers, vendors from various industries. A converter application receives the incoming data file and conducts preliminary quality checks using industry and rules component, and splits the data file into smaller size manageable units. Then, the loader application will process each of the small size data files separately. The architecture allows multiple loader applications to process many smaller size files simultaneously. The loader application will communicate the status of the loading of the data into the database to the load process component also. The information for each dataset status will be logged and available through the load reporter application.
The method begins with data being received (SN 1) from a relevant source 1305. The data, in this context, is defined as any relevant information ranging, but not limited to, product specifications, product use, product maintenance, marketing text and images, personal individual information, and downloadable applications when requested. A converter application 1310 checks (SN 2) a vertical industry specified rules component 1315 appropriate for the inbound data. The industry specified rules component 1315 replies (SN 3) with relevant information. The converter application 1310 calls (SN 4) a rules component 1320, which maintains rules on the inbound data, and sends (SN 5) the rules back to the converter application 1310. The converter application 1310 calls (SN 6) a conversion component 1325 to see what the general conversion requirements are for converting the data, to which the conversion information is sent back (SN 7) to the converter application 1310.
The summary information for what will be processed is sent (SN 8) to a load database 1330. The dataset is also sent (SN 9) to an approval queue 1335. At a verification decisional module 1340, verification is sent (SN 10) to the client for approval to process data. Summary information is sent to client. If the verification is not received in a certain time period, the system will need to contact (SN 11) a client/vendor 1345. Once verification is received, the data is ready to be processed (SN12). A loader application 1350 will pull (SN 13) the data and begin the load process.
A load component 1355 is called (SN 14) by the loader application 1350 to see what should be processed. The load component 1355 sends (SN 15) a request to the load database 1330. The load database 1330 returns (SN 16) the requested information to the load component 1355. The load component 1355 returns (SN 17) the dataset to the loader application 1350. The loader application 1350 will then process the datasets and load (SN 18) the data sets into an industry database 1360. A load reporter 1365 and report component 1370 also cooperate with the loader application 1350 to per loader application 1350 form its intended function.
Turning now to FIG. 14, illustrated is a flow diagram of an embodiment of an operation of a loader application 1410 constructed in accordance with the principles of the present invention. The sequence numbers (SNs) indicate a sequence of the method calls and the blocks represent objects for the implementation. The loader application 1410 checks (SN 1) the industry folders 1415 at a certain frequency. A load component 1420 is called (SN 2) for information regarding a file to be loaded. The load component 1420 returns (SN 3) the information to the loader application 1410. The loader application 1410 pulls (SN 4) the set of data into a database 1425 to process. The loader application 1410 provides (SN 5) the records into a check counts module 1430, which are provided (SN 6) to a match decisional module 1435. The match decisional module 1435 provides a final quality check step just to ensure the number records imported is the number records. If the records do not match, all the new records from the batch are removed (SN 7) in a remove records module 1440, and the user is notified (SN 8) in a notification module 1445. If the records do match, the user is notified (SN 9) in a notification module 1450, and an original XML load file is moved (SN 10) to an archive server 1455 for archiving.
Turning now to FIG. 15, illustrated is a flow diagram of an embodiment of an operation of a converter application 1510 constructed in accordance with the principles of the present invention. The sequence numbers (SNs) indicate a sequence of the method calls and the blocks represent objects for the implementation. The data is received (SN 1) from a customer application 1515, which can exist in any format. The converter application 1510 identifies the type of file in an identification module 1520 and calls (SN 2) an industry component 1525. The industry component 1525 holds the column definitions for the data and provides (SN 3) the definitions to a match definitions decisional module 1530. If the data definitions do not match, a user is notified (SN 4) via a notification module 1535 and the process is terminated (SN 5) via an abort module 1540. If the definitions for the columns do match, the data is sent (SN 6) to a rules component 1545. The rules component 1545 identifies each line of data as new, change, or delete. It also checks for duplicates. If any records are found that are duplicates or there is a problem, the line record will be removed from the load and placed into an error queue. The information is provided (SN 7) to a rules met decisional module 1550, to determine if the rules are met.
If the rules are not met, the user is notified (SN 8) via the notification module 1535 and the process is terminated (SN 5) via the abort module 1540. If the rules are all met, a conversion component 1555 is called (SN 9). This step will dissect the file into manageable pieces. The data after converted to XML format will be placed (SN 10) in the appropriate queue (QUE) 1560. The conversion component 1555 then calls (SN 11) a load component 1565. The primary job of the load component 1565 is to log summary information generated during the load process. The load component 1565 calls (SN 12) a notification module 1570 of the converter application. The notification module 1570 sends (SN 13) notification to a verification module 1575 for verification of the loaded data for a vendor/manufacturer. If the request is verified, the records are added (SN 14) from the queue to the database in a module 1580, the queue is cleaned (SN 15) in a module 1585, and the vendor/manufacturer is contacted (SN 16) in a contact vendor/manufacturer module 1590. If the request is not verified, the vendor/manufacturer is contacted (SN 17) in the contact vendor/manufacturer module 1590 for verification. The converter application will have four views available (SN 18) of the different queues via a queue views module 1595.
The XML conversion links an unlimited combination of data types by tagging them with a standard, machine-readable language to define each piece of data and determine what it does. The converter component 1555 is used to read XML documents and provide access to their content and structure. Incoming data formats to the database conversion component 1555 will include, but are not limited to, text files, Microsoft (MS) Word documents, MS Excel spreadsheets, comma delimited files, pipe delimited files, MS Access database files, and hard copy documents.
For instance, the XML conversion formats the incoming data, stores it in a structured document and places the data into the appropriate queue. The data elements on an XML document are specified using an industry specific document template. Each class of products or company within the system would have its own document template. After a product, or class of products has been selected using one of the core attributes, the corresponding document template is queried for a list of product attributes. These product attributes would be the available data fields that the client application could display. The client application would directly pull the value of an attribute from an XML document using the attribute name it retrieved from the template. Extensible stylesheet language (XSL) style sheets are defined for the above referenced document templates. The style sheets will have input from the pertaining vertical industry.
The industries that have set XML-based standards or are in the process of setting standards include, but are not limited to, accounting, advertising, aerospace, agriculture, arts/entertainment, astronomy, automotive, banking, biology, business services, catalogs, chemistry, computer, construction, consulting, customer relation, customs, databases, e-Commerce, electronic data interchange (EDI), enterprise resource planning (ERP), economics, education, energy/utilities, environmental, financial service, food services, geography, healthcare, human resources, industrial control, insurance, Internet/Web, legal, literature, manufacturing, marketing/public relations (PR), math/data, mining, multimedia, news, professional service, public service, publishing/print, real estate, religion, retail, robotics/artificial intelligence (AI), science, security, software, supply chain, telecommunications, translation, transportation, travel, waste management, weather and wholesale. A vertical industry standard definition of XML tags and concepts of structure will reflect the definition of the above reference industries and support other data objects. Clean XML-files will be the result. Industry specific XML-based languages include, but are not limited to, wireless markup language (WML), handheld device markup language (HDML), compiled hypertext markup language (CHTML), electronic business extensible markup language (EBXML), human resources (HR)-XML, cognitive modeling language (CML), physics-XML, wireless application protocol (WAP), PALM query application (PQA).
Turning now to FIG. 16, illustrated is a flow diagram of an embodiment of a load flow detail constructed in accordance with the principles of the present invention. The sequence numbers (SNs) indicate a sequence of the method calls and the blocks represent objects for the implementation. A converter application 1610 retrieves (SN 1) data from the industry directories 1615. The converter application 1610 composes (SN 2) summaries of the information about to be loaded for the industry in connection with an information module 1620. The summaries are provided (SN 3) to a verification module 1625 to be emailed to the client for verification. If there is no verification within a time period, the queue will be cleaned (SN 4) via a clean queue module 1630, and the client is contacted (SN 5) for resolution via contact client module 1635. If there is a verification, the data is moved (SN 6) from the queue to the database via a move data module 1640. The client will be sent (SN 7) the summary information of what was loaded in a notify client module 1645, and the original data file sent from the client will be moved (SN 8) to an archive server for archiving via an archiving module 1650.
Turning now to FIG. 17, illustrated is a block diagram of an embodiment of a data distribution subsystem constructed in accordance with the principles of the present invention. The data distribution subsystem demonstrates that the database (designated “NetData”) spans many industries (designated “Industry A to G”) covering different subscriber models (Vendor Subscriber Models based on vendor and original equipment manufacturer (“OEM”) requirements) from the corresponding subscribers (designated “Vendor A, Vendor B, OEM”). An associated data warehousing subsystem takes into account a clickstream, customer, product, vendor information as well as queries to accommodate a data warehouse architecture. An associated data mining subsystem takes into account web usage, customer centric, internal centric, vendor centric, product centric and query centric influences to accommodate a data mining model.
Turning now to FIG. 18, illustrated is a block diagram of an embodiment of an error subsystem constructed in accordance with the principles of the present invention. The error subsystem receives inputs 1810 that include all error based events from all components. The errors can also be received from the database and web server. The errors are processed 1830 via an interface 1820. The interface 1820 to components allows different types of data input. XML, log file, event errors from other objects and database are acceptable forms of error data for an error object 1840. The processing 1830 logs the specified errors, and provides an output 1850, which may include email notification, recordsets, flat files, and XML outputs. The errors are broken into three sections. Application errors mainly dealing with the three applications, namely, the converter application, the loader application, and the reporter application. Component errors are focused on the individual components themselves and the errors they may generate. Industry errors are based on rules, the number of times the data coming into the system is erroneous will be maintained for each specific source. It will also be used to capture things such as requests against a particular industry that does not make sense or for a product that does not exist within the industry.
Turning now to FIG. 19, illustrated is a flow diagram of an embodiment of a follow me architecture for allowing a user to instantly go back in time constructed in accordance with the principles of the present invention. The sequence numbers (SNs) indicate a sequence of the method calls and the blocks represent objects for the implementation. A user 1910 logs (SN 1) into a web site via a web server 1920. The web server 1920 will call (SN 2) a response component 1930 to see if the user 1910 has any previous pages visited in this session. The response component 1930 will return (SN 3) the string sets to the web server 1920 of pages visited prior. Through the web server 1920, the user 190 makes a request to the database 1940 for a product that hasn't been requested during his session, the database 1940 is queried (SN 4). The information is sent (SN 5) to the response component 1930. The response component 1930 composes the page contents, logs it (SN 6) into a queue 1950, and sends it (SN 7) to the user 1910. The user 1910 views the request with links on his page to always see the last ten places on the site visited. The diagram also provides a high-level web page layout 1960.
Turning now to FIG. 20, illustrated is a block diagram of an embodiment of a database architecture constructed in accordance with the principles of the present invention. A database (designated “NDC Global Database” 2010) is geographically distributed and includes a global user profile 2015, user activity information 2020, global member profile 2025, industry catalog 2030, global product catalog 2035, member specific catalog 2040, global product information 2045, global industry product information 2050, member specific product information 2055, and miner output data 2060. The database 2010 is coupled to data access director 2065, a web access redirector 2070, and a data loader 2075, global replicator/synchronizer 2080, information quality inspector 2085, and a data miner 2090.
Turning now to FIG. 21, illustrated is a block diagram of an embodiment of a hardware architecture constructed in accordance with the principles of the present invention. The hardware architecture includes a data layer 2110 with five to six very large database servers (one of which is designated 2120). The database servers 2120 will house the various databases throughout the system architecture. The hardware architecture includes a business layer 2130 with two to three transaction servers (one of which is designated 2140). The transaction servers 2140 house the business components and oversee communication with requests from the web servers to the database. The hardware architecture includes a presentation layer 2150 with four to five web servers (one of which is designated 2160) in a web farmed environment. This allows the web servers 2160 to be used in parallel. Depending on the network traffic or server load, the user will be directed to the least busy web server 2160. Thus, this embodiment demonstrates three classes of machines, with each class including one or more machines based on demand.
Turning now to FIG. 22, illustrated is a block diagram of an embodiment of a reporting architecture constructed in accordance with the principles of the present invention. The reporting architecture begins with the separate databases being rolled into one common reporting database 2210. A reporting engine 2220 can be scheduled to build reports in the non-peak time of operations. An internal user 2230 of the system can generate internal reports 2240 using the reporting engine 2220. The reporting engine 2220 will nightly generate most static content 2250 in the non-peak times of operations such as XML, hypertext markup language (HTML), text (TXT), and portable document format (PDF) files. From the user request side, there are two primary reporting methods. Static reports 2260 are the nightly generated reports. The web server service 2270 can handle these types of reports. Other reports 2280 are reports that do not exist in static format or are more complex. A report object 2290 handles these types of reports.
The design is scalable and accommodates an “n-tier architecture” with complete stateless design. Using the latest technologies, the system can be administered from one machine and if more machines are needed due to increased usage or spikes, a new machine can be guaranteed in a matter of minutes up and running without any downtime to current users.
In an initial example configuration, as few as two servers can be used. A web server and business rules can exist on the same server while the second server maintains the main database, web statistics, images, customer information, product history, products, and the OLAP database. As demand increases, servers can be added without changing the architecture. Additional servers will be added, load balanced in a web farm environment. For example, two to three separate business and transaction servers and six very large database (VLDB) servers to maintain the central database. The six database servers may include an OLAP/data mining server for reporting and viewing mined and compiled data from all other databases, a products server (current products) for maintaining a current and up-to-date product information list, a product history server for maintaining historical information about products and their performance, a customer information server for maintaining customer information such as density, population, and income levels, a web statistics server for tracking web site hits and usage for analysis and customer profiling, and an image server for storing product images.
The discussion that follows will provide some detail about various components of the system. The components may specify functions prefixed with “low” and “high” pertaining to low and high bandwidth requests, respectively. A health function of many of the components provides information such as when a component was loaded, the number of times the component was called, failed, or timed out, and an average time the component was called per hour. A load component manages the load information from the separate systems and also disparate formats (see, e.g., the load process with respect to FIG. 13, et seq.). A converter application sends the planned approach on dissecting the data from the source. A DataLoadGroup function loads what the application intends to do with the inbound data including a group name for the data, total records inbound from the vendor, and the number of files created.
A product database component is the main wrapper component for almost all of the database specific activity within the architecture. An insert function accepts product information for industry and stores details in database. A security component manages the security requirements by identifying and recognizing user validity, and granting information privileges based on specific authorizations of the user. For example, within a specific vertical industry, a Chief Executive Officer (CEO) could have different access privileges from a field maintenance worker. The security component is also the vehicle whereby users, and vendors are added and/or deleted. The security component validates existence of user with a Profile Q component. If validated, the Profile Q component returns a user identifier (ID), industry, and other general user specific information available in the MSMQ. The security component has an insert function that allows an administrator at the system to insert users, groups, and vendors. The security component has an update function that allows an administrator at the system to update users or groups of users. The security component has a delete function that allows an administrator at the system to delete specific users or groups of users, and view the same. All deleted groups or users will be placed in a delete table. The security component has a restore function that allows an administrator at the system to restore specific users or groups who have been deleted. The security component has a history function that allows an administrator at the system to view specific users or groups historical adds and deletes. In accordance therewith, a Profile Q component manages the information in the Profile queue including restoring a server to a complete state pre-crash, view contents of queue(s), verify if users exist in the MSMQ database, and create or delete a queue(s).
A query handler component manages the SQL requests with respect to all product specific database requests. The query handler component checks Profile Q for permission, generates the query from user input and sends information to a query builder. The query handler component also looks over the processes of processing the query and identifying industries. The query builder component sends SQL statements to a catalog object component that identifies the industries involved with queries. The catalog object components returns all industries associated with the query after identifying the same. A product ranger component then sends the SQL statements to the appropriate industry components. The industry components retrieve relevant industry information and log the requested information to the appropriate industry database for analysis.
A conversion component contains rules for importing data into the system such as converting sets of incoming recordsets or a flat file to an XML file. A server health component also contains rules for importing data into the system. A search Q component has a preset process for restoring/recovering data from a lost queue, and can completely rebuild the queues. The search Q component can create or delate a queue(s), and return the contents of a queue(s). A product detail component retrieves more detail about a product. A product history component handles all historical product requests (e.g., show product summary sales from January 1990 to January 2001), and provides the historical information to meet the request.
A customer information component is where internal administrative work occurs such as, but not limited to, addition and deletion of customers, and modification of existing customer's attributes. The customer information component retrieves all information available for customer, adds new customer information, modifies existing customer information in the database, removes existing customer information in the database, and retrieves records from the database for customers that have been deleted or modified. The customer information component allows an administrator to add attributes to a customer table, remove existing attributes from the table, retrieve current list of customer attributes, and modify or change an existing attribute. A web statistics component retrieves the necessary information for analyzing and evaluating web site usage and customer profiling information (e.g., hits per month, most popular pages/products, etc.), and can return hit information to the web site.
An OLAP/data mining component handles multidimensional expression (MDX) requests and will be located within a transaction server to ensure that when user requests information from an OLAP cube the data will get back to the user. It sends the MDX request to an OLAP server, and returns dimensions, facts, and metadata based on database. An image server component fetches the appropriate image file from an image server upon web request including retrieving the requested image from the image server and generating a list of all images on server. An error handler component will handle and log all errors within the system. From a web error to a database error, this object will be called and log the necessary information to the database and, in some cases, send out notification if severe enough.
A report component will generate all reports for users based on request including excel files, PDF files, text files and Joint Photographic Experts Group (JPG) files. The report component will accept inbound SQL query and return a result set, and will return path to static batch processed reports for quick access. A rules component contains the rules for the imported data into the system, and is used to identify measures and specifics of quality for the inbound data into the system. Depending on the industry, there may be particular rules for how the data quality is measured. The data rules will identify the specific rules for the particular dataset. A client health component maintains relative server information and communicates the status back to the server health component, but will also be available to separate applications to query and instantly see status of the component. The client health component returns general server information from the system such as free space, memory, and utilization. A response object constructs the HTML for the output to be displayed.
The system and method support may types of unique identifiers. This list is not meant to be comprehensive. Other identifiers are readily apparent to one skilled in the art from the figures and descriptions included in this document. Each manufacturer has their own schema for assigning model numbers. This will provided from each manufacturer by product and common product model family such as Cannon 5000 Series. Also, a serial number is assigned specifically by the manufacturer to a specific product unit. A part number describes the parts in a product. The assumption is that a product itself can be a part with a part number, and may consist of many parts. A vehicle identification number may be assigned to a specific car. An International Standard Book Number (ISBN) is a 10-digit number that uniquely identifies books and book-like products published internationally. Every ISBN consists of ten digits and whenever it is printed, the letters ISBN precedes it. The ten-digit number is divided into four parts of variable length, each part separated by a hyphen. The four parts of an ISBN include a group or country identifier, which identifies a national or geographic grouping of publishers, a publisher identifier, which identifies a particular publisher within a group, a title identifier, which identifies a particular title or edition of a title, and check digit, which is the single digit at the end of the ISBN that validates the ISBN. A catalog number identifies a catalog for a product.
A stock keeping unit (SKU) number is associated with a product for inventory purposes, and is used by distributors. The universal product code (UPC) is a bar code symbol that is the standard in the retail, and a growing number of non-retail, marketplaces. It uniquely identifies a product and the manufacturer. UPC version A is the basic version of UPC and is usually the version seen on grocery store items. The symbology is used to encode the ten digit product code. An eleventh digit indicates the type of product, and a twelfth digit is a modulo check digit. The symbol is divided into two halves, each containing five digits. The two six-digit patterns are surrounded by left, center and right guard patterns. The left six digits use odd parity encoding while the right six digits use even parity encoding. The first digit is the UPC number system digit related to the type of product (0 for groceries, 3 for drugs, etc.). The next five digits are the UPC manufacturer's code. The first five digits of the right half are the product code. The final digit is the check digit. Although UPC A is continuous, the left and right halves of the symbol can be independently decoded. A digit is coded as a sequence of two bars and two spaces within a space seven modules wide. Bar and space widths may be 12, 3, or 4 modules wide. This results in 20 possible bar-space combinations. Ten of these patterns are used for the left odd parity digits and ten are used for the right even parity digits. The left digits always start with a space, while the right digits always start with a bar.
UPC version E is the next most common version of UPC. It is a zero suppression version of UPC. It is intended to be used on packaging which would be otherwise too small to use one of the other versions. The code is smaller because it drops out zeros that would otherwise occur in a symbol. For example, the code 59300-00066 would be encoded as 593663. The last digit (3 in the example) indicates the type of compression. Guard bars precede and follow the data (no middle guard bars). The digits are coded following the parity pattern EVEN, EVEN, ODD, ODD, EVEN, ODD. The data is enclosed between two left-hand guard bars and three right-hand guard bars. The six digit number is always preceded by a 0 and followed by the check digit. The way the check digit is computed is by expanding the type E to a type A, then doing the regular check. The first 6 digits of a type A code identify the manufacturer of a particular product. The manufacturer identification is controlled by the Uniform Commercial Code (UCC). The next five digits is a product identification number given by the manufacturer to uniquely identify each of their products. The final digit is a check digit which can be used to verify the correctness of a given UPC number. The first digit of a UPC code identifies the following as set forth in the TABLE 1 below.

TABLE 1

First Digit	Meaning

0	Normal UPC Code
1	Reserved
2	Products sold by weight
3	Health related products
4	UPC code used without limits
5	Coupon
6	Normal UPC Code
7	Normal UPC Code
8	Reserved
9	Reserved

The European article numbering (EAN) system, the Japanese article numbering (JAN) system and the International article numbering (IAN) system are identical to UPC except for the number of digits. The JAN codes are the same as the EAN codes, with the flag characters set to “49”. There are two principal EAN versions. Standard EAN (sometimes called EAN-13) has ten numeric characters, two or three “flag” characters that are usually a code for the country of the EAN International organization issuing the number, and a check digit. In all other respects, it is identical to UPC version A. JAN is the same as EAN-13. For compatibility with UPC, flags 00,01,03,04, and 06 through 13 are assigned to the United States. Global trade item number (GTIN) a globally unique 14 digit number assigned to each packaging level of a product/service. A GTIN may use the EAN/UCC-8, UCC-12, EAN/UCC-13 or EAN/UCC-14 standard numbering structure. A GTIN is used when communicating with other trading partners. A social security number (SSN) is the standard SSN issued to individuals.
The NDC is a unique 10-digit, 3-segment number assigned by the Food and Drug Administration (FDA). The NDC identifies the labeler/vendor, product, and trade package size. The first segment, the labeler code, is assigned by the FDA. A labeler is any firm that manufactures, repacks or distributes a drug product. The second segment, the product code, identifies a specific strength, dosage form, and formulation for a particular firm. The third segment, the package code identifies package sizes. Both the product and package codes are assigned by the firm. The NDC will be in one of the following configurations: 4-4-2, 5-3-2, or 5-4-1. The United Nations/Standard Products & Services Classification (UN/SPSC) is an open, global electronic standard that provides a logical framework for classifying goods and services. A serial shipping container code (SSCC) is an 18 digit number that uniquely identifies every carton, pallets, etc. in a shipment.
The data access within the application environment will be achieved using stored procedures that are being called from the data access layer. In other words, all database access will be using stored procedures. This not only achieves query and data access management from a central location, but also increases the performance. The stored procedures are classified into different groups depending on the subject area with some examples being general, subscriber management, user login management, administrative activities, user activity, product management, data loading process, search, reporting and shipping. All user stored procedures (i.e., all procedures other than system stored procedures) begin with the subscript usp_. For example, a procedure to add a product will be called usp_AddProduct. Typically, the names for insert, delete, and update will begin as usp_Addxxx, usp_Editxxx, usp_Deletexxx and so on. All stored procedures must return a value at the end. This can be achieved by using RETURN @@ERROR. The value will be 0 (success), −1 (error), other negative numbers (error values, specific to stored procedure), positive numbers (stored procedure specific values). If needed, the same value may be returned in a SELECT statement.
All stored procedures must be well commented. The comments must be entered after the input parameter definition, and must include a description of the input as well output parameters, a brief description of the stored procedure, including intended usage if needed, and return values. An example is set forth in the following TABLE 2.

TABLE 2

	Usp_AddSubscriberType (@SubsciberTypeNum INT ;: 0, @Description varchar(20))
	AS
	-- This procedure is used to add a subscriber type.
	-. @SubsciberTypeNum INT subscriber number.
	-- If 0, a new subscriber number will be generated automatically.
	-. @Description varchar(20) - Description.
	-- Return Values: 0 - success.
	-- Returns the subscriber type number as a result set in a SELECT statement.

The description of the stored procedures in this document will be same as that of the comment entry in the stored procedure.

The following tables describe non-limiting examples of data fields for data models associated with the system and method as described herein. The data fields provided in the tables are selectively coupled to form the respective models. A catalog index model is limited to a SearchCatalog category data field. TABLE 3 below includes example data fields for an address data model.

TABLE 3

Category	Data Field	1	Data Field 2

Country	CountryNum	CountryName, CountryCode
State	StateNum	StateCode, CountryNum,
		StateName
City	CityNum	StateNum, CountryNum,
		tfcMarketID, CityName
AddressType	AddressTypeID	Description
Address	AddressIN	AddressTypeID,
		BuildingNumber,
		BuildingName, Street,
		Suite, City, State
Employment Type	EmploymentTypeNum	Description
Person	PersonIN	SubscriberNum, FirstName,
		MiddleName, MiddleInitial,
		LastName, AddressIN,
		EmploymentTypeNum
Contact	ContactID	SubscriberNum,
		ContactType,
		ContactName,
		ContactAddress
NotifyGroupContact	SubscriberNum,
	NotifyGroupID,
	ContactID
NotifyGroup	SubscriberNum,
	NotifyGroupID

TABLE 4 includes example data fields for a product data model.

TABLE 4

Category	Data Field	1	Data Field 2

Subscriber Industry	SubscriberNum,
	IndustryNum
Product Attribute	IndustryNum,	AttrType, AttrValue
	AttrNum, NDCID
Attribute	IndustryNum,	AttrName
	AttrNum
Category	CatNum	CatName
SubCategory	CatNum, SubCatNum	SubCatName
ProductCommentLogin	SubscriberNum,	CommentID
	LoginID, NDCID,
	CommentDateTime
Product	NDCID	RxID, MfrNum,
		PartNum,
		MajorIndustryNum,
		CatNum, SubCatNum,
		ModelFamilyNum,
		ModelNum,
		ProdFamilyID,
		GTINID, 10UPC,
		ISBNTypeNum,
		ISBN, UPCAID,
		UNSPCCID,
		CatalogNum,
		BrandName,
		ProductName,
		ShortDescription,
		PDADescription,
		LongDescription,
		Size, UOMQty,
		UserManual,
		SpecsFile
ProductAttribute	NDCID	Attr1Name,
		Attr2Name,
		Attr3Name
Mfr	MfrNum	MfrName
ProductFamily	ProdFamilyID	ProdFamilyName
ModelFamily	MfrNum,	ProdFamilyID
	ModelFamilyNum
ProductUsage	NDCID, UsageNum
Usage	UsageNum	Description
ProductCommentCommon	CommentID	NDCID, Comment,
		EnteredBy
Part	PartID	MfrNum, PartNum,
		PartName
PartAlternate	MfrNum	PartNum,
		AltMfrNum,
		AltPartNum,
		AltQuality,
		Comment
ProductPart	MfrNum, PartNum,
	SubMfrNum,
	SubPartNum,
	SubPartName
Industry	IndustryNum	IndustryName,
		IN1Name, ID1Name
ProductIndustry	IndustryNum, NDCID	IndIN1, IndID1
ISBNTitle	ISBN	ISBNTypeNum,
		ISBNCountryNum,
		ISBNPublisherNum,
		ISBNTitleNum,
		ISBNTitle
ISBNPublisher	ISBNPublisherNum,	PublisherName
	ISBNCountryNum
ISBNCountry	ISBNCountryNum	CountryName
ISBNType	ISBNTypeNum	TypeName
UPCMfr	UPCMfrNum	MfrNum
UPC	UPCAID	UPCTypeNum,
		UPCMfrNum,
		UPCProdNum,
		UPCEID, EANID
EAN	EANID	UPCTypeNum,
		UPCMfrNum,
		UPCAID
UPCType	UPCTypeNum	Description
UNSPCC	UNSPCCID
GTIN	GTINID
DrugCode	RxID	RxVendorNum,
		RxProductNum,
		RxPkgSize

TABLE 5 includes example data fields for a subscriber data model.

TABLE 5

Category	Data Field	1	Data Field 2

SubscriberType	SubsciberTypeNum	Description
AccountType	AccountTypeNum	Description
Contract	SubscriberNum,	ContractTypeID, CreationDate,
		StartDate, EndDate,
	ContractID	ContractName
ContractType	ContractTypeID	Description
Subscriber	SubscriberNum	SubscriberTypeNum,
		SubscriberName,
		AccountTypeNum, ActiveFlag,
		SubscriberFromDate,
		MainAddressNum,
		BillingAddressNum,
		AdminContactPN,
		BillingContactPN,
		Color1-4, Logo1-4
Facility	SubscriberNum,	FacilityType, FacilityName,
	FacilityID	Latitude, Longitude, BuildingName,
		BuildingNumber, Street, Suite,
		City, State, Country, Metro

TABLE 6 includes example data fields for a login data model.

TABLE 6

Category	Data Field	1	Data Field 2

Login	SubscriberNum,	PersonIN, ActiveFlag,
	LoginID	DisabledFlag, Password,
		DateCreated,
		DateActiveFlagChange,
		DateDisabledFlagChange,
		DateChanged, RoleID,
		LastLoginTime
LoginProfile	SubscriberNum,	ProfileName
	LoginID
Role	RoleID	RoleDescription
LoginGroup	SubscriberNum,	LoginGroupName,
	LoginGroupNum	CreateDate, Description,
		ProductAddPt, ProductDelPt,
		ProductEditPt, ProductViewPt,
		CommentPt, IsSubscriberAdmin,
		IsGroupAdmin, IsNDCAdmin
LoginGroupMember	SubscriberNum,
	LoginID,
	LoginGroupNum

TABLE 7 includes example data fields for an inventory data model.

TABLE 7

Category	Data Field	1	Data Field 2

ProductSKU	XTailerNum, SKU	NDCID, CatalogNum, Dept,
		Class, SKUDescription,
		SKUStatus, DateFirstSale,
		InService, DateLastSale
XTailer	XTailerNum	SubscriberNum, XTailerName
Vendor	XTailerNum,	VendorName
	VendorNum
Store	XTailerNum,	SubscriberNum, FacilityID,
	StoreNum	StoreName, Location, City,
		BldgNum, Street, Suite,
		CountryNum
SubscriberXTailer	SubscriberNum,
	XTailerNum
StoreSKU	XTailerNum, SKU	Qty, Aisle, DateLastSale

TABLE 8 includes example data fields for a support data model.

TABLE 8

Category	Data Field	1	Data Field 2

Support	SubscriberNum,	CallLogID, SupportCallTypeID,
	TheDateTime	UserTypeID, Severity,
		PersonReportedName,
		PersonReportedEmail,
		PersonReportedTel,
		PersonReportedFax,
		SecondContactName,
		SecondContactEmail,
		SecondContactTel,
		SecondContactFax,
		Comment, AssignedTo,
		ResolvedDate,
		ResolutionComment
SupportCallType	SupportCallTypeID	Description
UserType	UserTypeID	Description

TABLE 9 includes example data fields for a login activity data model.

TABLE 9

Category	Data Field	1	Data Field 2

LoginID	NDCSessionID	SubscriberNum, LoginGroupNum,
		LoginTime
LoginActivity	NDCSessionID,
	ActivityID
UserActivity	ActivityID	Description

TABLE 10 includes example data fields for a shipping data model.

TABLE 10

Category	Data Field	1	Data Field 2

SSCC	SSCCID	ContainerTypeID, NumItems,
		DateShipped, DateReceived
ContainerType	ContainerTypeID	Description
SSCC	SSCCID, ItemID
ShipInfo	SSCCID
ReceiptInfo	SSCCID
Item	ItemID	SSCCID, ItemTypeID, Description
ItemType	ItemTypeID	Description

TABLE 11 includes example data fields for a data management data model.

TABLE 11

Category	Data Field	1	Data Field 2

Server	ServerNum	ServerName, IPAdress,
		OperatingSystem
DBManagement	DBNum	ServerNum, DBTypeNum,
		DBName, Description
DBType	DBTypeNum	Description

TABLE 12 includes example data fields for a web track data model.

TABLE 12

Category	Data Field	1	Data Field 2

WebTrack	UDT	LDT, CustomerName, CustomerID, SessionID,
		PageID, Referrer, IndustryNum, PagesVisited,
		SessionSecs, Host, RequestString, Status, Bytes,
		UserAgent

Thus, the system and method exploits the capabilities and architecture of the Internet, PDAs, UPC codes or other unique identifiers, and database management techniques to provide relevant, timely, and accurate information for any item including products, individuals, and commodities. The system and method pertains to an M-Commerce, E-Commerce, and supply chain management system that functions as a real-time, individual, personal information aid. More specifically, this aid is available either by wireless or wired communications means and is concerned with the availability of quick and high quality data presented in a manner and detail that can be determined by the user and need not have a priori set up. This information is presently only available by extensive personal research via the Internet or similar means, specific individual queries, and/or personal visits to multiple physical locations. The present invention is particularly suited for, but not limited to shopping aids, field queries by service or sales personnel to solve real time problems discovered at customer sites, just-in-time management of resources at the location of need, individualized medical records, and individualized insurance records. What is important is to establish an intimate and direct relationship, in the form of a query, between the customer and given products or product classes that are of interest at that moment. The specific attributes of this query must be easily defined in a natural manner by the customer. The result is a system and method to facilitate in multiple purchase decision transactions, specification information and other similar information.
One skilled in the art should know that the present invention is not limited to receiving and processing a request message, and performing a search of the Internet. The present invention and method may also perform multiple functions at the same time. Also, other embodiments of the present invention may have additional or fewer steps than described above.
While the methods disclosed herein have been described and shown with reference to particular steps performed in a particular order, it will be understood that these steps may be combined, subdivided, or reordered to form an equivalent method without departing from the teachings of the present invention. Accordingly, unless specifically indicated herein, the order and/or the grouping of the steps are not limitations of the present invention.
Although the present invention has been described in detail, those skilled in the art should understand that they can make various changes, substitutions and alterations herein without departing from the spirit and scope of the invention in its broadest form.

Claims

What is claimed is:

1. A communication device operable with and remote from an information system containing core information, comprising:

a processor; and

memory including computer program code, said memory and said computer program code configured to, with said processor, cause said communication device to perform at least the following:

generate a request message containing a request for some of said core information from said information system;

receive at least one response message from said information system formatted based on a characteristic of a screen associated with said communication device and including:

said some of said core information,

a non-monetary rating of a value of said some of said core information,

an image of said some of said core information, and

a link to a web page associated with some of said core information; and

display said some of said core information, said non-monetary rating of said value of said some of said core information, said image of said some of said core information, and said link to said web page associated with said some of said core information on said screen, said communication device being capable of displaying a list of previous web pages visited by said communication device.

2. The communication device as recited in claim 1 wherein said list of previous web pages visited by said communication device comprises a link to said previous web pages.

3. The communication device as recited in claim 1 wherein said link to said web page associated with said some of said core information is tagged when said web page is visited by said communication device.

4. The communication device as recited in claim 1 wherein said request message comprises a category of said some of said core information and a request for more information about said category for said some of said core information.

5. The communication device as recited in claim 4 wherein said category for said some of said core information comprises a product and said more information about said category for said some of said core information comprises an attribute of said product.

6. The communication device as recited in claim 1 wherein said at least one response message from said information system is formatted based on a preference associated with said communication device.

7. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to display said some of said core information, said non-monetary rating of said value of said some of said core information, said image of said some of said core information, and/or said link to said web page associated with said some of said core information on different pages.

8. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to limit said display of said some of said core information, said non-monetary rating of said value of said some of said core information, said image of said some of said core information, and said link to said web page associated with said some of said core information according to a selected criterion.

9. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to generate a refining request message in response to said at least one response message.

10. The communication device as recited in claim 1 wherein said at least one response message comprises a location of said some of said core information or a distance of said communication device to said some of said core information.

11. The communication device as recited in claim 1 wherein said at least one response message is a function of a profile of said communication device.

12. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to log into said information system using an access identifier, said at least one response message from said information system being a function of access privileges associated with said access identifier.

13. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to log into said information system using an access identifier, said format of said at least one response message and content of said some of said core information being a function of a profile of said communication device associated with said access identifier.

14. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to generate said request message from a voice input into said communication device.

15. The communication device as recited in claim 1 wherein said memory and said computer program code are further configured to, with said processor, cause said communication device to receive an updated response message based on an update to said some of said core information within said information system.

16. The communication device as recited in claim 1 wherein said at least one response message is a function of web page usage with respect to said some of said core information.

17. A method operable on a processor of communication device remote from an information system configured to contain core information, comprising:

generating a request message containing a request for some of said core information from said information system;

receiving at least one response message from said information system formatted based on a characteristic of a screen associated with said communication device and including:

said some of said core information,

a non-monetary rating of a value of said some of said core information,

an image of said some of said core information, and

a link to a web page associated with some of said core information;

displaying said some of said core information, said non-monetary rating of said value of said some of said core information, said image of said some of said core information, and said link to said web page associated with said some of said core information on said screen; and

displaying a list of previous web pages visited by said communication device.

18. The method as recited in claim 17 wherein said list of previous web pages visited by said communication device comprises a link to said previous web pages.

19. The method as recited in claim 17 wherein said link to said web page associated with said some of said core information is tagged when said web page is visited by said communication device.

20. The method as recited in claim 17 wherein said generating said request message comprises providing a category of said some of said core information and a request for more information about said category for said some of said core information.

21. The method as recited in claim 20 wherein said category for said some of said core information comprises a product and said more information about said category for said some of said core information comprises an attribute of said product.

22. The method as recited in claim 17 wherein said at least one response message from said information system is formatted based on a preference associated with said communication device.

23. The method as recited in claim 17 further comprising limiting said display of said some of said core information, said non-monetary rating of said value of said some of said core information, said image of said some of said core information, and said link to said web page associated with said some of said core information according to a selected criterion.

24. The method as recited in claim 17 further comprising generating a refining request message in response to said at least one response message.

25. The method as recited in claim 17 wherein said at least one response message is a function of a profile of said communication device.

26. The method as recited in claim 17 further comprising logging into said information system using an access identifier, said at least one response message from said information system being a function of access privileges associated with said access identifier.

27. The method as recited in claim 17 further comprising logging into said information system using an access identifier, said format of said at least one response message and content of said some of said core information being a function of a profile of said communication device associated with said access identifier.

28. The method as recited in claim 17 wherein said generating said request message is from a voice input into said communication device.

29. The method as recited in claim 17 further comprising receiving an updated response message based on an update to said some of said core information within said information system.

30. The method as recited in claim 17 wherein said at least one response message is a function of web page usage with respect to said some of said core information.