ZA200304152B - A data processing system. - Google Patents

Description

J

A DATA PROCESSING SYSTEM

FIELD OF INVENTION

THIS INVENTION relates to a data processing system and to a method of controlling data processing in the system. [t also relates to a method of establishing a bank account in an automated fashion and to a data processing system for displaying consolidated client data for a plurality of clients.

Data processing systems for conducting online services, such as those for the purchase of goods and/or services over the internet, are well known.

In order to purchase the goods and/or services, the user of the data processing system must have a credit card and feeds in the appropriate credit card details to purchase goods and/or services. Further, the user typically visits a particular web site to purchase services and the transaction is then carried out between the user and the online service provider. Thereafter, the online service provider obtains the funds for the p purchase from a bank with which the credit card is associated. Thus, the user interacts with a particular service provider which then, in turn, i processes the transactions with the credit card authorities. In a similar fashion, the user may carry out financial transactions and process bank

CONFIRMATION COPY details. Each individual service provider may independently track user transactions but does not provide a consolidated user position a as the user visits each service provider independently.

It is to be appreciated that the invention described in this specification may be applied in an internet environment, an interactive television (TV) environment, a

WAP environment, a PDA environment, or the like. Further, for the purposes of this specification, the term "merchant" should be interpreted broadly to include any provider of goods and/or services via an electronic medium herein referred to as “online”.

SUMMARY OF INVENTION

According to a first aspect of the invention there is provided a method of managing transactions in a data processing system including a plurality of remote merchant servers of at least one merchant, which are operable to offer at least one of predetermined goods and services online to users of remote devices; at least one remote banking institution server of at least one banking institution at which the users have bank accounts, the banking institution server being operable to facilitate payment for goods and services which are purchased online from the merchant by users of the remote devices; and a central computing facility including

AMENDED SHEET at least one central server which is operable to communicate online with the remote devices and with the merchant servers and the banking institution server, the method including the steps of: a) in response to the central server receiving an online request from a user of a particular remote device to effect a particular transaction with said merchant, the central server sending an online instruction to the banking institution to verify whether the user has sufficient funds available for the transaction; b) in response to the central server receiving an online message from the banking institution verifying the availability of funds for the transaction, the central server sending a real-time online instruction to the banking institution server to reserve funds for the transaction; c) in response to the central server receiving an online message from the banking institution confirming the reservation of funds for the transaction, the central server sending an online message to the merchant that it may proceed with the transaction ; and

AMENDED SHEET d) in response to the central server receiving an online message from the merchant that it has processed the transaction, the central server sending an online instruction to the banking institution server to release the reserved funds and to pay said funds to a designated payee in order to complete the transaction.

The method may include registering said users of remote devices by recording predetermined particulars of said users sufficient to identify each registered user, in a database.

The method may include monitoring data processing carried out between each remote device and the banking institute server; retrieving banking data relating to a particular user, from the banking institution and merchant transaction data from the merchant with whom the user transacts; and communicating the banking data and the merchant transaction data to a remote device that is accessible to the user, thereby to provide the user with a consolidated data position.

AMENDED SHEET

According to the second aspect of the invention there is provided a central computing facility for managing transactions in a data processing system, the central computing facility including at least one central server which is operable to communicate online with a) a plurality of remote user devices, b) a plurality of remote merchant servers of at least one merchant which are operable to offer at least one of predetermined goods and services, to users of the remote devices, online,

Cc) at least one remote banking institution server of at least one banking institution at which the users hold bank accounts and which is operable to facilitate payment for goods and services which are purchased online from the merchant by users of the remote devices, the central server including a banking institution interface for interfacing with the banking institution server and a merchant interface for interfacing with the merchant servers, thereby to facilitate online transactions and communications between the banking institution, the merchant and the users of the remote devices, the central server of the central computing facility, being operable to send, in response to receipt of an online request from a user of a particular remote device to effect a particular transaction with said merchant, an online instruction to the banking institution server to verify whether the user has sufficient funds available for the transaction, the central server being operable, if the banking institution

AMENDED SHEET

WQ 02/37729 PCT/IB01/02076 verifies the availability of funds for the transaction, to send a real-time online instruction to the banking institution server to reserve funds for the transaction, the central server being operable thereafter to send an online message to the merchant that it may proceed with the transaction and thereafter, in response to receipt of a message from the merchant that the transaction has been processed, to send an online instruction to the banking institution server to release the reserved funds to a designated payee to complete the transaction.

The central computing facility may be operable to monitor data processing carried out between each remote device and the banking institution server and each merchant server, and to retrieve banking data relating to a particular user, from the banking institution and merchant transaction data from the merchant with whom the user transacts and to communicate the banking data and the merchant transaction data to a remote device that is accessible to the user, thereby to provide the user with a consolidated data position.

The central computing facility may be operable to maintain a record of transactions carried out by users, with the merchant servers and the banking institution server, the central computing facility including a user administration database in which said banking data and merchant transaction data pertaining to each user, is stored.

AMENDED SHEET

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is now described, by way of example, with reference to the accompanying diagrammatic drawings. In the drawings:

Figure 1 shows a schematic block diagram of a web-based data processing system in accordance with the invention;

Figure 2 shows a schematic block diagram of the service interaction provided by a web site of the system;

Figure 3 shows a schematic block diagram of a client consolidated page of the system;

Figure 4 shows a schematic block diagram of a voucher facility of the

AMENDED SHEET

) system;

Figure 5 shows a schematic block diagram of various modules of functional areas of the system;

Figure 6 shows a schematic block diagram of an operational overview of the system;

Figure 7 shows a schematic block diagram of the location of various servers of the system interconnected via the Internet;

Figure 8 shows a high level schematic block diagram of the interaction between a CAS server and various clients;

Figure 9 shows a more detailed schematic block diagram of the interaction between the CAS server and the various clients;

Figure 10 shows a schematic block diagram of a message data dictionary of the system;

Figure 11 shows a high level schematic block diagram of a message formatter;

Figure 12 shows a further schematic block diagram of the message formatter;

Figure 13 shows a schematic block diagram of the TBM system environment;

Figure 14 shows the transaction manager processes;

Figures 16 to 22 provide details on various processes and their associated actions;

Figure 23 shows a schematic entity relationship diagram of the transaction manager;

Figure 24 shows a high level schematic block diagram of how an account is opened at the banking institution for a new client;

Figure 25 shows a schematic flow chart of the client access, registration, and maintenance procedures;

Figure 26 shows a schematic flow chart of the client registration procedure;

Figure 27 shows a schematic flow chart of the logon process;

Figures 27A to 27H show various logon screens of the system;

Figure 28 shows a screen display of the client registration procedure;

Figure 28A shows a screen display of an Internet banking logon . procedure;

Figure 29 shows a schematic block diagram of the flow process during registration of a user at the banking institution;

Figure 30 shows a schematic block diagram of the client registration procedure during first time logon;

Figure 31 shows a screen display generated by the system for client profile customisation;

Figure 32 shows a further screen layout for client profile customisation;

Figure 33 shows a screen layout of a consolidated position of various services or facilities offered by the system; : Figure 34 shows a schematic block diagram of the client consolidation process;

Figures 35 and 36 show screen layouts used in the client customisation process;

Figure 37 shows an example of a screen layout of the facility to customise a profile and, in particular, to delete an address;

Figure 38 shows an example of a screen layout of a banking aspect of the system;

Figure 39 shows a further example of a screen layout of the banking : aspect;

Figure 40 shows a screen layout for creating a further account;

’ Figure 41 shows a screen layout of a client profile customisation facility;

Figure 42 shows a schematic block diagram of the process for validating a user name and for tracking clients;

Figure 43 shows a schematic block diagram of the tracking process of

Figure 42;

Figure 44 shows the CAS administration process for bank maintenance;

Figure 45 shows a screen layout when the bank tab on the web site is selected;

Figure 46 shows a screen layout of the form for creating a bank;

Figure 47 shows a screen layout of a bank detail confirmation screen;

Figure 48 shows a screen layout for creating a bank product;

Figure 49 shows a screen layout for confirming a bank product;

Figure 50 shows a screen layout for creating a bank card;

Figure 51 shows a screen layout for confirming a bank card;

Figure 52 shows a screen layout of a form for obtaining contact details;

Figure 53 shows a screen layout for creating a branch of a bank;

) Figure 54 shows a screen layout for editing a bank; .

Figure 55 shows a screen layout of a bank product list;

Figure 56 shows a screen layout for editing a bank product;

Figure 57 shows a screen layout for editing a bank card;

Figure 58 shows a screen layout for confirming a bank card change;

Figure 59 shows a screen layout for editing bank product contact person details;

Figure 60 shows screen layouts of further branch lists;

Figure 61 shows a screen layout for editing a bank branch;

Figure 62 shows a screen layout for confirming removal of a bank;

Figure 63 shows a schematic block diagram of the CAS administration product maintenance process;

Figure 64 shows a screen layout of a product category list;

Figure 65 shows a screen layout for creating a new product category;

Figure 66 shows a screen layout of a product provider list;

Figure 67 shows a screen layout for creating a new product provider;

Figure 68 shows a further screen layout of the product list including : product maintenance facilities;

Figure 69 shows a screen layout for creating a new product;

Figure 70 shows a screen layout for confirmation a new product;

Figure 71 shows a screen layout for creating a product contact;

Figure 72 shows a screen layout for creating/editing a product (bank transfer);

Figures 73A and 73B show screen layouts for editing a category of a provider or merchant;

Figure 74 shows a further screen layout for editing a product;

Figure 75 shows a screen layout of a bank transfer list for a particular product;

Figure 76 shows a screen layout of a contact list for a particular product; , 15 Figure 77 shows a screen layout for creating/editing contact details of a particular product;

Figure 78 shows screen layout listing outlets of a particular product;

Figure 79 shows a screen layout for creating/editing an outlet;

Figure 80 shows a screen layout showing voucher types;

Figure 81 shows the CAS administration process for client maintenance;

Figures 82A to 821 show screen layouts of functions that may be executed in regard to clients;

Figure 83 shows a merchant's screen layout relating to the vouchers;

Figure 84 shows a screen layout of a form for a merchant to change contact details;

Figure 85 shows a screen layout of a summary of transactions provided to a merchant which have taken place;

Figure 86 shows a screen layout of voucher details which the merchant may inspect;

Figures 87 to 95 show various screen layouts of the stock brokerage web site;

Figures 96 to 98 show various screen layouts of a comparative insurance web site of the system;

Figure 99 shows a schematic process overview of the housekeeping module or eBroom;

} Figure 100 shows an example of a screen display of the eBroom:

Figure 101 shows a screen layout of a report function selection form:

Figure 102 shows a schematic flow chart of the process for creating a report;

Figure 103 shows a schematic block diagram of the process for running a report; and

Figure 104 shows a schematic block diagram of the process for editing a report.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to the drawings, reference numeral 10 generally indicates a web-based data processing system in accordance with the invention.

The system 10 provides a web site providing subscribers or registered users with enhanced services/facilities. As described in more detail below, a facility to open an Internet bank account directly, a shopping facility, a facility to purchase/view/sell stock online, a facility to obtain comparative insurance, and links to various other web sites are provided.

The system 10 generates vouchers for use by the subscribers or , registered users which may be used at any merchant in the system, vouchers which may only be used at a specific merchant/participant, “20 generic discount vouchers, or the like. Thus, the system 10 allows a registered user to create a bank account at one or more banking

’ institutions and then perform financial transactions with or without the use of vouchers. Further, the system 10 provides the registered user with consolidated financial data showing the current status of the user with all the merchants i.e. statements relating to the bank account, purchases, or the like. The data processing system 10 is also referred to herein as the TBM or icanonline system.

