AU2018100338A4 - Resources Distribution System and Method thereof - Google Patents

Abstract

Abstract In one embodiment of the present invention, there is provided a user device comprising one or more sharing resources for sharing with one or more user devices. The sharing resources are surrendered to a server into a pool of resources managed by the server. The user device also has a processor for connecting to the server and participating in a resources allocation event and the resources allocation event comprises one or more comparison processes. The processor is adapted to provide a comparison value for a comparison process, and in the event that the comparison value is within a favourable domain set by the server in real time, the processor would be promoted to participated in a subsequent comparison process, otherwise the processor would be denied for the sharing resources. When a halting condition is satisfied, the processor will take control of a portion of the resources in the resources pool which is relinquished by the server. Methodi 30 Coct Resurcesino Resources; Pass Step32 Enterm a Eveni See a Step 33 Convnnson pmcens Step 34 Step 4...

Description

Resources Distribution System and Method thereof

TECHNICAL FIELD

[0001] The invention relates to a Resources Distribution System, and in particular, the present invention relates to a computer system, software or method for distributing resources across one or more participants in the system. BACKGROUND.

[0002] Resources allocation is one of the main functions of a computer operating system which is responsible for managing multiple resources within the computer environment to allow multiple processes to be executed simultaneously.

[0003] In Cloud computing a number of user devices are interconnected with each other through a server which may comprise a farm or cluster of machines. Some of the user devices may have low utilisation of their resources while others may need more in order to complete its task efficiently.

[0004] Cloud Computer is a type of Internet-based computing that provides shared computer processing resources and data to servers and user devices. It is a model for enabling ubiquitous, on-demand access to a shared pool of configurable computing resources (e.g., computer networks, servers, storage, applications, and services), which can be rapidly provisioned and released with minimal management effort.

[0005] Cloud computing relies on sharing of resources to achieve coherence and economy of scale, similar to a utility (like the electricity grid) over an electricity network.

[0006] Traditionally, the computer system may allocate a time slice for a process to utilise one or more resources. This technique is very common in use for sharing Central Processing Unit (CPU) where a part of a process may swap in and run in the CPU for an arbitrary time slice before swapping out with another process.

[0007] Another way to share resources is to divide the resources into different parts where each process owns a part of resources during its life cycle. The process may utilise the allocated resources at any time. This technique is common in use for sharing memory in a computer system, including volatile and non-volatile memory. A process will have a block of memory allocated to it until the memory is released.

However, the traditional methods were not suitable for a modem computer system where multiple client devices were sharing in a cloud computing environment to compete with a pool of system resources. US Patent No. 6823458 discloses an apparatus and method for securing system resources in concurrent multiple operating system environments. When a client device or application requests access to system resources, the receiving apparatus will determine if the resources requested are currently being used by another client or application. Based on a unique identifier sent by the client or application, the apparatus searches a resource state data structure for the resource requested and compares the unique identifier sent by the client or application with the unique identifier stored in the resource state data structure in association with the requested resource. If the two unique identifiers are the same, the client/application is provided with access to the requested resource. If the unique identifiers are different, the client/application is denied access to the requested resources. US Patent No. 8862738 discloses an approach for rebalancing/reallocating cloud resource capacities between resource pools that provide variable customer assurances and delivery penalties when assurances are not met. The variables that are considered hereunder include, overall ‘reservations’, total current capacity, remaining capacity against unused reservations and penalties that apply for failing to satisfy ‘reservation’ commitments. The approach uses a rate of capacity consumption to calculate the risk of consuming the available capacity in each resource pool (e.g., resource pools allocated to satisfy different levels of service with different SLA failure penalties). Based on the relative available capacity in each pool (as determined by the pool rate of consumption), resources are reallocated to maximize revenue (e.g., reduce financial penalty) across a resource pool set.

The previous methods rely on collaborated sharing of resources. They were not designed for a competitive environment. The present invention is substantially divergent in design elements from the prior art, and consequently, it is clear that there is a need in the art for a new approach for sharing resources in clouding computing type of environment.

Hence, there is a need for a method for sharing untapped resources of idle user devices and sharing more efficiently with other user devices.

Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.

IARY

PROBLEMS TO BE SOLVED

The present invention relates to a computer processing apparatus for managing system resources and improving the efficiency of the computer system.

It is, therefore, an object of the present invention to provide a new and novel approach for sharing resources and has heretofore not been utilized.

Other objects and advantages will become apparent when taken into consideration with the following specification and drawings.

It is also an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

It is a first aspect of the present invention to provide a user device comprising: one or more sharing resources for sharing with one or more user devices, wherein the sharing resources are surrendered to a server into a pool of resources managed by the server; and a processor for connecting to the server and participating in a resources allocation event, wherein the resources allocation event comprises one or more comparison processes, wherein the processor is adapted to provide a comparison value for a comparison process, and in the event that the comparison value is within a favourable domain set by the server in real time, the processor would be promoted to participate in a subsequent comparison process, otherwise the processor would be denied for the sharing resources, such that when a halting condition is satisfied, the processor will take control of a portion of the resources in the resources pool which is relinquished by the server.

