Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/02—Reservations, e.g. for tickets, services or events
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/16—Payments settled via telecommunication systems
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/12—Detection or prevention of fraud
  • H04W12/128—Anti-malware arrangements, e.g. protection against SMS fraud or mobile malware
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/12—Messaging; Mailboxes; Announcements
  • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/06—Buying, selling or leasing transactions
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Definitions

• the present invention relates to telecommunications.
• the invention relates to methods and systems for authentication and/or verification via telecommunications.
• Mobile terminals are able to deliver information to users when needed and where needed. Users want ubiquitous access to information and applications from the device at hand. They also want to access and update this information wherever they happen to be.
• SyncML is an industry initiative to develop and promote a single, common data synchronization protocol.
• vCalendar is an exchange format for personal scheduling information. It is applicable to a wide variety of calendaring and scheduling products and is useful in exchanging information across a broad range of transport methods. A number of vendors have adopted the specification because it allows their products to exchange calendaring and scheduling information.
• vCalendar is an open specification based on industry standards such as the x/Open and XAPIA Calendaring and Scheduling API (CSA), the ISO 8601 international date and time standard and the related MIME email standards.
• the vCalendar format utilizes data normally stored within a calendaring and scheduling application, facilitating the cross platform exchange of information about items such as events and to-do's.
• An event is a calendaring and scheduling entity that represents a designated amount of time on a calendar.
• a to-do is a calendaring and scheduling entity that represents an action item or assignment. For instance, it may be an item of work assigned to an individual.
• vCard automates the exchange of personal information typically found on a traditional business card.
• vCard is used in applications such as Internet mail, voice mail, Web browsers, telephony applications, call centers, video conferencing, PIMs (Personal Information Managers), PDAs (Personal Data Assistants), pagers, fax, office equipment, and smart cards.
• applications such as Internet mail, voice mail, Web browsers, telephony applications, call centers, video conferencing, PIMs (Personal Information Managers), PDAs (Personal Data Assistants), pagers, fax, office equipment, and smart cards.
• vCard information may include elements like pictures, company logos, live Web addresses, and so on.
• a common problem with all of these existing solutions is that they do not provide common semantics for different systems and the transfer of information may not always be as secure, or at least perceived as secure by customers, as many customers wish.
• Another problem is that booking systems have multiple different and usually quite complex user interfaces. If a customer wants to both make an appointment with a dentist and book a taxi to take him or her there, the customer needs to enter all the booking information to both booking systems in different ways. While the dentist may have in place a secure method of making reservations, authenticating the client who makes the reservation and receiving payment for a booking, the taxi company may not.
• SMS text messages it becomes challenging to manage client replies for instance when a client has been given a number of questions. For example, it makes sense to use SMS text messages to ask a client which option he or she chooses, because in many countries, like in Finland, it is very common to communicate with SMS text messages and they create revenues to operators. However, if a client replies to several inquiries by sending a number of text messages, it can be troublesome to find out, which answer corresponds to a certain question because the reply does not automatically include a reference to the question.
• a service asks a client if they want to reserve, in addition to a flight ticket, also a taxi and a hotel room, and the client replies "yes" to one question but “no" to the other, the service does not necessarily know which offer the client has accepted.
• SMS short mes- sage service
• the SMS protocol provides no standardized manner for authenticating mobile users or managing sessions. Lack of standardized authentication techniques leaves systems vulnerable to fraud, while lack of standardized session management makes it difficult for service providers to keep track of which of the clients' responses correspond to which questions from the service provider. On the other hand, session management, fraud prevention and introduction of new services should not be overly complex.
• Embodiments of the invention can be utilized in a system that comprises or supports one or more payment processor computers, one or more service provider computers and one or more mediator servers. At least one of each computer or server coordinate to provide servers to user that is a holder of one or more payment cards. Some embodiments relate to the payment processor computer, other embodiments relate to the mediator server, while yet further embodiments relate to the server provider computers. It should be noted that while the user is a holder of one or more payment cards, effecting payment does not always require use or even possession of a physical card and mere information suffices in some cases, such as in online shopping. While this is convenient for honest uses, it opens possibilities for fraud.
• one specific embodiment can be implemented as a method for a payment processor computer configured to manage transactions related to one or more services provided by service providers that comprise a first service provider and a second service provider, the transactions being payable by one or more payment cards.
• the method comprises performing the following acts at the payment processor:
• the first mediator server and the second mediator server may be the same mediator server or different mediator serv- ers.
• the invention can be implemented as a payment processor computer configured to perform the acts specified above.
• the payment processor computer may be implemented as a server computer configured to communicate with the mediator server over a telecommunication net- work.
• the payment processor computer comprises a memory and one or more processing units.
• the memory stores program instructions whose execution in the one or more processing units causes execution of the acts specified in connection with the method.
• the payment processor computer may comprise multiple processing units and load-balancing unit for distributing processing load among the multiple processing units.
• the payment processor computer complies with specifications issued by Payment Card Industry ("PCI") Security Standards Council, while the mediator server operates outside said specifications.
• PCI Payment Card Industry
• This implementation facilitates introduction of new services because transactions relating to the new services can be managed by the mediator server which does not have to comply with the PCI specifications.
• the payment processor computer and mediator server may provide joint authentication of the holder of the payment cards.
• the holder of the payment cards is authenticated by the payment processor computer using a first terminal and a first set of authentication information.
• the holder of the payment cards indicates a second terminal also operated by the holder of the payment cards, and the user of the second terminal is authenticated by using the second terminal and a second set of authentication information.
• the first request is received from a first terminal and indicates a second terminal, wherein the first terminal and second terminal may share a common physical device or reside in separate physical devices but the first terminal and second terminal use different authentication information.
• the first terminal is authenticated by using one or more of: a combination of user identifier and password; a programmed microchip and a PIN code
• the second terminal may be authenticated by using a non-predictable reply address for sending a notification to the second terminal. If the user of the second terminal has been able to respond to the notification, this means that the second terminal has received the notification from the mediator server. Otherwise the second terminal or its user could not know the non-predictable reply address.
• any fraudulent ac- tion is only possible if both the authentication information used from the first terminal and the second terminal are stolen before the theft is detected and the payment cards are suspended.
• Another specific embodiment is a method for a mediator server configured to manage transactions, which relate to one or more services provided by one or more service providers and are payable by one or more payment cards.
• the method comprises performing the following acts at the mediator server:
• the invention can be implemented as a mediator server configured to perform the acts specified above.
• a still further embodiment can be implemented as a method comprising performing following acts at a service provider computer:
• the invention can be implemented as a service provider computer configured to perform the acts specified above.
• Figure 1 shows a mediator that mediates services between a service provider and a representative mobile terminal, wherein the service being provided is a booking service;
• Figure 2 shows a version of the mediator that is capable of serving multiple service providers
• FIG. 3 represents a more detailed view of the system shown in Figure 2;
• Figures 4 and 5 are signaling diagrams depicting typical use cases in a system as shown in Figures 1 through 3;
• Figure 6 shows an example of a dynamic dialog matrix being applied to a query and reply
• Figure 7 shows detailed phases of the booking process which is an example of a service offered by a service provider
• Figure 8 shows an illustrative example of a dynamic dialog matrix
• Figure 9A is a block diagram of a system configured to authorize payments from mobile terminals
• Figures 9B and 9C are signaling diagrams illustrating typical uses cases in the system shown in Figure 9A;
• Figures 10A to 10D illustrates further variations for the embodiments described in connection with Figures 9A - 9C;
• Figure 11 schematically shows an exemplary block diagram for the various information processing and/or mediating servers in the systems described earlier.
• Figures 9A through 9C and 10A through 10D relate to provisioning of services in a system wherein payments are processed by a payment processor that needs to comply with a strict set of certification requirements.
• Figure 11 relates to an exemplary hardware description for the various servers and mediators.
• the techniques disclosed herein can be used to provide a wide range of financial services and transactions, including but not limited to: booking of a primary service; booking of a related service that relates to the primary service; executing payment for the primary and/or related services.
• An illustrative but non- exhaustive list of services includes transportation, accommodation, nutrition, entertainment, services relating to health or appearances, consultation or other ser- vices.
• session management e.g., session management, authentication, fraud prevention and/or ease of service provisioning
• acquirement eg purchase, loan, lease
• acquirement is an example of a service requested by a mobile user and offered by a service provider.
• the service providers are those with whom clients want to make appointments, reservations, or other bookings and comprise the resources for the booking system to allocate.
• Service providers conduct business through service provider booking services.
• the mediator is a network based service available to the service provider booking services over the network that provides additional semantics, translation and synchronization services needed for communication of the information needed for a client to complete a transaction with a service provider.
• the service provider booking services and the mediator are preferably applications operating on network servers such as the Internet or a private intranet.
• a system will comprise a plurality of service providers and service provider booking systems (implementing service provider booking services), but it is possible to have a simple booking system for only one service provider in which case the mediator and service provider could be tightly integrated into a single application.
• Clients preferably include clients communicating on mobile telephones capable of receiving short text messages, such as Short Message Service (SMS) messages.
• SMS Short Message Service
• the mediator may communicate with mobile telephone clients through an SMS gateway.
• SMS gateways are operated by mobile network operators.
• the me- diator communicates with clients using dialogs.
• the dialogs are short messages which present information to the client and allow a simple reply.
• the dialogs preferably provide users with simple choices, such as a selection between "yes" and "no", or a simple selection from an ordered list. Dialogs can also be one way, such as an acknowledgment to a reservation.
• a transac- tion may typically involve a sequence of dialogs each involving a simple response. Dialogs involve asynchronous communication by messages.
• the system as described makes it possible to coordinate bookings among different service provider systems in order to fill a clients need, for example coordination of an airline booking with transportation to the airport.
• Figure 1 is a diagram of a simple system, wherein reference numeral 100 denotes a mediator, reference numeral 102 denotes a service provider's booking system, which is in communication connection with the mediator 100 over a data network, such as the internet.
• Reference numeral 104 denotes a user terminal having a dialog with the mediator 100 over a mobile network.
• Figure 2 shows a plurality of service provider booking systems communicating with a mediator over a network.
• Figure 3 shows a mediator 100 communicating with various service provider systems and users with telephone devices communicating dialogs.
• a reason-based customer dialog is a desirable improvement from the client's point of view, because service providers can create their own dialogs for with each different kind of booking event.
• a dialog is closely related to a certain booking situation.
• a dialog may become activated automatically at the right moment, or the client can activate the dialog as needed, or another entity in the sys- tern can send a message to the dialog process of the mediator to activate the dialog.
• the dialog process then sends an inquiry to another entity in the system or informs the client and possibly inquires client's choices.
• the client can make reservations in several booking systems using only one user interface.
• the dialog process connects to remote booking systems over an appropriate data network, such as the Internet or mobile networks.
• a mediator service can be capable of transmitting booking information between service provider booking systems. For example, after a booking is entered into an airline booking system, a taxi booking system can offer the client a lift to the airport.
• a booking is an allocation of a single resource (either the airline booking or the taxi in the previous example), while a reservation is the union of the bookings for all of the resources for the same event (the airline booking plus the taxi booking in the previous example).
• the dialog between the client, the mediator and the booking systems as well as stored custom- er profiles ensure that the client gets the reason-based service he or she needs, not intrusive advertising.
• a client can make reservations as well as confirm, change, and cancel them using many kinds of communication means, including but not limited to the Internet, e-mail, and mobile terminals.
• the client can also synchronize a calendar provided by the mediator or a service provider with a calendar in a terminal device using mediator's synchronization functions.
• a service provider can remind clients to make reservations on a regular basis and thus increase customer loyalty.
• a mediator can help service providers to bring their booking systems together to provide more comprehensive services without extending their businesses unnecessarily. Because of internationalization, the mediator is able to support for example many languages, time zones, currencies, and data formats.
• the system including at least a mediator, a dialog process, a service provider, and a service provider booking system, can be on one of the following lev- els:
• dialogs There is a predetermined set of dialogs in the system. Their content and the possible choices are set in advance. For example, if a client books a flight, a dialog always offers certain other bookings. Client's prior actions are not taken into consideration.
• a dialog process may include a high-level expert system. It can act as an agent and negotiate with several service providers to get the best offer without client's direct involvement.
• a client books a service from a service provider.
• the booking may be carried out using a terminal that is connected to the mediator service.
• the client connects to the mediator service using a dialog.
• the client inputs a reservation inquiry to the dialog process that sends the inquiry to the mediator.
• the mediator inquires possible reservations from the service provider's information system using concepts and terminology that those services are able to interpret.
• the inquiry is based on client's preferences.
• the client discloses some preferences that are related to the specific booking when they enter the reservation inquiry to the dialog.
• the dialog process and the mediator service may have stored a client's general preferences and use them so that the client do not need to input all the preferences each time.
• management of the inquiry and booking processes may be based on sophisticated state models.
• Each booking process in- volves several phases that are described by states that track its status through its life cycle. For example, when the mediator has inquired about a reservation from a service provider, the corresponding entry in each system has a state that the booking is pending but not confirmed. If the systems do not have common understanding what a certain state means, the mediator translates them.
• a preferred booking process including the phases and states is described in Example 1.
• the mediator In addition to inquiring reservations from the service provider, the mediator is able to synchronize bookings in several service providers' systems. The synchronization is based on rules specified in the mediator service. For example, a rule can be that "if a client inquires booking for an airline ticket, inquire also bookings for taxis to the airport.” Therefore, an inquiry from the client may be multiplied in the mediator service resulting a number of inquiries.
• the service providers answer to the mediator if they are able to provide requested service and they may add some additional information, like on seats or timing.
• the mediator combines gathered information and sends it to the dialog process that shows a simple list of options to the client.
• the dialog process may show three options for a flight and ask if the client also wants to reserve a taxi that is actually already tentatively booked by the mediator.
• the client makes his or her decision by choosing the options from the simple list of alternatives.
• the dialog process sends information on the client's choice to the mediator that confirms the bookings in accordance with client's choices and cancels the unnecessary reservations.
• Figure 4 shows a sequence diagram of an inquiry CINQl originated by a client using a dialog DINQ1 sent to the mediator.
• the mediator initiates the inquiry MINQ1 which corresponds to CINQl and DINQ1 to booking system 1 a service provider booking system.
• an answer DANS1 gets back to the client offering a choice which is responded to with a selection CSELl resulting in a booking by the client on booking system 1.
• the mediator recognizes the potential need for a complementary service from booking service 2 and initiates an inquiry, MINQ2, to booking system 2, which ultimately results in a proposal including several choices, DANS2, returned to the client from which a selection, CSEL2, is made, resulting in a complementary booking on booking system 2.
• the bookings can be done in other means as well, for instance, by calling the service provider with a telephone or by visiting on site the service provider's office.
• the service provider may inform the mediator about client's bookings so that the mediator can inform the client on other options.
• a dentist could tell the mediator that the client has booked an appointment so that the mediator may offer to book a taxi also.
• the mediator can send a notice to the client that it has been a year since the client last had an appointment with his or her dentist and ask if the client wants to make a new appointment.
• This notice can already include a few options for the appointment.
• the mediator has checked the client's calendar if he or she has allowed that so that the given options are convenient for the client.
• the dialog shows the options in a simple and handy way. The client needs only to choose which option is the best for him or her or whether he or she wants to get new op- tions or postpone the booking.
• Figure 5 is a time sequence chart for a situation where the original inquiry, MINQ1, was initiated by the mediator.
• the mediator 100 is designed to interface with various service-specific systems generally denoted by reference numeral 122. These systems may be used to provide the services (including physical goods) described earlier.
• the mediator 100 interfaces to the service-specific systems 122 over a data network such as the Internet.
• the mediator 100 further interfaces to client terminals, such as mobile terminals ca- pable of receiving text messages, over a mobile network.
• client terminals such as mobile terminals ca- pable of receiving text messages
• interfacing of the mediator 100 to the various service-specific systems 122 and other parties may be accomplished by means of generic XML definitions.
• the mediator 100 may support vCard and vCalendar standards, since they are used by many major booking and calendar systems.
• the mediator 100 communicates with the mobile terminals and their users using Short Message Service (SMS) via an SMS Gateway for asynchronous communication.
• SMS Short Message Service
• the mediator 100 may comprise a customer dialog process 124 configured to use Dynamic Dialog Matrix (DDM) technique, which may be used to facilitate authentication and/or session management, as will be described in more detail in connection with Figures 4 through 8.
• DDM Dynamic Dialog Matrix
• the booking processes of the ultimate service providers only cover normal booking with regard to time and resource reservation.
• the booking processes of the mediator comprise booking, work, and financing. Both processes lead to the same point.
• the process of the mediator comprises seven phases as follows:
• Filing means initialization of a mediator process and a booking process. As a result of the initialization an entry is inserted in the database with basic information. It will not appear in a calendar since there is no scheduling information. It can be displayed in a separate task list of the owner as an open task. 2. Requesting
• Schedule is given to the owner and the resources. As a part and a result of the Scheduling the following data is needed:
• the data is copied from the Requesting and/or Scheduling phases.
• the same data structures can be used for this and status indicates the actual meaning of the data.
• Figure 7 shows the work flow transitions from phase to phase. For conditions, see the table above. Also, please note that Canceled Status always leads to accounting.
• the organizer/application has to make the decision of what to do with the reservation. That can be an automatic decision made by the system based on pre-set rules or made by the organizer manually.
• FIG 6 shows an example of the dynamic dialog matrix applied to a query and reply.
• An application sends a service request to a user to a mediator B.
• the mediator B picks up random B address from a group of available B addresses wherein it can receive responses from the user.
• the mediator B sends a query to user A, wherein the query may consist of a list of choices from which the user A may select the reply.
• the user A receives the query in their terminal and sends a reply to that query to the B address.
• the mediator B receives the user's reply in the B address.
• the mediator B processes the reply.
• First the mediator B validates the A address (which is the user's address).
• the mediator B may inform the application that no response was received.
• the mediator B verifies the B address (the reply address into which the reply was received).
• the mediator B may in- form the application that no response was received.
• the mediator B matches the reply C to the list of available choices for that message. If the reply does not correspond to the available list of choices, the mediator B may send an error information to the application, or send a new query to the user A. If the re- ply corresponds to the available list of choices that was sent to the user, the mediator B sends a return service response to the application.
• the system as described in connection with Figure 6 may have a plurality of B subscriber addresses, such as telephone numbers, wherefrom the mediator B may select a subscriber number where the message to the user A is sent. Further, the user A preferably has a mobile telephone, having a mobile subscriber number, whereto the message is sent, and wherefrom the user A may respond to the que- ry.
• the messages to and from the mediator B are sent over the telecommunication network.
• a major problem solved by the dynamic dialog matrix is the challenge of managing client replies, when a client has been given a number of questions and the client is using SMS text messages or similar technology in which a reply does not automatically include an explicit reference to the inquiry.
• An inquiry always includes some kind of receiver's address or identification.
• B subscriber's number In the SMS text message case that is so called B subscriber's number.
• sender's A subscriber's number or Calling Line Identity (CLI), or similar identification is also attached to each text message. Therefore the client or B subscriber is usually easily able to answer a message using mobile device's answer or reply function.
• CLI Calling Line Identity
• a mediator service that sends inquiries to a client uses different A subscriber numbers in different inquires, it is possible to differentiate between answers based on which number the client is sending replies to. For example, if a mediator sends a client an inquiry "Do you also need a taxi?" using A subscriber number Al and then inquiries "Do you need a hotel room?" from A subscriber number A2, client's reply to the first question goes to number Al and the second answer goes to number A2.
• a mediator keeps track on inquires and answers. In the matrix, there is a column for each client and a row for each A sub- scriber number the mediator is using. Obviously, there could be a row for each client and correspondingly a column for each A subscriber number as well.
• the mediator After sending an inquiry from a certain A subscriber number to a client, the status and the reply is stored in the corresponding cell of the matrix. As a result, the mediator is able to find out whether the client has replied to a certain inquiry and what the answer was. Also, it is possible to use the matrix to collect information about clients' behavior and use it for example for marketing purposes. A mediator needs only a limited number of A subscriber numbers. A dialog matrix can also be used to find out which A subscriber numbers can be used when the next inquiry to a certain client is sent.
• the Dynamic Dialog Matrix is also a powerful but very simple security measure for authenticating a mobile phone user who has only the capability of sending and receiving messages.
• the problem is for a service to confirm a sender's identity.
• One way to try to identify the user is to check the sender's address.
• Normally SMS, e-mail, and other alike messages have the sender's address attached. That address can be for example the sender's A-subscriber's number or Calling Line Identity (CLI), or e-mail address or IP address.
• CLI Calling Line Identity
• the downlink from a service provider to a user is usually relatively reliable and it is hard for others to capture or change messages, but the uplink from a user to a service provider is much more vulnerable and it is not too difficult to give a wrong sender's address.
• a well-known solution to the above problem is to use encryption technologies to secure the communications, public-key infrastructures (PKI) being good examples.
• PKI public-key infrastructures
• a user device can be equipped with a microchip, a secure SIM card in GSM devices for example, to encrypt messages using the user's private key. Then the service provider can be sure that the message is from the user, if it can be decrypted using the user's public key.
• PKI public-key infrastructures
• each request contains a different, preferably randomly chosen, reply number.
• reply number preferably randomly chosen, reply number.
• An example is for authenticating a user who is making a purchase, eg purchasing a software product "ABC".
• the user first initiates a purchase request to the company/service, eg directly in the software program, via an internet website or via a mobile device.
• the company/service then knows the user name and possible other identification information and sends a request to a credit card company to request a payment.
• the credit card company then sends a request to a mediator to authenticate the purchase.
• the mediator knows the user and the user's mobile number and sends a message, eg SMS or MMS, to the user's known phone number.
• An example of a message could be:
• An additional element of safety and security can be achieved using semantic analysis. For example, if the user is asked to tell how many items are ordered, and the answer is "y” or "yes ", then apparently the user did not know what the question was and the message was not an answer for the enquiry.
• Such a system can also provide a level of security for the user.
• the mediator can authenticate the company/service, by any acceptable method, and only send authentication messages once the company/service has been authenticated. Then, if the user does not provide their mobile number when providing their identification information, when they get an authentication message, even from a number they do not recognize, they will know that the mediator has authenticated the company/service.
• the message could be sent by a secondary entity at the request of the mediator.
• the mediator can then provide the user's bank with the necessary transaction details and request that the bank send the necessary authentication method.
• Another example would be if the mediator sends a request to the bank for some of the user's identity information, eg mobile number, so that it can proceed with sending the actual request itself or through a tertiary service provider which handles the actual message sending.
• DDM Dynamic Dialog Matrix
• a DDM which is being used for verification purposes can contain, or have access to, multiple of some or all of the following: reply addresses used for sending messages, reply addresses for which messages are received, user addresses, questions, acceptable answers for questions, order of receiving answers and verification information (eg product keys, ID codes).
• a key to the DDM is that it allows verification between a company /service and a user through a mediator (and possibly through another party) by matching information that each entity knows and the others should not know.
• a user downloads a piece of software from the internet they want to know that the software is legitimate, ie, not pirated or hacked, while software developers want to make sure that users are paying to activate their programs. Therefore, prior to use the user is requested to enter a product key.
• the user sends a message, eg SMS, to a number with a product ID code. If the ID code is valid and has not been previously registered then the user receives a message with the product key. Therefore, the DDM matches the user entered product ID code with an indicator if it has been registered to verify if a product key should be issued.
• a similar process could work in conjunction with the payment process described above.
• an additional message can be sent to the user with the applicable product key.
• a similar method and system can be used to verify the legitimacy of virtually any product, such as medicine or trademarked products. If the product has a code printed on the packaging and a known number associated with the products manufacturer or verification then a consumer can send a message to the known number with the product code to receive an indication if the code is valid and if it has been previously checked. Benefits to this system are that if pirated products do not have a code printed on the product or have an invalid code then the user will know right away. Additionally, if multiple users check the same code then the product manufacturer or verifier can check in to if the code has been reproduced by a manufacture of a pirated product.
• a further benefit to the system is that the product manufacturer can immediately send an inquiry back to the user if the product is determined to be pirated or suspected of piracy.
• An inquiry may be to ask where/when the product was purchased, what the purchase price was and/or other information which can be used to identify the entity responsible for the piracy or distribution of pirated goods.
• Figures 9A through 9C illustrate how an embodiment of the invention can be used to authorize recurring mobile payments.
• Figure 9A is a block diagram of an embodiment of the invention, which can be used to authorize mobile payments
• Figures 9B and 9C are signaling diagram illustrating series of events in the system shown in Figure 9A.
• a mobile payment refers to a payment transaction effected over a mobile network.
• PCI Payment Card Industry. Compliance specifications for the PCI-compliant environment 9-100 are published by PCI Security Standards Council, currently on address www . pcisecuritystandards . org.
• the elements in the PCI-compliant environment 9-100 include a payment processor 9-200, its associated database 9-202 and at least one merchant 9-250 as a legal entity.
• the database 9-202 stores general account and address infor- mation 9-210 on the users and merchants. While storing such information is considered good housekeeping for auditing or the like, it is strictly speaking not essential for the present embodiment.
• Some of the merchants 9-250 operate respective online stores or service providers 9-400, 9-401 through 9-40n outside the PCI-compliant environment 9-100. When a representative service provider is dis- cussed, reference numeral 9-400 is generally used, while reference numerals 9- 401 through 9-40n may be used when individual service providers need to be referenced.
• mediator 9-300 is a version of the mediators 100 described earlier, the present version being adapted to mediate between entities both inside and outside the PCI-compliant environment 9-100.
• the user 9-600 has multiple roles. Firstly, the user is a customer of the processor 9-200 and accordingly, a holder of one or more payment cards, one of which is denoted by reference numeral 9-610. While reference numeral 9-610 denotes the payment card, reference numeral 9-612 denotes the information on the payment card 9-610 that suffices to globally identify the payment card. In other words, knowledge of the complete information 9- 612 enables anyone having that knowledge to make payments (honest or fraudu- lent) that may be chargeable to the holder of the payment card 9-610.
• the user 9- 600 is also a subscriber of a mobile access network 9-500 and a user of at least one mobile terminal 9-620. [0086] When the system according to Figure 9 is put into use, the following assumption and conditions are in force.
• an initial trust relation between the payment processor 9-200 and mediator 9-300.
• the trust relation may be established by legal contracts signed between the operators (as legal entities) of the processor 9- 200 and mediator 9-300, and the legal entities instruct the processor 9-200 and mediator 9-300 (as network nodes) to trust each other.
• an "initial trust relation” may mean, for instance, the processor 9-200 authorized the mediator 9-300 to process transactions within a set of initial limits. During operation of the system, the limits may be increased.
• the set of initial trust relations have a few gaps, however. Firstly, because the processor 9-200 must operate in the PCI-compliant environment 9-100, it is imperative that the complete credit card information 9-612 (that is, information sufficient to make fraudulent purchases) is not conveyed outside of the PCI- compliant environment. This means, for instance, that although the mediator 9- 300 is trusted to mediate payment card transactions between service providers and mobile users (as payment card holders), the mediator must be able to operate without information that globally identifies the users' payment cards. Furthermore, it is an open question what links each user's payment card(s) 9-610 and mobile terminal(s) 9-620.
• step 9-2 the user 9-600 performs a registration to the web site of the processor 9-200.
• the user 9-600 authorizes an exemplary service provider 9-401 to offer services that may be charged against the user's payment card 9-610.
• the registration may be performed over the internet by utilizing any in- ternet-enabled terminal, which may or may not be the same terminal as the user's mobile terminal 9-620.
• the user may be authenticated by utilizing bank authentication, for example.
• the initial registration 9-2 may require bank authentication or some other form of strong au- thentication, while subsequent uses, such as configuration changes, may require lesser authentication, such as a user ID / password combination that is issued during the initial registration 9-2.
• the processor 9-200 stores information on the permission given by the user 9-600.
• the processor 9-200 may store an information tuple 9-212 that comprises the user's true identity, mobile identity, payment card number and the service provider's identity.
• the information tuple 9-212 is considered good housekeeping for auditing purposes while, strictly speaking, it is not absolutely necessary to effect payments.
• step 9-6 the processor 9-200 creates a "token" 9-214 that indicates to the mediator 9-300 that the information tuple 9-212 has been established.
• the token 9-214 is a filtered or reduced version of the information tuple 9-212 that fully identifies the permission given by the user 9-600 to the service provider.
• the full identification information 9-612 on the user's payment card(s) may not be conveyed to entities outside the PCI-compliant environment.
• the token 9-614 only contains sufficient information to identify a specific payment card 9-610 to the user / card holder 9-600.
• PaymentCardREF such information is shown as “PaymentCardREF” in the drawings, as this information item enables the mediator to reference the specific payment card 9-610 to the user / card holder 9-600.
• the "PaymentCardREF” information item may have a value of "VISA 4567", whereby it identifies the specific payment card among the present user's payment cards but fails to globally identify the payment card.
• the issuer/payment processor 9-200 sends the token 9-214 to the mediator 9-300.
• the issuer/payment processor sends the token to the service provider 9-401.
• the service provider 9-401 detects an opportunity to send a service offer to the mobile terminal 9-620 of the user 9-600.
• the service provider 9-401 may detect that the user is about to request or has requested some service (s) from the service provider, and the service provider may offer some related service(s) to the user.
• the user 9-600 may navigate to the service provider's web site and request information on services, thereby permitting sending of service offers to the user's mobile terminal.
• the service provider 9-401 sends a service proposal to the mediator 9-300.
• the service proposal 9-22 contains an identifier of the token 9-214 that was created in step 9-6.
• the service proposal 9-22 further contains details of the offer, such as what is being offered and at what price, etc.
• the mediator 9-300 reformats the offer and relays it to the user's mobile terminal 9-620.
• the reformatted offer 9-24 contains the "PaymentCardREF" information item, which only identifies the payment card to the user / card holder 9-600 but fails to globally identify it. While the reformatted offer 9-24 is sent to the user's mobile terminal 9-620, the service provider 9-401 does not have to send the mobile ID to the mediator 9-300 because the mobile ID can be obtained from the token 9-214 that was sent to the mediator in step 9-8.
• step 9-26 the user 9-600 responds from their mobile terminal 9-620.
• the user 9-600 user only has to send a " for "Yes” and anything else (including no response) for "No", for example.
• the offer may contain a list of choices (e.g. A, B, C, D) from which the user selects one by replying a "A" for choice A.
• the DDM technique keeps track of which response from the user corresponds to which service offer from which service provider.
• the mediator 9-300 utilizes the DDM technique and thereby identifies which service offer the user is responding to.
• the mediator 9- 300 may request acceptance from the issuer/service provider 9-200, which may perform a credit check, for example. If the outcome of the credit check is positive, the issuer/service provider 9-200 provides an acceptance to the mediator's request.
• the exchange of messages 9-30 and 9-32 serves two purposes. Firstly, the mediator conveys information on the user's acceptance to the issuer/payment processor 9-200 for charging purposes, and secondly, the mediator requests the issuer/payment processor 9-200 to carry any credit or security checks compliant with the policies of the issuer/payment processor. In step 9-34, provided that the outcome of the check(s) is positive, the mediator 9-300 forwards the user's acceptance to the service provider 9-401.
• step 9-36 the mediator, the issuer/service provider and/or the service provider may send a confirmation to the mobile user/card holder 9-600. Strictly speaking, the confirmation is considered good manners and good housekeeping, but is not absolutely essential for providing the requested service.
• the step 9-30 through may be executed in different orders and/or by different entities. As is apparent from the drawing, after step 9-34, each of the mediator, issuer/service provider and/or service provider know equally well that everything is in order, and any entity can send the confirmation to the mobile user.
• the service provider 9-401 is an airline carrier.
• the opportunity-detecting step 9-20 may be implemented such that airline carrier is an example of a merchant 9-250 inside the PCI- compliant environment 9-100, and this entity notifies the service provider 9-401, which is an example of an online store outside the PCI-compliant environment 9- 100.
• the airline carrier's online store may use the opportunity 9-20 to offer additional services, in which case the payments may be processed as described in connection with Figure 9B (initial preparatory steps 9-2 to 9-8, recurring steps 9-22 to 9-34).
• the first service may be an airline ticket
• the additional services may include one or more of a seat upgrade, user-selectable seat, shuttle service, or any additional service provided by the service provider 9-401 by using the token created in steps 9-6 ... 9-8.
• the mediator 9-300 determines which related service providers may send offers to the user 9-600, in a situation wherein a token exists for the user 9-600 and an original service provider 9-401.
• the original service provider means the one from whom the user has requested one or more services.
• the mediator 9-300 may determine which related service providers may send related offers to the user 9- 600. For instance, the operators of the various service providers (as merchants / legal entities 9-250) may agree on a set of initial trust level and a set of initial rules, and these sets of rules are delivered to the mediator. In a more ambitious implementation, the mediator 9-300 may dynamically adjust the trust level and/or the rules. For instance, the mediator 9-300 may adjust the trust level and/or rules based on implicit and/or explicit feedback from the users.
• the mediator 9-300 monitors the acceptance rates of service offers from the service providers and increases or de- creases the trust level depending on whether the acceptance rate meets or fails to meet some static or dynamic threshold value.
• a limitation of this technique is that the trust level of service providers is based on acceptance of the offer but the actual quality of the service is not evaluated.
• the mediator 9-300 monitors feedback from the users, which is sepa- rate from the acceptance of service offers. Such separate feedback, which may be entered from the users' mobile terminals or web terminals, may take into account the actual quality of the service.
• service provider 2 denoted by reference numeral 9-402 is one that meets the mediator-implemented criteria such that the service provider 2 is permitted to send offers to the user 9-600 that has already accepted offers from service provider 1 (and creation of a token for that service provider 1).
• the second major section in Figure 9C namely steps 9-42 through 9-56, relate to creation of a token for recurring payments from the user 9-600 to service provider 2, 9-402. What these steps accomplish, is largely analogous with creation of the token for recurring payments from the user 9-600 to service pro- vider 1, 9-402, that was described in connection with Figure 9B (see steps 9-2 through 9-8 for details). The actual implementation is different, however.
• steps 9-42 ... 9-56 it is not the user 9-600 who has the initiative but the mediator 9-300. Accordingly, the user need not explicitly register mobile payments for each individual service provider.
• Steps 9-42 through 9-56 illustrate one way of accomplishing that.
• step 9-26 the mediator 9-300 knows that the user 9-600 has authorized mobile payments for services from service provider 1, 9-401.
• the me- diator 9-300 now uses this piece of information and, in step 9-42, prompts the processor 9-200 to request permission to create a token for the combination of user 9-600 and service provider 2, 9-402.
• step 9-44 the processor 9-200 requests permission from the user 9-600 to create the token.
• step 9-46 the mediator 9-300 relays the request to the mobile terminal 9-620 of the user 9-600.
• the user accepts the creation of the token and sends an affirmative response (eg ⁇ ") in step 9-48.
• step 9-50 the user's permission to create the token is conveyed to the processor 9-200, which creates a record indicating the user's permission in step 9-52.
• step 9-54 the payment processor creates the actual token, which is sent to the mediator in step 9-56.
• steps 9-52 through 9-56 are similar to the respective steps 9-4 through 9-6 in which the first token was created in Figure 9B.
• the user needs to authenticate him/herself and/or specify which offers from multiple simultaneous service offers from one or more service providers are accepted and which are declined. It is possible to utilize the DDM technique described earlier in this patent specification to provide authentication and/or matching user responses to service offerings. In some implementations the DDM technique may be omitted, at least for low- valued transactions and/or in connection with users with good history.
• Steps 9-62 through 9-76 in which the service provider 2, 9-402 sends an offer to the user 9-600 and the user accepts, are analogous with the respective steps 9-22 through 9-34, the sole difference being the service provider.
• steps 9-22 through 9-34) it was service provider 1
• steps 9-62 through 9-76 it was service provider 2.
• Figures 10A to 10D illustrate further variations for the embodiments described in connection with Figures 9A - 9C.
• elements with reference numbers beginning with "10-” are described here for the first time. The remaining elements have been described in connections with earlier drawings, and a duplicate description is omitted.
• PCI Payment Card Industry
• the mediator 10-300 generally corresponds to the mediator 9-300 de- scribed in connection with Figures 9A - 9C.
• the difference to the prior implementation is that the mediator 10-300 resides inside the PCI-compliant environment 9-100 and naturally complies with all of the PCI infrastructure specifications and certifications.
• the signaling diagrams shown in Figures 9B and 9C are directly applicable to the implementation shown in Figure 10A.
• the fact that the mediator 10-300 resides inside the PCI-compliant environment and complies with the PCI specifications and certifications may have a variety of different implementations, including some or all of the following:
• the mediator may be implemented and operated by a legal entity whose employees undergo security clearance.
• the mediator or at least critical portions of it, are programmed or monitored by one or more well-trusted parties, and the integrity of the mediator is verified with cryptographic techniques. For instance, certificates verified by a trusted entity may be used. Alternatively or additionally, some critical portions of the mediator may be firmware coded in a manner similarly to mobile SIM cards, which are authenticated by using a challenge- response mechanism.
• the authentication algorithm that runs on the SIM is typically given a 128-bit random number (RAND) as a challenge.
• RAND 128-bit random number
• the SIM runs an operator- specific confidential algorithm which takes the RAND and a secret key Ki stored on the SIM as input, and produces a 32-bit response (SRES) and a 64-bit long key Kc as output.
• the same authentication scheme can be used in such a manner that the issuer/payment processor (as a legal entity) acts as the mobile operator acts in the SIM card example.
• the entire software of the mediator, or a critical subset of it may be coded, or at least inspected, by experts trusted by the issuer/payment processor.
• the software which includes the critical parts of the mediator functionality and the challenge-response mechanism, may be coded into firmware from which the mediator (as proxy server) may execute it.
• FIG 10B is a signaling diagram, which shows a variation from the signaling diagram shown in Figure 9C.
• the mediator performs two kinds of tasks.
• step 9-42 the mediator initiates a procedure which results in creation of a token for the combination of a user N and server provider 2, provided that a token already exists for the same user N and a related service provider 1.
• step 9-64 the mediator mediates a service offering from service provider 2 to the user N and relays the acceptance from user N to service provider 2 and to the issuer or payment processor.
• the issuer/payment processor 9- 200 directly obtains the permission to create the token for user N 9-600 and service provider 2, thus bypassing the mediator in the token-creation step.
• the issu- er/payment processor 9-200 proposes token creation to the user in step 10-44 and obtains the user's permission in step 10-48.
• Step 10-44 corresponds to steps 9-44 and 9-46 of Figure 9C
• step 10-48 corresponds to steps 9-48 and 9-50, apart from the fact that the mediator is bypassed, at least for this particular case.
• issuer/payment processor 9-200 is a party, which is trusted by each of the other entities, the fact that the authorization to create the token was obtained by the issuer/payment processor makes it easier for issuer/payment processor and the other entities to trust the mediator.
• the mediator may mediate the token-creation step similarly to the case shown in Figure 9C (steps 9- 48 through 9-56), but in this variation the issuer/payment processor 9-200 directly obtains the user's authorization to some or all of the individual transactions. What this means is that the mediator is bypassed in steps 9-64 through 9- 72 for some or all transactions. For instance, the issuer/payment processor may decide to bypass the mediator for some or all of the following cases:
• the parties other than the issuer/payment processor namely the mediator, user and service provider, have a low initial trust value.
• the initially low trust value is increased for any successfully completed transaction.
• a high-valued transaction increases the trust value of the parties of the transaction more than a low-valued transaction does.
• the trust value may be lowered by time, delayed payments or other forms of suspected behavior. If any party of a transaction has a low trust value, or a combination of the trust values of the parties of the transaction is low, either on an absolute scale or in comparison with the value of the current transaction, the issuer/payment processor may decide to bypass the mediator and obtain the us- er's authorization directly.
• FIG. 1C The signaling diagram of Figure IOC shows a different variation from the one shown in Figure 9C.
• steps 9-42 through 9-56 are similar to those shown in Figure 9B and 9C.
• the mediator 9-300 is in charge of obtaining the permission for the token creation from the mobile user 9-600.
• Figure IOC differs from Figure 9C in that the final confirmation 9-76 from the issuer/payment processor 9-200 to the mobile user 9-600 is preceded by a confirmation check 10-74, 10-76 between the issuer/payment processor 9-200 to the mobile user 9-600.
• the issuer/payment processor 9-200 may, at least for some of the individual transactions, bypass the mediator 9-300 and directly obtain the user's authorization to some perform or all of the individual transactions.
• the signaling diagram of Figure 10D shows a yet further variation from the one shown in Figure 9C.
• two mediators denoted by reference numbers 10-301 and 10-302 have been implemented.
• Each of the two mediators can correspond to the mediators 9-300, 10-300 described earlier.
• either mediator or both of them may reside inside or outside the PCI- compliant infrastructure 9-100.
• the messages and acts 10-xxx performed in Figure 10D are identical with messages and acts 9-xxx performed in Figure 9C, apart from the fact that messages and acts up to and including message 10-50 relate to mediator 1, while messages and acts beginning at message 10-50 relate to mediator 2.
• the first mediator 10-301 mediates the process of obtaining the mobile user's permission to create the token for the combination of the user and service provider 2, while the second mediator 10- 302 manages the process of obtaining the mobile user's permission to carry out individual transactions.
• the two mediators 10-301 and 10-302 are operated by mutually independent operators, the division of tasks between the two mediators makes it easier for the other parties to trust the mediators 10-301 and 10- 302. This is because a single fraudulent operator cannot actually benefit from fraudulent operations.
• the operator of the first mediator 10-301 was fraudulent and signaled authorizations for token creation without actually obtain- ing the mobile user's permission.
• This kind of fraudulent operation would be detected almost immediately because the confirmations for the individual transactions are mediated by the second mediator, which is operated by a different operator from that of the first mediator.
• the second mediator cannot act fraudulently unless the transaction involves a service provider for whom the mo- bile user has already authorized recurring payments via the first mediator. What this means is that benefiting from fraudulent behavior requires cooperation from three entities, namely at least one service provider plus the operators of the two mediators.
• the issuer/payment processor 9-200 may, at least for some permissions and transactions, bypass one or both the mediators and directly obtain confirmations from the mobile users, as described in connection with Figures 10B and IOC.
• the token may have a number of restrictions associated with it.
• the restrictions may apply to the lifetime of the token and/or to the value of financial transactions made by using the token.
• the lifetime restrictions may be defined in calendar time, such as a validity period terminating on a predefined day, or in number of uses, such as token that can be used for n transactions, wherein n is an integer.
• the value of financial transactions made by using the token may be restricted. For instance, any single transaction may be limited to an upper limit or the token may expire as soon as it has been used to execute transactions totaling over a given value.
• the restrictions associated with the tokens may be enforced by the issuer/payment processor 9-200, the mediator(s) 9-300, 10-301, 10-302, and/or the service providers 9-401, 9-402.
• FIG. 11 schematically shows an exemplary block diagram for the various information processing and/or mediating servers in the systems described earlier.
• a server architecture generally denoted by reference numeral 11-100
• the two major functional blocks of the database server system SS are a server computer 11-100 and a storage system 11-190.
• the server computer 11-100 comprises one or more central processing units CP1 ... CPn, generally denoted by reference numeral 11-110.
• the server computer 11-100 further comprises a network interface 11-120 for communicating with various data networks, which are generally denoted by ref- erence sign DN.
• the data networks DN may include local-area networks, such as an Ethernet network, and/or wide-area networks, such as the internet.
• the server computer 11-100 acts as a mediator 100, it may serve one or more service-specific systems 122 via the data networks DN.
• Reference numeral 11- 125 denotes a mobile network interface, through which the server computer 11- 100 may communicate with various access networks AN, which in turn serve the mobile terminals MT used by end users or clients.
• the server computer 11-100 of the present embodiment may also comprise a local user interface 11-140.
• the user interface 11-140 may comprise local input-output circuitry for a local user interface, such as a keyboard, mouse and display (not shown).
• management of the server computer 11-100 may be implemented remotely, by utilizing the network interface 11-120 and any internet-enabled terminal that provides a user interface. The nature of the user interface depends on which kind of computer is used to implement the server computer 11-100. If the server computer 11-100 is a dedicated computer, it may not need a local user interface, and the server computer 11-100 may be managed remotely, such as from a web browser over the internet, for example. Such remote management may be accomplished via the same network interface 11-120 that the server computer utilizes for traffic between itself and the client terminals.
• the server computer 11-100 also comprises memory 11-150 for storing program instructions, operating parameters and variables.
• Reference numeral 11- 160 denotes a program suite for the server computer 11-100.
• the server computer 11-100 also comprises circuitry for various clocks, interrupts and the like, and these are generally depicted by reference numeral 11- 130.
• the server computer 11-100 further comprises a storage interface 11-145 to the storage system 11-190.
• the storage system 11-190 may store the software that implements the processing functions, and on power-up, the software is read into semiconductor memory 11- 150.
• the storage system 11-190 also retains operating and variables over power- off periods.
• the storage system 11-190 may be used to store the dynamic dialog matrices associated with the clients and mobile terminals MT.
• the various elements 11-110 through 11-150 intercommunicate via a bus 11-105, which carries address signals, data signals and control signals, as is well known to those skilled in the art.
• the inventive techniques may be implemented in the server computer 11- 100 as follows.
• the program suite 11-160 comprises program code instructions for instructing the set of processors 11-110 to execute the functions of the in- ventive method, wherein the functions include performing the service provisioning and/or mediator features according to the invention and/or its embodiments.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Computer Security & Cryptography (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Finance (AREA)
• Tourism & Hospitality (AREA)
• Development Economics (AREA)
• Economics (AREA)
• Entrepreneurship & Innovation (AREA)
• Human Resources & Organizations (AREA)
• Marketing (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (1)

Applications Claiming Priority (4)

Publications (1)

Family

ID=49382984

Family Applications (1)

Country Status (2)

Citations (3)

• 2013
  • 2013-04-18 DE DE112013002111.0T patent/DE112013002111T5/de active Granted
  • 2013-04-18 WO PCT/FI2013/050432 patent/WO2013156686A1/en active Application Filing

Patent Citations (3)

Also Published As

Similar Documents

Legal Events