Title of Invention

A METHOD FOR TRANSMITTING PILOTS FROM AN ACCESS TERMINAL TO AN ACCESS POINT

Abstract

'COMPUTER-BASED SYSTEM FOR TRANSACTIONS PROCESSING' The invention relates to a computer-based system for transacting business between a customer (210) and a business organization (230) comprises a server (240) which is accessible by the customer (210) via a telecommunication network (220) and which houses a customer account containing account bookings associated with the customer (210). The server (240) is configured for the customer (210) to select via the telecommunication network (220) a function to be processed automatically, the function enabling the customer (210) to select via the telecommunication network (220) open items from a list of account bookings. The server (240) calculates a balance for the items selected, considering a debit or a credit status associated with each of the account bookings. The calculated balance is compared to a predetermined amount and the items selected are set off without payment when the balance is below the predetermined amount. On one hand, the customers (210) have full transparency of postings and are enabled to reconcile their accounts without involving personnel from the business organisation. On the other hand, the requirements on the technical infrastructure for executing data and financial transactions and for invoicing are reduced in that the customers (210) have the ability to interact and trigger financial transactions, depending on the credit/debit balance positions.

Full Text

Computer-based System for Transactions Processing Field of the Invention The present invention relates to a computer-based system for transactions processing and to a computer program product suitable therefore. More particularly, the present invention relates to a computer-based system for receiving orders and processing payments, while maintaining accounting of individual accounts. Specifically, the present invention relates to a computer-based system for transacting business between a customer and a business organization, the system comprising a server used by the business organization and being accessible by the customer via a telecommunication network, and a customer account housed on the server, the customer account containing account bookings associated with the customer. Background of the Invention Filing customer orders, invoicing customer bills, and processing customer payments are among the most common business processes. Yet these simple interactions continue to be the source of errors and inefficiencies and customer dissatisfaction. Thus, there remains a need to improve the accuracy and efficiency of transaction processing and improve customer-to-business communication, decrease costs, and minimize errors. Finding a suitable transaction processing approach depends to a very large extent on the nature of the customer business interaction. A common business that handles a large number of customer requests is the Insurance industry. Such businesses receive a large number of customer requests and therefore must handle a large number of transactions swiftly and efficiently. However, much error occurs in the interaction between a customer's claim for an incident and the insurance company's ultimate payment to settle the claim. Much overhead is required for the insurance company to handle each claim individually with persons that scrutinize the customer's claim for accuracy and reliability. Thus, insurance companies incur high costs related to the costs of overhead when each customer claim must be individually considered by a representative of the insurance company before any payment is made to the customer. In a similar manner, a reinsurance company may have to consider a large number of claims by insurance companies relating to various contracts that the insurance company has with the reinsurance company as well as keeping track of premium payments owed by each insurance company. Although the reinsurance company-to-insurance company interaction is based on trust, it is often labour intensive because of the premium and claim handling. In contrast, the customer-to-insurance company interaction is not as manually intensive because at least the premium amounts are fixed and invoices can be sent automatically. For example, when an insurance company presents a claim to the reinsurance company, the latter routinely prepares a payment to settle the claim, often without conducting the arduous tasks of considering the details of validity and reliability of the claim. The reinsurance company thereby "trusts" that the insurance company has presented a claim that conforms to the agreement between the two companies and does not unfairly or unreasonably affects the reinsurance company. Furthermore, any such payment to settle the insurance company's claim is typically delayed by the usual delays associated with the handling of the claim and preparation and transfer of the payment. Similarly, "trust" issues exist for handling premium payments from insurance companies to the reinsurance company. Finally, the reinsurance company typically does not conduct a proper accounting of the claim(s) that the insurance company(ies) has presented in the sense that generally there is no allocation of payments, claims, or premiums to individual contracts, but rather only at the customer (insurance company) level. Thus, there is little assurance, other than a reliance on the insurance company, that a claim is within the metes and bounds of the contract between the two businesses, and that the policy limit has not been exceeded. Thus, there are inefficiencies within the reinsurance company's routine of handling transactions with its customer and insurance companies. Such inefficiencies potentially lead to lost revenue and inaccurate or delayed accounting. Typically, computer-based systems for transactions processing that are configured to automatically invoice the premiums cause a lot of data transactions between the system and the customers. Furthermore, a corresponding number of financial transactions between customers and financial institutions and between financial institutions and the system are required for paying the invoiced premiums. Similarly, the payment of claims relies on numerous financial transactions between system and financial institutions. Carrying out the data and financial transactions in electronic fashion via a telecommunication network requires a considerable amount of bandwidth of the telecommunication network as well as processor and memory resources for executing and logging the financial transactions. Typically, invoicing the premiums also requires the system to generate a great volume of paper mail that must be delivered physically to the customers. Summary of the Invention It is an object of this invention to provide a computer-based system and a computer program product for transacting business between a customer and a business, wherein the system and the computer program product do not have the disadvantages of the prior art. In particular, it is an object of the present invention to provide a computer-based system and a computer program product for transacting business between a customer and a business, wherein efficiencies within the system's handling of transactions with customers are improved, while the requirements on the technical infrastructure for executing data and financial transactions and for invoicing are reduced. According to the present invention, these objects are achieved particularly through the features of the independent claims. In addition, further advantageous embodiments follow from the dependent claims and the description. The computer-based system for transacting business between a customer and a business organization comprises a server used by the business organization. The server Is accessible by the customer via a telecommunication network, for example by means of a terminal. Housed on the server is a customer account containing account bookings associated with the customer. According to the present invention, the above-mentioned objects are particularly achieved in that the system further comprises means for the customer to select via the telecommunication network a function to be processed automatically by the system, the function enabling the customer to select via the telecommunication network open items from a list of account bookings. Moreover, the inventive system comprises means for calculating a balance for the Items selected from the list of account bookings, considering a debit or a credit status associated with each of the account bookings. The inventive system also comprises means for comparing the calculated balance to a predetermined amount and to set off the items selected from the list of account bookings without payment when the balance is below the predetermined amount. On one hand, the efficiencies and flexibilities within the system's handling of transactions with customers are improved in that it is made possible for customers to access remotely their accounts and to select open items from the list of account bookings, i.e. to seiectively group their account bookings, and to select a function to be processed automatically by the system, i.e. to select financial operations to be applied to the specified group of account bookings. Organisation of their accounts and allocation of their account bookings are at the control of the customers. The customers have full transparency of postings and are enabled to reconcile their accounts without involving personnel from the business organisation. On the other hand, the requirements on the technical infrastructure for executing data and financial transactions and for invoicing are reduced in that the customers have the ability to interact and trigger financial transactions, depending on the credit/debit balance positions. For example, payment transactions can be avoided when selected payment advice functions or payment request functions involve small amounts. Particularly, a payment to a customer and all the data communication associated with the payment do not have to be executed when credits and debits related to a payment request are selected to result in a small balance. Likewise, a payment order from a customer and all the data communication associated with the payment order do not have to be executed when credits and debits related with a payment advice are selected to result in a small balance. Thus, the number of executions of financial transactions is reduced and invoicing can be eliminated or at least reduced significantly. Consequently, the requirements on the technical infrastructure for executing data and financial transactions and for invoicing are reduced because the amount of bandwidth of the telecommunication network as well as the processor and memory resources required for executing the financial transactions are reduced and because the volume of paper mail required for invoicing the premiums is reduced. Preferably, the system further comprises means for verifying that the balance is in favour of the system before continuing a payment advice as the selected function. Moreover, the system preferably comprises means for verifying that the balance is in favour of the customer before continuing a payment request as the selected function. Preventing execution of financial operations and settlement of account bookings depending on the balance of the respective group of account bookings has the advantage that unnecessary transactions and data communications are avoided. Thus, the requirements on the technical infrastructure for executing data and financial transactions are further reduced. In a preferred embodiment, the system further comprises means for making a submit payment advice button not available to the customer when the balance is zero. By visually hiding the button from the user, control over whether or not the payment advice operation is to be executed is removed from the customer. This makes it possible for the system to set off the respective group of selected account bookings without executing the payment advice when the balance is zero. Therefore, execution of the financial operation and data communication associated with the financial operation can be avoided in cases where the business organisation using the system is willing to write-off a small remaining balance in its favour. In a preferred embodiment, the system further comprises means for generating and communicating to the customer via the telecommunication network a unique reference number associated with a payment advice as the selected function. Furthermore, the system comprises means for receiving an electronic payment order via the telecommunication network and for pairing the electronic payment order with items selected from the list of account bookings based on the unique reference number included in the electronic payment order. Without having to issue an invoice and an associated invoice number, it is possible for the system to match account bookings to payment orders received from the customer. Consequently, it is possible to save processing power and energy for generating and delivering invoices to customers while maintaining the benefit of matching account bookings to payment orders. In a preferred embodiment, the system further comprises means for the customer to allocate via the telecommunication network account bookings representing payments from the customer with account bookings that are unsettled. Furthermore, the system comprises means for calculating a difference between the account bookings representing payments and allocated unsettled account bookings and for writing off the calculated difference when the calculated difference is below a predetermined amount. Payments from the customer can be matched directly by the customer to unsettled account bookings. There is no need for the system to generate and deliver invoices to the customer nor is there a need for a reference number that must be communicated to the customer and later reported back by the customer to the system. Furthermore, invoicing of remaining balances can be avoided, if the system is willing to write-off small remaining balances In his favour. In addition to a computer-based system for transacting business between a customer and a business organization, the present invention also relates to a computer program product Including computer program code means for controlling one or more processors of a computer, particularly, a computer program product including a computer readable medium containing therein the computer program code means. The computer program code means are configured to control the processors of the computer such that the computer executes all the functions of the computer-based system described above for transacting business between a customer and a business organization. Preferably, the computer program code means are configured to control the processors of the computer such that the computer embodies a server executing all the functions of the computer-based system described above for transacting business between a customer and a business organization. Specifically, controlled by the computer program product, the computer receives from the customer via the telecommunication network instructions to select a function to be processed automatically by the computer, the function enabling the customer to select via the telecommunication network open items from a list of account bookings. The computer calculates a balance for the items selected from the list of account bookings, considering a debit or a credit status associated with each of the account bookings. The computer compares the balance to a predetermined amount and the computer sets off the group of account bookings without payment when the balance is below the predetermined amount. Preferably, controlled by the computer program product, the computer verifies that the balance is in favour of the system before continuing a payment advice as the selected function and the computer verifies that the balance is in favour of the customer before continuing a payment request as the selected function. In a preferred embodiment, controlled by the computer program product, the computer makes a submit payment advice button not available to the customer when the balance is zero. In a preferred embodiment, controlled by the computer program product, the computer generates and communicates to the customer via the telecommunication network a unique reference number associated with a payment advice as the selected function. The computer receives an electronic payment order via the telecommunication network and pairs the electronic payment order with items selected from the list of account bookings based on the unique reference number included in the electronic payment order. In a preferred embodiment, controlled by the computer program product, the computer receives from the customer via the telecommunication network instructions to allocate account bookings representing payments from the customer with account bookings that are unsettled. The computer calculates a difference between the account bookings representing payments and allocated unsettled account bookings and writes off the difference when the difference is below a predetermined amount. The present invention, as described in the exemplary embodiments presented herein, addresses the shortcomings of the efficiencies and inaccuracies that typically occur between two or more parties to a business transaction. Such parties may include individuals, businesses, agencies, or governments. The examples presented throughout this disclosure are directed to interactions between a reinsurance company and its customer, an insurance company. However, this example is merely presented for simplicity and is not intended to be limiting to the present invention. Brief Description of the Drawings The present invention will be explained in more detail, by way of example, with reference to the drawings in which: Figure 1 shows an overview of an exemplary process of an embodiment of the invention for receiving claims and distributing funds within a reinsurance business. Figure 2 is a schematic diagram showing an exemplary system of the invention. Figure 3 is a screenshot showing a model current account summary according to an embodiment of the present invention. Figure 4 is a block diagram showing an exemplary embodiment of the present invention that shows a sequence of events that enables a customer to receive automated payments and account information when interacting with a reinsurance company. Figures 5-36 are exemplary screenshots that can be used in the exemplary processes and systems described in Figures 1-4 above. Figure 37 shows an exemplary process through which a customer makes a payment advice to a business. Figure 38 shows an exemplary process through which a customer makes a pairing advice to a business. Figure 39 shows an exemplary process through which a customer makes a payment request to a business. Detailed Description of the Preferred Embodiments Exemplary systems and methods according to the present invention utilize a universal interface between a customer and a business to facilitate transactions between the customer and the business. The exemplary systems and methods presented herein decrease the time and labour associated with conventional claims-processing routines, resulting in decreased costs and increased efficiency in transactions between the parties. Although the exemplary embodiments described herein are made with reference to the reinsurance industry as an example, the invention is not limited to this type of business. Other types of businesses can benefit from the exemplary systems and methods described herein. For example, insurance corporations, government agencies, and other entities that distribute funds or licenses, or other similar businesses or organizations may benefit from the systems and methods described herein, with expected modifications, apparent to one having skill in the art, to conform to the specific organization. As described above, the reinsurance industry, for exampie, is characterised by a relatively high level of trust between the reinsurers and their customers (insurance companies). In addition, there are typically a large volume of transactions between each customer and the reinsurer, i.e., one-time customers are rare. These characteristics of the reinsurance business create opportunities for improvement in transaction processing. Because of the relatively high level of trust between the reinsurers and their customers (insurance companies), it is practical to allow customers access to internal account records. In this way, customers can review records and provide input (e.g., payment advice or requests for payment) to improve accuracy and efficiency. Of course, there must be a user interface that facilitates such customer interaction. In addition, because there are typically a large volume of transactions between each customer and the reinsurer, it is possible to improve transaction processing by pairing and offsetting debits and credits. In the insurance-reinsurance context, a process for receiving and handling customer claims is shown in Figure 1. System 100 includes a front office portion 111 and a back office portion 112. Although the front office portion 111 and back office portion 112 are shown having certain functions, such functions may be shifted accordingly such that each office portion 111 or 112 may have more or fewer functions than is shown in Figure 1. Front office portion 111 is primarily involved in the function of placement 130. Generally, placement 130 Involves negotiation between a customer (e.g., an insurance company) and a business {e.g., a reinsurer) to distribute risk. The end result of the negotiation is typically a contract or treaty or modification to an existing contract or treaty. Several bundles of contracts 131 and 133 are obtained in this front office portion 111 function. Each of the bundles of contracts 131 and 133 may share one or more characteristics. Such acceptances 131 and 133 may include, for example, policies of the same line of business, currency, types of reinsurance, reinsured or the like. Each bundle may include as few as a single contract and as many as several 1000 contracts. Other types or organizations of the bundles are also possible. After the placement 130, the process proceeds to a series of back office portion 112 functions, including a technical accounting component 140 and a financial accounting component 150. In the technical accounting component 140, the acceptances 131 and 133 lead to two claims bordereaux 141 and 143, and premiums bordereaux 142 and 144, respectively. Generally, bordereaux are lists of all premiums or claims movements during a certain accounting period for a specified bundle of contracts. The totals are posted in the financial accounting component 150, which also includes current account. All detailed movements are posted in the technical accounting component 140. The two Bordereaux then become the basis for one statement of accounts 151 or 153, respectively, per agreed accounting period. Such period could be, for example, monthly, quarterly, or other determinable time period. The one or more statement of accounts 151 and 153 then lead to a financial accounting 150 function, which includes current account. Current account allows a customer to perform one or more financial transactions such as, for example, a payment request 161, a payment advice 162, or a pairing advice 163. Each of these transactions will be described in more detail below. Other financial transactions are also possible. In addition, from current account, it is possible to view a payment request already submitted, to view and/or to delete a payment advice, to view payment, and to view pairing information. Referring to the functional aspects of the system and method shown in Figure 1, the current account or financial accounting 150 functionality is the last step in the reinsurance value chain that is visible to a customer. Furthermore, typically one current account exists per customer and contains all the balances of technical reinsurance bookings (e.g., statements of accounts 151 or 153), cash call related bookings, payment bookings and information about matching/pairing status. A cash call is an advance payment the insurance company may request from the reinsurer in case of a large claim settlement. The amount will be debited in the next regular statement of accounts. Figure 2 is a schematic diagram showing an exemplary system of the invention. System 200 of the invention includes server 240 and account processing engine 250. Server 240 can include one server or a network of servers. Server 240 is associated with business 230. For example, server 240 can be owned, operated, or otherwise maintained by or on behalf of business 230. Server 240 is associated with account processing engine 250. Account processing engine 250 is associated with a processor that is configured to execute processes and methods in accordance with the present invention as described herein. For example, application processing engine 250 may execute various processes called for by current account. Server 240 is accessible to one or more customers 210 over network 220. Firewall 242 of server 240 is provided to prevent unauthorized access to server 240. The use of firewall 242 is well known in the art and it is therefore not described in detail herein. Customer 210 and business 230 can communicate with each other via network 220. Network 220 can be any known communications network. Preferably, network 220 is the Internet. In the context of the reinsurance industry, customer 210 is an insurance company that sells insurance policies to insured parties. Business 230 is a reinsurer that deals with customer 210 in provision of reinsurance services associated with the insurance policies of customer 210. For example, when customer 210 (e.g., an insurance company) provides business 230 with a payment advice that includes input data, the input data flows through application modules associated with server 240. For convenience, the process associated with the applications modules is hereinafter referred to as the "current account" process. The request is first validated technically to ensure that the input data provided by customer 210 fits the minimum data quality requirements. The data quality requirements can include, for example, correct syntax, each value of the Input data Is within a predefined (context-less) range, basic relationships between values in the request are correct (e.g., DATE1 is before DATE2), and so on. Next, modules/functions associated with server 240 can concentrate on business validation rules for several processes within current account. For example, the processes may include payment advice, payment request, pairing advice. The business validation rules can restrict a customer's freedom towards a desired data range and helps to standardize the processes. Filter rules or "business checks" may also be provided to determine afterwards whether manual intervention by the business is needed. The systems and methods of the present invention are designed to be user-friendly and readily accessible to a customer with minimal manual intervention by a business utilizing such systems and/or methods. Thus, a non-limiting means of providing access to the systems and/or methods of the present invention is through the Internet. A customer may readily access the customer's account through the Internet at any time and from any place in the world that allows Internet access. Such access may either be provided through hardwire means or remotely, i.e. network 220 may also include wireless networks, for example mobile radio networks or wireless local area networks (WLAN). This increased flexibility and lack of restraint with respect to time and place for account access provides a tremendous benefit to the customer. Likewise, such flexibility offered to the customer provides the business with an increased customer base of those who are attracted to such flexibility. A customer may access a system according to the present invention by, for example, typing a specific Internet address that enables access to the customer's account. Typically, a login page may be used to ensure secured access to the customer account, and to prevent unauthorized or fraudulent use of the customer account. Once a customer logs into the customer account properly, a menu-drive homepage may be provided, with various option pages, such as that shown as exemplary screenshot 300 in Figure 3. Although screenshot 300 is shown having particular features and traits, other screenshots, such as screenshot 500 shown in Figure 5 and screenshot 600 shown in Figure 6 are within the purview and scope of the present invention, which is not limited to the screenshot shown in Figure 3. Exemplary screenshot 300 is shown having a number of menu items 310. Each menu item contains a separate screen of features and options for the customer. The exemplary menu item shown in Figure 3 is current account 313. Other menu options include, but are not limited to, contracts 311, placements 312, user administration 314, address book 315, and statistics 316. Contracts 311 is intended for viewing details of bound contracts and accessing the premiums/claims bordereaux. Placement 312 is the negotiation area where insurance and reinsurance company submit offers, counter-offers, and accept or decline. In user administration 314, the insurance company can administer its customer account (i.e., users passwords, users access rights, company address, and company bank accounts). Address book 315 may be used for registering email accounts of other (competing) reinsurers should the client wish to forward offers to other reinsurance companies as well. In statistics 316 the insurance company may generate and view online reports on its book of business and its transactions with the reinsurer. The current account 313 is shown in Figure 3 as an example and is not intended to be limiting of the invention or the types of screenshots that are available. Within the current account 313 shown in Figure 3, a number of further options are provided to the customer that facilitate the customer's access and functional capacities. Header section 320 provides readily accessible parameters that the customer may change to access part or all of the customer account. Some of the options that may be changed in the header section include, but are not limited to, entry dates for analysis, transaction currency, and status of various account postings. Header section 320 can also filter the current account by group company information, posting date, status of booking, and currency. Other options, such as, filtering by reinsurer if more than one reinsurer is associated with the application, are possible. Other sections of the screenshot 300 of current account 313 are optionally available depending on the particular customer account and whether there are applicable items within each section. For example, upper section 330 may include, but is not limited to, particular items that have been entered into the system by the customer. Such items could include matter descriptions, relevant dates, and value amounts. Upper section 330 further contains all of the selected bookings. These bookings could include, but are not limited to, balances of confirmed statement of accounts 151 or 153 and their rectifications, payments (in or out) and cash call requests/regulations. The total of all bookings may be shown on the line "Balance Due," which is either a credit (in favour of the reinsurance company) or a debit (in favour of the customer). A detailed view may also be presented via a hyperlink, by pointing and clicking on the text of the bookings. Middle section 340 contains payments in transit or in the approval process. The sum of these bookings and the Balance Due form the Balance Preview. Lower section 350 includes matters that are to be considered to be due or payable in the near future. Such "future due" bookings are pro memoria (e.g., cash call contra entries). Finally, a footer section 360 includes a button option set that allows a customer to trigger a financial transaction. Such functional keys enable the customer to request specific functions from the system that are processed automatically without manual intervention. Such functions include, but are not limited to, payment advice 362, payment request 364 or pairing advice 363, as will be described in more detail below. Other optional functions are possible, such as, for example, the customer doing an online reconciliation of his current account with the displayed postings, storing comments to individual postings, and scheduling alarms for future actions. Systems and processes according to the present invention automate accounting processes that have typically required time-consuming and inefficient manual handling. Further, they also improve efficiencies in other transaction areas. Such other areas include, but are not limited to, data exchange between customer and company (e.g., reinsurer), validation and plausibility checks, confirmation about the status of a transaction and changes of status. Other areas may also receive benefits from the current invention. Access to a customer's current account offers several kinds of functionality including, but not limited to, the ability of the customer to view and filter online (anytime, anywhere) all of the bookings in the system. The customer also has the ability to interact and trigger a financial transaction, depending on the credit/debit balance position. Access allows the customer full transparency of postings and enables him to reconcile his own accounts without involving personnel of the business. Other functionalities are also apparent to one having ordinary skill in the art. Figure 4 shows an exemplary map 400 relating to the viewing and transaction processes. Map 400 is merely an example of the viewing and transaction procedures, and the current invention is not limited to this specific example. Other examples and procedures serving a similar function and having similar capabilities are within the purview and scope of the present invention. Map 400 includes several, vertical columns that describe some of the functionalities of the exemplary system shown and several horizontal rows that describe data at various stages through the system. A customer may interact with information on the business's servers by logging into the system interface 401. The system interface may be via a web page maintained by the business on the Internet. The business may provide secure access by requiring a customer to login to the system using, for example, a user name and password. A customer may view bookings at any time while accessing the system online. Such viewing may be in general by viewing all available bookings and balances, or more specific by viewing each individual booking detail by hyperlink. Figures 5 and 6 show screenshots 500 and 600 respectively. Figure 5 is an exemplary screenshot 500 of current account showing all bookings and balances for the specified period of time. This period of time does not have to extend through the present so the customer can see the status of his accounts for any period of time available. Figure 6 is an exemplary screenshot 600 of current account where the screen has been filtered to show an opening balance as of a specified date and all remaining balances. When a customer chooses the advise payment option (e.g., selects advise payment 362 from screenshot 300) when viewing the current account 402, shown in Figure 4, the system proceeds to the advise payment column 420, wherein the customer advises the business of an upcoming payment which can be paired with one or previous events. The customer does not need to pair the upcoming payment with any previous events. At the data entry portion 450 of the advise payment option, payment advice portion 421 is initiated. At this stage, the system presents a list of all open (e.g., unsettled) current account bookings as seen in the exemplary screenshot 700 of Figure 7. The customer then selects the open items the customer would like to settle by submitting payment. In the exemplary screenshot 700, the customer has selected open items with a $500 credit and an $11,000 credit for a total balance of $11,500. The system verifies that the sum of all selected postings Is in the system's favour and that the advised value date lies within a predefined limit before continuing. For example, as seen in screenshot 800 of Figure 8, the customer has selected two open items, a $500 credit and a $1000 debit for a total balance of a $500 debit, which is not in the systems favour. When such a situation occurs, the system suggests submitting a payment request or changing the selections. If, however, the amount is in the system's favour, then the customer is asked to input an expected value date. For example, as seen in screenshot 900, the customer has entered an expected value date of August 27, 2001. In the ideal scenario (i.e., the total favours the business) the total is a credit and the system proceeds to calculate payment advice process 423 in the data submission screen portion 460. When the system proceeds to calculate payment advice process 423, the system presents the preferred business bank account depending on, for example, payment currency and the customer's country. Furthermore, a unique reference number is generated that the customer is asked to quote in the payment order. Figure 10 is a screenshot 1000 displaying the expected value date, bank account number, and unique reference number. This reference number is later used to recognize the actual payment and to pair it in an automated fashion with the technical bookings. The customer then submits the payment advise information by clicking on the submit payment advice button. If there is only a relatively small amount of money due (e.g., below a predetermined amount), the customer may choose a set-off without payment. Figure 11 is a screenshot 1100 showing the option of setting-off without payment. In this exemplary scenario, there is a total payment of $1.00. In order to minimize cost a business may offer to set-off without payment (i.e., forego payment). A business may set this amount to any particular amount, such as, for example $20.00. The customer can always elect to make the payment; therefore, screenshot 1100 provides the same information regarding expected value date, bank account number, and unique reference number. If the total amount equals zero, then the business may offer to match the selected debit and credit items. Figure 12 shows screenshot 1200 where the total payment is zero. In this situation, the submit payment advice button is not available because there is no physical payment or bank routing necessary. Therefore, in the exemplary screenshot, the customer may be directed to select the set-off without payment button as a sign of acceptance. If the submission from calculate payment advice process 423 is proper, the system proceeds to payment advice confirmation process 425 in the confirmation screens portion 470. Here, the customer receives a message confirming the successful booking of the payment advice or set-off request. Exemplary screenshot 1300 shown in Figure 13 is an example confirming the successful booking of the payment advice, while exemplary screenshot 1400 shown in Figure 14 is an example confirming the set-off without payment. Once the payment advice confirmation process 425 is complete and the customer has acknowledged it, the system returns to the current account 402. After returning to the current account 402, the customer may automatically ascertain the effects of the just-implemented payment advise. If, however, an error occurs due to technical problems while trying to complete the calculate payment advice process 423, the system proceeds to the failed transaction confirmation process 480. Exemplary screenshot 1500 shown in Figure 15 advises the customer that the transaction has failed and request the customer to try again later. If the problem continues to occur the customer is encouraged to contact the business. After the customer acknowledges this screen, the system returns to current account 402 where the customer may perform any other tasks. When a customer chooses the request payment option (e.g., selects request payment 364 from screenshot 300) under the current account 402, the system proceeds to the request payment column 430, wherein the customer requests a payment from the business for a previous event. At the data entry portion 450 of the request payment option, payment advice process 431 is initiated. The business presents a list of all open (e.g., unsettled) current account bookings to the customer as seen in the exemplary screenshot 1600 of Figure 16. The customer selects which of the open items are to be settled by requesting a payment from the business. In screenshot 1600, the customer has selected open items with a $500 debit, an $11,000 debit, and a $1000.00 credit for a total balance of $10,500. The system then verifies that the sum of all selected postings is in the customer's favour before continuing. For example, as seen in screenshot 1700 of Figure 17, the customer has selected only a $1000 credit and no debit amount. Another example shown in screenshot 1800 of Figure 18, a $1000 credit and a $500 debit for a total balance of a $500 credit, which is not in the customer's favour. When such a situation occurs, the system suggests submitting a payment advice or changing the selections. Yet another example shown in screenshot 1900, another error has occurred. In the ideal scenario (i.e., the total favours the customer) the total is a debit and the system proceeds to calculate payment request process 433 in the submission screen portion 460. When the system continues to the calculate payment request process 433, the business lists some or all of the customer's bank accounts in payment currency as known by the business. The customer then selects the bank account to which the payment should be remitted. Furthermore, the customer can enter a reference text for easy recognition by the customer once the money has been transferred to the customer's designated destination. Figure 20 is an exemplary screenshot 2000 displaying list of customer's bank accounts, place for the customer to enter the reference text, and several buttons. From this screen the customer can choose to submit payment request or to set-off without payment. If there is only a relatively small amount (e.g., less than a predetermined amount) that the business owes the customer, the customer may be asked to agree to a set-off without payment (/.©., forego payment). The system then verifies that all data entry has been entered correctly, and then proceeds to the next process. If the submission from calculate payment request process 433 is proper, the system proceeds to payment request confirmation process 435 in the confirmation screens portion 470. Here, the customer receives a message confirming the successful booking of the payment request or set-off request. Exemplary screenshot 2100 shown in Figure 21 is an example confirming the successful booking of the payment request, while exemplary screenshot 2200 shown in Figure 22 is an example confirming the set-off without payment. Once the payment request confirmation process 435 is complete and the customer has acknowledged it, the system returns to the current account 402. After returning to the current account 402, the customer may automatically ascertain the effects of the just-implemented payment request. The payment request may then be further reviewed by one or more authorized parties (e.g., accountants of the business) before the actual payment is authorized. Such payment may be processed through, for example, payment order to a local operational data store, and from there via an electronic network to the customer's bank. If, however, an error occurs due to technical problems while trying to complete the calculate payment request process 433, the system proceeds to the failed transaction confirmation 480 process and screenshot 1500, as shown in Figure 15, will be displayed. If the customer chooses the pairing advice option (e.g., selects pairing advice 363 from screenshot 300) when viewing current account 402, shown in Figure 4, the system proceeds to the pairing advice column 440, wherein the customer allocates specific payment(s) with specific technical bookings. At the data entry portion 450 of the pairing advice option, the pairing advice process 441 is initiated. The customer is requested to present pairing advice - technical bookings information. If the business is unable to pair a customer's payment to open current account bookings (e.g., due to non-use of payment advice functionality), the customer can do so manually using the pairing advice process. One or more lists of information may be presented to the customer, such lists including, but not limited to, unpaired payment bookings, unsettled (e.g., due or overdue) technical current account bookings (e.g., mainly statements of accounts), or the like, as seen in exemplary screenshot 2300 of Figure 23. Other types of information may also be presented as lists. The customer then selects which of the open items shall be paired with particular payments) by allocating among the open items the ones that are to be matched. The system then first verifies that the sum of all selected technical postings plus an acceptable set-off amount is less than or equal to the total of unpaired payment bookings before proceeding. If the system proceeds to the calculate pairing advice process 442 within the data entry screen portion 450, information relating to the pairing advice - payment bookings is requested. The system presents several lists including, but not limited to, technical current account bookings as selected {e.g., on previous screen) by the customer for matching, all unpaired payments contained In the current account, or the like, as seen in exemplary screenshot 2400 of Figure 24. Other lists are also possible. Furthermore, the system proposes how to pair or allocate the open payment bookings using, for example, a first-in first-out principle. In the exemplary screenshot 2400, the system has proposed matching a $350 debit and a $310 debit with a $500 credit. The customer may then instruct which and how much of the open payments shall be paired, either fully or partially. The system may be configured to allow only one partial selection. The system may then verify the input. In case of a small (e.g., predetermined amount) discrepancy between technical and payment bookings, the system proposes a write-off of the pairing difference, either by the business or the customer. Exemplary screenshot 2500 of Figure 25 shows a scenario where the business is willing to write off the pairing difference amount. If the customer selects only full payments and there is a small discrepancy between the technical and payment bookings the system may present the customer with either exemplary screenshot 2600 of Figure 26 or exemplary screenshot 2700 of Figure 27. More specifically, screenshot 2600 shows the scenario where the business is willing to write off the difference because the checked full payments is slightly smaller than the total of the open item. Screenshot 2700 shows the scenario where the business asks the customer if he is willing to write off the difference because the checked full payments is slightly greater than the total of the open item. If the customer is not willing to accept the set-off the customer can go back and make different selections. If the submission from calculate pairing advice process 442 is proper, the system proceeds to pairing advice submission process 443 in the submission screen portion 460. In this process, the business presents the customer with the result of the previous two processes for review. Exemplary screenshot 2800 of Figure 28 shows a screen summarizing the proposed pairing. The customer can then conduct a final verification of the information before submitting the data. If the data is submitted, the system processes the pairing advice and returns to current account 402 and has immediate access to the results of the just-performed pairing instructions. If there are any processing errors (e.g., technical), the system proceeds to the failed transaction confirmation process 480 and screenshot 1500, as shown in Figure 15, will be displayed. In addition to advising of a payment, requesting a payment, or making a payment from current account, it is possible to see details of existing payment advice, payment request, or pairing by selecting it from the screen. For example, a customer on screenshot 300 could select "Your Payment Advice" to review the details about the payment advice. When a customer chooses to view a payment request (e.g., selecting the existing payment request) when viewing the current account 402, shown in Figure 4, the system proceeds to the view payment request process 491 in the current account transaction details portion 490. The customer is presented with details of the payment request. Exemplary screenshot 2900 of Figure 29 shows information about the payment request. In this exemplary embodiment, no further action is possible from this screen accept to return to current account. When a customer chooses to view a payment advice (e.g., selecting the existing payment advice) when viewing the current account 402, shown in Figure 4, the system proceeds to the view payment advice process 493 in the current account transaction details portion 490. The customer is presented with details of the payment advice along with the option of deleting the payment advice. Exemplary screenshot 3000 shows information about the payment advice. In this exemplary embodiment, the customer has an option to delete the payment advice. If the customer chooses to delete the payment advice, the system may first request confirmation as seen in screenshot 3100 of Figure 31. If the customer confirms the deletion of the payment advice, the system proceeds to delete payment advice process 495 in the current account transaction details portion 490. The system deletes the payment advice and presents confirmation that the payment was deleted. Exemplary screenshot 3200 of Figure 32 advises the customer that the payment advice was deleted. When a customer chooses to view pairing information while viewing the current account 402, shown in Figure 4, the system proceeds to the view pairing information process 499 in the current account transaction details portion 490. The customer is presented with details of a pairing in screen shot 3500 of Fig. 35. The screen shot 3500 may display details about the pairing process and the customer can view details from the respective statement of accounts by clicking on one of the paired items. Screen shot 3600 of Fig. 36 shows rectification information as well where two statements of accounts have been rectified. If the pairing resulted in a partial pairing, the information is split into a "paired" portion and an "unpaired portion." When a customer chooses to view a payment when viewing the current account 402, shown in Figure 4, the system proceeds to the view payment process 497 in the current account transaction details portion 490. The customer is presented with details of either an incoming payment made by the customer in favour of the reinsurer, as seen in screen shot 3300 of Fig. 33, or an outgoing payment from the reinsurer in the favour of the customer, as seen in screen shot 3400 of Fig. 34. The payment screen can show the rate of exchange for the incoming or outgoing payment. If the payment is partially paired as shown in screen shot 3300, the customer is given an opportunity to viewing the pairing by clicking on the according button. The current account system and processes described above can be used in a back office context. In the back office context, Figure 37 shows an exemplary process 3700 through which a payment advice may be processed by the business in a preparation-negotiation-performance-acceptance (PNPA) model. Once a customer has accessed current account through the business supported interface and selected advise payment, the system proceeds to the "Preparation" portion of the PNPA model. The system obtains the information provided by the customer regarding amount, expected value date, and which items to pay or set-off at "D: Register Payment Advice." The system validates the payment advice at "V: Validate payment advice" and if it is validated, the system seeks web confirmation at "C: Confirm Payment/Set-off advice." If not, the system indicates to the customer the nature of the error and await correction. Once the customer confirms the payment of set-off, the system proceed to either "P: Package Information-Pay Adv." or "P: Package Information - Set off' accordingly. The "P: Package Information-Pay Adv." contains information, such as, advised items, value date, total amount, reference number, and business bank account details. The "P: Package Information - Set off1 includes information, such as, advised items and write off amount (if any). During the "Negotiation" portion of the PNPA model, the system receives the package information at either "D: Get packaged information-Pay Adv." or "D: Get packaged information - Set off." The information may optionally go through several checks at T: Business check Payment Advice." or "F: Business check Set off." Checks for payment advice may include late payments for minimum deposits. Checks for set-off may include determining that the customer is not bankrupt. These checks are merely exempiary and if no checks are provided the system passes the information to the "Performance" portion of the PNPA model. At "Performance" the system either passes to "A: Make booking (Payment)" or "A: Make booking (Set off)." "A: Make booking (Payment)" causes the system to post a preliminary entry to current account and change the status of the selected open items to "payment in transit." "A: Make booking (Set-off)" causes the system to post DIFF booking and matching payments. If the payment advice resulted in payment, the system indicates payment advice processed, if the payment advice resulted in a set-off, the system proceeds to "A: Export Pairing Information to LODS." From there the system indicates Set-OfT advice processed. In the back office context, Figure 38 shows an exemplary process 3800 through which a payment request may be processed by the business in a PNPA model. Once a customer has accessed current account through the business supported interface and selected payment request, the system proceeds to the "Preparation" portion of the PNPA model. The system obtains from the client the bookings in favour to client and may also include bookings in favour to the business if they are overdue, amount, currency, statement of account reference, clients bank account, and a unique identifier if entered by the client at "D: Request Payment." The system validates the payment request at "V: Validate Payment Request" and if it is validated, the system proceeds to either "P: Package information - Pay Req" or "P: Package Information - Set off' accordingly. The "P: Package Information - Pay Req." contains information, such as, advised items, total amount, reference number, and customer bank account details. The "P: Package Information - Set off' includes information, such as, advised items and write off amount (if any). During the "Negotiation" portion of the PNPA model, the system receives the package information at either "D: Get packaged information-Pay Req." or "D: Get packaged information - Set off." The information may optionally go through several checks at *F: Business check Payment request." or "F: Business checks - Set off." Checks for payment advice may include late payments for minimum deposits. Checks for set-off may include determining that the customer is not bankrupt. These checks are merely exemplary and if no checks are provided the system passes the information to the "Performance" portion of the PNPA model. At "Performance" the system proceeds to either "A: Make preliminary booking (pay req)" or "A: Make preliminary booking (set off)." "A: Make preliminary booking (pay req)" causes the system to post a preliminary entry to current account and change the status of the selected open items to "payment in transit." It also determines a payment due date in the future, for example, three days. "A: Make preliminary booking (setoff)" causes the system to make a preliminary booking. After making the preliminary booking, the system seeks confirmation from the customer at either "C: Confirm Set off request" or "C: Confirm Payment request in the "Acceptance" portion of the PNPA model. Once the customer confirms, the system indicates either "Payment Set Off processed" or "Payment Request Processed." In the back office context, Figure 39 shows an exemplary process 3900 through which pairing advice may be processed by the business in a PNPA model. Once a customer has accessed current account through the business supported interface and selected payment advice, the system proceeds to the "Preparation" portion of the PNPA model. The system obtains the information provided by the customer regarding the selected open or overdue items for pairing at "D: Select open/overdue items for pairing." The system validates the pairing at "V: Validate Pairing." If not validated, the system returns to "D: Select open/overdue Items for pairing." If validated, the system requests the customer to allocate unpaired payments, either fully or partially, to the open/overdue items selected for pairing at "D: Allocate unpaired payments." The system validates the allocation at "V: Validate Allocation." If not validated, the system returns to "D: Allocate unpaired payments." If validated, the system proceeds to "P: Package information - Pairing." The "P: Package information - Pairing" contains information, such as, selected payments and selected open/overdue items. During the "Negotiation" portion of the PNPA model, the system receives the package information at "D: Get packaged information - Pairing." The information may optionally go through several checks at "F: Business check Pairing Advice." These checks are merely exemplary and if no checks are provided the system passes the information to the "Performance" portion of the PNPA model. At "Performance" the system proceeds to "A: Make booking into current account." "A: Make booking (Payment)" causes the system to indicate in current account that the payments are paired and the open/overdue items are settled After making the booking into current account, the system seeks confirmation from the customer at "C: Confirm pairing advice." in the "Acceptance" portion of the PNPA model. Once the customer confirms, the system indicates "Pairing advice processed." Each of Figures 37-39 provide keys indicating the nature of the processing that occurs at each step. It is understood that other processing means may be used without departing from the scope of the invention. The exemplary systems and methods described above according to the present invention have many advantages. One such advantage is that the interaction between the customer and the business is automated. This automation reduces the costs and errors associated with non-automated processes, such as, for example, person-to-person communications. Furthermore, all transactions are electronically recorded, thus reducing the potential for miscommunicatlon between live parties. Another advantage of this system is that a customer's balance can fluctuate day by day. One day the customer may owe the business and the next be entitled to the payment. This system provides full transparency for the client because he can see the daily values and use them to reconcile his accounts. Through the system described above, a customer can choose when it is best to act to make a payment or request payment because he is in full control of his accounts. This is beneficial to the business as well because they can rely on the customer's input, eliminate the need of manual entry, and minimize the amount of processing when payments from the customer are made or payments to the customer are required. Another unique advantage of the systems and methods according to the present invention is their ability for rapid expansion. Although the present invention is presented with very specific examples of procedures that are most commonly encountered in the reinsurance business, the invention is not restricted to this type of business. Any business that could benefit from automating transactional encounters between the business and its customers would benefit from the use of this invention. The parameters, options and paths shown in the exemplary embodiments of the figures could be programmed to account for the specific requirements and unique business options of any other business. In describing representative embodiments of the invention, the specification may have presented the method and/or process of the invention as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. As one of ordinary skill in the art would appreciate, other sequences of steps may be possible. Therefore, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. In addition, the claims directed to the method and/or process of the invention should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the sequences may be varied and still remain within the spirit and scope of the invention. The foregoing disclosure of the embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be apparent to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims appended hereto, and by their equivalents. 1. Computer-based system for transacting business between a customer (210) and a business organization (230), the system comprising: A server (240) used by the business organization (230) and being accessible by the customer (210) via a telecommunication network (220), A customer account housed on the server (240), the customer account containing account bookings associated with the customer (210), characterized in that the system further comprises: means for the customer (210) to select via the telecommunication network (220) a function to be processed automatically by the system, the function enabling the customer (210) to select via the telecommunication network (220) open items from a list of account bookings associated with the customer (210), means for calculating a balance for the items selected from the list of account bookings, considering a debit or a credit status associated with each of the account bookings, a debit being in favour of the customer and a credit being in favour of the business organization, and means for comparing the balance to a predetermined amount and to set off the items selected from the list of account bookings without payment when the balance is below the predetermined amount. 2. System according to claim 1, characterized in that it further comprises means for verifying that the balance is in favour of the system before continuing a payment advice as the selected function, and in that the system further comprises means for verifying that the balance is in favour of the customer (210) before continuing a payment request as the selected function. 3. System according to one of the claims 1 or 2, characterized in that it further comprises means for making a submit payment advice button not available to the customer (210) when the balance is zero. 4. System according to one of the claims 1 to 3, characterized in that it further comprises means for generating and communicating to the customer (210) via the telecommunication network (220) a unique reference number associated with a payment advice as the selected function, in that it further comprises means for receiving an electronic payment order via the telecommunication network (220) and for pairing the electronic payment order with items selected from the list of account bookings based on the unique reference number included in the electronic payment order. 5. System according to one of the claims 1 to 4, characterized in that it further comprises means for the customer (210) to allocate via the telecommunication network (220) account bookings representing payments from the customer (210) with account bookings that are unsettled, and means for calculating a difference between the account bookings representing payments and allocated unsettled account bookings and for writing off the difference when the difference is below a predetermined amount. 6. Computer program product comprising: computer program code means for controlling one or more processors of a computer used by a business organization and configured to be accessed by a customer (210) via a telecommunication network (220), the computer program code means controlling the processors of the computer such that the computer stores account bookings associated with the customer (210) in a customer account housed on the computer, characterized in that the computer program product comprises further computer program code means for controlling the processors of the computer such that the computer receives from the customer (210) via the telecommunication network (220) instructions to select a function to be processed automatically by the computer, the function enabling the customer (210) to select via the telecommunication network (220) open items from a list of account bookings associated with the customer (210), that the computer calculates a balance for the items selected from the list of account bookings, considering a debit or a credit status associated with each of the account bookings, a debit being in favour of the customer and a credit being in favour of the business organization, that the computer compares the balance to a predetermined amount, and that the computer sets off the group of account bookings without payment when the balance is below the predetermined amount. Computer program product according to claim 6, comprising further computer program code means for controlling the processors of the computer such that the computer verifies that the balance is in favour of the system before continuing a payment advice as the selected function, and such that the computer verifies that the balance is in favour of the customer (210) before continuing a payment request as the selected function. Computer program product according to one of the claims 6 or 7, comprising further computer program code means for controlling the processors of the computer such that the computer makes a submit payment advice button not available to the customer (210) when the balance is zero. 9. Computer program product according to one of the claims 6 to 8, comprising further computer program code means for controlling the processors of the computer such that the computer generates and communicates to the customer (210) via the telecommunication network (220) a unique reference number associated with a payment advice as the selected function, and that the computer receives an electronic payment order via the telecommunication network (220) and pairs the electronic payment order with items selected from the list of account bookings based on the unique reference number included in the electronic payment order. 10. Computer program product according to one of the claims 6 to 9, comprising further computer program code means for controlling the processors of the computer such that the computer receives from the customer (210) via the telecommunication network (220) instructions to allocate account bookings representing payments from the customer (210) with account bookings that are unsettled, and that the computer calculates a difference between the account bookings representing payments and allocated unsettled account bookings and writes off the difference when the difference is below a predetermined amount. 11. Computer-based system for transacting business between a customer (210) and a business organization substantially as herein described with reference to and as illustrated in the accompanying drawings. 12. Computer program product substantially as herein described with reference to and as illustrated in the accompanying drawings.

