GB2444515A

GB2444515A - Foreign currency trading game

Info

Publication number: GB2444515A
Application number: GB0624255A
Authority: GB
Inventors: Paul Green
Original assignee: GAMING PORTAL Ltd; Games Portal Ltd
Current assignee: GAMING PORTAL Ltd; Games Portal Ltd
Priority date: 2006-12-05
Filing date: 2006-12-05
Publication date: 2008-06-11
Also published as: WO2008068469A2; JP2011505602A; GB0624255D0

Abstract

A system for playing a foreign currency trading game in which financial data, eg exchange rates, is fed to two or more user devices, users trade currencies over the system and at the end of the game the user device with the best performance is selected based upon criteria and financial data stored on the system. The connection to the system may be through a dedicated connection or through a network such as the Internet. The financial data may be real or generated by the system. The user device may be a desktop computer, a mobile device, a PDA or any other suitable device. The game may alternatively involve the trading of commodities, shares or other financial entities.

Description

1 2444515

APPARATUS ADAPTED TO ANALYSE FINANCIAL DATA

This invention relates to apparatus for processing financial data. It is particularly applicable to apparatus adapted to monitoring user reactions to financial data.

According to one aspect of the present invention there is provided a system comprising: an output arranged to transmit financial data to at least two user devices; an input arranged to receive data from each of the at least two user devices; and processing means arranged to select a user device according to criteria stored on the system and the financial data.

Optionally, the financial data may be generated by the system. This allows the system greater control over the financial data, for example by preventing two pieces of financial data from converging within a predetermined range of each other.

Alternatively, the system may include at least a second input adapted to receive financial data generated by a third party external to the system wherein the financial data is either passed directly to the output or reconfigured by the system prior to transmitting to the output.

This provides the advantage of enabling users to select financial data according to real time situations, for example the current exchange rates.

The financial data may be a conversion value between a first and a second financial unit.

The conversion value may be, for example a price to buy the second financial unit using the first financial unit or a price to sell the second financial unit in order to receive the first financial unit.

The first unit may be money in a first currency and the second unit may be money in a second currency, a commodity or share price. The type of financial unit used by the system may be selected by a user and the data received from a user device may be an instruction to convert the first unit into the second unit. This enables the user to buy and sell currencies, commodities or shares.

Preferably, the processing means is further adapted to calculate the difference between the original amount of the first unit for a user device and the current amount of the first unit for a user device. In this way the profit or loss generated by a user selling and buying financial units can be calculated.

The criteria may specify that the user to be selected is the user with the greatest amount of the first unit recorded after a predetermined period of time. In this way the profit and loss account may be used to identify a user with the best performance by generating the most profit or least amount of loss. Alternatively, the criteria may specify that the user to be selected is the first user having the same recorded amount of the first unit as a predetermined amount specified on the system.

Optionally, data received from a user device may include an offer of a side game. The system may only receive an offer of a side game during a pre-speciuied period of time.

Preferably, the acceptance of an offer of a side game received from a second user device causes the system to generate a second account for the first user, the second account being adapted to calculate the difference between the amount of the first unit for a user device at the time of generating the second account and the current amount of the first unit for a user device. A second account may be generated upon acceptance of the side game by the second user device. The generation of a second account means that the side game will run independently of the main profit and loss account.

S The offer of the side game may be for a competition where the winner will be the user with the greatest value of the first unit after a predetermined period of time has expired.

Alternatively, the offer of the side game is for a competition where the winner will be the user having the greatest value of the recorded first unit in the account at the end of the game.

Data received by the input may be a financial data value for a predetermined time. The user sending a financial data value that is the same as the actual value of the financial data at the predetermined time is preferably selected as a winner. One or more users that send a financial data value within a specified range of the actual financial data at the predetermined time may also be selected.

According to a second aspect of the present invention there is provided a method comprising the steps of transmitting financial data to at least two user devices, receiving data from each of the at least two user devices and selecting a user device according to criteria stored on the system and the financial data.

