Patent Application
20140136719
The invention relates to transaction processing. Particularly, the invention relates to providing a predetermined response to an input in a communication network.
Today's world provides a wide variety of various information services e.g. via the Internet and telecommunication and other data communication networks. Because the amount of information transmitted in the networks is huge, it is often desirable to also manage or process the information at some point before it reaches its final destination. Nowadays it is desirable for many people to be able to determine how transactions (e.g. email messages, phone calls) are processed.
Email clients provide various rule based action, i.e. rules based on which incoming and/or outgoing emails can be processed. For example, a user may want that an email message with predetermined words in its subject field will be directly directed to a certain email folder.
In mobile phones, a user may determine a distinctive ringing tone for a caller. In another solution, the user may e.g. set his mobile phone to be in a silent alarm (silent ringing tone) except for one predetermined caller. Or when a called party does not answer to a phone call, the call may be automatically forwarded to the caller party's voice mail service.
What is common for all current solutions is the fact that they can be customized and managed only in their own dedicated environments. This provides only limited ways to process actions and transactions in the modern world. Therefore, there is a need for a solution that enables transaction processing in a versatile manner,
The invention provides a solution with which it is possible to create a service only once and then attach connectors at input and output ends to cover as many clients and presentation formats as is wanted. In other words, the invention is able to receive input in any commonly used form (e.g., HyperText Transfer Protocol (HTTP). File Transfer Protocol (FTP), email, Short Message Service (SMS), voice calls, Multimedia Message Service (MMS), socket sessions, 2D code initiated http request, 1D code initiated http request etc.). Similarly, by using the action connectors, the solution disclosed in the invention is able to provide a response to the input in any commonly used form (e.g., http, file, email, SMS, MMS, voice call, socket session etc.). The same, an in advance created service, can be accessed by any of the above input forms. In short, the invention is able to provide any output after standardised transaction processing to any input.
According to one aspect of the invention, there is provided a method for processing transactions. The method comprises: providing a plurality of input connectors which interface towards any external client able to request a service; providing a plurality of action connectors which interface towards any external client able to receive data from a service; receiving an input with one of the input connectors; determining, whether the input relates to a predetermined service of a customer; creating a transaction based on the input, when linking the received input to a predetermined service of a customer; processing the transaction to determine at least one output action; providing the at least one output action to at least one of the action connectors; and providing an output with the at least one action connector based on the at least one output action.
According to one another aspect of the invention, there is provided a computer program comprising code adapted to perform the method according to the invention when executed on a data processing device.
According to one another aspect of the invention, there is provided a computer system for implementing transactions. The computer system comprises a plurality of input connectors which interface towards any external client able to request a service, configured to receive an input; a plurality of action connectors which interface towards any external client able to receive data from a service; transaction creation means configured to: determine, whether the input relates to a predetermined service of a customer; create a transaction based on the input, when linking the received input to a predetermined service of a customer; transaction processing means configured to: process the transaction to determine at least one output action; provide the at least one output action to at least one action connector. The at least one action connector is configured to provide an output based on the at least one output action.
According to one another aspect of the invention, there is provided a method for processing transactions. The method comprises: providing at least one input, connector with customer and/or service information; receiving a transaction from at least one input connector; processing the transaction to determine at least one output action; and providing the at least one output action to at least one action connector.
According to one another aspect of the invention, there is provided a computer program comprising code adapted to perform the method of the above method when executed on a data processing device.
According to one another aspect of the invention, there is provided a transaction server for processing transactions. The transaction server comprises a first output interface configured to send to at least one input connector customer and/or service information; at least one input interface configured to receive a transaction from at least one input connector; transaction processing means configured to: process the transaction to determine at least one output action; provide the at least one output action to at least one action connector; and a second output interface configured to provide at least one output action to at least action connector.
Various embodiment of the invention are disclosed in the dependent claims.
The invention has various advantages over the prior art. In current solutions, one has to build several different services and each of the services maintains similar kinds of pieces of information. In the solution disclosed in the invention at hand, a plurality of existing services can be consolidated into one service and still get the same end result.
Furthermore, the introduction of forthcoming technologies is very easy because one has to implement only an input and action connector for a new technology. Other essential parts of the solution remain unchanged.
The solution disclosed in the invention is not limited to receive input only from a limited set of input sources. Similarly, the solution disclosed in the invention is not limited to provide a response or responses to the input to only a limited set of destinations. Furthermore, when a single service is created for a customer, the service can be used by any of the input connectors.
The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illustrate embodiments of the invention and together with the description help to explain the principles of the invention In the drawings:
Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
All actions relating to the transaction may be recorded in a log or logs 102 for further processing. The log 102 may be separate from the transaction server 100. Alternatively, it may be an internal part of the transaction server 100.
In a nutshell, the solution disclosed in the invention at hand is able to provide, in response to any input, any output in response to standardised transaction processing. With the invention at hand, it is possible to create a service only once and then attach connectors at input and output ends to cover as many clients and presentation formats as desirable.
A core 200 of a transaction server 214 comprises four logical modules: services 202, triggers 204, rules 206 and logs 208. Each of there will be discussed more thoroughly in the following paragraphs.
The transaction server 200 is configured to receive an input from a number of possible external clients able to request a service. The input is received with an input connector 210. An input connector 210 basically identifies a type of an input. The types include e.g. HTTP request, SMS, email etc. Similarly, the transaction server 214 is configured to provide an output for a processed transaction.
In practice, an input connector 210 may be implemented is several ways. For example, regarding short messages (SMS), service providers provide messages to the transaction server in various forms. A common nominator for all forms is that the content of the message, sender and receiver number are known. A connector identifies these data elements and creates a transaction based on them.
If a service provider provides a received message e.g. in a HTTP get form, the connector is run in practice in a HTTP server. The HTTP server may be a script running in a dedicated server other than the transaction server or alternatively, the HTTP server may be implemented in the transaction server. The script provider provides the service provider with a predetermined response, and after that examines the content of data received from the service provider. If a transaction is created, the connector calls an interface (e.g. HTTP and XML (Extended Markup Language)) of the transaction server and receives an acknowledgement from the transaction server.
In another embodiment, a connector consists of a SMTP service that receives messages e.g. from service providers or other users. With virtual domains and/or public folders (a virtual user) it is possible to build a desired amount of ‘pipes’. For the sending party, the routing address may be a domain or an email address (a virtual user/folder). Every message received with the connector is scanned for keywords (i.e. service keys). For every pipe, there exists 0 . . . n different keywords (i.e. service keys). Each of the keywords corresponds with one service in the transaction server. If a match is found a transaction is created, and the connector calls an interface (e.g. HTTP and XML) of the transaction server and receives an acknowledgement from the transaction server. If the connector is implemented in the transaction server or in a virtual machine, a faster method than an http request can be used, e.g. a RPC (Remote Procedure Call) call to a transaction server core interface.
The interface in the transaction server towards the (input) connectors is e.g. a java library. The library contains enough classes and methods, e.g. “ask connector parameters” (e.g. keywords (service keys)), “create a transaction”, “modify parameters” etc. In one embodiment of
The top level building blocks in the transaction server 214 are customers and services relating to each customer. Each customer is assigned a unique customer identifier (ID). Similarly, each service has a unique service identifier (ID). Unlike the customer ID, the service ID may be unique only within one customer ID. A service includes one or more triggers and each trigger may include one or more rules. Triggers and rules will be discussed in more detail shortly.
The same may also be expressed as with a real example. A client L lives in Frankfurt and uses a service of a Swedish service provider. The Swedish service provides uses a transaction server located in Helsinki of a Finnish service provider. The transaction server provides an output, which outputs data to an output connector of partner C located in San Francisco. The output connector on partner C transmits data to a logistics system in Singapore. Finally, the result of the chain is a purchased product which is delivered to Frankfurt to the client's home address.
In one embodiment of
In one embodiment, when an input connector receives input data from external clients, it requests from the transaction server (core) action instructions. The request may in practice be a database request to which the transaction server (core) returns one or more service keys. Then the input connector examines the input data. It should be noted that each input connector may differ from each other; a first input connector tries to find a character string (text) corresponding to the service keys, a second input connector performs logical comparisons, a third input connector examiner binary data etc. A common factor is that if a match if found, a transaction is created. In other words, the transaction server (core) “subscribes” transactions from different connectors by using service keys as parameters. It is important to notice that the transaction server (core) may subscribe from different input, connectors with the same service key. Similarly, output may be provided with multiple output connectors in response to the same service key.
A presentation attribute (‘Data parameter #1’) reveals which input connector created the transaction. Examples of possible presentation attributes include:
Each service has been assigned a service identifier that uniquely identifies the service. ‘Description’ provides a human readable name for service. ‘Customer ID’ provides a link to the customer to which the service belongs to. Each service may also comprise a validity parameter which contains the time interval the service is available for the customer.
If the trigger is valid the right action connector for the action is called. Examples of possible actions include:
a discloses an example of actions performed after receiving an input according to one embodiment of the invention. In this embodiment, an input connector receives an email message. The transaction server 902 reacts to every email message that contains a character string ‘n.n@abc.com’ from a sender 900. The functionality of the transaction server in roughly divided into two different aspects: service creation and service usage. Before a service can be used, it has to be created.
The service creation is first explained in more detail.
Each customer has his own customer identifier (ID). Let's assume that the customer ID in this case is #c. A service (#s) is created, which has a unique service key ‘n.n@abc.com’. The transaction server uniquely identifies a server based on the combination of #c and the service key. Thus different customers may have the same service key but the combination of #c and the service key is unique.
Next, a trigger is created for the service #s. In this example, the presentation ID is ‘email’. In other words, this trigger may be executed only to received emails. Next, the service creator chooses a desired action. In this case the action is to send a short message (SMS) to a predetermined recipient 904 every time when an email message of the customer #c contains a character string ‘n.n@abc.com’. Therefore, the action type is ‘send SMS.
The action data parameter #1 includes the mobile phone number to be used. The content of the short message is determined in the action data parameter #2. The short message may e.g. state that “An email received from a.a@abc.com” etc.
Now a service has been created. Based on the created service the transaction core tells to the input connector handling emails that the service #s receives service requests from the input connector when the service key of the service #s contains a value ‘n.n@abc.com’.
Next, the service usage (i.e. transaction processing) is explained in more detail. After the service creation, every time when the email input connector receives an email message, which contains (anywhere in the message) the character string ‘n.n@abc.com’, it creates a transaction.
The transaction structure disclosed in
Next, the transaction server core processes the transaction. Based on the ‘Service ID’ (#s) the transaction server core determines and examines all triggers whose ‘Presentation ID’ equals to #p (this parameter is found from ‘Data parameter #1’ field of the transaction structure). Now, the previously created trigger calls the chosen action connector (‘send sms’) every time because we have not created any rules for the trigger.
Let's now go shortly back to the service creation process. We want to create two rules for the trigger. The rules return ‘OK’ if the rules are realized.
1. Email—From ENABLE with ‘a.a@abc.com’ parameter (if From field of the email includes ‘a.a@abc.com’, the rule returns ‘OK’).
2. Email—To ENABLE with ‘n.n@abc.com’ parameter (if To field of the email includes ‘n.n@abc.com’, the rule returns ‘OK’).
Now, the action of the trigger action is executed only if both rules return ‘OK’. In other words, the rules verify that the sender of the email message is ‘a.a@abc.com’ and the message want sent to ‘n.n@abc.com’.
In addition to the embodiment disclosed in
3. Email—Subject DISABLE with ‘Summer Holiday’ parameter.
Now, those emails whose sender is ‘a.a@abc.com’ and receiver ‘n.n@abc.com’ will trigger an action unless the subject field of the email includes ‘Summer Holiday’.
In addition to the above, if it is wanted that when an email message comes from ‘y.y@abc.com’, a short message should be sent and additionally a copy of the email message should be sent to ‘a.a@abc.com’. To achieve this, two new triggers are created.
In the first trigger the ‘Presentation ID’ is the same as above, i.e. ‘email’. The ‘Action type’ is now ‘send SMS’ the parameter of which is #mobile (mobile phone number). A new rule is created for this trigger:
4. Email—From ENABLE with ‘y.y@abc.com’ parameter.
In the second trigger the ‘Presentation ID’ is the same as above, i.e. ‘email’. The ‘Action type’ is now ‘send email’ with ‘a.a@abc.com’ parameter. A new rule is created also for this trigger:
5. Email—From ENABLE with ‘y.y@abc.com’ parameter.
In other words, if rule 4 returns ‘OK’, a short message is sent to #mobile. And, if rule 5 returns ‘OK’, a copy of the email message is sent to ‘a.a@abc.com’.
For example, a rule ‘Email—To ENABLE’ means that if the sender of an email (e.g. s.s@abc.com) corresponds to the address in the ‘Rule data parameter #2’ field, the rule returns ‘OK’.
In one embodiment, every processed transaction is recorded in a log 208. Data in the log 208 may be used e.g. for reporting purposes. All possible attributes are stored for reporting. Log entries are written e.g. to indexed database tables. In one embodiment, all phases of the transaction process are timestamped.
b discloses another example of actions performed after receiving an input according to one embodiment of the invention.
A mobile phone 910 read a 20 code e.g. from a paper or an advertisement. In response to the reading, the mobile phone 910 sends a HTTP request to a trans action server 912. In response to receiving the HTTP request, the transaction server 912 returns to the mobile phone a web page or a HTTP address to a web page. In addition to this, the transaction server 912 may send a predetermined short message to a mobile 914, a predetermined email to a receiver 916 or it may perform any supported action 918. Each of the actions may be recorded in a log 920.
It is evident to a skilled person that although the above examples of the invention has been illustrated by using specific output examples, the output may take any appropriate form (e.g. data transmission, voice call, back coupling to an input connector, a product delivery, information processing, or any other predetermined action.
An essential aspect in the invention is that the transaction server is aware of various inputs. In other words, in one embodiment email messages must by routed through the transaction server. Similarly, if an action is required in response to an SMS, the transaction server need to know about the existence of the SMS e.g. from the teleoperator. The transaction server may then has to have interfaces to/from the existing network providers.
Each transaction processed by the transaction server is logged. In one embodiment, all possible attributes are stored for reporting. Log entries are written e.g. to indexed database tables. In one embodiment, all available transaction fields are stored and all phases of the transaction process are timestamped. The data stored in the log may then be processed for various reporting purposes.
In one embodiment, the log records all available data relating to transactions and also progression data relating to transactions (e.g. status data of all transaction stages). Based on the log records, it is later possible to follow, analyze and model all stages of transactions. Furthermore, it is e.g. possible to analyze user behaviour of different service users based on the log records. This provides valuable information e.g. for service providers.
The transaction server may offer a special user interface (UI) layer for configuring and creating customers and services for them. The UI layer may e.g. provide tools to create different user interface consoles for various clients. The transaction server supports e.g. HTML and XML based solutions. With the use interface it is possible to build simple as well as complex user interfaces for controlling the transaction server. The user interface may be a basic web based user interface for a normal user, a more complex user interface e.g. for service providers.
The exemplary embodiments can include, for example, any suitable servers, workstations, and the like, capable of performing the processes of the exemplary embodiments. The devices and subsystems of the exemplary embodiments can communicate with each other using any suitable protocol and can be implemented using one or more programmed computer systems or devices.
One or more interface mechanisms can be used with the exemplary embodiments, including, for example, Internet access, telecommunications in any suitable form (e.g., voice, modem, and the like), wireless communications media, and the like. For example, employed communications networks or links can include one or more wireless communications networks, cellular communications networks, 3 G communications networks, Public Switched Telephone Network (PSTNs), Packet Data Networks (PDNs), the Internet, intranets, a combination thereof, and the like.
It is to be understood that the exemplary embodiments are for exemplary purposes, as many variations of the specific hardware used to implement the exemplary embodiments are possible, as will be appreciated by those skilled in the hardware and/or software art (s). For example, the functionality of one or more of the components of the exemplary embodiments can be implemented via one or more hardware and/or software devices.
The exemplary embodiments can store information relating to various processes described herein. This information can be stored in one or more memories, such as a hard disk, optical disk, magneto-optical disk, RAM, and the like. One or more databases can store the information used to implement the exemplary embodiments of the present inventions. The databases can be organized using data structures (e.g., records, tables, arrays, fields, graphs, trees, lists, and the like) included in one or more memories or storage devices listed herein. The processes described with respect to the exemplary embodiments can include appropriate data structures for storing data collected and/or generated by the processes of the devices and subsystems of the exemplary embodiments in one or more databases.
All or a portion of the exemplary embodiments can be conveniently implemented using one or more general purpose processors, microprocessors, digital signal processors, micro-controllers, and the like, programmed according to the teachings of the exemplary embodiments of the present inventions, as will be appreciated by those skilled in the computer and/or software art(s). Appropriate software can be readily prepared by programmers of ordinary skill based on the teachings of the exemplary embodiments, as will be appreciated by those skilled in the software art. In addition, the exemplary embodiments can be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be appreciated by those skilled in the electrical art(s). Thus, the exemplary embodiments are not limited to any specific combination of hardware and/or software.
Stored on any one or on a combination of computer readable media, the exemplary embodiments of the present inventions can include software for controlling the components of the exemplary embodiments, for driving the components of the exemplary embodiments, for enabling the components of the exemplary embodiments to interact with a human user, and the like. Such software can include, but is not limited to, device drivers, firmware, operating systems, development tools, applications software, and the like. Such computer readable media further can include the computer program product of an embodiment of the present inventions for performing all or a portion (if processing is distributed) of the processing performed in implementing the inventions. Computer code devices of the exemplary embodiments of the present inventions can include any suitable interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes and applets, complete executable programs, Common Object Request Broker Architecture (CORBA) objects, and the like. Moreover, parts of the processing of the exemplary embodiments of the present inventions can be distributed for better performance, reliability, cost, and the like.
As stated above, the components of the exemplary embodiments can include computer readable medium or memories for holding instructions programmed according to the teachings of the present inventions and for holding data structures, tables, records, and/or other data described herein. Computer readable medium can include any suitable medium that participates in providing Instructions to a processor for execution. Such a medium can take many forms, including but not limited to, non-volatile media, volatile media, transmission media, and the like. Non-volatile media can include, for example, optical or magnetic disks, magneto-optical disks, and the like. Volatile media can include dynamic memories, and the like. Transmission media can include coaxial cables, copper wire, fiber optics, and the like. Transmission media also can take the form of acoustic, optical, electromagnetic waves, and the like, such as those generated during radio frequency (RF) communications, infrared (IR) data communications, and the like. Common forms of computer-readable media can include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other suitable magnetic medium, a CD-ROM, CDR, CD-RW, DVD, DVD-ROM, DVD±RW, DVD±R, any other suitable optical medium, punch cards, paper tape, optical mark sheets, any other suitable physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, an EPROM, a FLASH-EPROM, any other suitable memory chip or cartridge, a carrier wave or any other suitable medium from which a computer can read.
While the present inventions have been described in connection with a number of exemplary embodiments, and implementations, the present inventions are not so limited, but rather cover various modifications, and equivalent arrangements, which fall within the purview of prospective claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20075649 | Sep 2007 | FI | national |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12678629 | Jul 2010 | US |
| Child | 14156173 | US |
