GB2393806A

GB2393806A - Method for confirming authorisation of access to an account

Info

Publication number: GB2393806A
Application number: GB0223182A
Authority: GB
Inventors: Simos Symeou
Original assignee: Individual
Current assignee: Individual
Priority date: 2002-10-05
Filing date: 2002-10-05
Publication date: 2004-04-07
Also published as: GB0223182D0

Abstract

A system and method for shifting the Authorisation to initiate an Action on an Account of an Account Owner, from the Account Issuer to the said Account Owner which is comprised of a communication network, a messaging technology, a personal communication device, a password, a Transaction ID, a Personal PIN Number and messages communicated through the communication network between the said Account Issuer and the said Account Owner. Each time a Transaction is initiated on the said Account, the Account Issuer shifts authorisation to act on the said Account by using the communication network or channel to send appropriate messages to the personal communication device of the said Account Owner. The said Account Owner, upon receiving the request for authorisation, replies by communicating the decision to act on the said Account by using the said personal communication device to send the appropriate message through the communication network or channel.

Description

System and method to allow direct manipulation of an Account by shifting

Authorisation power to the Account Owner. Background of the invention

In today's society, technology is more and more becoming a part of our daily lives. Many times, we assign certain responsibilities to computer systems for taking a decision on our behalf. Examples of this could be our bank's systems authorising a financial Transaction after a certain number of checks they perform on information that another system communicated to them, or our company's intranet server granting access to our company Account by simply checking the validity of a pre-assigned usemame and password, without, in any of the cases, having any real proof that the details ultimately received by those computer systems were indeed supplied by the legitimate Account Owner.

This inappropriate shift of responsibility and authorization has created and is still creating a number of problems to the world, financial and otherwise. Large amounts of sensitive data and millions of pounds are lost yearly by the fraudulent use of such Accounts. Examples of Accounts can be a bank Account, the Account of an employee in a company, an small Account or an intemet banking Account.

This problem is not only limited to online or virtual Accounts, but also to Accounts that give an individual, access to secured physical areas, such as a bank's main safe area (where all the money is kept), the warehouse of a building, a secured military area or office and other locations that require a certain degree of clearance before someone can have access to them. The only check that usually takes place (when of course the entrance is not physically guarded) for a gate or a door to open and grant access to an individual, is for the individual to either enter a PIN number or swipe a pass card on a device attached next to the entrance under discussion (this excludes systems that operate using biometric technology). The computer system that controls access to the said entrance has no way of knowing whether the person that entered the PIN number or swiped the card is indeed the expected, authorised person or a fraudster. As far as the computer system is concerned, the details entered match with the ones held in its database. These cases create great damage to organizations by the "leak out" of business sensitive data, by the thousands of items that are stolen or by the intentional modifications of systems that result in them crashing, giving out wrong reports or performing miscalculations.

Figure 2a demonstrates how the transactions are currently finalized (approved or rejected). Anyone with the account access information (e.g. credit card details, username and password, a pass card or a PIN number) can initiate a transaction 20. The account access information is sent to the account issuer over the normal channels (through an acquirer, through the internet, through a leased line, etc) 21 until it reaches the account issuer. The account issuer receives the account access information 22 and checks for its validity 23. If it is correct (i.e. matches the information held in the computer systems of the account issuer), the transaction is authorised 24, otherwise the transaction is rejected 25. This invention looks into creating a system and method that provides a way to shift the power of Authorisation for executing or initiating an action on an account, from the computer system that had previously been assigned to authorise the said action and giving that responsibility to the owner of the account, thus allowing the person or entity that will be most effected in case of a damage from that action to have the power to either authorise or reject it.

Definition of terms Before going into the details of describing the invention, an understanding has to be established on the terms used in this document: a. Physical Pace: a building or a certain area of a building, a warehouse, a military area or any other establishment that requires some form of clearance to access it.

b. Account: a Financial, Online or Physical Account.

i. Financial Account: an Account of financial nature held on behalf of an individual or a company by a financial institution such as a bank. Examples of

Fnancial Accounts can be a bank account, a current account, a shares account, a loan account or a pension account.

ii. Online Account: an Account that can be accessed over the internet, usually with the use of a usemame and password and that holds sensitive or personal data either of business or financial nature. Examples of Online Accounts can be an internet banking account, an online shares portfolio account, a company intranet account, an online briefcase account or a web administration account.

iii. PhysicalAccount: a clearance status assigned to an individual to give him/her access to a physical place. That clearance can be in the form of a pass card that can be swiped on a card reader that operates next to the entrance of the Physical Place or a PIN number that can be entered on a device which operates next to the entrance of the Physical Place.

c. Property: an Account or a Physical Place.

Action: an act that results in accessing an Account. It can be legitimate or fraudulent. For a Financial Account could be using a credit card to buy goods or services, for an Online Account could be logging into your online share portfolio account and for a Physical Account could be entering your PIN number to open a door to enter a secure area in your company's establishment. An Action on a Physical Account would result in accessing the Physical Place or contents of the Physical Place. There are nine types of Actions: i. Approval Action ii. Block Action iii. Cancel Action lv. Pause Action v. Activate Action vi. Lock Action vii. Unlock Action viii. Divert Action ix. Query Action The functionality of each Action, when and how each Action is triggered and what it represents, is explained in the detailed description of the invention.

d. Authorisation: the power to initiate or execute an Action on a Property.

e. Damage: a financial or otherwise loss that results from a fraudulent Action on a Property. For a Financial Account could be transferring money out of the Account without the knowledge of the Account holder; for an Online Account could be someone logging into the online share portfolio of another person and selling shares at a loss; for a Physical Account could be someone using the pass card of another person to access a secured area.

f. Responsibility: the person or company that is liable for a Damage occurring on a Property. 9. Victim: The person or company that the Damage impacts most.

h. Account Issuer: the issuer of an Account to a person. The Account Issuer gives the Authorisation to that person to perform Actions on a Property. For a Financial Account would be a Bank creating a bank Account for someone upon request; for an Online Account could be E-Trade opening a share dealing Account for someone upon request and for a Physical Account could by an employee's company issuing a pass "rd to an employee.

i. Account Owner: the legitimate holder of an Account.

i. Account Access Information (MI): the information needed to access an Account. For a Fnancial Account could be the information held on a debit or a credit "rd; for an Online Account could be a username and password; for a Physical Account could be either the information held on a pass "rd or a PIN number.

k. Account Access information Medium (MIM): the object mat holds the AAI. It is given by the Account Issuer to the Account Owner. For a Financial Account could be a debit or a credit card; for an Online Account would be a usemame and password and for a Physical Account could be a pass card or a PIN number.

1. Transaction: can be applied to an Account. It is an a* on an Account that causes the Account to change state. A Transaction is initiated by either supplying the AAI (e.g. on a website) or by using the AAIM (e.g. swiping the Account's "rd). The triggering of a Transaction results in sending me AAI of the Account to the Account Issuer.

There are three types of Transactions: i. Financial Transactions: applied to Financial Accounts, a Financial Transaction is a Transaction that causes a change in the balance or state of a Fnancial

Account. There are two types of Rnancial Transac*ions: online Financial Transa*ions and high-street Rnancial Transa*ions. An online Financial Transa*ion is when the cardholder (Account Owner) is buying goods or services over the intemet on a website. A high-street Financial Transaction is when the Account Owner is buying goods or services from a high-street merchant over a Point Of Sale (POS).

ii. Online Transactions: applied to Online Accounts, an Online Transa*ion is a Transa*ion that gives the Account Owner access to his/her Account.

iii. Physical Transactions: applied to Physical Accounts, a Physical Transa*ion is a Transaction that gives the Account Owner access to the Account Issuer's Property. A Transa*ion can be initiated by anyone having the AAI whether this would be the Account Owner (which will make the Transa*ion a legitimate one) or someone else (which will make the Transa*ion a fraudulent one).

Examples of Transa*ions: for a Financial Account could be transferring funds out of the Account to pay for a purchase of goods or services; for an Online Account could be supplying the usemame and password to access your intemet banking service; for a Physical Account could be swiping a pass card to open the door mat gives access inside the warehouse. In other words, Transa*ion, as used in this document, is not necessarily restricted in the context of a Financial Transa*ion. It is any act that causes a one-way or two-way interaction with an Account of any type.

m. Message: a command sent by the Account Issuer to the Account Owner or by the Account Owner to the Account Issuer. A Message triggers an A*ion on the Account of the Account Owner. There are four types of Messages: i. Authorisation Shift Message (AuSM) ii. Authorrsation Response Message (ARM) iii. Account Status Message (ASH) iv. Account Query Message (AQM) Details on each of the Message types as well as what A*ion types they can generate are included in the detailed description.

Examples of Messages: for a Financial Account could be the issuing bank sending a message to the personal communication device of the Account Owner, shifting authorization for approving the purchase of goods; for an Online Account could be Whoop sending a message to the personal communication device of the Account Owner, shifting authorization for logging into the email account; for a Physical Account could be a company's servers sending a message to the personal communication device of the employee, shifting authorization for accessing a secure area in the company's establishment.

Additional terms that have to be established concern the different stages of a Transa*ion.

A Transa*ion can have the following stages from initiation to completion: a. Initia/ Transaction Stage (ITS): When an Action on an Account is performed that causes a Transa*ion on the said Account to be initiated. For a Financial Account could be supplying the card details and personal information on a merchant's website and clicking on the Buy" button. For an Online Account could be supplying a username and password to access your internet banking service. For a Physical Account could be swiping your pass card to open a door that gives you access to a restricted area of your military camp.

b. Pending Transaction Stage (PTS): When an Action is expected before the Transa*ion on an Account can continue. For a Rnancial Account could mean the merchant waiting a response from the issuing bank on whether a Transa*ion is approved or rejected. For an Online Account could mean waiting a response from the bank's systems to access your internet banking service. For a Physical Account could mean waiting for the computer system that controls access to an area to open the door to give you access to that area.

c. Final Transaction Stage (m) When an A*ion on an Account is performed that causes the Transa*ion on the said Account to be finalized (approved or denied).

For a Financial Account could mean the bank doing all the necessary checks on the AAI sent by the computer systems of the merchant and finalizing the Transa*ion.

For an Online Account could mean the bank's computer systems checking the AAI and giving the customer access to the internet banking service. For a Physical

Account could mean the computer systems that control access to a restricted area checking the AAI and opening the door to the soldier to give him access to the restricted area.

Problems that the invention solves This invention provides the method and system to shift the Authorisation power back and Forth between the Account Issuer and the Account Owner in such a way so that it ensures that the Authorisation is always with the person that has the Responsibility of the Account, is liable for the Damage on the Account and would be the victim from a fraudulent Action on the Account. It accomplishes this by establishing a two-way channel of communication between the Account Issuer and the Account Owner that is different than the normal channel currently followed for a Transaction to be finalized (approved or rejected).

Figure la demonstrates who has Authorisation, who gets Responsibility for Damage and who the victim is at the different stages of a Transaction, with the current, normal way of transacting. At the IN 1, the Authorisation to initiate a Transaction resides with the Account Owner. At the PTS 2, The Authorisation to continue the Transaction resides with the Account Issuer. At the FTS 3, The Authorisation to finalise the Transaction resides with the Account Issuer, the Responsibility for Damage on the Account resides with both the Account Issuer and Account Owner and both the Account Issuer and Account Owner will be the victims of any fraudulent Action on the Account Owner's Account. The weak point with the existing systems that is demonstrated here is that the Account Issuer has no way of verifying whether the person that initiated the Transaction is indeed the legitimate Account Owner or a fraudster. Despite of this fact, the Account Owner might still stand liable for any Damage done on his/her Account, even if the Account Owner did not have any involvement in the fraudulent Transaction.

This method and system provides the computer systems of the Account Issuer with a means to further guarantee that the AAI received by the computer systems of the Account Issuer originated from the Account Owner. The establishment of the additional channel of communication between the Account Owner and the Account Issuer is achieved by using any type of network, such as a wired or wireless communications network, the internet or an intranet, to establish a two-way communication between the Account Owner and the Account Issuer. The Account Owner uses this communication channel to communicate his/her response/decision back to the Account Issuer (during the PTS), shifting the Authorisation to act on the Account, back to the Account Issuer.

At the same time the invention gives a certain degree of guarantee to the Account Owner that histher AAI and/or AAIM will be rendered useless to anyone fraudulently using or stealing them.

Note: The invention is not concerned with cases that the AAI is not correct. This can already be handled by the existing systems.

The application of this invention can help in reducing unauthorized access to Financial, Online and Physical Accounts. It also empowers the Account Owner to initiate certain A*ions to direct the Account Issuer to either set or change certain parameters or the behaviour of the Account Owner's Account, resulting in giving the Account Owner more control over his/her Account.

Advantages of invention The application of this invention does not require any change in the internal structure of the systems that are currently used for Authorising a Transaction. People will still need to use their credit or debit cards, will still need to provide a username and password and will still need to swipe their pass card or enter their PIN to get access to their Account or Physical place. This invention adds another layer of protection/authorisation/identification that gives a higher sense of security to barn the Account Owner and the Account Issuer.

All Account Owners that are registered with an Account Issuer that uses the invention can have access to the services offered by the invention or can choose to opt out.

There is no need for extra "trips" for transferring data between either the Account Owner and the Account Issuer or between the Account Issuer and the merchant for communicating the extra information needed for the invention to work. What is different is that the Account Owner has to Authorise the Transaction himself/herself before the Account Issuer can finalise it.

Essential features of the invention i. A communication network or channel of any type, such as a wired communications network, a wireless communications network, or the internet; ii. A messaging technology that allows messages to be communicated back and forth between the Account Issuer and the Account Owner. The messages should be compatible with the communication network used so that they can be sent over it.

Examples of such messaging technology can be voice messages, sounds of different wavelengths to denote a different anion, Short Messaging Service (SMS) messages, Email or any other form of message type capable and compatible with a communication network. The said messages should follow a pre-agreed structure, said structure agreed between the Account Owner and the Account Issuer, for the purpose of avoiding miscommunication. Also, the structure of the said messages should be in a form understood by a human being when received by the Account Owner and in a form "understood" by the computer systems of the Account Issuer when received by the Account Issuer's computer systems; iii. A device that is capable of sending and/or receiving such messages. Examples of such devices can be the landline phone device of the Account Owner to receive the messages in a voice format, the mobile phone of the Account Owner to receive the messages either in voice format or in text format, the PDA device of me Account Owner to receive the messages either in voice format or in text format, the email account of the Account Owner to receive the messages in text format or any other device or system capable of receiving and sending the types of messages mentioned in point (ii) above. The messaging device has to be compatible with the communication network used and provide a means for the messages to be communicated to the user, such as a voice handset, a vibrating function or a screen.

Also, the said device has to preferably belong to the Account Owner. Such a device will be referred to as a personal communication device henceforth in this document; iv. The invention comes in the form of a software program supported by computer hardware that sits and operates next to the existing computer systems that control or have the power to Authorise Transactions on any one of the Account types (financial, Online or Physical) and communicates with the said computer systems by exposing a software interface that provides all me necessary methods and properties for establishing a two-way communication channel between the Account Issuer and Account Owner.

v. Real time, randomly generated, session based alphanumeric passwords. These are optional, depending on the way the invention is implemented and used.

vi. A Transaction ID number associated with each Transaction that is generated by the Account Issuer and sent to the personal communication device of the Account Owner as a means of identification between different Transactions. The said Transaction ID number has to be included in any message communicated to me Account Issuer by the Account Owner using the personal communication device of the said Account Owner. vii. A fixed (or not frequently changed) personal PIN number assigned to the Account Owner. The said personal Pith number has to be induded in every message communicated to the Account Issuer by the Account Owner using the personal communication device of the said Account Owner as a further means of identification of the said Account Owner to the said Account Issuer.

viii. A time-out period, which is a pre-determined amount of time (e.g. 5 minutes) that the Account Issuer has to wait for a response to the Authorisation shift communicated to the Account Owner before awing on a Transaction.

ix. A pre-established agreement between the Account Issuer and the Account Owner stating that messages communicated by the Account Issuer to the personal communication device of the Account Owner constitute a shift in Authorisation power for acting on the Account of the Account Owner from the said Account Issuer to the said Account Owner, and that messages communicated by the Account Owner to the computer systems of the Account Issuer constitute a shift in Authorisation power for

acting on the Account of the Account Owner back from the said Account Owner to the said Account Issuer.

Introduction to the drawings

1. Fgure la: Current Authorisation, Responsibility and Victims of Transactions at the different Transaction stages (US, a, l A).

2. Figure lb: Authorisation, Responsibility and Victims of Transactions at the different Transaction stages (Ids, PTS, FFS) with the application of the invention.

3. Figure 2a: Current Transaction flow.

4. Figure 2b: Transaction flow with the application of the invention.

5. Figure 3a: Financial Transaction Flow with the application of the invention.

6. Figure 3b: Online or Physical Transaction flow with the application of the invention.

7. Figure 4: What triggers the different types of Messages and what Actions each type of Message can generate.

8. Fgure 5a: AuSM message structure for Financial Accounts.

9. Figure 5b: ARM message structure for Financial, Online and Physical Accounts.

10. Fgure 6a: AuSM message structure for Online Accounts.

11. Figure fib: AuSM message structure for Physical Accounts.

12. Figure 7: What happens when the ARM message is not received.

13. Figure 8: ASM message structure.

14. Figure 9: AQM message structure.

15. Figure 10a: Account Issuer's data requirements for Financial Accounts: The table needed to maintain required information about the Account Owner and his/her Financial Account.

16. Figure Lob: Account Issuer's data requirements for Financial Accounts: The table needed to maintain required information for enabling me invention to function.

17. Fgure 10c: Account Issuer's data requirements for Financial Accounts: The table needed to log failed Financial Transactions.

18. Figure 11a: Account Issuer's data requirements for Online and Physical Accounts: The table needed to maintain required information about the Account Owner and his/her Online or Physical Account.

19. Fgure 11b: Account Issuer's data requirements for Online Accounts: The table needed to maintain required information for enabling the invention to function.

20. Figure llc: Account Issuer's data requirements for Online and Physical Accounts: The table needed to log Failed Online or Physical Transactions.

21. Figure 12: Data requirements for Account Issuer for Physical Accounts: The table needed to maintain required information for enabling the invention to function.

22. Figure 13a: High-street Financial Transaction.

23. Figure 13b: Online Financial Transaction implementation manner 1 (uses Internet IP Address) 24. Figure 13c: Online Financial Transaction implementation manner 2 25. Figure 14a: Online Transaction implementation manner 1 (uses Internet IP Address) 26. Fgure 14b: Online Transaction implementation manner 2 27. Figure 15: Physical Transaction Description of the invention

One of the important aspects of the invention is the shift of Authorisation power back and forth between the Account Owner and the Account Issuer to ensure that both the Account Issuer and the Account Owner take part (or have a say) in finalizing a Transaction on the Account Owner's Account.

The invention's method and system differs from the existing way of Transacting by shifting the Authorisation power to the Account Owner before the Transaction is finalised by the Account Issuer, resulting in the Account Issuer executing only what the Account Owner wants. Fgure lb demonstrates who has Authorisation, who gets Responsibility for Damage and who the victim is at the different stages of a Transaction, when the invention is applied. At the ITS 1, the Authorisation to initiate a Transaction resides with me Account Owner. At the PTS 2, The Authorisation to continue the Transaction is shifted from the Account Issuer to the Account Owner, thus resides with the Account Owner. At the 3, the Authorisation to finalise the Transaction is shifted back from the Account Owner to the

Account Issuer, thus resides with the Account Issuer, the Responsibility for Damage on the Account resides with both the Account Issuer and Account Owner and both the Account Issuer and Account Owner will be the victims of any fraudulent Action on the Account Owner's Account. The major difference from the existing way of Transacting is that the final Action that the Account Issuer executes on the Account Owner's Account is the one instructed by the Account Owner, so in effect both the Account Issuer and the Account Owner participate at the S. Figure 2b illustrates the flow of information from the moment a Transaction is initiated to the moment the Transaction is finalized, using the invention. Anyone with the AAI can initiate a transaction 20. The AAI is sent to the Account Issuer over the normal channels 21 until it reaches the Account Issuer. The Account Issuer receives the AAI 22 and checks for its validity 23. If the AAI is not correct, the Transaction is blocked 25. If the AAI is correct (i.e. matches the information held in the computer systems of the Account Issuer), the Account Issuer triggers an Authorisation shift (i.e. generates a message with specific information) 27a and communicates the Authorisation shift 28a to the personal communication device of the Account Owner. The Account Owner receives the Authorisation shift 29, prepares the decision (which is the Authorisation shift back to the Account Issuer) 27b and communicates the decision 28b back to the Account Issuer. The Account Issuer receives the decision 30 and checks to identify what Action to take 31. If the decision is Block, the Account Issuer Blocks the Transaction 25; if the decision is Approve, the Account Issuer Approves the Transaction 24.

The description of the invention is broken down into the following parts:

1. Message types: describes the Message types and what Action each can generate.

2. Action types: describes the Action types and where they can be applied.

3. Structure of messages: describes the structure of each Message type in relation to the Account type that the invention is applied at.

4. Data requirements by the Account Issuer: Describes what kind of data needs to be maintained by the Account Issuer to enable the application of the invention.

5. Putting it a/l together: explains how the invention is applied to the different Types of Accounts. Notes: À Text enclosed in double quotes ("I) denotes text that is used in messages communicated between the Account Issuer and the Account Owner, either enclosing the actual text or variable values.

Text enclosed in "<" and ">" denotes a variable value.

Text enclosed in "[<" and ->]- denotes an optional variable value.

Text enclosed in "[" and -]" denotes actual optional text.

