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

Abstract

A server system 195 is connected to a number of kiosks via a network 150, such as the internet, corporate or government intranets, extranets, etc. The kiosk has one or more predefined input/output devices 130 (e.g., display, keyboard, paper printer, telephone, etc.) and one or more driver programs 440 (local API) for each input/output device. The display is used to display one or more graphical user interfaces 105 and video images for the user of the kiosk. The kiosk has a browser 160 that is used to obtain the material from the server. The server has one or more application files 175 or configuration sets that serve the kiosk. The configuration set is a specialized application (use of the application causes the kiosk to be configured or reconfigured). One or more files in the configuration set include one or more embedded control programs 620 for controlling local APIs for devices of the kiosk. In this way, the device is controlled to configure the kiosk to implement the application.

Description

kiosks and servers connected to computer networks

The present invention relates to a kiosk and server connected to a computer network and allows the server to configure the kiosk.

A typical kiosk is usually, for example, a machine placed in a public place, accessed by users or customers, so that service providers can provide services to these users/customers. Typically, these services are "self-service" handled by the customer, without the need for the service provider to provide an agent to provide dedicated assistance to the customer. Thus, such services tend to be repetitive, simple, and specialized tasks, such as: 1) obtaining information, and/or 2) completing some simple transaction (such as buying a ticket, withdrawing cash, viewing a floor map of a department store, etc.).

The tasks to be handled need to be planned and determined in advance, and must be self-help. Therefore, the kiosk design is fixed and does not provide specific assistance to specific users.

Typically these transactions require the use of certain equipment such as one or more monitors, card readers, ticket printers, laser printers, ATMs, etc. These devices are generally fixed in kiosks for intended tasks and therefore have no other purpose.

The advantages of kiosks are convenience and reliability. Kiosks do not require full-time operators to perform their tasks, thus saving operating costs and increasing productivity.

Some information stations in the prior art are connected through a network, such as bank ATM machines, airline ticket machines and the like. There are also individual information stations, such as kiosks on shopping streets.

Existing technologies include information kiosks with video conferencing for banking applications in an attempt to establish a connection between banking agents and users/customers. This is accomplished by simply adding a videoconferencing system to a traditional kiosk.

Existing technologies have also combined kiosks and the Internet. This kiosk has a browser that displays HTML pages on the kiosk screen. Display screens on kiosks are controlled by user-selected hyperlinks. These kiosks are suitable for information access, and customers/users can browse through the information provided by selecting a "soft" button requesting a hyperlink. These kiosks may also be used for certain personal communications, like e-mail. In these systems, the screens are usually specially designed to provide a user interface (such as with navigation buttons, etc.), and the kiosk also acts as a filter to limit the URLs that customers can pass, so that only HTML defined by the kiosk builder The page (URL) can be accessed.

Most prior art kiosks are fixed, they cannot be changed or reconfigured easily, cheaply and quickly, because their programming is usually purpose-built (usually in a high-level computer programming language such as C++) and Installed on kiosks for specific applications. Mission changes require recoding, recompilation, reinstallation and retesting of the program on the kiosk. These generally have to be done by the kiosk manufacturer. Changing existing information stations is difficult, especially if there are a large number of information stations in the field that need to be updated.

Prior art kiosks fail to provide effective "face-to-face" service depending on the application, ie where an agent is required to consult and/or guide the user or customer to effectuate the service or transaction. An effective "face-to-face" customer service environment requires not only video/audio, but also simultaneous screen sharing (e.g. the user/customer sees data as the agent enters it) and remote device control (e.g. the agent can serve as a kiosk User/Customer prints receipt). The prior art does not provide for simultaneous screen sharing or remote device control of kiosks.

While some prior art provides user assistance from agents over the phone, typically the agent cannot see the kiosk screen directly. Therefore, the agent must rely on the user to explain any problems with the kiosk. Agents cannot look directly at kiosk screens to determine problems. Also, agents cannot remotely alter the kiosk's programs/functions to fix any kiosk problems. It is worth noting that the kiosks in some banking applications provide banking agents with the content of the kiosk screens. Also, the content is displayed by a separate application running on the agent workstation, rather than the application making the screen content displayed on the kiosk.

Certain existing technologies provide videoconferencing as a function of a kiosk. However, while video conferencing provides customers with audio/video connectivity to other components, this architecture has not been successful in the market. Because of the lack of tight integration between audio/visual communications and content on kiosk screens. When a customer has an input problem on a kiosk screen, the agent may not have the same information on the agent's screen as on the customer kiosk screen. For example, a kiosk has an ambiguous or erroneous value within the range of the screen, but the agent will not see the erroneous value during the video conference. Also, the agent can neither pinpoint the location on the customer's screen nor control the customer's screen. Additionally, agents cannot provide general information to customers through kiosks that are not pre-programmed to deliver. As another example, if a user requires information that is not available in the kiosk design, the agent can only provide voice or camera video information, and may not provide any information on the customer's kiosk screen or through other kiosk equipment. information.

Certain prior art discloses simple internet/browser based kiosks which can only handle limited and specialized applications, ie restricted browsing of information. These kiosks cannot provide an effective customer service environment with flexible applications because of the lack of kiosk control capabilities and coordination between customers and agents.

Accordingly, the present invention provides a kiosk and server as defined in the appended claims.

The approach described here benefits from the flexibility, reconfigurability, and collaborative kiosk architecture to provide a ubiquitous, configurable, and directly accessible web interface for a wide variety of applications, including "face-to-face" agent-to-customer Services and transaction processing, and ensure public access to many communication networks, such as the Internet (TCP/IP), Public Service Telephone Network (PSTN), Integrated Services Digital Network (ISDN) and so on. Thus, the web services system can deliver a very large number of applications (potentially created, developed and stored on one or more web servers) to reconfigure telekiosks and kiosk devices on the network in different ways for different applications , especially to support various input and output devices that are used in different ways for different applications.