In a second aspect of the invention, there is provided a method for sharing resources of a plurality of user devices carried out by a server, wherein the method comprising the steps of: collecting one or more resources associated with the user devices into a resources pool; allowing the user devices to participate in a resources allocation event, wherein the resources allocation event comprises a series of comparison processes; receiving comparison values from user devices for a comparison process to determine whether the comparison values fall within a favourable domain set in real time; if the comparison value of a user device falls within the favourable domain set, advancing the user device to participate in a subsequent comparison process, otherwise denying the user device for sharing resources; in the event that a halting condition is satisfied, relinquishing control of the resources pool by allowing each user device which has not been denied for sharing resources to take control of a portion of the resources.

It is a third aspect of the invention to provide a server comprising a processor to carrying a method comprising the steps of: collecting one or more resources associated with the user devices into a resources pool; allowing the user devices to participate in a resources allocation event, wherein the resources allocation event comprises a series of comparison processes; receiving comparison values from user devices for a comparison process to determine whether the comparison values fall within a favourable domain set in real time; if the comparison value of a user device falls within the favourable domain, advancing the user device to participate in a subsequent comparison process, otherwise denying the user device for sharing resources; in the event that a halting condition is satisfied, relinquishing control of the resources in the resources pool by allowing each user device which has not been denied for sharing resources to take control of a portion of the resources.

Preferably, the sharing resources comprises any one or more of: central processing unit, system memory, bandwidth, data storage, operating time, credits, and funds.

Preferably, at the commencement of the resources allocation event, the user device receives an input from a user to set a default comparison value.

Preferably, in each comparison process comprising the step of announcing a query on the server and inviting user devices to provide a comparison value.

Preferably, the query comprises a prediction of an unpredictable event.

Preferably, the unpredictable event relates to a real-time event that will take place in the future.

Preferably, the unpredictable event relates to an expectation value of share resources consumption in a user device.

Preferably, the unpredictable event relates to a sport event.

Preferably, the favourable domain set is determined by the server based on a subset of a sample space representing all the outcomes of the unpredictable event.

Preferably, the comparison value is set to the default value.

Preferably, the comparison value can be overridden by an input from a user.

Preferably, the comparison value comprises a value selected from a finite set.

Preferably, the comparison value comprises a value selected from a binary set.

Preferably, the server is adapted to utilise a portion of the resources in the resources pool.

Preferably, the server refuses to receive any comparison value from a denied user device for any further comparison processes related to the resources allocation event.

Preferably, when the halting condition is satisfied, the server is adapted to divide remaining resources in the resources pool amongst user devices that are not denied for resources sharing.

Preferably, the server is adapted to divide the remaining resources equally.

Preferably, the server is adapted to divide the remaining resources in proportion to resources surrendered by the user device.

Preferably, the halting condition comprises a predefined number of comparison processes has been carried out.

Preferably, the halting condition comprises the number of user devices that has been denied in sharing resources reaches a predefined value.

In yet another aspect of the present invention, there is provided a user device comprising: one or more sharing resources for sharing with one or more user devices, wherein the sharing resources are surrendered to a server into a pool of resources managed by the server; and a processor for connecting to the server and participating in a resources allocation event, wherein the resources allocation event comprises one or more comparison processes, wherein the processor is adapted to provide a comparison value for a comparison process, and in the event that the comparison value is within a favourable domain set by the server in real time, the processor would be promoted to participated in a subsequent comparison process, otherwise the processor would be denied for the sharing resources, such that when a halting condition is satisfied, the processor will take control of a portion of the resources in the resources pool which is relinquished by the server.

Preferably, the sharing resources comprises any one or more of: central processing unit, system memory, bandwidth, data storage, operating time, credits, and funds; wherein at the commencement of the resources allocation event, the user device receives an input from a user to set a default comparison value.

Preferably, each comparison process comprising the step of announcing a query on the server and inviting user devices to provide a comparison value of a prediction of a real-time unpredictable event that will take place in the future.

[0044] Preferably, the unpredictable event relates to an expectation value of share resources consumption in a user device, or a sport event.

[0045] Preferably, when the halting condition is satisfied, the server is adapted to divide remaining resources in the resources pool amongst user devices that are not denied for resources sharing, and wherein the halting condition comprises a predefined number of comparison processes has been carried out, or the number of user devices that has been denied in sharing resources reaches a predefined value.

BRIEF DESCRIPTION OF THE FIGURES

[0046] Fig. 1 is a schematic view of a computer system according to an embodiment of the present invention.

[0047] Fig. 2 is a flow chart of a method according to an embodiment of the present invention.

[0048] Fig. 3 is a flow chart for an example of an alternative use of the method as shown in Fig. 2 related to a rugby league game.

[0049] Fig. 4 is a flow chart for another example of an alternative use of the method as shown in Fig. 2 related to a cricket game.

[0050] Fig. 5 is a flow chart of a process according to an embodiment of the present invention.

DESCRIPTION OF THE INVENTION

