WORLD WIDE WEB BAR CODE ACCESS SYSTEM

Abstract: A bar code scanner (26) is coupled to a computer program (20) executing on a PC (10) that has access to the World Wide Web (WWW) of the Internet (14). A user swipes the bar code scanner (26) over a bar code (27) printed on printed material (29) to obtain additional information available on the WWW relating to information printed in a newspaper, book, magazine, catalog, or other printed material. The bar code contains a unique identifier called a resource link code. The resource link code scanned by the bar code scanner (26) is received by the computer program (20) and sent in a data packet over the Internet (14) to a resolution server (12, 22). The resolution server (22) translates (34) the resource link code into a Uniform Resource Locator (URL). The URL is then passed back to the computer program (20) executing in the user's PC (10). The computer program (20) passes the URL to a WWW browser program (16), which obtains the selected information over the WWW.

Description: WORLD WIDE WEB BAR CODE ACCESS SYSTEM This application claims the benefit of U.S. Provisional Application No. 60/016, 101 , filed July 21 , 1996, entitled "Analog Digital Bridge Software". Field of the Invention This invention relates generally to user interfaces for accessing information in distributed computer systems and more specifically to using a bar code scanner as a user interface for accessing information over the World Wide Web (WWW) of the Internet. Background of the Invention For hundreds of years the printed page has served as a standard means of communication between people. However, static printed materials inherently have a fundamental disadvantage in that in order to update the information contained therein, the materials must be reprinted. Often, printed materials such as books, newspapers, magazines, catalogs, and encyclopedias are out of date very soon after they are printed. Updating these materials frequently is an expensive and time-consuming endeavor. Additionally, it is difficult to link information contained in printed materials to other information in a dynamic and efficient manner. These disadvantages can be overcome by accessing and using digitally stored information. Information stored digitally in a computer system can be frequently and economically updated to reflect changes in that information. The information can be easily linked to other relevant information. Such information must be readily and easily available to many users in order to be valuable as a tool for widespread dissemination of knowledge. With the explosive growth in usage of the Internet, the dissemination of up-to-date information to large numbers of people is now commonplace. The Internet is a global network of connected computers. The World Wide Web (WWW) is the universe of accessible information available on a portion of the Internet. The WWW has a body of software, a set of protocols and a set of defined conventions for getting information over the WWW. The WWW uses hypertext and multimedia techniques to make it easy for users to gain access to this information. Typically, a user operates browser software on a personal computer (PC) to access information stored at a specified location on the WWW. One protocol by which the browser software specifies what information to obtain and display to the user and how to retrieve the information is known as the HyperText Transfer Protocol (HTTP). HTTP is used by a computer system known as a WWW server and a browser executing on a client computer system to communicate over the computer network. The information may consist of text, graphics, sound, motion pictures, and other data. This information is digitally stored in one or more files on the WWW server, which is connected to the Internet. A specific location of a file on the Internet is designated by a Uniform Resource Locator (URL). A URL is a string expression that can represent any resource on the Internet or on a local Transmission Control Protocol/Internet Protocol (TCP/IP) computer system. TCP/IP is a networking protocol that provides communication across interconnected networks, and between computers with diverse hardware architectures and various operating systems. The resource pointed to by the URL may be any type of file, including text files, executable files, image files, etc. The most common form of a URL is an HTTP address. Hence, if a user knows the URL of a piece of information available on the WWW or a local system, the user can type in the URL on the keyboard of the user's PC (in response to a prompt from the browser software) to obtain the desired information. The user inputs the URL to the browser software to select the location of the desired information to be fetched over the WWW and displayed on the PC's display. Many URLs are long and complex character strings, which usually include special characters and delimiters such as colons and slashes. Often the user is confused and frustrated when typing in long URLs into the browser because any errors in keying in the URL result in incorrect HTTP addresses. The browser then reports the error without displaying the desired information and the user must again attempt to enter in the correct URL. This effort is especially problematic for younger children, the elderly, or anyone who has little experience operating computers. However, even experienced users often make mistakes typing in long URLs, thereby wasting valuable time. An interface for entering URLs which is easy to use and largely free of user errors would help promote the widespread use of the WWW as a source of information to the general public, rather than let the WWW continue to be a tool only for those who are computer-literate. Such an interface should combine the advantages of printed materials and computer networks to provide easy access to a wide range of computerized, up-to-date information. This interface would allow printed materials to contains links to dynamic information stored electronically. The present invention creates a system which capitalizes on the widespread use of printed material (and its attendant low cost) with the dynamics of information storage and retrieval of the Internet and other distributed computer systems. Summary of the Invention An embodiment of the present invention includes a bar code scanner that is coupled to a computer program executing on a computer system that has access to the Internet. When a user desires to obtain additional information available on the WWW relating to information printed, for example, in a newspaper, book, magazine, catalog or other printed material, the user swipes the bar code scanner over a bar code printed on the printed material. The bar code contains a unique identifier called a resource link code. The resource link code scanned by the bar code scanner is received by the computer program and sent in a data packet over the Internet to a computer system called a resolution server. The resolution server translates the resource link code into a URL. The URL is then passed back to the computer program executing in the user's PC. The computer program passes the URL to a WWW browser program, which obtains the selected information over the WWW in the conventional manner. The communication details between the bar code scanner, the user's PC, and the resolution server are transparent to the user. The user merely scans the bar code and the selected information is fetched over the WWW is displayed on the user's PC display. Furthermore, the present invention allows WWW content providers to move content between servers in a way that is transparent to the user. Additional advantages and novel features of the invention will be set forth in part in the description which follows, and will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. According to one embodiment of the present invention, the foregoing and other advantages are attained by a system for obtaining a uniform resource locator addressing an information resource available on the World Wide Web (WWW) of the Internet. The system includes a bar code scanner for scanning a bar code printed on a printed material to produce bar code data. The system accepts the bar code data identifying an information resource on the WWW and translates it into a uniform resource locator addressing the information resource. In another embodiment of the present invention, a method of accessing an information resource over the World Wide Web portion of the Internet includes the steps of scanning a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource on the World Wide Web, translating the bar code data into a uniform resource locator of the information resource, and obtaining the information resource identified by the uniform resource locator. In another embodiment of the present invention, a client/server system for accessing an information resource available on the WWW of the Internet includes a client system coupled to the Internet for scanning a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource accessible over the Internet, for sending a command packet including the bar code data, and for receiving a response packet including a uniform resource locator of the information resource. The system includes a server system coupled to the Internet for receiving the command packet, for translating the bar code data of the command packet into the uniform resource locator, and for sending the response packet including the uniform resource locator to the client system, and a browser operating on the client system for accessing the information resource identified by the uniform resource locator. Still other advantages of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein is shown and described only the preferred embodiment of the invention, simply by way of illustration of the best mode contemplated for carrying out the invention. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive. Brief Description of the Drawings FIG. 1 is a block diagram of one embodiment of the present invention. FIG. 2 is a block diagram of an alternate embodiment of the server of the present invention. FIG. 3 is a flow chart of the steps to initialize the WEB WAND system. FIG. 4 is a flow chart of the steps to initialize the WEB WAND application on the Client System. FIG. 5 is a flow chart of the processing steps for the WEB WAND application on the Client System. FIG. 6 is a flow chart of the processing steps for the Resolution Server of FIG. 1. FIG. 7 is a diagram of the message commands communicated in the command and response packets between WEB WAND and the Resolution Server. Detailed Description of the Preferred Embodiment The present invention is a system and method that provides a simple, easy-to-use interface for accessing information on the World Wide Web (WWW) of the Internet. FIG. 1 is a block diagram of one embodiment of the present invention. A Client System 10 executing on a computer system local to a user forwards all requests to a remote file Server System 12. The Server System 12 accepts the Client's request, performs its associated operation, and returns a response to the Client System 10. Client System 10 may comprise a user's personal computer (PC), an engineering workstation, a large mainframe computer, or any other computer system capable of supporting client functions. Client System 10 may also be an Internet Appliance. An Internet Appliance is a low cost machine specially designed for Internet browsing that is not necessarily based on standard PC technology, Intel or Motorola microprocessors, or the WINDOWS operating system. This device, also called an Internet Terminal, would have a minimum amount of random access memory (RAM) and flash memory, a processor, a monitor, a keyboard, and a mouse (not shown). The Server System 12 is typically a general purpose computer system specifically configured to provide server functions. In the preferred embodiment, the Client System 10 and the Server System 12 communicate via the Internet 14, using a protocol called the Web Wand Resolution Protocol (WWRP). The WWRP is similar in design to the well-known Simple Mail Transfer Protocol (SMTP), but incorporates as different functionality and syntax. As discussed above, the Internet is a global network of connected computers which uses the Transmission Control Protocol/Internet Protocol (TCP/IP). SMTP is a TCP IP protocol that operates at layers 5 through 7 of the Open Systems Interconnection (OSI) model. SMTP is widely used to govern electronic mail transmissions and receptions on the Internet. Client System 10 includes various application programs. World Wide Web (WWW) Browser software 16 executes on the Client computer system. WWW Browser software retrieves documents called information resources from servers on the World Wide Web to the Client for display to the user. It allows the user to "move" easily from one WWW site to another. Every time a user requests a display of a specific information resource such as a WWW "page" or file, WWW Browser 16 obtains a copy of the requested file from a storage location of a server on the WWW for the Client. WWW Browser uses HyperText Transfer Protocol (HTTP) as a protocol for communicating over the Internet 14 to one of a plurality of HTTP Servers 18. The Client's connection to the Internet may be via a local area network (LAN) or via a modem and a telephone line. WWW Browser program 16 is resident on the Client System and requests a file containing information resources from a selected HTTP Server 18 and the HTTP Server forwards the file to the WWW Browser program on the Client. The address of the file must conform to the specified HTTP syntax (for example,"http://www.somebody.com/public/files/hello.htmr'). Examples of well known browsers include NAVIGATOR, commercially available from Netscape, and INTERNET EXPLORER, commercially available from Microsoft Corporation. WEBWAND 20 is an application program executing on Client System 10 that communicates with Resolution Server 22 resident in Server System 12. WEBWAND accepts scanned bar code data over Line 24 from optical Scanner 26. Scanner 26 is operated by a user 25 to scan a bar code 27 appearing on a printed material 29 such as a newspaper, book, catalog, etc. The bar code 27 may be in the Universal Product Code (UPC) format or any other bar code format capable of being reliably scanned by Scanner 26. Multiple bar code formats are simultaneously supported by WEBWAND 20. The bar code 27 represents a unique identifier of an information resource available on the WWW. In the preferred embodiment, the Scanner is a KEY WAND brand scanner commercially available from Hewlett-Packard Corporation, although other bar code readers are also available and equally suitable. Scanner 26 is attached to or in-line with the keyboard (not shown) of the Client System 10. The keyboard is typically attached to the Client System via a serial port. The Scanner sends keyboard scan codes (the data format used to represent key strokes) to the Client System, which presents it to WEBWAND 20 as American Standard Code for Information Interchange (ASCII) format data. The data is prepended with a special character to denote an input from Scanner 26. In the preferred embodiment, the special character is Function Key 12 (F12) although other character codes could also be used. Alternatively, Scanner 26 is attached directly to a standard serial port (not shown) of the Client System. Either method of attachment works equally well. There are two types of scanners that can be attached to a serial port, decoding and non-decoding. A decoding scanner converts the bar code data into ASCII data, which is then transmitted via the serial port. A non-decoding scanner sends a digital representation of the bar code according to light-to-dark state transitions. A special scanner driver computer program executed by the Client System is then required to convert those transitions into ASCII data. If a decoding scanner is used, WEBWAND 20 directly reads the ASCII data from the serial port. If a non-decoding scanner is used, the data is read from the scanner driver software. In either case, the data is presented to WEBWAND 20 in the form of ASCII data. The user 25 may also type in the bar code number via the keyboard (not shown) of the Client System 10 if the bar code is disfigured or if the Scanner is not able to scan the bar code without errors occurring. WEBWAND 20 formats the scanned bar code data received from Scanner 26 into a Resource Link Code (RLC) by stripping off any unnecessary header or trailer information, inserts the RLC into a command packet and sends the command packet through the Internet 14 to Resolution Server 22 over Lines 28 and 30. The command packet also contains a unique Identifier (ID) of the Client, which is obtained from a Client ID Data file 32 on Client 10. Client ID Data file 32 also contains information regarding user preferences, such as whether to look for RLC translations locally or over the Internet, a list of Resolution Servers to communicate with, and which Resolution Server from the list is to be contacted first when a translation is needed. There may be multiple Client ID Data files on Client 10, one for each user of the Client system. Resolution Server 22 receives the command packet, extracts the RLC and accesses RLC/URL Database 34. RLC/URL Database 34 stores a mapping of a RLC to a URL. That is, given a RLC, a corresponding URL may be obtained from the RLC/URL Database. In the preferred embodiment, the RLC URL Database is structured as a hash table, although other data structures or database management systems, such as relational databases, may also be used. After the RLC to URL translation is made, the URL is inserted into a response packet. The response packet is sent from Resolution Server 22 through the Internet 14 over Lines 36 and 38 to WEBWAND 20 in Client 10. WEBWAND 20 decodes the response packet received from Resolution Server 22 and extracts the URL. The URL is then passed as an input to WWW Browser 16. WEBWAND transfers the URL to WWW Browser 16 using an inter-application communication standard such as Object Linking and Embedding (OLE) or Dynamic Data Exchange (DDE). WWW Browser 16 uses the URL to access the desired information resource on the WWW by contacting a HTTP Server 18 in the usual manner. Upon receipt of the information from the HTTP Server 18, WWW Browser 16 displays the information to the user. The operations performed by WEBWAND and the Resolution Server are transparent to the user. The present invention also allows the Resolution Server to authenticate and monitor individual requests for RLC/URL translations. For example, if access to the WWW site specified by the desired URL is restricted due to membership requirements or content ratings, Resolution Server 22 queries User Database 40 to verify authorization and validate access. The user can subscribe as a member to a particular WWW site by using WWW Browser 16 to communicate with one or more HTTP Servers 42. HTTP Server 42 then updates the User Database 40 to add the user to the list of valid users for the selected WWW site. Access restrictions based on a site's content rating can also be easily accomplished. If each user of a Client has an individualized Client ID Data file 32 which is accessed when the user initializes the system, then a unique Client ID will be included in the command packets sent to the Resolution Server. For example, if the user is a child, then the record in the User Database 40 for this user reflects this fact and allows the Resolution Server to refuse to process requests to sites which are deemed to have objectionable content for children. One skilled in the art can readily see that because WEBWAND 20 interactively communicates with Resolution Server 22 to translate RLCs into URLs, WWW access requests initiated by Scanner 26 allow Server 12 to specifically tailor the presentation of information to the user based on user preferences. The User Database 40 can be used to store user preferences for each user of Client 10. For instance, one user preference might be a selected language for presentation of information. In this case, if the user preference for User No. 1 of Client 10 is English, but the user preference for User No. 2 of Client 10 is Spanish, this difference is handled by Resolution Server 22 when translating the RLC into a URL. That is, given a particular RLC from WEBWAND 20, Resolution Server 22 will translate the RLC into one URL if the user's language preference is English, but another URL if the preference is Spanish. Resolution Server 22 knows which user is operating the Client based on the individual Client ID selected by each user during system initialization. Of course, user selection of a Client ID can be password- protected to provide security against one user logging on as another user. Other user preferences include geographic location, age, education level, hobbies and interests, and so on. Resolution Server 22 also collects and stores information relating to requests for RLC/URL translations in a database called the Activity Log 44. Demographic information and statistics concerning user activity from the Activity Log 44 can be used by publishers and other content providers for real-time monitoring of usage of particular WWW sites. This information can be used to manage the performance of the WWW sites. Other information about the user and his or her equipment can also be collected using the present invention. For example, the technical capability of the user's computer system can be monitored. Such features as bandwidth, speed of transmission, display capability, and browser environment capability (e.g., support for Java or Active X technologies) can be transmitted to the Resolution Server 22 along with the scanned data and stored for later analysis. Demonstrated user behavior can also be stored to help content providers or advertisers tailor the presentation of the data for maximum effect. Such factors as attention span, response to various advertising formats, and degree of interactive behavior to selected content can be received with the scanned data and stored in the Activity Log 44. FIG. 2 is a block diagram of an alternate embodiment of the Server of the present invention. In this embodiment, Server System 12' includes functions interactively supporting publishers or other providers of information. The Bar Code Assignment and Management function 46 assigns and manages the Resource Link Code (RLC) to Uniform Resource Locator (URL) mapping. Bar Code Assignment and Management 46 creates a link between one or more URLs and a RLC according to available user preference criteria. It creates the entries in the RLC/URL Database mapping the RLC to one or more URLs. Bar Code Assignment and Management 46 is accessed by a publisher or content provider via HTTP Server 42 and a publisher's WWW Browser 45. The publisher requests a RLC to map to one or more of the publisher's WWW sites denoted by the URLs. The Bar Code Assignment and Management function enters the mapping in the RLC/URL Database 34 and returns a graphic representation of a bar code representing the RLC in a file such as an Encapsulated Postscript (.eps) or Tagged Image File Format (.tiff) file. The publisher then uses the graphic representation of the bar code in the publisher's printed materials. The publisher may also request that the URL have an associated expiration date after which the RLC/URL mapping will not be effective. The publisher requests the update of the RLC/URL Database 34 as required. The Publisher Registration function 48 handles the registration of a publisher as a participant in the system. It accepts registration information such as company name, address, administrative contact, and the like. The publisher interacts with the Publisher Registration function 48 through the publisher's WWW Browser 45 via HTTP Server 42. Information regarding the publisher and the publisher's business is stored in User Database 40. The Publisher Authentication function 50 provides security for subsequent attempts by the publisher to change information regarding the publisher's registration in the User Database 40. Before a publisher can modify the User Database, an authentication procedure must be carried out to ensure that the publisher requesting the change has proper authority to do so. Reporting Module 52 receives requests from publishers via HTTP Server 42 to generate activity reports from the Activity Log 44. Reports are compiled and forwarded to the requesting publisher after the publisher has been authenticated as discussed above. With the above-described components, the present invention provides the infrastructure for publishers to disseminate printed materials with bar codes signifying WWW resources, monitor the activity resulting from those printed materials, dynamically update the RLC/URL linkage, and receive reports which the publishers can use as part of a decision support system to further their business goals. FIG. 3 is a flow chart of the steps to initialize the WEBWAND system. During the startup or system initialization process of the Client System 10, a background task must be initiated to handle inputs for the WEBWAND system. After Start Step 100, WEBWAND 20 at Step 102 is launched as a Client application program as a background process or daemon that registers itself with the operating system of the Client to receive specific keyboard or serial port events (i.e., F12 or other special characters). Once this background task is executing, any specified keyboard or serial port event is reported by the operating system to this task so WEBWAND 20 can process the input data. System initialization processing related to WEBWAND ends at End step 104. FIG. 4 is a flow chart of the steps to initialize the WEBWAND 20 application on the Client System 10. This initialization sequence is started as a result of the user selecting WEBWAND as an application program on the Client to run by double-clicking the Client's mouse on the WEBWAND program icon, or by any other means well known in the art for commencing execution of an application program. After Start Step 110, the WEBWAND program at Step 112 is registered to receive a specific keyboard or serial port event if it has not already been registered during the system initialization processing described in FIG. 3. Next, at Step 114, the Client ID Data file 32 is read by WEBWAND 20 to obtain the Client ID of the user currently using the program and the identifier of the Client for purposes of communication with the Server System 12. Other user preference information such as desired language, presentation format, and the like, may also be read from the Client ID Data file. At Step 116, the WEBWAND application program waits for input from the user. Application initialization processing ends at End Step 118. FIG. 5 is a flow chart of the processing steps for the WEBWAND application on the Client System. After Start Step 150, the WEBWAND process 20 waits for user input from the Scanner 26 at Step 152. When the user swipes the Scanner across a bar code, the Scanner sends the scanned data through a specified serial port of the Client and the Client's operating system reports the event to WEBWAND 20. The data scanned may be included in the event notification or stored in a selected memory location by the Client's operating system for retrieval by the WEBWAND process. When a user input is received, WEBWAND processing continues with Step 154 by opening a communications channel with a selected Server System 12. Once a communications channel is open, the Client System 10 running WEBWAND is identified to the Server System 12 at Step 156. Next, at Step 158 a command packet requesting translation of a Resource Location Code (RLC)(which includes the scanned user input data) to a URL is built. The command packet is then sent to an available server at Step 160. A response packet is received from the server at Step 162. The response packet contains either a URL or an error indicator. If an error occurs, the command packet is sent to the next available server until a valid URL address is received or all available servers fail to return valid data (Step 164). The communications channel is closed at Step 166. The URL received in the response packet is sent to the WWW Browser 16 at Step 168. If the WWW Browser is not currently active in the Client, the WWW Browser is activated as an application process. The WWW Browser uses the URL to obtain the desired information. After WEBWAND passes the URL to the WWW Browser, processing continues with Step 152, wherein WEBWAND waits for the next user input from the Scanner. FIG. 6 is a flow chart of the processing steps for the Resolution Server 22 of FIG. 1. After Start Step 200, the Resolution Server starts a parent process to detect communication requests from clients on a specific input/output (I/O) port of Server 12 at Step 202. At Step 204, when the Resolution Server receives a command packet from a client, the Resolution Server spawns a new process to handle the command packet, or assigns the command packet to a running, available process. At Step 206, this child process executing on the Resolution Server validates the Client ID received in the command packet. It ensures that the Client ID is valid by checking the User Database 40. If the Client ID is valid at Test Step 208, then Yes path 210 is followed to Step 212. The Resolution Server then searches the RLC/URL Database 34 for the RLC included in the command packet. If the RLC is found in the RLC/URL Database (Test Step 212), then Yes path 214 is taken to Step 216. At this step the URL corresponding to the RLC from the command packet is obtained from the RLC/URL Database. At Step 218 the URL is inserted into a response packet intended for the client who sent the command packet. If the Client ID is not found to be valid at Test Step 208, then No path 220 is taken to Step 222. At Step 222 the URL of a client registration WWW site is returned in the response packet instead of the desired URL. Since the Client ID is not registered in the User Database 40 for the desired site, the user is directed to a registration site so the user can register the Client ID in a controlled manner. The User Database 40 is subsequently updated with the new client registration information. If the RLC is not found in the RLC/URL Database at Test Step 212, then No path 224 is taken to Step 226. At this step an error indicator is inserted into the response packet. Processing in all cases continues at Step 228, wherein the response packet is sent to the WEBWAND application in the Client System. After the response packet is sent, processing in the Resolution Server continues with Step 204 and the next received command packet. Communication between the Client System and the Server System in the present invention is accomplished according to a Web Wand Resolution Protocol (WWRP). The objective of the WWRP is to support the reliable and efficient translation of RLCs into URLs. The WWRP is independent of any particular transmission subsystem and requires only a reliable ordered data stream channel. An important feature of the WWRP is its capability to transfer lists of available servers to the Client System. This allows the Server System to provide updates to the services it provides in a manner similar to that of the Internet Domain Naming System. The WWRP design is based on the following model of communication. After receiving bar code data from the Scanner, WEBWAND 20 (sender) on the Client System 10 establishes a two-way communications channel with a Resolution Server 22 (receiver) on a Server System 12. WWRP commands are generated by WEBWAND as command packets and sent to the Resolution Server. WWRP replies are sent as response packets from the Resolution Server to WEBWAND. Commands and responses are composed of characters from the ASCII character set. WWRP command packets and response packets have a fixed syntax. Response packets include a numeric status code. In the preferred embodiment, command packets and response packets are not case sensitive. Generally, a command or response may be in upper case, lower case, or any combination of upper and lower case. However, the case of RLCs and Client IDs must be preserved. Initially, WEBWAND sends an OPEN command packet to open the communications channel (called a socket in the preferred embodiment) and to identify the sender of a request. If the Resolution Server can accept the request, it responds with a positive acknowledgment in an OPEN response packet. WEBWAND then sends a TRNS command packet identifying a RLC to translate. If the Resolution Server accepts this packet and successfully processes the RLC in the TRNS command packet, it responds with a URL as a positive acknowledgment in a TRNS response packet; otherwise it responds with a negative acknowledgment rejecting the RLC (but not the whole transaction). WEBWAND 20 initiates all messages between WEBWAND and the Resolution Server. Resolution Server 22 always responds with exactly one response packet for each command packet it receives. WEBWAND does not send another command packet until it receives a response packet from the Resolution Server in response to a previous command packet. Hence, the dialogue between WEBWAND and the Resolution Server is purposely lock-step, one command packet/response packet pair processed at a time for a given communications channel (socket). However, the Client System may establish multiple socket connections. All packets have a single "message command" token that identifies the packet's intended function. WEBWAND sets up this token as the first portion of all packets. The Resolution Server inserts a numeric status completion code immediately preceding a response token. WEBWAND may optionally append a list of parameters following the "message command" token in the command packet sent to the Resolution Server. Similarly, the Resolution Server may append a list of parameters following the numeric status code in the response packet sent to WEBWAND. All packets end with an "end of message" token after zero or more parameters. In the preferred embodiment of the present invention, a parameter consists of a "parameter identifier tag" and a "parameter data" token. The parameter identifier tag is a string of four characters. The parameter data is either a signed decimal number or a quoted string. A quoted string may contain any 8-bit value. Printable bytes are sent as ASCII codes, while non-printable bytes are sent as two hexadecimal characters preceded by a backslash character (e.g., "\0C"). This allows the communications system components of WEBWAND and the Resolution Server to provide for the transfer of arbitrary data as quoted strings. There must be exactly two hexadecimal characters following the backslash. The communications system components include procedures to handle all encoding and decoding of packets, thereby hiding these details from higher level processing of WEBWAND and the Resolution Server. Both message commands and the parameter identifier tags are single tokens of four bytes each. The tokens are case insensitive and are separated by delimiters including spaces, tabs, carriage returns, line feeds, and new lines. The quoted strings may contain both upper and lower case letters as well as other characters and binary information. Hence, case is preserved within quoted strings. In the preferred embodiment, no single packet can exceed 1023 bytes in length. This includes all separator characters, double quotes, and the end of message sequence. No single quoted string can contain more than 51 1 bytes of data, exclusive of the beginning and the ending double quote characters. All numbers sent as parameters, including client ID numbers, must be within the limits imposed by a 32-bit signed number. After establishing a socket connection, the socket may be kept open by both WEBWAND and the Resolution Server, or simultaneously closed at the end of a given packet. The message command in the packet determines whether the socket remains open or automatically closes. The socket may be opened, a single packet sent in each direction between WEBWAND and the Resolution Server, and then immediately closed. This enables the Resolution Server to unload unnecessarily open socket connections. FIG. 7 is a diagram of the message commands communicated in the command and response packets between WEBWAND and the Resolution Server. The message commands include Open Socket (OPEN) 300, Register User (REGU) 302, Servers (SVRS) 304, Translate (TRNS) 306, and Close Socket (CLOS) 308. The OPEN message 300 tells the Resolution Server to open a socket and leave it open for communication of subsequent commands. WEBWAND sends the Client ID to the Resolution Server and asks if the Client ID is valid. The Resolution Server responds with a status code of "OK" or "Invalid Client ID." This information is encoded in the numeric status code returned to WEBWAND in the OPEN response packet. The REGU message 302 is sent to the Resolution Server if the Invalid Client ID status is received. The REGU message asks the Resolution Server to register the current user's Client ID. The Client ID is also sent in this message. The Resolution Server responds with a Client ID number that the user should use for all further communications, and a quoted string that contains the URL of a customer registration HyperText Markup Language (HTML) forms document. WEBWAND stores the new Client ID in the Client ID Data file 32 and gives the customer registration URL to the WWW Browser 16. The user then uses the WWW Browser to register the Client ID with the User Database 40 through HTTP Server 42. The SVRS message 304 is sent to the Resolution Server to request a list of server Internet Protocol (IP) addresses that it should use. This message may be sent once during WEBWAND initialization, but may also be sent less frequently. The Resolution Server sends back a prioritized list of IP addresses in a single quoted string parameter. This string, when decoded back to a binary format, is a buffer with one or more null terminated ASCII strings. Each string is an individual IP address and the end of the buffer is indicated by the first zero length string (e.g., two "\0x00" in a row). Each of these strings are in a format that is acceptable to the standard C language sockets library. The TRNS message 306 is sent to request the Resolution Server to translate a Resource Link Code (RLC) into a Uniform Resource Locator (URL). The RLC is included in the command packet as a quoted string. The RLC is an exact copy of the data read from the Scanner 26, minus any unnecessary header and trailer information. The Resolution Server responds with a URL, in the form of a quoted string, in the TRNS response packet. The URL is then passed to the WWW Browser. The data within the quoted string includes all information required to completely specify the HTML document, including command line extensions for Common Gateway Interface (CGI) applications. The URL string is passed to the WWW Browser exactly as if the user had typed it (via the Client's keyboard) into the "Go to URL:" specification window in the browser. No assumption is made regarding the document currently displayed by the WWW Browser, thus there is no "base directory" for relative addressing as there are in embedded HTML links. The TRNS message can be sent without previously sending an OPEN message. If sent in this way, the socket connection is closed immediately after the Resolution Server sends the TRNS response packet. The Resolution Server manages the closing of the socket in the following manner. Upon socket initialization, a flag called "LEAVE OPEN" is set to false. After receiving an OPEN message, this flag is set to true. After receiving a CLOS message, this flag is set to false. After sending a response, the socket is closed if the LEAVE OPEN flag is false. The Resolution Server responds to TRNS command packets even if the LEAVE OPEN flag is false. Most command packets are of this type. The only packets sent to a socket immediately after opening are the OPEN and TRNS command packets. Other packets are sent only after an OPEN command packet. The CLOS message 308 is sent by WEBWAND to inform the Resolution Server that no further command packets will be sent through the open socket connection. No parameters are sent with a CLOS command packet. The Resolution Server acknowledges the CLOS command packet with an "OK" status in a CLOS response packet and closes the socket connection. Parameter identifier tags used in message commands for parameters include USID, RLCQ, URLQ, and SVRQ. Only one of each type of parameter is sent in any given packet. The USID parameter identifier tag denotes the Client ID number the Client is maintaining for the current user when this tag is sent by WEBWAND, or a new Client ID number (allocated by the Resolution Server) that WEBWAND should maintain from now on. The USID parameter is sent by both WEBWAND and the Resolution Server. The RLCQ parameter identifier tag denotes a quoted string containing an exact copy of the bar code data read by the Scanner. The RLCQ parameter is sent by WEBWAND. The URLQ parameter identifier tag denotes a quoted string containing the URL to give to the WWW Browser. The URLQ parameter is sent by the Resolution Server. The SVRQ parameter identifier tag denotes a quoted string containing a prioritized list of IP addresses. WEBWAND sends its current list of IP addresses that it uses to contact servers on the WWW. This list can be modified by the Resolution Server and returned to WEBWAND, where it is saved. The list is ordered by preference (i.e., the first server on the list is the first one tried when WEBWAND is invoked). The SVRQ parameter is sent by WEBWAND and the Resolution Server. Table I shows an example of a translation request and response between WEBWAND and the Resolution Server. TABLE I WEBWAND: TRNS 68723 "ar\02 Λ ET\0C." RESOLUTION SERVER: 100 "<http:\\ www.maui.com\something.html' ~ both sides close the socket connection — In the example of Table I, WEBWAND sends a TRNS command packet to the Resolution Server with a USID of 68723 and RLC data that was obtained from the Scanner. The Resolution Server responds with a response packet having a status code of 100 and the URL corresponding to the scanned bar code data. Table II shows an example of a client sign-on sequence. TABLE II WEBWAND: OPEN 68723. RESOLUTION SERVER: 100. WEBWAND: SVRS 68723 "199.4.33.17\00192.68.207.14\00maui.com\00\00" RESOLUTION SERVER: 100 "dancingbear.com\00199.4.33.17\00192.68.207.14\00\00** WEBWAND: CLOS. RESOLUTION SERVER: 100. — both sides close socket connection — In the example of Table II, WEBWAND opens up a socket connection with the Resolution Server by sending the OPEN command packet. The Resolution Server accepts the request and responds with a status code in a response packet. WEBWAND then sends a SVRS command packet containing a list of servers to the Resolution Server. The Resolution Server responds with an updated server list in a response packet. WEBWAND then sends a CLOS command packet and the Resolution Server responds with a response packet. Table III shows an example of a client sign-on sequence with a new client ID. TABLE III. WEBWAND: OPEN -3. RESOLUTION SERVER: 101. - status code flags bad client ID WEBWAND: REGU -3. RESOLUTION SERVER: 100 68723 "www.dancingbear.com\newuser.html" WEBWAND: CLOS. RESOLUTION SERVER: 100. — both sides close the socket connection -- ~ then later ~ WEBWAND: OPEN 68723. RESOLUTION SERVER: 100. WEBWAND: SVRS 68723 "199.4.33.17\00192.68.207.14\00maui.com\00\00" RESOLUTION SERVER: 100. -- server list is OK - WEBWAND: CLOS. RESOLUTION SERVER: 100. — both sides close the socket connection — In the example of Table III, WEBWAND begins by sending an OPEN command packet with an invalid client ID. The Resolution Server detects this error and sends back a bad status in a response packet. WEBWAND then sends a REGU command packet to register the new user. The Resolution Server responds by returning a new Client ID and a URL of a WWW page where the user can complete the registration process. WEBWAND sends a CLOS command packet to end this transaction and the Resolution Server replies with a response packet. At a later point in time, WEBWAND sends an OPEN command packet with the new Client ID in it. The Resolution Server validates this new Client ID and returns a good status in a response packet. WEBWAND sends list of servers for this Client ID to the Resolution Server in a SVRS command packet. The Resolution Server validates the server list and passes back a good status in a response packet. Finally, WEBWAND sends a CLOS command packet and the Resolution Server responds with a response packet. The invention has been described in its presently contemplated best mode, and it is clear that it is susceptible to various modifications, modes of operation and embodiments, all within the ability and skill of those skilled in the art and without the exercise of further inventive activity. Accordingly, what is intended to be protected by Letters Patent is set forth in the appended claims.

Claims: WHAT IS CLAIMED IS: 1. A system for obtaining a uniform resource locator addressing an information resource available on a World Wide Web portion of an Internet, the system including a bar code scanner for scanning a bar code printed on a printed material to produce bar code data, comprising: means for accepting bar code data, the bar code data identifying an information resource available on the World Wide Web, and for translating the bar code data into a uniform resource locator addressing the information resource. 2. The system of Claim 1 , wherein the uniform resource locator is in hypertext transport protocol (HTTP) format, and the information resource is a hypertext markup language (HTML) document. 3. The system of Claim 1, wherein the bar code is in Uniform Product Code (UPC) format. 4. A method for obtaining a uniform resource locator addressing an information resource available on a World Wide Web portion of an Internet comprising the steps of: scanning a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource available on the World Wide Web, the information resource being a hypertext markup language (HTML) document; and translating the bar code data into a uniform resource locator addressing the information resource. 5. A system for accessing an information resource over a World Wide Web portion of an Internet comprising: means for scanning a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource on the World Wide Web; means for translating the bar code data into a uniform resource locator of the information resource; and means for obtaining the information resource identified by the uniform resource locator. 6. The system of Claim 5 further comprising means (20) for sending the bar code data to the translating means and for receiving the uniform resource locator from the translating means. 7. The system of Claim 6 wherein the scanning means, the sending and receiving means, and the obtaining means are included in a first computer system, and the translating means is included in a second computer system, the first and second computer systems communicating with each other over the Intemet. 8. The system of Claim 7, wherein the first computer system is a personal computer (PC) system operated by a user and the second computer system is a server computer system translating bar code data into uniform resource locators for a plurality of users. 9. The system of Claim 7, wherein the obtaining means comprises a World Wide Web browser program executing on the first computer system. 10. The system of Claim 7, wherein the second computer system further comprises first storage means for storing correlations between bar code data and uniform resource locators. 11. The system of Claim 7, wherein the second computer system further comprises second storage means for storing information regarding requests by the first computer system for translation of bar code data into uniform resource locators. 12. The system of Claim 7, wherein the second computer system further comprises third storage means for storing information describing a plurality of users of the first computer system. 13. The system of Claim 7, wherein the first computer system further comprises at least one means for storing information identifying a selected one of a plurality of users of the first computer system and preference criteria for the selected user affecting translation of the bar code data into the uniform resource locator by the second computer system. 14. The system of Claim 9, wherein the sending and receiving means communicates the uniform resource locator to the World Wide Web browser program according to an inter- application communication standard. 15. A client/server system for accessing an information resource over a computer network comprising: client means coupled to the computer network for scanning a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource accessible over the computer network, for sending a command packet including the bar code data, and for receiving a response packet including a uniform resource locator of an information resource available on the computer network; server means coupled to the computer network for receiving the command packet, for translating the bar code data of the command packet into the uniform resource locator, and for sending the response packet including the uniform resource locator to the client means; and means for accessing the information resource identified by the uniform resource locator. 16. The client/server system of Claim 15, wherein the bar code is in Uniform Product Code (UPC) format. 17. The client/server system of Claim 15, wherein the client means processes scanned bar codes in a plurality of bar code formats. 18. The client/server system of Claim 15, wherein the computer network is an Internet and the uniform resource locator is in hypertext transport protocol (HTTP) format and identifies an address of the information resource available on a World Wide Web portion of the Internet. 19. The client/server system of Claim 18, wherein the information resource is a hypertext markup language (HTML) document. 20. The client/server system of Claim 19, wherein the accessing means is a World Wide Web browser program. 21. The client/server system of Claim 20, wherein the client means is an Internet appliance specially designed for browsing the World Wide Web of the Internet. 22. The client/server system of Claim 15, wherein the server means further comprises first storage means for storing correlations between bar code data and uniform resource locators. 23. The client/server system of Claim 15, wherein the server means further comprises second storage means for storing information regarding requests by the client means for translation of bar code data into uniform resource locators. 24. The client/server system of Claim 23, wherein the server means further comprises third storage means for storing information describing a plurality of users of the client means. 25. The client/server system of Claim 24, wherein the client means further comprises at least one means for storing information identifying a selected one of a plurality of users of the client means and preference criteria for the selected user affecting translation of the bar code data into the uniform resource locator by the server means. 26. The client/server system of Claim 25, wherein the preference criteria includes demographic information describing the selected user. 27. The client/server system of Claim 25, wherein the identifying information and the preference criteria are included in the command packet. 28. The client server system of Claim 25, wherein the preference criteria comprises a list of a plurality of server means. 29. The client/server system of Claim 24, wherein identification of the selected user in the command packet and the selected user's preference criteria from the third storage means affect translation of the bar code data into a uniform resource locator. 30. The client/server system of Claim 24, wherein the server means further comprises means for assigning and managing bar codes for a plurality of publishers of information on printed materials. 31. The client/server system of Claim 30, wherein the server means further comprises means for registering publishers. 32. The client/server system of Claim 31 , wherein the server means further comprises means for authenticating access to the second or third storage means by a publisher. 33. The client/server system of Claim 32, wherein the server means further comprises means for reporting results of user activity in requesting translations of bar code data into uniform resource locators to a selected one of the publishers. 34. The client/server system of Claim 33 wherein the server means further comprises means for receiving publisher requests for accessing the reporting means, the publisher registration means, the publisher authentication means and the bar code assigning and managing means. 35. In a client server system for accessing an information resource over an Internet, the client server system including a client system coupled to the Internet to scan a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource accessible over the Internet, to send a command packet including the bar code data, and to receive a response packet including a uniform resource locator of an information resource on the Internet, a server system comprising: server means coupled to the Internet for receiving the command packet including bar code data, for translating the bar code data into the uniform resource locator, and for sending the response packet including the uniform resource locator to the client system. 36. The server system of Claim 35, wherein the server means further comprises first storage means for storing correlations between bar code data and uniform resource locators. 37. The server system of Claim 36, wherein the server means further comprises second storage means for storing information regarding requests by the client system for translation of bar code data into uniform resource locators. 38. The server system of Claim 37, wherein the server means further comprises third storage means for storing information describing a plurality of users of the client system. 39. The client/server system of Claim 38, wherein the server means further comprises means for assigning and managing bar codes for a plurality of publishers of information on printed materials. 40. The client/server system of Claim 39, wherein the server means further comprises means for registering publishers. 41. The client/server system of Claim 40, wherein the server means further comprises means for authenticating access to the second or third storage means by a publisher. 42. The client/server system of Claim 41 , wherein the server means further comprises means for reporting results of user activity in requesting translations of bar code data into uniform resource locators to a selected one of the publishers. 43. The client/server system of Claim 42 wherein the server means further comprises means for receiving publisher requests for accessing the reporting means, the publisher registration means, the publisher authentication means and the bar code assigning and managing means. 44. In a client server system for accessing an information resource over an Internet, the client/server system including a client system coupled to the Internet to scan a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource accessible over the Internet, to send a command packet including the bar code data, and to receive a response packet including a uniform resource locator of an information resource on the Internet, a method of operating a server system coupled to the Internet comprising the steps of: receiving a command packet including bar code data from a client system; translating the bar code data into a uniform resource locator identifying an information resource accessible over the Internet; and sending a response packet including the uniform resource locator to the client system. 45. The method of Claim 44, wherein the translation step comprises the steps of: validating an identifier of a client system included in the command packet; setting the uniform resource locator in the response packet to address a client system registration information resource when the identifier is invalid; and obtaining the uniform resource locator corresponding to the bar code data and inserting the uniform resource locator into the response packet when the identifier is valid. 46. The method of Claim 44, further comprising the steps of: assigning a bar code to a selected uniform resource locator; and storing the assignment of the bar code to the selected uniform resource locator. 47. The method of Claim 44, further comprising the step of storing information regarding requests by the client system for translation of bar code data into uniform resource locators. 48. A method of accessing an information resource over a World Wide Web portion of an Internet comprising the steps of: scanning a bar code printed on a printed material to produce bar code data, the bar code identifying an information resource on the World Wide Web; forwarding the bar code data to a client computer system; sending the bar code data in a command packet to a server computer system over the Internet by the client computer system; translating the bar code data into a uniform resource locator of the information resource by the server computer system; sending the uniform resource locator in a response packet from the server computer system to the client computer system; forwarding the uniform resource locator to a World Wide Web browser program executing on the client computer system; and obtaining the information resource identified by the uniform resource locator. 49. The method of Claim 48, wherein the uniform resource locator is in hypertext transport protocol (HTTP) format and the information resource is a hypertext markup language (HTML) document.

Inventors: GRISWOLD BRIAN J, GRISWOLD TIMOTHY J, KRAFTSOW ANDREW P, GRISWOLD, BRIAN, J., GRISWOLD, TIMOTHY, J., KRAFTSOW, ANDREW, P.
Applicants: ERNESTINE LLC, GRISWOLD BRIAN J, GRISWOLD TIMOTHY J, KRAFTSOW ANDREW P, ERNESTINE, LLC, GRISWOLD, BRIAN, J., GRISWOLD, TIMOTHY, J., KRAFTSOW, ANDREW, P.
Application year: 1997
Main classification: G06F15
IPC codes: G06F17, G09B5, H04L29