Thus, in a preferred embodiment, the kiosk system may be connected to one or more networks, such as the Internet, corporate or government intranets, and the like. A kiosk has one or more input/output devices (such as monitors, keyboards, paper printers, telephones, etc.) and each IO kiosk user displays one or more graphical user interfaces and video images. Certain interfaces are application specific (an application is a purpose for which the kiosk is configured and reconfigured). A kiosk is fixed (an application is a purpose for which a kiosk is configured and reconfigured) a kiosk has a browser that fetches one or more application files (in a configuration set) from one or more servers on the network device. The application file (configuration set) consists of a set of HTML files that are served by the browser of the kiosk in order (depending on the application). One or more HTML files include embedded (control) programs for controlling the local API of one or more devices on the kiosk. One or more files may also include other HTML files, multimedia components (such as 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 using selection functions (such as speech, soft buttons, hyperlinks, etc.) on the kiosk. The application file (configuration set) corresponding to the selection (selection function) configures the kiosk accordingly. Thus, the kiosk is configurable and reconfigurable to implement various applications defined by the application files.

In certain preferred embodiments, one or more application files have one or more predetermined selection links (eg, hyperlinks). When the browser submits or interprets the application files (eg, file by file) predefined selection links are presented on the user's GUI as additional selections. Selecting one or more selections via one or more selection functions, the user can select and request one or more other configuration sets including zero or more other embedded control programs, HTML files, etc. Thus, through these additional selections by the user, the sequence of HTML document content submitted by the browser, and indeed the files in the sequence, can be altered to reconfigure the kiosk differently, to obtain information from the user, and/or to provide information to users. Sequentially submitted HTML files content configuration kiosk, providing a one-screen or multi-screen sequence of interactive screens and, if desired, sequencing (controlled by embedded programs) of device actions combined with reconfiguration for specifically selected applications information station. In these embodiments, the user (or other function in the kiosk or server) can reconfigure the kiosk for other applications by selecting a different option on the kiosk.

In certain preferred embodiments, the application portion includes Web page sharing functionality to allow agents or clients to work collaboratively over a network via kiosks and servers. A preferred embodiment implements a "thin" client architecture, ie, in which no specialized application software resides on the kiosk.

Various embodiments of the present invention are described in detail herein only by reference to the illustrations of the following figures.

Figure 1 is a block diagram of a preferred embodiment of a kiosk.

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

Figure 3 is a block diagram of an example of a graphical user interface used in a kiosk.

Fig. 4 is a block diagram showing a configuration set (application file) selected and executed by a user to configure a kiosk.

FIG. 5 is a block diagram of an application file set (configuration set), including one or more HTML files and associated hypertext portions including at least one embedded control program.

Figure 6 is a block diagram showing a preferred embodiment of a control program/function that executes the application file and interacts with the native API program to configure the kiosk.

Figures 6A-6D are block diagrams showing various preferred embodiments of the kiosk control mechanism.

Fig. 7 is a flowchart showing the implementation steps of executing an application file using the API control function.

Figure 8 is a flowchart showing the steps performed in a typical server.

Figure 9 is a block diagram showing a preferred kiosk software architecture using ActiveX.

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

Figure 10 is a block diagram of an alternative kiosk control embodiment using a plug-in.

1 which is a block diagram of a preferred embodiment of a kiosk 100, wherein the kiosk 100 includes a computer 110 (such as IBM's PC350 or PC750 personal computer), which has a suitable well-known network interface 155. Network 150 may be any known local area network (LAN) or wide area network (WAN). In a preferred embodiment, network 150 is the Internet, while other general networks 150 are expected to include: corporate intranets such as corporate networks, government networks, educational networks, inter-community extranets (extranets), and one or more retail commercial networks. These networks can be implemented through telephone networks, cable TV networks, ISDN networks, etc. Computer 100 has one or more input and/or output devices (below) 130 . They are installed as part of the kiosk 100 . Computer 110 typically has one or more main memories as is well known, one or more external memories (eg hard disk drive, CD-ROM, etc.) 110M and one or more central processing units (CPUs) 110C as are known. In addition, the computer 110 also has an optional hardware keyboard 135 and mouse 134 for maintenance purposes. The user accesses various (external devices 130) input and/or output devices (collectively numbered 130) to communicate with other clients and/or servers 195 connected to the network 150 via the computer 110 and the network 150, and/or from the connected The information is communicated to other clients and/or servers 195 on the network 150 . Examples of these input/output devices 130 include a touch terminal 103 with a screen 105, a printer 109, any well-known general information reader 111 (such as a card reader 121 for reading magnetic cards, credit cards or smart cards), a scanner (such as laser scanner) 112, any known general information writer 113 (such as a printer, ticket printer, such as a floppy disk drive media printer, financial statement printer, or receipt printer), vending machine (such as for selling slow-moving goods or computer disk) or any other device 130 that provides the user with information on the tangible medium 113A. Other input/output devices 130 include one or more of the following: ATMs, scanners, deposit machines, pen input 136, card issuers, ticket issuers, CRTs, keyboards, touch screens, program-controlled cameras camera, one or more human sensors (such as infrared). One or more lighting, CD-ROM player, audio input/output device (such as microphone 133, speaker 132 or telephone unit 107) and memory 113B. The kiosk 100 can be provided with well-known communication equipment such as a telephone 107 or a video conferencing system 114 such as the PictureTel PCS-100 Desktop ISDN Video Conferencing System (PictureTel is a registered trademark of PictureTel Corporation). The videoconferencing system includes a camera 131, a speaker 132, a microphone 133 and/or one or more ISDN connected or disconnected network connections via a suitable network interface 155. Connections can be made to other networks 151 such as the Plain Old Telephone System (POTS) telephone network 122 via telephone 107 , speaker 132 , and/or ISDN line 123 . Other external devices 130 can also be independently connected to the network (150, 151) using known interfaces.

Computer CPU 110C executes software programs including control process and library 125 and in some preferred embodiments one or more co-processes 170 . The control process 125 has two parts: one or more embedded control functions/programs 620 and one or more control mechanisms 640 (see Figures 5, 6-6D below). The embedded control program/function 620 satisfies specialized processing (such as car loans for the banking industry, shopping for card machines, etc.), and uses a mechanism 640 that does not satisfy specialized control to control and communicate with each input/output device (or a subset thereof) 130 Associated native application programming interface 680 (API). Thus, input/output device 130 is in some sense exclusively controlled by application content. In another embodiment, the control mechanism can be dynamically loaded from the network 150 to the computer 110 .

Collaborative process 170 includes APIs and other programs that perform functions that establish a collaborative session from kiosk 100 . A description of collaborative processes is described in US Patent Application Serial No. 08/722,287, entitled "Internet Web Page Sharing," filed September 27, 1996 by Fin et al., which is hereby incorporated by reference in its entirety. (See European Patent (EP) Application 97307536.0, Publication No. 833260.) The computer also executes programs required to interact with the network 150, including a Web browser program 160, such as the Netscape Navigator browser. (Netscape Navigator is a registered trademark of Netscape Communications Corporation).

FIG. 2 is a block diagram of another embodiment of the present invention showing a kiosk 100 within an enclosure or part of an enclosure 200 . Enclosed space 200 can be any type of space, such as a room, den or any other private or semi-private area, within which kiosk 100 resides for one or more users. In this embodiment, the computer 110 is connected to one or more known peripheral devices 130 . An environment is created for the user in the space 200 controlled by the computer 100 . For example, peripheral peripherals may include space lighting 205, displays 210 and/or environmental elements in space 200 that convey additional information (such as sales information) And/or secure access 215 from space 200 . Furthermore, this (partially) enclosed space may have other surrounding external devices 130 similar to those described above, such as audio, video conferencing, etc. Examples of virtual worlds are well known.

In preferred embodiments of the systems 100 and 200, the user selects (using the selection function) an application, such as banking, for which the kiosk will be configured, and the browser 160 connects to one or more applications on the Internet (general network) 150. Each web server 195 interacts to fetch one or more configuration sets 175. An optional data communication is initiated between the server 195 and the browser 160 of the kiosk (100, 200). Application files 175 are then executed file by file by browser 160 to: 1) Any request driver programs (local API 680) that control one or more input/output devices (such as touch terminal 103 or display) used with each application ) 130; 2) arbitrarily selects a series of input/output devices 130 to take action, such as displaying a series of web pages on a terminal/display; 3) arbitrarily selects to notify the user to input from the input device 130 to the server 195; and 4) also The arbitrarily selected application file 175 is further executed by the browser 160 according to the user's input. Thus, the user can select a first application (and its associated application file 175 on server 195) using the first selection function, which reconfigures the kiosk for the first specifically selected application. When the second application is selected, the kiosk is reconfigured again for the second application and so on. For any subsequent configuration, the selection function is presented to the user in the form of the previous configuration.

An application is any use for which the kiosk is configured. Examples of applications include usage (configuration) in: finance, business, information (news, advertising), communication (e-mail), web access, video conferencing, retail, market transactions, services (eg government planning). The owner of the application is any individual, organization or business that configures the kiosk to provide the application. For example a bank or mutual fund should deploy a kiosk with one or more financial applications. Examples of these financial applications include providing users with financial information, opening accounts, dispensing cash, paying bills, providing loans, making deposits, and getting assistance from agents. An example of a service owner is a car rental company that will deploy kiosks to provide car rentals/leases etc.

In another preferred embodiment, the kiosk (100, 200) is reconfigured by the server 195, not by the user. For example, a kiosk can be placed in a public place, like a shopping mall, and the browser can be configured to initially or periodically fetch (or The server can make a "push") configuration set (application file) 175 to the kiosk 100. Thus, from a remote location of the server 195, the system designer can control the configuration of the kiosk. As an example, a kiosk on a high street could be initially configured to display a map of the high street, play background music, announce or provide weather conditions, or other general information like news or stock quotes.

Configuration set 175 can also control one or more input/output devices 130 to have or become selected function 105A. For example, touch screens, icons, hypertext links, soft buttons on GUIs, hardwired buttons, remote sensors (like radio frequency identifiers), or live voice messaging for videoconferencing systems. Selection function 105A is a function that allows the user to make selections that cause the kiosk to be reconfigured for the user's application.

These selection functions 105A allow the user to reconfigure the kiosk 100/200, and/or access other information that the server 195 prompts the kiosk to provide.

The selection function 105A, and/or other displayed information may also be a source of income for the kiosk owner/operator. For example, announcements provided by kiosks can be paid advertisements. Application providers (such as banks, mutual funds, mortgage companies, lenders, brokers (stocks, real estate), rental businesses (vehicles, equipment) service providers and retailers) will pay for select functions on kiosk 100/200 For a fee, users will choose to configure the kiosk for their application. The fee amount can be based on: kiosk location, location/location of select function/information on kiosk (e.g. GUI), size of select function 105A, time and duration of select function 105A/information provided by kiosk, etc. . The selection function 105A/information can change at different times or be displayed periodically to target different types of users/customers. For example, a kiosk at an important central station may display long-term passenger flow information during peak hours, and the kiosk should be reconfigured just before lunch to have a selection function 105A for ordering meals.

The kiosk 100/200 can be reconfigured by the application provider through the server 195 into a user-specific kiosk. For example a travel agent may have a user profile for Mr. Smith who selects an option function 105A on the kiosk 100/200 in a public place or where he is employed. Once the kiosk is reconfigured for travel agent use, the kiosk (as directed by an application file 175) can request personal information from Mr. Smith, for example by entering a personal identification code or swiping a credit card using an input/output device. Then, the personal information of Mr.Smith is transmitted to the server 195 through the information station 100/200, and the profile of Mr.Smith is accessed. Using the information in the profile, one or more application files 175 are sent by the server to configure the kiosk specifically for Mr. Smith. For example, only things about vacations to Central America may be offered on the kiosk. In another embodiment, one or more application files 175 can allow the user to organize the GUI (below 300).

In another preferred configuration of the kiosk 100/200, a collaborative session is established between one or more kiosk users and one or more agents of the application provider. Collaboration is established by collaboration process 170 resident on the kiosk, or provided by server 195 from application files 175 (see Fin et al. patent application referenced above).

In another preferred configuration of the kiosk (100, 200), the server 195 provides the kiosk with application files 175 for monitoring or maintaining the kiosk. For example, in these embodiments, one or more embedded control programs 620 monitor the operational status of one or more input/output devices 130, such as with "safe" timing status, error checking protocols, etc., to determine which input/output devices 130 Equipment is working. These messages are passed back to the information station 195. Other application files 175 are used to query which I/O devices 130 are installed or functioning on a given kiosk. In this way, the server 195 can determine which additional application files to send to the kiosk, which input/output devices 130 are allowed to be installed or functioning, and which are not allowed (configured) to be installed or which are faulty. Thus, a kiosk containing any common combination of input/output devices 130 can be remotely installed to a server, and the server will provide the appropriate and working application files to make the kiosk work for any given application. Application files can also be used to obtain information from one or more input/output devices to determine how to operate those devices.