[0051] Referring to Fig. 1, a computer system of an embodiment of the present invention is shown to include one or more user devices 10 connected to a cloud server 12. The user device may comprise one or more of a Personal Computer (PC) 14, also known as desktop or workstation which has at least one monitor, a separated computer chassis housing an ATX motherboard or variant thereof having a modem installed thereon, a separated keyboard, and point device, typically a mouse. The user device may also include a portable computer 16, typically known as a laptop computer or notebook computer such as a Xerox NoteTaker™, Compaq™ portable, Macbook

Air™, or Lenovo Thinkpad™ wherein this portable computer comprises a communication module such as modem or network card for connecting to the Internet. Further the user devices may include one or more smart devices such as smart phone 18, smart tablet 20, or smart watch 22.

Most of these user devices have a few underutilised resources. Despite the fact these resources are idle, they still consume similar amounts of energy as they are busy. In time, one or more of the user devices may need a surge in computing power to complete a particular task. The present invention provides a system or method which allows a user device to take over or utilise sharing resources of other user devices.

The user devices are interconnected to a server in a cloud computing environment which comprises a server 24. In a cloud environment, a server may be implemented as a cluster of machines or a collection of computer servers usually maintained by an organization to supply server functionality.

In one embodiment of the present invention as shown in Fig. 2, there is provided a method 30 for sharing resources of a plurality of user devices carried out by a server. As mentioned above, a server may comprise a cluster of machines interconnected with each other. The method starts in step 31.

The server provides an interface for allowing a plurality of user devices for sharing resources. The server may announce that it will host a resources allocation event ahead of time. In another embodiment, the resources allocation event happens on demand of a user device.

In one embodiment, the server may request the user device to surrender a particular type of resource. In another embodiment, the server may allow the user devices to nominate a type of resources for sharing.

The sharing resources comprises any one or more of: central processing unit, system memory, bandwidth, data storage, operating time, credits, and funds. In one embodiment, a user device may surrender a type of resources akin to the type obtained in the end. However, in another environment, a user device may surrender a first type of resources to acquire a second type of resources. For example, a user device may relinquish the control of a portion of memory in order to acquire a larger portion of memory. In another example, a user device may give away a portion of CPU time in exchange for data storage. In a more aggressive environment, the user devices may purchase credit from a service provider and use the credit as a type of resources for sharing. In this situation, the user device does not need to give out any current resources. Further, the user device may acquire multiple sharing resources at the same time. In another further implementation, the server may provide a facility for the user device to purchase credit in real time.

The server 24 started to collect one or more resources associated with the user devices into a resources pool in Step 32. The server 24 is responsible to keep track of all the sharing resources in the resources pool at all time.

In one embodiment, the server only allows each user device to surrender an amount of the sharing resources at the same cost. For example, each user device must surrender exactly 50MByte memory, 5000GFlops, 500MBytpe of data storage, 50Mb bandwidth, 10 credit, etc. In this setting, the user device will expect to receive equally shared return of the sharing resources. In another embodiment, a user device may select an arbitrary amount of resources for sharing and the expected return of the sharing resources will be proportion to the amount given out in relative to the amount of surrendered sharing resources of other user devices.

The server 24 has a cut-off point for receiving sharing resources from user devices. Typically, the service announces or broadcasts a resources allocation event that will occur at a certain time. The cut-off point can be any arbitrary time before the commencement of the resources allocation event. Any user devices missing the cutoff time have to participate in the next resources allocation event.

Before the cut-off time, the server 24 allows the user devices to participate in a resources allocation event and select a default value as shown in Step 33. Each resources allocation event comprises a series of comparison processes.

In one embodiment, each comparison process in Step 34 comprising the step of announcing a query on the server and inviting user devices to provide a comparison value.

In Step 35, the server 24 will verify if a user device has submitted a comparison value. If there is no comparison value entered, the server 24 will set the default value of the user device as the comparison value as shown in Step 36.

In one embodiment, the query comprises system configuration data of the user device include the size of memory in the user device, the CPU type and speed, the bandwidth, the ISP, the Graphic Processing Unit type and speed, the disk space, etc. In one embodiment, the server may directly inquire the user devices regarding the share resources consumption in the user devices to make a decision. In another embodiment, the server may inquire the waiting time of the user devices.

However, it is envisaged that some user devices may return inaccurate information regarding their system configurations. Therefore, the server may from time to time choose to present the queries related to a prediction of an unpredictable event. For example, the server 24 may enquire the next quantum state of an entangled pair of photon within the system. In another embodiment, the query may be as simple as the state of a SR flip-flops system. Typically, the unpredictable event can be carried out in real time by the server.

In another embodiment, the unpredictable event can also relate to a performance sport. For example, the server 24 may invite all user devices to predict the outcome of a Rugby League Match, or other sport match.

The user devices may submit a default response to the server for all queries. For example, the user devices may update a full specification to the server, such that the server does not need to contact the user devices each time a new query is issued. In another embodiment, the user device may select a particular state for the quantum or flip-flop system. In yet another embodiment, the user may select a default team.

In one embodiment, the query will only require a response selected from a binary state. For example, the query may be whether the memory is greater than 2GB. In embodiment, the prediction can be within a range of value. For example, the memory is between 1GB and 2GB. The server may require the user device to make a prediction that falls within a favourable domain, such as the memory is between 1GB and 2GB.

