Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
MULTIMEDIA TELEPHONE SYSTEM AND DEVICE
Document Type and Number:
WIPO Patent Application WO/2011/059414
Kind Code:
A1
Abstract:
This invention relates to a Multimedia Telephone System and Device that performs multiple tasks in a distributed, fault-tolerant, secure manner. Two main components of this invention include a Central Management System (CMS) and a Multimedia Payphone Terminal (MPT). This invention provides what is essentially an integrated kiosk solution with efficient software and hardware components. End-users are provided with a high-tech payphone service, to provide a wide range of services such as video applications, tourist information and ticket sale service.

Inventors:
DINCER CELALETTIN (TR)
ATALAY MEHMET (TR)
ODABASI MUSTAFA KEMAL (TR)
KEBAPCIOGLU AHMET (TR)
KAYAALP NUSRET (TR)
EKSI ORHAN (TR)
OEZTUERK AHMET (TR)
Application Number:
PCT/TR2009/000143
Publication Date:
May 19, 2011
Filing Date:
November 16, 2009
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INNOVA BILISIM COEZUEMLERI A S (TR)
DINCER CELALETTIN (TR)
ATALAY MEHMET (TR)
ODABASI MUSTAFA KEMAL (TR)
KEBAPCIOGLU AHMET (TR)
KAYAALP NUSRET (TR)
EKSI ORHAN (TR)
OEZTUERK AHMET (TR)
International Classes:
H04M17/02; H04M3/42
Domestic Patent References:
WO2000062523A12000-10-19
WO1997042728A21997-11-13
WO2005018212A12005-02-24
Foreign References:
EP0902580A21999-03-17
FR2558325A11985-07-19
EP0845894A21998-06-03
US20020067812A12002-06-06
US20040147285A12004-07-29
Attorney, Agent or Firm:
KORKUT, Nazli (Inebolu Sok. Deris Patent Building No. 5Setustu, Kabatas, Istanbul, TR)
Download PDF:
Claims:
CLAIMS

A system to enable distributed, failure-tolerant, modular and secure multi-media enhanced applications on a payphone comprised of:

a. One or more Multimedia Payphone Terminals (MPTs) comprising:

i. Means to provide payphone applications, internet-based services, content, Short Message Service (SMS), e-mail service, video phone based applications, picture and video recording, saving and forwarding media via various applications including email, city guides, banking operations and secure payment via EMV certified components;

ii. Means to provide these applications in both connected and connectionless states (except online banking operation);

iii. Means to interface with a Central Management System CMS in both states such that the data is synchronized as required, to maintain consistency;

iv. Means to perform Multi-tasking in order to enable users to use more than one application, simultaneously.

b. a Central Management System (CMS) comprising: i. Means for secure data storage;

ii. Means to data back-up

iii. Means to act as a gateway of the private network for outer system connections;

iv. Means for online communication and management of MPTs;

v. Means to the produce reports;

vi. Means to monitor failures;

vii. Means to manage Multimedia Payphone Operating Centers (MPOC);

viii. Means to perform version control alongside enabling remote updates and managing tariff tables used by the MPTs;

ix. Means to manage advertisement and content management in MPTs.

A system of claim 1 wherein the MPT further comprises a modular design including:

c. a framework having:

i. a browser API used to interface with the Hardware Abstraction Layer (HAL); ii. a scheduler that interfaces with a transmitter and a monitor;

iii. one or more data-stores;

iv. an alert handler;

v. a file updater;

vi. a configuration manager; and vii. a command interpreter.

d. a communication handler executing multiple operation flows; and

e. one or more applications including:

i. a pricing unit;

ii. a tariff unit;

iii. one or more data-stores;

iv. a user manager;

3. A system of claim 1 wherein the Hardware Abstraction Layer (HAL) interfaces with various devices including a card-reader device, a pin pad driver, a control card driver, a PSTN card driver, a video camera driver and a system driver, through a common HAL interface.

4. A system of claim 3 wherein the card reader driver in turn uses a driver-specific protocol to talk to a card reader via a card reader hardware driver.

5. A system of claim 3 wherein the pin pad driver also uses a driver-specific protocol to talk to a pin pad via a pin pad vendors hardware driver.

6. A system of claim 3 wherein the control card driver uses a custom built protocol to a control card.

7. A system of claim 3 wherein the PSTN card driver uses a custom built protocol to talk to a PSTN card.

8. A system of claim 3 wherein the video camera driver through a device specific driver to a web camera vendors hardware driver which in turn talks to a web camera.

9. A system of claim 3 wherein the system driver typically interfaces with a WMI system that utilizes a WMI interface to interact with vendor hardware drivers to talk to PC Hardware.

10. A system of claim 3 wherein the operation flow for a dropped call comprises:

a. Generating an on hook signal is generated between the user and the telephone card.

b. Generating a drop call signal;

c. Generating an On Hook signal between the telephone card and the MPT;

d. Generating a response from the MPT to the Telephone card ;

e. Displaying a message for the user at the MPT;

f. In case the called party drops the call, generating a reverse signal at the telephone card;

g. Generating a drop call signal at the telephone card;

h. Sending a reverse signal from the telephone card to the MPT;

i. Sending an acknowledgement from the MPT back to the telephone card;

j. In the case of a line error, generating a line error signal between the telephone card and the MPT;

k. Generating an acknowledgement in the reverse direction; and

1. Displaying an error message for the user at the MPT. 1 LA system of claim 3 wherein the operation flow for an incoming call comprises:

a. Receiving an incoming call signal;

b. Generating an activate ring signal;

c. Receiving an incoming call signal;

d. Acknowledging the signal in .c;

e. Displaying an incoming call message for the user;