FIG. 3 shows an example of a Graphical User Interface (GUI) 300 as it appears on the screen/display of the kiosk 100/200. GUI 300 provides the main access interface for kiosk users by selecting function 105A. Examples of selection functions 105A include icon images 301-304 representing applications such as banking 301, insurance services 302, general software buttons 303, and pizza restaurants 304. GUI 300 can also display selection function 105A in the form of menu 320 with one or more selections (typically 325). Other examples of selection function 105A could be hyperlink 350 to part of GUI 300 and/or menu 320. Other areas 340 of GUI 300 can be used to enter information and/or other data. Using these fields of information 340, the GUI 300 can be presented in formats 370 such as tax forms, loan applications, loan applications, deposit slips, and the like. The GUI can be displayed as web pages through the browser 160 using well known techniques. The web pages may have a multimedia (sound, video) format that is presented to the user through other input/output devices 130 .

FIG. 4 illustrates the mechanism of how a user interacts through the user interface to select the selection function 105A. The selection function 105A causes the corresponding configuration set 175 to be offloaded from the server to the client (kiosk 100, 200) to handle certain specialized functions, as well as to control the specialized A subset of 451. External devices 130 are controlled through their native APIs 440 (or a subset 441 of these native APIs 440). Native API 440 is a software functional interface that directly controls one or more external devices 130 . For example, a native API for card reader 130 may include: initialization, startup, reading data from card, ejecting card, and shutdown functions.

Selection (of the kiosk configuration) is achieved through selection functions 105A, examples of which include:

a) The user explicitly touches a graphic icon on the screen, or other selection element such as a button.

b) The currently executing program determines that a selection needs to be requested based on the user's behavior. For example, if the user makes the same error more than two times in a row, a helper is requested.

c) According to the logic of the currently executing program, determine the next option (information station configuration). For example once a user completes a mortgage qualifying application and the bank approves it. The current application asks the user if he wants real estate agent information, and if he answers "yes" the kiosk configuration is changed to a choice for the realtor application.

In one embodiment, when selection 105A is made, browser 160 sends a request via HTTP to server 195 via web interface 155 for the first application file 175 (file 500) corresponding to selected function 105A (at Description of the file 500 in the application file/configuration set 175, see also FIG. 5). Server 195 then serves application file 175 to browser 160 . After the application file 500 arrives at the browser 160, the HTML content of the file 500 is executed line by line. The files 500 are also sent to the browser so that the browser 160 executes each file 500 line by line and configuration set 175 in the order defined by the HTML text in the configuration set 175 . Thus, by executing the file 500 in the application file/configuration set 175, the native API 440 (related to the device 130), or the subset 441 of the native API is invoked to control the selected subset of devices 451 and the kiosk (100, 200) is reconfigured. It is worth noting that the logic of each application file/file (175, 500) and/or the role of the user can change which application files/files (175, 200) are executed and/or whether certain application files are not executed.

By executing application files 175 , browser 160 selects and controls one or more devices 130 . Depending on which device 451 is selected during execution of the application file (eg, device subset 451 ) and how the device subset 451 is controlled. Define the configuration of the kiosk, for example, in a banking configuration, the executed application file 175 calls the API subset 441, such as selecting and controlling the card reader 111 and the printer 109 (equipment subset 451), reading bank cards and Print out the transaction log. In the same banking configuration, executing one or more application files (and/or some lines in the application files) 175 does not select or control the device 130, but does other actions, including: storing data, sending data, or returning Message to server 195 etc. In another configuration, Pizza orders, and the executed application file calls various API subsets 441 to select and control the same subset of devices 451 (i.e. card reader 111, printer 109) to read and charge from the credit card respectively And print out the shopping receipt indicating the selected Pizza main item.

It is worth noting that in some configurations, the executed application file 175 does not select one or more devices 130 . In this case, using the default facility, for example, a line in file 500 causes a line of displayed text to be sent directly to display 103 by default.

It is also worth noting that the browser 160 can access a private set of native executable modules. These modules interact with the executing application files with other native programs and/or libraries (see Figure 6).

FIG. 5 is a block diagram of an application file set (configuration set) 175 comprising one or more HTML files 500 and an associated hypertext section containing at least one embedded control program 620 . All web-based application files 175 are HTML based files with at least one embedded control program 620 . Application file 175 may optionally contain other hypertext portions, HTML-based or non-HTML-based. Typically, an HTML file includes standard HTML (such as HTML 3.0) signs as: text 525, images or graphics 528, animations (embedded as images 528, applets 505, scripts 515 or other embedded components 520) , sound (such as an embedded component 520 ), video (such as an embedded component 520 ) and other embedded programs 520 . These signs are well known. In a preferred embodiment, browser 160 is Netscape Navigator V3.0. Embedded programs can be implemented using Javascript and/or Java applets and/or any other embedded programs using plug-ins (Java is a registered trademark of Sun Microsystems, Inc.). As shown in FIG. 5, HTML file 500 embeds a Java applet with tag 505, tag 515 embeds Javascript functions, and tag 520 embeds any other program that requests browser plug-in functionality. More information on standard HTML tags can be found in the "Netscape HTML 3.0 Source Book", which is hereby incorporated by reference in its entirety. Certain embedded programs 520 are embedded in control functions/programs 620 .

FIG. 6 is a block diagram showing system components included in an embedded control program 620 executing a typical application configuration kiosk 100 .

In the browser 160, an interpreter 610 functions to interpret or recognize HTML tags in HTML files. The interpreter 610 will request the HTML tag executor 611 to execute the function of each HTML tag according to the type of the tag and the content of the tag. If this execution does not request the API calls 680 of the local kiosk program (including the local peripheral API 440), the browser executes 615 each HTML tag using the standard function library 617, if necessary. These functions 615 without API control include: displaying text, displaying images and so on. These are well known and present in prior art browsers.

However, if the executor 611 encounters an embedded control function 620 that calls the API 680 of a local kiosk, the executor 611 requests the security manager 625 inside the browser 160 to determine whether to allow the API call. As will be explained in more detail below, the kiosk control mechanism 640, or a portion of the mechanism 640A, is placed in a subdirectory of the directory where the browser is located. By doing these things, when the executor 611 encounters the embedded control function 620, the security manager 625 will look for the control mechanism 640 (640A below), and the API control function 621 will load the control mechanism 640/640A into the browser process 160 . For example, these embedded control functions 620 may include applets to call one or more native API functions 680/440 (i.e., the selected API subset 441) to operate a given subset of devices 451, for example, if the device is The card reader, embedded control function 620 with the control mechanism 680 can call the appropriate API 440 to open the card reader device, read data from the card, eject the card and close the card reader device.

It is worth pointing out that the browser 160 does not execute the embedded control function 620 from the network 150 to execute the native API 680 . In fact, these browsers specifically prevent the execution of these API control functions for well-known security reasons. For example, if the application file is changed while passing through the network, the execution of the corrupted control functions in the application file can cause unpredictable and harmful results on the client machine, ie the kiosk (100, 200).

As we all know, Java was designed to overcome network security problems by using specialized means, such as bytecode transmission and verification and error checking through virtual machines. Moreover, when Java is used in web-based applications using applets, embedded in HTML documents, the browser usually strictly prevents the Java applet from accessing any native Java programs on the client side unless they are Those in the standard Java library were built for the simple purpose of preventing any damage that the applet might do to the client. Because the applet comes from an environment you cannot control, ie it could come from any server on the entire network.

As stated in the book "Java Now" (P4., by Kris Jamsa, Jamsa Press, 1996. ISBN 1-884133-30-4), "To address security issues, Java developers must ensure that programmers cannot Application development computer virus, and the applet cannot return system information about the user (such as the files of the user's system) to the server, you will hate, for example, while browsing your competitor's web site, their Java applet Browse your hard drive. To provide this security, Java developers choose to restrict the operations that applets can perform. For example, Java applets cannot read or write files on the user's system. This way applets cannot store viruses to the user's disk or read the information stored on the user's disk". The book also states that "Java enables programmers to generate independent programs, and Java's independent programs are similar to programs generated by programmers with C++. This independent program can Read and write files and perform operations that Java restricts applets to do. On the other hand, Java applets run only within the scope of the browser...". This means that Java applets are not designed to operate browsers Functions outside of process 160.

During standard browser operation, the browser's security manager 625 monitors for violations of these security rules. If an applet is found to request access to a program that is not in the standard Java library, the browser simply reports a security violation error and stops executing the applet.

In one embodiment, portion 640A of kiosk-specific control mechanism 640 is added to browser 160 and other portion 640B of kiosk-specific control mechanism 640 is added to application programming interface (API) 680 (including 440) to enable The application file 175 configures the kiosk. Therefore, kiosk-specific control mechanism 640 is divided into two parts: browser mechanism 640A and API mechanism 640B. In this embodiment, browser mechanism 640A and API mechanism 640B communicate through inter-process communication (IPC) 640I. The IPC 640I interface allows the browser mechanism 640A and the API mechanism 640B to communicate using message passing instead of direct function calls. (IPC is well known, an example of which is Dynamic Data Exchange (DDE) used in the Windows operating system; Windows is a registered trademark of Microsoft Corporation).

