FIELD OF INVENTION

The present invention relates to a system and method for crediting a predictive entity.

BACKGROUND

In relation to investment related platforms or portals, currently, there are social trading platforms (aka prediction markets) which can provide a virtual environment to carry out trading of objects (can be real world objects). Such platforms do not operate in a way where users/traders make specific calls of individual objects with price buy and sell positions over a time period.

In addition, there are subscription-based platforms which provide access to an investment analyst’s newsletter or published portfolio, but the contents provided by the analyst typically include disclaimers and minimises all liability for providing incorrect or flawed information. As such, the analyst is likely to encounter difficulties providing basis on an accuracy of the information being provided.

Furthermore, other investment related platforms have contents that can be manipulated over the course of time, namely by deletion or alteration of contents after submission, which leads to substantial uncertainty in relation to the accuracy of the contents on the platform.

Moreover, even though it is now possible to‘follow’ or‘subscribe’ to an entity’s portfolio of objects (equities, commodities, etc) whereby the user can invest in the same portfolio, the user currently lacks critical insights pertaining to the buy and sell positions of an object.

In view of the aforementioned issues, it is evident that improvements for many aspects are desired.

SUMMARY

In a first aspect, there is provided a system for crediting a predictive entity, the system comprising at least one data processor configured to:

transmit, from a predictive entity device, a blueprint to a central server;

upload, to the central server, the blueprint;

associate, at the central server, at least one transaction to the blueprint;

upload, to an immutable ledger, the blueprint;

determine, at the central server, if the blueprint is accurate;

transmit, from the central server, payment instructions; and track, at the central server, a performance of the predictive entity.

In a second aspect, there is provided a data-processor implemented method for crediting a predictive entity, the method comprising:

transmitting, from a predictive entity device, a blueprint to a central server;

uploading, to the central server, the blueprint;

associating, at the central server, at least one transaction to the blueprint;

uploading, to an immutable ledger, the blueprint;

determining, at the central server, if the blueprint is accurate; transmitting, from the central server, payment instructions; and tracking, at the central server, a performance of the predictive entity.

In a third aspect, there is provided a central server configured for use in a method for crediting a predictive entity, the central server including at least one data processor configured to:

receive, from a predictive entity device, a blueprint;

associate, at least one transaction to the blueprint;

transmit, to an immutable ledger, the blueprint;

determine, if the blueprint is accurate;

transmit, payment instructions; and

track, a performance of the predictive entity.

In a final aspect, there is provided a non-transitory computer readable storage medium embodying thereon a program of computer readable instructions which, when executed by one or more processors of a central server, cause the central server to perform a method for crediting a predictive entity, the method being embodied in the steps of:

receive, from a predictive entity device, a blueprint;

associate, at least one transaction to the blueprint;

transmit, to an immutable ledger, the blueprint;

determine, if the blueprint is accurate;

transmit, payment instructions; and

track, a performance of the predictive entity.

It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting.

DESCRIPTION OF FIGURES

A non-limiting example of the present invention will now be described with reference to the accompanying drawings, in which:

FIG 1 is a schematic view of an example system for crediting a predictive entity;

FIG 2 is a process flow of a method for crediting a predictive entity;

FIG 3 is a schematic view of an example server of FIG 1 ; and

FIG 4 is an example process flow of step 270 of FIG 2. DETAILED DESCRIPTION

The present invention discloses a system and method for crediting a predictive entity, whereby“crediting” the predictive entity can be in the form of a quantitative gain in a financial manner and/or a quantitative gain in a reputation/credibility of the predictive entity. In addition, the present invention provides a framework whereby all entries by the predictive entity cannot be tampered, and correspondingly, the predictive entity will have to be cognizant of contents of the entries provided by the predictive entity as the contents will not be amendable. Moreover, predictive entities that are positively credited will enjoy benefits of the quantitative gain in reputation/credibility, while users of the system and method are able to have confidence in relation to the entries provided by the predictive entity.

It should be appreciated that the term“predictive entity” is intended to include a natural person or computer implemented software providing forecasted information, whereby the information can be related to, for example, financial forecasts, e-gaming forecasts, sporting event forecasts, and the like. In the described embodiments of the invention, an emphasis is made for financial forecasts, but this should not be viewed to limit the invention to solely financial forecasts.

