HUP0000799A2 - Kiosk and server connected to computer network - Google Patents

Abstract

The server (195) includes at least one configuration set associated with an application and has one or more files and at least one embedded control function capable of selecting a driver subset of one or more of the driver programs at a kiosk (100) . A device (130) communicates with the driver subset at a kiosk to cause the driver programs to control the device subset of one or more of the local kiosk functions to configure the kiosk to perform the application. The request comes from a kiosk to be configured or from an agent computer. The configuration set includes any one of the following: a remote device control, a remote message display, a file transfer, and an agent/client collaboration. The embedded control function includes a system monitoring program which determines the operating status of one or more of the local kiosk functions of a kiosk.

Description

Mr. 00007 ⁹³

68,688/KÖT

S.B.G. & K.

International

Patent Office

H-1062 Budapest, Andrássy Street 113.

Phone: 34-24-950, Pax: 34-24-323

PUBLICATION.

COPY

Kiosk and server connected to a computer network

The invention relates to a kiosk and a server connected to a computer network. The kiosks are configured by the server.

A kiosk is typically a machine located at a location that is generally accessible to users or customers, such as in a public place, so that a service provider can provide a service to those users and/or customers. These services are typically self-service, meaning that the customer performs them without assistance from a service provider employee. These services are therefore repetitive, simple, and specific services, such as 1) accessing information, and/or 2) performing certain simple transactions (such as purchasing a ticket, withdrawing cash, viewing a store floor map, etc.).

The tasks to be performed must be pre-programmed, pre-defined, and the tasks must be self-service. Therefore, kiosks are not designed to be flexible and do not provide personalized assistance to a specific user.

These transactions involve the use of some equipment. Such equipment may include one or more monitors, a card reader, a ticket printer, a laser printer, a cash dispenser, etc. These equipment are typically designed to perform predefined tasks that are inflexibly designed for the kiosk, and therefore these equipment cannot be used for any other purpose.

The advantages of kiosks are convenience and reliability. Kiosks do not require full-time operators to perform tasks, which saves operating costs and increases productivity.

Some well-known kiosks, such as bank ATMs (automatic teller machines), airline ticket machines, etc., are networked. There are also stand-alone kiosks, such as information kiosks on shopping streets.

Video conferencing kiosks are known for banking applications that aim to establish a connection between a bank employee and a user or customer. To this end, a video conferencing system is simply added to a traditional type of kiosk.

Kiosks combined with the Internet are also known. This kiosk has a browser that displays HTML pages on the kiosk screen. The screen displayed in the kiosk is controlled by hyperlinks selected by the user. These kiosks are suitable for accessing information in such a way that the customer or user can browse the information provided by selecting "soft buttons" that call up a hyperlink. These kiosks can also be used for certain personal communications, such as e-mail. In these systems, the screens are usually specially designed to form a user interface (for example, with navigation buttons, etc.

- 3 are provided), and the kiosk acts as a filter, limiting the URL (universal resource locator) that can be accessed by the client so that only HTML pages (URL) specified by the kiosk builder can be accessed.

Most known kiosks are inflexible. They cannot be easily, cheaply, and quickly modified or reconfigured because their programming is typically designed and developed for a single purpose (usually in ^{a high-level computer programming language such as C or C++ )} and installed in the kiosk for a specific application. Any changes would require recoding, redeployment, reinstallation, and retesting of the program. This would typically be done by the kiosk manufacturer. Existing kiosks are difficult to modify, especially when there are many kiosks that need to be updated.

Known kiosks cannot implement effective "personal service" applications, that is, applications that require an employee to consult with and/or direct the customer or user to complete a service or transaction. An effective "personal service" environment for a customer requires not only video and audio, but also synchronized screen sharing (e.g., the customer or user sees data as the employee enters data) and remote control of the equipment (e.g., the employee can print a receipt for the kiosk user or customer). Known systems do not provide synchronized screen sharing or remote control of the kiosk equipment.

In some well-known kiosks, the user can get help from an employee over the phone, but the employee usually cannot directly see the kiosk screen. Therefore, if problems arise at the kiosk, the employee can only assume that the user describes them. The employee cannot directly see the kiosk screen to solve the problems. In addition, the employee cannot change the kiosk program or operation from a remote location to determine the problem at the kiosk. It is worth mentioning that in some kiosks, in banking applications, employees are given a picture of the contents of the kiosk screen. However, this content is displayed by a separate application running on the employee's workstation, and not by the application that displays the contents of the screen at the kiosk.

Some known solutions include video conferencing as a feature of the kiosk. Although video conferencing provides the customer with audio and video connectivity to other participants, this architecture has not been successful in the marketplace because it lacks coherent integration between the audio and video connectivity and the content on the kiosk screen. If the customer has a problem with an input on the kiosk screen, the employee does not have the same information on their screen as the customer does at the kiosk. For example, if a field on the kiosk screen has an ambiguous or incorrect value, the employee does not see this incorrect value in the video conferencing environment.

- 5 in. The employee also cannot point to specific locations on the customer's screen or control the customer's screen. In addition, the employee cannot provide general information to the customer at the kiosk unless the kiosk is pre-programmed to provide it. Another example: if the customer needs information that is not available at the kiosk, the employee can only provide the information via voice and video camera, but cannot provide any information on the customer's kiosk screen or through other kiosk equipment.

Some simple Internet browser-based kiosks are also described, which are only suitable for limited and specific applications, i.e. limited information browsing. These kiosks are not able to provide an efficient service environment with flexible applications for the customer, because the kiosk has no control capabilities and there is no cooperation between the customer and the employee.

The object of our invention is to overcome the above-described shortcomings and disadvantages of kiosks and to this end, to develop a flexible, reconfigurable and interoperable kiosk architecture that provides the public with ubiquitous, configurable and directly accessible network interfaces for a range of applications, including "personal relationship-based service and/or transactions" between an employee and a customer, and also enables public access to multiple communication networks, such as the Internet (TCP/IP), the public telephone network, the integrated services digital network (ISDN), etc. The

- 6 network server systems can thus provide a very large number of applications - potentially created, developed and stored on one or more network servers - for reconfiguring remote kiosks and kiosk devices in the network(s) in different ways for different applications, primarily to support a wide variety of input and output devices used for different applications in different ways.

This task is solved according to the invention with respect to a server, which is used to reconfigure an electronic kiosk comprising one or more input and output peripheral units and corresponding drivers in a network, in that the server comprises:

means for connecting to the network, means for providing at least one configuration set comprising one or more files defining an application to be implemented in a kiosk and at least one embedded control function capable of selecting a subset of drivers for a kiosk, means for receiving a configuration request for a kiosk connected to the network, and means for delivering the at least one configuration set to the kiosk over the network in response to the configuration request, whereby the subset of drivers controls the associated subset of peripherals, thereby configuring the kiosk to execute the application.

The problem is solved according to the invention with respect to the electronic kiosk in that it comprises:

- 7 means for connecting to the network, means for obtaining from a server over the network at least one configuration set comprising one or more files defining an application to be implemented in the kiosk and an embedded control function, and means for selecting a subset of drivers for executing the embedded control function and for communicating with the subset to control the associated peripherals, and this means for configuring the kiosk to execute the application associated with the configuration set.

In one preferred embodiment, a kiosk system can be connected to one or more networks, such as the Internet, organizational intranets, or government intranets, etc. The kiosk has one or more input and output devices (e.g., displays, keyboards, paper printers, telephones, etc.) and one or more drivers (local API = local application programming interface) for each input and output device. The displays are used to provide one or more graphical user interfaces and video images to a person using the kiosk. Some interfaces are application-specific. (Application refers to the use for which the kiosk is configured or reconfigured). The kiosk has a browser that retrieves one or more application files (in a configuration set) from one or more servers in the network. The application files (configuration set) contain a group of HTML files that the kiosk browser displays in an order determined by the application.

- 8 meg. One or more HTML files contain embedded (control) programs that are used to control the local application programming interface of one or more devices in the kiosk. One or more files may also contain other HTML files, multimedia components (images or sounds) and/or hyperlinks to other HTML files, multimedia components, embedded programs and/or other application files. The first application file is selected from the server(s) by a selection function (e.g., sound, soft button, hyperlink, etc.) in the kiosk. The application files (configuration set) associated with the selection (selection function) configure the kiosk accordingly. Kiosks can thus be configured and reconfigured to perform different applications defined by the application files.

In some preferred embodiments, one or more application files have one or more predefined selection links (e.g., hyperlinks). When the browser presents or interprets (e.g., file-by-file) the application files, the predefined selection links are displayed to the user as additional selections in the graphical user interface. The user may select one or more selections using one or more selection functions to select and retrieve one or more configuration sets, HTML files, etc., containing zero or more embedded control programs. Therefore, the order in which the browser presents the contents of the HTML files, and indeed the files in the order, is changed by using these additional selections.

- 9 can be configured to reconfigure the kiosk in various ways, to receive information from the user and/or to provide information to the user. The presentation of the HTML files in sequence configures the kiosk to produce one or more screen sequences of interactive screens and, if necessary, sequences of device activities (controlled by the embedded programs), which in combination reconfigure the kiosk for the specific application selected. In these embodiments, the user (or other function within the kiosk or server) can reconfigure the kiosk for other applications by selecting a different selection function in the kiosk.