f. Sending two hook off signals in sequence;

g. Generating a response the last signal;

h. Generating a de-activate ring signal and a Line Up signal; i. Starting the call and generating a signal to indicate this, which is acknowledged;

j. Once the call starts, in case the called party quits, generating a call terminated signal;

k. Generating a deactivate ring signal;

1. Generating a call terminated signal which is acknowledged;

m. Displaying a message to the user;

n. Generating a second deactivate ring signal and a drop call signal;

o. Generating a second call dropped signal which is also acknowledged; and

p. Displaying a user message.

12. A system of claim 3 wherein the operation flow for a user that is out of credit comprises:

a. Displaying a message to inform the user; b. Issuing a drop call signal;

c. Dropping the call; and

d. Acknowledging this signal at the end.

13. A system of claim 3 wherein the operation flow for a user trying to browse comprises:

a. The user initiating the process by selecting a service; b. The browser loading the application;

c. Opening a service session such that a signal is sent to the pricing unit to initiate billing;

d. Executing payment authorization using secure channels; e. Commencing the browsing service pricing and this is acknowledged;

f. If a pricing event occurs, sending a signal from the Pricing Unit to the browse;

g. In case there is an error in the pricing, displaying a message is on the browser;

h. In case the user has no credit to use the service, displaying a message on the browser;

i. Terminating the service session being terminated and this is acknowledged;

ii. the termination leading to the browser navigating to the main homepage;

i. In case the user wishes to engage in a telephony service, if the user wishes to terminate the service, displaying a message on the browser asking if the user truly wishes to terminate j. Recoding the user decision is recorded and once the user confirms the termination, stopping the;

k. The pricing unit acknowledging the stop signal; and 1. service termination event checking to see if the user has NOT confirmed termination, in which case, the confirmation dialog on the browser is closed. 14. An Apparatus to enable distributed, failure-tolerant, modular and secure multi-media enhanced applications on a payphone comprised of:

a. a touchscreen;

b. an encrypted pin pad;

c. a handset;

d. a keyboard and trackball;

e. a printer;

f. a web camera;

g. shortcut keys;

h. one or more guiding LEDs;

i. a memory reader;

j. a credit-card reader;

k. a telephone card;

1. a line protection card; and

m. a control card;

all located in a specifically vandal proof design body of a stainless steel with 3 mm thick aluminum front panel, having a high security lock system, various shock sensors to monitor possible shock from outside

15. An apparatus of claim 14 wherein the telephone card is a proprietary card which along with providing basic PSTN payphone functions, also supports video phone based applications by transferring the handset to PC in case of video phone service usage, as this is a VoIP application.

16. An apparatus of claim 14 wherein the MPT Control card has several capabilities including:

a. Checking the AC line and turning off the PC in case of failure;

b. Checking the AC line and turning on PC in case of recovery;

c. Working as a watch-dog-timer and resetting the PC, if communication is lost;

d. Checking the temperature, reporting to MPT, and turning off/on cooler/heater accordingly, if necessary;

e. Checking the water and reporting to MPT, if water exists; f. Checking the shock and reporting to MPT, if shock applied;

g. Checking the door lock and reporting to MPT, if open; h. Controlling the LED guides.

17. A computer program product to enable distributed, failure- tolerant, modular and secure multi-media enhanced applications on a payphone comprised of:

a. Logging and transmitting local and networked transactions;

b. Security Features; c. Self-recovery;

d. Version-upgrades;

e. Encrypted versions of private data;

f. Distributed and modular architecture;

g. Fault-tolerance;

h. Service oriented modular structure;

i. Various voice, data, video and secure payment facilities. 18. A computer program product of claim 17 further comprising : a. Telephony Service;

b. Internet service;

c. Email service;

d. Video service;

f. Image service; and

g. SMS service

19. A computer program product of claim 17 further comprising a browser application that allows the user to navigate the available choices of using a card, pressing a function button and use the handset. 20. A computer program product of claim 17 wherein the user can use a credit card, wherein the product is capable of performing the required authentication for pre-authorization and utilizing the credit on the card. 21. A computer program product of claim 17 wherein the telephone service is used by checking for whether the call if free and whether the user has enough credit to carry out the call in the requisite time-frame.

22. A computer program product of claim 17 wherein the internet service is used by checking whether the user has enough credit to browse by taking the user to the corresponding page, upon available connectivity.

23. A computer program product of claim 17 wherein the SMS service is used by checking whether the user has enough credit to place the SMS on a per-message cost basis, accepting the sender detail and sending the same.

24. A computer program product of claim 17 wherein the e-mail service is used by checking whether the user has enough credit to send the message, make allowances for attachments, verifying the address that the user is sending to and sending the e-mail upon receiving confirmation on pricing.

25. A computer program product of claim 17 wherein the videocall service is initiated upon the users credit being verified, the address being correctly entered and the user's session being priced.

26. A computer program product of claim 17 wherein file management, including files belonging to various kinds of media, is performed by checking to see if the appropriate flash memory is present in the driver and saving the file once the memory is present.

27. A computer program product of claim 17 wherein the card reader interrupt flow is activated to detect the insertion and removal of a card.

Description:
MULTIMEDIA TELEPHONE SYSTEM AND DEVICE

ABSTRACT

This invention relates to a Multimedia Telephone System and Device that performs multiple tasks in a distributed, fault-tolerant, secure manner. Two main components of this invention include a Central Management System (CMS) and a Multimedia Payphone Terminal (MPT). This invention provides what is essentially an integrated kiosk solution with efficient software and hardware components. End-users are provided with a high-tech payphone service, to provide a wide range of services such as video applications, tourist information and ticket sale service.