A specific embodiment of the present invention will now be described by reference to the following drawings in which: Figure 1 is a schematic diagram of the system: and Figure 2 is a schematic diagram of the modules that may be present in the system.

DescriDtion of the System Structure The present invention comprises a system 10 as illustrated in Figure 1. The system is adapted to provide services to one or more user devices that connect to the system via input and output 22. The user device is adapted to enable a user to interact with the system, for example, by transmitting information to the system and receiving information transmitted by the system.

The system 10 may be connected to the user device directly through a dedicated connection, alternatively the connection may be through a network such as the internet, enabling the user to access the system through an internet web browser such as Internet Explorer. The user device may be, for example, a desktop computer, a mobile device, a PDA or any other suitable device.

The services may be provided to multiple users connected to the system 10. The system 10 may also allow a user to connect to one or more services that may be run concurrently by the system 10.

The system 10 may be considered as a series of components adapted to enable the system to provide functions to the user devices. The components may include, for example, a database 16 operable to store information received from user devices or any other device: a controller 14 to determine how information is collected by the system and stored in the database. The system 10 may also include a publishing system 18 that receives information output by the controller and configures it prior to transmitting it to a user interface. This enables data to be viewed on a user device in an optimal manner.

One or more servers connected to the network may be used to implement the system. For example, the controller 14, database 16 and publisher 18 may be stored and implemented on the same device, for example a server. Alternatively, one or more of these components may be stored and implemented on separate devices, such as separate servers. The devices may be connected directly to each other or, may be connected indirectly through a network such as the World Wide Web.

Additionally, the database may comprise a single database. Alternatively, the database 16 may include two or more component databases, each database configured to store data relating to a different characteristic, for example one database may store data relating to money and another may store data relating to user information. The two or more databases may be stored on the same storage means or different storage means.

Alternatively, one or more components making up the system 10 may be downloaded to the user device.

The present system 10 may also facilitate the transmission of real time data to the user device. The real-time data may be, for example, financial data. Financial data for the purposes of this description is taken to mean data relating to the values of one or more financial units that can be bought or sold.

Generally, the values of the financial units are determined by a conversion value between the two financial units. Usually, there are two separate conversion values related to the financial units. These conversion values may be the value at which a unit can be bought and the value at which a unit can be sold. For example, financial data may be an exchange value between one or more pairs of currencies where one value is the price at which a first currency can be bought using a second currency and the second value is the amount of the first currency that will be obtained on selling the second currency. This is equally applicable to commodities, share indices or any other appropriate data in place of foreign currencies.

The financial data may be received from a third party separate from the system 10 and the user device and either transmitted directly to a user device without processing, or alternatively, the system 10 may include a client for the third party that provides the financial data. Finally, the financial data may be generated by the system 10 without input from an external source. Advantageously if the financial data is received from the third party then updated whenever any changes to the financial data at real time.

The system may be configured in order that there is a minimum and maximum conversion rate between the first and second financial units. Alternatively, where two conversion rates are specified, the first to convert a first unit to a second unit and the second to convert the second unit to the first unit, the minimum and maximum difference between the two conversion rates may be specified.

The present system is described with reference to games which may be played by users using the user devices. It will be understood by the skilled person that other types of computer programs may be executed on using the system.

The controller 14 may be considered to be made up from a number of modules 12 that are able to carry out the separate functions required of the controller 14. The modules 12 may be implemented using one or more processors as appropriate.

Examples of modules which may be present in the system are illustrated in Figure 2 and include a clock module 24, leader board module, competition module, chat module 30, chart module 32, winning modules 34, prize fund module 36, prize fund allocation module 38, a research module 40, a game selection module 42, a finance module 44, an administration module 46, a performance module 48, a registration module 50 and a live data module 52.

All the modules may be present on a single server or, alternatively, one or more of the modules may be implemented remotely from the system.