In some preferred embodiments, a portion of the application includes a Web page sharing feature that allows an employee and a customer to collaborate over the network via the kiosk and server. One preferred embodiment includes a "thin client" architecture, meaning there is no application-specific software in the kiosk.

Our invention is described in connection with exemplary embodiments thereof with the help of our drawings, of which the

Figure 1 is a block diagram of a preferred embodiment of a kiosk, the

Figure 2 is a block diagram of another preferred embodiment of a kiosk, the

Figure 3. Block diagram of an example graphical user interface used in the kiosk, the

Figure 4 is a block diagram of a configuration set (application files) selected by a user and executed to configure the kiosk,

Figure 5 is a block diagram of a set of application files (configuration set) that includes one or more HTML files and associated hypertext components containing at least one embedded program, the

Figure 6 is a block diagram showing a preferred embodiment of a kiosk executing application files and control programs or functions that interact with local application programming interface programs to configure the kiosk, the

Figures 6A-6D are block diagrams of alternative preferred embodiments of kiosk control mechanisms,

Figure 7 is a flowchart showing the steps of executing an application file using the control functions of the application programming interface,

Figure 8 is a flowchart of the steps performed in a typical server,

Figure 9. Block diagram of a preferred kiosk software architecture using ActiveX,

Figures 9A-9D are block diagrams of various preferred embodiments of kiosk control mechanisms using ActiveX,

Figure 10 is a block diagram of another embodiment of kiosk control using plug heads.

Figure 1 is a block diagram of a preferred embodiment of a kiosk 100. The kiosk 100 includes a computer 110.

-II (e.g., an IBM personal computer, PC350 or PC750) having a suitable, known network interface 155. The network 150 may be any known local area network (LAN) or wide area network (WAN). In the preferred embodiment, the network 150 is the Internet. Other general networks 150 may be used, including intranets (organizational networks), government networks, educational networks, extranet networks between organizations, and networks used by one or more retailers, which may be implemented using telephone networks, cable networks, ISDN networks, etc. The computer 110 may have one or more input and/or output units 130 (below) mounted as part of the kiosk 100. The computer 110 typically has one or more main memory, one or more storage memories 110M (e.g., hard disk drives, CD ROMs, etc.), and one or more HOC central processing units. These are well known. The computer 110 also has an optional hardware keyboard 135 and a mouse 134, for example, for maintenance purposes. The user accesses various input and/or output devices 130 to transfer information to and from other clients and/or servers 195 connected to the network 150 through the computer 110 and the network 150. Such input and/or output units 130 include, for example, a touch-sensitive terminal 103 with a screen 105, a printer 109, any known general data reader 111 (e.g., a card reader 121 for reading magnetic cards, credit cards, or smart cards), a scanner 112 (e.g., a laser beam reader), any known general data writer 113 (e.g., a printer, ticket printer, media printer, such as a floppy drive, order printer, or receipt printer), an issuing device (e.g., for issuing stickers or computer disks), or any other input and/or output unit 130 that provides the user with information on a touchable medium 113A. Additional input and/or output units 130 are any one or more of the following: a banknote dispenser, a scanner, an insertion device, a pen input 136, a card issuing device, a ticket issuing device, a cathode ray tube, a keyboard, a touch screen, a programmable camera, one or more presence sensors (e.g., infrared), one or more lamps, a CD ROM player, an audio input-output unit (e.g., a microphone 133, a speaker 132, or a telephone 107), and a memory 113B. The kiosk 100 may be equipped with known communication devices, such as a telephone 107 or a video conferencing system 114, such as a PictureTel PCS-100 Desktop ISDN video conferencing system. (PictureTel is a trademark of PictureTel). The video conferencing system includes 131 camera(s), 133 microphone(s) and one or more I3DN connections or separate network connections via suitable network interfaces 155. Connections can be made to other networks 151, such as the plain old telephone service (POTS) telephone network 122 via the telephone set 107, the loudspeaker 132, the microphone 133 and/or the ISDN line 123. Other input and/or output units 130 can also be connected directly to the network 150, 151 using known interfaces.

-13The computer's HOC executes software programs, including control processes and libraries 125, and in some preferred embodiments, one or more cooperating processes 170. The control processes 125 consist of two parts: one or more embedded control functions and programs 620, and one or more control mechanisms 640 (see FIGS. 5 and 6-6D below). The embedded control functions and programs 620 include [?] specific processes (e.g., for banking, car rental, shopping, etc.) that use the non-included specific control mechanisms 640 to control local application programming interfaces 680 associated with the corresponding input and/or output units 130 (or subsets thereof). Therefore, the input and/or output units 130 are controlled in a specific manner consistent with the content of the application. In other embodiments, the control mechanisms may be dynamically loaded into the computer 110 from the network 150 .

The collaboration process 170 includes application programming interfaces and other programs that implement the functions that create the collaboration process from the kiosk 100. This collaboration process is described in U.S. Patent Application Serial No. 08/722,287, entitled "Internet Web Page Sharing," published September 27, 1996, to Fin et al., which is incorporated herein by reference in its entirety (see EP 97307536.0, European Patent Application Publication No. 833260). The computer further executes programs necessary for interacting with the network 150,

-14including a 160 Web browser program, such as a Netscape Navigator browser. (Netscape Navigator is a trademark of Netscape Communications Corporation).

Figure 2 is a block diagram of another embodiment of the invention in which the kiosk—in this case, kiosk 200—is located in an enclosed space or partially enclosed space. The enclosed space may be any type of space, such as a room, a cubicle, or any other private or semi-private area in which the kiosk and one or more users are located. In this embodiment, the computer 110 is connected to one or more known input and/or output devices 130, such that the computer 110 controls the creation of an environment for the user in the kiosk 200. The input and/or output units L 30 may include lighting 205 for illuminating the space, displays 210 in the kiosk 200 that add and/or remove additional information (e.g., sales information) and/or environmental factors (e.g., a changing display of a visual image or scenery or a virtual world) to and from the kiosk 200 and/or security access 215. In addition, the (partially) enclosed space may include other input and/or output units 130 similar to the input and/or output units 130 described above, such as audio, video conferencing, etc. Examples of virtual worlds are well known.

In the preferred embodiment of the systems (kiosks 100 and 200), the user selects (using a selection function) an application, such as a banking transaction, for which the kiosk is to be configured, and the browser 160 accesses the Internet 150.

-15 (in a public network) interacts with one or more Web servers 195 to retrieve one or more configuration sets 175. Optionally, data communication is initiated between the server 195 and the browser 160 in the kiosk 100, 200. The browser 160 then executes the configuration sets 175 file by file (.application files) to

L) optionally call driver programs (680 local application programming interfaces) that control one or more 130 input and/or output devices (e.g., 103 touch-sensitive terminals or displays) used in the corresponding application,

2) optionally cause a series of actions of input and/or output units 130, for example when a series of Web pages are to be displayed on the touch-sensitive terminal or display 103,

3) optionally establish communication from the user input to the server 195, and

4) optionally select additional application files (configuration sets 175) that the browser 160 will further execute depending on user input.

The user can thus use a first selection function to select a first application (and associated application files (configuration sets) 175 on the server 195 ) which reconfigure the kiosk for a first selected specific application. When a second application is selected, the kiosk is again reconfigured for the second application, and so on. The selection functions can be used for any subsequent

-16 can be specified for the user in a previous configuration.

An application is any use for which a kiosk is configured. Examples of applications include uses (configurations) in the following areas: finance, business, information (news, advertising), communications (e-mail, Web access, video conferencing), retail, marketing, services (e.g., government programs). An application owner is any person, organization, or company that configures the kiosk to enable the application. For example, a bank or mutual fund configures the kiosk for one or more financial applications. Examples of such financial applications include providing the user with financial information, opening an account, dispensing cash, paying with banknotes, requesting a loan, placing deposits, and providing assistance to the employee. An example of a service provider is a car rental company that configures the kiosk to rent and/or lease cars.

In further preferred embodiments, the kiosk is not reconfigured by the user, but by the server 195. For example, the kiosk is located in a public location, such as a shopping street. The browser may be configured to initially or periodically retrieve the configuration set 175 (application files) for the kiosk 100 from one or more servers 195 or from a base server or proxy server 195A located in the network 150. Therefore, a system designer may control the configuration of the kiosk from a remote location from the server 195. For example, a kiosk located in a shopping street may first be configured to display

-17leniti a map of the shopping street, plays background music, provides announcements or weather reports, or other general information, such as news or stock quotes. The configuration set 175 may further direct one or more input and/or output units 130 to have a selection function 105A or to be the selection function itself, such as a touch-sensitive screen, a hypertext link, a soft button on a graphical user interface, a hard-wired button, a remote sensor (similar to a radio frequency identification tag), or a voice-activated message for a video conferencing system. The selection function 105A is a function that allows the user to make a selection that reconfigures the kiosk for a user application. These L05A selection functions allow the user to reconfigure the kiosk 100, 200 and/or access other information that the kiosk may provide in response to the server 195.

The selection features 105A and/or other displayed information may also be a source of revenue for the kiosk owner and/or operator. The communication delivered by the kiosk may also be paid advertising. Application providers (e.g., banks, mutual funds, mortgage companies, money lenders, agents [brokers, real estate agents], rental companies [car or equipment rental companies], and retailers) may pay a fee to have a selection feature 105A on the kiosk 100, 200 that the user can select to configure the kiosk for that application. The fee may be determined by the location of the kiosk, the location of the selection feature, and the information.