Text separated by ''l'' denotes that either of the values can be used, but only one at a time.

1. Message types There are four types of Messages: AuSM, ARM, ASH and AQMmessage.

a. AuSM: applied to all types of Accounts (Financial, Online, Physical), an AuSM message is the message communicated by the Account Issuer to the Account Owner that shifts the power of Authorisation from the Account Issuer to the Account Owner.

The AuSM message is generated before the Account Issuer Authorises a Transaction that was initiated on the Account of the Account Owner, but after the Account Issuer checks and confirms the validity of the AAI information that has been communicated to the Account Issuer through the normal channels. The AuSM message can only be generated by the Account Issuer.

b. ARM: applied to all types of Accounts (Financial, Online, Physical), an ARM message is the message communicated by the Account Owner to the Account Issuer specifying the Action decided by the Account Owner that the Account Issuer should take on the Account Owner's Account, i.e. shifting the power of Authorisation back from the Account Owner to the Account Issuer. The ARM message can only be sent by the Account Owner to the Account Issuer when the Account Owner receives an AuSM message from the Account Issuer.

c. ASM: applied to all types of Accounts (financial, Online, Physical), an ASM message is the message communicated by the Account Owner to the Account Issuer ordering the Account Issuer to set (change) the status of the said Account Owner's Account.

The ASM message can only be generated by the Account Owner. The Account Owner can generate and send an ASM message to the Account Issuer at any time.

d. AQM: applied to Financial Accounts, an AQM message is the message communicated by the Account Owner to the Account Issuer requesting certain information about the Account Owner's Account. The AQM message can also be used to order the Account Issuer to perform a transfer of money from the said Account Owner's Account to another financial Account and also to get (retrieve) the status of the Account Owner's Account.

The following table gives a summary of what Message types can be applied to what

Account types: Message type Finanaial Online Physical Account Account Account 1 AuSM X X X 2 ARM X X X

3 ASM X X X

4 AQM X

Each of the Message types can generate a certain Action type. Figure 4 demonstrates this.

401, shows that a Transaction can trigger an AuSM message which in turn can trigger an ARM message, which in turn can generate either an Approval Action, a Block Action or a Cancel Action. 402, shows that the Account Owner can trigger an ASM message which in turn can generate either a Pause Action, an Activate Action, a Lock Action, an Unlock Action or a Divert Anion. 403, shows that the Account Owner can trigger an AQM message which in tum can generate a Query Action.

The following table gives a summary of what Action types each Message type can

enerate: Message type 1 AuSM 2 ARM 3 ASM 4 AQM,,

2. Action types There are nine types of Actions: Approval, Block, Cancel, Pause, Activate, Lock, Unlock, Divert and Query Action.

a. Approve/ Achon: applied to all types of Accounts (financial, Online and Physical), an Approval Action is an Action that causes a Transaction on the Account of the Account Owner to finalize. For a Financial Account could mean the Account Owner Authorising the Account Issuer to approve the said Transaction on the said Account by sending an ARM message containing approval instructions in response to the AuSM message that the Account Issuer sent to the personal communication device of the Account Owner; For an Online Account or a Physical Account could mean the Account Owner Authorising the Account Issuer to allow access to the said Account by sending an ARM message containing approval instructions in response to the AuSM message that the Account Issuer sent to the personal communication device of the Account Owner. b. Block Action: applied to all types of Accounts (Financial, Online and Physical), a Block Action is an Action that causes a Transaction on the Account of the Account Owner to stop. A Block Action implies that there was a fraudulent attempt on the said Account. For a Financial Account could mean the Account Owner Authorising the Account Issuer to stop the said Transaction on the said Account by sending an ARM message containing block instructions in response to the AuSM message that the Account Issuer sent to the personal communication device of the Account Owner; For an Online Account or a Physical Account could mean the Account Owner Authorising the Account Issuer to block access to the said Account by sending an ARM message containing block instructions in response to the AuSM message that

the Account Issuer sent to the personal communication device of the Account Owner. c. CancelAction: applied to Financial Accounts, a Cancel Action is an Action that causes a Transaction on the Account of the Account Owner to stop. A Cancel Action implies that a legitimate attempt by the Account Owner on his/her Account has been taken and the Account Owner wishes to stop the Transaction before it can be completed for any reason. This could mean the Account Owner Authorising the Account Issuer to abort the said Transaction on the said Account by sending an ARM message containing cancel instructions in response to the AuSM message that the Account Issuer sent to the personal communication device of the Account Owner.

d. Pause Action: applied to all types of Accounts (hnandal, Online, Physical), a Pause Action is an Action that causes the invention's system to stop being applied on the Account of the Account Owner, i.e. no AuSM messages will be sent to the personal communication device of the Account Owner, for as long as the Pause Action is in effect or for a specified period, said period being specified in the ASM message sent by the Account Owner to the Account Issuer. In other words, to Pause the Account means that Transactions on the said Account will operate as normal without requiring the Account Owner's Authorisation. The Account Owner can initiate a Pause Action at any ffme, by sending an ASM message to the Account Issuer using his/her personal communication device. An example could be an Account Owner instructing his/her issuing bank to pause the service to the Account Owner's Account from now until next day at 10 o'clock in the morning. This feature is useful when the Account Owner wants to leave his/her personal communication device at home or when the Account Owner knows that he/she will not have access to his/her personal communication device for some time. By Pausing the service (invention), the Account Owner is still able to conduct Transactions on his/her Account.

e. Activate Action: applied to all types of Accounts (financial, Online, Physical), an Activate Action is an Action that causes the invention's system to start being applied on the Account of the Account Owner again, i.e. AuSM messages will be sent to the personal communication device of the Account Owner before the Account Issuer can finalise a Transaction. An Activate Action can only follow a previously sent Pause Action and has to be sent at a time period that is earlier than the time specified in the Pause Action whereby the Pause Action is still in effect; otherwise it is ignored by the Account Issuer. The Account Owner can initiate an Activate Action at any time, by sending an ASM message to the Account Issuer using his/her personal communication device. An example could be the Account Owner requesting his/her bank to re-activate his/her account at 8 o'clock instead of waiting for the automatic re-a*ivation at 10 o'clock.

f. Lock Action: applied to all types of Accounts (financial, Online, Physical), a Lock Action is an Action that locks an Account, i.e. preventing Transactions to initiate on it (apart from any direct debits or standing orders or any other kind of predefined orders on the said Account), until an Unlock Action is initiated by the Account Owner. The Lock Action gives the effect of as if the Account does not exist. The Account Owner can initiate a Lock Action at any time, by sending an ASM message to the Account Issuer using his/her personal communication device.

9. Unlock Action: applied to all types of Accounts (financial, Online, Physical), an Unlock Action is an Action that unlocks a previously Locked Account, i.e. allowing Transactions to initiate on it. It has an effect only when the Account is either Locked or Paused. The Account Owner "n initiate an Unlock Action at any time, by sending an ASM message to the Account Issuer using his/her personal communication device. h. Divert Action: applied to Financial Accounts, a Divert Action is an Action that causes Authorisation shift requests to be communicated to the personal device of a person other than the Account Owner, said person being a person that the Account Owner wishes to allow access to his/her Account for a limited period of time, a limited number of transactions, or a limited transaction amount. Only the Account Owner can initiate a Divert Action. The Divert Action automatically shifts Authorisation of the Account back to the Account Owner once the predefined parameters have been met. The Account Owner can deactivate the Divert A*ion at any time. The Divert A*ion does not remove from the Account Owner the rights to initiate a Lock, Unlock, Pause, Activate, Query or Divert A*ion. The Divert A*ion does remove from the Account Owner the rights to initiate an Approval, Block or Cancel Action, until the Divert A*ion is deactivated. The Account Owner can initiate a Divert A*ion at any

time, by sending an ASH message to the Account Issuer using his/her personal communication device. An example of a Divert Action could be a parent giving his credit card to his son to buy goods from the Internet, only allowing a maximum of 248 to be spent.

i. Query Action: applied to Financial Accounts, a Query Action is an Action that causes information about the Account of the Account Owner to be communicated back to the personal communication device of the Account Owner. The Account Owner can initiate a Query Action at any time, by sending an AQM message to the Account Issuer using his/her personal communication device. Examples could be requesting the balance of the said Account or asking how many Transactions were executed on the said Account today. A Query Action can also initiate a Financial Action on the said Account. An example could be the Account Owner requesting the transfer of money from his/her Account to another financial Account.

The following table gives a summary of what Action types can be applied to what Account

types: - Action type Financial Online Physical Account Account Account 1 Approval Action X X X 2 Block Action X X X 3 Cancel A*ion X 4 Pause Action X X X 5 Activate Action X X X 6 Lock Action X X X 7 Unlock Action X X X 8 Divert Action X 9 Query Action X 3. Structure of messages The message structures vary slightly depending on the type of Account (Financial, Online, Physical) that the invention is applied at. The description of the structure of messages is

broken down into four parts, one for each of the three Account types and a fourth part describing the procedure whereby the Account Issuer fails to receive the ARM message from the Account Owner.

Notes: The sequence of the fields shown in each of the Message types is not

necessarily restricted to the sequence shown. The sequence can be decided upon by the Account Issuer in any manner that the Account Issuer finds convenient and is comfortable with.

The words used in the messages are not necessarily the ones that have to be used. Abbreviations of words can be used to shorten the messages for the convenience of the Account Issuer and Account Owner. For example, pN could be used instead of"Pause". Some examples are also given in the description

itself. The words in the messages are not case sensitive, i.e. Pause" is equal in meaning to "pause".