BACKGROUND

FIELD OF THE INVENTION This invention relates to a Multimedia Telephone System and Device that performs multiple tasks in a distributed, fault-tolerant, secure manner.

DISCUSSION OF PRIOR ART

EP 0 845 894 A2 discloses A system for accessing multimedia mailboxes over the internet and via telephone wherein the invention limits itself to voice and e-mail interfaces including storage and retrieval of voice messages over both the data network and the internet. Indexing the messages by unique identifiers, this invention provides lookup and retrieval of the same. This invention also provides session information to be stored, which indicates that the state required to enable this application might not be conducive to thin-clients being used. This invention addresses the storage, retrieval and inter-conversion between various formats for video as well. The present invention is distinct in its treatment of all types of multi-media and not being limited to voice messages. Present invention is also distinct from this invention because of the segregation into the inner and outer layers, the introduction of the central management application and possibly thin-client installations and the depiction of its interaction with various devices including smart cards. The present invention has no private mailbox. It has its own username and SMS number and it provides one way service. No private account is needed for sending SMS and emails. If user wants to use his/her private account, s/he has to use internet service to do this. The present invention has no message storage function for storing picture, record video, or type text, review them during editing etc. It is sent to the receiver once SEND command is given. Only necessary data is saved in central management database, such as payment tool, where it was sent, date, time etc. the present invention is a fat-client and able to operate even when the connection to CMA is lost. US2002/0067812 Al discloses Technique for linking telephony and multimedia information wherein the invention proposes a simpler idea to ameliorate overheads and present a set of methods to exchange multimedia information, over and above what is made available with the H.323 Standard but such Telecom providers as AT&T. Parties that are making telephone calls are further able to exchange multimedia information by setting up a URL, which serves as a conduit for this information. This invention is different from present invention in a number of ways including the utilization of an actual computer at the caller and the callee sends, the establishment of bridges and gateways to authenticate the exchange, special consideration for teleconferencing and the utilization of set top boxes for caller identification.US2004/0147285 Al discloses Method for managing transmissions of multimedia data via an internet-type network, in particular telephone or video phone data, and smart card for implementing the method wherein this invention similar to the present invention in number of ways including compatibility with external peripherals such as smart cards and it is a multi application card and introduction of a directory server whose functions seem to be close to the Central Management System. Smart card is used for managing communications between a first subscriber system and a second subscriber system via a network. The distinguishing features include the combination of the communication protocol layer with the smart card. In the present invention, smartcard is used as a payment tool; payment can be done via subscription, private prepaid or postpaid card, or a credit card and covers EMV requirements with certified hardware and software. It has no relation for managing transmissions of multimedia data. WO00/62523 discloses Interactive multi-media payphone system combining networking and telephony technology wherein the three embodiments of the invention are presented that work with the normal telephone network, a separate data network for e-mail and other services and a separate network (data network) for Internet access, e-commerce, e-mail etc. Their description of various interfaces such as the voice interface, the payment acceptor and the UI seems to be close to the interfaces proposed by present invention. Service providers are treated as distinct entities thereby presenting stand-alone functions for the same. In the present invention the network is a private secure network which provides data and PSTN together. PSTN line is connected to telephone exchange while data line is routed to the central management system. Network is connected to SMS center and E-mail server via central management system it has one data line connected to center, and central management system manages the required routings and stores necessary data in database. WO 97/42728 discloses Method and apparatus for coordinating internet multimedia content with telephone and audio communications wherein the invention allows two users to concurrently view content on each other's screens and make modifications to the same. This invention is primarily concerned with the modification of online forms shared between two users, typically a call center operator and a customer of some kind. This application further talks about two users having the capability to simultaneously edit content related to software downloads. This is not particularly relevant to present invention as it is not addressing other forms of multi-media other than forms and downloads. The only similarities seem to be in the maintenance and updation of session information via applets. WO/2005/018212 discloses Multimedia device with internet and phone function wherein the invention is enabling various functions to the user such as telephone, conference calls, internet, TV, shopping catalogs, telephone directory and remote monitoring. This opens up the door for inviting content providers (that provide, for example catalogs for malls) to update and maintain the content storage section of this invention. Further, the OS environment seems to be MS-XP and this is arguably a weak point of this invention (as it does not seem to make room for multiple OS-es).

SUMMARY OF THE INVENTION

This invention relates to a Multimedia Telephone System and Device that performs multiple tasks in a distributed, fault-tolerant, secure manner. Two main components of this invention include a Central Management System (CMS) and a Multimedia Payphone Terminal (MPT). This invention provides what is essentially an integrated kiosk solution with efficient software and hardware components. End-users are provided with a high-tech payphone service, to provide a wide range of services from video applications, tourist information and ticket sale service. A system to enable distributed, failure-tolerant, modular and secure multi-media enhanced applications on a payphone comprised of one or more Multimedia Payphone Terminals (MPTs) comprising (a) Means to provide payphone applications, internet- based services, content, Short Message Service (SMS), e-mail service, video phone based applications, picture and video recording, saving and forwarding media via various applications including email, city guides, banking operations and secure payment via EMV certified components; (b) Means to provide these applications in both connected and connectionless states; (c) Means to interface with a Central Management System CMS in both states such that the data is synchronized as required, to maintain consistency; (d) Means to perform Multi-tasking in order to enable users to use more than one application, simultaneously and a Central Management System (CMS) comprising: (a) Means for secure data storage; (b) Means to act as a gateway of the private network for outer system connections, failure management, customer management, e-mail server, SMS center and bank host; (c) Means for online communication and management of MPTs; (d) Means to the produce reports; (e) Means to monitor failures; (f) Means to manage Multimedia Payphone Operating Centers (MPOC); (g) Means to perform version control alongside enabling remote updates and managing tariff tables used by the MPTs; (h) means to manage advertisement and contents to be displayed on MPTs.