The system 10 includes a transaction manager server 12 and a client administration system (CAS) server 14. The servers 12, 14 are connected to a remote Internet banking server 16 and a remote banking system server 18 of a banking institution 20. Further, the transaction manager server 12 is connected to remote merchant servers of an online shopping facility 22 and a plurality of different web sites 24. Likewise, the CAS server 14 is connected to the web sites 24 which, in particular, include a stockbrokerage web site 26, a comparative insurance web site 28, and various other web sites generally indicated by reference numeral 30. The stockbrokerage web site 26 is connected to a financial institution 29. The CAS server 14 includes a CAS module 32 which is connected to a user front end 34. The user front end 34 is connected to a plurality of users via the Internet. In use, a user logs into a web site provided by the system 10 and is allowed selective access to various data processing functions or services offered by the system 10. Access to certain aspects of the web site are restricted to registered users. } The specific embodiment of the invention is described with reference to personal computers connected to the Internet. It is however important to appreciate that the invention may be applied in a WAP environment, interactive TV environment, POA environment or the like.

The client administration system server 14 handles the client user interfaces and the client registration process which occurs via the

Internet. The transaction manager server 12 handles all transactions and external communications between the various servers forming part of the system 10. Accordingly, the transaction manager server 12 includes a communications module 36 and a transaction controller 38. The banking institution 20 includes back office systems that handle bank account and financial transactions and the Internet banking server 16 provides a facility so that a client can access his/her bank account and perform standard Internet banking tasks. Merchants forming part of the shopping facility 22 optionally elect to provide their clients with the facility to use the system 10 as an alternative payment method. Accordingly, there is a direct interface between “icanonline”, generally indicated by reference numeral 40 and the conventional Transact System, which is the currently known order management system used by Internet shopping web sites.

The financial institution 29 is a stockbroker connected to the stockbrokerage web site 26 which allows a user to invest on a stock exchange, for example, the Johannesburg Stock Exchange in South

Africa. "

Referring in particular to Figure 2 of the drawings, reference numeral 42 generally indicates the service interaction provided by the icanonline web site of the system 10. The web site allows users to be added as shown at 44, a facility to update details of a user as shown at 46, a facility to allow authentication of a user as shown at 48, and selected additional requests as shown at 49. In Figure 3, a client consolidated position of the various facilities or services offered by the system 10 is shown. The user has access to the banking institution 20, the comparative insurance web site 28, the stockbrokerage web site 26, the online shopping facility 22, a facility to customise the user's profile as shown at 51, and an airmail facility 56 which allows mail, e.g. e-mail, or the like to be sent to the user.

As described in more detail below, the system 10 selectively rewards a user with vouchers which may be used to purchase services and/or goods via the system 10. Vouchers may be generated from a report as shown at 54 or from an external list as shown at 55. The voucher generated is then sent via e-mail to the user 567 who can then claim or allocate a voucher as shown at 59 or use the voucher in the online shopping facility 22. The user 57 may allocate and/or select a voucher which may or may not be of sufficient value to purchase goods or, in addition, may use the voucher as partial payment and authorise payment for the balance by the banking institution 20.

The transaction manager server 12 includes various modules of functional areas (see Figure Bb), In particular, the transaction manager server 12 includes a transport services module 61, a batch handler module 66, a system database 65, a recovery manager module 70, and XML utilities 69. The transaction controller 38 provides business processes, general processes and various actions which are executed by a process manager 71. The transport services module 61 forms part of the communications module 36 (see Figure 1) and is responsible for the sending and receiving of messages and information to any external server connected to the system 10. In the embodiment depicted in the drawings, the transport services module 61 uses TCP/IP protocols to communicate with the banking institution 20 and the Transact System of the online shopping facility 22. The communications module 36 includes a message formatter 37 which defines each particular message dependant upon its recipient server. In particular, the messages are formatted to correspond with various message layouts from XML (which is used for the internal format) to specific formats required e.g. by the banking institution 20, the

Transact System, or the like. Messages received from the various external servers are also formatted into an XML format for internal processing. Accordingly, the XML utility 69 is provided to handle the

XML data for internal use. The recovery manager module 70 is arranged to bring the system 10 to the state in which it was prior to a system crash. The batch handler module 66 uploads all batch files received and schedules the corresponding batch processing of data in the system 10.

The transaction controller 28 (see Figure 1) handles the execution of all transactions in the system 10 and is also the mechanism through which external applications interface with the functionality of the system 10 with the assistance of the process manager 71. As described in more detail below, the transaction manager server 12 keeps a record or audit of transactions to allow a client consolidated position to be displayed.

Referring in particular to Figure 6 of the drawings, reference numeral 80 generally indicates an operational overview of the system 10. As can be seen from the overview 80, the transaction controller 38 is interfaced via the message formatter 37 to the banking institution 20 via a TCP server 82, and to the Internet 84, other interfaces, and the Transact System via a further TCP server 86. The transaction controller 38 is also connected to the CAS server 14 and to a CAS database 88. Figure 7 shows the ’ location of the various servers connected via the Internet 84. In the present embodiment, a TBM database server 90 including the CAS database 88 is provided in Cape Town together with an application server 92 which hosts the icanonline web site. The servers 90, 92 are connected to a server 94 which hosts the stockbrokerage web site 26.

The servers 90, 92, 94 are connected via firewalls 96, 98 to the Internet 84 and to the banking institution 20 which is typically located in Durban.

Accordingly, the banking institution 20 includes firewalls and associated computer equipment generally indicated by reference numeral 100.

Computer equipment 102 of the Transact System is connected via a firewall 104 to the Internet 84.

The transport services module 64 (see Figure 5), as mentioned above, is responsible for communication between the system 10 and all other external systems, mainly using TCP/IP and FTP as the communication protocols. For security purposes, the banking institution 20 does not allow outside entities to connect to their network and, therefore, connection between the Internet banking server 16 and the banking system server 18 (see Figure 1), and the transaction manager server 12 and the CAS server 14 is initiated by the banking institution 20. The

CAS server 14 includes the TCP servers 82, 86 with Microsoft

VisualBasic 6.0 and a Windows 2000 platform. The TCP servers 82, 86 are responsible for sending and receiving messages between the CAS server 14 and the financial institution 20 and the Transact System of the online shopping facility 22 via a raw TCP/IP connection. The TCP servers 82, 86 expect acknowledgments from each client every five minutes, and should the TCP servers 82, 86 not receive an acknowledgment, the TCP servers 82, 86 will then notify the CAS server 14 that communication between the CAS server 14 and the financial institution 20 no longer exists. In response to the aforementioned, all outgoing messages to the financial institution will be stored until the client has picked up an uncompleted transaction and completed it.

Reference numeral 106 (see Figure 8) generally indicates a high level design of the TCP servers 82, 86. Temporary memory area 108 is provided using an array or collection and is used to communicate between a sender 110 and a listener 112. The listener 112 listens on a specified port for incoming connection requests and communicates with the message formatter 37. In a similar fashion, the sender 110 writes the necessary data to the temporary memory area 108 and sends a message via TCP/IP protocol to a requested destination. The message formatter 37 takes the data and the message format and merges them into a message with the correct format required by the listener 112. The message formatter 37 communicates with the sender 110 and is operable to strip out any data from a message and forward the data to various modules of the system 10. A transaction object module 114 communicates with both the message formatter 37 and the CAS database 88 and forms part of a payment engine which processes the data and writes the data to the CAS database 88. As shown by line 116, the transaction object module 114 polls the temporary memory area 108 for any status changes.

Figure 9 shows a more detailed schematic block diagram of the interaction between the CAS server 14 and its various clients. : Interaction between the various clients and the CAS server 14 is effected in a two phase process which relates to the sending and receiving of messages respectively. In phase one, the transaction object module 114 is instantiated by the payment engine or message formatter 37.

Thereafter, the transaction object module 114 writes the necessary transactions into the CAS database 88 and calls the message formatter 37 to create a specific message. If a message has been created successfully, it is then passed on to the sender 110. During this process an incoming string has a requested message applied to it using a predefined or specified message format. The message format differs dependent upon the specific destination of the message. Thereafter, an instance of the sender object is created and a message is sent. Messages are received from a message store in memory. The sender 110 sends the message to the destination via communications mediums supporting the

TCP/IP protocol and the transaction identification, message status, or the like is written into the temporary memory area 108. Failed and sent message statuses are defined depending on the status of the message.

In phase two of the process, the TCP servers 82, 86 have a listener object and, only one object can listen at a time once a connection request is received via a port 118. Data from the message is stripped by the message formatter 37 and thereafter stored in the temporary memory area 108. The message transaction identification data is passed into a message echo data section so that the message formatter 37 can link the message to the correct place in the temporary memory area 108. The transaction object module 114 picks up the change in status, as shown by line 120, and processes the data and updates the CAS database 88 accordingly. The system 10 is arranged to deal with communication failures as well as unplanned disconnects. © 25 The communication protocol is arranged so that if the TCP servers 82, 86 do not receive an acknowledgment from the client, the TCP servers 82,

86 then send a request acknowledgment to the client and, in the event of the client failing to respond to the request acknowledgment after two minutes, the TCP servers 82, 86 will then close the connection to the port 118 and listen on the port 118 for a connection requested from the client. Notification to an administrator module of the CAS system 14 and to the client is sent. Further, every five minutes, the content of the temporary memory area 108 is committed to the CAS database 88 for recovery purposes which is performed by a recovery system. Under normal shutdown, the temporary memory area 108 is committed to the

CAS database 88 before shutdown. However, on normal shutdown all transactions are completed and no new transactions can be initiated.

Accordingly, on normal shutdown of the CAS server 14, the shutdown procedure reads data from the temporary memory area 108 to ensure that no transactions are in a sent state. Should any transactions with a sent state be found, the shutdown procedure waits until the transaction has been received prior to performing a shutdown. Further, during the shutdown procedure, the transaction object module 114 may not initiate any new transactions. Accordingly, only once all the transactions have been completed can the CAS server 14 be shut down. Upon an abnormal or unplanned shutdown, the recovery procedure reads from the recovery database and places the temporary memory area 108 into the same state that it was in prior to the abnormal shutdown and, further, the temporary memory area 108 is read and matched to the transactions in the CAS : payment engine database. The CAS server 14 is arranged to notify the client during a subsequent logon of the status of the last transaction i.e. whether or not is was successful or failed.

The message formatter 37 provides flexibility to the system 10 by

’ keeping the message layouts in the database and formats the messages as required dependent upon the requirements of the various clients (see

Figure 10). Reference numeral 122 (see Figure 11) generally indicates the high level design of the functionality of the message formatter 37.

As can be seen from the drawing, the message formatter 37 receives messages 124 and message requests 126 which are then processed to generate data 128 and messages 130. The message formatter 37 includes a message data dictionary 132 as shown in Figures 10 and 11.

The messages 124 may be incoming or outgoing messages from or to any source. The message requests 126 instruct the message formatter 37 to produce a message and a message identifier, destination data, and other data are required as inputs in an XML format. The message formatter 37 then reads the message request 126 and removes the data 128 which is output in an XML format. The message formatter 37 is arranged so that it can handle various different message formats and holds all the logic to create and read messages. Each message, its format and destination are stored in the CAS database 88.

The messages are created using the message formatter 37 and a message format collection 134 (see Figure 12). The message format collection 134 includes instances of the message object and each message object represents a message. Initially, the message format collection 134 is empty and as messages are requested the collection is checked, and if a particular message does not exist in the message collection, it is then added. To add a message to the collection, the message structure is read from the database 88 and a message object is then created. As hereinbefore described, the message formatter 37 includes a message request function and a read message function. The message request function returns messages and the read message function takes an incoming message and places the data either in the temporary memory area 108 or as an XML string depending on various predetermined criteria.