Any timestamps (Date and/or Time) communicated between the Account Owner and the Account Issuer have to comply to the time zone of the country that the Account is held to establish a common timestamp protocol that will allow for global application of the invention. For example, if someone has an Account in the UK, then GMT times will be used by the Account Issuer when sending messages to the Account Owner and vice versa.

a. Structure of messages for Financial Accounts i. AuSM messages The AuSM message for Financial Accounts is generated by the Account Issuer and sent to the personal communication device of the Account Owner when a Financial Transaction is initiated on the Financial Account of the Account Owner and the Account Issuer receives the MI and verifies its validity. The AuSM message shifts Authorisation of the Transaction to the Account Owner, who is going to be the

immediate victim of any fraudulent Action taken on the said Financial Account. By shifting Authorisation, the Responsibility to handle the Transaction lies with the Account Owner.

Figure 5a shows the fields contained in an AuSM message. These are: Last four

digits of Account Number Sal, Transaction Amount 5a2, Transa*ion ID 5a3, Message asking permission to authorise transaction 5a4 or Password for verifying identity to authorise transaction 5a5 and Expected ARM Instructions 5a6. Optional fields that can be added include: Date & Time of transaction 5a8, Merchant name

5a9, Account Issuer name 5alO, Comments Ball. The structure is as follows: <Last_4_digits_of_account_number> + <Transacffon_amount> + <Transaction ID> + ( < Message_asking_permission_to_authorise_transaction> l < Password_for_verifying_identity_to_authorise_transaction>) + <Expected_ARM_instructions> [ + <Date__Time_of_purchase [ + <Merchant_name> [ + <List_of_goods_purchased> [ + <Account_Issuer_name> + [ + Comments]]]]] Held Sal contains information identifying the Account that the Financial Transaction is applied on. Only the last four digits of the Account number are used for security and simplicity reasons. An example could be Account *8791.

Held 5a2 contains information specifying the amount of the attempted transaction. An example could be"Amount 14.04n.

Field 5a3 contains information specifying the Transaction ID. The Transaction

ID is a 2-4 digit number that is unique for every new transaction on the said Financial Account. It is used to distinguish between transactions that are currently in PTS. This field is initialised every 24 hours at the beginning of the

day and is not necessarily generated in a sequential order. An example could be"Transaction ID is 15.

Field 5a4 is the Authorisation shift part of the message. The Account Issuer

asks the Account Owner what Action to take on the Transaction. An example could be "How do you want to proceed with this transaction?" or "Do you want to authorise this Transaction?n.

Field 5a5 is a randomly generated, 4-8 digits, session based password which

is used for online Financial Transactions in the place of field 5a4. This field can

only be used for online Financial Transactions and if the Account Issuer knows the Internet IF Address of where the Transaction has initiated. If the Account Issuer knows the IP Address of where the Transa*ion was initiated, the said Account Issuer shows a popup window on the monitor of the computer system from where the Transaction was initiated, asking from the person that initiated the Transaction to supply the password contained in the AuSM message that was sent to the personal communication device of the Account Owner. In this case, the ARM message for Approving the Transa*ion is sent through the Internet. Otherwise, if the Financial Transa*ion is a high-street Financial Transa*ion or if the Account Owner does not want to Approve the Transa*ion or when the Transa*ion is fraudulent, the Account Owner uses his/her personal communication device to communicate the ARM message back to the Account Issuer. More details on this are in section 5 of the description,

"Putting it all together" and in the sections that follow.

Field 5a6 contains information and instructions to the Account Owner on what

the ARM message can contain. These instructions include how the Account Owner is to communicate the ARM message back to the Account Issuer, what types of Ac*ions are expected and what other information the Account Owner needs to include to enable the Account Issuer to verify his/her identity and act on his/her behalf. The Action types allowed are either one of Approve, Block or Cancel Action. An example could be "Reply with Approve, Block or Cancel followed by the Transaction ID and your Personal PIN numbers. The "Approve-, Block. or "Cancel" words denote the type of Action the Account Owner is allowed to take on his/her Account at this stage, namely Approve, Block or Cancel Action respectively. These words can also be replaced by other, pre-agreed words or letters that will have the same effect. For example "Approve" could be "A-, "Block" could be ABE and "Cancel. could be "en.

Optional field 5a7 is a timestamp of the Transa*ion indicating when the

Transa*ion was initiated. An example could be "Date 15/06/2002 12: 27.

Optional field 5a8 contains information identifying the name of the merchant

from which the goods or services are being purchased. An example could be "This transaction is from The Good Grocery Store. or This transaction is from BestOnlineItems.com-. Optional field Sa9 contains a list of the goods or services of the attempted

Transa*ion along with the quantity of each item and/or service. An example could be"Items purchased are: 2 batteries, 1 Camera GC4, 1 music CD".

Optional field Mayo contains information identifying the name of the Account

Issuer. An example could be "This message is from Vision Bank-.

Optional field Ball contains additional information that the Account Issuer

finds useful to convey to the Account Owner. An example could be "We will assume you do not authorise this transaction if we don't get a response in 5 minutes". Commas (,), spaces and/or full stops (.) are used between the fields to make the

AuSM message more user-friendly and readable. An actual example of an AuSM message could be: "Account *8791, Amount 14.04, Transa*ion ID 15. show do you want to proceed with this transaction? Reply with A, B or C followed by the Transa*ion ID and your Personal PIN number. Date: 15/11/2002 20:44. This transaction is from BestOnlineItems.com. Items purchased are: 2 batteries AAA, 1 music CD. This message is from Vision Bank. We will assume you do not authorise this transaction if we don't get a response in 5 minutes.

ii. ARM messages The ARM message for Financial Accounts is generated by the Account Owner once the Account Owner receives an AuSM message on his/her personal communication device. The Account Owner uses his/her personal communication device to send the ARM message to the Account Issuer. The ARM message shifts Authorisation of the Transa*ion back to the Account Issuer and the Account Issuer acts on the Transa*ion as instructed by the Account Owner. The Account Issuer does not take into account any ARM messages received that do not have a corresponding AuSM message. Figure 5b shows the fields contained in an ARM message. These are: Transaction ID

5a3, A*ion type 5bl and Personal PIN Number 5b2. The structure is as follows: <Transaction_lD> + <A*ion_type> + <Personal_PIN_number> Field 5a3 is the same Transa*ion ID that was sent in the corresponding AuSM

message. Following the example of the AuSM message in (i) above, this should be "15.

Field 5bl is one of the A*ion Types instructed in the corresponding AuSM

message, specifying to the Account Issuer what A*ion to take on the Transa*ion. Following the example of the AuSM message in (i) above, this should be either of "Approve", "Block" or "Cancel" for Approve A*ion, Block A*ion or Cancel A*ion respectively. Equally, it could be any other pre-agreed word or letter such as "A" instead of Approve-, ABE instead of mock" or "C" instead of Cancel-.

Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalise a Transaction on the Account of the Account Owner. An example could be "6765.

Spaces are used between each field to distinguish between them. An actual example

of an ARM message could be: "15 A 6765"

instructing the Account Issuer to Approve the Transaction for the corresponding AuSM message with Transaction ID -15't Note: In me "se of online Financial Transactions, if the Account Issuer knows the {P Address of the place where the Transaction was initiated and the Account Owner wants to Approve the Transaction, then the said Account Owner sends the ARM message (which is going to be the password contained in the AuSM message that was sent by the Account Issuer to the personal communication device of the Account Owner) through the Intemet by entering the said password in the popup window that the Account Issuer shows on the screen of the computer system of where the Transaction was initiated (the Account Issuer can also optionally ask for the Transaction ID 5a3 to be supplied in the popup window).

iii. ASM messages file Account Owner can create and send an ASM message to the Account Issuer at any time, using his/her personal communication device, to either set or get the status of his/her financial Account.

Figure 8 shows the fields contained in an ASM message. These are: Account number

81, Status Action command 82 and Personal PIN Number 5b2. The structure is as follows: <Account_Number> + <Status_Action_command> + <Personal_PIN_Number> Held 81 identifies the Account that the status Action is to be applied on. An example could be -30350831437285n.

Field 82 identifies the Action to be applied on me Account. The allowed actions

are any of Pause, Activate, Lock, Unlock or Divert Action.

Examples using a Pause Action: "Pause" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shirts) until an Activate Action is issued; Pause until 23:00" causing the Account Issuer to operate on the Account normally from the time the ASM message is sent until 23:00 o'clock and then automatically Activate the Account again (i. e. start Authorisation shifts); "Pause from 09:00 to 16:00" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) from 09:00 o'clock until 23:00 o'clock and then automatically Activate the Account again (i.e. start Authorisation shifts); "Pause from 09:00 to 23:00 repeat" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) from 09:00 o'clock until 23:00 o'clock and then automatically Activate the Account again (i.e. start Authorisation shifts), repeating the same action automatically every day; "Pause 23/11/2002" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) all day on the 23 of November 2002 and then automatically Activate the Account again (i.e. start Authorisation shifts) at the beginning of 24eh November 2002.

Example using an Activate Action: "A*ivate" causing a Paused Account to activate. The command is ignored if the account is not Paused or if the account is Locked (if the Account is Locked, a message is sent to the personal communication device of the Account Owner informing of the fact).

Example using a Lock Action: "Lock" causing the Account to Lock until an Unlock command is issued.

Example using an Unlock Action: Unlock" causing a Locked Account to Activate. Examples using a Divert Action: "Divert to 99456765" causing AuSM messages to be diverted to the person mat has the personal communication device with the number 99456765 until another Divert Action is issued; "Divert to 99456765 until 22/11/2002- causing AuSM messages to be diverted to the person that has the personal communication device wim me number

99456765 until the beginning of 22 November 2002; Divert to 99456765 for 5 hours" causing AuSM messages to be diverted to the person that has the personal communication device with the number 99456765 for the next five hours starting from the time the ASM message is sent and then automatically divert the Authorisation back to the Account Owner; Divert to 99456765 for 2 transactions. causing the next two AuSM Messages that receive an ARM message Approving the Transaction to be diverted to the person that has the personal communication device with the number 99456765 and then automatically divert the Authorisation back to the Account Owner; "Divert to 99456765 until amount = 100 ±10 causing AuSM messages to be sent to the person that has the personal communication device with the number 99456765 until the said person spends anything between 90 to 110 (100 minus 10 to 100 plus 10) on the Account and then automatically divert the Authorisation back to the Account Owner; "Divert to 99456765 for 3 transactions or amount = 100 ±20 for 5 hours" causing AuSM messages to be sent to the person that has the personal communication device with the number 99456765 until the said person completes three transactions or until anything between 80 to 120 (100 minus 20 to 100 plus 20) are spent on the Account, but only if any of these happens in the next five hours starting from the time the ASM is sent; Cancel divert" causing any previous Divert Action to be cancelled and return Authorisation back to the Account Owner. Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN Number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalise a Transaction on the Account of the Account Owner. An example could be "7185.

Spaces and commas (,) are used between each field to distinguish between them.

Actual examples of an ASM message could be: -30350831437285, pause until 23:00, 7185" instructing the Account Issuer to pause Account with number 30350831437285 until 23:00 of current day and then automatically Activate it again; "30350831437285, divert to 99456765 amount = 100 ±10, 7185" instructing the Account Owner to shift Authorisation for Account with number 30350831437285 to the person that has the personal communication device with the number 99456765 until anything between 90 to 110 is spent on the Account and then automatically shift Authorisation back to the Account Owner.

iv. AQM messages The Account Owner can create and send an AQM message to the Account Issuer at any time, using his/her personal communication device, to either get information about his/her Financial Account or initiate a transfer of funds to another Financial Account. Figure 9 shows the fields contained in an AQM message. These are: Account number

81, Query Action command 91 and Personal PIN Number 5b2. The structure is as follows: <Account_Number> + <Query_Action_command> + <Personal_PIN_Number> Field 81 identifies the Account that the Query Action is to be applied on. An

example could be"30350831437285.

Field 91 identifies the Query Action to be applied on the Account. Examples

could be: Balance" requesting a response on the current balance of the said Account; "Balance 24/08/Z002" requesting a response on what the balance on the said Account was at a previous date (24 August 2002 for this example); "Transactions August 2002- requesting a response on how many Transactions were executed on the said Account in the month of August 2002; Amount August 2002- requesting a response on how much money were spent in the month of August 2002; 'Status" requesting a response on what the status of

the Account is (i.e. if any Pause, Lock or Divert Action is in place or ifthe Account's status is normal); "Average daily spending in August 2002 requesting a response on what the average daily spending was in the month of August 2002; "Email statement for September 2002 to

[email protected]" requesting an email with the financial statement of the Account Owner's Account to be sent to email account

[email protected]; Transfer 100 to 50551831437464- causing the amount of ú100 to be transferred as soon as possible to Account 50551831437464; Transfer 100 to 50551831437464 on 23/11/2002" causing the amount of ú100 to be transferred to Account 50551831437464 on the 23'd November 2002.

Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner) when registering for using the service. The Personal PIN Number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalize a Transaction on the Account of the Account Owner. An example could be "7185.

Spaces and commas (,) are used between each field to distinguish between them.

The following table shows examples of AQM messages sent by the Account Owner to the Account Issuer and the possible responses sent by the Account Issuer back to the personal communication devic of the Account Owner: AQM message Possible response from Acocurt Issuer "30350831437285, balance, 7185- "The current balance on account 30350831437285 is ú2,345. 22.-

"30350831437285, balance 24/8/2002, The balance on account 30350831437285 at 7185" 24/8/2002 was ú2,345.22.

"30350831437285, transactions August The number of transactions executed on 2002, 7185 account 30350831437285 in August 2002 were 56."

"30350831437285, amount August "The amount of money spent on account 2002, 7185- 30350831437285 in August 2002 was ú1234.45.-

"30350831437285, status, 7185" The status of account 30350831437285 is: Paused until 23:00 tonight."

"30350831437285, transfer 100 to -ú100 were transferred from account 50551831437464, 7185 30350831437285 to account 50551831437464"

"30350831437285, average daily "The average daily spending on account spending in August 2002, 7185 30350831437285 in the month of August 2002 was ú39.82" "30350831437285, Email statement for An email was sent to account

September 2002 to [email protected] showing the [email protected], 7185" financial statement of account

30350831437285 for month September 2002."

"30350831437285, transfer 100 to "ú100 will be transferred from account 50551831437464 on 23/11/2002, 30350831437285 to account 50551831437464 7185" on 23/11/2002-

The response from the Account Issuer is a message answering or verifying the Query of the Account Owner and it is formatted in a spoken-like manner, so that it is easily understood by the Account Owner.

b. Structure of messages for Online Accounts i. AuSM messages The AuSM message for Online Accounts is generated by the Account Issuer and sent to the personal communication device of the Account Owner when an Online Transaction is initiated on the Online Account of the Account Owner and the Account Issuer receives the AAI and verifies its validity. The AuSM message shifts Authorisation of the Transaction to the Account Owner, who is going to be the immediate victim of any fraudulent Action taken on the said Online Account. By

shifting Authorisation, the Responsibility to handle the Transaction lies with the Account Owner.

Figure 6a shows me fields contained in an AuSM message. These are: Account

Issuer name 5alO, Account type Gal, Transaction ID 5a3, Message asking permission to authorise transaction 5a4 or Password for verifying identity to authorise transaction 5a5 and Expected ARM Instructions 5a6. Optional fields that