-18te, or its placement on the kiosk (e.g., graphical user interface), the size of the selection function 105A, the time and duration when, or for how long, the kiosk provides the selection function 105A, or information, etc. The selection function 105A, or information, may be varied at different times or displayed periodically to target different groups of consumers and customers. For example, a kiosk at Grand Central Station in New York City may display information to commuters during rush hour and may be reconfigured to have selection functions 105A for restaurant reservations just before lunchtime.

The kiosk 100, 200 can be reconfigured by the application provider via the server 195 to be user-specific. For example, a travel agency would need a user profile for Mr. Smith. Mr. Smith selects a selection function 105A at the kiosk 100, 200 in a public location or at his workplace. When the kiosk is reconfigured for the travel agency application, the kiosk (controlled by one of the configuration sets (application files) 175) can prompt Mr. Smith to provide personal information, such as by entering a PIN or swiping a credit card, using one of the input and/or output units 130. The personal information about Mr. Smith is transmitted by the kiosk 100, 200 to the server 195, and Mr. Smith's profile can be accessed. Using the information in the profile, the server 195 sends one or more configuration sets (application files) 175 to reconfigure the kiosk specifically for Mr. Smith. A possible example is

-19J. ^: J· dául, that the kiosk only has travel packages to Central America. In other embodiments, one or more configuration sets 175 (application files) may allow the user to organize the graphical user interface (see below for graphical user interface 300).

In other preferred embodiments of the kiosk 100, 200, a collaborative program flow is established between one or more kiosk users and one or more employees of the application provider. The collaboration is established by the collaborative process 170, which is resident in the kiosk or provided by the server 195 as a configuration set (application file) 175 (see the above-referenced patent application to Fin et al.).

In a further preferred arrangement of the kiosk 100, 200, the server 195 provides the kiosk with 175 configuration sets (application files) that are used to monitor or maintain the kiosk. In these embodiments, for example, one or more embedded control functions and programs 620 monitor the operational status of one or more input and/or output units 130, such as using "dead man timer status, error checking protocols, etc. to determine which input and/or output units are operational. This information is returned to the server 95. Other configuration sets 175 (application files) are used to query which input and/or output units 130 are installed or operational in a particular kiosk. In this manner, the server 95 can determine what other configuration sets 175 (application files) need to be sent to the kiosk to

-20: : :.:. . ·.

·«« ·«« · ** installed or functional input and/or output units 130 are enabled, and non-installed or defective units are not enabled. Therefore, kiosks containing any general combination of input and/or output units 130 can be installed remotely from the server, and the server provides the correct and functional application files to make the kiosk functional for each given application. The application files can also be used to obtain information from one or more input and/or output units to determine how to operate those units.

In Figure 3, an exemplary graphical user interface 300 is shown on the screen or display 105 of a kiosk 100, 200. The graphical user interface 300 provides the kiosk user with the main access interface via the selection function L05A. The selection function 105A is, for example, the icons 301+304: a bank icon 301, an insurance company icon 302, a general soft button 303, and a pizza restaurant icon 304. The graphical user interface 300 can also display the selection functions 105A in the form of a menu 320 with one or more selections (typically selections 325). Further examples of the selection functions 105A are hyperlinks 350, which may be part of the graphical user interface 300 and/or the menu 320. Other information fields 340 of the graphical user interface 300 may be used to enter information and/or other data. Using these information fields 340, the graphical user interface 300 may be displayed in the form of a form 370, such as a tax return, loan application, mortgage application, or deposit form.

-21stb. in the form. The 300 graphical user interface can be displayed as a Web page by the 160 browser using well-known techniques. The Web page may have multimedia (audio, video) parts that the user can access through other 130 input and/or output units.

Figure 4 illustrates the mechanism whereby the user interacts with the user interface to select a selection function L05A, which causes the appropriate configuration set 175 (application file1) to be downloaded from the server 95 to the client (kiosk 100, 200) to perform certain specific functions and control a specific subset 451 of the input and/or output units 130 (e.g., telephone set 107, printer 109, data reader 111, data writer 113, video conferencing system 114, etc.). The input and/or output units 130 are controlled through their local application programming interfaces 440 (or a subset 441 of these local application programming interfaces 440). The local application programming interfaces 440 are software functional interfaces that directly control one or more input and/or output units 130. For example, in a card reader, the local application programming interfaces 440 may include initialization, startup, data read (from card), card eject, and power off functions.

The kiosk configuration is selected using the selection function 105A. For example, the selection function 105A includes:

J. J. H- J·

a) A user firmly taps an on-screen icon or other selection device, such as a button.

b) The currently executing program determines the need to invoke a selection based on the user's behavior, for example, it invokes a help program if the user makes the same mistake more than twice in a row.

c) The logic in the currently executing program determines the next selection (kiosk configuration). For example, if the user completes the mortgage application prequalification and the bank approves it, the running application might ask the user if they need real estate information. If the answer is yes, the kiosk configuration changes to a real estate application.

In one embodiment, when performing a selection function 105A, the browser 160 sends a request to the server 195 in HTTP via the network interface 155 for the first 175 configuration set (application type) (500 application file) corresponding to the selection function 105A. (See also FIG. 5, where the 500 application files in the configuration set (application file) 175 are described.) The server 195 then passes the configuration set (application file) 175 to the browser 160. When a file 500 arrives at the browser 160, the HTML content of the application file 500 is executed line by line. If the next 500 application files are related (e.g., hyperlinked) to the application files 500 of the current application being executed by the browser, then these next 500 files are also passed to the browser. In this way, the browser 160

4 4 ··· 4

JJ ^; r <· executes each 500 application file line by line, from configuration set 175 to configuration set 175 in the order specified by the instructions in the HTML text in the configuration set 175. By executing the 500 application files in the configuration set 175 (application files) in this manner, the local application programming interfaces 440, or subsets 441 of the local application programming interfaces, assigned to the input and/or output unit 130, are invoked to control the selected subset 451 of the units, and the kiosk 100, 200 is reconfigured. Note that logic in each of the 175 application files or 500 application files and/or user actions may change which of the 175 application files or 500 application files are executed and which are not, or some are not executed.

By executing the configuration sets (application files) 175, the browser 160 selects and controls one or more input and/or output units 130. The kiosk configuration is determined by the units (e.g., subset of units 451) specified during execution of the application files, and how the subset of units 451 is controlled. For example, in the case of a banking transaction configuration, execution of the configuration set (application files) 175 invokes a subset of application programming interfaces 441, i.e., selects and controls the data reader 111 (card reader) and the printer 109 (subset of units 451) to read the bank card and print the transaction receipt. In the same banking transaction

-24Λ ^; ύ <· configuration, one or more configuration sets (application files) 175 (and/or lines in application files) do not select and control an input and/or output unit 130, but rather cause other activities, including storing data, returning data or a message to the server 195, etc. In another configuration, when ordering a pizza, execution of the application files calls another subset 441 of the application programming interfaces to select and control the same subset 45 1 of units (i.e., the data reader 111 and the printer 109) to read and charge a credit card, and to print a receipt indicating the type of pizza selected.

Note that in some configurations, execution of the configuration set (application file) 175 does not select one or more of the input and/or output devices 130. In these cases, the default devices are used. For example, a line in the application file 500 that causes a line of text to be displayed is directed to the touch terminal 103 by default.

It is further noted that the browser 160 may have access to a special group of locally executable modules that use other local programs and/or libraries to interact with the execution of application files (see FIG. 6 ).

Figure 5 is a block diagram of 175 configuration sets (application files) that include one or more HTML 500 application files and associated hypertext components,

-There is at least one embedded 620 control program within 25 thousand.

Each Web-based 175 configuration set (application file) is formed by HTML-based files with at least one embedded control program 620. The configuration set (application file) 175 optionally includes other hypertext components, which may or may not be HTML-based. A typical HTML file includes standard HTML tags (such as HTML 3.0) for text 525, images or graphics 528, animation, audio, video, and other embedded programs 520. (Animation is implemented as images 528, widgets 505, scripts 515, or other embedded programs 520; audio and video are implemented as an embedded program 520). These tags are well known. In one preferred embodiment, the browser 160 is Netscape Navigator v3.0. Embedded programs can be implemented using JavaScript and/or a Java utility and/or any other embedded program that uses plug-ins (Java is a trademark of Sun Microsystems Inc.). The HTML application file 500, as shown in Figure 5, uses tags 505 to embed a Java utility, tags 515 to embed JavaScript functions, and tags 520 to embed any other program that calls the browser plug-in functions. More information on standard HTML tags can be found in the Netscape HTML 3.0 Source Book, which is incorporated by reference into this patent application. Some of these embedded programs 520 include embedded control functions and programs 620.

In Figure 5, the symbolic identification lines are shown with common English name designations for better illustration.

-26• · · · · • · «···· · * * · · ·« · *·

FIG. 6 is a block diagram illustrating the components of the system involved in executing the functions and programs of the embedded controller 620 of a typical application configuring a kiosk 100.

Functionally, browsers 160 include a parser 610 that parses or recognizes HTML tags in HTML files. The parser 610 invokes an HTML tag execution unit 611 for each HTML tag to perform functions depending on the tag type and the tag content. If the execution does not invoke an application programming interface 680 call to local kiosk programs (including peripheral local application programming interfaces 440), the browser uses a library of standard functions 617 to perform control functions 615 for each HTML tag as needed. Such non-application programming interface 615 control functions include text display, image display, etc. These are well known and are included in prior art browsers.