The present invention further proposes an apparatus to enable distributed, failure-tolerant, modular and secure multi-media enhanced applications on a payphone comprised of a 6 mm touchscreen, an encrypted pin pad, a handset, a stainless steel keyboard and trackball, a printer, a web camera, shortcut keys, one or more guiding LEDs, a memory reader, a credit-card reader, a telephone card and a control card, all located in a specifically vandal proof designed body of a stainless steel with 3 mm thick aluminum front panel, having a high security lock system, various shock sensors to monitor possible shock from outside

The present invention further proposes computer program product to enable distributed, failure-tolerant, modular and secure multi-media enhanced applications on a payphone comprised of: (a) Logging and transmitting local and networked transactions; (b) Security Features; (c) Self-recovery; (d) Version-upgrades; (e) Encrypted versions of private data; (f) Distributed and modular architecture; (g) Fault- tolerance; (h) Service oriented modular structure; and (i) Various voice, data, video and secure payment facilities;

BRIEF DESCRIPTION OF DRAWINGS

Figure 1 describes the basic design of the system showing the main components.

Figure 2 shows the MPT Network Topology on the Data Network.

Figure 3 shows the MPT PSTN Topology.

Figure 4 shows the CMS module diagram.

Figure 5 describes MPT Module Diagram

Figure 6 describes MPT Outlook

Figure 7 describes HAL in detail. Figure 8 describes Sample Operation Flow (Drop call)

Figure 9 describes Sample Operation Flow (Incoming call)

Figure 10 describes Sample Operation Flow (Out of credit)

Figure 1 1 describes the Sample Operation Flow when the user browses content

Figure 12 describes MPT Screen capture (Telephone and SMS Service in use)

Figure 13 describes MPT Screen capture (Internet service)

Figure 14 describes MPT Screen capture (Email service)

Figure 15 describes MPT Screen capture (Video service)

Figure 16 describes MPT Screen capture (Image service)

Figure 17 describes MPT Screen capture (SMS service)

Fig. 18 shows the general flow of the present invention.

Fig. 19 shows the service choices available to the user.

Fig. 20a-c show the card approval and crediting process.

Fig. 21 shows the telephone service in the present invention.

Fig. 22 shows the internet service.

Fig. 23 shows the SMS service.

Fig. 24a-b show the email service in this invention.

Fig. 25 shows the Picture/Video Sending/ record service

Fig. 26 shows the Video Conference Service

Fig 27 shows the pricing

Fig 28 a-b shows the shows the Card reader interrupt Flow.

Fig 29 a-b shows the shows the File Management. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Overall Layout

This invention relates to a Multimedia Telephone System and Device that performs multiple tasks in a distributed, fault-tolerant, secure manner. Two main components of this invention include a Central Management System (CMS) and a Multimedia Payphone Terminal (MPT). The system of the present invention is de-centralized, robust and modular in design. It is fault-tolerant and failure-resistant by providing a series of features to enable these properties. One or more client terminals interact with a Central Management System to provide the end-users, who might be distributed in space and time, with several applications including voice, data, video and image applications. Essentially, a host of media-based applications are combined into this invention to present an integrated kiosk, by means of which content and other information are disbursed by the content provider and availed by the end-user. The MPT and CMS modules communicate by means of a communication handler, which is the main layer that provides a delivery-guaranteed and protocol impendent data-transfer inside an abstract envelope.

Figure 1 describes the basic design of the system showing the main components. The Multimedia Payphone Terminal (MPT) applications 1 encompass a framework 2 which communicates via a communication handler 3. The Central Management System (CMS) 6 also encompasses a framework 5 and also communicates via a communication handler 4. Various CMS Applications include the e- mail server 7, an SMS Center 8, a CRS 9, an FMS 10 and a VPOS Switch 11. Figure 2 shows the MPT Network Topology on the Data Network. One or more MPT terminals 22a..22e are connected to the MPT Intranet 20, which interfaces with the Multimedia Payphone Operating Center (MPOC) 24, a service security gateway 27 and a Loop back Interface 25. The Loop back interface 25 further interfaces with the Central Management system 25a, which can manifest itself in several forms 25c..25f in terms of hardware and storage configurations and additionally interface with financial institutions 26 via a dedicated lease line, and various CMS Applications and subsystems such as the CRS 32a, the FMS 32b, the SMS sub-system 32c and the e-mail sub-system 32d.

Figure 3 show a more detailed layout of the components of the system. This figure motivates the capability of the MPT to act as a regular phone, while also performing the functions of an integrated kiosk. The MPT 305 interfaces with both PSTN 300 and GSM 301 networks to talk to a variety of devices 302, 303. The MPT is once more connected to the MPT Intranet 304, which interfaces with the Multimedia Payphone Operating Center (MPOC) 306, a service security gateway 309 and the Central Management system 308, which can manifest itself in several forms 308a..308c in terms of hardware and storage configurations and additionally interface with various CMS Applications and sub-systems such as the CRS 307a and the FMS 307b. The MPT network is designed as a secure network. Though the system has connections with many external systems, none of those connections is directly done through MPT. As seen in Fig. 2, external systems include (a) a Video phone with service that supports video calls, in which voice and video transmitted together through the data line, (b) a CRS Customer Relations System, to which MPT receives and transfers customer information before or after the service provided depending on the payment type selected, (c) a FMS Failure Monitoring Service, to which CMS transfers failures occurred in MPTs. By this means, related servicemen immediately reported about the failure (d) an SMS Center which is the center used for sending SMS messages, (e) an E-Mail Server, (f) A Bank Authorization Host, which MPT sends and receives necessary banking data. Connection can be done with more than one bank.