The browser mechanism 640A is located in the browser subdirectory, so any API control function 620 in any application file 175 can be recognized by the interpreter 610 in the browser 160 . The API mechanism 640B receives messages from the browser mechanism 640A, and independently controls various functions including the device API 440 according to the messages. Thus, an applet from a browser can control one or more devices and native functions, but only those with browser mechanism 640A.

Therefore, access to application files 175 on the network by other functions in the kiosk remains secure. Thus, kiosks are configurable and secure. In addition, since the API mechanism 640B operates the device API regardless of the browser, any device control function (a subset of the API control function 620 used to control a given device) passed to the API mechanism 640B will be executed on the device subset 451, Even if the application files are more delayed or changed in the browser 160 . This provides a persistent way to handle device operations, i.e. once the API function (640, 440) is initialized, the function is completed regardless of whether the application file 175 is changed/delayed by the browser. User interaction is more efficient, for example an application file 175 can control the card dispenser to issue new cards. The user/browser then moves on to another application file while the card dispenser device is writing data on the magnetic strip and embossing new cards.

The browser mechanism 640A is: 1) located within the browser's own standard directories/libraries, and 2) structured to enable the application file 175 to request one or more native APIs 680 through two methods, which are : Transmit messages (such as function names and related parameters) about one or more local API functions (see Figures 6A and 6C and their explanations) or directly request local API functions (see Figures 6B and 6D) through message transmission using the name server mechanism and its explanation).

In a preferred embodiment, the browser mechanism 640A includes a Java API (sometimes referred to as a "Java Wrapper") known to the application file 500, and also includes functions written in a native language (such as C++) to communicate (such as using interprocess communication or name server) or call the local API680 directly.

API mechanism 680B: 1) directly access various local function modules (such as browser control module, collaborative function module, device control module, and system monitoring module, etc.); 2) have a structure that can request one or more API functions 680 Set, or use the name server mechanism, or directly call the relevant local function module; and 3) have an IPC that can communicate with the API640A based on the message. (It is worth noting that API functions 680 are specifically designed to control any given device or function in the kiosk, and may or may not be accessible by application files 175).

An example application that uses this kiosk control mechanism is to query the system for configuration and status before the application determines how to configure the kiosk. In the application file 175, the applet CallAPI.class can be used to request the API function 640 "query_status". like,

           
    Public class CallAPI extend applet implement Runnable{

...

a=new kioskAppInterface(); (640A)

a.send_APImessage("query_status"); (640A)

a.get_APImessage("status", sysStatus); (640A)

...
}
And the applet can embed HTML files,

＜HTML＞(175,500)

...

<body>

...

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

＜/applet＞

...

＜/body＞

＜/HTML＞.

        

When this applet is executed through a browser, it first declares a class called kioskAppInterface, which is located in the browser's standard library along with the associated DLL. Then, a method of the kioskAppInterface class (640A) called send_APImessage() is used to send the API message "query_status" (640A). This method calls the interprocess communication function 640I to send a message to the API mechanism 640B. The API mechanism 640B then requests the relevant native API function 680 to obtain system state data and sends the data back to 640A through the interprocess communication function 640I. The applet uses the method get_APImessage() with the command "status" to get the data sent back from 640B, and stores the data in a data structure called the sysstatus class.

API messages passed between 640A and 640B may use the name server function mechanism (see FIG. 6A below). Usually, when 640B gets a message, the name service function (in 640B) analyzes the message and calls the corresponding native function API 680 . In this example, it calls a system monitoring program function API to obtain system status data, and these status data are explained as follows: in the name service function in 640B:

           
...

if (Func_Name = = "query_status")

{data=system_supervisor_get-status(); (680, 690)

send_message(data);(640I)}

else if (Func_Name = = "read_card")

{ ... }

...
Here is an example of getting data as described above from the "sysStatus" class data structure:

Num.of Device=5

laser printer=OK

card reader=OK

card issuer＝no card supply

receipt printer=OK

ticket printer=OK

        

This message states, they are 5 devices on the kiosk and all are working except the card issuer which requires a card.

Based on the kiosk's current status data, the application file 175 selects laser printers, receipt printers, and card readers (equipment subset 451) and avoids the use of cards when the status data indicates that the card issuer does not have a card in its supply slot. Issuer (in which case the card could be produced by other means and mailed to the kiosk user).

In certain preferred embodiments, similar techniques are used to determine which devices are provided on the kiosk and whether they are functioning properly. Thus, the server can provide specific application files 175 to configure the kiosk based on which devices the kiosk is available and/or which devices are operable. Thus, any number of kiosks of different designs and/or operational states can be configured by appropriately selecting application files on the server corresponding to various application configurations. As in a banking application, the application file 175 (file 500) containing laser printer controls is sent to a kiosk equipped with laser printers for printing high quality bank financial statements, while the application file 175 (file 500) with receipt printer controls Will be sent to those kiosks that are the same task (bank financial statements) and have only (available and operable) receipt printers. In this way, kiosks with malfunctioning laser printers or less expensive kiosks without laser printers can still be properly configured for banking applications.

In another embodiment, state information can be requested by one or more servers by means of sending requests on application files. This information can be used to determine which kiosks and/or those devices on those kiosks require service. For example, a service representative can be dispatched, if necessary, to add cards to the card issuing facility.

In another embodiment, status information may be required for the service history of the kiosk and/or device. In addition, other market information can be obtained, for example, which configurations are most needed by which types of users at a particular location. In a preferred embodiment, the kiosk can have a browser window (system monitoring application window) running in the background of any other application. The system monitoring application window may include one or more HTML files that include one or more applets that communicate with one or more servers. (The mechanism by which Java applets communicate with servers is well known). The system monitors the application window and can be activated whenever the kiosk is powered on and keeps the kiosk active all the time. In this way, one or more servers can obtain the system status information of the kiosk at any time by communicating with the applet.

Among the possibilities offered by the described method are: 1) a "thin client" kiosk; since no application specific software needs to be pre-installed on the kiosk, the kiosk can be set up and maintained cost-effectively. Thus, one application (application file 500) can be written to the server for a large number of "thin" kiosks connected to the server network. For any "thin" kiosk on the network, no application specific software has to be designed. In fact, the network can consist of one or more standard (and thus less expensive) "thin" kiosks, completely without the application of specialized software. (For example, a kiosk producer can produce one or more kiosks, independent of any application). Application files 500 can be developed, updated and/or maintained on the server, and can be used to reconfigure one or more kiosks on the network without changing any programs on those kiosks. This "thin client" information station makes it possible to develop large-scale information stations for the general public to access services at any time and any place. For example, a "kiosk phone" can communicate over the Internet and/or over a telephone network. 2) Due to the reconfigurability of the kiosk, a large number of various applications developed on the server can be delivered through this kiosk. Therefore, application providers can share any information station on the network. These applications can be provided on kiosks at specific times and/or for specific conditions, such as requested by the user or for any given environmental condition (the umbrella shop advertises when the day starts to rain). 3) Because the information station can be based on the open standard technology of the Internet and the web, it can take advantage of the advantages of the Internet and the WWW, which are rich in information, rich in media and rich in technology.

Here are non-limiting examples of how users can use the kiosk 100:

1. Dynamically display various images, video clipboards, sounds, graphics patterns and texts on the screen of the free time information station. The contents of the screen are all controlled by the HTML file, and the HTML file is updated according to the request of the information station or the push of the server. Service providers may pay different prices for different kinds of screen "actual levels" and the time spent displaying them. In the morning and evening newsletters, it can display major headlines and financial market changes; in the middle of the day, it can display promotions for many restaurants; in weekends, it can display advertisements for sales in department stores. This content often attracts passers-by to touch the screen.

2. The user sees the screen, walks over and touches it. It immediately goes to the next screen showing an array of image icons and text indicating the category of the application.

3. The user touches the Pizza order icon to bring up a new screen. From the new screen, the user can choose the type of pizza. The screen will prompt the user where and when to submit the pizza. And the user can give information by touching the keyboard on the screen. A control program 620 embedded in HTML collects data. The screen will then prompt the user to insert his (or her) credit card to authorize the charge. The control program will open the credit card reader and collect credit card information. The control program can then use the relevant kiosk API functions to invoke communication functions on the kiosk to access credit card companies (eg, via modem) and pizza shops (eg, via fax). After completing these functions, the screen will confirm the order information with the user, and other general separate sales transactions can be completed in the same way.

4. The user can also press the phone icon to make a phone call. The phone application HTML file is displayed on the screen as a phone keypad. After the user enters the phone number, the embedded control program will call the relevant API function 640A to start the phone call. This could be a regular telephone call via the Public Service Telephone Network (PSTN) or via the Integrated Services Digital Network (ISDN) or via a network connection (122, 123, 150) relying on kiosks, application files 500, and user selection 105A Internet-based phone call. When the phone is connected, the user can either use the cell phone, or use a phone connected by a phone line equipped on a kiosk (see U.S. Patent Application 08/595,897 Hortensius et al., titled "Multipoint Simultaneous Voice and Data Services Using a Media Splitter Gateway Architecture", filed February 6, 1996. Corresponding to European Patent Application 789470, which is hereby incorporated by reference in its entirety).

