INTERACTIVE MULTI-MEDIA PAYPHONE SYSTEM COMBINING NETWORKING AND TELEPHONY TECHNOLOGY
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates in general to the fields of telephony and networking and more particularly to a payphone system combining networking and telephony technology.
2. Description of the Related Art Current society, in both the business and personal environments, has a high expectation of and demand for information technology services. Dependence on telephones, facsimile machines, electronic mail ("e-mail"), the World Wide Web (the "web"), twenty-four hour news broadcasts, and myriad other information sources is becoming increasingly common. Many factors, including technological, societal, and political, have contributed to the burgeoning supply of services and products. Some of the technological factors include digital technology, miniaturization of electronics, increased power storage in batteries, and improvements in heat dissipation. These technological factors have also allowed products to become progressively smaller, such as cellular telephones, laptop computers, and palmtop devices.
Communications products, however, have also continued to be relatively specialized. The examples of cell phones and computers demonstrate this situation. Products have integrated multiple services where possible, such as combination facsimile/scanner/printer machines and computers that allow e-mail access as well as web browsing. However, the typical communications user, for example at a home or a business office, requires a variety of separate devices including a facsimile machine, a computer for e-mail access and data transfer, and a telephone.
This persistent condition has many drawbacks, such as increased expense to acquire each of the separate devices and increased difficulty of use due to the increased numbers of user interfaces which must be learned and used. There are also other, less obvious, costs such as the dislocation of large numbers of people who do not have access to these communications services, due perhaps to the prohibitive expense. Additionally, as society becomes increasingly more mobile, the need for access to these, and other, forms of communication also increases. The present invention is directed to overcoming or at least reducing the effects of one or more of the problems set forth above.
SUMMARY OF THE INVENTION
Embodiments of the present invention overcome or at least reduce the effects of some of the problems in the prior art by combining a public payphone with a variety of services. Embodiments combine a payphone with (i) a separate data network for Internet access, e-commerce, e-mail services, (ii) a private network with controlled content targeted for specific payphones, the content including applications with tourist related information, or (iii) e-business services which utilize either the phone network or a separate data network. Embodiments of the payphone also allow for greatly increased options in payment, including myriad smart cards, coins, currency, credit cards, and other magnetically striped cards.
An embodiment of the present invention also incorporates a dedicated service provider to manage the payphones which are connected to it on a secure, private network. The service provider controls the content of the payphones and can push content or download it.
Briefly, in accordance with one aspect of the present invention, there is provided a payphone system including a voice interface, a payment acceptor, and a user interface. The voice interface is adapted to provide voice reception or voice transmission for communication over a voice network. The payment acceptor is coupled to the voice interface. The user interface is adapted to interface to a data network and to the voice network.
Briefly, in accordance with another aspect of the present invention, there is provided a method of providing services. The method includes providing a voice interface which is adapted to provide voice reception or voice transmission for communication over a voice network. The method also includes providing a payment acceptor which is coupled to the voice interface, and providing a user interface which is adapted to interface to a data network and to the voice network.
Briefly, in accordance with another aspect of the present invention, there is provided a payphone system including a first payphone, a second payphone, and a service provider. Each of the payphones includes a voice interface, a payment acceptor, and a user interface. The service provider is adapted to be coupled to each of the payphones through a data network, to provide content to each of the payphones, to provide access to an Internet, and to process financial transactions.
Briefly, in accordance with another aspect of the present invention, there is provided a payphone system including a mechanism for interfacing a user to a voice network, a mechanism for accepting payment, and a mechanism for interfacing the user to a data network.
Briefly, in accordance with another aspect of the present invention, there is provided a method of providing services. The method includes a step for achieving the result of communicating over a voice network, a step for achieving the result of accepting payment, and a step for achieving the result of communicating over a data network.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows a front view of a payphone according to an embodiment of the present invention. FIG. 2 shows a software component model of a payphone.
FIG. 3 shows an architecture of a payphone system.
FIG. 4 shows an interconnection of components in a payphone system and components outside of the system.
FIG. 5 shows a management system for a service provider.
FIG. 6 shows a system of interconnected content servers. FIG. 7 shows a remote management system architecture.
FIG. 8 shows various ICONS used in a Datajack service.
FIG. 9 shows a dialing keypad screen.
FIG. 10 shows a rate card screen for a Datajack service.
FIG. 11 shows a service help screen for a Datajack service. FIG. 12 shows a screen informing users to replace a handset.
FIG. 13 shows a payment screen
FIG. 14 shows a screen prompting the user to touch the screen.
FIG. 15 shows a screen with instructions for paying with a credit card.
FIG. 16 shows a screen used during credit card validation. FIG. 17 shows a screen instructing a user to connect to a Datajack.
FIG. 18 shows a screen prompting a user to start dialing.
FIG. 19 shows a screen indicating that a Datajack service is in use.
FIG. 20 shows a screen indicating that a connection has failed.
FIG. 21 shows a screen containing charge information. FIG. 22 shows a screen indicating that there is no charge.
FIG. 23 shows a content distribution screen.
FIG. 24 shows a screen for entering a remote command.
FIG. 25 shows a screen with the output of the remote command.
FIG. 26 shows a screen for performing an integrity check. FIG. 27 shows a screen for checking the status of background jobs.
FIG. 28 shows a screen with the output of the status check.
FIG. 29 shows a flow process for loading news data.
FIG. 30 shows a sample screen with a power pole.
FIG. 31 shows another sample screen with a power pole. FIG. 32 shows a screen with advertising.
FIG. 33 shows a screen with a virtual keyboard.
FIG. 34 shows a design presentation for a service layout.
FIG. 35 shows an advertisement rotation flow.
FIGS. 36-37 show a call flow.
FIG. 38 shows various views of an exterior of a payphone.
FIG. 39 shows the interconnection of certain components of a payphone.
DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS
1. Brief Overview
The present invention provides, among other things, a payphone system which combines both telephony and networking technologies and offers the user a single point of contact for phone services as well as data and networking services. Embodiments of the present invention further provide a medium for building additional services and products which will be available to the user, thus producing a combination telephone, information kiosk, and service gateway. One embodiment of the present invention provides the user with access to a telephone as well as e-business applications such as facsimile transmission; e-mail sending and retrieval; printing using a hard-wired, infra-red, or other type of connection; scanning; and datajack (that is, data port) connectivity for data transfer using a laptop, palmtop, or other device. One embodiment additionally provides further services such as web browsing, electronic commerce ("e-commerce"), a guide to local attractions for tourists, a restaurant guide, a system for making hotel reservations, news broadcasts, and voting or polling services. One embodiment additionally provides information of interest such as a directory of events and shows, information on airports, airlines, and hotels, information on maps and directions, and information on public transportation. One embodiment additionally provides video-conferencing capabilities.
These developments significantly advance the state of the art in payphones and public telephones, collectively "payphones. " Payphones have remained relatively static, compared to the advances in other communications fields. This lack of development has been due, in part, to a variety of constraints imposed by, for example, requiring payment, having a suitably durable design, and achieving a design and function that would appeal to mass consumers and also be adaptable in order to maintain that appeal. An embodiment of the present invention overcomes these longstanding obstacles with a private, secure network connecting a series of payphones, a service provider which controls content that is pushed to the machines or downloaded to them, accepting multiple options for payment, and a
modular software and hardware design allowing continued development of embodiments and tailoring them to particular applications.
In addition to networking technology and telephony technology, the present invention further combines, as indicated by the partial list of services above, internet technology, computer technology, information technology ("IT"), multi-media, point-of- sale ("POS") capability, advances in advertising practices, and advanced user-interfaces. The IT includes, for example, the integration of and communication with databases, a client-server architecture and functionality, and a management interface. The advertising capability includes, for example, traditional forms, interactive advertisements, web advertising, and targeted placement of advertisements. One embodiment of the present invention includes multi-lingual support. The user interface employs a unique command pole design featuring icons and a rolling interface in which the command pole rotates in three-dimensions .
2. Physical Layout of a Payphone Embodiment The payphone of the present embodiment will be interchangeably referred to as a payphone or as a Power Phone. FIGS. 1 and 38 show a payphone 10 according to various embodiments of the present invention. The payphone 10 includes a phone handset 18 attached to a cord 20 which is connected to the main body 22. The handset 18 serves as the voice interface for the user and is adapted to provide voice reception and voice transmission for communication over a voice network. Additional embodiments can utilize other voice interfaces, such as for example, a microphone, a speaker, a hard-wired headset including either a microphone or speaker, and a wireless headset. The voice interface need not provide for both voice reception and voice transmission in all embodiments
The user also communicates with the payphone 10 through the touch screen 14. The touch screen 14 serves as a user interface and is adapted to interface to a data network and to the voice network. The touch screen 14 may provide access to the data network with, for example, a selection providing for an Internet connection. The touch screen 14 may provide access to the voice network with, for example, a keypad used for dialing a phone number or a number directory allowing a number to be searched for and automatically dialed. A touch screen 14 is further described in Appendix D.
Additional embodiments can utilize other user interfaces, such as for example, a standard key pad such as are found on common telephones, a display screen that is not a
touch screen and can utilize a mouse or track ball, a speaker, a microphone, a microphone coupled to a voice recognition program, a data port, a scanner, a facsimile machine, and a printer. In one embodiment, a scanner provides facsimile service as well as scanning service. The user interface may also serve as the voice interface, such as in an embodiment where a handset can be used with regular telephone calls over the voice network or with calls placed over the data network such as with Internet phone applications. Additionally, a voice recognition program could be used to accept commands over the handset, or another microphone, for selecting various services offered on the payphone. As just suggested, in some embodiments the user interface may serve as an interface to services offered on the payphone and need not necessarily serve as an interface to the data network. The user interface of the payphone 10 also includes a standard data jack 24 with an RJ11 or an RJ45 socket, indicated in the lower right corner of FIGS. 1 and 38, allowing a data connection. Appendix A contains a detailed description of a Datajack service and a user interface to the service. The payphone 10 can be equipped with and interfaced to a scanner (not shown), a printer (not shown), a contactless smart card reader (not shown), and a variety of other peripherals as required or desired.
The payphone 10 also contains multiple payment acceptors, including a coin slot 12 and a magnetic card reader 16 which both allow payment. Additional embodiments can utilize other payment acceptors, such as for example, (i) a paper currency acceptor, (ii) a smart card reader supporting asynchronous processor based technologies, disposable memory card technologies such as the Eurochip standard from Seimens or the T2G standard from Phillips, and/or contactless technologies, (iii) an account-based calling card reader such as a go-card, (iv) a credit card reader, (v) a magnetic-striped card reader, (vi) a talk- talk smart card ("TTSC") reader, (vii) a debit card reader, and (viii) a calling card reader. The voice interface and/or the user interface can also serve as the payment acceptor by allowing the user, for example, to type in a credit card number with a keypad or touch screen, to speak a credit card number, or to type in or speak digits or a selection for choosing third party billing or collect calling.
3. Architecture of a Payphone Embodiment Referring to FIG. 39, there is shown a block diagram 390 showing the main components for an embodiment of the present invention. The block diagram 390 shows an interconnection between a hard drive 391, a card reader 16, a CPU board 393, a handset
18, a telephony board 395, an MPEG decoder 396, an LCD (liquid crystal display) display and touch screen 14, a line simulator 398, a datajack 24, and an ISA bus 399.
The architecture of the system is preferably designed around open standards. One embodiment of the present invention utilizes the Internet Protocol ("IP") standard, the hyper-text markup language ("HTML"), the Java language, the Open Database Connectivity Standard ("ODBC"), the ISO 7811 and 7812 standards for magnetic stripe cards from the International Standards Organization ("ISO"), and the ISO 7816 standard for integrated circuit ("IC") cards. This provides a number of benefits such as, for example, allowing an increased variety of services to be offered by third parties. The supported ISO card standards allow processing of most of the current Visa and MasterCard cards. Further, with ODBC, the system can connect to various different databases, such as for example, SQL, Foxpro, and Access. Appendix B, which describes the data updating process for an application, contains details of the required database conformity.
The software platform of the payphone preferably includes a browser technology such as that developed by Microsoft, and various ActiveX control modules. A payphone browser can serve as the user interface to a majority of the functions and services provided by the payphone. FIG. 2 shows a software model for an embodiment of the present invention. A Microsoft Windows NT 4.0 operating system 28 is preferably used. The payphone browser 21 receives HTML data 23, for example over a data network. The browser 21 also interfaces to the control modules 25 for the various hardware devices or services. The control modules 25 preferably include ActiveX control files, and use a generic interface to the browser 21. Appendix E contains a further description of an ActiveX control file for an embodiment of the present invention, and Appendix F contains a description of the software flow for several additional features. The browser 21 further interfaces to the various content stored on a storage medium
26, which it receives, for example, over a data network. The storage medium 26 is preferably a digital storage medium, including without limitation a magnetic or optical hard disk and a Bernoulli drive, but any suitable storage medium can be used. The content can be secured if desired, preferably using a Secured Socket Layer ("SSL") protocol 27 and DES encryption. The content which the browser 21 displays may be pushed to the payphone or stored locally on the payphone in the storage medium 26. Pushing or storing data both allow targeted advertising or promotion of services. Pushing data further allows
improved performance due to updating the information at a single location. The payphone also preferably allows a remote interface to monitor activity on the payphone, to upload data from the payphone or to download data to the payphone, and to perform functions, for example integrity checks of data, directly on the payphone.
4. Description of Networks
Preferably, the payphone is connected to both a voice network and a data network. The voice network is typically used for telephone communication and preferably utilizes the public switched telephone network ("PSTN"), but other analog networks can also be used, whether public or private. Additionally, digital networks, including an Integrated Services Digital Network ("ISDN") and the Internet, can be employed. In particular, services such as Internet phone applications can be used for voice communications over the Internet. The voice network is also used for data, as happens, for example, with facsimile transmissions or data file transfer over a phone line.
The data network is preferably a private, secure payphone network with a service provider connected thereto. In other embodiments, however, the data network can be the PSTN, an ISDN network, or any other public or private network. In some embodiments, the voice network and the data network will be the same network and all services, including phone, fax, e-commerce, web surfing, etc., will be communicated through a single network. Additionally, either the voice network or the data network can employ any variety of communications media, standards, transmission technology, and topology, including for example, satellite, radio frequency, cellular, line-of-sight, point-to-point, circuit-switching, packet-switching, leased line, shared line, secured, non-secured, PSTN, DDS circuit, magnetic, optical, magnetic-optical, fiber optic, coaxial cable, token rings, local area networks ("LANs"), metropolitan area networks ("MANs"), and wide area networks ("WANs").
The data network 34 of the present embodiment will also be interchangeably referred to as a Power Phone Network or PPN. Referring to FIG. 3, there are shown three clusters 58, 60, 62 of payphones 10 connected to a PowerPhone Operations Center or service provider 46 through data networks 34. As illustrated, a data network 34 may be a direct connection to the service provider 46, such as those connecting the two payphones 10 in cluster 62. The data network 34 may also connect to a local area network ("LAN"),
such as those shown in clusters 58, 60, that interconnects multiple payphones 10. The data network 34 can also be used to refer to the entire network between the payphone 10 and the service provider 46, thus possibly including a LAN, a router, and other devices. In FIG. 3, cluster 58 is connected to the service provider 46 through an El line, cluster 60 is connected to the service provider 46 through a 64k ISDN line, and the payphones 10 in cluster 62 are each connected to the service provider 46 through separate dedicated 64k lines.
FIG. 3 thus shows two of the principal methods of implementing a data network 34. The first is to use a point-to-point wide area network ("WAN") card from each payphone 10 back to the service provider 46, as in cluster 62. The second is to use a LAN to interconnect multiple payphones 10, using a LAN card, and then to connect the LAN to the service provider 46 using an additional connection, as shown in clusters 58, 60.
Referring to FIG. 4, there is shown a system 30 in which a payphone 10 can be utilized. The payphone 10 is connected to a public switched telephone network 32 for making phone calls, transmitting facsimiles, or performing modem communication, for example. The payphone 10 is also connected to a data network 34 for utilizing data and networking services. As will be discussed more fully below, the data network 34 connects to a service provider 46 which acts as a gateway for the data and networking services. The service provider 46 can be connected to an extranet 36 for providing access to a customer 42. The service provider 46 can also connect to the Internet 38 for providing access to, for example, a web site 40 and a customer Virtual Private Network ("VPN") 44.
5. Service Provider
The service provider 46 of the present embodiment will be interchangeably referred to as a Point of Presence ("POP"). As described in connection with FIG. 3, the service provider 46 is connected to the data network 34, along with the payphones 10. The service provider 46 provides a variety of important functions, including storing information and content, receiving and integrating content revisions, delivering content and services to the payphones 10, processing transactions from users using the payphones 10, providing monitoring capability so that the payphones 10 can be monitored, providing Internet access, and performing encryption/decryption as required. These and other functions will be described below with reference to FIG. 5. a. Shadow System
A content provider (not shown) can connect to the service provider 46 through the Internet or an extranet, as shown in FIG. 4, or any other suitable connection such as a direct telephone line connection or a dedicated network. Preferably, the content submission is an automatic data upload from content providers. The content provider submits its content to a shadow content system 66, or buffering area, for a content administrator (not shown) to check/ verify the content. The content administrator will then do a migration which copies the verified content to a content system 68, or production server, where content distribution will take place to deliver the content to each payphone 10. Appendices B and C describe content submission procedures for particular applications. The shadow content system 66 also provides a separate development and test environment for content integration. This environment allows the content administrator to integrate content without interfering with the operational part of the system, and to do this before the content is distributed and downloaded. The environment also includes, without limitation, the following: (i) standard tools for the creation of content that fits within the style guide for payphone services, (ii) tools to check that all content, including content provided by other parties, fits within the specifications for the payphone services and is executed on each payphone, and (iii) a tool to update the content. b. Content System
The content system 68 stores the content that is to be provided to the payphones 10 either by downloading or pushing the content. As shown in FIG. 6, the content system 66 may contain a system of replicated content servers 76 which can provide content to separate groups of payphones. Not all payphones or groups of payphones on a given data network 34 need to have the same content, thus allowing targeted content delivery. Note that certain data or content can be stored directly on a payphone 10, whereas other data will be stored at the service provider 46 and the service provider 46 will send the data to the payphone 10. Static information and/or frequently accessed information is preferably stored locally on a payphone hard disk to minimize the loading on the network traffic whereas dynamic information is preferably kept in a central server. c. Financial Transaction System The financial transaction system 74 provides secured socket layers and encryption for secure communications link capability to ensure security of financial information, credit card numbers, etc. A Certificate Server (not shown) is preferably utilized for this function.
The financial transaction system 74 further contains the capabilities to communicate with financial networks 71 to clear the transactions, such as by connecting to a card clearing institute 35 (see FIG. 3), also known as a credit card clearinghouse. Additionally, the financial transaction system 74 can also communicate with the actual vendor involved in a transaction through the Internet 38, an extranet 36, or another suitable connection. Each vendor may have different levels of communication required, some desiring real-time updating of transactions for inventory control and requiring a dedicated line, and others desiring only a daily activity report sent through the Internet 38 using encrypted e-mail. d. Internet Server The Internet server 72 enables Internet and web access. This access is used by myriad entities in the payphone system, including at times the user from a payphone 10, the financial transaction system 74 to communicate with a vendor, content providers to upload content, and remote individuals to monitor payphones 10 (described below). e. Billing System A billing system (not shown) is preferably used to track the various billing requirements. Two areas in particular are record intensive. The first is the advertising content on the payphones 10. Common billing models require accurate records of what content is installed on each payphone 10, when it was installed, when it was removed, the amount of time it was displayed on the screen, the number of user inquiries it generated (if appropriate), and various other indicators of the value of the advertising. The second area is billing for transactions on the payphones 10. Typically, the financial transaction system 74 enables pass-through billing to the user and generates reports on sales for the vendors. Alternate billing models, however, require the service provider 46 to track the sales and bill the users directly. f. Logging and Auditing System
The logging and auditing system (not shown) also keeps track of statistics. In particular, the logging and auditing system preferably tracks the number of times each page of content is accessed, the number of transactions initiated from each page of content, the number of dialing events initiated from each page of content, and date and time correlation information for these data items. Various other statistics are kept in other embodiments.
6. Remote Monitoring System
The remote monitoring system provides access to the payphones for authorized individuals such as content providers and payphone or data network administrators. In one embodiment of the present invention, a remote monitoring system performs four principal tasks. These tasks are downloading a file from one or more payphones, uploading a file to one or more payphones, executing a shell command on one or more payphones, and doing an integrity check by performing a checksum comparison between a local file and a remote file. Typical tasks are described in detail in Appendix G.
One embodiment is illustrated in FIG. 7, which is a network diagram to show how a management client talks to a server using Common Gateway Interface ("CGI") calls. CGI calls allow web clients to communicate with external viewers and other applications. The remote machine, which is called the management client 71, runs Internet Explorer 4.0 or above. The management server 73 residing in the service provider is a Linux server running Apache Web Server, has Practical Extraction and Reporting Language 15.0 ("perl5.0") or above, and is an FTP client. The payphones 10, PPKC1330 - PPKC1332, are IIS FTP servers and remote shell daemons. IIS refers to Internet Information Server developed by Microsoft. The management client 71 talks to the management server 73 using CGI calls which, in turn, control the group of payphones 10 over an Ethernet connection 34.
7. Variations In accordance with an aspect of the present invention, the functionality disclosed herein can be implemented by hardware, software, and/or a combination of both. Software implementations can be written in any suitable language, including without limitation hyper-text markup language ("HTML"), JAVA, other high-level programming languages such as C+ + , mid-level, and low-level languages, assembly languages, and application- specific or device-specific languages.
Such software can run on a Intel-based computer such as a 486 or a Pentium (preferably an Intel-based or compatible Pentium II CPU running at 133 MHz or above), other general purpose computers, an application specific piece of hardware, or other suitable device. In addition to using discrete hardware components in a logic circuit, required logic may also be performed by an application specific integrated circuit ("ASIC"), a programmed programmable logic device ("PLD"), or other device. The system will also
include various hardware components which are well known in the art, such as connectors, cables, and the like.
Moreover, at least part of the functionality of the present invention may be embodied in computer readable media (also referred to as computer program products), such as magnetic, magnetic-optical, and optical media, used in programming an information-processing apparatus to perform in accordance with the invention. This functionality also may be embodied in computer readable media, or computer program products, such as a transmitted waveform to be used in transmitting the information or functionality. The principles, preferred embodiments, and modes of operation of the present invention have been described in the foregoing disclosure. The invention is not to be construed as limited to the particular forms disclosed, because these are regarded as illustrative rather than restrictive. Moreover, variations and changes may be made by those of ordinary skill in the art without departing from the spirit and scope of the invention.
Appendix A: Description of Datajack Service
Introduction
This appendix serves as a tutorial to the PowerPhone Datajack Service. It is used as an example of a common e-business application because it demonstrates many of the common steps involved in selecting a service and interacting with the user interface. Below is a quick guide to the service, followed by more detailed instructions on using the application.
Quick Guide to the Datajack Service 1. Pick up the handset.
2. Press the Datajack icon 81 (see FIG. 8) on the screen.
3. Press the flashing proceed button 83 (see FIG. 8) on the screen after reading the rate card.
4. Insert coins or swipe a credit card. For detailed instructions, press the corresponding icon 85 (see FIG. 8) on the screen.
5. After sufficient payment has been inserted, the user is prompted to connect a computer by inserting a telephone cable into the datjack port.
6. Press the flashing proceed button 83 (see FIG. 8) on the screen after plugging into the datajack. 7. The user starts dialing from his/her notebook.
8. If successful, the system starts charging. If it fails, a screen is displayed to prompt the user to try again and to go back to step 6 after pressing "Proceed"
9. The user can terminate the service either by unplugging from the datajack or by pressing the exit button 87 (see FIG. 8). 10. The amount charged will be displayed
Note:
When the touch screen is not pressed for a predefined period, a time out warning screen is displayed. A further lack of input from the user will result in the Datajack service being terminated.
Pressing the exit button at any time prior to pressing the send button will cancel the transaction.
Detailed Step-bv-Step Instructions
1. The user lifts up the PowerPhone handset. The commercial video stops playing and reveals the dialing keypad screen shown in FIG. 9. The user presses the Datajack icon shown on the bottom left corner of the screen.
2. After the Datajack icon is pressed, the rate card screen of FIG. 10 is shown. The user is informed of the service's charging scheme and service provider's disclaimer. To continue, the user needs to press the flashing PROCEED button, which is the second button from the bottom on the pole at the right hand side of the screen. Pressing the EXIT button will terminate the application. Pressing the "?" button will display the help screen shown in FIG. 11.
3. After the PROCEED button is pressed, the screen of FIG. 12 will be displayed. Its purpose is to prompt the user to replace the handset. To continue, the user can press the PROCEED button. 4. After the PROCEED button is pressed, the amount of credit inserted by the user is checked. If the user has inserted sufficient credit for the service to start, an appropriate screen will be displayed. Conversely, if there is insufficient credit for the service to start, the screen shown in FIG. 13 will be shown to the user, prompting for payment. If the user takes no action for a predefined period, a warning screen such as that shown in FIG. 14 is displayed. A further lack of input from the user will result in the Datajack service being terminated.
5. For detailed instructions on using a particular payment type (e.g. coin or credit card), the user can press the corresponding icon in the Payment screen of FIG. 13. The screen shown in FIG. 15 is displayed when the user presses the Credit cards icon. If a credit card is swiped, the screen shown in FIG. 16 is displayed while the PowerPhone validates the credit card via the card center.
6. After sufficient payment has been inserted and verified, the screen shown in FIG. 17 will be displayed. It prompts the user to plug the user's cable into the datajack. After plugging in the cable, the user can press the PROCEED button. 7. After the PROCEED button is pressed, the screen shown in FIG. 18 will be displayed. It prompts the user to start dialing from his/her modem within ten seconds after pressing "PROCEED".
8. After the user's modem begins dialing, if the connection is successfully created the screen shown in FIG. 19 will be displayed and the PowerPhone begins charging. The user's credit will be deducted for each interval of time and will be displayed on the upper right corner of the screen. The user's credit will be charged for the connection charges and for the connection time.
9. Conversely, if the connection fail, the screen of FIG. 20 will be displayed. In this case, the user needs to press the PROCEED button again to go back to step six.
10. The user can terminate the datajack service either by unplugging the cable or by pressing the EXIT button. In both cases, the screen of FIG. 21 will be displayed and the total amount which has been charged will be displayed. Eight seconds later, it will go back to the attract loop.
11. In addition, pressing the EXIT button at any time prior to a successful connection will cancel the transaction and the user will not be charged. The screen of FIG. 22 is displayed when the EXIT button is pressed. Eight seconds later, it will go back to the attract loop.
Appendix B: Description of Data Updating for an Application
This appendix describes the data updating specification and procedure for the -Tourist application. The iTourist application provides a wide range of brief and essential tourist information, including information on historical facts about the city, transportation, hotels, sightseeing, tours, shopping, dining, sports and recreation, departure, popular events, nightlife, and maps. This appendix describes (i) the data that can be updated, (ii) the submission process, (iii) the data format of database related sections, (iv) the time frame and cost, (v) the database structure for database sections, and (vi) the graphics and movie specification.
1. Data that can be Updated
-Tourist's data can be divided into three major areas: (i) database related sections, that is, Dining, Shopping, Nightlife, and Hotels, (ii) non-database related sections, which will include all sections except the above, and (iii) pictures, pages, content, and maps applicable to iTourist.
Data of the database related sections can be updated if the content provider provides the agreed text format explained in section three below. Data of the non-database related sections can also be updated provided they are in ASCII text file format and Chinese text is in Big-5 code. Graphics and movies can be changed as well and their formats are described in section six below.
Data cannot be updated automatically by the content provider. It has to be done through a submission process explained in section two below.
All updating work is a global replacement. Therefore, the following activities, among others, will require additional work to effect: (i) adding a subsection at any level, (ii) creating an additional page, as is required, for example, if the number of words in a specific piece of text in ASCII format exceeds the existing ones in the iTourist application, and (iii) adding a picture icon, together with its related database, at any level.
2. Submission Process The data submission process from the point of submission to the point of updating the PowerPhones at the installed site (for bottom level text only) is as simple as a file transfer. Provided that the updated data complies with the proper format, iMagic will
transfer those changes to the DATA center. Thereafter, the changes will be downloaded to the appropriate Power Phones.
3. Data Format of Database Related Section 3.1 Updating Database Related Sections
To update database related sections, the information must be provided in a database (xbase format). iMagic will process such databases accordingly. The format of that database for each section has been fixed, as described in section five.
For any modification of new fields and data to a database section, the whole database needs to be supplied to iMagic and iMagic will make the changes accordingly. New pictures, such as a logo and hotel pictures, can be sent by e-mail.
3.2 Local Hong Kong Words
For some local Hong Kong words which are not included in the standard Chinese character set, the internal codes agreed upon between the Hong Kong Tourist Association and iMagic for such words need to be supplied.
4. Time Frame and Cost
To start, it is proposed that iMagic will receive a monthly update no later than the fifteenth of each month so that the changes will be uploaded to the PowerPhone in the first week of the following month. There will be an upload fee applicable to every upload job.
5. Database Structure for Database Sections
There are four content sections created by the page generator in the iTourist application. The generator produces all the pages for Shopping, Dining, Nightlife, and Hotels. The structure of the database format for each follows.
5.1. Structure for the dining section Structure for database: dinelst.dbf Field Field Name Type Width Dec
SHOP ID C 8 0 Width: 5 - > 8
2 CAT ID C 40 0
3 SUBCAT ID C 40 0
4 REGION ID C 40 0
5 DSTRICT D C 40 0
6 REMARKS C 40 0
** Total ** 209
Note: The inherent structure of the "dbf" format requires one additional byte for each row.
Therefore, the "Total" values are greater than the actual sum by a value of one.
Structure for database: dine_e.dbf / dine_c.dbf Field Field Name Type Width Dec
1 SHOP D C 8 0 Width: 6 - > 8
2 SHOP NAME C 80 0
3 SHOP_ADDR C 120 0
4 SHOP_TEL C 20 0
5 OPHR1 C 50 0
6 OPHR2 C 50 0
7 OPHR3 C 50 0
8 PRICE C 4 0
9 LOUNGE C 0
10 MUSIC C 0
11 BAR C 0
12 HALAL C 0
13 CARDS C 0
** Tota ** 388
Structure for database: dine_cat.dbf
Field Field Name Type Width Dec
1 TYPE C 3 0
2 CODE C 16 0
3 DESC_E C 60 0
4 PARENT C 30 0
5 DESC C C 30 0
** Total ** 140
5.2 Structure for the shopping section Structure for database: shoplst.dbf Field Field Name Type Width Dec
1 SHOP ID C 8 0 Width: 5-> 8
2 CAT ID C 40 0
3 SUBCAT ID C 40 0
4 REGION ID C 40 0
5 DSTRICT ID C 40 0
6 REMARKS C 40 0
** Total ** 209
Structure for database: shop e.dbf / shop_c.dbf Field Field Name Type Width Dec
1 SHOP ID C 8 0 Width: 6-> 8
2 SHOP_NAME C 80 0
3 SHOP ADDR C 120 0
4 SHOP TEL C 20 0 ** Total ** 229
Structure for database: shop_cat.dbf
Field Field Name Type Width Dec
1 TYPE C 3 0
2 CODE C 16 0
3 DESC E C 60 0
4 PARENT C 30 0
5 DESC_C C 30 0
** Total ** 140
5.3. Strucmre for the nightlife section Strucmre for database: nitelst.dbf Field Field Name Type Width Dec
1 SHOP D C 8 0 Width: 5 -> 8
2 CAT D C 40 0
3 SUBCAT ID C 40 0
4 REGION ID C 40 0
5 DSTRICT D C 40 0
6 REMARKS C 40 0
** Total ** 209
Strucmre for database: nite_e.dbf / nite_c.dbf Field Field Name Type Width Dec
1 SHOPJD C 8 0 Width: 5 -> 8
2 SHOP_NAME C 80 0
3 SHOP_ADDR C 120 0
4 SHOP TEL C 20 0
5 OPHR1 C 50 0
6 OPHR2 C 50 0
7 OPHR3 C 50 0
8 PRICE C 4 0
9 LOUNGE C 0
10 MUSIC C 0
11 BAR C 0
12 HOSTESS C 0
13 CARDS C 0
** Total ** 388
5.4. Strucmre for the hotel section Strucmre for database: hotel_e.dbf / hotel_c.dbf Field Field Name Type Width Dec
1 H ID C 5 0
2 H_NAME C 80 0
3 H_REGION C 1 0
4 H ADDRESS C 120 0
5 H PHONE C 20 0
6 H FAX C 20 0
8 H EMAIL1 C 20 0
9 H EMAIL2 C 20 0
10 H EMAIL3 C 20 0 Width: 5-> 20
12 H_WEB1 C 20 0
13 H_WEB2 C 20 0
14 H_WEB3 C 20 0 Width: 5-> 20
15 H SINGLE C 40 0 Width: 20 -> 40
16 H_DOUBLE C 70 0
17 H SUITES C 40 0 Width: 20 -> 40
18 H VvΗEREIS C 20 0
19 H_HTML C 20 0 For iMagic internal use only
20 H LOGO C 40 0 For iMagic internal use only
21 H_PHOTO C 40 0 For iMagic internal use only
22 H REMARKS C 50 0 For iMagic internal use only
** Total ** 687
5.5. Region and district databases Structare for database: region. dbf
Field Field Name Type Width Dec
1 TYPE C 3 0
2 CODE C 16 0 Width: 12 -> 16
3 DESC E C 60 0
4 PARENT C 30 0
5 DESC_C C 30 0
** Total ** 140
Strucmre for database: district.dbf
Field Field Name Type Width Dec
1 TYPE C 3 0
2 CODE C 16 0
3 DESC_E C 60 0
4 PARENT C 30 0
Graphics & Movie Specification
Size: 734 x 544 pixels (W x H) (Full screen size)
Format: 1. Graphics
Standard JPEG (*.jpg) GIF 87 or 89a (*.gif)
2. Movie
MPEG I (*.mpg) standard VCD video stream parameters
352 x 240 pixels
30 fps (frames per second) data rate < 150 Kbytes/sec audio stream parameters
ISO Layer II
Sampling frequency: 44.1 KHz or lower Mode: Stereo, Intensity stereo or Dual channel data rate = 224 Kbits/sec N.B.: 1. A movie is played back in full frame display with no overscan.
Consideration has to be made on using TV commercial video which is normally played back in "overscan" mode.
2. The size of alphabets/characters within the video has to be considered for clear display. 3. The audio is played back in mono mode, through the handset, irrespective of what the format of the movie is.
Appendix C: Content Submission for a CNN News Service Application
This appendix contains information on the content submission for the CNN News
Service application offered in an embodiment of the present invention. The delivery procedure and the file transfer flow are described below. Further aspects of the CNN application dealing with the user interface are described in Appendix D on the user interface.
Delivery Procedure
1. Daily updated/modified "ini" file and graphics files should use the same file naming convention and directory structure described in the specification document.
2. Use of compression programs, such as WinZip or Command Line Zip, to zip up all delivered files is essential. Note that the directory strucmres must be preserved during compression. For example, for WinZip select the "Recurse Folders" option. Password option can be added for security reasons if it is only available from the command line.
File Transfer Flow
The flow described below is also represented in FIG. 29.
CNN can upload news stories from the CNN server 290 to the iMagic ftp site 291 daily before 11:30 PM Hong Kong time, step 293. The deadline for final file delivery is 12:10 AM.
CNN uses SSH (SCP, Secure Copy) to transfer files to iMagic' s server 291 using the correct IP number.
At 11:30 PM, iMagic 's CNN automation program, step 294, will then decompress the latest file and validate its content.
If the file is validated, the zip file will then be transferred to NWT's distribution server 292 through the RAS server, step 295.
The distribution server 292 is scheduled to finish decompressing all files and send them to the PPs 10 in the targeted locations by 2:30 AM Hong Kong time, step 296. If a problem is detected in the file, an error message will be sent to the CNN operator. The operator is expected to deliver a new file to iMagic's server.
By default, iMagic's validation program is scheduled to perform three rounds of checking in a 20-minute interval at 11:30 PM, 11:50 PM, and 12:10 AM.
No new file will be validated if the delivery is later than the scheduled checkpoints. For example, a new file should be at iMagic's server 291 before 11:30 PM if it is expected to be validated at the first checkpoint, which occurs at 11:30 PM. Any file sent later than 11:30 PM will be deferred to the second or third checkpoints.
If the validation program fails to grab a new file in the Falcon server 291 in each of the three attempts, then the PPs 10 will not be able to process any file transfer. The news then will stay as it is without any change. The whole delivery is 100% automated. Therefore, no content manipulation and editing will be carried out by iMagic.
Appendix D: Sample User Interface Screen Layouts
This appendix describes several of the screen layouts of an embodiment of the present invention. Additional screen layouts are also shown throughout the specification, as, for example, in the description of the Datajack service in Appendix A, and in the description of the remote monitoring system functions in Appendix G.
Referring to FIG. 1, the touch screen 14 allows the user to communicate with the payphone 10 in order to select services. Referring to FIG. 30, in one embodiment of the present invention the touch screen 14 contains a command pole 50 which can rotate in three dimensions. The command pole 50 is shown to the left of center, but other placements are utilized such as, for example, at the right of the touch screen 14 as shown in FIG. 31.
Programs control the display of the screen 14 and present on the screen 14 the various options available as well as instructions. FIG. 30 shows the use of a keypad 52 on the touch screen 14. FIG. 33 shows a virtual keyboard being displayed on the touch screen. FIG. 31 shows the use of preprogrammed buttons 56 that are used in an application called PowerLink. The buttons 56 allow the user to navigate through the services offered by the application.
The user interface also provides information, such as the elapsed time and charge 324 in FIG. 32. Additional information is provided by advertising content, which the user might read or even interact with to obtain different levels of information. FIG. 30 shows several advertising banners on the left side 54 of the screen 14.
These advertising banners can integrate links that allow the user to touch the ad and acquire additional information or services. In the screen layout of FIG. 30, there can be up to nine slots of advertising in the left side 54, each one running horizontally and being stacked upon the ones below. FIG. 32 shows another sample screen in which a CNN advertisement is using multiple advertising slots. FIG. 32 also shows an example of a scrolling or banner ad, also called a ticker tape, 322. FIGS. 34-35 show layouts and sequences for the CNN application which further describe the myriad options available for displaying multi-media information on the screen.
Given the flexibility of a programmable display, there are numerous methods of interacting with the user to acquire information. Further, embodiments of the present invention may also utilize other interface devices such as voice control through a
microphone and speech recognition, voice prompting through a speaker, command input with a light pen, etc.
Appendix E: Description of an ActiveX Control File
The Phoner control is an ActiveX dual interface control that supports telephone service such as voice, fax, and Datajack. The control has no runtime-visible user interface.
The control works with Pika Inline telephone cards. This appendix describes the Phoner control software module using the following function tables as well as the voice call flow diagrams in FIGS. 36-37.
Briefly, FIG. 36 shows the sequence of events during a Phoner Control process. First, the PP Server will call 360 the Phoner Control's Initialize function. Phoner Control's Initialize function will initialize 361 the Pika Card using Pika Driver. It does so by reading the setting for system registry, loading Pika Driver (the multi-threaded driver supplied by the maker of the Pika Card), and starting a new process called Inline.exe. This process is responsible for the lowest level driving of the Pika Card. Then, the PP Server will call 362 the Phoner Control's DialCall function. Phoner Control's DialCall function will dial 363 the phone call through the connected phone line using the Pika Driver to access the Pika Card. When the call is connected, the driver will inform 364 the Phoner Control, which will in turn inform 365 the PP Server via a Windows event. At the same time, the Pika Driver will perform a line reversal event 366, that is, a change of voltage required to signal 367 that a call is connected. When the call finishes, the PP Server will call 368 the Phoner Control's Hang Up function. The PSTN line is onhook and there is a conference of handset and PSTN line 369.
Briefly, FIG. 37 illustrates a sequence which starts with a dial event 371 and ends with a hangup 376. There are three paths between these two points. In the first, the dial 371 is followed by taking the line off hook and dialing the number 372. Then, if the event DialCallComplete occurs and the server waits for the line reversal 373. If the line reversal occurs, the server starts charging 375. After that, if a second line reversal is detected, the headset goes on hook, or the user selects another call, then the server stops charging 377. Hangup occurs 376 after the system stops charging 377. The second path is followed if, while the server is waiting for the first line reversal 373, a timeout occurs. In that case, a voice prompt is played 374 and hangup occurs 376. The third path is followed if, after the line goes off hook and the number is dialed 372, the line is busy or there is no dial tone. In that case, as in the second path, a voice prompt is played 374 and hangup occurs 376.
Methods
Events
Registrv Settings of Phoner
All Keys are based at HKEY_LOCAL_MACHINE\SOFTWARE\Imagic
Appendix F; Internal Flow of Several Software Modules
This appendix provides some detail on the flow of the internal software modules, including the ActiveX components, of the payphone which is an embodiment of the present invention. The tables which follow are time sequence tables ("TST" tables) and are to be read from the top to the bottom. It is to be understood that the behavior of the payphone, as shown in the tables below, is dependent on the particular payphone application and that not all embodiments need to support each of the features described below.
Card Reader control Filename: CardReader.ocx.
For magnetic stripe cards and contact smart cards. It has the ability to read/write Credit Cards, EPS, Talk Talk, GPM103, and ISO7816 T = l T=0 Smart Cards.
CARD READER PP USER Scenario 1: get the credit card details to send off for clearing at the bank
Scenario 2: read calling card details stored on a smart card for auto dial
Coin System control
Filename: CoinSystem.ocx.
For coins of many countries. It has the ability to accept HK coins, Canadian coins, and more, to limit the number of coins stored in credit at a given time, to sequence the refunding, and to produce coin usage reports.
COIN SYSTEM PP USER
CSC Reader control
Filename: CSCReader.ocx.
For CSCs (Contactless Smart Cards). It has the ability to read/write Octopus CSCs and produce transaction reports.
CSC READER PP USER
Scenario 1 : detect stored value contactless smart cards and manage the debiting and production of transaction details
Scenario 2: responding to an asynchronous error
Scanner Control
Filename: Scanner. ocx.
For the A4 sized monochrome scanning. It has the ability to format the scanned images for faxing.
SCANNER PP USER
Scenario 1 : used to scan pages which are passed on to the fax application
Scenario 2: responding to an asynchronous error
Appendix G: Remote Monitoring System Functions
This appendix discusses several of the functions which the service provider of a payphone system can perform and contains several example screens which illustrate these functions. All of these functions are performed from a remote location through the service provider, such as from a management client 71 through a management server 73 as shown in FIG. 7.
The first example is content distribution. Referring to FIG. 23, there is shown a content distribution screen. By pressing the Start button, the file patch_vlr3.tar will be distributed to the three listed PowerPhones, which are ppkcl330, ppkcl331, and ppkcl332, and placed under the c:\ directory. Notice that there is a Background check box. If it is checked, the command will be sent to background and the user will not need to wait for the completion of the command. All of the results will be re-directed to the log files which can be viewed through the "View Op. Log" option on the menu. The field at the bottom can be used to execute a command on a management server 73 (see FIG. 7). For example, the current working directory can be changed to the /tmp directory by entering "cd /tmp".
The second example involves executing a command on a remote PowerPhone. Referring to FIG. 24, there is shown a remote management screen for executing a command on PowerPhone PPKC1331 (see also FIG. 7). This example shows how to execute a command on a remote PowerPhone. The command field shows the words "dir \*tar" . By pressing the Start button, a listing of all of the "tar" files under the c:\ directory of the payphone ppkcl331 will be shown on the screen. FIG. 25 shows the output that executing this remote command generates. The output is displayed on the same display from which the command was entered, that is, the remote location.
The third example is for performing an integrity check with a checksum command, which is similar to the "cksum" Unix command. The checksum command compares the contents of two files and can be used as an integrity check after a file transfer. Referring to FIG. 26, there is shown a screen for performing the integrity check for the content transmitted to one or more payphones. Note that the Win32 version of the cksum program must be installed in the PowerPhone before this function can be used. The fourth example shows how to check the status of background jobs, such as in the first example if the operation is performed in the background. In such cases, the output is sent to a log file on the Linux Server, which is an embodiment of a management server
73. These logs can be viewed through the "View Op. Log" function. FIG. 27 shows the screen for this function. The output of the View Op. Log function is shown in FIG. 28. FIG. 28 reveals that a download command was issued on "Mar 22 1999 11:26:07" and was not successful due to a network error.