The Central Management System

The function of the CMS includes, but is not limited to, secure data storage, acting as a gateway of the private network for outer system connections except internet and video phone applications, online communication with the MPTs, the production of reports, monitoring failures, managing Multimedia Payphone Operating Centers (MPOC), managing MPTs, version control alongside enabling remote updates and managing tariff tables used by the MPTs. The CMS s connected to several sub-systems, elaborated below. The modular design of the CMS enables the addition of new applications as an easy extension to the existing design.

Figure 4 shows the CMS module diagram 400, expanding on the roles of the framework 407 and communication handler 406. The CMS 400 is comprised of several components including, but not limited to, the FMS, the alert monitoring system 413, the event monitor 412, the reports sub-system 414, the payment handler 415, the user manager 422, the data-store 423, the Tariff Manager 418, the Unit Manager 419, the Version Manager 420 and the Content Manager 421. The framework is comprised of a service proxy 407, an alert handler 408, a data-store 409, a collector 410, an information server 411, a configuration manager 416 and a scheduler 417. Several external applications interface with the CMS including, but not limited to, the SMS sub-system 403, the e-mail server 401, the FMS 402, the CRS 404 and the VPOS switch 405 to securely interface with financial institutions.

The multi-media payphone terminal

MPTs are essentially the stand-alone devices by means of which a user can avail information made available by the system. The content provided to the user is populated by one or more content providers and the users are charged at a fixed or roving price model. The functions of the MPTs include, but are not limited to, providing payphone applications, internet-based services, content, Short Message Service (SMS), e-mail service, video phone based applications, picture and video recording, saving and forwarding media via various applications including email, city guides, banking operations and secure payment via EMV certified components. The MPTs are able to provide these applications in both connected and connectionless (except for online banking operations) states. Several services are provided by interfacing with the CMS in both states and the data is synchronized as required, to maintain consistency. Multi-tasking is another important feature within the MPTs, as the user is talking on the phone, they are also able to manipulate video based applications, etc.

Figure 5 describes MPT Module Diagram expanding on the roles of the framework 502 and communication handler 507. wherein the MPT 500 is comprised of one or more applications 501, a pricing unit 513, a tariff unit 514, one or more data-stores 515, 517, and a user manager 516. The framework is comprised of a browser API 502 used to interface with the Hardware Abstraction Layer (HAL) 503. A scheduler 504 interfaces with a transmitter 505 and a monitor 506. There are one or more data-stores 508, an alert handler 509, a file updater 512, a configuration manager 510 and a command interpreter 511.

Figure 6 describes MPT Device comprised of a screen 607, an encrypted pin pad 608, a handset 609, a keyboard and trackball 610, a printer 611, a web camera 600, shortcut keys 601, one or more guiding LEDs 603, a memory reader 604, a credit-card reader 605 and a vandal proof design 606. The MPT further has a telephone card and a control card, both proprietary to this invention, associated with it. The telephone card is a proprietary card and along with providing basic PSTN payphone functions, it also supports video phone based applications by transferring the handset to PC in case of video phone service usage, as this is a VoIP application. The MPT Control card has several capabilities including:

• Checking the AC line and turning off the PC in case of failure;

• Checking the AC line and turning on PC in case of recovery;

• Working as a watch-dog-timer and resetting the PC, if communication is lost;

• Checking the temperature, reporting to MPT, and turning off/on cooler/heater accordingly, if necessary;

• Checking the water and reporting to MPT, if water exists;

• Checking the shock and reporting to MPT, if shock applied; · Checking the door lock and reporting to MPT, if open;

• Controlling the LED guides.

The Hardware Abstraction Layer HAL, is included to solve the problems of backwards compatibility across various versions and upgrades to hardware and device drivers and to enable the control of such hardware by the CMS. The HAL acts as a layer between the applications and the hardware and all the requests are routed via the HAL and handled by it in sequence based on the defined priority. This solves the data-conflict problem between the hardware and the application. Figure 7 describes the HAL in detail. The HAL Service 700 interfaces with the card-reader device 701, a pin pad driver 702, a control card driver 703, a PSTN card driver 704, a video camera driver 705 and a system driver 706, through a common HAL interface. The card reader driver 701 in turn uses a driver-specific protocol to talk to a card reader 712 via a card reader hardware driver 707. The pin pad driver 702 also uses a driver-specific protocol to talk to a pin pad 713 via a pin pad vendors hardware driver 708. The control card driver 703 uses a custom built protocol to a control card 714. The PSTN card driver 704 uses a custom built protocol to talk to a PSTN card 715. The video camera driver 705 through a device specific driver to a web camera vendors hardware driver 709 which in turn talks to a web camera 716. A system driver 706 typically interfaces with a WMI system 710 that utilizes a WMI interface to interact with vendor hardware drivers 711 to talk to PC Hardware 717.

Figure 8 describes Sample Operation Flow for a dropped call. The operation is described between a user 800, the telephone card 801 unit and the MPT 802. When the user terminates a call, 8a an on hook signal is generated 8b between the user and the telephone card. A drop call signal 8c is then generated and this is followed by an On Hook signal 8d between the telephone card 801 and the MPT 802. This is followed by a response from the MPT to the Telephone card 8e and a message is displayed 8f for the user at the MPT. In case the called party drops the call, a reverse signal 8g is generated at the telephone card and a drop call signal 8h is generated at the telephone card. This is followed by a reverse signal 8i being sent from the telephone card 801 to the MPT 802, which is followed by an acknowledgement 8j from the MPT back to the telephone card. In the case of a line error, a line error signal 8k is generated between the telephone card 801 and the MPT 802 followed by an acknowledgement 81 in the reverse direction. This is followed by an error message 8m being displayed for the user at the MPT.