The functions of the modules and examples of games provided by the system are now described with reference to foreign exchange financial data. However, any other suitable type of financial data may be used.

The clock module 24 is adapted to produce instances of timers. Each instance of the timer being adapted to display, for example the time left until a game begins or the time left until a game ends. The timer may also trigger alerts that are transmitted to a user device to inform the user that there is a predetermined amount of time left before an action, for example the end of a game, occurs.

The registration module 50 controls how a user registers with the system and accesses games. Any information required by the system before a user can enter a game, for example financial information, is determined by this module 50. The information collected by this module 50 is transmitted to the database for storage.

The database 16 is a structure configured to store information, such as a user's financial information or any other required information. It may consist of one or more separate database entities. The database entities may be located in one location or, alternatively, they may be situated in different locations, for example, on separate servers.

The chat module 30 controls communication between two or more users using devices connected to the system, for example by enabling the display of text data transmitted by user devices. The communication may occur either whilst a game is being played or not.

JO The live data module 52 is adapted to monitor and control any financial data. The financial data may be generated by the finance module 52. Alternatively, the live data module 52 may be adapted to push financial data received from an external source to a user device without reconfiguring the financial data.

Optionally, the live data module 44 may be adapted to reconfigure the financial data such that it can be displayed by the user device without requiring the user device to be adapted to access or process the financial data.

The system may also be adapted to automatically update live data at the user device without requiring the system to receive requests for updated data from the user device. For example, if the user device accesses the system using a web browser it is advantageous for the financial data, such as exchange rates to change at the user device at the same time as changes are generated or received by the system. It is also preferable that the update of financial data does not require the entire web page to be reloaded at the user device.

This may be achieved by the system being adapted to detect a change in financial data and cause asynchronous loading of the financial data that has changed on the web page being displayed using the web browser. Preferably, an AJAX based application on the system is used to selectively transmit the data to the web browser on the user device.

The chart module 32 may collate information, for example changes in the financial data over time, and produce charts, such as line graphs, in order that users can view the information graphically, for example the charts may show the relative movements of currencies with reference to time. I0

The research module 40 is adapted to collate and transmit information on financial data in order that the user may utilise the information to improve their trading within a game. This information may include the chart produced by the chart module.

Additionally, the research module 40 may transmit news or commentary regarding the financial data. The news and commentary may be received by the system from a third party.

This may be done, for example in the form of a line of text that moves across the screen.

The text may also display event information, forecasts, information relating to currently pending and current games and recent winners. The text may link to a webpage with further details regarding the subject matter of the text.

The winning module 34 determines how the winner of a game is chosen. Preferably, the winner is chosen using a winning formula. The winning formula for a game may be predetermined by the system according to the type of game or, alternatively, one or more users may choose the formula when an instance of the game is set up. The winning formula is described in more detail in relation to games below.

The leader board module 26 uses the winning formula to determine the relative positions of any users that are participating in a game. This may then be displayed to the user in the form of a table or any other suitable format.

The prize fund module 36 determines the amount of money that is won by the winner, as determined by the winning module. The amount of money awarded to a user that has won a game may either be based on a percentage of the total entry fees paid by the users playing a game or, alternatively, it may be a fixed amount.

The prize fund allocation module 38 is then responsible for determining how any prize money is allocated by applying the winning formula.

The publisher 18 processes data received from other modules for display at a user interface and converts the data into a suitable format to display on the user interface of a user device.

The format may, for example, be suitable for display using an Internet browser on a personal computer or a handheld device. The data processed by the publisher 18 may include financial data.

The communication module 43 is provided to control the transmission of messages either within the system, for example between modules or servers, or messages that the system transmits to users devices.

The finance module 44 is enabled to control financial data within the system. It may also control the collection of money using specific payment collection means using information input by the user.

Preferably the finance module 44 controls three separate accounts for each user although the number of accounts for a user may vary. The three accounts are for: free' money, bonus' money and real' money.

