WO2020176962A1

WO2020176962A1 - A method and system for building an honour score via a communication network

Info

Publication number: WO2020176962A1
Application number: PCT/CA2019/050422
Authority: WO
Inventors: Fabrice Fotso Kengne
Original assignee: Fabrice Fotso Kengne
Priority date: 2019-03-01
Filing date: 2019-04-08
Publication date: 2020-09-10
Also published as: CA3035399A1

Abstract

A method and system for real time honour score building via the Internet. A transaction is placed by a payer at a client system and processed and confirmed by a server system. The client system receives transaction information including identification of the payer, payment information and schedule information from the server system. The server system then assigns a payer identifier to the client system and associates the assigned payer identifier with the received payment information and schedule information. The server system sends to the client system the assigned payer identifier and an HTML document identifying the transaction and including a payment button. The client system receives and stores the assigned payer identifier and receives and displays the HTML document in private group including consenting payees and payers. In response to the selection of the payment button, the client system sends to the server system a request to process the identified transaction. The server system receives the request and combines the payer information associated with the client identifier of the client system to generate an order to evaluate the transaction in accordance with scheduling information whereby the payer effects in real time the construction and display of his honour score by completion of the payment.

Description

A METHOD AND SYSTEM FOR BUILDING AN HONOUR SCORE VIA A COMMUNICATION NETWORK

TECHNICAL FIELD:

The present invention relates to a computer method and system for building an honour score and, more particularly, to a method and system for scoring transactions over the Internet.

BACKGROUND OF THE INVENTION:

The internet comprises a vast number of devises and devise networks that are interconnected through communication links. The interconnected devises exchange information using various services, such as electronic email, and the World Wide Web ("WWW"). The WWW service allow server devise system (i.e., Web server or Web site) to send graphical Web pages of information to remote client devise system. The remote client devise system can then display the Web pages. Each resource (e.g., computer or Web page) of the WWW is uniquely identifiable by a Uniform Resource Locator ("URL"). To view a specific Web page, a client devise system specifies the URL for that Web page in a request (e.g., a HyperText Transfer Protocol ("HTTP") request). The request is forwarded to the Web server that supports that Web page. When that web server receives the request, it sends that Web page to the client devise system. When the client devise system receives that Web page, it typically displays the Web page using a browser. A browser is a special-purpose application program that effects the requesting of Web pages and the displaying of Web pages.

The World Wide Web is especially conducive to conducting electronic transaction. Many web servers have been developed through which payees can manage and receive payments. The payments can include options that are delivered electronically to the payee over the Internet and options that are delivered through conventional distribution channels. A server computer system may provide an electronic version of a catalog that lists the scheduled transactions that are accessible. A user, who is a potential payer, may browse through the catalog using a browser and select various transactions that are to be proceeded. When the user has completed selecting the transactions to be proceed, the server computer system then prompts the user for information to process the payment of the transactions. This payer-specific payment information may include the payer's name, the payer's payment account and a schedule due date for the payment. The server computer system then typically process the payment by sending a confirming web page to the client devise system and scores the transactions.

The scoring of the various transactions is generally based on the "credit score" model. When the payer process a transaction, a server computer system selectively adds transactions into the payer credit history and score them to provide a credit score. Although the credit score model is very popular, it has a downside that it require many interactions and does not include all the transactions process by the payer. For example the payer process various transactions and all of them do not necessary count toward his credit score. Additionally there is also a delay between the selected transactions that are added in the payer credit history before they can impact the payer credit score. Furthermore credit score access and discernment rigidity add it to the payer overhead when presenting an accurate indication of his financial trustworthiness. Also with more interaction with the credit score model, each time sensitive information is transmitted over the Internet, it is susceptible to being intercepted and decrypted.

SUMMARY OF THE INVENTION:

An embodiment of the present invention provides a method and system for building an honour score from a client system. The client system is provided with an identifier that identifies a customer. The client system displays information that identifies the transaction and displays an indication of an action (e.g., a single action such as clicking a mouse button) that a payer is to perform to process the identified transaction. In response to the indicated action being performed, the client system sends to a server system the provided identifier and a request to process payment of the identified transaction. The server system uses the identifier to identify additional information needed to generate an honour score for the transaction, generates the honour score and displays the honour score in the client system.

The server system receives and stores the additional information for customers using various devices systems so that the server system can generate such honour scores. The server system stores the received additional information in association with the identifier of the customer and provides the identifier to the client system. When requested by the client system, the server system provides information describing the transaction to the requesting client system. When the server system receives a request from a client system, the server system combines the additional information stored in association with the identifier included in the request to effect the scoring of the transaction.