Figure 9 describes Sample Operation Flow for an incoming call). The operation is described between a user 900, the telephone card 901 unit and the browser 902. When an incoming call is received 9a, an activate ring signal 9b is generated. This is followed by an incoming call signal 9c, which is acknowledged 9d. An incoming call message is then displayed 9e for the user. This is followed by two hook off signals 9g and 9h being sent in sequence and a response 9i for the last signal 9h. This is followed by a de-activate ring 9j signal and a Line Up 9k signal. The call starts at this point and a signal is generated 91 to indicate this, which is acknowledged 9m. Once the call starts, in case the called party quits, a call terminated signal is generated 9o. This is followed by a deactivate ring signal 9p followed by a call terminated signal 9q, which is acknowledged 9r. This is followed by a message being displayed to the user 9s and a second deactivate ring signal 9t and a drop call signal 9u. This is followed by a second call dropped signal 9v which is also acknowledged 9w, followed by a user message that is displayed 9x. Figure 10 describes the Sample Operation Flow when the user is Out of credit. The operation is described between a user 1000, the PSTN card 1001 unit and the PC 1002. As the call is in progress 1003, if a situation occurs where the user is out of credit 1004, a message is displayed to inform the user 10a. This leads to a drop call signal 10b being issued, followed by a dropped call 10c. This is acknowledged at the end lOd.

Figure 1 1 describes the Sample Operation Flow when the user browses content. The user initiates the process by selecting a service 11a, which is followed by the browser 1100 loading the application lib. A service session is then opened 11c and this signal is sent to the pricing unit 1101. Card Authorization is then executed 1102 using secure channels. The service pricing commences at this time lid and this is acknowledged lie. At this point the service formally starts 1103. If a pricing event occurs, a signal is sent llf from the Pricing Unit 1101 to the browser 1100. In case there is an error in the pricing, a message is displayed llg on the browser 1100. In case the user has no credit to use the service, a message is displayed llh on the browser 1100. This leads to the service session being terminated Hi and this is acknowledged llj. The service is then terminated Ilk and the termination 1104 leads to the browser 1100 navigating to the main homepage HI. In case the user wishes to engage in a telephony service 1105, if the user wishes to terminate the service 11m a message is displayed lln on the browser 1100 asking if the user truly wishes to terminate. The user decision is recorded llo and once the user confirms the termination lip, the service is stopped llq and this stop signal llq is acknowledged by the pricing unit llr. The service termination 1106 event also checks to see if the user has NOT confirmed termination, in which case, the confirmation dialog on the browser 1100 is closed lis.

Figure 12 describes MPT Screen capture (Telephone and SMS Service in use) wherein there are a number of banners 1200, 1201, 1202, depicting various banners and choices 1203, 1204, 1205,

Figure 13 describes MPT Screen capture (Internet service) 1300 wherein the user once again has tabbed browsing options 1301, 1302, 1303, 1304, 1305, 1306 and can access other services such as email 1307, SMS 1308 Music 1309 or other screens 1310.

Figure 14 describes MPT Screen capture (Email service) 1400 wherein the user can send a message to a certain recipient 1401, with a subject 1402 and the main text 1403. The options to send 1404 and include attachments 1405 is also provided.

Figure 15 describes MPT Screen capture (Video service) 1500 wherein the user 1501 may choose to record a video 1502. The standard functions of replay 1507, sending 1508 and emailing 1509 are also available. The video can be played 1503, paused 1504, rewound 1505 and forwarded 1506. Figure 16 describes MPT Screen capture (Image service) 1600 wherein the user 1601 may choose to capture an image of themselves 1602. The image may be captured iteratively 1607, saved 1608, emailed 1609, and navigated 1603, 1604, 1605, 1606 until the user chooses the exit 1610.

Figure 17 describes MPT Screen capture (SMS service) 1700 to a particular recipient 1701 and text 1702. Standard options to send 1705, switch to recipient field 1703 and switch to text field 1704 are made available to the user.