Bonus money may be placed within a bonus money account and may be allocated to a user when they perform a specified action, for example they may have entered a predetermined number of games, won a game or have entered a predefined code into the system. The administrator may also select to place bonus money within a bonus money account.

The amount of bonus money placed within the account may be predetermined, for example, entering a specific code may result in $10 of bonus money being placed within a bonus money account. Alternatively, the amount of bonus money placed within the account may be defined by the administrator.

The Bonus money may have limitations associated with it, for example, it may be used by a user to enter a game but not be withdrawn as cash. Another limitation may be that the bonus money can only be used by a user when the user no longer has any real money available on the system.

Free money may be placed within a free money account that can be used to play games for free. Conditions may be attached to credits in the free money account; for example, this money may only be able to be used in games where no prize can be won. Money may be placed in the free money account, for example, when they first register with the system or when any other suitable condition is fulfilled.

"Real" money is money that may be deposited or withdrawn by the user into an account external to the system, for example, a bank account.

The finance module 44 may receive money and subtract the fee for playing a game from the appropriate account for a user when notified by the game selection module 42 that access to a game has been requested and credit the appropriate account for a user when notified by the prize allocation module 38 that a user has won prize money. This may be done, for example, by transmitting the amount to be added or subtracted from the users account to the database where the financial information for the user is stored using the database output.

Once money has been added or subtracted from a user's real money account the amount of money the user can withdraw is increased or reduced by the amount of money added or subtracted from the real money account respectively.

Advantageously the system allows users to bid in a number of ways within a game. The different possible modes of bidding within a game are described below.

The game selection module 26 controls user interaction with computer programs, such as a game stored on the system. The module 26 enables a user to view, select and register to play games present on the system such as games that are due to start or have started.

Advantageously the game selection module 26 can control more than one type of game.

The admihistration module 46 enables an administrator to modify the system's attributes, for example by creating a new game template. A new game may be created, for example using a template of a game. In a game template the various settings that are common to all games are specified. The template also specifies variables that can be altered by any user connected to the system when they choose to set up a new game.

These variables may be: the name of the game, the type of game, when the game starts, the fee to enter the game, the configuration of the winning module for the game, the prize money, how many people will win prize money, how long the game will last, how much money can be traded during the game, which currencies will be traded during the games, how long people have to register for the game and when they have to register by, when the clock showing the time left in the game is shown, whether bidding periods are allowed and what the bidding options are and how the prize fund, leader board is displayed.

An administrator who has control of the system may enter the variables. Additionally, variables that a user can vary when setting up their own instance of a game may be specified. For example a user may desire to set up a game using a particular type of financial data, for example, currencies, commodities or share indices. The variables may have default values which are assumed if no other value is specified.

Optionally, an administrator may select the minimum and maximum conversion rate between the first and second financial units. Alternatively, if two conversion rates are used, one to convert a first unit to a second unit and another to convert the second unit to the first unit, the administrator may specify the minimum and maximum difference between the two conversion rates.

The Types of Games provided by the System The games described below will be described with reference to trading in foreign currencies.

However, it should be recognised that the financial data may be any suitable financial data, such as the prices of commodities or share indices.

A user registered in a game is provided with the ability to bid upon the outcome of their winning the game, achieving a minimum profit in a game or any other game outcome. The game outcome being determined by actions the user takes in relation to the financial data.

The first and second embodiment will be described with reference to the following terms.

Firstly, a first financial unit, called a base currency for the purposes of this description, will be selected. A base currency is preferably the currency that is used to buy into another unit and used to calculate any profit or losses generated by the user from that trade.

For example, the base currency may be US dollars and the other unit may be related to another currency, a commodity price or a share index. A user may then convert the base currency into the other unit according to the any specified conversion value, for example the buy price of the other unit. At a later point in the game the user may convert the other unit back into the base currency using a second conversion value, for example the sell price for the other unit.

At the end of a game the system may automatically close all open trades and convert all units to the base currency using the appropriate conversion value.