However, if the HTML tag execution unit 611 finds an embedded control function and program 620 that calls one of the kiosk's local application programming interfaces 680, the HTML tag execution unit 611 calls a security manager 625 within the browser 160 to determine whether the application programming interface call is permitted. As will be described in more detail later, a kiosk control mechanism 640, or a portion of that mechanism 640A, is located in a subdirectory of the directory in which the browser is located. In this way, the security manager 625 finds the kiosk control 640

-27 mechanism (mechanism part 640A) when the HTML tag execution unit 611 encounters the embedded control function and program 620, and an application programming interface control function 621 loads the kiosk control mechanism 640 and the mechanism part 640A into the browser process 160. These embedded control functions and programs 620 may include, for example, utility applications that may call one or more local application programming interfaces 680 and 440 (i.e., the selected subsets 44L) to operate the particular subset 451 of the units. For example, if the unit is a card reader, the embedded control function and program 620 may use the kiosk control mechanism 640 to call the appropriate local application programming interfaces 440 to open the card reader unit, read data from the card, eject the card, and close the card reader unit.

It is noted that the known browsers 160 do not execute the embedded 620 control functions and programs from the network 150 to execute the local application programming interfaces 680. These browsers specifically prevent the execution of the control functions of these application programming interfaces for known network security reasons. For example, if the configuration set 175 (application file) changes while traveling over the network, the corrupted control function in the application file may cause unpredictable and harmful results at the client machine, i.e., the kiosks 100, 200.

It is well known that Java is designed to support various special tools, bytecode transfer and authentication, virtual

-28• · · · « ·*· «*· **t* ’ft * machine error checking, etc. solves network security problems. In addition, when Java is used as a helper application in a Web-based application, that is, embedded in HTML files, the browser usually strictly prevents the Java helper application from accessing any local Java programs on the client machine, except those in the standard Java library that is built into the browser. The reason for this is simply to prevent any possible damage that the helper application may cause to the client machine, since the helper application comes from an uncontrolled environment, that is, it can come from any server on the network.

As the book “Java Now” (Kris Jamsa, Jamsa Press, 1996, ISBN 1-884133-30-4, P. 4) states, “to address security issues, Java developers had to ensure that a programmer could not develop a computer virus using a Java utility, and that a utility could not transmit information about the user’s system (such as a file on the user’s system) back to the server. For example, you would not want to be browsing your competitor’s Web site while their Java utility was browsing your hard drive. To achieve this security, the Java developer decided to limit what the utility could do. For example, a Java utility could not read or write files on the user’s system. Thus, a utility could not store viruses on the user’s disk or read information stored on the user’s disk. It also states that “Java is

-29allows programmers to create stand-alone programs. Stand-alone Java programs are similar to the programs that programmers can create using . Such stand-alone programs can read and write files and perform operations that Java restricts to helper applications. A Java helper application, however, runs only within a browser.... This means that Java helpers are not designed to run programs outside of the .160 browser process.

During standard browser operation, the browser's security manager 625 monitors for any violations of these security rules. If it is determined that a helper application is requesting access to a program within the non-standard Java library, the browser reports a simple security violation error and stops execution of the helper application.

In one embodiment, mechanism parts 640A of the specific kiosk control mechanism 640 are added to the browser 160, and other mechanism parts 640B of the specific kiosk control mechanism 640 are added to the local application programming interfaces 680 (including the local application programming interfaces 440) to allow the configuration set (application file) 175 to configure the kiosk. Accordingly, the specific kiosk control mechanism 640 is divided into two parts, a browser mechanism part 640A and an application programming interface mechanism part 640B. In this embodiment, the browser mechanism part 640A and the application programming interface mechanism part 640B communicate with each other via an interprocess communication (IPC) 6401. Interprocess communication 6401 allows the browser mechanism portion 640A and the application programming interface mechanism portion 640B to communicate by sending messages instead of direct function calls. (Interprocess communications are well known, one example of their application is the use of dynamic data exchange (DDE) in the Windows operating system. Windows is a trademark of Microsoft Corporation).

The browser mechanism part 640A is located in the browser subdirectory so that the interpreter program 610 in the browser 160 recognizes any API control function and program in any configuration set (application file) 175. The API mechanism part 640B receives messages from the browser mechanism part 640A and independently controls various functions, including the local API of the unit 440, in accordance with the message. In this way, the helper application is authorized by the browser to control one or more units and local functions, but only those that have a browser mechanism part 640A. Therefore, the multiple functions in the kiosk are still secured against being accessed by the configuration set (application files) 175 over the network. Furthermore, since the API mechanism portion 640B operates the local API of the unit 440 independently of the browser, each unit control function (a subset of the API control function and program 620 used to control a particular unit) implemented through the kiosk control mechanism of the API 640 is a subset of the units 451.

-31 is executed even if the application file in the browser 160 is later terminated or changed. This allows the unit to be managed in a persistent manner, i.e., when a local application programming interface function 640, 440 is initialized, the function can be completed regardless of whether or not the configuration set (application file) 175 has been changed or terminated by the browser 160. This persistence of execution also allows some of the user's interactions with the kiosk to be more efficient. For example, a configuration set (application file) L75 may direct a card issuing device to issue a new card. The user or browser may then proceed to another application file while the card issuing device writes data to the magnetic stripes and embosses the new card.

The browser mechanism portions 640A are 1) located in the browser's own standard library, and 2) have a structure that allows a configuration set 175 (application file) to invoke one or more local application programming interfaces 680, either by passing a message using a name server mechanism that passes messages (e.g., function name and associated parameters) to one or more local application programming interfaces (see FIGS. 6A and 6C and explanation), or by directly invoking the local application programming interfaces (see FIGS. 6B and 6D and explanation).

In one preferred embodiment, the browser mechanism portions 640A include a Java application programming interface.

-32 (sometimes called a "Java wrapper"), which is known by the application file 500 and contains functions programmed in a native language (such as C ⁺⁺ ) for communication (such as interprocess communication or using name servers) or for direct calls to the local application programming interfaces 680.

The mechanism portion of the application programming interface 640B 1) directly accesses various local function modules (e.g., browser control modules, collaboration function modules, unit control modules, and system management modules, etc.); 2) has a structure that can call a group of one or more local application programming interfaces 680 either by using a name server mechanism or by directly calling the associated local function module; 3) has an interprocess communication that allows message-based communication with the mechanism portion of the application programming interface 640A. (Note that the functions of the local application programming interfaces 680 are specifically designed to control each particular unit or function in the kiosk and may or may not be accessible by the configuration set (application files) 175).

One application of this kiosk control mechanism is to query the system installation and status before the application decides how to configure the kiosk. A CallAPI. class utility can be used in the 175 configuration set (application file) to "query status".

-33pot 640 to call the API function. For example:

Public class CallAPI extend applet implement Runnable { a = new kioskAppInterface (); (640A) a .send_APImessage(„query status); (640A) a .get_APImessage(„status, sysStatus); (640A) and this helper app is embedded in the HTML file as <HTML> (175, 500) <body>

<applet name=API src=CallAPI.class... >

</applet>

</body>

</HTML>.

When the browser executes this helper application, it first implements a class called kioskAppInterface. This file and related dynamic link libraries (DLLs) are stored in the browser's standard library. The browser then uses a kioskAppInterface class method called send_APImessage() to send a "query status (640A) application programming interface (API) message. The method calls an interprocess communication function 6401 to send a message to a

-34 of the application programming interface mechanism portion 640B. The application programming interface mechanism portion 640B then calls the associated local application programming interface function 680 to obtain system status data and returns the data to the mechanism portion 640B via an interprocess communication function 6401. The helper application uses the get_APImessage() method containing the “status” command to obtain data returned from the kiosk control mechanism 640 and stores the data within a class called sysStatus.

The API message passed between mechanism parts 640A and 640B may include a name server function mechanism (see Figure 6A below). Generally, when mechanism part 640B receives a message, the name server function (the

640B) parses the message and calls the appropriate local API function 680. In this example, a system supervisor calls an API function to obtain system status information, which can be represented as follows:

In the mechanism part 640B in the name-server function, if ( Func)_Name == “query status) data = system_supervisor_get_status();

send_message(data); (6401) } else if (Func_Name == “read card) (680, 690)

-35Here is an example of the data received in the data structure of the aforementioned "sysStatus class:

number of units = 5 laser printer = OK card reader = OK card issuer = no card supply receipt printer = OK ticket printer = OK.

This message indicates that there are five units in the kiosk and all are working except the card issuer, which needs cards.