Fig. 18 shows the general flow of the present invention. The browser application starts 1800 and the user is taken to a welcome page 1801. The user then has the choice to use a card 1802, press a function button 1803 or use the handset 1804. If the user enters a card 1802, the card approval and crediting takes place 1805. If the user presses a function button 1803, the service choice is made available to the user 1806. If the user takes off the handset 1804, the telephone service 1807 is initiated. Fig. 19 shows the service choices available to the user 1900. The service choices 1901 extend across an internet service 1902, an SMS service 1903, an email service 1904, a picture/video recording service 1905 and a video conference service 1906. Fig. 20a-c show the card approval and crediting process. The process start 2000 with checking whether there is enough credit in the pool to start the service 2001 If there is not enough credit, a check to see if the card is inside the reader 2003 is performed. If so, another check to see if the card has been changed 2002, if not, a message to insert the card is displayed 2004. In case the card has changed 2002 , the check to see if the card is inside the card reader 2003 is also performed, if so, the card type is checked 2009. In case the card is undefined, a message is shown 2010. In case it's a pre-paid card, there is a check to consider the serial number, expiry date and a read is performed 2008. Once this is done, a check to see if the card is valid and has usable credit is performed 2011. In case this is not so, an invalid card message is displayed 2007, followed by a message to insert another 2006, followed by card approval and authorization 2005, leading back to the card changed 2002 check. In case a family card has ben used, a pin is requested 2012 followed by a check to see if the pin has been entered 2013. In case the pin has ben entered, the pin is sent for verification 2014. If the pin has not been entered, a check to see if the time-limit to enter the pin has expired 2015 is performed. If so, a message is displayed 2027 followed by a check to see if the warning period is over 2028. If so, a message to ask the user to retrieve their card 2029 is displayed and if not, a check to see if the pin has been entered 2030 is performed. Once the pin is sent for verification 2014, a message is displayed to the user to tell them that their transaction is being processed 2016. A check is then performed to see if an answer is received from the verification center 2017. If not, the user is told via a message that their card cannot be verified for technical reasons 2018. If so, another check to see if the pin is correct, is performed 2019. If so, a check to see if there is usable credit to perform the service is carried out 2023, if so, the payment is made 2025 and the usable limit and successful authorization message is displayed 2026. If the pin 2019 is incorrect, a check to see if the pin trial limit has been reached 2020 is performed, if so, the "limit reached" message is displayed 2022 and if not the user is prompted to re-enter the pin 2021. In case there is not enough usable credit 2023, a message is displayed to the user 2027. A further check is performed when the card type is checked 2009 to see if the card belongs to any black lists and the expiry date is also checked 2031. A check to see if the card is valid is performed 2032 and if so, a check to see if the EMV is active is performed 2033. If so, a message to enter the pin is displayed 2034. This is followed b a check to see if the pin has been entered 2035, if so, another check to see if the offline pin has been verified 2036 is performed, if not, a check to see if the pin trial limit has been reached 2037 is performed, if so, the message about the limit being reached 2038 is displayed and if not a "pin not verified" message is displayed 2039. If the offline pin is verified 2036, a check to see if the card is available for using points 2040. If so, a usage choice is checked 2041 and if it is points, the points are checked 2042 followed by a check to see if the points are enough 2043. If the points are enough, the pre-authorization amount type is changed to points 2045. This is followed by a message to show that the approval was not taken due to technical reasons 2046 followed by a message saying that there is not enough credit on the card 2047. In case there are not enough points 2043, a waning message is shown 2044and a check is performed to see if this can continue with money 2048. If so, a pre-authorization request is sent to the center 2049, followed by a check to see if the center has responded with an answer 2058, followed by a check to see if the pre- authorization request has been approved 2051. In case the pin has not been entered 2035, a check to see if the pin entering period has expired is performed 2053 followed by a message to have the user enter the pin on time 2053. This is followed by a warning period check 2059, in case of which a message to have the user retrieve their card 2056 is displayed and if not a check to see if the pin has been entered is performed 2055 iteratively until the warning period is valid. A check to see if the telephone service is effective 2057is performed and in case this is so, a check to see if the prepaid card is used 2058 is performed. If so, the card is checked 2060 and if it is not finished, a card change message is displayed 2062followed by a check to see if the card change button has been pressed 2063 in which case the card is charged with appropriate credit 2064 followed by a check to see if the prepaid card is entered in the reader 2065. In case the card is finished 2059, 2060, a message is displayed 2069. Fig. 21 shows the telephone service in the present invention. When the handset is taken off 2100 a dialtone is received 2101 followed by a check for the dialtone 2102, if there is none, a dialtone is given 2101. If there is a dialtone a check to see if there is enough credit in the pool 2104, if not a "only free cal transaction" warning is given 2105, followed by a check to see if the free call has been placed 2106 in which case the number is dialed 2108. If no free call has been placed 2106, a warning to insert the card is displayed 2107.This is followed by a check to see if the opposite number is ringing 2111. If so, a connecting message is shown 2115, followed by a check to see if there is an answer 2116 iteratively. If so, a check to see if this is a free call 2117 is performed. If the number is not ringing 2111, an error message is shown 2113, 2114. If it is a free call 2117 an iterative check is performed to see if the call has ended 2118 and if so, the handset is taken off 2119. If this is not a free call 2117, the pricing is initiated 2120 and required checks for pricing errors 2121 are performed and messages are displayed 2122. If there is no prcint error, a check to see if the 30second window has been exceeded 2125. If so, the credit approval and crediting entry is performed 2126 and a check to see if card approval and crediting was successful 2127 and if not, the call ends 2128. Other messages associated with this flow include the credit the user has and the credit taken from the card 2129, displaying when the credit is down to 1 2130 and warning the center on rate-based pricing 2131. Further, any of the parallel service buttons to do with the internet, email, sms, picture or video services can be pressed 2123 leading to providing the user with that service choice 2124.

Fig. 22 shows the internet service which starts 2200 by checking if there is credit in the pool 2201. If not, a warning screen is shown 2202 followed by an exit choice 2203 such that the service ends when the button is pressed 2204. If there is enough credit 2201, a browser with the internet access menu is displayed 2205, with an explanation 2206. This is augmented with a pricing option 2207 wherein the user-entered address is viewed 2211, and a check for a file transaction is performed 2211 where the file is viewed iteratively 2210. If the file is not to be viewed a check to see if there is a pricing error is performed 2208 and an error message is displayed 2209. If the file is to be saved, the file save window is shown 2213 and the file is saved 2214. If the file is to be set an address is requested 2215 and the file is sent.

Fig. 23 shows the SMS service which is started 2300 and an SMS sending window is displayed 2301, followed by a check to see if a button is clicked 2302 If not, the window 2301 is displayed iteratively. If so, the service amount is shown 2303, followed by a check for user approval of the service amount 2304. If so, the approval is accepted 2305 followed by a check for the approval of the sending request 2306. If the approval is received, the pricing is done 2309, the SMS is sent 2310 and the info message is show 2311. If there is a pricing error 2308 an error message is shown 2307. If the end-service button is pressed 2312, the session ends 2313. Other messages associated with this module include information on how many characters can be used 2314, the character number 2315 and the payment amount 2316.