If the user has gained more of the base currency selling the other unit than was used to buy it then they will have made a profit. If, however, they have retrieved less of the base currency than was used to buy it then they will have made a loss. The amount of base currency profit or loss that a user has at any one time is specified in their profit/loss account.

If desired a user may only be able to use a minimum amount of the base currency to buy another unit. Additionally, it may be desired to specify a maximum amount of the base currency that can be traded for another unit.

In any game there may be more than one type of base currency.

The game may start at a specified time. Alternatively, the start of the game may depend on certain criteria. For example, the game may begin when a predetermined number of users have registered to play or alternatively, after a predetermined amount of time, for example a 5-minute period. The predetermined amount of time may be calculated, for example from the time the first user registers to play the game.

If the number of users registered to participate in a game is lower than the predetermined number of users then the system may, optionally, allow a registered user to select whether to proceed with playing game or not. The system may specify a minimum number of participants in a game, for example two, If the number of participants is lower than the minimum then the instance of the game will not proceed.

If the user registers to participate in a game in which the maximum number of players have already registered and playing they may select to join the new game generated by the system when the first game became full. Alternatively, the user may select to join a queuing system, comprising a list of users waiting to enter the game, for the full game. Users are preferably added to the queue in the order that they attempt to join the game. When an active player in the game leaves the game then the first user in the queue is allowed to join the game.

The system may also match a user to a game in which users are waiting to play. This may occur automatically when a user joins a queue.

A user may register to participate in a game either before the game has begun (referred to as pre-registration) or they may select to enter a game in which trading between first and second financial units has commenced. If the user pre-registers for a game then they may choose to select to trade a first unit for a second unit upon commencement of the game.

Alternatively, a user may wait until the game starts before selecting trades.

Upon registration the fee, or other appropriate amount required to enter the game is debited from the appropriate user's account by the finance module.

Although users can register to participate in a game before the game commences a user may also choose to participate in a game where trading has already started. In this instance the user selects the game from a menu and the user automatically enters the game.

Users can also optionally select to continue playing when any game ends. This will automatically move them to another game of a similar type that is about to start.

In the first embodiment two or more users trade a pair of financial units. As described previously, one unit, known as the base currency, is the unit that is converted to a second financial unit according to specified conversion rates. The base currency is used to calculate the amount of profit or loss a user has made. The game may last for a predetermined time with the winning module determining the winner as the user making the largest profit or smallest loss, as determined by having the greatest amount of base currency, after the predetermined time has elapsed. Prior to determining the winner it is preferably that all the financial units that are not the base currency are converted to the base currency. If there is more than one financial unit specified then multiple winners may be specified, for example a winner for each pair of financial units, or one overall winner may be specified.

Alternatively, the duration of the game may vary with the winner being determined by the winning module as being the first person to reach a specified profit. If desired a maximum game duration may be specified. If the game runs for the maximum duration then the winner may be determined as the user making the largest profit or smallest loss.

A user may also have the option to challenge other users to a side game. The user is advantageously able to choose whether the side game is open in order that any other user can participate in the game, or private, If the bid is private then the user preferably selects the game names of the users they wish to compete with by selecting them from a user list.

The side game may be won, for example, by the participating user finishing with the most profit or smallest lost in a specified duration. The side game offer can be made at any time in the game.

When a side game is created where the game is for which user will make the most profit or smallest toss in a specified duration it is preferable that all users participating in the side game are provided with a secondary profit and loss account which starts at zero from the time of the side game. Preferably the users will maintain their overall positions in the main game with the creation of a secondary profit and loss account having no effect on the main profit and loss account. In this instance thewinner will be the user with the most profit or smallest loss in their secondary profit and loss account after the specified duration has elapsed.

The bid a user makes on entering a side game may be debited from each user's account and credited to a game fund. When the competition ends the winner's account is credited the value of the game fund. A predetermined amount, competition fund percentage, or any other suitable amount may be deducted from the game fund and credited to another account on the system, for example the administrator's account.