Documents:

1029-CHENP-2007 CORRESPONDENCE OTHERS 16-01-2012.pdf

1029-CHENP-2007 AMENDED CLAIMS 10-04-2013.pdf

1029-CHENP-2007 AMENDED CLAIMS 25-06-2013.pdf

1029-CHENP-2007 AMENDED PAGES OF SPECIFICATION 10-04-2013.pdf

1029-CHENP-2007 CORRESPONDENCE OTHERS 15-10-2013.pdf

1029-CHENP-2007 CORRESPONDENCE OTHERS 18-09-2012.pdf

1029-CHENP-2007 CORRESPONDENCE OTHERS 24-09-2013.pdf

1029-CHENP-2007 CORRESPONDENCE OTHERS 19-11-2013.pdf

1029-CHENP-2007 EXAMINATION REPORT REPLY RECEIVED 10-04-2013.pdf

1029-CHENP-2007 FORM-3 10-04-2013.pdf

1029-CHENP-2007 OTHER PATENT DOCUMENT 10-04-2013.pdf

1029-CHENP-2007 OTHER PATENT DOCUMENT 25-06-2013.pdf

1029-CHENP-2007 OTHERS 10-04-2013.pdf

1029-CHENP-2007 EXAMINATION REPORT REPLY RECEIVED 25-06-2013.pdf

1029-CHENP-2007 FORM-3 25-06-2013.pdf

1029-chenp-2007-abstract.pdf

1029-chenp-2007-claims.pdf

1029-chenp-2007-correspondnece-others.pdf

1029-chenp-2007-description(complete).pdf

1029-chenp-2007-drawings.pdf

1029-chenp-2007-form 1.pdf

1029-chenp-2007-form 26.pdf

1029-chenp-2007-form 3.pdf

1029-chenp-2007-form 5.pdf