Fig. 24a-b show the email service in this invention. The process will start 2400 and an E-mail sending window 2401 is displayed, followed by a check to see is a add file button is clicked 2402. If so, add file window 2403 is displayed followed by file management listing files 2404. If the listing file is successful 2405, a check for chosen file attachment and size and total additional size available to send 2407. If not the error message is shown 2406. If so, copy the file in memory to temporary file 2408 followed by check to successful recording 2409. If the recording successful the info message is shown 2410, if not the error message is shown 2411. If there is no click on the add file button 2402, a check to see if the send button is clicked 2412 followed by a check to see whether receiver address entered correct 2414 and a check to see if internet service is effective 2415. If not the service amount is shown 2416 followed by a check for a user approved service amount 2417. if so, ask approval from center for sending 2418 followed by check for a center approved sending request 2419. If the approval is received, the pricing is done 2420, an E-mail is sent 2421 and the info message show 2424. If there is a pricing error 2420 an error message is shown 2423. If the receiver address entry 2414 is not correct the warning message 2413 is given to E-mail sending window 2401. If the end-service button is pressed 2425, the session ends 2426. When the arrange attachments button is pressed 2427, a check to see whether the file attached 2428. If not, the view attachment file is empty 2429 and if so, the E-mail attachments is listed 2430 and is followed by check whether the add button is clicked 2431. If the add button is not clicked, a check for a file selected, delete button clicked 2432. If so, delete file from the attachments and in message is given 2434. If not, a check to see if the close button is clicked.

Fig. 25 shows the Picture/Video Sending/ record service which is started 2500 and a preview window is displayed 2502, which is augmented with explanation 2501 and save record 2403. if the picture is saved , a check for a choice 2504 for cancel and save. If the picture is saved, a check for a saving method 2505 via E-mail and show the service amount 2506 followed by a check to see user approved the service amount 2507. If the approval is received, the pricing is done 2508, take address and Explanation info 2509 and info is sent 2510. If there is a pricing error 2514 an error message is shown 2515. When the picture is saved via saving method 2505, and show service amount 2511, followed by a check user approved the service amount 2512. If the approval is received, the pricing is done 2513, file saved by file management 2516. If there is a pricing error 2514 an error message is shown 2515. When the show preview window is saved by start/continue record and show the remaining time with process time 2403 followed by check for ending of record time 2517. If no, the record is saved 2403 and if so, wait for transaction choice 2518 and a check for hide the record chosen 2519. If so watch the recorded video 2520, if not the picture is saved. If the end-service button is pressed 2522, the session ends 2521.

Fig. 26 shows the Video Call Service which is started 2600 and a video preview window is displayed 2601 and show the target address entry box 2602, followed by a check to see if a target address is entered 2603 and a check for a valid address 2604. If not, the warning messages show 2606. If so, connect to entered address 2605 followed by check to see if the other side is answered. If not, the warning message shows 2608. If so the pricing is done 2609, and start the conversation 2610. If there is a pricing error 2611 an error message is shown 2612. If the end-service button is pressed 2613, the session ends 2614.

Fig 27 shows the pricing which is started 2700 to determine the credit amount to be collected 2701 followed by a check to see if the service is free 2702. If not, a check to see if the change card (telephone service button pressed) 2703, if not a check to see if the credit to be collected in pool 2704. If either of change card 2703 or credit to be collected in pool 2704 is true then the check to see if the service is free 2702 is performed iteratively. If change card is true 2703, a check to see if the card approval and crediting situation successful 2705. If so, collect credit transfer to pool 2706, followed by a check to see if the collection is successful 2707. If so, update the credit info on screen 2708 and successful pricing is displayed 2709. When the card approval and crediting situation is not successful 2705, a check for the card in reader card approval and crediting has been done previously 2710. If so successful pricing is displayed 2714. If not, the card approval and crediting 2711 followed by a check for the card approval and crediting situation successful 2712. If not, display the warning screen 2713 and successful pricing is displayed 2714 and followed by check for successful collection 2707. If the collection is successful update the credit info on screen 2708 and successful pricing is displayed 2709. If card approval crediting situation is successful 2713. If so, collect credit transfer to pool 2706, followed by a check to see if the collection is successful 2707 and update the credit info on screen 2708 and successful pricing is displayed 2709. If the end-service button is pressed 2715, the pricing cycle ends 2716.

Fig 28 a-b shows the shows the Card reader interrupt Flow. A check to see if the card taken off the reader during service 2800. If so, a check to see if the credit card is a card type 2801, if not, give the warning that pricing will continue until the service is ended 2802 and the card taken off the reader during service 2800 and again if not the exit end service and show service choice menu 2803. A check to see if the card inserted to reader 2804 for card approval and crediting 2805.

Fig 29 a-b shows the shows the File Management. The process will start 2900 by checking if there is flash memory present in the driver 2901. If not, give the warning message, wait memory to be inserted 2902 followed by check to see if the time to insert memory expired 2903, if so show the warning message 2904 and display the unsuccessful file listing 2905. If the insert memory is not expired, give the warning message wait memory to be inserted 2902. If the flash memory in the driver is present 2901, save the file to flash memory 2906 followed by a check for successful saving 2907. If not, error message is shown 2908 and display the successful file saving 2909. If so, show the info messages and display the unsuccessful file saving. When the files are listed, a check for flash memory present in the driver 2913, files are listed 2918 and display the successful file listing 2919. If not give the warning message, wait memory to be inserted 2914 followed by check to see if the time to insert memory expired 2915, if so show the warning message 2916 and display the unsuccessful file listing 2917.