A user may participate in one or more side games with other users throughout the game.

The side games may run concurrently.

In a second embodiment the users in a game may be able to bid on the outcome of the game, for example whether they will win. The winner may be determined using any of the methods described with reference to the first game embodiment.

One or more bidding intervals are provided, for example there may be a bidding interval at the end of the game, there may also be further bidding intervals within the game. Preferably.

during bidding intervals no trading occurs.

Users may only be allowed to raise a bid a maximum number of times. Additionally, a maximum or minimum raise may be specified. For example the first bidding period could be up to a maximum multiple of 8 times the entry and the second bidding period up to a maximum multiple of 16 times the entry. Preferably, further bidding periods occurring after the initial bidding period start with an opening bid equal to the last raise of the bidding period immediately preceding it.

It may also be desired to specify the maximum amount that can be bid during any one game.

For instance, in the example given above, the maximum bid may be 16 times the entry. In this instance once a raise of 16 times the entry has been placed no further bids will be permitted. If the second raise was 12 times the entry then the third bid may be 4 times the entry making the total bids 16 times the entry fee.

It may be advantageous to limit the duration of time in which a user can submit a bid, for example the time duration may be 20 seconds to place the first bid and 15 seconds for any subsequent bids. If a user fails to place a bid in the allotted time the system will close their position and they will not be able to bid further in that period of bidding.

In order to facilitate a user in placing bids it may be advantageous for the competition module to calculate the amount by which the users can raise the bidding and transmit the amount to the publisher which may then transmit the information for display at the user device. The amount may, for example, be on a button that can be selected by the user when it is their turn to bid. Examples of buttons that may be displayed are illustrated in the

table below:

___________________________ ______________________________________________________________________

If showing a user has the option to check, i.e. decline to bid -this is only possible if no other user has bid during the current round of bidding.

If the Call option is available the Call button will display rrwi..iuuii showing the appropriate amount a user has to stake to Call, I0 i.e. to match the last bid.

If showing a user has the option to raise up to the amount ___________________ shown. Buttons will be shown for each raise permutation available to the user. A raise increases the amount that is required to be bid to stay in the game.

_____________________________________________________

Users can Close and exit the game.

When a user selects a box or button this is transmitted to the system by the user interface where it is processed by the publisher and then transmitted to the competition module. The competition module receives the selection made by the user and recalculates the call and raise amounts that are to be displayed to other users as appropriate. The competition module may also end the bidding interval if the maximum raise has been entered.

Additionally, the competition module may provide the option for a user to pre select their available bidding option or to select from one of the auto bid options before it is their turn to bid. This may be enabled, for example, using boxes as illustrated in the table below.

A user can check the Auto Call button prior to their turn and C Auto Call the system will automatically call at the users turn.

A user can check the Auto Raise button prior to their turn C Auto Raise Max and the system will automatically raise to the maximum allowed.

This allows a user to remain in the game even if they cannot manually enter bids, for example because they are not present at a user device during the bidding interval.

Additionally, the competition module may select the first user who is to bid in a round. The first user to bid may be automatically selected according to rules stored on the system by being the first user to register for the game. Alternatively, the competition module may, for example, select the first user to bid by selecting the user with the first surname when the surnames are listed alphabetically. In further bidding periods other criteria may be used to choose the first user to bid, for example the first user to bid may be the user at the top of the leader board or, if no trading positions have been closed (see below), the lowest numbered user still in the game.

Optionally, a specified number of users, such as two, play against each other in head to head games. The game type for the head to head games may be either of the embodiments described above. The winner of the head to head game then progresses to the next round.

The losers are eliminated from the game.

Once there are only a predefined number of users left in the game there is a final where all the users still in the game play against each other to determine the winner, It is preferable that the users have to qualify to take part in the head to head games and the head to head games are played over a predefined period of time.

Preferably, the first user to register will play the next user to register with the winner of the game qualifying for the next round.

