Patent Application
20210256539
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.
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.
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.
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:
Referring initially to
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
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
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
Turning now to
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
Turning now to
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
Turning now to
Turning now to
Turning now to
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
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
Turning now to
Turning now to
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 21a). The image server component 1185 will return the path to the image (SN 21b). 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
Turning now to
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
Turning now to
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
Turning now to
Turning now to
Turning now to
Turning now to
Turning now to
Turning now to
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
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.
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.
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 4 includes example data fields for a product data model.
TABLE 5 includes example data fields for a subscriber data model.
TABLE 6 includes example data fields for a login data model.
TABLE 7 includes example data fields for an inventory data model.
TABLE 8 includes example data fields for a support data model.
TABLE 9 includes example data fields for a login activity data model.
TABLE 10 includes example data fields for a shipping data model.
TABLE 11 includes example data fields for a data management data model.
TABLE 12 includes example data fields for a web track data model.
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 60306127 | Jul 2001 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13663231 | Oct 2012 | US |
| Child | 17248993 | US | |
| Parent | 10197065 | Jul 2002 | US |
| Child | 13663231 | US |