In another embodiment, the server may invite the user device to make a prediction of the next team to score a try during a Rugby League Game.

The user devices may respond for each query individually by submitting a comparison value. In this way, the server 24 may receive comparison values from user devices for a comparison process to determine whether the comparison values fall within a favourable domain set in real time as shown in Step 38.

If the comparison value of a user device falls within the favourable domain, advancing the user device to participate in a subsequent comparison process as shown in Step 40, otherwise denying the user device for sharing resources as shown in Step 39.

In this way, the server 24 may eliminate a number of user devices that have less urgent needs and prioritise user devices that have a more urgent need of the sharing resources. After a sequence of queries or comparison process, the server may reduce the number of eligible user devices.

In every round, the server 24 will check whether a halting condition is satisfied as shown in Step 41. For example, the server may check whether the number of remaining user devices has reduced to an arbitrary number, or the server has made all queries of the system configuration, or the game is finished.

When the halting state is reached, the server 24 will not keep the sharing resources any further but relinquish control of the resources in the resources pool by allowing each user device which has not been denied for sharing resources to take control of a portion of the resources as shown in Step 42, and the process is end in Step 43. The remaining user devices will then have a temporary boost in the resources. In this way, the sharing resources of a user device may be more efficiently and effectively distributed.

If halting condition is not met, the user devices that are not eliminated from the event will proceed to participate in another round of the comparison process as in Step 34.

During the resources allocation event, the server 24 may require extra resources to carry out the task. For example, comparing thousands of system configurations of user devices is a resources intensive task. When the user devices participate in the resources allocation event, the user devices relinquish control of the sharing resources such that the server 24 may use the sharing resources if required.

In another embodiment of the present invention to provide a user device comprising sharing resources and a processor, the sharing resources are allocated by the user device for sharing with one or more user devices such that the sharing resources can be surrendered to a server into a pool of resources managed by the server.

The processor is adapted connecting to the server 24 in order to participate in a resources allocation event. This resources allocation event comprises one or more comparison processes as shown in Step 34. The processor is further adapted to provide a comparison value for a comparison process.

In the event that the comparison value is within a favourable domain set by the server in real time, the processor would be promoted to participate in a subsequent comparison process, otherwise the processor would be denied for the sharing resources as shown in Step 39.

After each comparison process, the server 24 will check whether a halting condition is satisfied as shown in Step 41. If it is, the processor will take control of a portion of the resources in the resources pool which is relinquished within the server by distributing the resources to the remaining user devices as shown in Step 42.

In another embodiment of the present invention, there is provided a server comprising a processor to carrying a method comprising the steps of: (i) collecting one or more resources associated with the user devices into a resources pool; (ii) allowing the user devices to participate in a resources allocation event, wherein the resources allocation event comprises a series of comparison processes; (iii) receiving comparison values from user devices for a comparison process to determine whether the comparison values fall within a favourable domain set in real time.

The server 24 will then determine whether the comparison value of a user device falls within the favourable domain, advancing the user device to participate in a subsequent comparison process, otherwise denying the user device for sharing resources.

After each comparison process, the server will check whether a halting condition is satisfied. If a halting condition is satisfied, relinquishing control of the resources pool by allowing each user device which has not been denied for sharing resources to take control of a portion of the resources.

The present invention and the described preferred embodiments specifically include at least one feature that is industrial applicable.

In another embodiment, the resources sharing system can be used for gaming. Or an analogy of the invention system is now provided in a game form. The objective of the game is to continually select the correct outcome of the next event in the match. This will continue until the Participant makes an incorrect selection, a winner(s) is declared, or the match ends.

The concept of the present invention can be used to improve the computer operating system in the resources allocation such that a user device may receive a boost in spare resources given up by another user device. However, concept of the present invention can be applied in a number of other technical fields. A participant can use a user device to enter a game. This is done by paying an entry fee or credit. This can be compared to the sharing resources.

Thereby the participant enters into a competition with other participants. Each participant will be asked to make a default pick between one of two possible outcomes when they enter the game.

Thereafter, they will choose between one of two possible outcomes for the next event in the match. In this situation, the match is similar to a resources allocation event, and the event in a match is similar to the comparison processes mentioned above.

An incorrect pick will eliminate the participant from the game. Hence, similar to the above algorithm of denying the user devices from sharing resources. A correct pick will advance the participant to the next phase of the game, where their next selection of the same two possible outcomes is required. This will continue until the participant makes an incorrect pick, a winner(s) is declared, or the match ends.

In the following, sport examples are given to discuss a number of different aspects and implementations of the invention, where a list of terms are defined as follows.

Default Pick: A choice the participant needs to make immediately upon entering the game. In the case that they miss lockout for their first pick of the first event of the match or miss a live pick during the match, their default pick will take precedence.

Elimination: When a participant makes an incorrect pick, the participant will be eliminated from the game. Once eliminated from the game that participant cannot reenter the game under any circumstance.

Entry Fee: The participant’s buy-in fee for the game. A participant can have more than one entry. Each entry fee into the game will be for the same value.