According to the current state data of the kiosk, the configuration sets (application files) 175 may choose to use the laser printer, the receipt printer, and the card reader (subset of units 451), but must avoid using the card issuer because, according to the state data, there are no cards in the card issuer (in such circumstances, the card can be produced by another device and mailed to the kiosk user.

In some preferred embodiments, similar methods are used to determine what units are in the kiosk and whether or not those units are functioning properly. In this manner, the server can provide specific 175 configuration sets (application files) to the kiosk based on what units are in the kiosk and/or whether those units are functional. Therefore, any number of different kiosk layouts and/or operating situations can be configured by selecting the application files appropriately at the server.

-36a for the appropriate application configuration. For example, in a banking application, application files containing laser printer control (500 application files) are sent to kiosks equipped with laser printers for printing high-quality bank statements, while application files containing receipt printer control (500 application files) are sent to kiosks equipped with only (available and functional) receipt printers for the same task (bank statements). In this way, kiosks with faulty Laser Printers or less expensive kiosks without Laser Printers can be configured appropriately for a banking application.

In other embodiments, one or more servers may request status information via requests sent in application files. This information may be used to determine whether the kiosks and/or the units therein require service. For example, a service worker may be dispatched to insert cards into a card issuing device if necessary.

In other embodiments, status information may be requested for use in kiosk and/or unit service history. Other market information may also be obtained, such as which configuration is most frequently used by a particular class of users in a given location.

In one preferred embodiment, the kiosk may have a browser window (a system administrator application window) that runs in the background of all other applications. This system administrator application window may contain one or more HTML files that are one or more helper applications that communicate with one or more servers.

-37 contains (or contains). (The mechanism for the Java helper to communicate with the server is well known). This system monitoring application window can be started at any time when the kiosk is powered on and runs as long as the kiosk is powered on. In this way, one or more servers can obtain information about the kiosk's system status at any time by communicating with the helper(s).

The described solution opens up the following possibilities, among others:

1) Thin client kiosk: Since the kiosk does not require application-specific software to be pre-installed, the kiosk is inexpensive to build and maintain. Therefore, one application (500 application files) can be written on a server and used by a large number of thin kiosks in a network connected to the server. No application-specific software needs to be designed for any of the thin kiosks in the network. The network can be composed of one or more standard (and therefore cheaper) thin kiosks, and no application-specific software is needed at all. (For example, a kiosk manufacturer can produce one or more standard kiosks that can be used for each application and independently of the application.) The 500 application files can be developed, upgraded and/or maintained on the server and used to reconfigure one or more kiosks without having to change any programming in these kiosks. This thin client kiosk allows for the mass deployment of kiosks to be used for these kiosks. the public has public access anytime and anywhere

-38hessen. An example of this is a “kiosk phone” that can communicate over the Internet and/or the telephone network.

2) A large number and variety of applications can be developed at the server and released through this kiosk, since the kiosk is reconfigurable. Therefore, application providers can share any kiosk in the network. These applications can be provided at the kiosk at specific times and/or for specific situations, for example, at the request of a user, or under any given environmental conditions (for example, an umbrella shop advertises when it is raining).

3) The applicability of the information-rich, multi-media and technology-rich benefits of the Internet and the World Wide Web, as kiosks can be based on the open standard technology of the Internet and the Web.

Below are some non-limiting examples of how a user may use these 100 kiosks.

1. The kiosk screen dynamically displays different images, video clips, audio, graphic patterns, and text during idle time. The content of the screen is entirely driven by HTML file(s), and the HTML file(s) are updated either at the request of the kiosk or by the server. Service providers can charge different prices for different types of screen “real estate” and the time they are displayed. During the morning and evening peak hours, the main focus may be on major news and financial market developments, while during lunchtime, there may be many restaurant advertisements, and on weekends, there may be department store sales advertisements. The content is designed to keep people who pass by touching the screen.

2. The user sees the screen, walks up to it, and taps it. [<goes directly to the next screen, which shows icons and. text indicating the application categories.

3. The user taps the pizza order icon. A screen appears from which the user can select a pizza type. The screen asks the user where and when the pizza should be delivered, and the user can enter this information using the touch-sensitive keyboard on the screen. The control function and program 620 embedded in the HTML captures the data. The screen then prompts the user to insert their credit card to authorize the charge. The control program opens the card reader and captures the information on the credit card. The control program can then use the functions of the kiosk's associated application programming interface to invoke the communication function in the kiosk to access the credit card company (e.g., via a modem) and the pizza shop (e.g., by sending a fax). After performing these functions, the screen verifies the order information to the consumer. Other general retail transactions can be performed similarly.

4. The user can also tap a phone icon to make a phone call. The phone application HTML file appears on the screen with the phone keypad. After the user enters the phone number, the embedded control program calls the mechanism portion of the associated API function 640A to initiate the phone call, which is based on the kiosk's network connection (122 telephone network, 123 ISDN line, 150

-40 network), depending on the application file 500 and the user's selection function 105A, it may be a traditional telephone call over the public telephone network, or over an integrated services digital network (ISDN), or over an Internet-based telephone. Once the connection is established, the user may use a mobile telephone or a hands-free telephone provided with the kiosk equipment (see Hortensius et al., U.S. Patent Application Serial No. 08/595,897, published February 6, 1996, which is identical to European Patent Application Serial No. 789,470, and is hereby incorporated by reference in its entirety).

In other preferred embodiments, the user may choose to have a video phone call, or even a video conference call, with a shared application if the other end has the same capability. The control function and program 620 embedded in the HTML application then invokes the mechanism portion 640A of the associated application programming interface function to initiate the video conference function of the kiosk. The user may use the touch screen and stylus provided in the kiosk to facilitate the conversation (referring to the aforementioned patent application of Fin et al. entitled "Internet Web Page Sharing").

5. The user can select a fax function. The screen prompts the user to enter their fax number, insert their credit card, place the document to be faxed in the appropriate unit (such as the document slot), and when ready, press

-41 screen, the OK button. When the button is touched, the embedded control function and program 620 calls the mechanism portion of the corresponding unit control application programming interface 640A to operate the scanner, read the document, return the document, and send the document electronically over a network, such as the public telephone network or the Internet.

6. The user can select the e-mail function. The screen shows the HTML application associated with the e-mail. The embedded control function and program 620 can call the mechanism part 640A of the associated application programming interface function, or can communicate directly with the mail server and directory server through the browser to identify the user, search for existing e-mail messages, or send new messages.

7. The user may select the selection function 105A to transfer an electronic file to a storage medium, such as a floppy disk. The screen may prompt the user to perform certain actions, such as inserting the floppy into a slot. The embedded control function and program 620 calls the mechanism portion 640A of the associated application programming interface function to read the floppy and read or write the file or files that the user selects, and then transfer them as instructed by the user, such as sending them to someone's email address.

8. The user can select one of several service providers (e.g., application-owned service providers on the server), such as a lawyer, doctor, certified public accountant, real estate agent, rental agent, investment advisor, insurance agent

