Method for performing transactional communication using a universal transaction account identifier assigned to a customer

• US 8,868,467 B2
• Filed: 08/27/2004
• Issued: 10/21/2014
• Est. Priority Date: 10/23/2002
• Status: Active Grant

• Current Assignee: Oleg Serebrennikov
• Original Assignee: Oleg Serebrennikov
• Inventors: Serebrennikov, Oleg
• Primary Examiner(s): Ravetti, Dante
• Application Number:
  US10/927,460
• Publication Number:
  US 20050114367A1
• Time in Patent Office: 3,707 Days
• Field of Search: 705/10, 705/16, 705/21, 705/59, 705/75, 705/71, 380/44, 380/262, 380/278, 380/279
• US Class Current: 705/75
• CPC Class Codes: G06F 16/951 Indexing; Web crawling techniques
• CPC Class Codes: G06F 16/9566 URL specific, e.g. using aliases, detecting broken or misspelled links
• CPC Class Codes: G06Q 20/16 Payments settled via telecommunication systems
• CPC Class Codes: G06Q 20/34 using cards, e.g. integrated circuit [IC] cards or magnetic cards
• CPC Class Codes: G06Q 20/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
• CPC Class Codes: G06Q 20/4014 Identity check for transactions
• CPC Class Codes: H04L 67/10 in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46

Abstract

Methods, systems, computer data signals, recordable media and methods of doing business for wireless or wired network communication between network resources each having a unique telephone number associated therewith, including, among other feature, forming a primary number file (PNF) comprising a uniform telephone address (UTA) which has a telephone number associated with a network resource.

User-friendly and seamless payment procedure is provided wherein payer or payee only need to know accordingly the payee or payer UTA number to allow transaction and seamless payment routing between payer and payee bank accounts. Unified approach is allowed wherein financial institution also are networking Targets having UTA numbers assigned for them and the financial institution can receive Fund Transfer Agreement or Deal Agreement from networking Targets, authenticate payer using particular Target UTA and apply the payment from this particular UTA bank account.

Internet Settlement Architecture provides unique implementation of a clearing routes ranging by using cost command for EEP; and the ranging in turn allows the routing management by using cost and time user preferences, thus allowing operational cost management implementation for financial institutions and their respective customers using cost tracing command. On-line, multi-tier and multi-route clearing infrastructure and payment services provide seamless and transparent payment cost and payment routing management, enabling End-to-End payment Straight Through Processing (STP). Network specific identifiers (such as UTA, ZUTA and others) and the network specific software user interfaces (phone user interface and only numeric keyboards) may be used to navigate and manage the Internet Settlement Infrastructure enabling seamless payment addressing and clearing. Users are enabled to address payments without a need to know payee'"'"'s banking details and payment routing information providing End-to-End account details resolution and Straight Through Processing for payment clearing services. Payment processing is diverted into online communication. Extensive use of the PKI trusted sources enables trusted financial account mappings allowing secure payment and clearing environment. The use of Attribute Certificates containing only payer network address mapped to its DCF network address allows filling in the DNS system database with the trusted mapping information avoiding the need to disclose the real banking details of the payee to a public. The use of existing DNS technology for resolution of trusted mapping information allows seamless gathering of banking routing information enabling on-line straight through processing.

Claims

1. A transactional communication method using transactional messages delivered over a communication network (CN), wherein the CN comprises a routing database;

the routing database comprising at least a first field storing a network identifier (NI) and a second field storing a network address (NA);

the routing database providing resolution services by receiving from a remote terminal a query containing the NI and retrieving the NA from the second field corresponding to the received NI wherein the retrieved NA is further used to locate a connection endpoint;

the CN implementing a messaging protocol or request-response session messaging protocol (MP) wherein MP messages are created using MP messaging syntax rules;

wherein transactional messages are delivered to a service provider or processing center authorized by the service provider (SP) managing customer accounts and processing the transactional messages while providing services to a customer;

the method comprising;

creating, using at least one of one or more hardware processors, universal transactional account (UTA) identifiers, each of the UTA identifiers comprising a unique string of symbols or characters;

assigning, using at least one of the one or more hardware processors, each of the UTA identifiers to the customer and associating the UTA identifier with a customer account corresponding to the customer;