The recovery manager module 70 (see Figure 5) includes three components. Firstly, a recovery component restores the state of the application after a server failure has occurred. Secondly, a shutdown component is used to handle a normal shutdown process ensuring that the application is in a stable state and can be shutdown and, thirdly, a startup component which is used to load all the system variables and check all components of the system 10 on system startup.

Referring in particular to Figure 13 of the drawings, reference numeral 136 generally indicates a schematic block diagram of the transaction controller 38. The transaction controller 38 includes a transaction engine 138 and a payment engine 140, as mentioned above, to control transactions via the system 10. The transaction manager server 12 executes processes and actions, the processes being a logical grouping of various actions or steps that need to be executed to complete a transaction. The main logical processes within the system 10 are shown in Figure 14. Various processes and their associated actions are described in Figures 15-22 of the drawings. Figure 23 provides an entity relationship diagram of the transaction manager 12.

The functions and procedures of the transaction controller 38 are setout below. The fields shown below are the dynamic fields of the messages.

* CreateAccount

Private Function CreateAccount (TransactionDate as Date, PostingDate as Date, bisIBP as Boolean, Sxml as String, Err as string) as string.

Purpose:

Controls the create account process.

Assigns a transaction number.

Precondition:

TransactionDate, PostingDate, blsIBP and sXML cannot be empty.

TransactionDate - used in Message to the banking institution 20, which in this case is NBS.

PostingDate - used in Message to NBS.

The Variable bisIBP is used to decide if AccountEnquiry must be called.

Post Condition:

Message XYZ will be handed back to the caller of this function

ExecTxn.

The Account number is written to the database, and the message transaction table reflects a CreateAccount transaction against the client. . An account is then created for the client.

Message Information:

May be defined dependent on the circumstances.

Error Handling:

Serr is passed by reference and will contain an error message if an error occurred. 5 . AccountEnquiry

Private Function AccountEnquiry (TransactionDate as Date, PostingDate as Date, AccountNumber as varchar, CASTransactionNum as long, byREF sErr as string) as Boolean.

Purpose:

Sends a message to NBS checking if the Client is a NBS client.

Precondition:

This Function is only called if blsIBP = true.

TransactionDate, PostingDate, Account number and CAS TransactionNum cannot be empty.

Post Condition:

Sends message 087 to the NBS and returns a true or false. : True = Client is an existing IBP/phone bank users. :

False = Client is not an existing IBP/phone bank user.

The Message Transaction table is updated.

Message Information:

R-Code/Mweb (server 92 in Figure 7) Acc Enquiry Request 087

Transaction Date

Posting Date

Account Number

CAS Transaction Number (Echo Data)

R-Code/Mweb Acc Enquiry Reply 087

Surname

Initials

R-Codes

Account Descriptor 1

Account Descriptor 2

Internet Account Number

Phone Bank Account Number

CAS Transaction Number (Echo Data)

Error Handling:

Returns true if there were no errors and False if there were errors.

Serr is passed by reference and will contain an error message if an error : 20 occurred. ° Message Builder

Private Function Message Builder (CASTransactionNum as long, byref sErr as string) as string.

Purpose:

Creates a message, which will be sent via http to IBP logon screen.

Precondition:

Preconditions may be defined dependent upon the circumstances.

Post Condition:

Message XYZ is created and returned to the caller of this function.

Message Transaction Table is updated.

The message will contain the Account Number or IBP Number and e-mail address.

Message Information:

System dependent messages may be defined.

Message

IPB Number/Account Number

E-mail

Error Handling:

Serr is passed by reference and will contain an error message if an error occurred. ° Batch Processes

A new client receives an e-mail with a registration code, the client needs to go to the TBM registration page and fill in this code. On filling in of the code the RegistrationDate field on the ClientProfile table is up dated.

A stored procedure schedule under the administrative module or eBroom runs at night and finds all records in the ClientProfile table where the

RegistrationDate is greater or equal to today and IBPConformationData is

NULL.

The results of the procedure must be sent to the message formatter 37 and a file will be created.

This is sent to the NBS using the Transport services.

Fields to add to ClientProfile

IBPConformationDate

Database - First Pass

Entity Transaction

CASTransactionNum

StatusCode

DateTime

TransactionType

Message

MessageNum

Destination : DateTime

MessageTransaction

CASTransactionNum

MessageNum * Create Account

When a new client registers with the TBM system 10, a bank account must be created for the client. The Client will go to the TBM web site and register on the system 10. Throughout the registration process the

CAS system will rely on the transaction manager module to provide information and interface with the bank. The Create Account functional process consists of various transaction manager processes. The business rules for creating an account are as follows: ‘and telephorie numbers. nL bs 0 Bat

The Banking System: server 18 must confirm the receipt of the

Actount Creation message, On confirmation of account création, the : ‘system must pass the TBM account number back to the Transaction’ the Client's identity has been verified the ‘account will be either 05 activated oF rejected: ii ) % : J ir Te Co pe ia hat i:

A client may carry on in the TBM system 10 even though the account : status is only provisionally active. The banking system server 1 8 will ro a transaction if the acéount is not active...

Banking system server 18 will send a:master account number back to

In order to create a new account at the banking institution 20, new client details are captured as shown at block 142 (see Figure 24) which shows a high level design of the process) whereafter an account is created as shown at block 144 and the CAS server 14 then confirms the new client details as shown at block 146. In addition, a message is sent via http protocol from the CAS server 14 to a server of the banking institution 20 as shown by line 148. The banking system server 18 confirms the password as shown at block 150 and, thereafter, the CAS server 14 then despatches a “welcome and congratulations” message to the user as shown at block 152. Thus, a new client captures his/her details on the “icanonline” web site by pressing an “OK” button and, thereafter, the new client is redirected to a confirmation of new client details web page.

When the client presses the confirm button, the create account process is initiated and an account is created for the client with the banking institution 20. Once the account has been created for the client, the client's web browser is directed directly to the financial institution's

Internet banking screen via the Internet banking server 16 and a : password is then selected or, in the case where the client is an existing client of the financial institution 20, the password may be confirmed. It is important to note that the client then communicates directly with the

Internet banking facility of the financial institution 20 and not via any third party. Typically, the communication is via a pop-up screen which may then be closed once the procedure has been completed.

Three different scenarios can be present when creating a new account.

Firstly, the client may be a new client to both the system 10 and to the banking institution 20, secondly, the client may be a new client to the system 10 but an existing client of the banking institution 20 but not its

Internet banking facility and, thirdly, the client may be a new client to the system 10 who is already a client of the financial institution’s Internet banking facility.

Block Funds / Transaction Authorisation

When a client buys goods through an online Internet store using his TBM account, the transactions must be authorised in the same manner as a standard credit card transaction. During this process the clients bank account is queried to verify that the client has sufficient funds. The client has to authorise the transaction at the bank's Internet banking site. On doing this, an amount equal to the transaction value is blocked in his account. 2. Funds are Blocked for a period according to default parameters

4." Ifthereis a reservation and insufficient funds to satisfy (because 2 3 of charges) allow the account to go overdrawn.

TBM accounts : Care allowed to go overd rawn through batch charg es being : i generated TLE se aE Te 5. The Block message requests alithorisation for a certain amount itis released via an Unblock message... Croll] ’ 7. : The Blo ck message fields are : wid So I: : wh i ES iE ! 0 i Reservation Amount pA a i a , oe p Fil : : ow : i + ‘Reservation Date oT Ln CTE me 10.2 When a client makes. a purchase, CAS notifies the Banking toni vet i dado Nebo seal csbbod 158 os ait.

they cannot perform the transaction. The account Number and

EE password will be validated and the relevant funds put on hold if

Transaction Authorisation Process

The following steps are followed in the Authorisation process: . The client shops on the Internet (shopping site that supports the

TBM payment method, e.g. Shopzone); . As part of the checkout of pay process the client has to select a payment method, e.g. Visa, Mastercard or TBM; ° On selecting TBM the client is requested to authorise the transaction. When the client clicks on the Authorise button a second instance of the web-browser is opened and the client is redirected to the TBM site. As part of this redirection process the basic client and transaction information is passed to TBM via

HTTP; . The TBM site first reads the TBM cookie on the client's machine to verify that the client has logged onto the TBM web site prior to moving to the shopping site, by checking the date and time values in the cookie. If it is less than the predefined value (20 minutes), the client is considered logged on; . The Pre-Order Authorisation process is called which logs the . transaction in the database and requests the client's account balances from NBS; ° The client is then presented with his available vouchers where he can select the vouchers to be used;

° The client is then requested to authorise the transaction by providing his IBP password on the NBS Internet banking site. As part of the redirection to the IBP site, details regarding the client's portion of the transaction is send to the bank (via HTTP). For this the Process Order Auth(Client) process is used; . On arrival back at the TBM site the reply message is read and if authorised, the relevant details are stored in the database (Process

Reply process);