can be added include: Date & Time of Attempted access 6a2, Comments Ball. The structure is as follows: <Account_Issuer_name> + <Account_type> + cTransaction_ID> + ( < Message_asking_permission_to_authorise_transa*ion> l < Password_for_verifying_identity_to_authorise_transaction>) + <Expected_ARM_instructions> [ + <Date_& Time_of_attempted_access> [ + <Comments>]] Field 5alQ contains information identifying the name of the Account Issuer. An

example could be This message is from SharesAIIOverThePlace led-.

Field Gal: contains information identifying what kind of Online Account the

Account Owner holds with the Account Issuer. An example could be Tour Online Share Portfolio".

Field 5a3 contains information specifying the Transaction ID. The Transaction

ID is a 2-4 digit number that is unique for every new transaction on the said Online Account. It is used to distinguish between transactions that are currently in PTS. This field is initialised every 24 hours at the beginning of the

day and is not necessarily generated in a sequential order. An example could be"Transaction ID is 125.

Field 5a4 is the Authorisation shift part of the message. The Account Issuer

asks the Account Owner what Action to take on the Transaction. An example could be "How do you want to proceed with this transa*ion?. or Ado you want to authorise this transaction?.

Field 5a5 is a randomly generated, 4-8 digits, session based password which

is used in the place of field 5a4. This field can only be used if the Account

Issuer knows the Internet IP Address of where the Transaction has initiated. If the Account Issuer knows the Internet IF Address of where the Transaction was initiated, the said Account Issuer shows a popup window on the monitor of the computer system from where the Transac*ion was initiated, asking from the person that initiated the Transaction to supply the password contained in the AuSM message that was sent to the personal communication device of the Account Owner. In this case, the ARM message for Approving the Transaction is sent through the Intemet. Otherwise, if the Account Owner does not want to Approve the Transaction or when the Transaction is fraudulent, the Account Owner uses his/her personal communication device to communicate the ARM message back to the Account Issuer. More details on this are in section 5 of the description, putting it all together and in sections that follow.

Reld Sa6 contains information and instructions to the Account Owner on what the ARM message can contain. These instructions include how the Account Owner is to communicate the ARM message back to the Account Issuer, what types of Anions are expected and what other information the Account Owner needs to include to enable the Account Issuer to verify hisJher identity and act on his/her behalf. The Action types allowed are either one of Approve or Block.

An example could be "Reply with Approve or Block followed by the Transaction ID and your Personal PIN number-. The unapproved or Block. words denote the type of Action the Account Owner is allowed to take on his/her Account at this stage, namely Approve or Block Action respectively.

Optional field 6a2 is a bmestamp of the Transaction indicating when the

attempt to access the Online Account was initiated. An example could be Date 15/11/2002 15:33.

À Optional field Ball contains additional information that the Account Issuer

finds useful to convey to the Account Owner. An example could be owe will assume you do not authorise this access if we don't get a response in 5 minutes .

Commas (,), spaces and/or full stops (.) are used between the fields to make the

AuSM message more user-friendly and readable. An actual example of an AuSM message could be: "This message is from SharesAIIOverThePlace Ad concerning your online share portfolio. Transaction ID is 125. How do you want to proceed with the attempted access on 15111/2002 15:33? Reply with Block or Approve. We will assume you do not authorise this access if we don't get a response in 5 minutes."

ii. ARM messages The ARM message for Online Accounts is generated by the Account Owner once the Account Owner receives an AuSM message on his/her personal communication device. The Account Owner uses his/her personal communication device to send the ARM message to me Account Issuer. The ARM message shifts Authorisation of the Transa*ion back to the Account Issuer and the Account Issuer acts on the Transa*ion as instructed by the Account Owner. The Account Issuer does not take into account any ARM messages received that do not have a corresponding AuSM message. Figure Sb shows the fields contained in an ARM message. These are: Transa*ion ID

5a3, Action type 5bl and Personal PIN Number 5b2. The structure is as follows: <Transaction_ID> + <Ac*ion_type> + <Personal_PIN_number> Field 5a3 is the same Transa*ion ID that was sent in the corresponding AuSM

message. Following the example of the AuSM message in (i) above, this should be125n.

Field 5bl is one of the Action Types instructed in the corresponding AuSM

message, specifying to the Account Issuer what Action to take on the Transaction. Following the example of the AuSM message in (i) above, this should be either of Approve" or "Block" for Approve Action or Block Action respectively. Equally, it could be any other pre-agreed word or letter such as "A" instead of "Approve" or "B" instead of "Block-.

Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalize a Transaction on me Account of the Account Owner. An example could be "6765.

of an ARM message could be: "125 B 6765"

instructing the Account Issuer to Block the Transac*ion (i.e. deny access) for the corresponding AuSM message with Transaction ID "125n.

Note: If the Account Issuer knows the IP Address of the place where the Transa*ion was initiated and the Account Owner wants to Approve the Transa*ion, then the said Account Owner sends the ARM message (which is going to be the password contained in the AuSM message that was sent by the Account Issuer to the personal communication device of the Account Owner) through the Internet by entering the said password in the popup window that the Account Issuer shows on the screen of the computer system of where the Transaction was initiated (the Account Issuer can also optionally ask for the Transaction ID 5a3 to be supplied in the popup window).

iii. ASM messages The Account Owner can create and send an ASM message to the Account Issuer at any time, using his/her personal communication device, to either set or get the status of his/her Online Account.

* 81, Status A*ion command 82 and Personal PIN Number 5b2. The structure is as follows: <Account_Number> + <Status_Action_command> + <Personal_PIN_Number> Held 81 identifies the Account that the status A*ion is to be applied on. It can be the number or the name that identifies the Account. An example could be "my_personal_email@ my_personal_domain.com.

Field 82 identifies the A*ion to be applied on the Account. The allowed actions

are any of Pause, A*ivate, Lock or Unlock Action.

Examples using a Pause Action: Pause. causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) until an A*ivate A*ion is issued; "Pause until 23:00" causing the Account Issuer to operate on the Account normally from the time the ASM message is sent until 23:00 o'clock and then automatically Activate the Account again (i. e. start Authorisation shifts); "Pause from 09:00 to 16:00'causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) from 09:00 o'clock until 23:00 o'clock and then automatically A*ivate the Account again (i.e. start Authorisation shifts); "Pause from 09:00 to 23:00 repeat" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) from 09:00 o'clock until 23:00 o'clock and then automatically A*ivate the Account again (i.e. start Authorisation shifts), repeating the same action automatically every day; "Pause 23/11/2002- causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) all day on the 23 of November 2002 and then automatically Activate the Account again (i.e. start Authorisation shifts) at the beginning of 24th November 2002.

Example using an A*ivate A*ion: Salivated causing a Paused Account to activate. The command is ignored if the account is not Paused or if the account is Locked (if the Account is Locked, a message is sent to the personal communication device of the Account Owner informing of the fact).

Example using a Lock A*ion: Lock" causing the Account to Lock until an Unlock command is issued.

Example using an Unlock Action: "Unlock" causing a Locked Account to Activate. Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Spaces and commas (,) are used between each field to distinguish between them.

An actual example of an ASM message could be: "my_personal_email@my_personal_domain.com, pause until 23:00, 7185" instructing the Account Issuer to pause small Account my_personal_email@my_personal_domain.com until 23:00 of current day and then automatically Activate it again.

c. Structure of messages for Physical Accounts i. AuSM messages The AuSM message for Physical Accounts is generated by the Account Issuer and sent to the personal communication device of the Account Owner when a Physical Transaction is initiated on the Physical Account of the Account Owner and the Account Issuer receives the AAI and verifies its validity. The AuSM message shifts Authorisation of the Transaction to the Account Owner, who is going to be the immediate victim of any fraudulent A*ion taken on the said Physical Account. By

Figure 6b shows the fields contained in an AuSM message. These are: Account

Issuer name Plato, Account type Gal, Transaction ID 5a3, Message asking permission to authorise transaction 5a4 and Expected ARM Instructions 5a6.

Optional fields that can be added include: Date & Time of Attempted access 6a2,

Comments Ball. The structure is as follows: <Account_Issuer_name> + <Account_type> + <Transaction_ID> + <Message_asking_permission_to_authorise_transaction> + <Expected_ARM_instructions> [ + <Date_&_Time_of_attempted_access> [ + <Comments>]] Held halo contains information identifying the name of the Account Issuer. An example could be "This message is from YourCompany Ad".

Field Gal: contains information identifying what kind of Physical Account the

Account Owner holds with the Account issuer. An example could be "Your company's intranet account-.

field 5a3 contains information specifying the Transaction ID. The Transaction

day and is not necessarily generated in a sequential order. An example could be "Transaction ID is 202.

Field 5a4 is the Authorisation shift part of the message. The Account Issuer

asks the Account Owner what Action to take on the Transaction. An example could be "How do you want to proceed with this transactions.

Field 5a6 contains information and instructions to the Account Owner on what

the ARM message can contain. These instructions indude how the Account Owner is to communicate the ARM message back to the Account Issuer, what types of Actions are expected and what other information the Account Owner needs to include to enable the Account Issuer to verify his/her identity and act on his/her behalf. The Action types allowed are either one of Approve or Block.

An example could be "Reply with Approve or Block followed by the Transaction ID and your Personal PIN number-. The "Approve. or "Block" words denote the type of Action the Account Owner is allowed to take on his/her Account at this stage, namely Approve or Block Action respectively.

À Optional field 6a2 is a timestamp of the Transaction indicating when the

attempt to access the Physical Account was initiated. An example could be "Date 15/12/200214 04.

Optional field Ball contains additional information that the Account Issuer

finds useful to convey to the Account Owner. An example could be "We will assume you do not authorise access to your account if we don't get a response in 5 minutes".

AuSM message more user-friendly and readable. An actual example of an AuSM message could be: "This message is from YourCompany Ad concerning your company's intranet account. Transaction ID is 202. How do you want to proceed with the attempted access on 15/12/2002 14:047 Reply with Block or Approve. We will assume you do not authorise this access if we don't get a response in 5 minutes."

ii. ARM messages The ARM message for Physical Accounts is generated by the Account Owner once the Account Owner receives an AuSM message on his/her personal communication device. The Account Owner uses his/her personal communication device to send the ARM message to the Account Issuer. The ARM message shifts Authorisation of the Transaction back to the Account Issuer and the Account Issuer acts on the Transaction as instructed by the Account Owner. The Account Issuer does not take

into account any ARM messages received that do not have a corresponding AuSM message. Figure 5b shows the fields contained in an ARM message. These are: Transac*ion ID

5a3, Action type 5bl and Personal PIN Number 5b2. The structure is as follows: <Transaction_ID> + <Action_type> + <Personai_PIN_number> Field 5a3 is the same Transaction ID that was sent in the corresponding AuSM

message. Following the example of the AuSM message in (i) above, this should be"202.

field 5bl is one of the Action Types instructed in the corresponding AuSM

message, specifying to the Account Issuer what Action to take on the Transaction. Following the example of the AuSM message in (i) above, this should be either of Approve" or "Block" for Approve Action or Block Action respectively. Equally, it could be any other pre-agreed word or letter such as "A" instead of "Approve" or "B" instead of "Block".

Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalize a Transaction on the Account of the Account Owner. An example could be "6765n.

of an ARM message could be: "202 A 6765-

instructing the Account Issuer to Approve the Transaction (i.e. grant access) for the corresponding AuSM message with Transaction ID "202n.

iii. ASM messages The Account Owner can create and send an ASM message to me Account Issuer at any time, using his/her personal communication device, to either set or get the status of his/her Physical Account.

81, Status Action command 82 and Personal PIN Number 5b2. The structure is as follows: <Account_Number> + <Status_A*ion_command> + <Personal_PIN_Number> Held 81 identifies the Account that the status Action is to be applied on. It can be the number or the name that identifies the Account. An example could be -069315.

À Field 82 identifies the Action to be applied on the Account. The allowed actions

are any of Pause, Activate, Lock or Unlock Action.

Examples using a Pause Action: "Pause" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) until an Activate Action is issued; Pause until 23:00" causing the Account Issuer to operate on the Account normally from the time the ASM message is sent until 23:00 o'clock and then automatically Activate the Account again (i. e. start Authorisation shifts); Pause from 09:00 to 16:00" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) from 09:00 o'clock until 23:00 o'clock and then automatically Activate the Account again (i.e. start Authorisation shifts); "Pause from 09:00 to 23:00 repeat" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) from 09:00 o'clock until 23:00 o'clock and then automatically Activate the Account again (i.e. start Authorisation shifts), repeating the same action automatically every day; "Pause 23/11/2002" causing the Account Issuer to operate on the Account normally (i.e. no Authorisation shifts) all day on the Woof November

2002 and then automatically A*ivate the Account again (i.e. start Authorisation shifts) at the beginning of 24eh November 2002.

Example using an A*ivate Action: "Activate" causing a Paused Account to activate. The command is ignored if the account is not Paused or if the account is Locked (if the Account is Locked, a message is sent to the personal communication device of the Account Owner informing of the fa*).

Example using a Lock A*ion: "Lock" causing the Account to Lock until an Unlock command is issued.

Example using an Unlock A*ion: "Unlock" causing a Locked Account to A*ivate. À held 5b2 is a fixed 4-digit number assigned to each Account Owner by the Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN Number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalize a Transa*ion on the Account of the Account Owner. An example could be -7185.

Spaces and commas (,) are used between each field to distinguish between them.

An actual example of an ASH message could be: "069315, pause until 23:00, 7185" instructing the Account Issuer to pause the company's intranet Account 069315 until 23:00 of current day and then automatically A*ivate it again.

d. When the ARM message is not received or when the ARM is received and is wrong Figure 7 shows the Account Issuer waiting to receive the ARM message 71. If the ARM message is not received yet 72 and the Timeout period is not yet expired 73, the Account Issuer keeps waiting to receive the ARM message 71. When the ARM message is not received 72 and the timeout period expires 73, the Account Issuer Blocks the Transa*ion 25, notifies the Account Owner 74 with a message to his/her personal communication device and registers the Transaction Block details 75. If the ARM message is received 72 and is corre* 76 the process continues to Check ARM 31. If the ARM message is not corre* 76 and the ARM message is received less than three times 77, the Account Issuer asks for the ARM message again (by sending another AuSM message 78 to the personal communication device of the Account Owner) and waits to receive the ARM message 71. If the ARM message is received and is not comet 76 for the third time 77, the Account Issuer Blocks the Transa*ion 25, notifies the Account Owner with a message to his/her personal communication device 74 and registers the Transa*ion Block details 75.

In the case where the ARM message is wrongly received for three times by the Account Issuer, the Account Issuer can automatically Lock the Account of the Account Owner to prevent from further possible fraudulent A*ions on the said Account, for a specified period of time (e.g. 2 hours) after which the Account will automatically Unlock. If the Account Issuer chooses to take this A*ion (i.e. Lock the said Account), then the Account Issuer notifies the Account Owner with a message to the personal communication device of the Account Owner. In the case where the Account Owner receives such a message (i.e. notifying that his/her Account is Locked for a specified period of time), the Account Owner can send an ASM message at any time to Unlock the said Account. The message sent by the Account Issuer to the personal communication device of the Account Owner notifying of the temporary Lock Action on the Account Owners Account could look something like this: 'This message is from Account_Issuer_Name. Your account with number 94586358583 has been temporarily locked because fraudulent attempts to access it have been detected. Your account will automatically unlock in two hours. On the meantime, you can unlock your account at any time."

4. Data requirements by the Account Issuer For the invention to work, the Account Issuer has to hold and maintain certain data. The volume and kind of data varies slightly depending on the type of Account (Financial, Online, Physical) that the invention is applied at. The description of the data requirements

is broken down into three parts, one for each Account type.

Notes: The sequence of the fields shown in each of the tables that the Account Issuer