In a third embodiment users transmit predicted values for financial data at a predetermined time. For example, if the financial data is an exchange rate between one or more pair of currencies then the game may involve a user predicting the exchange rate between the one or more pairs of currencies at I 500hrs the next day. Alternatively, users may predict the price of one or more commodities, or share indices.

The winning module will determine the winner according to the predicted values transmitted by users. The winning user is the user that correctly predicts the value of the selected financial data at the predetermined time. The winner receives an award, for example of money. Optionally, if the user is within a specified range of the value of the financial data then they may also receive a lesser award.

The user may only be permitted to submit a selected number of prediction values to the system.

A user can submit a predicted value at any time during a time period before the predetermined time. The administrator may select when the time period for submitting predicted values starts and ends. Preferably, the time period ends at a specified time before the predetermined time.

For example, the predetermined time may be 1500 hours the next day; this may be the next working day. The time period for submitting predicted values to the system may end at 1500 hours on the current day. Therefore, until 1500 hours on the current day, users may submit the value that they predict the financial data will be at 1500 hours the next day.

The system selects a winner at 1500 hours the next day; the winner being the user that submitted a value equal to the actual value of the financial data at 1500 hours the next day.

Users that submitted values within a specified range of the actual value of the financial data may also receive lesser prizes.

A user may select to generate an instance of a game. In doing this the user may select the financial data to be used, for example which currencies, commodities or share indices are to be traded; the minimum and maximum bids, the fee for entering the game, the maximum number of players and any other suitable options. The user may also choose to specify users that are able to enter the game or, alternatively, the user may specify that any user can participate in the game.

Once the user has generated the game instance it is presented to the relevant users as an offer. An offer may be displayed as text on a part of the display at a user device, for example in a separate window or webpage. Alternatively if the offering users specify users then email or other communications may be sent to the specified users. Users may then join the game as before.

Use of the system The use of this system is described with reference to exchanging currencies. However, as will be well understood the use of this system is equally applicable to any game where financial entities are traded.

Generally, a user will access the site, register or logon, pay the entry fee and play a game.

Users arriving at the web site must register their details and deposit funds before they can access and play the available games. The database, or part of the database, therefore, must be able to store data such as: the user's ID that they use to access the system, their password, the user's address (including house number/name, street, city/town and country), contact details, such as their telephone number, mobile number or fax number, payment details, such as their credit or debit card details, details of the amount of money they have transferred to be used on the system. Answers to questions that need to be answered in order to, for example, get a password reminder can also be stored in the database. Further information such as the user's occupation and age etc... may also be stored in the user database.

All user information should be available and the system should include all the latest registration features, including postcode matching, country selection etc. Whilst accessing the system a user can view a range of available information including help, FAQ, game schedules, historic game data, winners data and general company information.

Once registered a user can access a list of games that they can join and can select a game to play. Once they have entered the game the user device will display all of the information to enable a user to execute and manage trades, review trade history and to monitor their status on the leader board. Preferably, all games on the system will be able to monitor live trading rates.

In order to trade in a game a user will select: the currency pair to be traded, the amount of the base currency, whether they are going to buy or sell the currency then execute the trade.

Providing the trade is within the games trading limits the system will execute the trade. The user will be able to see the status of the trade in the open positions window on the screen.

Once a user has selected a currency pair the next decision is to decide the amount of base currency to trade. Preferably, a menu on the user interface allows this selection from within the limits set for the game.

Once a user has selected an amount of currency they next have to choose whether to buy or sell the currency. Preferably this is done by the user selecting a buy or sell option displayed on the user interface. The system will then execute the trade if it is within the users trade limits. When a user executes a trade the system will deliver an instant confirmation of the trade details to the users screen. If the system fails to execute the trade because a user attempts to execute a trade outside of the trading limits for the game an error message will display.