In another preferred embodiment, if the other end has the same device, the user can choose a video phone call or even a video conference call with application sharing, then the control program 620 embedded in the HTML application will call the relevant API function 640A, start the video conference function of the information station. Users can use touch screens and electronic pens equipped on kiosks to facilitate conversations. (Citing the "Internet Web Page Sharing" patent application Fin et al. mentioned above).

5. The user can choose the fax function. The screen will prompt the user to enter the fax number, input the credit card, and put the document to be faxed into the corresponding device (such as the document chute). And touch the OK button on the screen when ready. When the button is touched, the embedded control program 620 will request the relevant device control API function 640A on the kiosk to operate the scanner, scan the document, return the document, and send the document electronically through a network such as the PSTN or the Internet.

6. User can choose email function. For email, the screen will display the HTML application. The embedded control program 620 can request related API functions 640A or directly communicate with the mail server, and the directory server authenticates the user through the browser and retrieves existing email messages or sends new messages.

7. The user can choose 105A to transmit electronic files on a medium carrier, such as a floppy disk. The screen may prompt the user to follow certain processes, such as inserting a floppy disk into a slot. The embedded control program 620 will request the relevant API function 640A to read the disk and read or write the files selected by the user, and send them according to the same user's instructions (such as sending to a certain person's email address).

8. The user can choose a service from a wide range of service providers (such as application owners on the server), such as lawyers, doctors, accountants, real estate agents, loan brokers, investment consultants, insurance agents, etc. The screen will display the corresponding application providing the requested service in an HTML file (the service can be presented in any natural language such as English, Spanish, Chinese, Japanese, French, Italian, etc., according to the user's choice).

9. Depending on the service provider's application, a real-time collaborative session can also be initiated with video, audio, screen sharing and remote device control capabilities (see referenced above to Fin et al.). The embedded program calls related API functions 620 to manage video, audio and data communications.

10. Users can choose to search for information. The screen prompts the user what information is required, while the embedded control program collects the data and sends inquiries based on the type of information. Queries can be sent over the Internet using known search engines, databases on application servers, and databases on other web servers.

11. User can choose customized application server. For example, once a user is authenticated (eg, information accessed from a magnetic or smart card) the application profile provides information and/or a kiosk configuration customized for that user.

12. The user can select the configuration of the kiosk 100, not originally provided by the kiosk. By interacting with the kiosk in the first configuration, the kiosk can be reconfigured in the second configuration according to other application files 175 . For example, the first configuration may provide a user input (icon or hyperlink) which accesses the application file 17.5 of the second configuration.

13. A user may be one or more students or trainees. They need access to one or more kiosks on the network connected to their servers providing the "teaching" application files 175.

14. The user can select "Electronic" products from the information station. For example, a compact disc (CD) with music, video, computer software and/or other multimedia information can be distributed from a suitable distribution device. Additionally, blank media (eg, tape, floppy disk, writable CD, etc.) can be written to by suitable kiosk equipment to provide any "electronic" information that can be transmitted to users in intangible form over the network. For example, the latest opera recordings could be provided on CD in this way without having to ship CDs "mastered" in a factory to stores.

Another example is now given showing certain kiosk control mechanisms 640 for inputting information from and outputting information to kiosk devices. In a normal input situation, the application file 500 may have an embedded applet 620 called CallAPI.Class for calling the API function 640 "hardkey_input" such as

           
Public class CallAPI extend applet implement Runnable{
				
<dp n="d21"/>
...

a=new kioskAppInterface(); (640A)

while(InputData.lastchar!=RETURN)

{

a.send_APImessage("hardkey_input"); (640A)

a.get_APImessage("input", InputData); (640A)

(for example, display key input at a suitable position on the screen)

...

while(InputData.lastchar!=RETURN)
{

a.send_APImessage("softkey_input"); (640A)

a.get_APImessage("input", InputData); (640A)

(e.g. display key input at a suitable position on the screen)}

...

a.send_APImessage("LaserPrint", FileName); (640A)}

and this applet is embedded in the HTML file, such as

<HTML> (500)

...

<body>

...

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

＜/applet＞

...

＜/body＞

＜/HTML＞.

        

When this applet is executed by the browser, it first declares a class called kioskAPPInterface. This file and the associated DLL are located within the browser's standard library. It then uses a method of the kioskAPPInterface class (640A) called send_APImessage() to send the API message "hardkey_input" (640A). The method requests the interprocess communication function 640I to send a message to the API mechanism 640B. The API mechanism 640B then calls the associated native API function 680 to collect keystroke inputs from the hardware keys, equip the kiosk with these inputs, and send them back to 640A via the interprocess communication function 640I. The applet uses the method getAPImessage() and the command "Input" to get the data sent back from 640B and store them in an internal data structure called the InputData class.

In the name server function in 640B,

           
    …

    else if(Func_Name=="hardkey_input")

         {data = get_hardkey_input(); (680, 690)

         send_message(data);(640I)

         }

    else if (Func_Name = = "softkey_input")

         {

         data = get_softkey_input(); (680, 690)

         send_message(data);(640I)

         }

    else if (Func_Name = = "LaserPrint")

         {

         Laser_Print(FileName); (680, 690)

         }

    …

        

Note that if the application file 500 had an embedded applet requesting "soft key" input, similar API messages would be passed between 640A and 640B, and a different API function 680 would be used to "pop up" on the screen "soft keyboard window and get user input. API functions 680 are well known for using these soft keyboard inputs.

In the same way, if the application file 500 has an embedded applet that requests printing on an output device, such as a laser printer, the code above will point to the native API function 680 . Laser_Print(FileName), controls the laser printer to print the file "FileName".

FIG. 6A shows an embodiment of a kiosk control mechanism 640 utilizing IPC 640I and name server function 640B. In this case, a small fixed set of general communication (mainly for message passing) API functions 640A is used by the application file (175, 500). These communication API functions communicate or pass messages between 640A and 640B. The execution of the message is implemented by the name server function in 640B. This server function 640B also serves as the server of IPC640I. Name server functions recognize a variety of predefined messages. For example, in one embodiment, the communication API function set has 2 functions: send_message(message) and get_message(message). However, there is a lot of "news" here. The name server function in 640B has a table containing each of these predefined messages, and each predefined message is associated with a logical set of possible calls to the appropriate native API function 680 to execute the respective predefined message. In this embodiment, new devices and new functions realized by these new devices can add the logic needed to realize the new functions by providing new predefined messages. In this way, the application files (175, 100) only need to pass These new functions can be implemented by using the new message identifier in the defined communication API function. Generally only involves changing the "ASCII" or "text" message identifiers in the application file 500. It is not necessary to code and compile new embedded programs or modify existing programs in order to use the new functionality. Therefore, since the kiosk provider has incorporated the required logic in the name server 640B, there is little to do for the owner of the application (here the application file 175 on the server) to perform the new function.

6B is a block diagram of another embodiment of a kiosk control mechanism 640 using IPC 640I for mapping native APIs in browser mechanism 640A. That is, many or all of the kiosk control functions 620 are executed directly from the application file 500 by calling corresponding mapped native APIs in the browser mechanism 640A. Each mapped native API 640A communicates via IPC 6401 with an API mechanism 640B which in turn invokes the appropriate native API function 680 . Here, mapped native API 640A is a Java API program. Instead of having a Java API program written specifically for one or more native APIs 680, for each name server case at least one Java API program must have logic to control one or more native APIs 680. These Java API programs 640 are predefined and known to the application file 500.

In this embodiment, new devices and/or new functionality enabled by these devices are added through newly mapped native APIs (640A) provided in the browser mechanism 640A with their corresponding API mechanisms 640B. In this embodiment, the application file 500 needs to use direct calls to execute each of these new functions. Therefore, some or all of the logic for implementing new functions must be defined in the application file 500 . For example, the programmer of the application, indicating the application file 500 on the server, must code this logic, such as by writing a new Java applet.

Another embodiment of a kiosk control mechanism 640 is shown in FIG. 6C. In this embodiment, there is no IPC 640I, so the API mechanism 640B is incorporated into the browser mechanism 640A. Also, the name server functionality (also merged) is still used and combined with the communication API set to become a browser mechanism (640B, 640). In this embodiment, persistent state is lost because the native function 680 terminates once the application file 500 (including the applet) is "dropped" (no longer executed) by the browser. This embodiment is useful where persistent state is not required. For example, it does not include the case of kiosk equipment other than browser control of the screen.

FIG. 6D shows another embodiment of a kiosk control mechanism 640 . In this embodiment, the IPC 640I and API mechanisms 640B are completely absent. Here the applet directly calls API functions (640, 640A), which in turn directly calls native API functions 680. The API function 640 here is a Java API program. There is a Java API program written for one or more of the respective native APIs 680. In contrast, for the name server case, at least one Java API program must have the logic to control one or more local APIs 680 that are predefined and known to the application file 500. Continuity is also lost in this example.

FIG. 7 is a flowchart of an execution process 700 implemented by a kiosk.

The browser 160 first obtains 705 (an HTML) file 500 from the application file 175, and then the browser 160 interprets 710 the markup and the content of the application file 500. If the browser 160 does not encounter a native API call at 715, the browser processes 720 associated known actions to perform the flag. If the browser encounters a native API call 715, the browser will call 725 the relevant API function (640 or 640A). In a preferred embodiment, the browser mechanism 640A communicates 730 messages with the API mechanism 640B through an interprocess communication function 640I. Additionally, a message server is used as described above. The API mechanism 640B receives the message and calls 735 the associated native function 680 . The API mechanism 640B then communicates 740 messages with the browser mechanism 640A via the inter-process function 640I, based on the results of the native function execution.

The browser is controlled 750, either through screen input, embedded control program logic, or through external browser control functions 660 to request the next HTML document. Therefore, the browser can be treated as a local kiosk device. Thus, the browser can be controlled to load any specified HTML document from one or more servers on the network by accessing the known browser interface (API 681 ) using the native API 660 . Native API 660 is designed (see above) to allow embedded control program 620 to access browser interface 681 .

FIG. 8 is a flowchart of a server process 800 performed on one or more servers on a network. The server receives a request 810 from one or more kiosks over the network, the request identifying which one of the application files 175 the kiosk is selecting/accessing. The request also has the location of the kiosk 100 that is requesting/accessing the application file. Upon receiving the request, the server sends 820 a request for the application file 175 to the kiosk. Application files 175 can be preformed or dynamically generated by logic on the server.

In another embodiment, the kiosk sends the request 810 to the proxy server 195A. The proxy server 195A is generally located closer to the kiosk than the server 195. Additionally, proxy server 195A can be located on a computer within kiosk 100/200. For example, server 195 may be located in a first city, such as a headquarters location, while proxy server 195A is located in another city. On a local area network connected to the kiosk, the proxy server 195A can send requests to servers over the network 150 for as many or all of the application files 175 that the kiosk may require according to pre-plans. In this way, when a kiosk needs an application file, it can access the application file 175 faster and more reliably on the proxy server 195A. Additionally, the proxy server may request the application file 175 from the server 195 during "off peak" times on the network.

In other embodiments, the server (195, 195A) can be used to "push" information to one or more kiosks identified by the server 195. For example, at step 810, a request is initiated at server 195. This activation 810 may be caused for different reasons. For example, an application update may require one or more kiosks to be reconfigured with new application files 175 . In addition, at certain times of the day, there may be new configuration requirements, that is, news from different sources should be given at 5 pm every day, and the server can also "push" the information station to "check" periodically to determine which An information station needs maintenance.

A preferred implementation of this embodiment uses a "server push function" 685 that works on 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 interface 681. The server 195 sends a request to the server push function, causing the browser to request the specific application file 500 from the server 195 .

Fig. 9 is a block diagram showing the mechanism when the embedded control program uses ActiveX technology instead of Java. ActiveX control objects can be implemented in various programming languages, such as C++, VB or Java. An ActiveX object can be embedded in an HTML document, for example,

           
    <HTML>
     …

    <BODY>

    …

    <OBJECT

    ID="MyObject"

    CLASSID="CLSID: 8E27C92B-1264-101C-8A2F-
040224009C02＞

    <PARAM NAME="Version" VALUE="458752">

    ＜/OBJECT＞

    …

    ＜/BODY＞

    </HTML>

        

In this case, the browser must be ActiveX capable, that is, support ActiveX technology. In a preferred embodiment the browser is Microsoft Corporation's Internet Explorer.

When the application file 500 arrives at the browser 160, the HTML file is interpreted 910 according to its markup and content. As in the case of Java discussed above, the browser will execute 920 the non-API control function as before. The 930 API control function executed by the browser calls the API 940 directly. Similar to the case of Java, the first part of API 940A communicates with the second part of API 940B through inter-process communication function 940I (such as 640I), and API 940 calls local API function 680 in turn.

The difference between ActiveX and the aforementioned Java is that ActiveX can contain objects written in non-networking languages such as C++ or VB. Objects written in these languages are downloaded to the browser as executable code. Thus, such an object can do anything that a native program written in the same language can do. But like Java applets, it has no security restrictions. Thus, if the embedded control program 620 is like an ActiveX control written in a language other than Java, the API functions 940 can be placed anywhere in the kiosk. If Java is used in ActiveX objects, the previously discussed mechanisms must still be used.

In Figures 9A-9D, blocks with previously discussed numbers have functions as discussed above.

Figure 9A shows an embodiment of a kiosk control mechanism 940 using IPC and name server functions. The browser mechanism 940A is a native language API which need not be placed in the browser directory, but can be placed anywhere in the kiosk storage, such as in the kiosk system directory. However, the path (ie location) of the browser mechanism 940A must be known by the application file 500 .

FIG. 9B is a block diagram of another embodiment of a kiosk control mechanism 940 using IPC 640I with mapped native API. As shown in FIG. 6B , there is at least one browser mechanism 940 for one or more native APIs 680 .

Figure 9C shows another embodiment of a kiosk control mechanism 940 without IPC 640I. Here browser mechanism 940A can be placed as discussed in Figure 9A.

Figure 9D shows another embodiment of the kiosk control mechanism using ActiveX controls when the control is not implemented in Java. In this embodiment, since such an embedded ActiveX control can directly call native API 680, 940 is not needed at all. In this case, persistence of execution is lost.

Figure 10 shows another kiosk control mechanism using the so-called plug-in technology. In this case, the preferred embodiment uses Netscape's Navigator V3.0 or higher browser 160.

The control mechanism 1040 here comprises a browser mechanism (plug-in module and associated JavaWrapper) 1040A accessed by the kiosk control program (620) in the application file/file (175, 500): when accessed, the plug-in module 1040A Executed as part of the browser 160: the executing plug-in module 1040A in turn calls the inter-process communication function 1040I. The inter-process communication function (IPC) 1040I may be the same as the IPCs (640I, 940I) described above. IPC 1040I in turn communicates with API mechanism 1040B to call local API 680 . API mechanisms 1040B can be the same as those described above (640B, 940B).

In this embodiment, the browser mechanism 1040A is implemented by plug-in technology (refer to "Programming Netscape Plug-ins" by Zan Oliphant, Sams.net Publishing, 1996, ISBN1-57521-098-3). The plug-in technology uses native code modules, that is, realizes with C or C++ or similar programming languages. In addition, in a more preferred embodiment, the Java wrapper plug-in 1040A is placed in a special plug-in directory specified by the browser 160. When the HTML interpreter 610 encounters an embedded file (620), the embedded file identifies each plug-in 1040A based on the extension of the unique filename in the embedded file, also known as the Multipurpose Internet Email Extension (MIME) type, and the plug-in 1040A is dynamically loaded into the browser device 160.

The embedded kiosk control program (620) can be: 1) a JavaScript function 2) a Java applet, and/or 3) a predefined set of control scripts contained in a (MIME) file with only one extension.