holds in its database is not necessarily restricted to the sequence shown. The sequence can be decided upon by the Account Issuer in any manner that the Account Issuer finds convenient and is comfortable with.

The names of the fields are shown in a meaningful manner for simplifying the

description of the invention; they do not necessarily have to be named in such

a way.

a. Data requirements for Financial Accounts The Account Issuer of the Financial Account needs to hold three tables in its database, one for maintaining necessary information about the Account Owner, another to enable the invention to function and a third one (which is optional) for logging failed transactions.

Figure 10a shows the fields that are required for maintaining information about the

Account Owner. These are: Account number 10al, Subscriber 10a2, Personal PIN number 5b2, Account status 10a3, Pause date 10a4, Pause time 10a5, Activate date 10a6, Activate time 10a7, Repeat pause/activate 10a8, Divert contact details 10a9, Transactions remaining on divert guano, Amount remaining on divert 10all, Divert margin amount 10al2, Amount threshold for authorization shift 10al3, Transactions threshold for authorization shift 10al4, Transactions executed today 10al5 and Account owner's communication device details 10al6. The structure of the table is as follows: <Account_number> + cSubscriber> + cPersonal_PIN_number> + <Account_status> + <Pause_date> + <Pause_time> + <Activate_date> + <Activate_time> + cRepeat_pause_activate> + cDivert_contact_details> + <Transactions_remaining_on_divert> + cAmount_remaining_on_divert> + <Divert_margin_amount> + <Amount_threshold for_authorisation_shift> + <Transactions_threshold_for_authorisation_shift> + <Transactions_executed_today> + <Account_owner's_communication_device_details> Field 10al is the full Financial Account number of the Account Owner. This is

used to distinguish between Account Owners.

Field 10a2 is the field that determines whether the Account Owner is a

subscriber to the invention's service (or wants to use the service) or whether the Account Owner chooses to opt out from the service. The values of this field

can be either "Yes. or "No-. If "Yes, it means the Account Owner willreceive an AuSM message on his/her personal communication device for every Transaction initiated on his/her Account. If "No-, it means the Account Owner is not using the service, so no Authorisation shifts will be taking place.

Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalise a Transaction on the Account of the Account Owner. An example could be "2408.

Field 10a3 indicates at which state the Account is. It can be eitherOK,

"Locked, "Paused" or Diverted-.

If "OK-, the Account Issuer will send an AuSM message to the Account Owner before finalizing any Transaction on the said Account. This field can only have

the value OK" if the Subscriber field 10a2 has the value "Yes-, otherwise it is

kept empty.

If "Locked", the Account Issuer will automatically Block any Transaction on the Account Owner's Account without notifying the Account Owner. This field can

only have the value Locked" if the Subscriber field 10a2 has the value Yes",

otherwise it is kept empty.

If "Paused-, no Authorisation shifts will take place, i.e. no AuSM messages will be sent to the personal communication device of the Account Owner; instead, the Account Issuer will finalize Transactions as if the invention is not in place.

This field can only have the value "Paused" if the Subscriber field 10a2 has the

value "Yes-, otherwise it is kept empty.

If "Diverted-, no Authorisation shifts will be sent to the personal communication device of the Account Owner; instead Authorisation shifts will be sent to the person that has the personal communication device with the number (or email) specified in the Divert conta* details field 10a9. This field

(lOa3) can only have the value "Diverted" if the Subscriber field 10a2 has the

value "Yes, otherwise it is kept empty.

Field 10a4 specifies which date the Account will Pause. An example could be

"22/1V2002. This field can only have a value if the Account status field 10a3

has a value of "Paused" or if the Repeat pause/activate field 10a8 has a value

of "Yes-, otherwise it is kept empty.

Field 10a5 specifies which time the Account will Pause. An example could be

"23:00. This field can only have a value if the Account status field 10a3 has a

value of "Paused" or if the Repeat pause/a*ivate field 10a8 has a value of

"Yes-, otherwise it is kept empty.

Field 10a6 specifies which date the Account will A*ivate. An example could be

"23/11/2002'. This field can only have a value if either of the Pause date field

10a4 or Pause time field 10a5 have a value, otherwise it is kept empty.

Field 10a7 specifies which time the Account will Activate. An example could be

"09:00'. This field can only have a value if the Pause time field 10aS has a

value, otherwise it is kept empty. If the value of this field is smaller (i.e. earlier

time) than the value of the Pause time 10a5 field, then the time of the next

calendar day is evaluated.

Field 10a8 specifies whether a previously set Pause and A*ivate activity

involving fields Pause date 10a4, Pause time 10a5, Activate date 10a6 and

A*ivate time 10a7, is to be repeated automatically. It can be either "Yes" (for repeating) or "No" (for not repeating). This field can only have a value if either

of the following combinations is true: Pause date 10a4 and either of Activate date 10a6 or Activate time 10a7 not empty, or Pause time 10a5 and either of A*ivate date 10a6 or A*ivate time 10a7 not empty or Pause date 10a4, Pause time 10a5, A*ivate date 10a6 and A*ivate time 10a7 not empty; otherwise it is kept empty.

Field 10a9 specifies the number or email of the personal communication device

of the person (other than the Account Owner) to whom any Authorisation shifts will be communicated. This field can only have a value if the Account status

field 10a3 has a value of Diverted', otherwise it is kept empty.

Field 10alO specifies the number of transactions that remain to be executed on

the Account of the Account Owner before the previously issued Divert A*ion switches back to the Account Owner again. The value of this field can be set

when the Divert A*ion is issued by the Account Owner. Every time a Transaction is executed on the said Account, this number is reduced by 1 until it becomes -0. Once it becomes ^0-, the value of the Account status field 10a3

automatically becomes OK-, but only if the value of the Amount remaining on divert field 10all is either of -0', less than the value of Divert margin amount

field 10al2 or negative. This field can only have a value if the Account status

field 10a3 has a value of"Diverted", otherwise it is kept empty.

held 10all specifies me amount of money that remain to be spent on the Account of me Account Owner before me previously issued Divert Action switches back to the Account Owner again. The value of this field can be set

when the Divert A*ion is issued by the Account Owner. Every time a Transaction is executed on the said Account, mis value is reduced by the Transaction amount 5a2 until it becomes either -0" or less (or equal) than the

value specified in the Divert margin amount field 10al2 or negative but less

(or equal) than the negation value of the Divert margin amount field 10al2.

Once these said conditions are met, the value of the Account status field 10a3

automatically becomes POKE, but only if the value of the Transactions remaining on divert field 10alO is "0. For example, assuming the value of

Transactions remaining on divert field is -0- and the value of Divert margin

amount 10al2 is -10-, if this field has a value of -120 then: if the Transaction

amount 5a2 is "120-, this field becomes -0" and the value of Account status

field 10a3 becomes OK-; if the Transaction amount 5a2 is anywhere between

U110" and "119.99-, this field becomes 120 minus the value of the Transaction

amount 5a2 and the value of Account status field 10a3 becomes "OK-; if the

Transaction amount 5a2 is anywhere between -120.01 to -129.99-, this field

becomes 120 minus the value of the Transaction amount 5a2 and the value of Account status field 10a3 becomes "OK; if the Transaction amount 5a2 is

anywhere outside the previously given margins, the Transaction is automatically rejected and the Account Issuer notifies the person to whom the Divert Action is applied accordingly. This field can only have a value if the

value of the Account status field 10a3 is "Diverted", otherwise it is kept empty.

Reld 10al2 specifies the amount by which the value in the Amount remaining on divert field 10all can fluctuate. This field can only have a value if the value

of the Amount remaining on divert field 1011 has a value, otherwise it is kept

empty. Field 10al3 specifies the amount which the Transaction amount has to exceed

before an Authorisation shift is issued to the Account Owner. If the Transaction amount 5a2 is less or equal to the value in this field, then the Account Issuer

finalizes the Transaction as usual, without notifying the Account Owner. The value of this field can be set by the Account Owner at any time by issuing an

ASM message.

Field 10al4 specifies the number of Transactions for the day that have to be

executed on the Account Owner's Account before the Account Issuer starts sending Authorisation shifts to the Account Owner. The value of this field is

checked against the value of the Transactions executed today field 10al5.

When the values in these two fields are the same, then me Account Issuer will

start sending Authorisation shifts to the Account Owner before finalising a Transaction on the Account Owner's Account. The value of this field can be set

by the Account Owner at any time by issuing an ASH message.

Held 10al5 holds the number of Transactions executed for the day on the Account of the Account Owner. Every time a Transaction is executed, the value of this field is incremented by 1. The value of this field is initialised at the

beginning of each day.

Field 10al6 holds the details of the personal communication device of the

Account Owner to enable the Account Issuer to divert any required AuSM messages to the Account Owner.

Figure 10b shows the fields that are required for enabling the invention to function.

A new record is created in this table for every Transaction on each Account. The fields in this table are used by the Account Issuer to check against the response

received from the Account Owner in the ARM message. The fields are: Account

number 10al, IP Address 10bl, Session based password 10b2, Session expiry date 10b3 and Transaction ID 5a3. The structure of the table is as follows: <Account_number> + cIP_Address> + <Session_basedassword> + <Session_expiry_date> + <Transaction_ID> Field 10al is the full hnandal Account number of the Account Owner. This is

used to distinguish between Account Owners.

held 10bl is the Intemet IP Address from the where the Transaction was initiated in the case of an online Financial Transaction. The IP Address is attached in the Authorisation request file sent to the Account Issuer by the online Merchant. Whether the Account Issuer receives an IP Address or not, depends on the way/manner that the invention is implemented. If me Account Issuer does not receive an IP Address in the Authorisation request file received by the Merchant, then the Account Issuer does not generate a value for the

Session based password field 10b2 and expects the ARM message to come

through the personal communication device of the Account Owner. If the Account Issuer receives an IP Address in the Authorisation request file sent to the Account Issuer by the Merchant, then the Account Issuer generates a value for the Session based password field 10b2, sends it to the personal

communication device of the Account Owner through the AuSM message and at the same time (the Account Issuer) establishes a dire* communication over the internet with the Account Owner asking the Account Owner to enter the Session based password value received on his/her personal communication device, in a field on the popup window which the Account Issuer shows on the

monitor of the computer system from which the Transa*ion was initiated. In this latter case, the value of the password received from the Account Owner is checked against the generated value in the Session based password field 10b2

for equality. Only when the two values are equal, the Transa*ion is Approved.

This is a means of both an Authorisation shift and identity verification. More on this in section 5 of the description, putting it all together.

held 10b2 is a randomly generated, session based password that the Account Issuer generates and sends to the personal communication device of the Account Owner when the Account Issuer receives the IP Address of where the Transa*ion is initiated, otherwise this field remains empty. A new value is

generated for this field for every new Transa*ion. Any attempt to use a

previously generated value of this field will be useless because the value

expires. More on this in section 5 of the description, "PuKing it all together".

Field 10b3 holds the expiry date and time before which the Account Issuer

must get a response from the Account Owner to be able to Approve a Transa*ion. If the IP Address is known, the ARM message is expected over the Intemet and it has to be equal to the value in the Session based password field

10b2 which is generated by the Account Issuer before the AuSM message is sent to the communication device of the Account Owner. If the IP Address is not known the ARM message is expected through the personal communication device of the Account Owner. If the ARM message is not received by the Account Owner before the expiry date and time denoted in mis field the

Account Issuer Blocks the Transa*ion. If the ARM message is received within the timeframe specified by the value of this field, the Account Issuer does one

of the following: if the IP Address is known, the response over the internet is checked against the value in the Session based password field 10b2 and if the

two are the same, the Transac*ion is Approved, otherwise the Transa*ion is Blocked; if the IP Address is not known, which means the response is received through the personal communication device of the Account Owner, the Account Issuer Approves the Transa*ion if the value of the Transa*ion ID field 5a3 in

the ARM message is the same as the one generated and kept in the Transaction ID field in the table and the value of the Personal PIN number

received is the same as the value in the Personal PIN number 5b2 field;

otherwise the Transa*ion is Blocked.

Field 5a3 is the Transaction ID sent in the AuSM message by the Account

Issuer to the personal communication device of the Account Owner. An example could be "043.

Figure 10c shows the fields that are required to log failed Transactions. A new record

is created on this table for every Blocked, Expired or Cancelled Transa*ion on each Account. This information is optional but useful to maintain for statistical and other purposes. The fields are: Account number 10al, Failure reason loci, Date 10c2,

Time 10c3, Transa*ion Amount 5a2, Merchant name 5a9 and Transa*ion ID 5a3.

The structure of the table is as follows: <Account_number> + <Failure_reason> + <Date> + <nme> + <Transaction_amount> + <Merchant_name> + <Transa*ion_lD> Field 10al is the full Financial Account number of the Account Owner. This is

used to distinguish between Account Owners.

Field loci holds the reason of the failure. It can have either of the following

values: unbacked-, "Cancelled-, "Expired. The value "Blocked. indicates that the Transa*ion was Blocked by the Account Owner, the value "Cancelled"

indicates that the Transa*ion was Cancelled by the Account Owner and the value "Expired" indicates that no response was received from the Account Owner and the Account Issuer Blocked the Transa*ion.

Field 10c2 holds the date of when the Transaction failed.

Field 10c3 holds the time of when the Transa*ion failed.

Field 5a2 holds the Transa*ion amount of the failed Transa*ion.

field 5a9 holds the name of the Merchant from which the goods or services

were to be bought.

Held 5a3 holds the generated Transa*ion ID of the Transa*ion.

b. Data requirements for Online Accounts The Account Issuer of the Online Account needs to hold three tables in its database, one for maintaining necessary information about the Account Owner, another to enable the invention to function and a third one (which is optional) for logging failed transactions. Figure 11a shows me fields that are required for maintaining information about the

Account Owner. These are: Account ID 11al, Subscriber 10a2, Personal PIN number 5b2, Account status 10a3, Pause date 10a4, Pause time 10a5, Activate date 10a6, Activate time 10a7, Repeat pause/a*ivate 10a8 and Account Owner's communication device details 10al6. The structure of the table is as follows: <Account_ID> + <Subscriber> + <Personal_PIN_number> + <Account_status> + Pause_date> + <Pause_time> + <Activate_date> + <Activate_time> + <Repeat_pause_a*ivate> + cAccount_owner's_communication_device_details> Field 11al is the full Online Account ID of the Account Owner. It can be a

number or a username. This is used to distinguish between Account Owners.

Field 10a2 is the field that determines whether the Account Owner is a

subscriber to the invention's service (or wants to use the service) or whether the Account Owner chooses to opt out from the service. me values of this field

can be either Yes" or "No-. If "Yes-, it means the Account Owner will receive an AuSM message on his/her personal communication device for every Transa*ion initiated on his/her Account. If "No' it means the Account Owner is not using the service, so no Authorisation shifts will be taking place.

Field 5b2 is a fixed 4-digit number assigned to each Account Owner by the

Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalize a Transaction on the Account of the Account Owner. An example could be "2408.

Field 10a3 indicates at which state the Account is. It can be either "OK",

"Locked" or "Paused".

If "OK-, the Account Issuer will send an AuSM message to the Account Owner before finalising any Transa*ion on the said Account. This field can only have

the value "OK" if the Subscriber field 10a2 has the value Yes", otherwise it is

kept empty.

If "Locked, the Account Issuer will automatically Block any Transaction on the Account Owner's Account without notifying the Account Owner. This field can

only have the value "Locked" if the Subscriber field 10a2 has the value Yes",

otherwise it is kept empty.