assigning, using at least one of the one or more hardware processors, the NA further referred to as an account NA to the SP;

receiving, using at least one of the one or more hardware processors, the UTA identifier from a first remote terminal, at a time subsequent to creation of the UTA identifier, and storing the UTA identifier into the first field and the account NA into the second field of the routing database;

creating, at a second terminal coupled to the CN and using at least one of the one or more hardware processors, an MP message containing at least the UTA identifier and a value;

sending, by the second terminal and using at least one of the one or more hardware processors, the UTA identifier for resolution to the routing database using the CN and retrieving the account NA from the second field of the routing database corresponding to the received UTA identifier;

transmitting, via the CN and using at least one of the one or more hardware processors, the created MP message from the second terminal to the SP at the retrieved account NA; and

receiving, at the SP and using at least one of the one or more hardware processors, the transmitted MP message and parsing the MP message to determine the UTA identifier and the value.

2. The method of claim 1, further comprising applying SP accounting rules to the customer account corresponding to the received UTA identifier for the value and accordingly updating the customer account.

3. The method of claim 1, further comprising:

providing, by the SP, the customer account with individual connectivity on the CN using the account NA and/or MP;

creating an MP message containing at least the value using a second terminal coupled to the CN;

creating CN communication, using the retrieved account NA, between the second terminal and the customer account and transmitting the created MP message to the customer account;

applying SP accounting rules to the customer account for the value and accordingly updating the customer account.

4. The method of claim 1, wherein the UTA identifier comprises a unique string of symbols or characters composed by following NA syntax rules wherein UTA resolution is omitted and instead the UTA identifier is used as the account NA to establishing CN communication between the second terminal and the SP or the customer account.

5. The method of claim 1, wherein the routing database further comprises a third field for a value, and wherein the third field represents the customer account managed by the SP and stores data corresponding to a customer.

6. The method of claim 1, wherein the MP message is created by a third terminal and transmitted from the third terminal to the second terminal using a communication network coupled to third and second terminals.

7. The method of claim 1, wherein the UTA identifier comprises a unique string of characters composed by following Uniform Resource Identifier syntax rules, the CN is Internet, the NI is a Uniform Resource Identifier (URI), the NA is an Internet Protocol (IP) address, the MP is IP, and the routing database is a DNS system database or IN-ADDR.ARPA domain database.

8. The method of claim 1, wherein the UTA identifier comprises a unique string of characters composed by following DNS name syntax rules and consisting of conventionally concatenated parts, further referred to as labels, delimited from adjacent labels by ‘

dot’

characters;

the CN is Internet, the NI is a DNS name or ENUM, the NA is an Internet Protocol (IP) address, the MP is a stack of TCP/IP protocols or Sigtran protocol, and the routing database is a DNS system database or IN-ADDR.ARPA domain database.

9. The method of claim 8, wherein the rightmost label of the UTA identifier is a string of three Latin letters <

PAY>

and each of the letters being either upper or lower case letter, the method further comprising;

(1) registration in an Internet DNS system database of the UTA identifier as a valid DNS name containing the Latin letter string <

PAY>

as a rightmost label representing the generic top level domain name; and

(2) providing resolution services by the Internet DNS system database by receiving from a first or second terminal a query containing the UTA identifier;

retrieving an IP address from a second field of the Internet DNS system database corresponding to received UTA identifier and returning a retrieved IP address to the first or second terminal.

10. The method of claim 9, further comprising:

matching a rightmost label of the UTA identifier retrieved from the message with the string of three Latin letters <

PAY>

;

determining whether or not the matching is successful;

based on determining that the matching is successful, authorizing by the SP to provide the value; and

based on determining that the matching is not successful, denying by the SP to provide the value.

11. The method of claim 8, wherein the routing database is a DDDS DNS database using ORDER and PREF fields to define clearing or accounting methods and a method of usage priorities, the routing database implementing a DDDS algorithm, wherein the First Well Known Rule comprises an MP message parsing rule, and wherein the routing database implements resolution and at least one of clearing or accounting as DDDS database rules managed by keys encoded into the MP message as parameter values.