Event: A certain aspect within a match that the game will be based upon. E.g. Which team will score the next try?

The Game: The competition where participants will compete by picking the outcome of the next event in the match, until they are eliminated, the match ends, or a winner(s) is determined.

In-Game Lockout: The time during a match that participants have until to confirm their next pick.

Live Picking: The in-game picks being made by the participant on an ongoing basis until they are either eliminated, the match ends, or a winner is determined.

Lockout: The time just before a match starts where no more entries are allowed into the game.

Match: Team A Vs Team B or Player A Vs Player B in any given sport.

Minimum Pool: The nominated minimum amount of money that will be shared by the winning participants, prior to any event commencing. The figure will be displayed prior to each game. Once the initial lockout of each match has passed, the prize pool amount will be greater than or equal to the minimum pool.

Participant: A person who has a registered account, and has entered one or more entries into the game.

Pick: The participant’s pre-determined default pick or the live picking of one of two options, on an ongoing basis while the match is in play.

Pool: The sum of all participant’s entry fees.

Prize Pool: The total amount of money that will be allocated to winning participant(s) for any given game. This will be determined as the pool minus the company’s commission.

Winner: The participant(s) who have made all the correct picks during the match, either via live picking or through the default pick and have remained in the game until the end. There can be more than one winner.

Winning Dividend: The winning dividend will be the prize pool divided equally amongst the winning participant(s) for that given game.

As an example, each participant will pay an entry fee of $10. In this example, we will assume that a participant will only have one entry, with a total investment of $10. Hence, 400 participants would mean there is a pool of $4000.

The host server will keep a percentage of the pool (as an example assume 10%), and the remainder of the pool will be declared as the prize pool and be shared equally among winning participants.

Therefore: Prize pool = $4000 - 10% = $3600.

The game would now be ready to begin and the server may post this prize pool amount as the potential dividend for a sole winning participant.

Shortly before the match begins, (for example: one minute) entry into the game will closed and no more entries will be allowed.

When the participant enters the game, they will be asked to make a default pick between one of two possible outcomes.

For example, in a match of rugby league, the two possible outcomes will be either Team A or Team B. In the game, they will be selecting which team will score the next try. The participant will need to choose Team A or Team B as their default team for the match. This default team will take priority when no live picks are made by the participant during the match. The default team will not be able to be changed during the game. If the participant does not choose their default, the home team will be selected.

Once this is completed, the participant will make a choice between one of two possible outcomes for the first event in the match. They will have up until the lockout time to make their decision.

Once the match has started, the Participant will wait for the outcome of the first event of the match. For example, Team A to score the first try of the match. They will only be able to select their next pick for the next event once their present pick is successful. If unsuccessful, they are eliminated from the game.

Correct picks will always advance the participant to the next phase of the game, where their next pick is required. They will need to make their picks before the next in-game lockout commences. In the case that they miss making their next pick, their default pick will automatically take precedence as their selection. This process will continue until the participant makes an incorrect pick, a winner or winners are declared, or the match ends.

The following example {using the figures from [0088] and [0089]} provides a more specific embodiment of the present invention. In one example, there is provided a game of Rugby League with Team A against Team B and the need to predict which team is going to score next try?

The game begins and Team A scores the first try. Fifty percent of four hundred participants were using a software application of an embodiment of the present invention to pick Team A to score first. This means 200 participants remain in the contest. The other 200 have been eliminated, and cannot re-enter the contest.

Once the first in-game lockout has occurred, the software application will show participants how many entries remain in the contest for the next selection process as well as the current winning dividend if there is no other event. The software application will also show how many selected Team A, and how many selected Team B (incorporating the defaults and picks), for the next event. This will continue for each stage, until a winner is declared.

Progressing in this example, participants have until just before the next in-game lockout to decide who will score the next try; a selection that will be made using the software application. If they miss that time period of selection, their default pick will be selected.

The kick-off takes place and including picks and default’s there is a 70%/30% split towards Team A.

Team A scores again which means that 140 entries (70% of the 200 entries) remain in the game and 60 entries are eliminated.

Again, the participants have until the next in-game lockout to decide who will score the next try. If they miss that time period of selection, their default will be selected.

Team B scores the third try of the match and this time it was an 80%/20% split. This means that there would be 28 entries (20% of the 140 entries) remaining in the game.

This software process continues until the match is complete and/or a winner or a group of winners is determined.

The winner(s) can be determined by three ways. 1) There is only one participant remaining in the contest. Whether their next pick is correct or incorrect will not matter as they are the final entrant and will be declared the winner and receive 100% of the prize pool. 2) The match ends and no more picks are possible. All remaining participants are paid their equal dividend. 3) All remaining participant make their last pick incorrectly. While technically there is no sole winner, the system will pay out on a countback to the last group of entries before they were all unsuccessful. This is due to the fact that in this case, all remaining participants have collectively made an incorrect pick, meaning no one is left in the game.

All winners will receive an equal share of the Prize Pool. This will be known as the winning dividend. Hence, Prize Pool / Winner(s) = Winning Dividend.