If "Paused", no Authorisation shifts will take place, i.e. no AuSM messages will be sent to the personal communication device of the Account Owner; instead, the Account Issuer will finalize Transactions as if the invention is not in place.

mis field can only have the value "Paused. if the Subscriber field 10a2 has the

value Yes-, otherwise it is kept empty.

Field 10a4 specifies which date the Account will Pause. An example could be

"22/11/2002n. This field can only have a value if the Account status field 10a3

has a value of "Paused. or if the Repeat pause/activate field 10a8 has a value

of Yes-, otherwise it is kept empty.

Field 10a5 specifies which time the Account will Pause. An example could be

23:00n. mis field can only have a value if the Account status field 10a3 has a

value of "Paused" or if the Repeat pause/activate field 10a8 has a value of

Yes", otherwise it is kept empty.

Field 10a6 specifies which date the Account will Activate. An example could be

-23/1V2002n. This field can only have a value if either of the Pause date field

10a4 or Pause time field 10a5 have a value, otherwise it is kept empty.

Field 10a7 specifies which time the Account will Activate. An example could be

"og:00n. This field can only have a value if the Pause time field 10a5 has a

time) than the value of the Pause time 10a5 field, then the time of the next

calendar day is evaluated.

Field 10a8 specifies whether a previously set Pause and Acitvate activity

involving fields Pause date 10a4, Pause time 10a5, Activate date 10a6 and

Activate time 10a7, is to be repeated automatically. It can be either "Yes" (for repeating) or "No" (for not repeating). This field can only have a value if either

of the following combinations is true: Pause date 10a4 and either of Activate date 10a6 or Activate time 10a7 not empty, or Pause time 10a5 and either of Activate date 10a6 or Activate time 10a7 not empty or Pause date 10a4, Pause time 10a5, Activate date 10a6 and Activate time 10a7 not empty; otherwise it is kept empty.

Figure 11b shows the fields that are required for enabling the invention to function.

received from the Account Owner in the ARM message. The fields are: Account ID

11al, IP Address 10bl, Session based password 10b2, Session expiry date 10b3 and Transaction ID 5a3. The structure of the table is as follows: <Account_ ID> + <IP_ Address> + <Session_based_password> + <Session_expiry_date> + <Transaction_ID> Field 11al is the full Online Account ID of the Account Owner. It can be a

number or a username. This is used to distinguish between Account Owners.

Feld 10bl is the Internet IP Address from the where the Transaction was initiated. The IP Address is known to the Account Issuer since a direct communication link is established between the Account Issuer and the Account Owner. Whether the Account Issuer uses the IP Address or not, depends on the way/manner that the invention is implemented. If the Account Issuer does not want to use the IP Address in the implementation of the invention, then the Account Issuer does not generate a value for the Session based password field 10b2 and expects the ARM message to come through the personal

communication device of the Account Owner. If the Account Issuer wants to use the IP Address, then the Account Issuer generates a value for the Session based password field 10b2, sends it to the personal communication device of

the Account Owner through the AuSM message and at the same time (the Account Issuer) uses the direct communication over the internet with the Account Owner asking the Account Owner to enter the Session based password value received on his/her personal communicaffon device, in a field on the

popup window which the Account Issuer shows on the monitor of the computer system from which the Transaction was initiated. In this latter case, the value of the password received from the Account Owner is checked against the generated value in the Session based password field 10b2 for equality. Only

when the two values are equal, the Transaction is Approved. This is a means of both an Authorisation shift and identity verification. More on this in section 5 of the description, "Putting it all together'.

Field 10b2 is a randomly generated, session based password that the Account

Issuer generates and sends to the personal communication device of the Account Owner when the Account Issuer wants to use the IP Address of where

the Transaction is initiated, otherwise this field remains empty. A new value is

* generated for this field for every new Transaction. Any attempt to use a

previously generated value of this field will be useless because the value

expires. More on this in section 5 of the description, ''Putting it all together".

Reld 10b3 holds the expiry date and time before which the Account Issuer must get a response from the Account Owner to be able to Approve a Transaction. If the IP Address is used, the ARM message is expected over the Intemet and it has to be equal to the value in the Session based password field

10b2 which is generated by the Account Issuer before the AuSM message is sent to the communication device of the Account Owner. If the IP Address is not used, the ARM message is expected through the personal communication device of the Account Owner. If the ARM message is not received by the Account Owner before the expiry date and time denoted in this field the

Account Issuer Blocks the Transaction. If the ARM message is received within the timeframe specified by the value of this field, the Account Issuer does one

of the following: if the IP Address is used, the response over the internet is checked against the value in the Session based password field 10b2 and if the

two are me same, the Transaction is Approved, otherwise the Transaction is Blocked; if the IP Address is not used, which means the response is received through the personal communication device of the Account Owner, the Account Issuer Approves the Transaction if the value of the Transaction ID field 5a3 in

received is the same as the value in the Personal PIN number 5b2 field;

otherwise the Transaction is Blocked.

Reld 5a3 is the Transaction ID sent in the AuSM message by the Account Issuer to the personal communication device of the Account Owner. An example could be "043n.

Figure TIC shows the fields that are required to log failed Transactions. A new record

is created on this table for every Blocked or Expired Transaction on each Account.

This information is optional but useful to maintain for statistical and other purposes.

The fields are: Account ID 11al, Failure reason loci, Date 10c2, Time 10c3 and

Transaction ID 5a3. The structure of the table is as follows: <Account_number> + <Failure_reason> + <Date> + <Time> + <Transaction_ID> Field 11al is the full Online Account ID of the Account Owner. It can be a

number or a username. This is used to distinguish between Account Owners.

Field loci holds the reason of the failure. It can have either of the following

values: "Blocked" or Expired. The value "Blocked" indicates that the Transaction was Blocked by the Account Owner and the value "Expired" indicates that no response was received from the Account Owner and the Account Issuer Blocked the Transaction.

Reld 10c2 holds the date of when the Transaction failed.

Field 10c3 holds the time of when the Transaction failed.

Field 5a3 holds the generated Transaction ID of the Transaction.

c. Data requirements for Physical Accounts The Account Issuer of the Physical Account needs to hold three tables in its database, one for maintaining necessary information about the Account Owner, another to enable the invention to function and a third one (which is optional) for logging failed transactions.

Figure 11a shows the fields that are required for maintaining information about the

Account Owner. These are: Account ID 11al, Subscriber 10a2, Personal PIN number 5b2, Account status 10a3, Pause date 10a4, Pause time 10a5, Activate date 10a6, Activate time 10a7, Repeat pause/activate 10a8 and Account Owner's communication device details 10al6. The structure of the table is as follows:

<Account_ID> + <Subscriber> + <Personal_PIN_number> + <Account_status> + <Pause_date> + <Pause_time> + <Activate_date> + <Activate_time> + <Repeat_pause_activate> + <Account_owner's_communication_device_details> Field 11al is the full Online Account ID of the Account Owner. It can be a

number or a usemame. This is used to distinguish between Account Owners.

Field 10a2 is the field that determines whether the Account Owner is a

can be either Yes" or "No-. If "Yes, it means the Account Owner will receive an AuSM message on his/her personal Communication device for every Transaction initiated on his/her Account. If "No-, it means the Account Owner is not using the service, so no Authorisation shifts will be taking place.

Held 5b2 is a fixed 4-digit number assigned to each Account Owner by the Account Issuer (or chosen by the Account Owner), when registering for using the service. The Personal PIN number is used for additional security to prevent someone that steals the AAI and the personal communication device of the Account Owner from using it to finalise a Transaction on the Account of the Account Owner. An example could be "2408".

Field 10a3 indicates at which state the Account is. It can be either POKE,

"Locked" or Paused-.

If "OK", the Account Issuer will send an AuSM message to the Account Owner before finalizing any Transaction on the said Account. This field can only have

the value "OK" if the Subscriber field 10a2 has the value Yes-, omerwise it is

kept empty. If "Locked, the Account Issuer will automatically Block any Transaction on

the Account Owner's Account without notifying the Account Owner. miS field can

only have the value Locked" if the Subscriber field 10a2 has the value "Yes'

otherwise it is kept empty.

If "Paused-, no Authorisation shifts will take place, i.e. no AuSM messages will be sent to the personal communication device of the Account Owner; instead, the Account Issuer will finalist Transactions as if the invention is not in place.

mis field can only have the value "Paused" if the Subscriber field 10a2 has the

value "Yes, otherwise it is kept empty.

Field 10a4 specifies which date the Account will Pause. An example could be

22/1V2002. This field can only have a value if the Account status field 10a3

has a value of "Paused" or if the Repeat pause/activate field 10a8 has a value

of "Yes-, otherwise it is kept empty.

Field 10a5 specifies which time the Account will Pause. An example could be

23:00n. This field can only have a value if the Account status field 10a3 has a

value of "Paused" or if the Repeat pause/activate field 10a8 has a value of

"Yes' otherwise it is kept empty.

held 10a6 specifies which date the Account will Activate. An example could be 23/1V2002. mis field can only have a value if either of the Pause date field

10a4 or Pause time field 10a5 have a value, otherwise it is kept empty.

Field 10a7 specifies which time the Account will Activate. An example could be

"09:00. mis field can only have a value if the Pause time field 10a5 has a

value, otherwise it is kept empty. If the value of miS field is smaller (i.e. earlier

time) than the value of the Pause time 10a5 field, then the time of the next

calendar day is evaluated.

Held 10a8 specifies whether a previously set Pause and Activate activity involving fields Pause date 10a4, Pause time 10a5, A*ivate date 10a6 and

Activate time 10a7, is to be repeated automatically. It can be either Yes" (for repeating) or "No" (for not repeating). mis field can only have a value if either

of the following combinations is true: Pause date 10a4 and either of Activate date 10a6 or Activate time 10a7 not empty, or Pause time 10a5 and either of Activate date 10a6 or A*ivate time 10a7 not empty or Pause date 10a4, Pause time 10a5, A*ivate date 10a6 and A*ivate time 10a7 not empty; otherwise it is kept empty.

Figure 12 shows the fields that are required for enabling the invention to function. A

new record is created in this table for every Transaction on each Account. The fields

in this table are used by the Account Issuer to check against the response received from the Account Owner in the ARM message. The fields are: Account ID 11al,

Session expiry date 10b3 and Transaction ID 5a3. The structure of the table is as follows: <Account_ID> + <Session_expiry_date> + <Transaction_ID> Field 11al is the full Online Account ID of the Account Owner. It can be a

number or a usemame. This is used to distinguish between Account Owners.

held 10b3 holds the expiry date and time before which the Account Issuer must get a response from the Account Owner to be able to Approve a Transaction. If the ARM message is not received by the Account Owner before the expiry date and time denoted in this field, the Account Issuer Blocks the

Transaction. If the ARM message is received within the timeframe specified by the value of this field, the Account Issuer Approves the Transaction if the value

of the Transaction ID 5a3 in the ARM message is the same as the one generated and kept in the Transaction ID field 5a3 in the table and the value of

the Personal PIN number received is the same as the value in the Personal PIN number 5b2 field; otherwise the Transaction is Blocked.

Field 5a3 is the Transaction ID sent in the AuSM message by the Account

Figure lie shows the fields that are required to log failed Transactions. A new record

The fields are: Account ID 11al, Failure reason loci, Date 10c2, Rme 10c3 and

Transaction ID 5a3. me structure of the table is as follows: <Account_number> + <Failure_reason> + <Date> + <name> + <Transa*ioQID> À Field 11al is the full Online Account ID of the Account Owner. It can be a

number or a username. This is used to distinguish between Account Owners.

Field loci holds the reason of the failure. It can have either of the following

Field 10c2 holds the date of when the Transaction failed.

Field 10c3 holds the time of when the Transaction failed.

Field 5a3 holds the generated Transaction ID of the Transaction.

5. Putting it all together The system and method behind this invention can either be implemented only on the Account Issuer's systems or the major part of it on the Account Issuer's systems and a very small part of it on the merchant's systems. None of the two cases changes the internal structure of the computer systems of either the Account Issuer or merchant.

If the system is implemented only next to the Account Issuer's systems, then no Internet IP Addresses Will be used at any time for any of the Account types. This means that all ARM messages have to be received through the 2-way communication network from the personal communication device of the Account Owner.

If the system is implemented next to the Account Issuer's systems and a part of it implemented next to the systems of the merchant, then the Intemet IP Address can be retrieved and used in the AuSM messages sent by the Account Issuer to the personal communication device of the Account Owner. This means that in the cases of online Financial Transactions and Online Transactions, the Account Owner is expected to enter the password 5a5 contained in the AuSM message, in a popup window that the Account

Issuer shows on the screen of the Account Owner's computer system to a* as both the ARM message and also as an identity verification to the Account Issuer.

The acquisition, by the Account Issuer, of the Intemet IP Address that specifies where the Transaction was initiated From, in the case of online Financial Transactions is achieved as follows: before the merchant sends the authorization request file (such a file can be the ISO8583 file) to the Account Issuer through the normal channels, the part of the system that sits next to the computer systems of the merchant takes the authorization request file and attaches to it the IP Address that specifies the coordinates on the intemet From where the Transa*ion was initiated. This is possible because a dire* connection is established between the person contacting the Transaction and the computer systems of the merchant. Once the invention's system attaches the IP Address to the authorization request file, the merchant continues as normal and forwards the authorization request file through me normal channels, to be received by the Account Issuer.

The acquisition, by the Account Issuer, of the Intemet IP Address that specifies where the Transaction was initiated from, in the case of Online Transactions is almost always known because the Account Owner of an Online Account has to establish a direct connection with the computer systems of the Account Issuer to be able to execute any Transactions (e.g. to log in the Account).

All the Account Owners that have an Account with an Account Issuer that uses the invention will be able to use the services that the invention offers. The invention does not change the way that Transactions are conducted. The same AAI is needed to Authorise a Transaction as before and Account Owners will keep using the same AAIM as before.

Following are specific examples of the different ways the invention can be implemented for each of the different types of accounts (Financial, Online, Physical).

a. Putting it all together For Financial Accounts Figure 3a demonstrates the flow of information when the invention is applied to either online Financial Transactions or high-street Financial Transactions. Anyone with the MI can initiate a transaction 20. The AAI is sent to the Account Issuer over the normal channels 21 until it reaches the Account Issuer. The Account Issuer receives the AAI 22 and checks for its validity 23. If the AAI is not come*, the Transa*ion is Blocked 25. If the MI is corre* (i.e. matches the information held in the computer systems of the Account Issuer), the Account Issuer generates an AuSM message 27a and communicates the said AuSM message 28a to the personal communication device of the Account Owner through the 2-way communication channel. The Account Owner receives the AuSM message 29 on his/her personal communication device. If the Transa*ion is a high-street Financial Transa*ion or an online Financial Transa*ion and the Account Issuer does not know the IP Address of where the Transa*ion was initiated, the Account Owner prepares the ARM message 27b on his/her personal communication device and communicates the decision 28b back to the Account Issuer using the 2-way communication channel that his/her personal communication device is using. If the Transa*ion is an online Financial Transa*ion and the Account Issuer knows the IP Address of where the Transaction was initiated, the Account Owner supplies the password 5a5 contained in the AuSM message 29 in the popup window that the Account Owner shows on me monitor of the computer system From where the Transa*ion was initiated and sends it through the Intemet. The Account Issuer receives the decision 30 and checks to identify what Action to take 31. If the decision is Block, the Account Issuer Blocks the Transa*ion 25; If the decision is Cancel, the Account Issuer Cancels the Transa*ion 26; If the decision is Approve or if the password received matches the password 5a5 that the Account Issuer sent in the AuSM to the personal communication device of the Account Owner, the Account Issuer Approves the Transa*ion 24.