BRIEF DESCRIPTION OF THE DRAWINGS:

Figure 1A-B illustrate single-action-pay and scoring in one embodiment of the present invention,

Figure 2 is a block diagram illustrating an embodiment of the present invention,

Figure 3 is a flow chart diagram of a routine that enables single-action-pay for a customer, Figure 4 is the flow diagram of a routine to generate a single-action-pay Web page, Figure 5 is a flow diagram of a routine which processes a single-action-pay.

DETAILED DESCRIPTION OF THE INVENTION:

The present invention provides a method and system for honour scoring of transactions in a client/server environment. The honour scoring system of the present invention increase the number of payer transactions incorporated to generate a "credit score" / trustworthiness score and reduce the amount of time it take for a transaction once processed to affect the credit score. In one embodiment, the server system assigns a unique client identifier to each client system. The server system also stores payer-specific payment information for various potential payers. The payer-specific payment information may have been collected from a previous payment processed by the payer. The server system maps each client identifier to a payer that may use that client system to process a payment. The server system may map the client identifiers to the payer who last processed a payment using that client system. When a payer wants to process a payment, the payer uses a client system to send the request for information describing the transaction to be processed along with its client identifier. The server system determines whether the client identifier for that client system is mapped to a payer. If so mapped, the server system determines whether single-action-pay is enabled for that payer at that client system. If enabled, the server system sends the requested information (e.g., via a Web page) to the client devise system along with an indication of the single action to perform to process with payment for the transaction. When the single-action-pay is enabled, the payer need to perform that action (e.g., click a mouse button) to process with payment of the transaction. When the payer performs that single action, the client system notifies the server system. The server system then completes the transaction by adding the payer-specific honour scoring information for the payer that is mapped to that client identifier to the transaction payment information (e.g., amount). Thus, once the details of a transaction are displayed, the payer need to take a single action pay to process with payment and score that transaction.

Figures 1A illustrate single-action-pay in one embodiment of the present invention. Figure 1A illustrates the display of a Web page describing a transaction that may be scored. The example Web page was sent from the server system to the client system when the payer requested to review detailed information about the transaction. This example Web page contains a summary description section 101, a payer identification section 102, a payee identification section 103, an amount identification section 104, a single-action-pay section 105. One skilled in the art would appreciate that these various sections can be omitted or rearranged or adapted in various ways. In general, the payer need only to be aware of the transaction or transactions to be scored by the single action and of the single action needed to process with payment. The summary description section provide information that identifies and describes the context of the transaction(s) that will be scored. The payer, payee and amount identification sections provide specific information that describes the payer, payer and amount of the transaction(s) that will be scored. The single action-pay section provides the conventional capacity to process with payment. The server system adds the summary description, the payer identification, the payee identification, the amount identification, and the single-action pay sections to each Web page for a transaction that will be scored. This example single-action-pay section allows the payer to score the transaction. Once the payer clicks the button, the payment is initiated at the end of which the transaction is scored, unless the payer takes some action to modify the payment process. The single-action-pay section contains the pay now button 105a, the combine payment button 105b, the payment reminder button 105c. The payer identification section displays enough information so that the payer can verify that the server system correctly recognizes the payer. To reduce the chances of sensitive information being intercepted, the server system correctly identified the payer but yet not enough information to be useful to an unscrupulous interceptor. The additional sections and subsections allow the payer to obtain various settings or obtain more information related to the single-action-pay.

When the payer selects the pay now button, the client system sends a message to the server system requesting the payer to process payment of the displayed transaction to be scored. After the server system processes the message, the server system provides to the client system new web pages with conventional capabilities to process and confirm payment. Figure 1A illustrates the display of a Web page confirming a single-action-pay. The confirming Web page contains essentially a message of confirmation that the payment and the scoring of the transaction(s) have been successfully completed.

To help minimize operation costs and payer confusion, the server system may combine various single-action-pay into a multiple-item pay when the payer selects the combine payment button. For example, if a payer pays one transaction using the single-action-pay and to pay another transaction using the single-action-pay, then those payments may be cost effectively combined into a single payment. The server system combines the single-action payments when the associated payee and payment processor are the same. For example, if one transaction has both same payee and payment processor, then the two single-action-pays may be cost- effectively combined. However, if the other transaction will be process for another payee or with another payment processor, then the two single-pays would not be combined. Figure IB illustrates the display of a Web page representing four-single pays that have been combined into one separate multiple-transaction pay based on the similarity of the payees and payment processor and two single pays. The payment information 106 indicates that transaction 1 and transaction 2, which have the same associated payee and payment processor been combined into one payment. The payment information 107 indicates that transactions 3, which do not have the same associated payment processor, is combined into a separate payment. The payment information 108 indicates that transactions 4, which do not have the same associated payee and payment processor, is combined into a separate payment.