12. The method of claim 8, wherein the UTA identifier comprises at least one label representing at least one of a telephone number identifier, a Society for Worldwide Interbank Financial Telecommunication (SWIFT) identifier, a credit card identifier, or a debit card identifier.

13. The method of claim 8, wherein the UTA identifier represents a multi-level DNS or a IN-ADDR.ARPA name (MLN) and the MLN is hierarchical and comprises X (wherein X>

0) concatenated parts;

wherein a right-most label conveys a top-level domain further referred as Label¹, and down a tree a left-most domain representing Label^K;

UTA<sup>(K−

1)</sup> identifier being a generic identifier to a UTA^K identifier wherein UTA<sup>(K−

1)</sup> is a substring of a UTA^K string remaining after deletion of the left-most Label^K from the UTA^K string;

accordingly Node^K being assigned with the UTA^K identifier and Node<sup>(K−

1)</sup> being assigned with the UTA<sup>(K−

1)</sup> identifier wherein each Node^K is a child node to the Node<sup>(K−

1)</sup> in a sequence wherein an upper node is the SP to its child nodes and at least a left-most label representing a customer for all upper labeled parties representing SP and being nodes on the CN;

the method further comprising;

creating generic UTA¹ and assigning UTA¹ to the top level SP¹ being Node¹;

creating UTA² by adding a new label to UTA¹ from left and assigning the UTA² to Node²;

sequentially creating UTA^K and assigning the UTA^K to the Node^K until (K=X−

1) then creating UTA^X and assigning the UTA^X to the customer;

assigning with NA^K each Node^K in sequence and the NA^K further referred as account NA^K;

receiving the UTA^K from the first remote terminal, at a time subsequent to UTA^K creation and account NA<sup>(K−

1)</sup> assignment, and storing the UTA^K into the first field and the account NA<sup>(K−

1)</sup> into the second field of the routing database;

receiving the UTA^K from the first remote terminal, at a time subsequent to UTA^K creation, and associating the UTA^K with a particular Node<sup>(K−

1)</sup> customer account;

creating an MP message (Message^X) comprising UTA^X and a value using the second terminal coupled to the CN;

sending by the second terminal the customer UTA^X for resolution to the routing database using the CN and retrieving the account NA<sup>(X−

1)</sup> from the second field of the routing database corresponding to the received UTA^X;

creating a CN communication between the second terminal and the SP<sup>(X−

1)</sup> using the retrieved account NA<sup>(X−

1)</sup> and transmitting the created Message^X to the SP<sup>(X−

1)</sup> ;

receiving the Message^X by the SP<sup>(X−

1)</sup> and retrieving at least the customer UTA^X and the value from the Message^X;

applying SP<sup>(X−

1)</sup> accounting rules to SP<sup>(X−

1)</sup> customer account corresponding to the received customer UTA^X for the value and accordingly updating the SP<sup>(X−

1)</sup> customer account; and

up the tree, executing an accounting procedure for A=1 by following steps;

creating MP message (Message<sup>(X−

A)</sup>) comprising the customer UTA^X and the value retrieved from Message<sup>(X−

A+1)</sup> by the SP<sup>(X−

A)</sup>;

sending UTA<sup>(X−

A)</sup> by the SP<sup>(X−

A)</sup> for resolution to the routing database using the CN and retrieving upper level account NA<sup>(X−

A−

1)</sup> from the second field of the routing database corresponding to the received UTA<sup>(X−

A)</sup>;

creating a CN communication between the SP<sup>(X−

A)</sup> and the upper level SP<sup>(X−

A−

1)</sup> using the retrieved account NA<sup>(X−

A−

1)</sup> and transmitting the Message^X to the SP<sup>(X−

A−

1)</sup>;

receiving the Message^X by the SP<sup>(X−

A−

1)</sup> and retrieving at least the customer UTA^X and the value from the Message^X;

restoring UTA<sup>(X−

A)</sup> by adding to UTA<sup>(X−

A−

1)</sup> assigned to SP<sup>(X−

A−

1)</sup> from left the Label<sup>(X−

A)</sup> removed from the retrieved UTA^X; and

applying SP<sup>(X−

A−

1)</sup> clearing rules to SP<sup>(X−

A−

1)</sup> customer account corresponding to the restored customer UTA<sup>(X−

A)</sup> for the value and accordingly updating the SP<sup>(X−

A−

1)</sup> customer account; and