Reference is now made to Fig. 3 which depicts a flow chart of an alternative embodiment of a game implementation of the present invention. In this scenario, the match is Team A vs Team B. The game event to predict is the next team to score. Arrows marked with “S” indicate that the Participant A’s pick was successful and Participant A stays in the game, moving onto the next round. Arrows marked with “F” indicate that the Participant A’s Pick was unsuccessful and Participant A is eliminated from the game. Arrows marked with “N”, indicate a continuation onto the next stage of the game.

Each participant is required to submit an entry fee into a game’s pool.

Participant A, who has already made an account with the host system, has an account balance of a minimum of $10 and chooses to enter one entry into the game for the match through a user device running a software application of an embodiment of the present invention.

Upon entry into the game, the Participant A will use the user device to pick a default team which they believe will be scoring in the case that they miss any part of the game via a user interface of the software application.

In this example, the Participant A selects the Team A as the default. Participant A also chooses the Team A to be the first team to score in the match. As the Participant A waits for kick-off, they can see the number of entries are building in the pool. Just before kick-off, lockout will occur and no other entries will be accepted.

Once lockout occurs, the Participant A will now compete in the game, but cannot change their default team or their first pick. The Participant A can see what the percentage of entries are that have picked Team A to score first and the percentage that picked Team B to score first.

After the kick-off, there are hypothetically 400 entries in the pool. The minimum pool figure has been passed, the pool is $4000, the prize pool $3600.

Referring to Fig.3: After the participants choose a team (or a default team is chosen if the participant did not make a choice), a game event will occur. As shown in Step 101 in Fig. 3, the game event started and the Team A scored in the 10th minute. For the participants who did not make the correct pick, they will be eliminated from the game in Step 102. As was the previous example, 200 entries who picked Team B (50%) are eliminated from the game and 200 entries are left to play the next round.

In Step 103, Participant A and all other participants still left in the game after Step 101 have until the next in-game lockout to select which team will be the next to score. In the case that they missed the in-game lockout, their pre-match default will take precedence. Participant A chooses Team A again in this example. We assume that including Participant A, 70% (140 entries) of the remaining entries have chosen Team A and the other 30% (60 entries) have chosen Team B.

In Step 104, the event of Step 103 has an outcome. In this example, the Team A scored again in 18th minute. For the 30% of entries who did not correctly select this, they will be eliminated from the game (Step 105). In this example, 60 entries are eliminated from the game and 140 entries are left to play the next round.

In Step 106, the Participant A and all other participants left standing after the second try have until the next in-game lockout to select which team will be the next to score. If a participant misses the in-game lockout their pre-match default pick will take precedence. Participant A chooses Team B this time. Including Participant A, there are 80% (112 entries) of the remaining 140 entries who have chosen Team A and 20% (28 entries) who have chosen Team B.

In Step 107, the event of Step 106 has an outcome. In this example, the Team B scored in the 39th minute. The entries who selected incorrectly are eliminated from the game as shown in Step 108. In this example, 112 entries are eliminated from the game and 28 entries are left to play the next round.

In Step 109, the Participant A and all other participants left standing after the third try have until the next in-game lockout to select which team will be the next to score. If a participant misses the in-game lockout their pre-match default pick will take precedence. Participant A chooses Team B again. Including Participant A, there are 50% (14 entries) of the remaining entries who have chosen Team A and 50% (14 entries) who have chosen Team B.

In Step 110, the event of Step 109 has an outcome. In this example, the Team B scored again in the 57th minute. The entries who selected incorrectly are eliminated from the game as in Step 111. In this example, 14 entries are eliminated from the game and 14 entries are left to play the next round.

In Step 112, the Participant A and all other participants left standing after the fourth try have until the next in-game lockout to select which team will be the next to score. If a participant misses the in-game lockout their pre-match default pick will take precedence. Participant A chooses Team B again. Including Participant A, there are ~57% (8 entries) of the remaining 14 entries who have chosen Team A and ~43% (6 entries) who have chosen Team B.

In Step 113, the event of Step 112 has an outcome. In this example, the Team B scored again in the 65th minute. The entries who selected incorrectly are eliminated from the game as shown in Step 114. In this example, 8 entries are eliminated from the game and 6 entries are left to play the next round.

In Step 115, there are no more tries scored by either team in the match. The halting condition is satisfied as the game comes to an end. This means that the 6 entries left (including Participant A) will share the prize pool. In this embodiment, the prize pool will be shared equally and hence each of the remaining entries will receive a winning dividend of $600 each.

Reference is now made to Fig. 4, in which another example of the present invention implemented as a game is described. The game relates to a hypothetical Cricket fixture between Team A and Team B. The predicting event is who will be the next batsman to be dismissed.

Each participant is required to submit an entry fee into the game’s pool.

The Participant A who has already made an account with the host server, has a minimum balance of $10 in his account and chooses to enter one entry into the game for the match.

Upon entry into the competition, the Participant A selects a default option for each team in case Participant A misses part of the game. For Cricket, the participant will select either option A) the batsman higher in the order, or option B) the new batsman/the batsman lower in the order.

In this game, Team A will bat first. The Participant A has selected the batsman lower in the order (Option B) as his default for Team A.