Figure 2 is a block diagram illustrating an embodiment of the present invention. This embodiment supports the building of honour score over the internet using the World Wide Web. The server system 210 includes a sever engine 211, a client identifier/customer table 212, various Web pages 213, a customer database 214, a score database 215, and an inventory database 216. The server engine receives HTTP requests to access Web pages identified by URLs and provides the Web pages to the various client systems. Such an HTTP request may indicate that the payer has performed the single action to effect the single action payment. The customer database contains customer information for various payers or potential payers. The customer information includes payer-specific payment information such as the name of the customer and payment accounts. The score database 215 contains an entry for each of the honour score that has been processed for each customer. The inventory database 216 contains a description of the various transactions scheduled and processed. The client identifier/customer table 212 contains a mapping from each client identifier, which is a globally unique identifier that uniquely identifies a client system, to the customer last associated with that client system. The client system 220 contains a browser 221 and its assigned client identifier 222. This client identifier is stored in a file, referred to as a "cookie". In one embodiment, the server system assigns and sends the client identifier to the client system once when the client system first interacts with the server system. From then on, the client system includes its client identifier with message sent to the server system so that the server system can identify the source of the message. The server and the client systems interact by exchanging information via communications link 230, which may include transmission over the Internet.

One skilled in the art would appreciate that the single-action-pay techniques can be used in various environments other than the Internet. For example, single-action-pay can also be in an electronic mail environment in which a transaction is described in an electronic mail message along with an indication of the single action that is to be performed to effect the scoring of the transaction. Also, various communication channels may be used such as local area network, wide area network, or point-to-point dial up connection. Also, a server system may comprise any combination of hardware or software that can process payment and generate score in response to the single action being performed. A client system may comprise any combination of the hardware and the software that can interact with the server system. These systems may include television-based systems or various other consumer products through which orders may be placed.

Figure 3 is a flow diagram of a routine that enables single-action-pay for a customer. To enable single-action-pay, a server system needs to have information about the customer that is equivalent to the payer-specific payment information. The server system can obtain this information in various ways. First, the server system could ask the customer using a Web page for the payer-specific payment information. Second, the server system could also save the purchaser-specific payment information collected when a payment is placed. In step 301, the server system retrieves the client identifier that was sent by the client system. In step 302, the server system updates the client identifier/customer table to indicate that the generated client identifier has been associated with that customer. In step 303, the server system sets a button indicating that single-action-pay is enabled for that client identifier and that customer combination. In step 304, the server system supplies a confirming Web page to the client system. The next time a payer attempts to score a transaction, the client system will supply its client identifier to the server system. With single-action-pay for that payer, the server system will assume that the payer is the customer associated with that client identifier in the client identifier/customer table. Figure 4 is the flow diagram of a routine to generate a single-action-pay Web page. The server system generates a Web page describing a transaction and then adds a single-action-pay section. In one embodiment, the server system adds partial payer-specific payment information to the section. This information may include the customer's name, the payee's name and the transaction context summary. Such partial information should be the minimum information sufficient to indicate to the payer whether or not the server system is using the correct payer- specific payment information. In the step 401, the server system generates a standard shopping cart-type Web page for the transaction. In step 402, the single-action-pay button is set for the client identifier and customer combination. In step 403, the server system adds the single-action section to the Web page and completes.

Figure 5 is a flow diagram of a routine which processes a single-action-pay. When a payer performs the single action needed to score a transaction, the client system notifies the server system. The server system then combines the payer-specific payment information for the customer associated with the client system with the transaction payment information to process the payment and complete the transaction scoring. The single-action-pay may also be combined with other single-action-pays and possibly with other conventionally placed payment to reduce operation costs. In one embodiment, single-action-pays can be combined if they are associated with the same payee and payment processor. This routine illustrates the scoring of the single- action-pays into a before due date honour (e.g., a payment of the single-action-pay being completed before their respective scheduled date of payment), a due date honour (e.g., a payment of the single-action-pay being completed at the specific scheduled date of payment), an after due date honour (e.g., a payment of the single-action-pay being completed within two days after their respective scheduled date of payment) and an overdue date honour (e.g., a payment of the single-action-pay being completed more than two days after their respective scheduled date of payment). One skilled in the art would appreciate that the single-action pays can be combined in various ways based on other factors, such as amount of the payment and intermediate-term. In the step 501 when the transaction is available for processing then the server system continue at steep 502. In Step 502, if the payment of the single-action-pay is completed before their respective transaction scheduled date of payment, then the server system attribute a before due date honour score to the payer and continues at step 506, else the server system continues at step 503. In step 503, if the payment of the single-action-pay is completed at the specific scheduled date of payment, then the server system attribute a due date honour score to the payer and continues at step 506, else the server system continues at step 504. In step 504, if the payment of the single-action-pay is completed within two days after their respective scheduled date of payment, then the server system attribute after due date honour score to the payer and continues at step 506, else the server system continues at step 505. In step 505, with the payment of the single-action-pay completed more than two days after their respective scheduled date of payment, the server system attribute an overdue date honour score to the payer and continues at step 506. In step 506, the server system generates the payer score and sends the payment and score confirmation and completes.