repeatedly executing the accounting procedure assuming A=A+1 until A=X−

Y wherein Y>

=1 representing Node^Y being an end point SP.

14. The method of claim 1, wherein the UTA identifier comprises a unique string of characters composed by following telephone number syntax rules;

the CN is a PSTN or Mobile Telephone Network or IP based network;

the NA is a point code (PC) or International Mobile Subscriber Identity (IMSI) or Temporary Mobile Subscriber Identity (TMSI) or address created using MCC/MNC tuple syntax rules;

the MP is a SS7 or Sigtran or Integrated Services Digital Network (ISDN) or stack of TCP/IP protocols or Code Division Multiple Access (CDMA) Paging Channel protocol;

the routing database is a PSTN routing database including but not limited by Service Switching Point (SSP) and/or Service Control Points (SCP) and/or Service Data Point (SDP) or the routing database is Global System for Mobile Communications (GSM) Network Switching Subsystem (NSS) databases or CDMA switching and routing facilities together further referred to as a mobile routing database.

15. The method of claim 1, wherein the UTA identifier comprises a unique string of characters or symbols representing a real or brand name or a telephone number further referred to as a name;

the CN is Internet, the NI is the name, the NA is an Internet Protocol (IP) address or PointCode, the MP is a stack of TCP/IP protocols or Sigtran protocol or SS7 Protocol, the routing database is a DNS system database or IN-ADDR.ARPA domain database or PSTN routing database or mobile routing database.

16. The method of claim 1, wherein the UTA identifier comprises a unique string of characters composed by following Unstructured Supplementary Services Data (USSD) syntax rules;

the CN is a Global System for Mobile Communications (GSM) telephone network and/or Internet Protocol (IP) based network;

the NA is a code of a USSD center;

the MP is SS7 and/or a stack of TCP/IP protocols and/or Short Message Peer-to-Peer (SMPP) protocol or Sigtran or Code Division Multiple Access (CDMA)c Paging Channel protocol;

the routing database is GSM Network Switching Subsystem (NSS) databases and/or the USSD center.

17. The method of claim 1, wherein the UTA identifier comprises a unique string of characters composed by following telephone number syntax rules;

the CN is a mobile network;

the NI is a telephone number;

the NA is a point code or IMSI or TMSI;

the MP is a Short Message Peer-to-Peer protocol (SMPP) or stack of TCP/IP protocols; and

the routing database is a mobile routing database.

18. The method of claim 1, wherein the UTA identifier comprises a unique string of characters composed by following e-mail address syntax rules;

the CN is a TCP/IP based network;

the NI is an e-mail address;

the NA is an Internet Protocol (IP) address;

the MP is a stack of TCP/IP protocols or Internet Message Access Protocol (IMAP); and

the routing database is a DNS system database.

19. The method of claim 1, further comprising:

determining, using at least one of the one or more hardware processors, whether or not the message value is greater than a value associated with the customer account;

based on determining that the message value is not greater than the value associated with the customer account, authorizing by the SP to provide the value; and

based on determining that the message value is greater than the value associated with the customer account, denying by the SP to provide the value.

20. The method of claim 1, wherein the SP is a financial institution and the value is a currency amount;

the value in the customer account representing a customer currency amount and the value in the MP message representing a debit currency amount, and the SP accounting rules comprising a step of subtracting the debit currency amount from the customer currency amount and updating the customer currency amount in the customer account.

21. The method of claim 1, further comprising:

storing the created UTA identifier on a machine readable medium capable of carrying or storing the UTA identifier wherein the UTA identifier is read from the machine readable medium by the second terminal via contact or contactless data link exchange;

subsequently reading at least the UTA identifier from the machine readable medium using the second terminal;

receiving by the SP from the second terminal a message containing the UTA identifier and the value;

applying SP accounting rules to a SP customer account corresponding to the received UTA identifier for the value and accordingly updating the SP customer account.

22. The method of claim 1, wherein the UTA identifier is associated with at least one alternative route of processing a transaction and the at least one alternative route is associated with the customer account;

wherein the CN comprises route tracing for providing transaction cost and time estimation and management;