As the participants wait for lockout, they can see the amount of entries are building in the pool through a user device running software of an embodiment of the present invention.

Once lockout occurs, no more participants can enter the game. By the time of lockout, there are 400 entries in the pool. The pool is $4000, and the prize pool $3600.

When the two opening batsmen of the Team A are confirmed, the user device running the software application of the present invention receives a notification of who the two openers are. The participant then has the ability to select either batsman to be the next one to be dismissed.

The Participant A selects batsman B to be the next (first) batsman out. After a selection is made, a participant cannot change the pick. The participants can see that 60% of entries have picked Batsman 1 (Option A) to be dismissed first and 40% have picked Batsman 2 (Option B) to be dismissed first.

After each wicket, the participant will receive a notification of the next batsman in and have the ability to choose who will be dismissed next. If a participant misses the selection, the default (the batsman lower down the order) will take precedence. A running example of the game itself in theoretical action is depicted in Fig. 4 wherein the Arrows marked with “S” indicate that a Participant’s pick was successful and the Participant stay in the game, moving onto the next round; Arrows marked with “F” indicate that the participants pick was unsuccessful and they are eliminated from the game. Arrows marked with “N” indicate a continuation onto the next stage of the game.

Reference is now made to Fig. 4. In Step 120, Batsman 1 and 2 are in. In Step 121, the two opening batsmen of Team A walk out to bat. Batsman 1 is on strike. Batsman 2 is down the non-strikers end. Shortly before the match begins, the system does not allow any more participants into the game. In this example, there are 400 entries to start the game. There are 60% (240 entries) of entries who selected Batsman 1 to be dismissed first and 40% (160 entries) of entries who selected Batsman 2 to be dismissed first.

In Step 122 the event of Step 121 has an outcome. In this example, Batsman 2 was dismissed in the 3rd over of the first innings of the match. The participants who made the incorrect pick are eliminated from the game as in Step 123. In this example, 240 entries are eliminated from the game and 160 entries are left to play the next round.

In Step 124, Batsman 1 and Batsman 3 are in. In Step 125, the Participant A and all other participants left standing after the 1st wicket have until the next in-game lockout to select which player will be the next one to be dismissed. If a participant misses the in-game lockout their pre-match default pick will take precedence. In this example, Participant A chooses Batsman 1 (Option A). Including the Participant A, there are 50% (80 entries) of the remaining entries who have chosen Batsman 1 (Option A) and 50% (80 entries) who have chosen Batsman 3 (Option B).

In Step 126 the event of Step 125 has an outcome. In this example, Batsman 1 was dismissed in the 10th over of the first innings of the match. The participants who made the incorrect pick are eliminated from the game as in Step 127. In this example, 80 entries are eliminated from the game and 80 entries are left to play the next round.

In Step 128, Batsman 3 and Batsman 4 are in. In Step 129, Participant A and all other participants left standing after the 2nd wicket have until the next in-game lockout to select which player will be the next one to be dismissed. If a participant misses the in-game lockout their pre-match default pick will take precedence. In this example, Participant A chooses Batsman 4 (Option B). Including the Participant A, there are 40% (32 entries) of the remaining entries who have chosen Batsman 4 (Option B) and 60% (48 entries) who have chosen Batsman 3 (Option A).

In Step 130 the event of Step 129 has an outcome. In this example, Batsman 4 was dismissed in the 15th over of the first innings of the match. The participants who made the incorrect pick are eliminated from the game as in Step 131. In this example, 48 entries are eliminated from the game and 32 entries are left to play the next round.

In Step 132, Batsman 3 and Batsman 5 are in. In Step 133, Participant A and all other participants left standing after the 3rd wicket have until the next in-game lockout which player will be the next one to be dismissed. If a participant misses the in-game lockout their pre-match default pick will take precedence. In this example, Participant A chooses Batsman 5 (Option B). Including Participant A, there are 75%(24 entries) of the remaining entries who have chosen Batsman 5 (Option B) and 25% (8 entries) who have chosen Batsman 3 (Option A).

In Step 134 the event of Step 133 has an outcome. In this example, Batsman 5 (Option B) was dismissed in the 18th over of the first innings of the match. The participants who made the incorrect pick are eliminated from the game as in Step 135. In this example, 8 entries are eliminated from the game and 24 entries are left to play the next round.

In Step 136, Batsman 3 and Batsman 6 are in. In Step 137, Participant A and all other participants left standing after the 4th wicket have until the next in-game lockout to select which player will be the next to be dismissed. If a participant misses the ingame lockout for the next ball, their pre-match default pick will take precedence. In this example, the Participant A chooses Batsman 3 (Option A). Including Participant A, there are 33%(8 entries) of the remaining entries who have chosen Batsman 6 (Option A) and 67% (16 entries) who have chosen Batsman 6 (Option B).

In Step 138 the event of Step 137 has an outcome. In this example, Batsman 3 (Option A) was dismissed in the 20th over of the first innings of the match. The participants who made the incorrect pick are eliminated from the game as in Step 139. In this example, 16 entries (33%) are eliminated from the game and 8 entries are left to play the next round.