When the browser 160 loads the plug-in module 1040A, the plug-in 1040A becomes available to the HTML document, ie the function in the plug-in (Plug_in function) becomes available to the embedded program (620). For example, to call a JavaScript function or a Java applet function. In doing so, the kiosk native API 680 can be controlled by any given embedded program 620 through one or more corresponding plug-ins 1040A. In other words, the plug-in module 1040A will call the IPC function 1040I to call the kiosk native API 680 through the corresponding API mechanism 1040B.

Three non-limiting examples are now given. Example 1 uses JavaScript functions as an embedded kiosk control program 1030 with a plug-in module 1040A providing messaging functionality

The application file 175 of the control program 1030 has the following form:

           
    <HTML>

    <HEAD>

    wait

    <\HEAD>

    <BODY>

    <BODY> <APPLET NAME="MY APPLET" SRC="MY
APPLET.CLASS"> etc.

    <EMBED NAME="MYEMBED" SRC="MSGPASS.MET">

    <SCRIPT LANGUAGE=JAVASCRIPT>

    wait

    MY APPLET.PluginAPI_SendMsg("CARDREADER_ON");

    wait

    <\SCRIPT>

    wait

    <\BODY>

    <\HTML>

    The Java applet "MY APPLET.Java" should contain code like:

    import PluginWrapper

    wait

    PluginAPI = new PluginWrapper();

    wait

    pubklic PluginAPI_SendMsg(String msg){

    wait

    PluginAPI. SendMsg(msg);

    wait

    }

    The Java wrapper file, PluginWrapper.java should include the following code:

    import netscape.plugin.Plugin;
				
<dp n="d30"/>
    wait

    public class PluginWrapper implements Plugin{

    wait

    public native void SendMsg(String msg);

    wait

    }

        

The plug-in module 1040A associated with the embedded control program 1030 above will provide the method SendMsg(), which is implemented in native language code like C++, for example.

Example 2 directly uses a Java applet as the kiosk control program 1030 embedded with a plug-in module 1040A providing messaging functionality.

The application file with control program 1030 is as follows:

           
    <HTML>

    <HEAD>

    wait

    <\HEAD>

    <BODY>

    <EMBED NAME="MYEMBED" SRC="MSGPASS.MET">

    <APPLET NAME="MYAPPLET" SRC="MYAPPLET.
CLASS">

    wait

    <\BODY>

    <\HTML>

    The code contained in the Java applet "MYAPPLET.Java" is:

    import PluginWrapper

    wait

    PluginAPI = new PluginWrapper();

    PluginAPI. SendMsg(msg);

    wait

    }
				
<dp n="d31"/>
    The Java wrapper file, PluginWrapper.Java will include the following code:

    import netscape.plugin.Plugin;

    wait

    public class PluginWrapper implements Plugin{

    wait

    public native void SendMsg(String msg);

    wait

    }

        