wherein the route tracing ascertains the at least one alternative route and the method further comprising managing the at least one alternative route and selecting at least one of the at least one alternative route based on at least one of the transaction cost or the time estimation.

23. The method of claim 1, further comprising:

creating at least one encrypted account record (EAR) by encrypting private customer account data using a public key of the SP;

creating a transaction data group (TDG) including at least one of;

(i) the customer UTA identifier, (ii) the account NA assigned to the SP, (iii) an open part of customer account data referred as a public account record (PAR), or (iv) the at least one EAR, wherein the at least one EAR and the PAR together are referred to as an Account Data Group (ADG);

creating in the routing database at least one additional field for at least one of the ADG elements; and

storing in the at least one additional field a value of the at least one ADG element at a time subsequent to creation of the ADG element;

making the value available for the first and second terminals through a resolution process.

24. The method of claim 23, wherein at least one of the UTA identifier or account NA is trustworthily mapped to the at least one EAR and the PAR by creating for the customer a digital certificate (DC) containing at least one of the UTA identifier or the account NA and the at least one EAR and the PAR;

wherein the at least one of the UTA and the account NA and the at least one EAR and the PAR represent the TDG.

25. The method of claim 24, further comprising:

storing in the DC a number of TDG each mapping a particular account or mapping a particular clearing route for an account having a number of clearing routes managed by appropriate SPs;

creating additional new TDG for a next SP and mapping the customer UTA to the next TDG by storing the new TDG into the DC.

26. The method of claim 23, further comprising:

generating a pair of encryption private and public keys for at least one of the customer and the SP associated with the UTA identifier;

creating in the routing database a public key field (PKF) associated with the UTA identifier;

loading the public key into the PKF at a time subsequent to public key generation;

receiving from the first or second terminal a query containing the UTA identifier;

retrieving the public key from the PKF corresponding to the received UTA identifier;

returning the public key to the first or second terminal; and

using the retrieved public key by the first or second terminal in order to authenticate an endpoint associated with the received UTA identifier or to encrypt customer account details using received Public Key so creating EAR for the customer.

27. The method of claim 23, further comprising:

creating in the routing database at least one of a field for the EAR further referred to as EARF or a field for the PAR further referred to as PARF;

storing the customer EAR into the EARF and the customer PAR into the PARF at a time subsequent to EAR and PAR creation;

providing resolution services by receiving a query containing the UTA identifier and retrieving the EAR from the EARF corresponding to the received UTA identifier and the PAR from the PARF corresponding to the received UTA identifier;

decrypting the EAR using a private key of the SP or processing center; and

applying SP accounting rules to account data from the PAR and account data decrypted from the EAR associated with the UTA identifier.

28. The method of claim 23, wherein the SP is a processing center authorized for processing credit and/or debit card payments;

the account NA is the processing center gateway NA and the EAR encrypting customer credit or debit card details allowing payments further referred to as card details;

the method further comprising;

retrieving by the processing center the customer UTA identifier and currency debit amount from the MP message received from the second terminal;

retrieving the customer EAR corresponding to the retrieved UTA identifier from the DC or from the routing database using resolution services;

decrypting the EAR using a private key of the processing center and receiving decrypted customer card details;

subtracting the currency debit amount from the customer currency amount available on a credit or debit card account corresponding to the decrypted card details.

29. The method of claim 1, further comprising:

providing at least one of;

(1) UTA identifier creation;

(2) association of the UTA identifier with the SP customer account;

(3) a transaction service provided by the SP;

(4) loading the UTA identifier into the first field and the account NA into the second field of the routing database;

(5) execution by the SP of the accounting rules;

(6) a resolution service;

(7) TDG creation;

(8) ADG creation;

(9) DC creation;

(10) route tracing ascertaining or management service;

(10) creating a PKF;

(11) loading the PKF with a public key value;

(12) EAR encryption services;

(13) authorization notification service;

or (14) resolution service provided by the DNS name system database for the UTA information containing a Latin string <

PAY>

as a rightmost label wherein the UTA identifier is a valid DNS name for Internet and the Latin string <

PAY>

representing generic Top Level Domain for the valid DNS name.

30. The method of claim 1, wherein the second terminal is a same terminal as the first remote terminal.