-42agent etc. The screen shows the corresponding application in HTML files that provide the desired services. (Based on the user's selection, this service can be provided in any natural language, such as English, Spanish, Chinese, Japanese, French, Italian etc.).

9. Depending on the provider's application, a real-time collaborative program flow can also be initiated with video, audio, split-screen, and remote control functions (see the above-referenced patent application of Fin et al.). The embedded program calls the control functions and programs of the associated application programming interface 620 for video, audio, and data communication.

10. The user can select an information search. The screen asks the user what information they need. The embedded control program takes the data and sends a query depending on the type of information. The queries can be sent over the Internet, using well-known search engine algorithms, databases on application servers, and databases on other network servers.

11. The user may choose to receive personalized application services. For example, if the user is already identified (e.g., by accessing information on a magnetic stripe or smart card), the application files provide personalized information and/or kiosk configuration for the user.

12. The user may also select configurations of the kiosk 100 that are not originally present in the kiosk. In interaction with the initial configuration of the kiosk, references to other configuration sets (application files) 175 are reconfigured.

-43guration the kiosk to a second configuration. For example, the first configuration may provide a user input (icon or hyperlink) that accesses the second configuration's 175 configuration set (application files).

13. The user may be one or more students or learners who have access to one or more kiosks connected to a network where the server “teacher 175” provides configuration sets (application files).

14. Users can select "electronic products" at the kiosk. For example, compact discs (CDs) containing music, video, computer software, and/or other multimedia information can be dispensed from a suitable dispensing device. Alternatively, blank media (e.g., tape, floppy disk, recordable CD, etc.) can be written to by suitable devices at the kiosk to create any "electronic information" that can be transferred to the user in a non-touchable form over the network. For example, the latest opera recording can be transferred to a CD without having to ship a factory-cut CD to a store.

In further examples, we will show some 640 kiosk control mechanisms that can receive input information from and output information to kiosk devices. In a typical input situation, the application file 500 may have an embedded utility called CallAPI.class that is used to invoke the 640 "hardkey input" API function. For example:

-44- ·· · . .

• · ♦ · · · * ·*

Public class CallAPI extend applet implement Runnable { a = new kioskAppInterface (); (640A) while (InputData. lastchar != RETURN) । ( a . send_APImessage („hardkey_input) ; (640A) a .get_APImessage(„input, InputData); (640A) (e.g. keyboard input at a suitable location on the screen)

I í while (InputData. lastchar != RETURN)

I i a . send_APImessage (,,sof tkey_input ) ; (64 OA) a .get_APImessage(„input, InputData); (640A) (e.g. key input at a suitable location on the screen) ) a .send_APImessage(„LaserPrint, FileName); (640A) } and this helper is embedded in the HTML file as <HTML> (500) <body>

<applet name=API src=CallAPI. class. . . >

</applet>

</body>

</HTML>

-45When the browser executes this helper application, it first implements a class called kioskAppInterface. This file and related dynamic link libraries (DLLs) are stored in the browser's standard library. The browser then uses a kioskAppInterface class method called send_APImessage() to send a “hardkey input (640A)” application programming interface (API) message. The method calls an interprocess communication function 6401 to send a message to an API mechanism portion 640B. The API mechanism portion 640B then calls the associated local API function 680 to take the key input(s) from the hardware key provided to the kiosk and returns the data to the mechanism portion 6400 via an interprocess communication function 6401. The helper application uses the “get_APImessage()” method containing the “input command” to receive data that is returned from the kiosk control mechanism 640 and stores the data in a data structure within a class called InputData.

In the name server function, 640B else if (Func_Name == “hardkey_input) J data = get_hardkey_input(); (680, 690) send_message(data); (6401) else if (Func_Name == “softkey_input)

-46data = get_softkey_input(); (680, 690) send_message(data); (6401)

I else if (Func_Name == “LaserPrint) I I

Laserjprint(FileName); (680, 690)

I I

Note that if the application files 500 have embedded utilities that "call for softkey input," similar API messages will be passed between mechanism portion 640A and mechanism portion 640B, and various local API functions 680 will be used to cause a softkey window to "pop up" on the screen and capture user input. The local API functions 680 for these softkey inputs are well known.

Similarly, if the application files 500 have embedded utilities that call for printing a file on an output device, such as a laser printer, then the above code will direct the local application programming interface function Laser_print(FileName) 680, which will control the laser printer to print the file "FileName."

Figure 6A shows an embodiment of a kiosk control mechanism 640 that uses an interprocess communication 6401 and a name server function (mechanism portion 640B). In this

-In the case of the 175,500 application files, a small, fixed set of general communication API functions (mechanism part 640A) is used (mainly for transferring messages). These communication API functions communicate or transfer messages between mechanism part 640A and mechanism part 640B. The message is executed by the name server function, which is in mechanism part 640B. The name server function (mechanism part 640B) also serves as an interprocess communication server 6401. The name server function recognizes a variety of predefined messages. For example, in one embodiment, the set of communication API functions has two functions: send_message(message) and get_message(message). There are, however, more "messages." The name server function in mechanism section 640B has a register containing all such predefined messages, and each predefined message is associated with a logic group that can call the appropriate local application programming interface functions 680 to execute the appropriate predefined message.

In this embodiment, new units and/or new functions performed by these units can be added by specifying new predefined message(s) and the logic necessary to perform the new functions. In this way, the application files 175, 500 can perform these new functions simply by using the new message identifier in the given communication API function. This typically involves only changes to the "ASCII or "text message identifier g *>»41 · ** in the application file 500. There is no need to code and compile new embedded program(s) or modify existing program(s) to use the new functions. Therefore, the application owner (and therefore the application files 175 on the server(s)) only needs to do a little to perform the new functions, since the kiosk provider has built the necessary logic into the name server (in mechanism part 640B).

6B. .Ibra is a block diagram of another embodiment of the kiosk control mechanism 640 that uses interprocess communication 6401 to map local application programming interfaces in the browser mechanism portion 640A. In this case, many or all of the kiosk control functions and programs 620 are implemented by directly calling the appropriate mapping local application programming interfaces in the browser mechanism portion 640A from the application file 500. Each mapping local application programming interface mechanism portion 640A communicates with the application programming interface mechanism portion 640B through the process! communication, which in turn calls the appropriate local application programming interfaces 680. Here, the mapping local application programming interfaces mechanism portions 640A are Java application programming interface programs. There is a Java program that is specifically written for one or more local application programming interfaces 680. Unlike the name server case, at least one Java application programming interface program must contain logic to control one or more 680 local application programming interfaces. These Java application programs

-49 interface programs are predefined and are known by the 500 application files.

In this embodiment, new units and/or new functions performed by these units can be added by creating new mapping local application programming interfaces (640A) in the browser mechanism parts 640A with their corresponding application programming interface parts 640B. In this embodiment, the application files 500 must perform all such functions in direct calls. Therefore, some or all of the logic for performing the new function must be defined in the application files 500. The application programmer must code this logic, for example, when designing the application files 500 on the server, by writing a new Java utility.

Figure 6C shows another embodiment of the kiosk control mechanism 640. In this embodiment, there is no interprocess communication 6401, and therefore the API mechanism portion 640B is merged into the browser mechanism portion 640A. The name server functionality, which is also merged, is still used and is combined with the set of communication APIs to form the browser mechanism (640B, 640). In this embodiment, the persistence is lost because once the application file 500 containing the auxiliary application is “dropped” by the browser (no more execution), the local API function 680 is terminated. This embodiment is useful when persistence is not required,

-50for example, where none of the kiosk units are included except for the browser-controlled screen.

6D shows another embodiment of the kiosk control mechanism 640. In this embodiment, there is no interprocess communication and no API mechanism portion 640B at all. Here, the utility directly calls the API function (640, 640A), which directly calls the local API function 680. Here, the API function is a Java API program. There is a Java API program that is specifically written for one or more local APIs 680. Unlike the name server case, at least one Java API program must contain logic to control one or more local APIs 680. These Java API programs are predefined and known by the application file 500. In this embodiment, the permanence is also lost.

Figure 7 illustrates the execution process 700 performed by the kiosk.

In step 705, the browser 160 receives a file (HTML) 500 from the application files 175. Then, in step 710, the browser interprets the tags and content of the application file 500. If, in step 715, the browser does not find a local API call, then, in step 720, the browser executes the tags with the associated known actions. If, in step 715, the browser finds a local API call, then

In step 725, the browser invokes the associated application programming interface function (640 or 640A).

In one preferred embodiment, in step 730, the browser mechanism part 640A communicates messages with the mechanism part 640B via interprocess communication 6401. In another embodiment, a message server is used as described above. In step 735, the mechanism part 640B receives the message and invokes associated local application programming interfaces 680. Then, in step 740, the mechanism part 640B communicates messages with the browser mechanism part 640A via interprocess communication 6401 regarding the results of the execution of the local functions.

Step 750 controls the browser to request the next HTML file by screen input, embedded controller logic, or external browser control function 660. The browser can thus be treated as a local unit of the kiosk. Therefore, the browser can be controlled to load any specific HTML ^file from one or more servers over the network, accessing known browser interfaces 681 using a local external browser control function 660. The external browser control function 660 (local application programming interface) is designed (see above) to allow embedded controller functions and programs 620 to access the browser interfaces 681.

Figure 8 illustrates a server process 800 executed on one or more servers in a network. In step 810, the server receives a request from one or more kiosks over the network. The request identifies which configuration set 175 (application file) the kiosk is selecting and accessing.

-52The request also includes the location of the kiosk 100 requesting or accessing the application files. Upon receipt of the request, the server sends the requested application file(s) 175 to the kiosk in step 820. The application file(s) 175 may be pre-prepared or dynamically generated by logic on the server.

In other embodiments, the kiosk sends the request to a proxy server 195A in step 810. The proxy server 195A is typically located closer to the kiosk than the server 195. Alternatively, the proxy server 195A may be located on a computer 110 in the kiosk 100, 200. For example, the server L95 may be located in a first city, such as the headquarters, while the proxy server L95A is located on a local area network (LAN) connected to the kiosk(s) in another city. The proxy server 195A may send the request to the server 150 over the network for many or all of the configuration sets (application files) 175 that the kiosk may need on a predetermined schedule. In this way, the kiosk can access the application files on the 195 server more quickly and reliably when the application files are needed. In addition, the 195A proxy server can request the application files from the 195 server during off-peak network hours.

In other embodiments, the server (195, 195A) may be used to “push” information to one or more kiosks identified by the server 195. For example, in step 810, the server 195 initiates the request. There may be various reasons for this initiation. For example, updating an application may require one or more kiosks to be reconfigured to

-53new with 175 configuration sets (application files). Alternatively, a new configuration may be required at a certain time each day, i.e. at 5:00 PM each day the news is provided from a different source. The server may also initiate periodic checks of the kiosks to determine which kiosks require maintenance.

One preferred implementation of this embodiment utilizes a server push function 685 operating in the kiosk. The server push function 685 is connected to the network 150 and can receive messages from the server 195. The server push function 685 also has access to the browser interfaces 681. The server 195 sends a request to the server push function 685, which causes the browser to request specific application files 500 from the server 195.

Figure 9 is a block diagram showing the mechanism in which the embedded control program uses ActiveX technology instead of Java. An ActiveX control object can be implemented using different programming languages, such as Visual ^Basic or Java. The ActiveX object can be embedded in an HTML file. For example:

<HTML>

<BODY>

<OBJECT

ID = "MyObject"

CLASS ID=CLSID:8E27C92B-1264-10IC-8A2F-040224009C02>

-54<PARAM NAME “Version VALUE=458752>

</OBJECT>

</BODY>

</HTML>

In this case, the browser must be ActiveX-enabled, i.e. it must support ActiveX technology. In one preferred embodiment, the browser is Microsoft Internet Explorer.

When the application file 500 arrives at the browser 160, step 910 parses the HTML file based on its tags and content. As in the Java case discussed above, in step 920 the browser executes the non-API control function as before. In step 930 the API control functions executed by the browser directly invoke the APIs 940. As in the Java case, the first portion of APIs 940A communicates with the second portion of APIs 940B (e.g., 640B) via an interprocess communication function 9401 (e.g., 6401), which invokes the local API functions 680.

The difference between ActiveX and the previous Java case is that ActiveX can contain an object written in a non-network language, such as C ⁺⁺ or Visual Basic. An object written in these languages is downloaded to the browser in executable code. Therefore, such an object can do everything that a local program written in the same language can do, but it does not have the security restrictions of a Java helper application. so if you have an embedded 620 control

-55function and program is written as an ActiveX control using the non-Java language, then the 940 application programming interface function can be placed anywhere in the kiosk. If Java is used in the ActiveX object, the mechanisms discussed earlier must still be used.

In Figures 9A-9D, the boxes with the numbers discussed above have the functions described above.

9A shows an embodiment of an application programming interface (kiosk control mechanism) 940 using interprocess communication and name server functionality. The first part of the browser 940A is a native language application programming interface that does not need to be located in the browser directory, but can be located anywhere in the kiosk memory, such as the kiosk system directory. However, the application file 500 must be aware of the browser mechanism (first part) 940A.

Figure 9B is a block diagram of another embodiment of an application programming interface (kiosk control mechanism) 940 that uses interprocess communication and name server functionality 6401 to map local application programming interfaces. As in Figure 6B , there is at least one application programming interface (browser mechanism) 940 for one or more local application programming interfaces 680.

Figure 9C shows a further embodiment of the application programming interface (kiosk control mechanism) 940 without interprocess communication 6401. Here, the browser mechanism 940A can be positioned as in Figure 9A.

-56A Figure 9D shows another embodiment of the kiosk control mechanism that uses an ActiveX control when the control is not implemented in Java. In this embodiment, no API 940 is required at all, because such an embedded ActiveX control can directly call the local API 680. In this case, the persistence of execution is lost.

Figure 10 shows a further version of the kiosk control mechanism using the so-called plug-in technique. In this case, the preferred embodiment uses a Netscape Navigator v3.0 or higher 160 browser.

Here, the control mechanism 1040 includes a browser mechanism L040A (plug-in module and associated Java wrapper) that is accessed by the control functions and programs 620 in the application file 175, 500. When accessed, the browser mechanism 1040A is executed as part of the browser 160. The executing browser mechanism 1040A, in turn, invokes an interprocess communication function 10401. The interprocess communication function 10401 may be the same as the interprocess communications 6401, 9401 described above. The interprocess communication 10401, in turn, communicates with the application programming interface mechanisms 1040B to invoke the local application programming interfaces 680. The API mechanisms 1040B may be the same as the second parts 640B, 940B described above.

In this embodiment, the browser mechanism 1040A is implemented using a plug-in technique (see Zan Oliphanr,

-57Sams.net Publishing, 1996, ISBN 1-57521-098-3). The plug-in technique uses a native code module, i.e. implemented in C or similar programming languages, and in a preferred embodiment also uses a Java wrapper. The browser mechanisms 1040A (plug-ins) are located in a special plug-in library defined by the browser 160. When the HTML parser 610 encounters the embedded file (control function and program 620) that identifies the corresponding plug-in module (browser mechanism 1040A) in the embedded file, also called a Multipurpose Internet Mail Extension (MIME) type, by a single filename extension, the plug-in module (browser mechanism 1040A) is dynamically loaded into the browser 160.

The embedded kiosk control program (620) may be 1) a Javascript function, 2) a Java utility, and/or 3) a predefined set of control scripts contained in a single (MIME) file with a single extension.