Furthermore, the term“blueprint” is intended to include data storing forecasted information, while “crediting” is intended to include, for example, payment of all sorts of currency, attributing of favourable feedback, and so forth.

Referring to FIG 1 , there is shown an example of a system 100 for crediting a predictive entity. In this example, the system 100 includes a central server 140, a plurality of user devices 120, a predictive entity device 1 10 and a blockchain network 130, all connected to a communications network 150. The blockchain network 130 is configured to provide an immutable ledger. In some embodiments, the blockchain network 130 can be replaced by a storage repository which does not allow, using hardware, software (for example, using a particular graphical user interface), or a combination of both, tampering and changing of data stored at the storage repository. The storage repository can be administered by an entity administering to a platform accessible to both the plurality of user devices 120, and the predictive entity device 1 10. The central server 140, the plurality of user devices 120, the predictive entity device 1 10 and the blockchain network 130 are communicatively connected to each other via the communications network 150. Each of the central server 140, the plurality of user devices 120, the predictive entity device 1 10 and the blockchain network 130 can be connected to the communications network 150 either wirelessly or via a cabled connection. The communications network 150 can be of any appropriate form, such as the Internet and/or a number of local area networks (LANs). The central server 140 is able to communicate within the system 100 over the communications network 150 using standard communication protocols.

The predictive entity device 1 10 and user devices 120 can be, for example, smart phones with the capability of running software applications which can enable different functionalities for users of the smart phones to interface with the central server 140, laptop computers, desktop computers and so forth.

CENTRAL SERVER 140

The central server 140 is typically administered by an entity operating the method and system for crediting a predictive entity. The central server 140 typically carries out processes to enable the carrying out of the method for crediting a predictive entity while receiving and transmitting relevant data. While the central server 140 is illustrated as a single computing system in FIG 3, it should be appreciated that the central server 140 can be a distributed set-up utilising a plurality of computing systems.

The components of the central server 140 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 150 for communication.

In the example shown in FIG 3, the central server 140 is a commercially available server computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and/or methods executed or performed by the central server 140 are implemented in the form of programming instructions of one or more software components or modules 322 stored on non-volatile (e.g. hard disk) computer-readable storage 324.

The central server 140 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a BUS 335:

1. random access memory (RAM) 326;

2. at least one computer processor 328, and

3. external computer interfaces 330:

a. universal serial bus (USB) interfaces 330a (at least one of which is connected to one or more user-interface devices, such as a keyboard, a pointing device (e.g., a mouse 332 or touchpad),

b. a network interface connector (NIC) 330b which connects the central server 140 to the data communications network 150; and c. a display adapter 330c, which is connected to a display device 334 such as a liquid-crystal display (LCD) panel device.

The central server 140 includes a plurality of standard software modules, including:

1. an operating system (OS) 336 (e.g., Linux or Microsoft Windows);

2. web server software 338 (e.g., Apache, available at http://www.apache.org);

3. Javascript or Python modules 340; and

4. structured query language (SQL) modules 342 (e.g., MySQL, available from http://www.mysql.com), which allow data to be stored in and retrieved/accessed from an SQL database 316.

Together, the web server 338, Javascript module 340, and SQL modules 342 provide the central server 140 with the general ability to allow users with the mobile phones and computing devices equipped with standard web browser software to access the central server 140 and in particular to provide data to and receive data from the database 316. It will be understood by those skilled in the art that the specific functionality provided by the central server 140 to such users is provided by scripts accessible by the web server 338, including the one or more software modules 322 implementing the processes performed by the central server 140, and also any other scripts and supporting data 344, including markup language (e.g., HTML, XML, Java) scripts, and the like.

The boundaries between the modules and components in the software modules 322 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. Furthermore, the operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention. Alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field- programmable gate array (FPGA), the design of a gate array or full-custom application- specific integrated circuit (ASIC), or the like.

Respective steps of processes of the central server 140 may be executed by a module (of software modules 322) or a portion of a module. The processes may be embodied in a non-transient machine - readable and/or computer-readable medium for configuring a computer system to execute the method. The software modules may be stored within and/or transmitted to a computer system memory to configure the central server 140 to perform the functions of the module.

The central server 140 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via input/output (I/O) devices 330. A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.

BLOCKCHAIN NETWORK 130

The blockchain network 130 is a typical distributed data processing network which underpins the method and system for crediting a predictive entity. The blockchain network 130 is configured to provide an immutable ledger. It should be appreciated that the blockchain network 130 can be within the communication network 150, but it is shown as a separate component in FIG 1 for the sake of clarity. One purpose for the use of the blockchain network 130, in manner which is typically known, is as a distributed ledger that can record transactions (data exchanges) between two parties efficiently and in a verifiable and permanent way. The permanence of the transactions is advantageous in relation to storing of records, which will be evident from subsequent portions of the description.

Referring to FIG 2, there is shown a method 200 for crediting a predictive entity. The method 200 will be described with reference to the components of system 100 for illustrative purposes, but the method 200 can be carried out using other systems as appropriately configured.

For the purpose of illustration, it is assumed that the method 200 is performed at least in part using one or more electronic processing devices such as a suitably programmed microcontroller forming part of the central server 140 in communication with the user devices 120, the predictive entity device 1 10, and so forth.

In addition, when describing the method 200, a term blueprint is used. The term blueprint is used to refer to a forecast by a predictive entity, whereby parameters of the forecast transaction are visible. For example, for a financial forecast, the parameters include, target price for a stock, trading timeframe, buy-in price, amount staked on the stock, amount staked on the blueprint and so forth. It should be appreciated that there are similar parameters for different types of forecasts. As a further example, for a sporting event (football) forecast, the parameters include, target number of goals, whether extra time is needed, win odds, amount staked on the match, amount staked on the blueprint and so forth. Thus, the blueprint is adaptable depending on forecast type.

At step 210, the predictive entity uses the predictive entity device 1 10 to input requisite parameters of a blueprint before transmitting the blueprint for uploading to a portal, the portal being hosted by the central server 140. It should be noted that the portal can be a forecasting-centric portal accessed by users seeking forecasting information. It should be appreciated that the inputting of the requisite parameters by the predictive entity for the blueprint is carried out using an appropriate graphical user interface which can be configured/customised for different forecast types. The transmission of the blueprint also can also include transmission of a request to upload the blueprint to the portal. At step 220, the blueprint is then uploaded to the central server 140, such that the blueprint can be accessed by users of the portal. Subsequently, at step 230, the central server 140 associates transactions pertaining to the blueprint, whereby the transactions can relate to either requests to access the blueprint, or stakes by the prediction entity on the blueprint. This is because users of the portal are able to make payment to gain access to a blueprint at the portal. In some embodiments, there may be a multi-tier system where different levels of access to the blueprint is available for the users. A lowest level of access indicates minimal exposure to the forecasted information of the blueprint while a highest level of access indicates maximum exposure to the forecasted information of the blueprint. For example, when the payment made by the users is defined in relation to a proportion of the stake by the predictive entity, a payment defined by a higher proportion of the stake results in the users having a higher level of access to the blueprint. The payment can be in the form of either fiat currency or cryptocurrency. Similarly, the predictive entity is able to place a stake on the accuracy of the blueprint, whereby payout is by an administrator of the portal should the predictive entity make an accurate prediction. In some embodiments, a higher the value of the stake placed by the predictive entity, the more confident the predictive entity is in relation to the blueprint. It should be appreciated that the payment by the user can be a mechanism configured to attract users to the portal. For example, early adopter users of the portal can enjoy a larger payout for their payment, bulk payments for multiple blueprints can enjoy a discount, and so forth. At step 240, the central server 140 then uploads the blueprint in a typical manner to an immutable ledger, the blockchain network 130 being an example, whereby the blueprint and correspondingly, the parameters of the blueprint are passed through the blockchain network 130 and forms part of the blockchain database. In this regard, the blueprint is not able to be altered or deleted, even when the portal is no longer in operation. In some embodiments, the blockchain network 130 can be replaced by a storage repository which does not allow, using hardware, software (for example, using a particular graphical user interface), or a combination of both, tampering and changing of data stored at the storage repository. The storage repository can be administered by an entity administering to a platform accessible to both the plurality of user devices 120, and the predictive entity device 1 10.

At step 250, typically after the trading timeframe defined in the parameters of the blueprint, the central server 140 determines if the forecast in the blueprint is accurate. Accuracy can be defined to be a percentage of correct parameters. The blueprint can be considered as accurate as long as, for example, more than 80% of the parameters are correct, more than 55% of the parameters are correct, and so forth. During instances where the blueprint only has one parameter (that is, a binary situation), it should be appreciated that there are no partially correct outcomes in those circumstances.

If the blueprint is determined to be accurate, at step 260, the central server provides instructions to ensure that payment from the transactions associated with the blueprint is made to a designated account of the predictive entity. The payment will include pay-outs to the predictive entity for stakes made on the blueprint. As mentioned earlier, the payment can be in the form of fiat currency or cryptocurrency.

If the blueprint is determined to be inaccurate, at step 270, the central server refunds payment to a user’s pre-defined account from the transactions associated with the blueprint except for the stakes on the blueprint made by the prediction entity. In some embodiments, refunds to users will include a proportion of the stake by the predictive entity on the blueprint, leading to refunds being greater than an amount paid by the users. The exact amount refunded to the users may be determined by various factors such as, for example, time accessing the blueprint, order, total number of users that accessed the blueprint, user categorisation (eg. high volume user), or some other variation. As such, users do not incur a cost if the blueprint is determined to be inaccurate. In addition, even though a cost is incurred for the user if the blueprint is determined to be accurate, the user potentially is able to make a bigger profit from utilising the parameters provided in the blueprint. It should be appreciated that the refund need not be a full refund and can be a portion of the full amount, for example, to cater for administrative fees. It should be appreciated that the refund can be in the form of either fiat currency or cryptocurrency.

Referring to FIG 4, there is shown a further break-down of the step 270. In this example, at step 272, it is determined whether the predictive entity placed a stake on the blueprint. If so, at step 274, the central server determines a proportion of the stake to pay the user, whereby the actual proportion can depend on factors such as, for example, time accessing the blueprint, order, total number of users that accessed the blueprint, user categorisation (eg. high volume user) and so forth. If the predictive entity did not place a stake on the blueprint, at step 276, the central server determines the payment made by the user to access the blueprint, as well as the stake component (if applicable) to determine an appropriate amount to refund to the user. At step 278, the central server then transmits the appropriate amount to the user’s pre-defined account as a refund.

Subsequently, at step 280, the central server tracks and stores a performance of each predictive entity, specifically in relation to an accuracy rate for blueprints provided by each predictive entity, such that the users to the portal is able to access performance records of each predictive entity. Typically, the performance for the predictive entity is tracked by monitoring the predictive entity for a minimum number of blueprints such that the predictive entity is able to have a track record. For example, there can be a ranking list of predictive entities, whereby the predictive entities can be ranked based on a quantity of “accurate” blueprints or a percentage of “accurate” blueprints. Ensuring access to the performance records allows users to gain more insights in relation to which blueprints they should access with a fee. The user can then use the blueprints to decide on whether to follow the forecast of the predictive entity. It should be appreciated that while the method 200 discloses the processing of a single blueprint, it is possible for the predictive entity to provide a bundle of blueprints at a single instance. In this regard, when the bundle of blueprints is provided, each blueprint can be processed sequentially or simultaneously.

The above described system 100 and method 200 provide a number of advantages. One advantage relates to an inability to amend/tamper with contents of blueprints. This perceived permanent/immutable nature of the blueprints provides users with an assurance of the contents in the blueprints. In addition, the permanent nature of the blueprints consequently provides users with an assurance of a track record of a predictive entity. Moreover, the system 100 and method 200 also incentivizes prediction entities to share accurate forecasts (the prediction entities get a fee from users seeking access to their blueprints when the forecasts are accurate) and the users enter into a situation with a favourable outcome regardless of an accuracy of the forecasts since there is a refund component for the users who are seeking access to the blueprints.

Throughout this specification and claims which follow, unless the context requires otherwise, the word“comprise”, and variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers. Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.