In Step 140, there are no more wickets taken in the match. The halting condition is satisfied as the game comes to an end. This means that the 8 entries left will share the prize pool. In this embodiment, the prize pool will be shared equally and hence each of the remaining entries will each receive a winning dividend of $450 each.

In another aspect of the invention, the invention related to a process as disclosed in the flow chart as shown in Fig. 5.

Participant A has to set up an account in the system with sufficient funds. The account can be accessed by logging in from a user device using a username and a password as in Step 150.

In Step 151, after logging in, Participant A can enter in a game lobby interface displayed on the user device, where there are a number of games to choose from (with different sized entry fees and for a variety of different sports).

In Step 152, Participant A then selects which game to play from the user interface of the user device.

In Step 153, Participant A activates the game and confirms the payment of entry fee by clicking the user interface on the user device. Once this is done, the system confirms that Participant A is now officially entered in the game.

In Step 154, as soon as the entry fee has been paid, Participant A will be led to an interface where the participant must choose a default option. In one embodiment, the default option must be either Option A or Option B.

In Step 155, Participant A is asked to choose a first pick out of Option A or Option B for the coming event. If no choice is made by Participant A, the default option will take precedence for their first choice.

In Step 156, a Lockout occurs. On the user device, there will be a countdown on the user interface which will be visible to all users with or without a user account. At this point, no more entries are allowed in the game. All participants who have already bought into the game can see the number of entries and the total prize pool dividend.

The participants can also see how many participants have selected Option A or Option B for the next game-specific event.

In Step 157, the system, and the participants will wait for the next game-specific event of the match to occur.

In Step 158, once the game-specific event occurs, each participant will be notified whether their pick was successful or not. If it is successful, the participant will receive another notification to select the next outcome (Option A and Option B) of the coming event. If a pick is not made before in-game lockout, the participant’s default pick will take precedence. If a participant is not successful, that participant is eliminated from this game.

In Step 159, as soon as the in-game lockout occurs, participants can no longer change their pick. On the interface of the user device, the participants can see the amount of entries who selected Option A or Option B as well as the corresponding potential winning dividends in the event that no more game-specific events occur before the end of the game.

In Step 160, the system, and the participants will wait for the next game-specific event of the match to occur.

In Step 161, once the game-specific event occurs, each participant will be notified whether their pick is successful or not. If it is successful, the participant will receive another notification to select the next outcome (Option A and Option B) of the coming event. If a pick is not made before in-game lockout, the participant’s default pick will take precedence. If a participant is not successful in the pick, the participant will be eliminated from this game.

In Step 162, as soon as the in-game lockout occurs, participants can no longer change their pick. On the interface of the user device, the participants can see the amount of entries who selected Option A or Option B as well as the corresponding potential winning dividends in the event that no more game-specific events occur before the end of the game.

In Step 163, this selection of outcomes of this identical game-specific events process continues until the game ends or there is a winner or a group of winners.

In Step 164, all winners will receive a notification advising the number of winners the amount of the winning dividend.

In Step 165, soon after the match is complete, winning participants will be paid their winning dividend.

Using the same principles as shown in Fig. 3 and Fig. 4, the processes of the game can be replicated throughout a number of aspects of any given sport. This as long as there is a similar sequential phase whereby participants are either eliminated or proceed into the next round through a series of binary selections.

While the variety of sports and games are endless, some examples that can be included but not limited to in the future include:

Tennis - Which player will win the next game or set?

American Football - Which team will score the next touchdown?

Baseball - Which team will score the next run?

Rugby Union - Which team will score the next try?

Darts - Which player will win the next game or set? AFL - Which team will kick the next goal?

Soccer - Which team will score the next goal?

Claims (5)

1. A user device comprising: one or more sharing resources for sharing with one or more user devices, wherein the sharing resources are surrendered to a server into a pool of resources managed by the server; and a processor for connecting to the server and participating in a resources allocation event, wherein the resources allocation event comprises one or more comparison processes, wherein the processor is adapted to provide a comparison value for a comparison process, and in the event that the comparison value is within a favourable domain set by the server in real time, the processor would be promoted to participated in a subsequent comparison process, otherwise the processor would be denied for the sharing resources, such that when a halting condition is satisfied, the processor will take control of a portion of the resources in the resources pool which is relinquished by the server.

2. A user device according to Claim 1, wherein the sharing resources comprises any one or more of: central processing unit, system memory, bandwidth, data storage, operating time, credits, and funds; wherein at the commencement of the resources allocation event, the user device receives an input from a user to set a default comparison value.

3. A user device according to Claim 1 or Claim 2, wherein each comparison process comprising the step of announcing a query on the server and inviting user devices to provide a comparison value of a prediction of a real-time unpredictable event that will take place in the future.

4. A user device according to any one of Claim 1 to 3, wherein the unpredictable event relates to an expectation value of share resources consumption in a user device, or a sport event.

5. A user device according to any one of Claims 1 to 4, wherein when the halting condition is satisfied, the server is adapted to divide remaining resources in the resources pool amongst user devices that are not denied for resources sharing, and wherein the halting condition comprises a predefined number of comparison processes has been carried out, or the number of user devices that has been denied in sharing resources reaches a predefined value.