Preferably, users are able to access their live and historic trade information throughout the duration of a game. As users open trades their unrealised profits are transmitted to their user interface from the publisher in real time, moving as the market moves. When users close their positions their Profit and Loss position is realised and displayed.

Preferably users are able to view the following information: the position for any currency trades that have not been traded back into the base currency; their currency exposure, the result of netting off positions containing the currency, in which they hold positions; any orders left against their open positions that can be modified or cancelled; a record of trades that have been made; closed positions for trades when they return the traded currency back to the base currency; profit and loss that has been finalised as the result of closing trading positions, unrealised profit and loss for trades which have not yet been finalised and open orders for which a stop loss or take profit order has been sent to the system (an opportunity to automate an order that will execute if the market price occurs).

Claims

1. A system comprising: (i) an output arranged to transmit financial data to at least two user devices; (ii) an input arranged to receive data from each of the at least two user devices: and (iii) processing means arranged to select a user device according to criteria stored on the system and the financial data.

2. A system as recited in Claim 1 wherein the financial data is generated by the system.

3. A system as recited in Claim 1 wherein the system further comprises at least a second input adapted to receive financial data generated by a third party external to the system wherein the financial data is either passed directly to the output or reconfigured by the system prior to transmitting to the output.

4. A system as recited in Claim 1 wherein the financial data is a conversion value between a first and a second financial unit.

5. A system as recited in Claim 4 wherein the conversion value is either a price to buy the second financial unit using the first financial unit or a price to sell the second financial unit in order to receive the first financial unit.

6. A system as recited in Claims 4 or 5 wherein the first unit is money in a first currency and the second unit is money in a second currency, a commodity or share price.

7. A system as recited in Claim 6 wherein the type of financial unit used by the system is selected by a user.

8. A system as recited in any preceding claim wherein the data received from a user device is an instruction to convert the first unit into the second unit.

9. A system as recited in Claim 8 wherein the processing means is further adapted to calculate the difference between the original amount of the first unit for a user device and the current amount of the first unit for a user device.

10. A system as recited in Claims 8 or 9 wherein the criteria specifies that the user that is selected is the user with the greatest amount of the first unit recorded after a predetermined period of time.

11. A system as recited in Claims 8 or 9 wherein the criteria specifies that the user that is selected is the first user having the same recorded amount of the first unit as a predetermined amount specified on the system.

12. A system as recited in any preceding claim wherein the data received from a user device includes an offer of a side game.

13. A system as recited in Claim 12 wherein the system only receives an offer of a side game during a pre-specified period of time.

14. A system as recited in Claim 12 or Claim 13 wherein the acceptance of an offer of a side game received from a second user device causes the system to generate a second account for the user side game, the second account being adapted to calculate the difference between the amount of the first unit for a user device at the time of generating the second account and the current amount of the first unit for a user device.

15. A system as recited in Claim 14 wherein the second account is generated upon acceptance of the side game by the second user device.

16. A system as recited in any of Claims 12 to 15 wherein the offer of the side game is for a game where the winner will be the user with the greatest value of the first unit after a predetermined period of time has expired.

17. A system as recited in any of Claims 12 to 15 wherein the offer of the side game is for a game where the winner will be the user having the greatest value of the recorded first unit in the account at the end of the game.

18. A system as recited in Claim 1 wherein data received by the input is a financial data value for a predetermined time and the criteria selecting the user that sends to the system financial data that is the actual value of the financial data for the predetermined time.

19. A system as recited in Claim 1 wherein data received by the input is a financial data value for a predetermined time and the criteria selecting the user that sends to the system a financial data value that is within a specified range from the actual financial data at the predetermined time.

20. A method comprising the steps of: (i) transmitting financial data to at least two user devices; (ii) receiving data from each of the at least two user devices; and (iii) selecting a user device according to criteria stored on the system and the financial data.

21. A system substantially as herein described with reference to and as shown in any combination of the accompanying drawings.

22. A method substantially as herein described with reference to and as shown in any combination of the accompanying drawings.