As in Example 1, the plug-in module 1040A associated with the above embedded control program will provide a method SendMsg(), implemented eg in native language code like C++.

Example 3 uses an embedded file 1030 containing a predefined set of control scripts and interprets and executes scripts to control an associated plug-in module 1040A of the kiosk native API 680 .

Application files 175 with embedded files 1030 may be of the form:

           
    <HTML>

    <HEAD>

    wait

    <\HEAD>

    <BODY>

    <EMBED NAME="MYEMBED" SRC="MSGPASS.MET">

    wait

    <\BODY>

    <\HTML>

    And the plug-in module 1040A can form the following code:

    NPError NP_LOADDS NPP_NEW(MPMIMEType pluginType,

    NPP pInstance,
    uint16mode,

    int16argc,

    char*argn,

    char*argv,
				
<dp n="d32"/>
    NPSaveData*saved)

    {

    if(pInstance==NULL)

      return NPERR_INVALID_INSTANCE_ERROR;

    KioskIPC*pKioskIPC = new KioskIPC(pInstance);

    pInstance->pdata = pKioskIPC;

    pKioskIPC->mode=mode;

    return NPERR_NO_ERROR;

    }

    NPERROR NP_LOADDS NPP_Destroy(NPP pInstance,

    NPSaveData*save)

    {

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

    if(pKioskIPC)

       {

       delete pKioskIPC;

       pInstance->pdata = NULL;

       }

    return NPERR_NO_ERROR;

    }

    void NP_LOADDS NPP_StreamAsFile(NPP pInstance,

    MPStream*stream, const char*fname)

    {

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

    if(pKioskIPC)

    pKioskIPC->InterpretFile(fhame);

    }

        

All three plug-in functions shown above complete the standard plug-in API provided by the Netscape browser 160. Other plug-in APIs provided by the browser 160 are not used here.

When the <embed> tag is interpreted by the HTML interpreter 610, the file 1030MSGPASS.MET is downloaded to the local disk and the corresponding plug-in module 1040A is loaded into the browser 160 if it has not already been loaded. The browser 160 will automatically call the plug-in API NPP_New () to create a plug-in instance, and call the plug-in API NPPStreamAsFile () with the downloaded file name to execute the file. When necessary, the browser 160 will call the plug-in API NPP_Destroy () to invalidate the plug-in instance.

Class KioskIPC and function InterPretFile() can be implemented in native language like C++ to interpret and execute scripts predefined in embedded files. In this sense, there is no restriction on what kind of script is, as long as the function InterPretFile( ) is implemented so that the script can be analyzed and the required performance can be performed with reasonable performance. Below is an example.