Figure 13a shows an example of the application of the invention For a high-street Financial Transa*ion. me Account Owner (or anyone else with the AAI) gives his/her credit card (AAIM) 13a2 to the merchant who swipes it through the Point Of Sale (POS) 13a3. The merchant then, sends the authorization request file through the normal channels (acquirer & distribution channels through bank owned associations like Visas and MasterCard@) 13a4 to the Account Issuer's systems 13a5. At this stage the Account Issuer checks for the

validity of the AAI contained in the authorization request file and if the AAI is correct, the Account Issuer involves the Invention's system 13a6, passing to it the Account Owner's communication device details 10al6 along with Transaction amount 5a2 and any of the optional fields Date time of transaction 5a7, Merchant name 5a8, List of goods

purchased 5a9 and Account Issuer name 5alO. The invention's system 13a6, prepares an AuSM message using the information supplied to it by the Account Issuer's systems 13a5

Account Owner. At the same time, the Invention's main system, using the IF Address sent to it by the Account Issuer's systems 13a5, constructs and shows a Popup window (Authorisation screen) 13b2 on the screen of the computer system from where the Transaction was initiated. The Account Owner, upon receiving me AuSM message fi om the Account Issuer, has two options: if the Account Owner wants to Block or Cancel the Transaction, he/she can prepare an ARM message using his/her personal communication

merchant). The AAI is transferred through the Intemet 13b3 to the commerce server 13b4 of the merchant. The merchant then prepares the authorization request file and sends it through the normal channels (acquirer & distribution channels through bank owned associations like Visa<9 and MasterCard@) 13a4 to the Account Issuer's systems 13a5. At this stage the Account Issuer checks for the validity of the AAI contained in the authorization request file and if the AAI is corre*, the Account Issuer involves the Invention's system 13a6, passing to it the Account Owners communication device details 10al6 along with Transa*ion amount 5a2 and any of the optional fields Date & time of

transaction 5a7, Merchant name 5a8, Ust of goods purchased 5a9 and Account Issuer name halo. Upon receiving this information, the Invention's system 13a6 prepares an AuSM message using the information supplied to it by the Account Issuer's systems 13a5 and information that me Invention's system 13a6 prepares, namely Transaction ID 5a3, Message asking permission to Authorise Transac*ion 5a5, Expected ARM instructions and any Comments Ball, and sends the generated AuSM message Trough the Communication channel 28 to the personal communication device 13al of the Account Owner. The Account Owner, upon receiving the AuSM message from the Account Issuer, prepares an ARM message using his/her personal communication device 13al, by using the field Transaction

ID 5a3 received in the AuSM message and adding to it his/her decided Action (Approve, Block or Cancel Ac*ion) and his/her Personal PIN number 5b2. Then, the Account Owner sends the prepared ARM message through the 2way communication channel 28 to the invention's system 13a6. The invention's system 13a6, checks the information received from the Account Owner in the ARM message. If me ARM message received is not corre*, the Invention's system 13a6 sends the same AuSM message to the personal communication device 13al of the Account Owner through the communication channel 28 again, asking the Account Owner (using the comments field Ball) to re-supply the ARM.

The process of asking the Account Owner to re-supply the ARM message is repeated up to three times after which the Invention's system 13a6 notifies the Account Issuer's systems 13a5 to Block me Transa*ion and the Account Issuer's systems Block the Transa*ion.

Another case that causes the Invention's system 13a6 to notify the Account Issuer's systems 13a5 to Block the Transaction, is if the period allowed to receive the ARM message from the Account Owner is expired. If the ARM message received is correc*, the Invention's system 13a6 notifies the Account Issuer's systems 13a5 to act according to the Action that the Account Owner Authorised (i.e. Approve, Block or Cancel the Transa*ion) and the Account Issuer's systems act according to the Action mat the Account Owner Authorised. After finalizing the Transa*ion, the Account Issuer's systems 13a5 send the authorization response file back to the merchant's Commerce server 13b4, through the normal channels 13a4. The merchant then, notifies me person who initiated the Transaction of the Account Issuer's decision (i.e. whether the Transac*ion has been accepted, rejected or cancelled).

b. Putting it all together for Online Accounts Figure 3b demonstrates the flow of information when the invention is applied to Online Transactions. Anyone with the AAI can initiate a transaction 20. The MI is sent to the Account Issuer over the normal channels 21 until it reaches the Account Issuer. The Account Issuer receives the MI 22 and checks for its validity 23. If the MI is not correct, the Transac*ion is Blocked 25. If the AAI is correc* (i.e. matches the information held in the computer systems of the Account Issuer), the Account Issuer generates an AuSM message 27a and communicates the said AuSM message 28a to me personal communication device of the Account Owner through the 2-way communication channel.

The Account Owner receives the AuSM message 29 on his/her personal communication device. If the Account Issuer does not know the IP Address of where the Transaction was initiated, the Account Owner prepares the ARM message 27b on his/her personal communication device and communicates the decision 28b back to me Account Issuer using the 2-way communication channel that his/her personal communication device is using. If the Account Issuer knows the IP Address of where me Transa*ion was initiated, the Account Owner supplies the password 5a5 contained in the AuSM message 29 in the popup window that the Account Owner shows on the monitor of the computer system from where the Transa*ion was initiated and sends it Trough the Intemet. The Account Issuer receives the decision 30 and checks to identify what Action to take 31. If the decision is Block, the Account Issuer Blocks the Transaction 25; If the decision is Approve or if the password received matches the password 5a5 that me Account Issuer sent in the AuSM to

the personal communication device of the Account Owner, the Account Issuer Approves the Transaction 24.

Figure 14a shows an example of me application of the invention for an Online Account that uses the Intemet IF Address. The difference with the application on a Financial Account is that the invention's system only needs to sit next to the systems of the Account Issuer because, since the Account Issuer establishes a dire* connection with the person (the Account Owner or a fraudster] trvinn to execute a Transacting {- n Inn in to an Tntrnot

the two fields received (Password and Transaction ID) match the two fields generated by

the Invention's system 13a6 (namely Password for verifying identity to authorise Transaction 5a5 and Transaction ID 5a3) respectively, then the Invention's system 13a6 notifies the Account Issuer's systems 13a5 to Approve the Transaction and the Account Issuer's systems 13a5 Approve the Transaction. If the two fields received (Password and

Transaction ID) do not match the two fields Generated (namely Password for verifying

Screen 14a2 on the screen of the computer system from where the Transaction was initiated depending on the outcome of the Transaction.

c. Putting it all together for Physical Accounts Figure 3b demonstrates the flow of information when the invention is applied to Physical Transactions. Anyone with the AAI or the AAIM can initiate a transaction 20. The AAI is sent to the Account Issuer over the normal channels 21 until it reaches the Account Issuer.

The Account Issuer receives the AAI 22 and checks for its validity 23. If the AAI is not correct, the Transaction is Blocked 25. If the AAI is correct (i.e. matches the information held in the computer systems of the Account Issuer), the Account Issuer generates an AuSM message 27a and communicates the said AuSM message 28a to the personal communication device of the Account Owner through the 2-way communication channel.

The Account Owner receives the AuSM message 29 on his/her personal communication device. The Account Owner prepares the ARM message 27b on his/her personal communication device and communicates the decision 28b back to the Account Issuer using the 2-way communication channel that his/her personal communication device is using. The Account Issuer receives the decision 30 and checks to identify what Action to take 31. If the decision is Block, the Account Issuer Blocks the Transaction 25; if the decision is Approve, the Account Issuer Approves the Transaction 24.

Figure 15 shows an example of the application of the invention for a Physical Account. For this kind of implementation, the whole system of the invention has to sit next to the Account Issuer's systems. Figure 14b shows a scenario of how this is achieved: the Account Owner 151 (or anyone with the correct AAI or the AAIM) either swipes the pass card or enters the PIN number that gives access to a Secured Area 153 in a company's establishment. The information is transferred to the Account Issuer's systems 13a5. At this stage the Account Issuer checks for the validity of the AAI received and if the AAI is correct, the Account Issuer involves the Invention's system 13a6, passing to it the Account Owner's communication device details 10al6 along with the optional field Date & time of

attempted access 6a2. The Invention's system 13a6 then prepares an AuSM message using the information supplied to it by the Account Issuer's systems 13a5 (namely optional field Date & time of attempted access 6a2) and information that the Invention's system

13a6 prepares, namely Account Issuer Name Plato, Account type Gal, Transaction ID 5a3, Message asking permission to authorise transaction 5a4, Expected ARM instructions 5a6 and any Comments Ball, and sends the prepared AuSM message through the Communication channel 28 to the personal communication device 13al of the Account Owner 151. The Account Owner 151, upon receiving the AuSM message from the Account Issuer, prepares an ARM message using his/her personal communication device 13al, by using the field Transaction ID 5a3 received in the AuSM message and adding to it his/her

decided Action (Approve or Block Action) and his/her Personal PIN number 5b2, and sends the prepared ARM message to the Invention's system 13a6 through the Communication channel 28. The Invention's system 13a6, upon receiving the ARM message from the personal communication device 13al of the Account Owner, checks the ARM message for validity (i.e. Transaction ID received equal to Transaction ID 5a3 sent and Personal PIN number received equal to stored Personal PIN number 5b2). If the ARM message received is not correct, the Invention's system 13a6 sends the same AuSM message to the personal communication device 13al of the Account Owner through the communication channel 28 again, asking the Account Owner (using the Comments field Ball) to re-supply the ARM.

The process of asking the Account Owner to re-supply the ARM message is repeated up to three times after which the Invention's system 13a6 notifies the Account Issuer's systems 13a5 to Block the Transaction and the Account Issuer's systems 13a5 Block the Transaction. Another case that causes the Invention's system 13a6 to notify the Account Issuer's systems 13a5 to Block the Transaction, is if the period allowed to receive a response from the Account Owner is expired. If the two fields received (Password and

Transaction ID) match the two fields generated by the Invention's system 13a6 (namely

Password for verifying identity to authorise Transaction 5a5 and Transaction ID 5a3) respectively, then the Invention's system 13a6 notifies the Account Issuer's systems 13a5 to Approve the Transaction and the Account Issuer's systems 13a5 Approve the Transaction, i.e. give access to the Secured area 153.

Claims

1. A system and method for transferring Authorisation for a Transaction on an Account from the Account Issuer to the Account Owner, comprising the following: a communication network or channel; a messaging technology; a personal communication device compatible with the said messaging technology and capable of one-way or two-way communication; a password comprising of alphanumeric strings of text generated by the said Account Issuer; a Transac*ion ID number generated by the said Account Issuer and associated with each said Transaction; a Personal PIN Number assigned to the said Account Owner by the said Account Issuer; a predetermined timeout period of time used by the said Account Issuer to determine whether an Action On be performed on the said Account; messages that are communicated through the said communication network or channel by the computer systems of the said Account Issuer to the said personal communication device of the said Account Owner shifting the Authorisation for performing an Action on the said Account; messages that are communicated through the said communication network or channel by the use of the said personal communication device of the said Account Owner to the computer systems of the said Account Issuer shifting the Authorisation for performing an Action on the said Account.

2. The system and method of claim 1 when applied on a Financial Account to perform an online Financial Transac*ion whereas the Internet IP address from where the said online Financial Transaction was initiated is known, to comprise the steps of: the said online Financial Transaction is initiated on the said Financial Account of the Account Owner either by the authorised said Account Owner or by an unauthorized person or system; the AAI is received by the Account Issuer and the validity of the said AAI is verified by the said Account Issuer; the said Account Issuer generates an AuSM message which contains a password and the Intemet IF address from where the said online Financial Transaction was initiated and sends this said AuSM message to the personal communication device of the said Account Owner through a compatible communications network or channel shifting in this way the Authorisation to act on the said Financial Account from the said Account Issuer to the said Account Owner; the said Account Owner receives the said AuSM message on his/her said personal communication device; the said Account Owner either prepares an ARM message using his/her said personal communication device and sends the said ARM message to the said Account Issuer through the said communications network or channel to perform a Block Action or a Cancel Ac*ion on the said Financial Account, or the said Account Owner uses the said password contained in the said AuSM message and enters the said password in the popup window that appears on the screen from where the said online Financial Transac*ion was initiated and sends the information entered on the said popup window to the said Account Issuer to perform an Approval Action on the said Financial Account; if the said Account Issuer receives the said ARM message, the said Account Issuer performs a Block Ac*ion or a Cancel Ac*ion on the said Financial Account depending on the instructions contained in the said ARM message, whereas if the said Account

Issuer receives the said information entered on the said popup window, the said Account Issuer perfomms an Approval Action or a Block Action on the said Financial Account, depending on whether the said information entered on the said popup window is the same as the said password sent by the said Account Issuer to the said Account Owner.

3. The system and method of claim 1 when applied on a Financial Account to perform an online Financial Transaction whereas the Intemet IP address from where the said online Financial Transaction was initiated is not known, to comprise the steps of: the said online Financial Transaction is initiated on the said Financial Account of the Account Owner either by the authorised said Account Owner or by an unauthorized person or system; the AAI is received by the Account Issuer and the validity of the said AAI is verified by the said Account Issuer; the said Account Issuer generates an AuSM message and sends this said AuSM message to the personal communication device of the said Account Owner through a compatible communications network or channel shifting in this way the Authorisation to act on the said Financial Account from the said Account Issuer to the said Account Owner; the said Account Owner receives the said AuSM message on his/her said personal communication device; the said Account Owner prepares an ARM message using his/her said personal communication device and sends the said ARM message to the said Account Issuer through the said communications network or channel to perform a Block Action, a Cancel Action or an Approval Action on the said Financial Account; the said Account Issuer receives the said ARM message and performs a Block Action, a Cancel Action or an Approval Action on the said Financial Account depending on the instructions contained in the said ARM message.

4. The system and method of claim 1 when applied on a Financial Account to perform a high-street Financial Transaction, to comprise the steps of: the said high-street Financial Transaction is initiated on the said Financial Account of the Account Owner either by the authorised said Account Owner or by an unauthorized person or system; the MI is received by the Account Issuer and the validity of the said AAI is verified by the said Account Issuer; the said Account Issuer generates an AuSM message and sends this said AuSM message to the personal communication device of the said Account Owner through a compatible communications network or channel shifting in this way the Aumorisation to act on the said Physical Account from the said Account Issuer to the said Account Owner; the said Account Owner receives the said AuSM message on his/her said personal communication device; the said Account Owner prepares an ARM message using his/her said personal communication device and sends the said ARM message to the said Account Issuer through the said communications network or channel to perfomm a Block Action, a Cancel Action or an Approval Action on the said Financial Account; the said Account Issuer receives the said ARM message and perfomms a Block Action, a Cancel Action or an Approval Action on the said Financial Account depending on the instructions contained in the said ARM message.

5. The system and method of claim 1 when applied on an Online Account to perform an Online Transaction whereas the Internet IP address from where the said Online Transaction was initiated is known, to comprise the steps of: the said Online Transaction is initiated on the said Online Account of the Account Owner either by the authorised said Account Owner or by an unauthorized person or