When the browser 160 loads the plug-in module (browser mechanism 1040A), the plug-in module (browser mechanism 1040A) is available to the HTML document, i.e. the plug-in functions become available to the embedded programs (620) for calling, for example, a JavaScript function or Java utility. This allows the kiosk 680 local application programming interfaces to be controlled by any given embedded 620 control function and program through one or more corresponding plug-in modules (browser mechanism 1040A). In other words, the plug-in module (browser mechanism 1040A) will call the interprocess communication function 10401 to call the kiosk 680 local application programming interface through the corresponding application programming interface mechanism 1040B.

Three non-limiting examples are described below.

Example 1 uses JavaScript functionality as an embedded kiosk control program 1030 with a plug-in module (browser mechanism 1040A) that performs a message passing function.

The configuration set 175 (application file) with the control program 1030 is as follows:

<HTML>

<HEAD>

etc.

</HEAD>

<BODY> <APPLET NAME- "MYAPPLET SRC-"MYAPPLET. CLASS> etc.

<EMBED NAME=MYEMBED SRC=MASGPASS.MET>

<SCRIPT LANGUAGE^JAVASCRIPT etc.

MYAPPLET.PluginAPI_SendMsg("CARDREADER_ON);

etc.

<\SCRIPT>

etc.

<\BODY>

<\HTML>.

The Java utility application "MYAPPLET.Java" will contain code like this:

-59import PluginWrapper etc.

PluginAPI = new PluginWrapper(); etc.

public PluginAPI_SendMsg(String msg) { etc .

PluginAPI.SendMsg(msg);

etc.

I J

The Java wrapper file, PluginWrapper.java, will contain the following code:

import netscape . plugin. Plugins;

etc.

public class PluginWrapper implements Plugin { etc .

public native void SendMsg(String msg); etc.

I J

The plug-in module (browser mechanism 1040A) associated with the embedded control program 1030 provides the SendMsg() method, which is implemented, for example, in native language code, such as C ⁺⁺ .

Example 2 uses a Java utility application as a directly embedded kiosk control program 1030 with a plug-in module (browser mechanism 1040A) that performs a message passing function.

-60Α 175 configuration set (application file) with the 1030 control program is as follows:

<HTML>

<HEAD> etc.

</HEAD>

<BODY>

<EMBED NAME=MYEMBED SRC=MASGPASS.MET>

<APPLET NAME = “MYAPPLET SRC=“MYAPPLET.CLASS> etc.

<\BODY>

<\HTML>.

The Java utility application "MYAPPLET.Java" contains this code:

import PluginWrapper etc.

PluginAPI = new PluginWrapper ();

PluginAPI.SendMsg(msg) { etc .

PluginAPI . SendMsg (.msg) ;

etc.

I)

The PluginWrapper. Java Java wrapper file may contain the following code:

import netscape . plugin.Plugin;

• « · · · · ·

-61- ’· ··· *·« · ·· public class PluginWrapper implements Plugin { etc. ..........

public native void SendMsg(String msg); etc.

I I

As in Example 1, the plug-in module (browser mechanism 1040A) associated with the above embedded control program 1030 provides the SendMsgO method, which is implemented in, for example, native language code, such as C++.

Example 3 uses an embedded control program 1030 containing a set of predefined control scripts and a corresponding plug-in module (browser mechanism 1040A) that interprets and executes the scripts to control the local application programming interfaces of the kiosk 630.

The application file 175 with the embedded control program 1030 may be as follows:

<HTML>

<HEAD> etc.

</HEAD>

<BODY>

<EMBED NAME=MYEMBED SRC=MASGPASS.MET> etc .

<\BODY>

-62A plug-in module (1040A browser mechanism) may contain the following code:

NPError NP_LOADS NPP_NEW (MPMIMEType pluginType,

NPP plnstance, uintlő mode, int 16 argo, char ¹ argn, char* argv,

NPŐavedData* saved) I I

LE (plnstance == NULL) return NPERR_INVALID_INSTANCE_ERROR;

KioskIPC* pKiosklPC = new KioskIPC (plnstance);

plnstance->pdata = pKiosklPC;

pKioskiPC->mode = mode;

return NPERROR_NO_ERROR; I I

NPERROR NP_LOADS NPP-Destroy (NPP plnstance, NPSavedData*save) I l

KioskIPC* pKiosklPC = (KioskIPC *)plnstance->pdata;

If (pKiosklPC) delete pKiosklPC;

pnstance->pdata = NULL;

return NPERROR NO ERROR;

VOID NP_LOADDS NPP_StreamAsFile (NPP plnstance,

MPStream* stream, const char* fname) Í I

KioskIPC* pKioskIPC = (KioskIPC *)plnstance->pdata;

if (pKioskIPC) pKioskPC->InterpretFile(fname);

I ♦

All three pluggable functions shown above implement the standard pluggable APIs provided by the Netscape 160 browser. Other pluggable APIs provided by the 160 browser are not used here.

If the <embed> tag is interpreted by the HTML parser 610, the control program 1030, MSGPASS.MET, is downloaded to the local disk, and the corresponding plug-in module (browser mechanism 1040A) is loaded into the browser 160, if it is not already loaded. The browser 160 automatically calls the plug-in API NPP_New() to create a plug-in instance, and calls the plug-in API NPPStreamAsFile( ) with the downloaded file name to execute the file. If necessary, the browser 160 calls the plug-in NPP_Destroy() to destroy the plug-in instance.

The KioskIPC class and the InterpretFile() function can be implemented using a native language, such as C ⁺⁺ , to interpret and execute a predefined script contained in an embedded file. In this sense, there is no restriction that the script can be as long as the implemented InterpretFile() function, so you can parse the

-64 scripts and can provide the necessary functions with reasonable performance. An example of this is the following:

In the embedded file, the script looks like this:

(beginning of MSGPASS.NET) etc.

SendMessage: OpenCardReader etc.

(end of MSGPASS.MET), and InterpretFile() contains this code:

(beginning of InterpretFile()) and b.

switch (Command) { etc.

case "SendMessage:

SendMsg(Msg;

break;

etc.

(end of InterpretFile()).

The 1040A plug-in module (1040A browser mechanism) may also create some buttons in the 160 browser window to implement some interactive control of its functions. For example, it may create a “Print” button and wait for it to be tapped or clicked to call the SendMsg() function to send the “PrintCurrentPage” message. The <embed> tag may also contain a predefined set of parameters for the 1040A plug-in module (1040A browser mechanism).

-65- _r ·, ·»ί· »^· to properly control the implementation of the 1040A plug-in module (1040A browser mechanism). For more information on how to use the <embed> tag and how to implement a plug-in module, see Stuart Harris and Gayle Kidder's "HTML Publishing for Netscape" (ISBN 1-56604-288-7), and Zan Oliphant's cited work.

Claims (45)

-66PATENT CLAIMS 1. A server for reconfiguring an electronic kiosk in a network comprising one or more input and output peripheral units and corresponding drivers, characterized in that it comprises: means for connecting to the network, means for providing at least one configuration set (175) comprising one or more files defining an application to be implemented in a kiosk (100, 200) and at least one embedded control function (620) capable of selecting a subset of drivers for a kiosk, means for receiving a configuration request for a kiosk connected to the network, and means for transmitting the at least one configuration set (175) to the kiosk over the network (150) in response to the configuration request, whereby the subset of drivers controls the associated subset of input and/or output units (130) and thereby configures the kiosk to execute the application. 2. The server according to claim 1, characterized in that the configuration request comes from the kiosk (10.0, 200) to be configured. 3. The server of claim 1, wherein the configuration request comes from an employee's computer. 4. The server according to any one of claims 1-3, characterized in that the at least one configuration set (175) is -67« a · * · ·»· * J* *··* includes any of the following: remote unit control, remote message display, file transfer, and collaboration between an employee and a customer. 5. The server of any one of claims 1-5, wherein the at least one embedded control function (620) comprises a system monitoring program for monitoring the operational status of one or more local kiosk functions of a kiosk (100, 200). 6. The server of claim 5, wherein the operational status is used to determine one or more of the following: maintenance needs for one or more input and/or output units (130); maintenance history for one or more input and/or output units (130); which application files are used in the network (150) to respond to one or more requests; and market information about one or more users of the kiosk. 7. The server of claim 5 or 6, wherein the operational state determines which configuration sets (175) the server (195) provides to the kiosk over the network (150). 8. The server of any one of claims 1-7, wherein the at least one configuration set (175) comprises one or more HTML files having zero or more hypertext components. 9. The server according to any one of claims 1-8, characterized in that the application is a customized application, which is -68kiosk (100, 200) is tailored to the needs of one user. 10. The server according to any one of claims 1-9, characterized in that the application provides access to the Internet through the kiosk (100, 200) configured with at least one configuration set (175). 11. A server according to claim 10, characterized in that the Internet access establishes a communication link between one or more users via one or more designated servers (L95). 12. The server according to any one of claims 1-11, characterized in that the application comprises one or more of the following: telephone calling, e-mailing, teleconferencing, fax transmission, training activity, information search in the network, and Web-based collaboration. 13. The server according to any one of claims 1-12, characterized in that the application provides information to a user at a kiosk (100, 200) configured with at least one configuration set (175). 14. The server of any one of claims 1-13, wherein the at least one embedded control function (620) is capable of causing the kiosk (100, 200) to request one or more configuration sets (175). 15. A method for operating a server (195) connected to one or more kiosks (100, 200) via a network (150), each kiosk (100, 200) having one or more input and/or output devices (130) and associated drivers, -69characterized in that the method steps are as follows: preparing at least one configuration set containing one or more files that define an application to be implemented at the kiosk, and at least one embedded control function that can select a subset of the driver program at the kiosk, receiving a configuration request from a kiosk connected to the network, "in response to this request, sending the at least one configuration set to the kiosk over the network, as a result of which the subset of the driver programs controls the assigned subset of the input and/or output units, and configuring this kiosk to execute the application. 16. An electronic kiosk, characterized in that it comprises: means for connecting to a network (150), one or more input and/or output units (30) and drivers associated therewith, means for accessing from a server (195) on the network (150) at least one configuration set (175) comprising one or more files defining an application to be implemented in the kiosk (100, 200) and an embedded control function (620), and means for executing the embedded control function (620) for selecting a subset of the drivers and for communicating with the subset to control the associated input and/or output units (130), and this means for the out Configures -70osk (100, 200) to execute the application assigned to the configuration set (175). 17. The kiosk of claim 16, wherein the access and execution means is a browser (160) in the kiosk (100, 200). 18. The kiosk of claim 17, wherein the input and/or output unit is any one or more of the following: a printer (L09), a media reader, a media recorder, a media dispenser, a banknote dispenser, a scanner (1 L 2), an insertion device, an electronic pen (1.36), a card issuing device, a check printer, a printer, a ticket issuing device, a cathode ray tube, a keyboard, a touch screen (105), a camera, a presence sensor, a telephone, a lamp, a microphone (133), a speaker (132), a CD ROM player, a mouse (135) and a memory (11 3 B). 19. The kiosk of claim 17 or 18, further comprising a display on which the browser (160) displays a web page as part of the application. 20. The kiosk of claim 19, wherein the Web page includes one or more of the following visual features: a hyperlink (350), a hyperlink to request one or more additional configuration sets (175), an icon, a menu, a text input field, a data input field, an advertisement, an announcement, news, weather report, and general information. -Ί\ 21. A kiosk according to any one of claims 17-20, characterized in that the application of the kiosk (100, 200) is a selectable application selected by one or more selection functions (105A). 22. A kiosk according to claim 21, characterized in that the application of the kiosk (100, 200) is a default application that is reconfigured by a configuration set (175) not associated with a selection function (105A). 23. A kiosk according to claim 21 or 22, characterized in that the selection function (105A) is displayed in the kiosk (100, 200) at one or more time intervals. 24. The kiosk of any one of claims 21-23, wherein the selectable application organizes the graphical user interface (300) to be adapted to the user's preference. 25. A kiosk according to any one of claims 21-24, characterized in that the selectable application is selected by an employee who is also connected to the network (150). 26. The kiosk of any one of claims 21-25, wherein the selectable application comprises one or more of the following: remote control of units, remote message display, file transfer, and collaboration between an employee and a customer. 27. The kiosk of any one of claims 17-26, further comprising a system monitoring program for determining the operational status of one or more input and/or output units (130) in the kiosk (100, 200). 28. The kiosk of claim 27, wherein the purpose of using the operational status is to determine one or more of the following: maintenance needs at one or more input and/or output units, one or more input and/or application files are used to respond to the request, and market (.130) ; maintenance history at output unit (130); in which network (150) one or more information about the users of the kiosk . 29. A kiosk according to any one of claims 17-28, characterized in that the browser (160) receives a request to determine what local kiosk functions and units are installed and, based on this, determines how to operate the drivers of the corresponding units. 30. The kiosk of any one of claims 17-29, wherein the files are HTML files having zero or more hypertext components. 31. A kiosk according to any one of claims 17-30, characterized in that the application is a personalized application that is adapted to the needs of a user of the kiosk (100, 200). 32. The kiosk according to any one of claims 17-31, characterized in that the application program provides access to the Internet. 33. The kiosk of claim 32, wherein the access to the Internet provides a communication link between the first and second users via one or more designated servers (195). 34. The kiosk of any one of claims 17-33, wherein the application comprises one or more of the following: telephone calling, e-mailing, teleconferencing, fax transmission, training activity, information search in the network, and Web-based collaboration. 35. The kiosk of claim 18, wherein the subset of input and/or output units (130) comprises a printer, and the application configures the printer to print one or more of the following: a receipt, a check, a Web page, a coupon, a ticket, a pass, and a form. 36. The kiosk of claim 18, wherein the subset of input and/or output units (130) comprises one or more of a microphone (133), a speaker (132), and a telephone set (107), configured by the application to form a public telephone. 37. The kiosk of claim 18, wherein the subset of input and/or output units (130) comprises a microphone (133), a loudspeaker (132) and a video conferencing system (114), which are configured by the configuration set (175) to form a video conferencing terminal. 38. The kiosk of claim 18, wherein the subset of input and/or output units (130) comprises a camera (131) configured by the application to capture images of one or more of the following: the user, the location surrounding the kiosk (100, 200), and a document. 39. The kiosk of claim 18, further comprising a data writer (113) for writing to a data medium, the application configuring the data writer (113) to write any of the following: music, software, text, graphics, educational material, and multimedia information. 40. The kiosk of claim 18, wherein the subset of input and/or output units (130) comprises a data reader (111) capable of reading recorded data media, and the data reader (111) is configured by the configuration set (175) to input information recorded on the recorded data media. 41. The kiosk of any one of claims 17-40, wherein the embedded control function (620) is a Java utility application. 42. The kiosk of claim 41, wherein the Java utility communicates via interprocess communication (6401) with an application programming interface unit that controls one or more local drivers. 43. The kiosk of any one of claims 17-40, wherein one or more of the embedded control functions is an ActiveX control. 44. The kiosk of any one of claims 17-40, wherein one or more of the embedded control functions is a pluggable control. 45. Procedure for configuring an electronic kiosk connected to a network and containing one or more input and/or output units and associated driver programs -75sara, characterized by the fact that it consists of the following steps: accessing at least one configuration set from a server over a network, which includes one or more files defining an application to be performed at the kiosk, and further includes an embedded control function, and executing the embedded control function to select a subset of programs driving the embedded control function and to communicate with the subset to control the associated subset of input and/or output units, thereby configuring the kiosk to perform the application associated with the configuration set. The authorized person A/ ¹ J Dr. Zoltán Kötetes, patent attorney, member of the SBG & K. International Patent Office, H-1062 Budapest, Andrássy út 113. Telephone: 34-24-950. Fax: 34-24-323 PUBLICATION