Although the present invention described in terms of various embodiments, it is not intended that the invention be limited to these embodiments. Modification within the spirit of the invention will be apparent to those skilled in the art. Also, various different single actions can be used to effect the scoring of a transaction. For example, a voice command may be spoken by the payer, a button on a television remote control device may be depressed by the payer, or selection using any pointing device may be effected by the purchaser. Finally, the payer can be alternately identified by a unique customer identifier that is provided by the customer when the customer initiates access to the server system and sent to the server system with each message. This customer identifier could be also stored persistently on the client system so that the payer does not need to re-enter their customer identifier each time access is initiated. The scope of the present invention is defined by the claims that follow.

Claims

A METHOD AND SYSTEM FOR BUILDING AN HONOUR SCORE VIA A COMMUNICATION NETWORKCLAIMS :

1. A method for constructing honour score, the method comprising:

Transmitting to a client system a client identifier of the client system for persistent storage at the client system;

Receiving to a server system a request to process transaction and combining the payer information associated with the client identifier of the client system to generate an order to score the transaction in accordance with honour criteria whereby the payer effects the construction and display of his honour by completing of the payment

For each plurality of transactions:

Transmitting from the server system for display in private group including consenting payees and payers, information identifying a transaction and an indication of a single action that is to be performed to effect the payer transaction, and

Receiving at the server system a request to pay the identified transaction and the client identifier, the request to pay being a single-action-pay and the client identifier for identifying account information of the payer

In response to receiving a payer request to combine multiple single-action-pays into one single-action-pay, combining into one single-action-pay when the payee and the payment processor are the same for the identified transactions.

And

In response to receiving a request to cancel either the identified transaction or the prior identified transaction, removing the identified transaction or prior identified transaction corresponding to the request to cancel from the single payment prior to fulfillment of the single payment.

2. The method of claim 1, wherein the scoring of a transaction includes evaluating the singleaction-pay payment completion with predetermined criteria for honour.

3. The method of claim 2, wherein the predetermined criteria for honour comprises a before due date honour or a due date honour or an after due date honour or over due date honour, the before due date honour corresponding to a payment of the single-action-pay being completed before their scheduled date of payment, the due date honour corresponding to a payment date of the single-action-pay being completed at their specific scheduled date of payment, the after due date honour corresponding to a payment of the single-action-pay being completed within two days after their scheduled date of payments, the over due date honour corresponding to a payment date of the single-action-pay being completed more than two days after their scheduled date of payment

4. The method of claim 1, wherein transmitting comprises transmitting via the Internet and receiving comprises receiving via the Internet.

5. The method of claim 1, wherein the single-action-pay corresponds with the click within the display information having the indication of the single action that is to be performed to proceed payment of the identified transaction.

6. The method of claim 1, wherein the identified transaction is alternately processable using a shopping cart model.

7. A method for combining transactions within a single-action-pay system, the method comprising: Transmitting to a client system a client identifier for persistent storage within the client system, the client identifier for identifying account information about the payer

Transmitting web pages describing transactions processable through a shopping cart model or single-action-pay sections with combine payments button;

Receiving, in response to a selection of the combine payment button being performed within the single-action-pay section, a first request to combine for the first transaction and the payer identifier, the first request being the first singleaction-pay

Transmitting web pages describing transactions processable through a shopping cart model or single-action-pay section;

Receiving, in response to a second selection of the combine payment button being performed within the single-action-pay section, a second request to combine for second transaction and the payer identifier, the second request being the second single-action-pay

In response to satisfying a predetermined combining criteria (similar payee and similar payment processor), combining the first single-action-pay and the second single-action-pay into a single transaction, and

In response to receiving a request to cancel either the first transaction or the second transaction, removing the first transaction or the second transaction corresponding to the request to cancel from the single transaction prior to fulfillment of the single transaction.