system; the MI is received by the Account Issuer and the validity of the said AAI is verified by the said Account Issuer; the said Account Issuer generates an AuSM message which contains a password and the Internet IP address from where the said Online Transaction was initiated and sends this said AuSM message to the personal communication device of the said Account Owner through a compatible communications network or channel shifting in this way the Authorisation to a* on the said Online Account from the said Account Issuer to the said Account Owner; the said Account Owner receives the said AuSM message on his/her said personal communication device; the said Account Owner either prepares an ARM message using his/her said personal communication device and sends the said ARM message to the said Account Issuer through the said communications network or channel to perform a Block Action on the said Online Account, or the said Account Owner uses the said password contained in the said AuSM message and enters the said password in the popup window that appears on the screen from where the said Online Transaction was initiated and sends the information entered on the said popup window to the said Account Issuer to perform an Approval A*ion on the said Online Account; if the said Account Issuer receives the said ARM message, the said Account Issuer performs a Block Action on the said Online Account depending on the instructions contained in the said ARM message, whereas if the said Account Issuer receives the said information entered on the said popup window, me said Account Issuer performs an Approval Ac*ion or a Block Action on the said Online Account, depending on whether the said information entered on the said popup window is the same as the said password sent by the said Account Issuer to the said Account Owner.

6. The system and method of claim 1 when applied on an Online Account to perform an Online Transaction whereas the Internet IP address from where the said Online Transac*ion was initiated is not known, to comprise the steps of: the said Online Transaction is initiated on the said Online Account of the Account Owner either by the authorised said Account Owner or by an unauthorized person or system; the AAI is received by the Account Issuer and the validity of the said AAI is verified by the said Account Issuer; the said Account Issuer generates an AuSM message and sends this said AuSM message to the personal communication device of the said Account Owner through a compatible communications network or channel shifting in this way the Authorisation to a* on the said Online Account from the said Account Issuer to the said Account Owner; the said Account Owner receives the said AuSM message on his/her said personal communication device; the said Account Owner prepares an ARM message using his/her said personal communication device and sends the said ARM message to the said Account Issuer through the said communications network or channel to perform a Block Ac*ion or an Approval Action on the said Online Account; the said Account Issuer receives the said ARM message and performs a Block A*ion or an Approval A*ion on the said Online Account depending on the instructions contained in the said ARM message.

7. The system and method of claim 1 when applied on a Physical Account to perform a Physical Transaction, to comprise the steps of: the said Physical Transaction is initiated on the said Physical Account of the Account Owner either by the authorised said Account Owner or by an unauthorized person or system; the MI is received by the Account Issuer and the validity of the said AAI is verified

by the said Account Issuer; the said Account Issuer generates an AuSM message and sends this said AuSM message to the personal communication device of the said Account Owner through a compatible communications network or channel shifting in this way the Authorisation to act on the said Physical Account from the said Account Issuer to the said Account Owner; the said Account Owner receives the said AuSM message on his/her said personal communication device; the said Account Owner prepares an ARM message using his/her said personal communication device and sends the said ARM message to the said Account Issuer through the said communications network or channel to perform a Block Action or an Approval Action on the said Physical Account; the said Account Issuer receives the said ARM message and performs a Block Action or an Approval Action on the said Physical Account depending on the instructions contained in the said ARM message.

8. The method of claims 1 to 7 wherein said communications network or channel comprises of a one-way or two-way wireless telecommunications network capable of transmitting data in a format that can be processed by computer systems and in a format that can be understood by human beings.

9. The method of claims 1 to 7 wherein said communications network or channel comprises of a one-way or two-way wired telecommunications network capable of transmitting data in a format that can be processed by computer systems and in a format that can be understood by human beings.

lO.The method of claims 1 to 7 wherein said communications network or channel comprises of the Intemet.

11.The method of claims 1 to 7 wherein said communications network or channel comprises of any type of network capable of transmitting one-way or two-way messages in a format that can be processed by computer systems and in a format that can be understood by human beings.

12.The method of claim 1 wherein said messaging technology comprises of an email over the Internet.

13.The method of claim 1 wherein said messaging technology comprises of voice over a wired telecommunications network.

14.The method of claim 1 wherein said messaging technology comprises of voice over a wireless telecommunications network.

15.The method of claim 1 wherein said messaging technology comprises of SMS (Short Messaging Service) over a wireless telecommunications network.

16.The method of claim 1 wherein said messaging technology comprises of any type of technology that can handle messages in a format which can be processed by computer systems and in a format that can be understood by human beings.

17.The method of claims 1 to 7 wherein said personal communication device comprises of a device capable of sending and receiving data in text fommat.

18.The method of claims 1 to 7 wherein said personal communication device comprises of a device capable of sending and receiving data in voice format.

19.The method of claims 1 to 7 wherein said personal communication device comprises of a device capable of sending and receiving data in digital format.

20.The method of claims 1 to 7 wherein said personal communication device comprises of any device capable of sending and receiving data in a format that On be processed and understood by computer systems and in a format that can be understood by human beings.

21.The method of claims 1 to 7 wherein said password is chara*erised by: a sequence of alphanumeric characters; is of variable length; is generated randomly each time an AuSM message has to be sent by the Account Issuer to the personal communication device of the Account Owner whereas the Internet IP address from where the Transa*ion has been initiated is known; is valid for the approval of only one Transa*ion.

22.The method of claim 1 wherein said Transac*ion ID is chara*erised by: a 2-4 digit number; is generated by the Account Issuer each time an AuSM message has to be sent to the personal communication device of the Account Owner; is unique for each Transaction on each Account; is generated in a sequential order or in a random order for each Transa*ion; is initialised every 24 hours.

23.The Transaction ED of claims 1 and 22 further characterized by being used in each ARM message sent to the said Account Issuer of a Financial Account.

24.The Transaction ID of claims 1 and 22 further chara*erised by being used in each ARM message sent to the said Account Issuer of an Online Account.

25.The Transaction ID of claims 1 and 22 further chara*erised by being used in each ARM message sent to the said Account Issuer of a Physical Account.

26.The method of claim 1 wherein said Personal PIN Number is characterized by: a fixed 4-digit number; is assigned by the Account Issuer to the Account Owner.

27.The Personal PIN Number of claims 1 and 26 further chara*erised by being used by the Account Owner in each ARM message sent to the Account Issuer as a means of verifying the identity of the said Account Owner.

28.The Personal PIN Number of claims 1 and 26 further chara*erised by being used by the Account Owner in each ASM message sent to the Account Issuer as a means of verifying the identity of the said Account Owner.

29.The Personal PIN Number of claims 1 and 26 further chara*erised by being used by the Account Owner in each AQM message sent to the Account Issuer as a means of verifying the identity of the said Account Owner.

30.The method of claim 2 wherein the said AuSM message has the following structure: last few digits of the number describing the Financial Account; the amount of the Financial Transaction; a Transa*ion ID as chara*erised in claims 22 and 23; a password as chara*erised in claim 21; ARM message instructions that the Account Issuer expe*s to receive from the Account Owner;

other optional information such as date and time of Transaction, merchant name, list of goods purchased, Account Issuer name, comments.

31.The method of claim 3 wherein the said AuSM message has the following structure: last few digits of the number describing the Financial Account; the amount of the Financial Transaction; a Transaction ID as characterised in claim 22 and 23; a text string asking permission from the Account Owner to verify and authorise the said online Financial Transaction; ARM message instructions that the Account Issuer expects to receive from the said Account Owner; other optional information such as date and time of Transaction, merchant name, list of goods purchased, said Account Issuer name, comments.

32.The method of claim 4 wherein the said AuSM message has the same structure and use as the AuSM message of claim 31.

33.The method of claim 5 wherein the said AuSM message has the following structure: a text string that specifies the name of the Account Issuer; another text string describing the type of the Online Account; a Transaction ID as characterised in claim 22 and 24; a password as characterised in claim 21; ARM message instructions that the Account Issuer expects to receive from the Account Owner; other optional information such as date and time of attempted access, comments.

34.The method of claim 6 wherein the said AuSM message has the following structure: a text string that specifies the name of the Account Issuer; another text string describing the type of the Online Account; a Transaction ID as characterised in claim 22 and 24; a third text string asking permission from the Account Owner to verify and authorise the Online Transaction; ARM message instructions that the Account Issuer expects to receive from the Account Owner; other optional infommation such as date and time of attempted access, comments.

35.The method of claim 7 wherein the said AuSM message has the following structure: a text string that specifies the name of the Account Issuer; another text string describing the type of the Physical Account; a Transaction ID as characterised in claim 22 and 25; a third text string asking permission from the Account Owner to verify and authorise the Physical Transaction; ARM message instructions that the Account Issuer expects to receive from the Account Owner; other optional information such as date and time of attempted access, comments.

36.The method of claims 2, 3 and 4 wherein said ARM message has the following structure: a Transaction ID as characterised and applied in claims 22 and 23; an Approval Action as characterised in claim 47 or a Block Action as Characterised in claim 50 or a Cancel Action as characterised in claim 53; a Personal PIN Number as characterised and applied in claims 26 and 27.

37.The method of claims 5 and 6 wherein said ARM message has the following structure: a Transaction ID as characterised and applied in claims 22 and 24; an Approval Action as Characterised in claim 48 or a Block Action as Characterized in claim 51;

a Personal PIN Number as characterised and applied in claims 26 and 27.

38.The method of claim 7 wherein said ARM message has the following structure: a Transaction ID as characterised and applied in claims 22 and 25; an Approval Action as characterised in claim 49 or a Block Action as characterised in claim 52; a Personal PIN Number as characterised and applied in claims 26 and 27.

39.The method of claims 1, 2, 3 and 4 further characterised by allowing the Account Owner to initiate a Transaction on the Financial Account of the said Account Owner by preparing an ASM message at any time and sending this said ASM message to the Account Issuer using the personal communication device of the said Account Owner.

40.The method of claim 39 wherein said ASM message has the following structure: last few digits of the number describing the Financial Account; a Pause Action command as characterised in claim 54 or an Activate Action command as characterised in claim 57 or a Lock Action command as characterised in claim 60 or an Unlock Action command as characterised in claim 63 or a Divert Action command as Characterised in claim 66; a Personal PIN Number as characterised and applied in claims 26 and 27.

41.The method of claims 1, 5 and 6 further characterised by allowing the Account Owner to initiate a Transaction on the Online Account of the said Account Owner by preparing an ASM message at any time and sending this said ASM message to the Account Issuer using the personal communication device of the said Account Owner.

42.The method of claim 41 wherein said ASM message has the following structure: last few digits of the number describing the Online Account; a Pause Action command as characterised in claim 55 or an Activate Action command as characterised in claim 58 or a Lock Action command as characterised in claim 61 or an Unlock Action command as characterised in claim 64; a Personal PIN Number as characterised and applied in claims 26 and 27.

43.The method of claims 1 and 7 further characterised by allowing the Account Owner to initiate a Transaction on the Physical Account of the said Account Owner by preparing an ASM message at any time and sending this said ASM message to the Account Issuer using the personal communication device of the said Account Owner.

44.The method of claim 43 wherein said ASM message has the following structure: last few digits of the number describing the Physical Account; a Pause Action command as characterised in claim 56 or an Activate Action command as characterised in claim 59 or a Lock Action command as characterised in claim 62 or an Unlock Action command as characterised in claim 65; a Personal PIN Number as characterised and applied in claims 26 and 27.

45.The method of claims 1, 2, 3 and 4 further characterised by allowing the Account Owner to initiate a Transaction on the Financial Account of the said Account Owner by preparing an AQM message at any time and sending this said AQM message to the Account Issuer using the personal communication device of the said Account Owner.

46.The method of claim 45 wherein said AQM message has the following structure: last few digits of the number describing the Financial Account; a Query Action command as characterised in claim 67; a Personal PIN Number as characterised and applied in claims 26 and 27.

47.The method of claim 36 wherein said Approval Action is a predetermined text string

included as part of the ARM message to approve a Financial Transaction.

48.The method of claim 37 wherein said Approval Action is a predetermined text string included as part of the ARM message to approve an Online Transaction.

49.The method of claim 38 wherein said Approval Action is a predetermined text string included as part of the ARM message to approve a Physical Transaction.

50.The method of claim 36 wherein said Block Action is a predetermined text string included as part of the ARM message to stop a Financial Transaction.

51.The method of claim 37 wherein said Block A*ion is a predetermined text string included as part of the ARM message to stop an Online Transaction.

52.The method of claim 38 wherein said Block Action is a predetermined text string included as part of the ARM message to stop a Physical Transaction.

53.The method of claim 36 wherein said Cancel Action is a predetermined text string included as part of the ARM message to stop a legitimate Financial Transaction.

54.The method of claim 40 wherein said Pause Action is a predetermined text string included as part of the ASM message to stop applying the system and method of claims 1, 2, 3 and 4 on a Financial Account.

55.The method of claim 42 wherein said Pause Action is a predetermined text string included as part of the ASM message to stop applying the system and method as described in claims 1, 5 and 6 on an Online Account.

56.The method of claim 44 wherein said Pause A*ion is a predetermined text string included as part of the ASM message to stop applying the system and method as described in claims 1 and 7 on a Physical Account.

57.The method of claim 40 wherein said Activate Action is a predetermined text string included as part of the ASM message to reactivate and start applying the system and method as described in claims 1, 2, 3 and 4 on a Financial Account.

58.The method of claim 42 wherein said Activate Action is a predetermined text string included as part of the ASM message to reactivate and start applying the system and method as described in claims 1, 5 and 6 on an Online Account.

59.The method of claim 44 wherein said Activate Action is a predetermined text string included as part of the ASM message to reactivate and start applying the system and method as described in claims 1 and 7 on a Physical Account.

60.The method of claim 40 wherein said Lock A*ion is a predetermined text string included as part of me ASM message to automatically prevent any Financial Transaction to be finalised on a Financial Account of the system and method as described in claims 1, 2, 3 and 4.

61.The method of claim 42 wherein said Lock Action is a predetermined text string included as part of the ASM message to automatically prevent any Online Transaction to be finalised on an Online Account of the system and method as described in claims 1, 5 and 6.

62.The method of claim 44 wherein said Lock Action is a predetermined text string included as part of the ASM message to automatically prevent any Physical Transaction to be

finalised on a Physical Account of the system and method as described in claims 1 and 7.

63.The method of claim 40 wherein said Unlock Action is a predetermined text string included as part of the ASM message to reactivate the system and method as described in claims 1, 2, 3 and 4 on a Financial Account that was previously locked using a Lock Action command as described in claim 60.

64.The method of claim 42 wherein said Unlock Action is a predetermined text string included as part of the ASM message to reactivate the system and method as described in claims 1, 5 and 6 on an Online Account that was previously locked using a Lock Action command as described in claim 61.

65.The method of claim 44 wherein said Unlock Action is a predetermined text string included as part of the ASM message to reactivate the system and method as described in claims 1 and 7 on a Physical Account that was previously locked using a Lock Action command as described in claim 62.

66.The method of claim 40 wherein said Divert Action is a predetermined text string included as part of the ASM message to instruct the Account Issuer to divert authorization for initiating or finalising an Action on a Financial Account to a person other than the Account Owner for the system and method as described in claims 1, 2, 3 and 4.

67.The method of claim 46 wherein said Query Action is a predetermined text string included as part of the ASM message to instruct the Account Issuer to supply the Account Owner with information relevant to the Financial Account of the said Account Owner.

68.The method of claim 1 wherein said Action is one of the following Action types: Approval Action as described in claims 2, 3, 4, 5, 6, 7, 36, 37, 38, 47, 48 and 49; Block Action as described in claims 2, 3, 4, 5, 6, 7, 36, 37, 38, 50, 51 and 52; Cancel Action as described in 2, 3, 4, 36 and 53; Pause Action as described in claims 40, 42, 44, 54, 55 and 56; Activate Action as described in claims 40, 42, 44, 57, 58 and 59; Lock Action as described in claims 40, 42, 44, 60, 61 and 62; Unlock Action as described in claims 40, 42, 44, 63, 64 and 65; Divert Action as described in claims 40 and 66; Query Action as described in claims 46 and 67.