In the embedded file, the script looks like this:

           
    (begiuning of MSGPASS.MET)

    wait

    SendMessage: OpenCardReader

    wait

    (end of MSGPASS.MET)

    The function InterpretFile() includes the code as:

    (beginning of InterpretFile())

    wait

    switch(Command){

    wait

    case "SendMessage":

       SendMsg(Msg);

       break;

    wait

    (end of InterpretFile()).

        

In order to achieve some interactive control of functions, in the browser 160 window, the plug-in module 1040A can also create certain buttons. For example, it can create a button "Print" and wait for it to be touched or clicked in order to call the SendMsg() function to send the message "PrintCurrentPage". The <embed> tag can also include a predefined set of parameters for controlling the plug-in module 1040A according to the execution of the plug-in module 1040A. For further information on how to use the <embed> tag and how to implement plug-in modules, please refer to "HTML Publishing for Netscape" (Stuart Harris and Gayle Kidder ISBN 1-56604-288-7) and Zan Oliphant's reference book above.

Claims (102)

1. a server comprises being connected to the device on the network, is used for reconfiguring the electronic information station with one or more outside input-output apparatus and related driver programs through network, and said server is characterised in that also and comprises:

Be used to provide the device of at least one config set, config set comprises one or more files of the application that definition will carry out at information station, and can select at least one of a subset of driver to embed control function at information station;

Be used for from linking the device of the information station reception configuring request on the network; And

Be used for responding said request and at network said at least one config set sent to information station, make the subset of driver go to control relative external equipment subset, thereby the device of the application that will carry out at information station of described config set definition is carried out at the configuration information station.

2. according to claim 1 server, the configuring request here is from the information station that will be configured.

3. according to claim 1 server, the configuring request is here acted on behalf of computer from one.

4. according to claim 1 server, at least one config set comprises any in following here: Remote Device Control, remote message show, file transmits, and agency/client works in coordination with.

5. according to claim 1 server, at least one embeds control function and comprises a system supervisor here, is used for determining the mode of operation of one or more local informations station function of information station.

6. according to claim 5 server, the mode of operation here be used for to be determined following any or a plurality of: the maintenance that one or more external equipments are required, the maintenance history of one or more external equipments, which application file to respond one or more requests, reaches the market information of relevant one or more kiosk user in the network service.

7. according to claim 5 or 6 server, the mode of operation here determines which config set server will serve information station at network with.

8. according to claim 1 server, at least one config set comprises the one or more html files with zero or a plurality of hypertext part here.

9. according to claim 1 server, the application here is in the customized application of information station for customization.

10. according to claim 1 server, the application here provides the access to the internet by said at least one config set configuration information station.

11. server according to claim 10 to the access of the internet server by one or more appointments, provides communication linkage here between one or more users.

12. server according to claim 1, the application here comprise in following any or a plurality of: the search of call, Email, video conference, facsimile transmission, training session, network information and collaborative based on Web.

13. server according to claim 1 is on the information station that is applied in said at least one config set configuration here, for the user provides information.

14. server according to claim 1, at least one embedding control function can make information station go for and ask one or more config sets here.

15. the method that the server of linking one or more electronic information station by network is operated, each information station has one or more outside input-output apparatus and related driver programs, and said method comprises the steps:

At least one config set is provided, and config set comprises one or more files of the application that definition will carry out at information station, and can select at least one of a subset of driver to embed control function at information station;

Receive configuring request from the information station that is connected on the network; And

Respond said request and send said at least one config set to information station at network, make the subset of driver go to control relative external equipment subset, thus the application that will carry out at information station that the configuration information station carries out that described config set defines.

16. an electronic information station comprises:

Be used for device connected to the network;

One or more outside input-output apparatus and related driver programs device;

Be used for by the device of network from least one config set of server access, config set comprises one or more files of the application that definition will carry out at information station and comprises and embed the control function; And

Carry out to embed the device of control function, with the subset of selecting the driver device and with subset communication, with control relevant external equipment therewith, thereby the corresponding application that will carry out at information station of described config set definition is carried out at the configuration information station.

17. information station according to claim 16, the access means here and actuating unit are provided by the browser on the information station.

18. information station according to claim 17, one or more input-output apparatus here comprise in following any or a plurality of: printer, medium read in device, media recorder, media dispenser, Automatic Teller Machine, scanner, verifier (deposer), electronic pen, card issuing device, cheque punch, printer, ticket distribution device, CRT, keyboard, touch-screen, video camera, human body sensor,, telephone set, illumination, microphone, loudspeaker, cd-rom player, Genius mouse and memory.

19. according to claim 17 or 18 information station, also comprise a display, the Web page or leaf that browser provides on it is as a part of using.

20. information station according to claim 19, the Web page or leaf here comprise in the following visual properties any or a plurality of: hyperlink, be the hyperlink, icon, menu, input text area, data input area, advertisement, notice, news broadcast, weather forecast of the one or more additional configurations collection of request, and the explanation of general information.

21. it is the application selected of being selected by one or more selection functions that information station according to claim 16, the information station are here used.

22. it is to use the default application of reshuffling with the irrelevant config set of selection function that information station according to claim 21, the information station are here used.

23. according to claim 21 or 22 information station, the selection function here one or more time cycles occur at information station.

24. information station according to claim 21, here select to use hobby according to the user, organize graphic user interface customization.

25. information station according to claim 21, the agency who uses by also being connected on the network that selects here selects.

26. information station according to claim 21, here select to use comprise in following any: Remote Device Control, remote message show that file transmits and agency/client works in coordination with.

27. information station according to claim 16 also comprises a system supervisor, to determine the mode of operation of one or more information station equipment.

28. information station according to claim 27, the mode of operation here be used for to be determined following any or a plurality of: required maintenance, the maintenance history of one or more input-output apparatus, which application file of one or more input-output apparatus is used for configuration information station, and relevant user's market information.

29. information station according to claim 17, the browser here receives request, determines that those information station functions and equipment installs, in order to determine how to operate each device driver.

30. information station according to claim 16, the file here are the html files with zero or a plurality of hypertext part.

31. according to claim 21 or 22 information station, the application here is the customized application for customization.

32. according to claim 21 or 22 information station, the application program here provides the access to the internet.

33. information station according to claim 32 here to the access of internet, provides the server by one or more appointments, the communication linkage between the first and second users.

34. according to claim 21 or 22 information station, the application here comprise in following any or a plurality of: call, Email, video conference, facsimile transmission, training session, network information search, and collaborative based on Web.

35. information station according to claim 18, the subset of devices here comprise printer and use configure printer to print any in following: receipt, check, Web page or leaf, order form, ticket, passport and form.

36. information station according to claim 18, the subset of devices here comprise in following any or a plurality of: microphone, loudspeaker, and through using the telephone set of the public telephone that is configured as.

37. information station according to claim 18, the subset of devices here comprise microphone, loudspeaker, reach the video conferencing system that is configured as video conference terminal by config set.

38. information station according to claim 18, the subset of devices here comprise by the video camera of using configuration, to take the one or more photos in following: the landscape around user, the information station, and literary composition gear.

39. information station according to claim 18, the subset of devices here comprises the media writer of writing storage medium, writes in following any and use this media writer of configuration: music, software, text, figure, text, and multimedia messages.

40. information station according to claim 18, the subset of devices here comprise that the medium of energy read record medium reads in device, the medium here reads in device and is disposed by config set, with the information that records on the input recording medium.

41. information station according to claim 16, the embedding control function here is Java Applet.

42. information station according to claim 41, the Java Applet here is by the device A PI communication of interprocess communication with the one or more local drivers of control.

43. information station according to claim 16, one or more embedding control functions here are ActiveX control.

44. information station according to claim 16, one or more embedding control functions here are plug-in unit control.

45. an information station comprises:

One or more input-output apparatus;

The local program device of one or more each input-output apparatus of driving;

One browser, by one or more network connections, get the one or more config sets with one or more files from network, one or more config sets have at least one and embed the control function, one or more config sets are relevant in the selected application of information station with the user, embed the control function and select the local subset of one or more local programs, and with local subset communication, make local program in the local subset drive the local subset of one or more local informations station function, so that the information station that is configured is carried out the user in the selected application of information station.

46. information station according to claim 45, the local information station function here be comprise following in any or a plurality of input-output apparatus: printer, medium read in device, media recorder, media dispenser, Automatic Teller Machine, scanner, verifier (deposer), electronic pen, card issuing device, cheque punch, printer, ticket distribution device, CRT, keyboard, touch-screen, video camera, human body sensor,, telephone set, illumination, microphone, loudspeaker, cd-rom player, Genius mouse and memory.

47. information station according to claim 45 also comprises a display, the Web page or leaf that browser provides on it is as a part of using.

48. information station according to claim 47, the Web page or leaf here be comprise following in any form: financial application, personal information situation, application, tax position, mortgage application, service request, education form, administration form, shopping request, and the condition of stock.

49. information station according to claim 47, the Web page or leaf here comprise in the following visual properties any or a plurality of: hyperlink, be the hyperlink, icon, menu, input text area, data input area, advertisement, notice, news broadcast, weather forecast of one or more the second config sets of request, and the explanation of general information.

50. information station according to claim 45, one or more application here are the default application by one or more config set configurations irrelevant with selection function.

51. information station according to claim 45, one or more application here are by one or more application selected with selecting to use relevant selection function selection.

52. 1 information station according to claim 5, the selection function here comprise in following any or a plurality of: the soft-key button on touch-screen, icon, hypertext link, the display, sensor, button, sound and voice control.

53. 1 information station according to claim 5, the selection function here one or more time cycles on information station occur.

54. 1 information station according to claim 5, selecting here use according to user's hobby customization organize graphic user interface.

55. 1 information station according to claim 5, here select to use agent selection by also linking on the network.

56. 1 information station according to claim 5, here select to use comprise in following any: Remote Device Control, remote message show that file transmits, and agency/client works in coordination with.

57. information station according to claim 45 also comprises a system supervisor here, to determine the mode of operation of one or more information station local functions.

58. 7 information station according to claim 5, the mode of operation here are used for determining following any or a plurality of: required maintenance, the maintenance history of one or more input-output apparatus, that application file of one or more input-output apparatus is used for configuration information station, and relevant user's market information.

59. information station according to claim 45, the browser here receives request, determines that those information station functions install, in order to determine how to operate corresponding device drives.

60. information station according to claim 45, the network here may be one or more in following: the net that internet, WWW, Intranet, telephone network, cable television network, ISDN net, collaboration network, government's net, education network and one or more retailer use.

61. information station according to claim 45, the file here are the html files with zero or a plurality of hypertext part.

62. information station according to claim 45, the application here are the customized application for customization.

63. information station according to claim 45, the application program here is access the Internet.

64. 3 information station according to claim 6, the information station here is to user's charge of access the Internet.

65. 3 information station here to the access of internet, provides the server by one or more appointments according to claim 6, the communication linkage between one or more the second users.

66. 5 information station according to claim 6, the communication chain here comprise in following any or a plurality of: voice, video, Email, data, shared web page or leaf.

67. information station according to claim 45, the application here is communications applications.

68. 7 information station according to claim 6, the communications applications here comprise in following any or a plurality of: the search of call, Email, video conference, facsimile transmission, training session, network information and collaborative based on Web.

69. being services, information station according to claim 45, the application here use.

70. 9 information station according to claim 6, the service here use comprise in following any or a plurality of: advertisement, service charge and service request.

71. information station according to claim 45, the application here are to provide information at tangible medium.

72. information station according to claim 45, the configuration of the application here display provides the Web that comprises multimedia messages page or leaf, these information comprise in following any or a plurality of: the image of inventory, menu, seat arrangement, map, one or more soft key, form, advertisement, product.

73. information station according to claim 45, the subset of devices here comprises printer, and uses configure printer to print any in following: receipt, check, Web page or leaf, order form, ticket, passport and form.

74. information station according to claim 45, the subset of devices here comprise in following any or a plurality of: microphone, loudspeaker, and by the telephone set of using the public telephone that is configured as.

75. information station according to claim 45, the subset of devices here comprise microphone, loudspeaker, reach the video conferencing system that is configured as video conference terminal by config set.

76. information station according to claim 45, the subset of devices here comprise through using the video camera of configuration, to take the one or more photos in following: the landscape around user, the information station, and document.

77. information station according to claim 45, the subset of devices here comprises the media writer of writing storage medium, and uses the collocating medium write device to write any in following: music, software, text, figure, teaching material, and multimedia messages.

78. information station according to claim 45, the subset of devices here comprise that the medium of energy read record medium reads in device, the medium here reads in device and is disposed by config set, with the information that records on the input recording medium.

79. 8 information station according to claim 7, the recording medium here are in following any: the memory on the electronic card, the floppy disk of computer, tape, CDROM, and memory devices.

80. information station according to claim 45, the control program here is Java Applet.

81. 0 information station according to claim 8, one or more drivers here have a java applet, by the device A PI communication of interprocess communication with the one or more local drivers of control.

82. information station according to claim 45, one or more embedding control functions here are ActiveX control.

83. information station according to claim 45, one or more embedding control functions here are plug-in unit control.

84. a server comprises:

One or more connections to network connect one or more requests that receive by this;

Have one or more files and have at least one or more config sets that embed the control function, one or more config sets are relevant in the selected application of information station with the user, embed the control function and can select the driving subset of one or more drivers, and with driving subset communication, make driver control the subset of devices of one or more local informations station function, carry out the user in the selected application of information station to dispose one or more information stations.

85. 4 server according to claim 8, the request here is from one or more information stations that will be configured.

86. 4 server according to claim 8, the request here is from an agency computer.

87. 4 server according to claim 8, the config set here comprise in following any: Remote Device Control, remote message show, file transmits and agency/client works in coordination with.

88. 4 server according to claim 8, one or more embeddings control functions here are system supervisors, are used for determining the mode of operation of one or more local informations station function of one or more information stations.

89. 8 server according to claim 8, the mode of operation here are used for determining following any or a plurality of: the maintenance history of the required maintenance of one or more external equipments, one or more external equipments, those application files in the network service to respond one or more requests, and the market information of relevant one or more kiosk user.

90. 8 server according to claim 8, the mode of operation here are used for determining that server will serve that config set on the network.

91. 4 server according to claim 8, the config set here comprise the one or more html files with zero or a plurality of hypertext part.

92. 4 server according to claim 8, the application here is the customized application for customization.

93. 4 server according to claim 8, the application program here are by the one or more information station access the Internet by the config set configuration.

94. 3 server according to claim 9, the access of internet here provides the server by one or more appointments, the communication linkage between one or more the second users.

95. 4 server according to claim 8, the application here is communications applications.

96. 5 server according to claim 9, the communications applications here comprise in following any or a plurality of: the search of call, Email, video conference, facsimile transmission, training session, network information and collaborative based on Web.

97. being services, 4 server according to claim 8, the application here use.

98. 7 server according to claim 9, the service here use comprise provide in following any or a plurality of: advertisement, service and service charge.

99. 4 server according to claim 8, the application here are to use the information station of config set configuration to provide information as the user.

100. 4 server according to claim 8, one or more embeddings control functions here are one or more information stations are gone for ask one or more config sets.

101. a method of being carried out by the server on the network comprises the following steps:

Receive a request from one or more information stations of linking on the network;

Send one or more config sets to information station, config set has one or more files and at least one embeds the control function, one or more config sets are that the user is selected relevant with using at information station, embedding the control function can select the driving subset of one or more drivers and with the communication of driving subset, make the driver subset of devices configure information station of one or more local informations station function carry out the user in the selected application of information station.

102. configuration is linked on the network and is had one or more outside input-output apparatus and the method at the electronic information station that reaches related driver programs, comprises the steps:

From at least one config set of server access, config set comprises one or more files of the application that definition will realize at information station, and comprises that embeds a control function by network; And

Carry out embedding the control function, with the subset of selection driver and with subset communication, to control relevant therewith external equipment

Thereby the configuration information station realizes using accordingly with config set.

Images