J In the background the rest of the transaction (TBM and/or

Merchant Voucher transactions) is submitted to NBS for authorisation (Process Order Auth(Vouchers); o The second instance of the browser is killed and the client is requested to complete the buying process by clicking on the Buy button on the original payment browser window; 15 . On clicking Transact will generate a standard authorisation request which is send to TBM; : ° TBM receives the request and checks the TBM database for the authorisation of the corresponding transaction (Final Order Auth

Request). If the transaction was successfully authorised, TBM sends the authorisation number as part of the confirmation back to

Transact.

Settlements

The Merchant, on shipping the ordered goods to the client, initiates settlement or payment requests. The settlement transactions are © 25 captured on the Order Management system (Transact) and sent via

TCP/IP to the TBM system 10.

[ Business Rules ~ | a iE Settlements . are initiated via the Unblock message that * unblocks the hold on the account and processes a payment for the specified amount ‘which ‘may not exceed the Blocked 2... :"Unblocking is a request that comes from the merchant to NBS. * "Request for cancellation of an order, in which case a previous: «order wds submitted and funds were blocked and now nsed to ov beunblocked: co email oe Dat customer and the mérchant now request his payment. = 4

High Level Design -

The diagram below shows a high level design of the unblocking of funds and the different components involved.

On receiving the settlement transaction from Transact, the TBM system

Ti i Transport

BB

Request.

executes the following steps: ° The TBM database is checked to confirm that the transaction is still outstanding (Settlement Request process); . If the request is for a partial transaction (the transaction is not final yet), TBM logs the request in the database and waits for the final settlement request. Only then will the full transaction be processed; o On receiving the final settlement request, the Transaction Manager evaluates the full transaction to determine if any partial cancellations were part of the transaction. If there were, the transaction controller 38 initiates the Voucher system to recalculate the transaction values; o It then generates the settlement/unblock transactions for the client and voucher transactions which are then sent to the banking institution 20.

Unblock Request o A Request coming from one of the merchants.

Transaction Controller . Handles transactions between NBS and the merchants.

Message Formatter . Format the messages sent into it from the source version to a message that can be interpreted by the destination.

Transport Service

. Transport message from Transaction Controller 38 to NBS 20 and back.

NBS

° The banking side.

Detailed Design

Merchant

The merchant is an online entity that sells products or services. When a user logs on and buys from the merchant, funds are blocked on NBSs side. The UnblockFunds Function’s purpose is to either cancel or pay out the funds that were blocked.

A function named UnblockFunds in the transaction controller 38 is then called.

Transaction Controller

This function’s layout is as follows: :

Public Function UnblockFunds (sXMLDetail as String, Vdestination as

Variable, TransactionType as UnblockTransactionTypes) as Boolean

The purpose of this function is to request from NBS 20 that funds are either unblocked or paid out to the merchants account. The function is contained in the transaction controlier 38.

Components of Function . SXMLDetail: All the detail needed by NBS 20 is converted into

XML by the WEB interface and is then sent via this function. . VDestination: This is the destination to which the message is sent which in this case will be NBS 20. ° TransactionType: An ENum is created which must be called

UnblockTransactionType. This ENum has two variables in it called

Settlement and Cancellation. This indicates whether or not the amount in question must be paid out to the merchant or if the transaction must be cancelled.

The very first step of this function is to validate the transaction. This is accomplished by checking the details of the Payment Request. . Checking if correct merchant requested the transaction and that it is the same merchant that originally made the transaction. 15 . Checking that the amount is the same as the original amount. . Checking Transaction Numbers and entry that reside in the

Database.

Once it is accepted that the transaction is valid then the transaction is passed to the Message Formatter 37, which will convert the message to

NBS specific format.

Message Formatter

The message formatter 37 consists of a completed function called

E

WriteMessage. This function has the following parameters: * MessageNum: The number of the NBS messages to be built up. o SDestination: The destination to which the message must go

NBS. . SXML: The XML data that is needed to be included in the message.

The function then returns a string with the formatted message, which is returned to the Transaction Controller 38.

Transaction Controller (Step 2)

The transaction controller 38 unblocks funds function must now call the

SendMessage function in the transport services control with the resulted formatted message. This function has the following parameters:

Transaction ID

Formatted Message

Destination This will be NBS or banking institution 20.

This function resides in the transport services controller or module 64. /

Transport Services

The transport services handles the rest by adding the transaction to the

TMA Temporary Memory Area and sending it to the NBS. The NBS handles the transaction on their side and once finalized they send a response back to the transport services. This is where the Transaction

Controller 38 yet again comes in to the picture.

Transaction Controller (Step 3)

The Transaction will now reside in memory in the Transport Services

TMA. The transaction Controller now polls the memory area with the

Transaction Services Poll function to see if a response was sent. As soon as a response is detected, it can be read from the memory and handled. The response must then be converted from a NBS specific string to a XML string. This can be done with the Read message function. This function consists of the following parameters: o NBSString This is the response from NBS. . SXMLResponse The XML translated string.

This string is now passed back to the Web interface, which then handles the transaction and response to the merchant.

Referring in particular to Figure 25 of the drawings, reference numeral 160 generally indicates a schematic flow chart of the client access, registration, and maintenance procedures of the TBM system 10.

Initially, a CAS “welcome and logon” message is displayed (see block 162) and, at decision block 164, it is ascertained whether or not the user is a new or an existing client of the system 10. If the user is not an : existing client, the user is requested to provide a user name and password (see block 166) whereafter the user name is verified to ensure that it is unique, as shown at block 168. If the user name is unique, personal details of the user are obtained as shown at block 170 and details specific to the banking institution 20 are then requested as shown at block 172 whereafter the data is reviewed as shown at block 174. If the reviewed details are in order, as shown at decision block 1786, the user is authenticated as shown at block 178. If, however, the details are not in order, the process reverts to block 170 to obtain corrected or further personal details.

If the user is an existing client, the process goes directly from block 164 to block 178 where the user is authenticated. Thereafter, as shown at decision block 180, if the user is not OK the user name is checked as shown at block 182. If, however, the user is OK the process proceeds to decision block 183 which determines whether or not the user is a first time user. If so, the process proceeds to block 184 where the user enters a particular registration code. If the user is not a first time user, the user then proceeds directly to the user's home page (see block 186) and, thereafter, to block 188 to a service maintenance facility 190. A check is then done to ascertain whether or not a new service is to be added as shown at block 192 and, if so, the appropriate login is effected as shown at block 194. If no new service is to be added the user then proceeds to decision block 196 to ascertain whether or not a service is to be removed. Thereafter, if no service is to be removed, the process proceeds to decision block 198 and, once completed, the administrative : module or eBroom performs the relevant housekeeping. © 25 The CAS “welcome and logon” (see block 162 in Figures 25 and 26) is in the form of a logon screen which provides the client with the option of logging on or registering with the system 10. Existing users of the system 10 are required to authenticate themselves before being allowed access to the TBM web site. At each login attempt, the user name and details are checked against the database and, if this is the first time the user logs in, he or she will have to enter the registration code which the

CAS server 14 has mailed to him.

When a client selects to enrol with the system 10, three options are provided, namely a new client option, an existing service provider client option, or an existing client of the banking institution 20 option as shown at decision blocks 202, 204, and 206 (see Figure 26). The client access, registration and maintenance procedures of Figure 25 are then carried out.

If a client signs on to the banking institution 20 via decision block 206, a separate secure process is then opened wherein the client's details are authenticated and received as shown at block 208. At this point the client interacts directly with the banking institution 20. The new client may then choose a password and further authentication takes place as shown at block 210. Thereafter, a registration code is e-mailed to the client as shown at block 212 followed by “congratulations” and several instructions as shown at block 214 (see Figures 26 and 27). Examples : of various logon screens are shown in Figures 27A to 27H. . In the event of an existing client signing on, it is determined whether or not the client or user has logged in before as described above (see decision block 216) and, if the client has logged in before, the user's home page is then displayed as shown at block 218. If not, the registration code is verified as shown at block 220 and terms and conditions associated with the system 10 as shown at block 222, are displayed to the client. If the terms and conditions are accepted as shown at block 224, services are added as shown at block 226.

However, if the terms and conditions are not accepted, the request is flagged and the data is deleted after a predetermined period as shown at block 228. The CAS server 14 sends the client three e-mail reminders if the client does not login during a given period and then deletes the client record and advises the banking institution 20 to do likewise. When the client logs onto the CAS server 14, enters a registration code, and accepts the terms and conditions, a first time marketing e-mail is then despatched to the client. The client is also mailed with a brochure and a card file is couriered to the customer. The courier envelope is then handed across to the client upon presentation of an identity document of which the courier takes a copy.

If the user is an existing client of the banking institution 20, the CAS server 14 passes the account number to the Internet banking server 16 which is used to ascertain the Internet banking status of the client. The user is then requested to verify himself with his password before the process can continue. The system 10 caters for situations where a selected user name already exists, when a user has forgotten his/her password and/or user name, or client registration details. Once the process has been completed, the system 10 generates a screen layout } : confirming the details provided by the client (see Figure 28).

Referring in particular to Figure 29 of the drawings, reference numeral 230 generally indicates the flow process during registration of a user at the banking institution 20. Initially, an Internet banking login screen is provided as shown at block 232 whereafter authentication takes place as shown at block 234. If the client is not authenticated by the banking institution 20, registration in the system 10 takes place a shown at block 236 but details from the banking institution 20 are not passed on to the client administration server 14. If the user is authenticated, a check is done to ascertain whether or not there is a CAS register link as shown at block 238 and, if not, the process reverts back to the bank as shown at block 240. If, however, there is a registration link then CAS registration is effected as shown at block 242 and relevant data from the banking institution 20 is passed on to the CAS server 14. Figure 30 shows a schematic block diagram of the client registration process at first time logon. Once registration of the system 10 has taken place, a registration code is sent to the user via e-mail which is then required to be entered for the system 10 to verify the user’s identity. Provision is made in the system 10 for registration error code messages e.g. if the client has entered an incorrect e-mail address. Further, client profile customization facilities are provided to allow the client to include bonus services (see

Figures 31 and 32).

As shown in Figure 33, the system 10 is arranged to provide a consolidated position 260 of the various facilities or services which a client or user of the system 10 uses. In particular, details of a bank balance 252 at the banking institution 20 are shown, details of share or . stock portfolios 254 are shown, details of insurance taken through the comparative insurance web site 28 are shown as generally indicated by arrow 256, transaction statuses of the stockbrokerage web site 26 are shown at 258, details of transactions conducted via the online shopping facility 22 are shown at 260, and vouchers which have been earned are shown at 262. Various messages may also be generated as shown at 264. The consolidated position 250 includes data sourced from the CAS database 88 as well as data which the system 10 may poll from other servers e.g. the banking system server 18.

Once the user has logged into the system 10, various options are available. Firstly, the customer may customize his/her profile. In particular, once the client has successfully logged on, he/she can change personal address details by selecting the “customize my profile” option (see block 268 in Figure 34). If the client has not effected any changes to his/her profile within six months of the last change, it is required that the client confirms the client information by way of an additional message such as “please confirm that the information held on our database is still correct by selecting the OK button”. If any of the bank held information 16 is changed a password is required. Figures 35, 36 and 41 show examples of screen layouts to accommodate this facility.

As mentioned above, a password is required in order to modify or update bank held records. Figure 37 shows a screen layout to delete a bank held address. In order to effect the changes, a further screen layout (see

Figure 38) is provided. The screen layout provided in Figure 38 is only communicated to the client once all address and contact details relating to the bank have been effected. If the Internet bank verification has . failed, a further screen layout is forwarded to the client as shown in

Figure 39. As shown in Figure 40, the client may elect to open another © 25 bank account in response to which a further card is sent to the client via courier. When any bank related functions are executed by the user or client, a separate browser window is opened which directs the user to the Internet banking server 186.

Referring to Figure 42 of the drawings, reference numeral 300 generally indicates the user name validation and tracking process of the system 10.

Once the user name and password is captured as shown at block 302, the system 10 ascertains whether or not the user exists {see block 304).

If the user does not exist, an error is displayed as shown at block 306 whereafter a wrong user counter is incremented for the session as shown at block 308. Only a selected number of retries are permissible (see decision block 310) whereafter the user is forced to close the session (see block 312). If, however, the user successfully enters his/her password within the predetermined number of tries, a search is conducted for a user and the search results are shown (see blocks 314 ~~ and 316).

If the user exists, a check is conducted to see if the password for the user is correct as shown at decision block 318 whereafter, if the password is correct, the user table is updated (see block 320) and the user home page is displayed (see block 322). If, however, the password is incorrect, the wrong password counter is incremented as shown at block 324 and, in a similar fashion to the wrong user counter, only a predetermined number of retries are possible as shown generally by arrow 326. User authentication is also provided at blocks 328, 330, and 332. . If authentication fails, the user can call a customer care center via a telephonic communication link where an operator can unblock the user's account as generally indicated by arrow 334. Upon login to the Internet banking server 16, the banking institution 20 sends a profile identification code to the CAS server 14 as shown at block 338 which then provides a user password change screen (see block 340) and a check facility (as shown at block 342) to change the password. If the change in the password is successful, the user is directed to the user home page as shown at block 344. Figure 43 shows the process of how the system 10 then deals with an incorrect user name and/or password.

Referring in particular to Figure 44 of the drawings, reference numeral 350 generally indicates the CAS administration process for bank maintenance by a system administrator. All processes in which information is added, changed or deleted in the CAS database 88 are confirmed with the user before any changes are effected. The CAS administration process of the system 10 allows a user to create a bank as shown at block 352, to delete a bank as shown at block 354, and to edit banking details as shown at block 356. If the user selects the option to create a new bank, confirmation of the instruction is sent to the user at block 358 whereafter product details are captured as shown at block 360. The product details are then confirmed (see block 362) whereafter a card is created as shown at block 364. Card details are subsequently confirmed as shown at block 366 and a request for further cards is then processed as shown at decision block 368. Contact details are confirmed and captured (see arrow 370) and branch details are confirmed as shown at arrow 372. .

When deleting a banking institution, confirmation is requested as shown at decision block 374, whereafter confirmation as to whether or not the user is indeed a subscriber is ascertained as shown at decision block 376.

Prior to removal of the bank details and all related bank records as shown at block 378, the user is required to confirm the deletion process (see block 380). When editing bank details, as shown at block 356, a user may select either to edit bank branch details (as shown by arrow 382) or edit bank products as shown by arrow 384. All processes where information is added, changed or deleted in the database will be confirmed with the user before the changes are effected.

Bank List

All banking institution or bank related operations are accessed by the

Administrator via the Banks tab on the Icanonline web site. Once clicked, the screen will refresh to show the list of active banks (see Figure 45).

The operations accessible from the above screen are:

J Creating a New Bank; o Editing, deleting a current Bank; . Editing a Bank's Products, Cards, Contacts and Branches.

Each Listing screen operates in the same fashion. If the desired operation is Delete or Edit, the user must first select one of the radio buttons listed to the right of the list. Once selected, the desired operation can be : performed. If only one list of items exists on the page, the Create operation can be selected without selecting an existing item; if more than one list of items exists on the page, the user must first select one of the radio buttons to the right of the list item heading.

Fields:

Rules: [ST Count of Branches Inked 6 Garrent Bank "= 7°]

Create a New Bank by an Administrator (see Figure 46)

The Address Details are for internal use only and are not displayed to users. The Bank Branches section is shown to users when they have to visit a branch to verify their details. : Fields:

Rules: 4 | Date to Activate the Bank, Must be a valid date, notin the past. | [F117 _=[ end ot the treation proses. = LL i ne LEST Sa tn

Ad Confirm the New Bank

After a new bank is created, the administrator must confirm the bank details (see Figure 47). The fields and rules required are set out below:

Fields:

Bankai [Wetshown [WA] ‘Bank.AddressT, Bank.Address2,- | Address ~ fC INIA Tae

Bank PostCode, Country Nate © 1 ems bho 0 08

Rules:

I AE

J Create Bank Product

An example of a create bank product screen is shown in Figure 48 and the required fields and rules are set out below:

Fields:

BankService.AccountRangeFrom,. | Allocate User. | [No — - |3, ES so em Range oo hen ck pee arte Ta ER pee By ie Bf

Rules: 3 | An account rangeiis entered if the bank prodiict would like the TBM system 10° 2 Nome is seleoted, thetwa doobunt number fields, and the Allocate té-existing "| ‘numbers and the checkbox are enabled... Loi. hha Teo 4 | The.TBM system 10 can allocate account numbers to all ClientProfile records. ~ oi: |'buittr, This buffer is stored in the system variables tabie. ©. > i. gure dey Se el Dn “7+ 1 if otie Product exists, continiie. with the Wizard creation ot the Baik 1 | ©

. Confirm the New Bank Product

After a new bank product has been created, a confirmation screen is displayed (see Figure 49). The following fields and rules are defined:

Fields: ‘BankSevice.Neme ~. .." [Name “i, oo URAC

Banas. Dastiption | Desorption | TWA 0]

Rules: [1 | Save changes. Connie with the Wizard of Graating a Bank, © 3" | Do not save, display Create Bank Product (see Figure 48)..0.~ © «5.

Create Bank Product Card

Once a new bank product has been successfully created, a bank product card is then produced (see Figure 50). If more than one Product was created, all the Product's card details can be captured in one process.

Fields: : BankServiceCard:Description | Description: ~~ “}:Yes . “I yf 47-7 7]

Rules: (Wo Thales 0 or] [1 ['A description for the Product Card. This must be upigue per Bank, ~~ + "2.7 Validate and save current details, display, Canfirm the New. Bank Product Card,

Cbd eB ae es pe Te eT

EE clei n BURR Ses RE ie ee RR a nines de ET a a Rd ns Bn Bel a RE

Cad RT en TR OT Te Te a a ee oi Vit the Bank, Senin we Es ani er Te I re o Confirm the New Bank Product Card

New bank product cards are confirmed upon finalization thereof (see

Figure 51). :

Fields: (Held Name... 7 |Caption sv... + | Required] Rules »-]

BAnkSPrcaCatd Desorption, | Description =. nF. Ln NIA a

Rules: 7 TT this option is Salacted, Create Bank Product Card (see Figure 50] wil ba. "| displayed for th crastion of another binkoard:; If. there Js mote than ong: =| products. If this option is not selgcted, continue with the wizard of creating &

RE RE I uo EE SI (ERE Teh EEE HEY ho] Banka EE od a Geb Ce 0 SR informations CT eee [4 Do not save, display Create Bank Product Card (see Figure 50). ~~~ ° Create a Bank Branch

A bank branch can be created via the screen display shown in Figure 53.

The BankBranch table will be pre-populated with NBS branch information before the go-live date of the system 10.

Fields:

Rules: :

) Use Country table to populate combo list, Will default to “RSA”. 16. | Display Confirm the New Bank Branch (see below). © Set 7} The first Branch, display message New Bank Branch Error Message. © © |/1f one Branch exists for. the hank, display Bank: List (see Figure 45).if in the 1 process of creating a bank, or Edit a Bank [see Figiire 54) when editing a bank: cin. lor Branch List (see Figure 45), depending on the ofiginiof the. creation request. : ° Confirm the New Bank Branch

This page displays a confirmation message for the creation of the New

Bank Branch. The page has the same information as the Create Branch page (see Figure 53), but the information is read only.

Fields:

Figld Name, :'*:=' 7 7] Caption. rik 5 | Required. | Rules. 7. ]

BankBranchiName «(Name 0-007 0 TNA TT TR ! -BankBranchiAddress®, = 10 “Te Tn SOE TREE To TRE

PR ne Re TR ER TE TR Re Te ge ‘BankBranch. Address? «Vl ky oe To anne Rn

SE GG el RE Se Sl i TL i RT

BankBrangh:Address3, hie Gr Hs nee Rn Sill aE a

EE Ta OR EY Th ST TL KN a

BankBranth Town), (05 ESE Le a eT hi | BankBraneh.PosiCode, | {shan 0 Fp ed Be Gl

Sahel ali se te fn OE i sl SE I ee el LB i “CountryiName 7 ber ie ee B08 aT BE ERE EE a

LNA Gs pie BT Oreste another Branch? 1 N/A © dee]

Rules: . [No JRules 10 Fors Ee TT ET TT

TF JFANIS Option s selectad; Create » Bark Branch [55 Figura 31 1s deplaed for + “2: fithe creation of snotherbank, : “Ltd he SEE

’ 2 Save changes. Display Bank List [see Figure 45) if in the process of creating

Cabanon

Edit a Bank (ses Figure 54) when editing a bank or Branch List (see Figure 60), depending on the origin of the creation request; “ti th. lv . Edit a Bank

A bank may be edited using the screen display of Figure 54.

Fields:

BR NT BE a

Bank Products

Fields:

Bank Branches

Fields:

Rules:

B.. [List Name, Description for. each record in BankProduct for Bankld; sort by.

Edit wi dlplay Edit Bank Prodiiet (see Figure 58). | "x iioul £1 | Delete will display. Confirm’ Remove Bank Piodact (see below). "Si 1 =o

‘Display Confirmation Message. See Confirm the Bank (Figure 47), =~ © 8. | Cancel changes Display Bank List (see Figure 45). = © =| i . Bank Product List

An example of a screen layout for a bank product list is shown in Figure 55. The fields and rules are as follows:

Fields: ‘Field Name + + “io woo Caption: 7 = | Required». 4 Rules’ © " ounCisn BankSoibatote] | Cloris” “1 "LTA Tolar]

Rules:

No.-| Bales tists Lei i el TE £ onl CH SRN SRE i RR ERA CEE ce CE It URED Te a Re i [RE a EL RS Ne a Sa Se I re 1 | Count of. Client Profiles linked to current Bank. | ols be duly sien 0s

UU Bank Breation: nL mate hE TE Ue a ie en ee)

Wl lading fe] ner ng Sa NR Fou nr ia BIR eR TT ea TT sr then display Cenfitm: Remove Bank Product for deletiig the bank selected: 7 a ert Tom fhe select column. The system a will then display the Edit Bank Product (see Figure 58] forthe product selected;

J Edit Bank Product

Bank products may be edited as shown in Figure 56.

Fields:

FieldName - ~:~ [Caption " . | Required

BankSeviceMame™ 1 i

BankServics Desaription 1 |Description [Yes 12 “BankService.AccountRarigeFrom, | Allocate User... [No = 18,40 rh ES etc IS STR ER EE EO “BankSeryice. AccountRangeTo! © | Accontst Nome of. i} Lo A dan wl ea LfNol Has

REE Be ER

Chm BE eh eee a Uc lelients ne cen EEE Tel ins pe ve

Cards

Fields: :

BankCard Desorption. ETL Desdiption or. INA 16 0 0]

CourtiCiient.BankCardCae).,. +. | Clients. =. | = JANA TE T®

Confirm the Bank Product Changes

See confirm the New Bank Product (see also Figure 49). : o Edit a Bank Card

The system 10 makes provision for the editing of a bank card (see Figure 57). The fields and rules are as follows:

Fields:

Field Name ~~~. ankCard BankGede [Tmo [i “BankCard.Description- ~~.

Rules: (No. [Reales oo oop ooo TUT nan ET a [2 | Descriptive Name of Card. © = wow one TAT ee 14 +} Cancel changes arid display: Edit Bank Product (sée Figure 58): pn 11 ! . Confirm the Bank Card Change

The screen layout to confirm a bank card change is shown in Figure 58.

The fields and rules are as follows:

Fields:

Field Name vd dn 'BapkServiceCard.Description «| Description. oo. WA =o hia]

Rules:

° Edit Bank Product Contact Person Details

The screen layout to edit bank product contact details is shown in Figure 59 and the fields and rules are set out below:

Fields:

Rules:

‘ [4 | At least one contact number must exist, Display Create’ Bank Product

J Confirm the Bank Product Contact Person Changes

This page displays a confirmation message for the addition of the Bank

Person Contact Details. The page has the same information as the Edit page, but the information is read only.

Fields:

Rules: © 2 pilbulated with captured information, FTL lan Cale

° Branch List

Screen layouts of branch lists are shown in Figure 60. The fields and rules are as follows:

Fields:

Rules: “17 Use Bank table fo populate all banks. Only Yisplay branches for the bank. o Edit a Bank Branch

The screen layout for editing a bank branch is shown in Figure 61. The fields and rules are as follows:

Fields:

Rules: 25 . Confirm: Remove Bank

The screen layout to confirm removal of a bank is shown in Figure 62 and ’ the fields and rules are set out below:

Fields:

Bank:Address1, Bank Address2, | Address. «po NACE le

Rules:

Lote clientbrofileAceount, ho TT a

Does J BankServiceContactPerson. tli he He SEER

. [Te BankServiceContactPersonDetail. © =...

Show Bank List (see Figure 48). ~~ ~~ - 1,

Remove Bank Error Message : Records Exist in Related Tables. If records exist in related tables, display an error message: “There are related records in ClientProfile, the Bank cannot be deleted”. o Confirm: Remove Bank Product

The same information is displayed as for the edit pages.

Fields: “Field Name «0 0 vn oo [Caption uJ Required “] Riles ©. 1]

BankService.Description | Description ib [NARS] en

Count(ClientProtils, BankCode} 1 Subscribed Users [N/A il ot] :

Rules:

Ei be the nufnber. | of [ClientProfiléAcsount ‘where BankCode - | and’ al Bank ServicelD is the ohe selected for delgtion.s ivi an MTR eh 2: | For the deletion of. a bank product, there must be, no related records in the following. tables liriking to this. bank” product’ (Display. error message (ses: [Fn os : - So og : ” i) y - rn a on : B RE : aba STE 5 ne ERE SE et ! : EST Sa i Tables) ead Ba Se EE Re ma a Re Ce 0

Sn | ClientPRORISAGOOURL, + wi hh i eT / RN RT a RA RT TE ER IR

On deletion:of the bank product, the records in the following tables are also:

Ce fe ein EL TR TT RI pe Re nn eT

Lc oddelSteds tc ss Tn nT Sp Te a gee eT

[BankCar ERE

BankServiceContactPerson; Co ERATE RE PTE I SE J ‘ | BankServiceContactPersonDetail, 1... oth ino ee oo “| If this is the-only Bank Product for. the Bank, display etror message (see, + | below): Remove Bank Product Error Message: At least ono Bank Product rust “i depending ‘on the-origin for the request, | «= EEL na ne

Remove Bank Product Error Message: Records Exist in Related

Tables. If records exist in related tables, display an error message: “There are related records in ClientProfileAccount, the BankProduct 40 cannot be deleted”.

Remove Bank Product Error Message: At least one Bank Product must exist. If this is the only Bank Product for the Bank, display an error message: “At least one Bank Product must exist for a Bank, the BankProduct 45 cannot be deleted”. o Confirm: Remove Bank Product Contact Person

The same information is displayed as for the edit pages.

Fields: “Flold Name ©. +. r= J Caption © - | Required: J Rules] 50 BankServiceContactPerson.Nanie =~ +... | Contact Person |. N/A = [1.0]

BarkSeribeContactParsonDetal ContaciTyps "BankServiceContactPersonDetail. Description | Deseription | NIA =: “11 1. ]

. _BankServiceContactPersonDetail. Details ~~ :

Rules: 1 |'List all the-existing contact details for the persoh as is in the ‘database . ¢ os Pare ae EE a ee La en TU a

Iv | Reimiove Contact Pekson.Error Message: At least ane Contact Person mist exist

BN Re TT NE SCRE Sa I Se a ath Hlsee DE low ¢ i I a I a rat z Ene RE Beis Wir Bo Ra 4:5 |: Show Edit Bank: Produet (see Figure 56). «Limb. ou meen TUE

Remove Contact Person Error Message: At least one Contact

Person must exist. If this is the only Contact Person for the Bank

Product, display an error message:

At least one Contact Person must exist for a Bank Product, the

Contact Person cannot be deleted”. 15 . Confirm: Remove Bank Contact Person Detail

This page displays a confirmation message for the deletion of the Bank

Contact. The page has the same information as the Create Contact page, but the information is read only.

Fields:

Field Name _ ~ Tcaption ~~ | Required | Rules

BankServiceContact.ContactTypeCode | Contact Type = [N/A ~~ ‘ BankSeryiceContact.PrimaryContactTypel | Default in i |BankServiceContact.Description ~~ | Description © [N/A

Rules: (No. [ Rules oT TT TR Te TERRE eT] ‘Delete the Bark Contact. . BE a a

FE RRR a TT TR TT TR Ee ed Te of Return to Edit Bark Product (see Figure 561000 70 0 arnt et es

El 0 fot delete thesfecordii eo 0 To Fn a a DED «v. bRetuin to Edit Bank Product (sed Figure 58)c 70 Lp Lelie en i . Confirm: Remove Bank Card

This page displays a confirmation message for the deletion of the Bank

Card. The page has the same information as the Create Card page, but : the information is read only. : Fields:

BankCard. Description’ + “] Pesceiption 1. [N/A ET

Rules:

No. | Rules ~~ ~~ — oo 0]

A A Bank card cannot be deleted if a Client has selected to use this bank card. . | | The only time this record can be deleted is when there are no related records ¥ [in ClientProfile. T o permanently remove a bankcard, these -ClientProfile "| Return to Edit Bank Product (see Fidure B68). 15 ollie ot

Cy Ee

CU Returfi to Edit Bank Product (see Figure $6), To oT meade OF RT ° Confirm: Remove Bank Branch

This page displays a confirmation message for the deletion of the New

Bank Branch. The page has the same information as the Create Branch page, but the information is read only.

Fields: =

TBepkBranchiName Loa [Name [NAC TREE rn EAT EE aE A Tp ee a ‘BankBranchiAddress2, | Tc Ae Bn Bie dle BankBraneh Address, hw EE ig ll

LEE RE SR ER RA ECE

| BankBranch. Town, ~o 1. ET Pe ne ee

BarikBranch.PostCode, 0 sa] En TT Te

Country Name Fiabe ie ai eT La Th Ea Te ] [WA oe ow | Cancel: INA ET2 T

Rules:

: 1 | Delete the Bank Branch. EE . Depending on the origin of the process, return to either Edit a Bank (see Figure

Ba) or Branch List see Figure 60). ao it this is the only Branch fof the Bank, display error massage: Reirovs Bank === - ae - a 27] Dp not delefe the record.” 11 7 Tl sR 7 | bal.of Branehlist (see Figure 60. Li Eee oe

Remove Bank Branch Error Message: At least one Branch must exist. If this is the only Branch for the Bank, display an error message: “At least one Branch must exist for a Bank, the Branch cannot be deleted”.

Reference numeral 400 generally indicates the CAS administration process for product maintenance (see Figure 63). A service list is provided (see block 402) which provides the option of creating a product category (see block 404) or deleting a product item as shown at block 406. When a product category is created, the new category is confirmed and provider or merchant details are captured and confirmed as generally indicated by reference numeral 408. Thereafter, the product is created and confirmed (see arrow 410) followed by the capturing and confirmation of product details as shown at 412. As shown at block 414, bank transfer details are created and thereafter confirmed and captured as generally indicated ] by arrow 416. The voucher engine and correspondence engine 418, 420 respectively are then activated and the goods and/or services are thereafter listed as shown at 422.

In order to delete a product item as shown at block 406, confirmation of subscription is first ascertained whereafter all related items and records are deleted as generally indicated by arrow 424. Categories of items (see block 426) can be created, edited or deleted (see blocks 428, 430 and 432). Likewise, a provider (see block 434) may either be created, edited or deleted (as shown by arrow 436). Account transfers (block 438), outlets 440, and contacts 442 may be created, edited and deleted as generally indicated by arrows 444, 446, and 448. ° Product Category List

An example of a screen display for this feature is shown in Figure 64. The fields and rules are set out below.

Fields:

Rules:

. 4 User must select an available Product category from the select column. The system will then display Product Voucher Types {see Figure 80) for deleting _ |: the Product category selected: = CT . Create a New Product Category

See Figure 65 for an example of a screen display.

Fields:

FieldName: =. . J Caption | Required” [Rules

SatviceCategary.DisplayNamé =~ «| Display Name

Rules: [1 |The name to display to'the Client [In the menu of.the:www.icanonline.co.za). [7 TA short description for the Product Category. © © on i il [3 I Display. confiration messager. |. rrr nT [© [et una gu Fin Con ly ean Category List

Cola nT Ee nt Ce Te BT es ae Te

Tak teees Figure BA). pr a te en She nS AE ST Ye

Confirm the New Product Category

This page displays a confirmation message for the creation of the New

Product Category. The page has the same information as the Create ) Product Category page, but the information is read only.

Fields:

Field Name [ Caption | Required | Rules

ServiceCategory.DisplayName | Display Name [N/A [ ~~ _ServigeCategory.Description. 2 EE TE 1] SRE 7 CE

Rules: + | Retiitn 10 Product Cateriory List (ese Figire 841; = oh ik in [2 "Show Edita Category (see Figure 78A), 1 = eo “| Returii to Product Category List, © ir ee SE ER Ee Lg ee . Product Provider List (see Figure 66)

Fields:

Field Name "7 e000 8a eo] Caption ot [| Required + | Rules" 77174" ]

CountiSsrvibe, SarvibePravdend) | Froalots © [WIA TTT TE]

Rules: ‘Count of Active Products linked to the Product Provider.® 2

[2] Display Create a New Product Provider. Co : 3 | User must select an available Product provider from the select. for the Product provider selected, co #4 | User.must select an available Product provider from the select.

Provider for deleting the Product provider selected, |. . Create a New Product Provider (see Figure 67) -

Fields:

Rules: 1° | To manage the creation of TBM vouchers, a TBM Product Provider and TBM "52 Let a TNE vouchers canoe eres; for ass Prone, Doth to Peles

[3] Genel the Creation 6 a Product Provider, fetarn to Froauot Provider List ses. . Confirm the New Product Provider

This page displays a confirmation message for the creation of the New

Product Provider. The page has the same information as the Create

Product Provider page, but the information is read only.

Fields:

FieldName. *<, ._ [Caption | Required | Rules

ServiceProvider Name I Name © [NA [7

Rules: ol | Productitsee Figure 74) cn EE Sel ne end ed ‘Show Edit Product Provider: (see Figure 78Al «iv wc v dE ila 7 ath La en es mn TT OR Beh DT Le

Return to Product Provider List see Figare 6). «17 ci tie 15 . Product List

All Product related operations are accessed via the Products tab (see

Figure 68). Once clicked, the screen refreshes to show the list of active

Products. Each Listing screen operates in the same fashion. If the desired operation is a Delete or Edit, the user must first select one of the radio buttons listed to the right of the list. Once selected, the desired operation can be performed. The Create operation can be selected without selecting an existing item.

Fields:

:

Rules:

J Create New Product (see Figure 69)

Fields:

Service.Addresst; ©. © © Address, INA GT ‘Sorvice.Address2, I 7 Lo I 0 Se a . 1. ps Bg Lin Fl

Service Address3, oo bef

Country Name. name ER Le Be pd

Rules: 4 | The E-mail address is: used for the: Transaction Co-ordinator-to. rallback a {who will Know how ‘to gerfofim the operation: ~~. |. i 0h

The MerchantiD js used. by. the Transaction Coordinator. It Will default 10 “IC” +"

A free‘product does not nead bank transfer-details. Vouchers canriot'be created

7 If this is set to Immediately, the record will be marked ACT (Active) immediately on completion of ‘the ‘wizard, or clicking ‘on OK. E Le © | Ifthe user-enters a date, the date must be a valid date in'the future. ‘A task will’ be created fof eBroom to activate the Product on this ate, =. n 8 | Save and validate changes, Continue to create at least one Product Contact. ‘9 | Atleast one Product must.exist for a Provider: If this was created from the wizard, + _-| display an error message inforining the user. If the user confirms the cancellation, rollback all records created during the wizard process, else continue to create at’ "|teastions Product Contact. «no Tene Si 1 7} 106 Product List (see Figure 88). svi © RT TRE mn . Confirm New Product (see Figure 70)

Fields:

See Create New Product Fields (see Figure 69). All fields are be marked read-only.

Rules: ‘Save changes, move 10 next Wizard item depending on selsction-iri Create New

Product {see Figure 69). oo Lo Tse Se SE eT

F 2 [show Edit a Producti{see Figure 74). hn mT eT TE 3 | Axlasst on Product RUSE exit for a Provider: If his was created from the wizard,

LC display an error message informing the user: If the user confirms'the cancellation; + rollback all records created during the wizard process, else: continue to create at

© | tfthis is not the first Product for a Provider, cancel the creation process and return : [eran {see Figure 68). oc. open ° Create Product Contact

The page shown in Figure 71 is used to create a new contact record for the selected Product.

Fields:

Rules: + | serviceGontactPersonDetailContactTypeCods = “WeH” vi © 4 “4 | ServiceContactPersonDetail. Primary ContractTypelnd = True -- ~~* 77 T7 5... | ServicaContactPersonDiotai. PrimaryCortractTypelnd = Trug [1

I serticeContactPersonDetail Contact TypeGode = WFX¥.. “i ili ol

ServiceContactPersonDetail. Description = “E-mail Address” - ER OR ~ mtn Se peCode = “EML" © =~ Gi ] 7 | Save with the area code at the end of the number ‘with a “||" separating the

SJ At Jsast one Contact must, exist for a Product: Tf THis was created from the. : a . . “cancellation , rollba ckall records created during the Wizard ‘process, elie sortinue 5S

J Confirm the Product Contact

This page displays a confirmation message for the creation/edition of the

Product Contact. The page has the same information as the Create/Edit

Contact page, but the information is read only.

Fields:

Rules: dp SA a en Pea ee BE Te i | AtToast one Cortact pst ex|ot 107 a PodUCE If ths was created from the wizard. fo roditiet List iste Fhe 0B). | hte Se RE ° Create/Edit Product Bank (Bank Transfer Information) {

An example of a screen display of this feature is shown in Figure 72.

Fields:

Rules: "1. | At least the *Bank Holding” and “Merchant Settlement accounts must be. "| completed. Ses Rule 4 for BankTypeCods, = noid ° Confirm the Bank Transfer Information

This page display a confirmation message for the creation/editing of the Bank

Transfer Information. The page has the same information as the Create/Edit page, but the information is read only.

Fields:

FieldName ~~. ° [Caption ° |Requited - [Rules

Rules: [2 | Show Create/Edit Product Bank {Bank Transfer. Information) {see Figure 72). ] o Edit a Category 16 The same rules apply as in Create a New Product Category (see Figure 73A). ° Confirm Edit Product Category

The same rules apply as in Confirm the New Product Category. ° Edit Product Provider

The same rules apply as in Create a New Product Provider (see Figure 73B). . Confirm Edit Product Provider

The same rules apply as in Confirm the New Product Provider. ° Edit a Product (see Figure 74)

Fields:

See Create New Product (see Figure 69) for Fields and Rules for Product

Details and Address. [Fields ++ 0 wo “or Dr I Gaptioncin 0 co, of. [Req | Rule

Tr 7S [N/A + "OT Accounts oT oo UL NJAC [BT

INA ier Te [Contacts rn INIA T6.

Rules:

1 | Ar account range is entered if the product would:like the TBM system 10 to allocate account © | numbers automatically. Tha. CAS will then sent the client information to the product, as per : the Service Interaction Specification. LL eo ne

None is selected, the: 2 account.number fields, and the Allocate ta existing checkbox i: cane ser slat ro ton, sible th account nombre athe chee. "277 | The TBM system 10 oan allocate account numbers to all ClientProffle-réogrcs. This function 10 . Confirm Product Edit

The same rules apply as for Confirm New Product (see Figure 70). . Bank Account List j

An example of a screen layout of this feature is shown in Figure 75.

Fields:

ServiceBank.BranchCode’ Branch Code [Na ~~ Tcreate [Na _ 12

Rules: 1 |-Display details for all. records in ServiceBank where ServicelD. = Current Service. . “2.2 /|. Display Create/Edit. Product Bank (Bank Trangter Information) {see Figure:72). +"

J Contact List (see Figure 76)

Fields:

FieldName © oo. {Caption [Required | Rules =

ServiceContact Namal Ln EEC Ce

ServiceContactDetail.Detail

Rules:

ST Bevige re a TET Te I es Ee 2° | Display Create Product Contact {ee Figure 74). oo 0" 07m Td

Display Create/Edit Confact (see Figure 77) “oi ps imi mn - ° Create/Edit Contact (see Figure 77)

Fields:

Field Name — Tcaption | Required | Rules

ServiceContactPerson.Name [ Contact Person | No. | 1

ServiceGontactPersonDetail:ContactType | ~*~

ServiceContactPersonDetail Description | Description | Yes ‘ServiceContactPersonDetail. Details. =~

Rules:

ET EE RE ER RR

[1° | Use for Descriptive Page fitle. oor. too oooh mp nn 2 [Populate drop down from Gontactlype table, oo ero Cow Too en 3 | Read the area code at the end of the number with, numbers separated bya “||”. "5438762 [10217 Use the “||” delimiter to pick up the area code in future. ; 7 the type of contact seleCted. io UL SATE an ca [4 | Display confirmation Screen... «cof oom eal [5 | Cancel changes and return to Contact List (se6 Figure 76). -iv ows = oo 16 . Confirm: Remove Product Contact

This page displays a confirmation message for the deletion of the Product

Contact. The page has the same information as the Create Product Contact page, but the information is read only.

Fields:

Field Name = ~~ =. i.)

Rules:

ll] Delete the Product Contact. EE SE So : © | Return to Create New Product (see Figure 69) or Edit a Product (see Figure 74).

Do not delete the record." © © 0

Return to Create New Product (see Figure 89) or Edit a Product (see Figure 74}. od List Outlets (see Figure 78)

Fields:

TY TAT RN 1 SEG LT Me DRE ET

ServiceOutiet (Addresst + [Address [Na = 7

PostCode). an Ue me 0 TE Bee ob nba la

Rules:

C17 | Display.details Tor all records in ServiceOutlst where ServicelD = Current Service.” [7 | Display Create/Edit Dutlet. (see Figure 79). © +7 5 oh hahdei in Ths bo a | Display Create/Edit Outlet (see Figure: 79). xo oo 07 wie tof 0 [4 J: Display Confirm: Remove Product Outlet.» Tr 0" on PRT fs oe

J Create/Edit Outlet (see Figure 79)

Fields:

Field Name... ‘| Caption. .| Required :" * [Rules ©]

ServiceOuler Name [Name © [Ves © [Al 1]

:

Rules: ° Confirm: Remove Product Outlet

This page displays a confirmation message for the deletion of the Product

Outlet. The page has the same information as the Create Product Outlet page, but the information is read only. The Product Outlet cannot be deleted if there are any related records in Product. All these Product records need ‘ to be amended before the Product Outlet can be deleted.

Fields:

: Field Name i [Caption [Required | Rules

WA Joc Twa [i] [WA 7 Teemcel [WA [3

Rules:

FE Product Qutlet. = © nat

Return to Edit a Productsee Figiite 24); = + nF na

CNEL NRE TE ER RE Ee

CoE Return to Edit -Producgt {see Figure 74). oa 7 Fn BRR GE BRL Li nt . Product Voucher Types (see Figure 80)

When a new Product is created, a record is inserted into casServiceVoucherList for all the available voucher types: When the user access this page for the first time, all the voucher types are selected.

Fields: _ctiVouchdrType. Description. (Nia oo TT Beleten x oo Nfac vo LA

Rules: [1 | Available Vousher types in ctlVoucherType is displayed. . «= = in 7]

LE be checked wher a record exigts i gasServiceaucherList for 5 | this Product and Veusher Type, ori iit cn SB de ee ne Es

Display Confirm: Product Voucher Types. CL : Se ne

Ld Confirm: Product Voucher Types

This page displays a confirmation message for the Product Voucher Types.

The page has the same information as the Select Product Voucher Types page, but the information is read only.

Fields: :

FieldName: ~~ ~~ 4% = 0

Rules: 2°: | Return to Product Voucher Types.(see Figure 80). © © © 57 oon 7 Ti . Confirm: Remove Product Category

This page displays a confirmation message for the deletion of the Product

Category. The page has the same information as the Create Product Category page, but the information is read only. The Product Category cannot be deleted if there are any related records in Product. All these Product records need to be amended before the Product Category can be deleted.

Fields:

Field Name ~~ [Caption [Required [Rules

Rules: (No. [Rules ~~ ~~ =~ — ~~ = ~ 0 Tvomo or]

Return to Produst Category List (see Figure 64). © i. li ©") etufin’to Product Category List (see Bigure.ed) to PT od . Confirm: Remove Product Provider

This page displays a confirmation message for the deletion of the Product

Provider. The page has the same information as the Create Product Provider page, but the information is read only. The Product Provider cannot be deleted if there are any related records in Product. All these Product records need to be amended before the Product Provider can be deleted.

Fields:

Rules:

Delete the Product Provider.. f=" | = + 0 Loy pm

Return to Produit Provider Uist (see Figure 86¥, 5 1 in 0 2 hon delete the fecord, . oy oT Ra 0

Return to, Product Provider List (see Figure 66]: ot ee

4 Confirm: Remove Product

This page displays a confirmation message for the deletion of the Product.

The Product cannot be deleted if there are any related records in

ClientProfileService, ProductBankAccount and Voucher. All these records need to be amended before the Product can be deleted.

Fields:

See Confirm New Product for Field List (see Figure 70).

Rules:

Reference numeral 450 generally indicates the CAS administration process for client maintenance. Clients may be deleted as shown at block 452 and associated blocks 454, clients may be reinstated as shown at block 456 and associated blocks 458, and profiles may be locked or unlocked as generally indicated by blocks 460 and 462 respectively. . o Client Search © 20 Due to the large number of records that will exist in the client database, clicking on the Clients tab will not show a list in the embodiment depicted in the drawings. Instead, the administrator is shown a selection screen, which allows the administrator to shorten the list by entering some details for the client he or she seeks (see Figure 82A).

Fields:

Rules: 1 | The Administrator must enter something into at least of one the search fields. "+ | appends wiidoard characters 10 the fields so that partial matches will be found.

Ra Sort redords b , Client Surname Client. FirstName. Sele SET : to populate this dropdown. bec TEL 3 | Execute the builtquery. . FE 40h The Te en © frecordsmatoh fil eh a

If the Search criteria supplied finds more than 200 records, display Client Search

Confirm (see Figure 828), otherwise display Client List (see Figure 82C). “+ o Client Search Confirm

If the Search criteria supplied finds more than 200 records, the user may select to edit the criteria, or to display the current results (see Figure 82B).

Fields:

Rules: 2 | Execute the built query. . If no records are found, add ‘a note to the- screen. ° Client List (see Figure 82C)

Fields: i

Rules: 2 1 | Retrieve all ClientProfiles for the ClientlD, if any are locked then show the Status gwe82D). . Client Profile

The client profile screen allows the administrator to view all the TBM services the client has selected to use, as well as their personal details. All of this information is read-only, the only change the administrator is allowed to make is to lock, unlock, delete and re-instate users (see Figure 82D).

Fields: -Client. Title + ClientFirstName + *_. | Name. = *.-. [NJA f+ io

Count(ClientProfileAccount.UsetNdéme) |-Products ~~ ~*~ NA. [2

Contact Details:

Address Details:

ClientAddress.(Address1 +. |Detall "= ~~ [N/A =. = |B. = + PostCode + Counteyd + oi | ooo et ce RS oe

Rules: 6 | If StatusCde is LCK:{Locked), Show Activate'button. Display Client Status — © | Unlock (see Figure 826). © oo 0 : : | (see Figure 82F). SE or Bh p A ae I StatusCde is PND (Pending), User is undergoing registration and Administrator :

Oh

: only, | I

If StatusCde is PND, do not display either button.

If StatusCde is ACT, display the Delete button, If Clicked, displayClient - Remove (see Figure 826). : Lo eT oo . Lo

If StatusCde is DEL, display the Reinstate Button. If Clicked, display a System the user. Display Notify Products (see Figure 82H), ~~~ © © o Client Status — Unlock (see Figure 82E)

Fields:

I Rc Eki EO TAS RAT WY

Rules: informative title:and message. 0. ©: Co. Wt Eg 2 If this is set to immediately, set the StatusCde to Active immediately on Yes. : Clear the ClientProfile. StatusChangeReason to null. i. Coe date. The StatusCde will not. change until’eBroom reaches that date. Ll »

. Return to Client Profile (see Figure 82D). [5 1 Add an eBroom task to Sent a ClientUnlocked E-mail message to user. ° Client Status — Lock (see Figure 82F)

Fields:

Field Name = [Caption - .. [Required [Rules

ClientProfile.StatusChangeReason | State Reason, ~ : [Yes = | © |] [NA [Create Emal INA.

Rules:

Use ‘ClientProfile.StattisCde and ClientProfile:StatusChangeReason to create; an __|informative title and message, lo Sa

Update the ClientProfile.StatusCde:& ClientProfile. StatusChangeReason fields.

Show-Correspondence Manager to explaity reason for tock: ~~ ~~ ~~ .. [3 | Return to Client Profile’{see Figure 82D)... ¢ © oo hn ngids 0

Figures 83 to 86 show typical screen layouts available to merchants forming part of the system 10 thereby to enable the merchants to view a summary of associated transactions online. Typically, the system 10 runs a weekly batch at the end of each week to update statement tables so that transactions are shown on a weekly basis. Month end summaries are also provided. The system 10 also allows a merchant to change selected details (see Figure 84) by e-mailing or phoning the system administrator.

Navigation of the web site of the system 10 to each associated web site,

; namely the Internet banking server 16, the online shopping facility 22, and the web site 24 is handled with an Off Site Viewer (OSV) which is a frame containing the entire site and linked back to the system site. The system 10 provides facilities for new service providers, service account creations, client detail amendments, or the like. ° PROCESSES

Examples of various processes of the Client Administration System are set out below.

TBM navigation

Navigation out of the TBM site, for example to Moneymax, is handled within an Off Site Viewer OSV. This is a frame containing the entire Moneymax site and a link back to the TBM site.

TBM initiated procedures

Procedures initiated by TBM for Client Account Administration expose a standard interface allowing other Services to easily plug into the process.

TBM is only responsible for initiating these remote procedures and action their response.

J New Service Provider : If a service provider is added that requires client data that TBM does not hold:

} - TBM client data will be amended to include these fields. . The user will receive an Airmail message when he logs on with a link to a popup window that will capture all the additional information required. - New users to TBM will have had to enter these details at their point of registration. ° Service Accounts Creation

When the TBM account has been authenticated, known service provider accounts will be created.

The users will be prompted to indicate whether they are existing users at the service provider and provide their login and password for each service provider.

Existing User at service provider:

Login and password will be validated, and the TBM database will store the service provider login for the Client.

New user at service provider:

A new account is created at the service provider. The username defaults to the TBM username. Conflicts are resolved by appending an incremented number to the username. If the username reaches it's maximum length, the last character will be truncated before appending the number.

The service provider may indicate that they wish the TBM system to determine the user account number. In which case, the account number allocation method will have to be specified. For example, users may be allocated account numbers from 1 to 10 000, consecutively.

The TBM system exposes user fields and the functionality that creates the account at the service provider formulates the account number and passes it to and from the TBM system and the Service provider.

The procedures at the service provider which create accounts will return a unique identifier for the specific client. TBM will use this identifier to resolve the client at the Service Provider.

The procedure at the service provider that creates accounts will be responsible for defaulting values for fields:

Password, PasswordHint

This procedure also translates the following fields to their lookup values(if available):

Language

Country

Province

AddressSuburb E

Title :

Procedures that do not execute successfully generate an email to recipients (specified in the system parameters) which highlights the process that failed and generate the relevant error message. The : system parameters page (see Ebroom spec) contains a field for email addresses for the Service Provider Interaction Administrators.

o Client Detail amendments

These include changes to user information. TBM first requests authorisation from NBS for amendment. This is an immediate process that calls the NBS Internet Banking popup window. If authorised, these details will be submitted to the Service Providers via the interface.

These amendments will only be passed "down" to the Service

Providers. TBM will not accept changes from the Service Providers.

The procedures at the Service Providers have their specific rules, determining whether newer details should be overwritten. o Functionality that Services provide

TBM Login - the login page allows TBM user logins.

Account Creation Process - A process that adds a new user, and authenticates existing user accounts. These processes are initiated by

TBM after new users are authenticated.

Calls to TBM to retrieve client's Banking Details.

Calls to TBM to query client's availability of funds, and perform payment transactions.

MMX skips first time registration code validation.

MMX automatically deselects all daily e-mails."

Netcover provides interface to.quote functions. ° Service Provider Login

Login screen to either TBM or Moneymax.

Users of Moneymax who are not TBM members may only log in to

Moneymax.

When TBM users log on to TBM, their service provider login is passed to the Service Provider if the TBM account validates successfully.

Username [Text | Username: | TBM username rules, see TEM io a 1. This process calls the TBM logon process which will either : - validate the user successfully and return his username for the

Service Provider to login the user. - Return a login error. : 2. Authenticate user. The Service Provider logon functionality. . MaxBroker Trading

Broker Selection

Flow: this page is reached from selecting MaxBroker from the TBM,

Portfolio screen.

Changes to the broker selection page (see Figure 87) include the

; facility for choosing a TBM(not CAS) account to be used when purchasing shares. This setting over-rides the Bank details that the

Broker account is related to. Again, if the Use TBM option is selected and the user is not logged onto TBM, a new login window will be opened. Upon successfully logging in, the Broker page will be refreshed and house the users TBM Bank details. * MaxBroker Trade Confirmation

The MaxBroker Trade Confirmation page (see Figure 108) indicates if the user is paying by means of his TBM account, and the amount to be reserved. This transaction amount is calculated by a formula incorporating all charges and facilitating purchases at Market value.

The TBM user may use the "Use Voucher" process button to take him "through the voucher payment system. Once he has completed satisfying the funds required by the transaction, the trade order processing continues. This processing includes the broker interface.

If the amount cannot be satisfied, the screen below will load, and display an appropriate message indicating the available funds and the required funds. The user then has the option to Edit his order.

If the User chooses Process Order, the payment engine checks for available funds in the TBM account. If sufficient funds are available, processing of the trade continues. If such funds are not available, the payment engine will notify the user of insufficient funds and the funds : that are available. The user will then be returned to the screen below.

The user has the option to Edit his order.

Ld Portfolio Browse (see Figure 90)

The Maxtrader/MaxBroker summarised portfolio information is displayed in a portfolio page. Together will other users information.

MaxBroker accounts and estimated outstanding values are displayed per broker, across his accounts for the broker.

Maxtrader Play portfolios will not be reflected in the consolidated position.

MAXBROKER accounts that have no investments will not be reflected.

The Maxbroker accounts will also state the date/time of when the data was received.

Netcover section: there is a link to the Netcover Comparative quote page if the client has Netcover insurance. If not, quotes for the client for specific cover (fixed amounts} are displayed (see Figure 91).

For example, Figure 87 shows a screen layout of the stockbrokerage web site 26. Figure 88 indicates a further screen layout of the stockbrokerage web site 26. If the user selects to make payment by means of their TBM account, the amount is then reserved. The user may select a use voucher button to allow payment using a voucher. Once the user has completed satisfying the funds required by the transaction, the trade order will then be processed.

Figures 89 to 96 provide further screen layouts of the stockbrokerage web site 26. Figures 97 to 99 provide sample screen layouts of the system 10 . when accessing the comparative insurance web site 28.

The system. 10 includes a housekeeping module or eBroom for scheduling various tasks relating to the vouchers, correspondence manager, service

) interaction, client administration, and reporting to clients. The eBroom module is responsible for the day to day housekeeping of the CAS database 88. The eBroom module is run on an SQL server and is run physically close to the back end database. Tasks performed by the e-broom module include mailing registration codes, forgotten passwords, password hints, or the like.

Further, the eBroom maintains the CAS database 88 to ensure system integrity and acts as a mediator for modules when changes in one module would affect another module. The eBroom performs no business processes itself and is priority driven. - Accordingly, all processes in the eBroom module are allocated a priority at a system level which determines which tasks are performed first and which tasks are run during off-peak times (see process overview in Figure 100). An example of a screen layout for the eBroom module is shown in Figure 101.

As mentioned above, the system 10 also includes a report manager for generating various reports related to operation of the system 10. A default page (see Figure 102) shows a list of existing reports and typically, an administrator selects to run, edit, or delete an existing report or alternatively create new reports. The report list is grouped into active reports 610, inactive reports 612 and incomplete reports 614 (Examples of screen layouts of the report manager are shown in Figures 102 to 104).

The inventors believe that the invention, as illustrated, provides a new data processing system 10 with enhanced functionality.

Claims (10)

) : "wore PCT/IB01/02076 CLAIMS

1. A method of managing transactions in a data processing system including a plurality of remote merchant servers of at least one merchant, which are operable to offer at least one of predetermined goods and services online to users of remote devices; at least one remote banking institution server of at least one banking institution at which the users have bank accounts, the banking institution server being operable to facilitate payment for goods and services which are purchased online from the merchant by users of the remote devices; and a central computing facility including at least one central server which is operable to communicate online with the remote devices and with the merchant servers and the banking institution server, the method including the steps of: a) inresponse tothe central server receiving an online request from a userofa particular remote device to effect a particular transaction with said merchant, the central server sending an online instruction to the banking institution to verify whether the user has sufficient funds available for the transaction; b) in response to the central server receiving an online message from the banking institution verifying the availability of funds for the transaction, the central server sending a real-time online instruction to the banking institution server to reserve funds for the transaction; AMENDED SHRET oo.

WO 02/37729 PCT/IB01/02076 c) in response to the central server receiving an online message from the banking institution confirming the reservation of funds for the transaction, the central server sending an online message to the merchant that it may proceed with the transaction ; and d) in response to the central server receiving an online message from the merchant that it has processed the transaction, the central server sending an online instruction to the banking institution server to release the reserved funds and to pay said funds to a designated payee in order to complete the transaction.

2 The method of claim 1, which includes registering said users of remote devices by recording predetermined particulars of said users sufficient to identify each registered user, in a database.

3 The method of claim 1, which includes monitoring data processing carried out between each remote device and the banking institute server; retrieving banking data relating to a particular user, from the banking institution and merchant transaction data from the merchant with whom the user transacts, and communicating the banking data and the merchant transaction data to a remote device that is accessible to the user, thereby to provide the user with a consolidated data position.

AMENDED SHEET

Co. WO 02/37729 PCT/IB01/02076

4. A central computing facility for managing transactions in a data processing system, the central computing facility including at least one central server whichis operable to communicate online with a) a plurality of remote user devices, b) a plurality of remote merchant servers of at least one merchant which are operable to offer at least one of predetermined goods and services, to users of the remote devices, online, C) at least one remote banking institution server of at least one banking institution at which the users hold bank accounts and which is operable to facilitate payment for goods and services which are purchased online from the merchant by users of the remote devices, the central server including a banking institution interface for interfacing with the banking institution server and a merchant interface for interfacing with the merchant servers, thereby to facilitate online transactions and communications between the banking institution, the merchant and the users of the remote devices, the central server of the central computing facility, being operable to send, in response to receipt of an online request from a user ofa particular remote device to effect a particular transaction with said merchant, an online instruction to the banking institution server to verify whether the user has sufficient funds available for the transaction, the central server being operable, if the banking institution verifies the availability of funds for the transaction, to send a real-time online instruction to the banking institution server to reserve funds for the transaction, the central server being operable thereafter to send an online AMENDED SHEET

To WO 02/37729 76 message to the merchant that it may proceed with the transaction and thereafter, in response to receipt of a message from the merchant that the transaction has been processed, to send an online instruction to the banking institution server to release the reserved funds to a designated payee to complete the transaction.

5. A central computing facility as claimed in claim 4, which is operable to monitor data processing carried out between each remote device and the banking institution server and each merchant server, and to retrieve banking data relating to a particular user, from the banking institution and merchant transaction data from the merchant with whom the user transacts and to communicate the banking data and the merchant transaction data to a remote device that is accessible to the user, thereby to provide the user with a consolidated data position.

6. A central computing facility as claimed in claim 5, which is operable to maintain a record of transactions carried out by users, with the merchant servers and the banking institution server, the central computing facility including a user administration database in which said banking data and merchant transaction data pertaining to each user, is stored.

7 Anew method of managing transactions ina data processing system substantially as described in the specification.

8. A method of managing transactions in a data processing system substantially as described in the specification, with reference io and as illustrated in the accompanying diagrammatic drawings. AMENDED SHEET

9. A new central computing facility substantially as described in the specification.

10. A central computing facility substantially as described in the specification, with reference to and as illustrated in the accompanying diagrammatic drawings. AMENDED SHEET