10. Devices of the backtesting system 10 may interconnect via wired connections, wireless connections, or a combination thereof.

Referring now to FIG. 2, shown therein is a diagram of an exemplary embodiment of the user device 18 of the backtesting system 10 constructed in accordance with the present disclosure. In some embodiments, the user device 18 may include, but is not limited to, implementations as a personal computer, a cellular telephone, a smart phone, a network-capable television set, a tablet, a laptop computer, a desktop computer, a network-capable handheld device, a server, a digital video recorder, a wearable network-capable device, a virtual reality/augmented reality device, and/or the like.

In some embodiments, the user device 18 may include one or more input device 50 (hereinafter “input device 50”), one or more output device 54 (hereinafter “output device 54”), one or more processing component 58 (hereinafter “user processor 58”), one or more communication device 62 (hereinafter “communication device 62”) capable of interfacing with the network 26, one or more memory 66 (hereinafter “user memory 66”) storing processor-executable code and/or user application(s) 74 (hereinafter “user application 74”). The user application 74 may include, for example, a web browser capable of accessing a website and/or communicating information and/or data over a wireless or wired network (e.g., the network 26), and/or the like. The input device 50, output device 54, user processor 58, communication device 62, and user memory 66 may be connected via a path 70 such as a data bus that permits communication among the components of user device 18.

The user processor 58 may be implemented as a single processor or multiple processors working together, or independently, to execute the user application 74 as described herein. It is to be understood, that in certain embodiments using more than one user processor 58, the user processors 58 may be located remotely from one another, located in the same location, or comprising a unitary multi-core processor. The user processors 58 may be capable of reading and/or executing processor-executable code and/or capable of creating, manipulating, retrieving, altering, and/or storing data structures into the user memory 66.

Exemplary embodiments of the user processor 58 may include, but are not limited to, a digital signal processor (DSP), a central processing unit (CPU), a field programmable gate array (FPGA), a graphics processing unit (GPU), a neural processing unit (NPU), a microprocessor, a multi-core processor, an application specific integrated circuit (ASIC), combinations thereof, and/or the like, for example. The user processor 58 may be capable of communicating with the user memory 66 via the path 70 (e.g., data bus). The user processor 58 may be capable of communicating with the input device 50 and/or the output device 54. The user processor 58 may include one or more user processor 58 working together, or independently, and located locally, or remotely, e.g., accessible via the network 26.

The user memory 66 may be one or more non-transitory processor-readable medium. The user memory 66 may store the user application 74 that, when executed by the user processor 58, causes the user device 18 to perform an action such as communicate with or control one or more component of the user device 18 and/or, via the network 26, the backtesting device 22. The user memory 66 may be one or more user memory 66 working together, or independently, to store processor-executable code and may be located locally or remotely, e.g., accessible via the network 26.

The input device 50 may be capable of receiving information input from the user 14 and/or user processor 58, and transmitting such information to other components of the user device 18 and/or the network 26. The input device 50 may include, but is not limited to, implementation as a keyboard, a touchscreen, a mouse, a trackball, a microphone, a camera, a fingerprint reader, an infrared port, an optical port, a cell phone, a smart phone, a PDA, a remote control, a fax machine, a wearable communication device, a network interface, combinations thereof, and/or the like, for example. The input device 50 may include the primary user interface 30 on the user device 18.

The output device 54 may be capable of outputting information in a form perceivable by the user 14 and/or user processor 58. Implementations of the output device 54 may include, but are not limited to, a computer monitor, a screen, a touchscreen, a speaker, a website, a television set, a smart phone, a PDA, a cell phone, a fax machine, a printer, a laptop computer, a haptic feedback generator, an olfactory generator, combinations thereof, and the like, for example. It is to be understood that in some exemplary embodiments, the input device 50 and the output device 54 may be implemented as a single device, such as, for example, a touchscreen of a computer, a tablet, or a smartphone. It is to be further understood that as used herein the term user (e.g., the user 14) is not limited to a human being, and may comprise a computer, a server, a website, a processor, a network interface, a user terminal, a virtual computer, combinations thereof, and/or the like, for example.

The communication device 62, in communication with the user processor 58, may interface with the network 26. The network 26 may permit bi-directional communication of information and/or data between the user device 18 and/or the backtesting device 22. The network 26 may interface with the backtesting device 22 and/or the user device 18 in a variety of ways. For example, in some embodiments, the network 26 may interface by optical and/or electronic interfaces, and/or may use a plurality of network topographies and/or protocols including, but not limited to, Ethernet, UDP/TCP/IP, circuit switched path, combinations thereof, and/or the like, as described above. For example, the user processor 58 may be capable of communicating via the network 26 by exchanging signals (e.g., analog, digital, optical, and/or the like) via one or more port (e.g., physical or virtual ports) using a network protocol to provide updated information to the backtesting device 22 (e.g., to a backtesting application 90 (described below) executed on the backtesting device 22).

Referring now to FIG. 3, shown therein is a diagram of an exemplary embodiment of the backtesting device 22 constructed in accordance with the present disclosure. The backtesting device 22 may include one or more device that execute(s) one or more application or service in a manner described herein. In the illustrated embodiment, the backtesting device 22 is provided with a memory 82 (hereinafter “backtesting memory 82”) accessible by one or more processing component 86 (hereinafter “backtesting processor 86”). The backtesting memory 82 may include one or more non-transitory computer-readable medium storing processor-executable code and/or software application(s) 90 (hereinafter “backtesting application 90”) and one or more database 94 (hereinafter “database 94”).

In one embodiment, the database 94 can be a relational database, a time-series database, a vector database, a non-relational database, or the like. Examples of such databases comprise, DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, MySQL, PostgreSQL, MongoDB, Apache Cassandra, Weaviate, and the like. It should be understood that these examples have been provided for the purposes of illustration only and should not be construed as limiting the presently disclosed inventive concepts. The database 94 can be centralized or distributed across multiple systems. The backtesting memory 82 may further store, for example, the historical/past data for a plurality of market instruments. In some embodiments, the historical data may be stored, for example, in the database 94. In some embodiments, the backtesting memory 82 may store data for each backtesting session being executed by user(s) 14 on the backtesting device 22. In some embodiments, the data for each backtesting session may be stored in an in-memory datastore/database. Exemplary in-memory datastores may include, e.g., REDIS® (Redis Ltd., San Francisco, CA, USA). In one embodiment, the database 94 may include a first database storing user data and/or session data and a second database storing the historical data.

In some embodiments, the backtesting device 22 may comprise the one or more backtesting processor 86 working together, or independently to, execute processor-executable code, such as the backtesting application 90, stored on the backtesting memory 82. Additionally, the backtesting device 22 may include at least one input device 96 (hereinafter “input device 96”) and at least one output device 100 (hereinafter “output device 100”). Each element of the backtesting device 22 may be partially or completely network-based or cloud-based, and may or may not be located in a single physical location.

The backtesting processor 86 may be implemented as a single processor or multiple processors working together, or independently, to execute the backtesting application 90 as described herein. It is to be understood, that in certain embodiments using more than one backtesting processor 86, the backtesting processors 86 may be located remotely from one another, located in the same location, or comprising a unitary multi-core processor. The backtesting processors 86 may be capable of reading and/or executing processor-executable code and/or capable of creating, manipulating, retrieving, altering, and/or storing data structures into the backtesting memory 82 such as in the database 94.

Exemplary embodiments of the backtesting processor 86 may be constructed similar to and in accordance with the user processor 58 described above in more detail. The backtesting processor 86 may be capable of communicating with the backtesting memory 82 via a path 104 (e.g., data bus). The backtesting processor 86 may be capable of communicating with the input device 96 and/or the output device 100.

The backtesting processor 86 may be further capable of interfacing and/or communicating with the user device 18 via the network 26 using a communication device 108. For example, the backtesting processor 86 may be capable of communicating via the network 26 by exchanging signals (e.g., analog, digital, optical, and/or the like) via one or more port (e.g., physical or virtual ports) using a network protocol to provide updated information to the user application 74 or the primary user interface 30 executed on the user device 18.

In some embodiments, the backtesting memory 82 may be located in the same physical location as the backtesting device 22, and/or one or more backtesting memory 82 may be located remotely from the backtesting device 22. For example, the backtesting memory 82 may be located remotely from the backtesting device 22 and communicate with the backtesting processor 86 via the network 26. Additionally, when more than one backtesting memory 82 is used, a first backtesting memory 82 may be located in the same physical location as the backtesting processor 86, and additional backtesting memory 82 may be located in a location physically remote from the backtesting processor 86. Additionally, the backtesting memory 82 may be implemented as a “cloud” non-transitory processor-readable medium (i.e., one or more backtesting memory 82 may be partially or completely based on or accessed using the network 26).

The backtesting memory 82 may store processor-executable code and/or information comprising the database 94 and the backtesting application 90. In some embodiments, the backtesting application 90 may be stored as a compiled application file, such as an executable file, for example, or in a structure (or unstructured) format, such as, e.g., in a non-compiled file.

The input device 96 of the backtesting device 22 may transmit data to the backtesting processor 86 and may be constructed in accordance with or similar to the input device 50 of the user device 18 described above in more detail. The input device 96 may be located in the same physical location as the backtesting processor 86, or located remotely and/or partially or completely network-based. The output device 100 of the backtesting device 22 may transmit information from the backtesting processor 86 to the user 14, and may be similar to the output device 54 of the user device 18. The output device 100 may be located with the backtesting processor 86, or located remotely and/or partially or completely network-based.

Referring now to FIG. 4, shown therein is an illustration of a first screenshot 200a of an exemplary embodiment of the user device 18 displaying the primary user interface 30 with a backtesting dashboard 204 constructed in accordance with the present disclosure. As shown by the first screenshot 200a, the user processor 58 may display the primary user interface 30 of the backtesting application 90 on the user device 18 to display a backtesting session list 208 having one or more backtesting item 212a-n associated with a particular backtesting session, a strategy group 216, and a checklist group 220.

In one embodiment, the backtesting dashboard 204 may be generated by the backtesting processor 86 and may be transmitted by the backtesting processor 86 to the user processor 58 via the network 26. For example, the backtesting dashboard 204 may be a series of web pages or a web application that is generated by the backtesting processor 86 and displayed on the primary user interface 30 on the output device 54 of the user device 18 by the user processor 58.

The backtesting session list 208 may display a list of one or more of the backtesting items 212, for which each backtesting item 212 may be associated with a particular backtesting session. The backtesting session list 208 may display the list of all backtesting items 212 for the user, or, in other embodiments, may display a list of a subset of the backtesting items 212 for the user.

As shown in FIG. 4, each backtesting item 212 includes one or more backtesting property label 224 corresponding to a respective backtesting property, for example, shown as a period label 224a, a name label 224b, a starting balance label 224c, a strategy label 224d, and a pairs label 224e. In other embodiments, additional backtesting property labels 224 may be provided. Each backtesting property label 224 may correspond to a backtesting property of the backtesting session. The period label 224a may be a simulation timeframe that a particular backtesting session includes or is executed over, which corresponds to a historic date/time of the historic market instrument. The name label 224b may be a name of the particular backtesting session. The starting balance label 224c may be a starting balance of the particular backtesting session. The strategy label 224d may correspond to a strategy name of a particular strategy in the strategy group 216. The pairs label 224e may refer to any financial instrument or asset available within the particular backtesting session and may correspond to the historic market instrument being examined as part of the particular backtesting session. For example, the pair of instruments may encompass two or more assets, such as one or more financial instruments. The one or more financial instruments may include, for example, stocks, bonds, currency (e.g., United States Dollar (USD), Euro (EUR), and the like), commodities (e.g., gold and silver), and/or any other tradable asset. While each backtesting item 212 is shown with a currency pair associated with the pairs label 224e (e.g., shown with EUR/USD), the pairs are not limited to currency pairs alone and may encompass a wide range of assets or financial instruments that the user desires to analyze.

In one embodiment, each of the one or more backtesting properties are included in the session data and correspond to the backtesting property labels 224 for the associated backtesting session may be stored in the backtesting memory 82, such as in the database 94, and may be associated with the particular backtesting session.

In one embodiment, each backtesting item 212 includes a view input 226. The backtesting processor 86 may receive one or more input from the user device 18 indicative of selection of the view input 226 of a particular backtesting item 212 by the user, and, responsive to the selection, may cause the primary user interface 30 to replay the associated backtesting session of the particular backtesting item 212. For example, the backtesting processor 86, responsive to one or more input, e.g., from the user device 18, may cause the primary user interface 30 to display a backtesting session view 300 (shown in FIG. 5A) and be loaded with session data of the associated backtesting session sent to the user processor 58.

In one embodiment, the backtesting processor 86 may receive one or more input from the user device 18 indicative of the user selecting a create input 228. Responsive to the selection of the create input 228, the backtesting processor 86 may generate a new backtesting session.

In one embodiment, the backtesting processor 86 may generate a backtesting item context menu 230 (FIG. 4) responsive to receiving an input from the user via the user device 18. For example, if the user right-clicks (or hold-clicks) a particular backtesting item 212, the backtesting processor 86 may generate the backtesting item context menu 230 having one or more context menu operations 234 operable to, upon selection by the user via the user device 18, cause the backtesting processor 86 to execute a particular function against the backtesting session associated with the particular backtesting item 212. In one embodiment, the one or more context menu operations 234 include operations that when executed by the backtesting processor 86 may cause the backtesting processor 86 to: edit the backtesting session; duplicate the backtesting session; view the journal of the backtesting session; continue the backtesting session; and delete the backtesting session. For example, upon selection of the “Continue” context menu operation 234, the backtesting processor 86, responsive to the selection, e.g., from the user device 18, may cause the primary user interface 30 to display the backtesting session view 300 (shown in FIG. 5A) loaded with session data of the backtesting session associated with the particular backtesting item 212.

In one embodiment, the backtesting dashboard 204 may further include the strategy group 216. The strategy group 216 may include one or more session collection having a strategy name and associated with one or more backtesting session. In one embodiment, the one or more backtesting session is mutually exclusive between session collections, that is, each backtesting session can only be associated with one session collection. In other embodiments, each backtesting session can be associated with more than one session collection. As shown, each backtesting item 212 may display the strategy label 224d comprising the strategy name of the session collection of which the backtesting session associated with the backtesting item 212 is a member.

In one embodiment, the backtesting dashboard 204 may further include the checklist group 220. The checklist group 220 may display one or more checklist 240a-n (shown as a first checklist 240a, a second checklist 240b, and a third checklist 240c). Each checklist 240 may be created and customized by the user. In one embodiment, the checklist 240 may be used as a reminder of one or more step that the user has identified as important to follow before the user places an order. Upon selection of a particular checklist 240, the backtesting processor 86 may prompt the user to update or edit the particular checklist 240. In one embodiment, the checklist group 220 may further comprise a new checklist input 244. The backtesting processor 86, responsive to the user selecting the new checklist input 244 may generate a checklist dialog.

Referring now to FIG. 5A, shown therein is an illustration of a second screenshot 200b of an exemplary embodiment of the user device 18 displaying the primary user interface 30 with a backtesting session view 300 displayed and constructed in accordance with the present disclosure. Generally, the backtesting session view 300 displays a backtesting session, such as the backtesting session associated with a particular backtesting item 212 selected by the user 14 from the backtesting dashboard 204.

As shown, the backtesting session view 300 includes a chart 302 having a graph 304, such as a candlestick line graph, showing a value of a historic market instrument 305 (e.g., historical stock data for a stock, financial market, or foreign exchange market that is at least one market-day old, or from a prior market-day) and having an axis of abscissas 306a showing a time, and an axis of ordinates 306b showing a market instrument value. The backtesting session view 300 provides the user with a time granularity 308 of a ticker step corresponding to a timeframe for which each candlestick of the graph 304 of the historic market instrument 305 pertains, as well as an option menu 312 having one or more option 316a-n, shown as options 316a-g, described in detail below. While the time granularity 308 is shown as having a value of 4 hours, it should be understood that other time granularities of the ticker step may be selectable by the user 14, for example, the time granularity 308 may have options including, but not limited to, 1 second, 5 seconds, 15 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hours, 4 hours, 8 hours, 12 hours, 1 day, 7 days, 1 week, 1 month, 1 year, and the like, or any value therebetween in 1 second increments. Upon receiving an indication of selection of a particular value of the time granularity 308 by the user 14, the user processor 58 may store the particular value as the time granularity of the graph 304 in the session data.

In one embodiment, the historic market instrument 305 may be, for example, a time-series data having the market instrument value associated with a particular time value. The historic market instrument 305 may be provided with time granularity 308 within the graph 304 where the time granularity 308 is a time delta between consecutive market instrument values in the time-series data. For example, the historic market instrument 305 may have a time granularity 308 of 5 minutes, resulting in the time-series data providing market instrument values in 5-minute increments. In one embodiment, the backtesting processor 86 may calculate the market instrument value for a particular time granularity 308. For example, the historic market instrument 305 may be stored in the backtesting memory 82, such as from the database 94, at a first time granularity, such as a first market instrument value for each 0.25-second increment, and the backtesting processor 86 may calculate a second market instrument value at a second time granularity, e.g., for each 5-minute increment, such as, by a high value, low value, beginning value, and ending value of the first market instrument value at each 0.25-second increment within the 5-minute increment as the second market instrument value.

In one embodiment, the backtesting processor 86 may retrieve the value of the historic market instrument 305 from the backtesting memory 82, such as from the database 94. In one embodiment, the database 94 storing the historic market instrument values is a non-relational database and/or a time-series database. The value of the historic market instrument 305 may be, for example, stored with, or associated with, the session data.

In one embodiment, the graph 304 may show historic market instrument values for the historic market instrument 305 that have a time value at, or before, a simulation time 310. For example, as shown in FIG. 5A, the simulation time 310 is shown as “07:00:59 (UTC)” and the primary user interface 30 with the backtesting session view 300 loaded with session data of the associated backtesting session may show the market instrument values for the historic market instrument 305 only up to the market instrument values having a time value at or before the simulation time 310 of 07:00:59 (UTC), and may not, for example, display the market instrument values having the time value greater than the simulation time 310. As used herein, reference to “prior market instrument value”, or the like, refers to market instrument values of the historic market instrument 305 prior to the simulation time 310 and within a timeframe of the chart 302. Further, it should be understood that while the chart 302 only shows the graph 304 of the market instrument values of the historic market instrument 305 having the time value up to and including the simulation time 310, the simulation data of the associated backtesting session may include the time-series data of the historic market instrument 305 for a duration of the associated backtesting session, which includes, for example, market instrument values of the historic market instrument 305 having a time value greater than the simulation time 310.

In one embodiment, the option menu 312 may include an indicator option 316a, a place order option 316b, a hide navbar option 316c, a day option 316d (shown as ‘Thu’ indicating ‘Thursday’), an economic calendar option 316e, a show events option 316f, and a goto option 316g. In one embodiment, the indicator option 316a, when selected by the user, causes the user processor 58 to display one or more indicators on the chart 302. In one embodiment, the place order option 316b, when selected by the user, causes the user processor 58 to display a place order dialog on the primary user interface 30. In one embodiment, the hide navbar option 316c, when selected by the user, causes the user processor 58 to hide the option menu 312 from the display on the chart 302. In one embodiment, the day option 316d, when selected by the user, causes the user processor 58 to toggle a “day of week” modal, e.g., when a cursor is within the chart 302 or over the historic market instrument 305 of the graph 304. In one embodiment, the economic calendar option 316e, when selected by the user, causes the user processor 58 to display an economic calendar drawer operable to display an economic calendar for one or more country. In one embodiment, the show events option 316f, when selected by the user, causes the user processor 58 to display one or more event of the economic calendar in the chart 302 and/or on the graph 304.

In one embodiment, the goto option 316g, when selected by the user, causes the user processor 58 to display a goto menu 350 on the primary user interface 30. As shown, the goto menu 350 may have one or more type of goto jumps 354, such as a Next Session jump 354a, a Next Day Open jump 354b, a Next Silver Bullet Session jump 354c, a Next News Event jump 354d, and a Custom settings menu selection 358. It should be understood that the goto jumps 354 listed above and identified in FIG. 5A are provided by way of example only and that the goto jumps 354 are not limited to these specific implementations. For example, additional goto jump 354 implementations may include goto jumps 354 corresponding to a previous significant event jump, wherein the system identifies and navigates to the nearest prior occurrence of a predefined trading condition, such as a high volatility spike, liquidity sweep, major support interaction, and/or major resistance interaction. Further, the goto jump 354 may include a session-defined event jump, wherein upon selection of the session-defined event jump, the backtesting processor 86 calculates a jump target based on user-specified trading sessions or time-based conditions. The user 14 may provide inputs (such as user-specified trading sessions, time-based conditions, and/or significant event settings/selections) to the user processor 58 and/or the backtesting processor 86, e.g., via selection of an advanced options 354e from the goto menu 350.

In one embodiment, each goto jump 354 may be dynamically calculated based upon the simulation time 310, the type of the goto jump 354, and user configuration, instead of corresponding to a predetermined date-timestamp within the simulation timeframe. In this way, neither the user processor 58 nor the backtesting processor 86 generates predetermined timestamps for each goto jump 354, thereby improving efficiency of the backtesting system 10, e.g., of the user device 18 and the backtesting device 22.

In one embodiment, the backtesting session view 300 includes a show journal input 320 operable to cause the user processor 58 to display a one or more journal entry or journal screenshot as described in U.S. application Ser. No. 18/915,708 entitled “Security Trading Backtesting System Having an Interactable Journal” filed on Oct. 15, 2024, the entire content of which is hereby incorporated herein by reference in its entirety.

In one embodiment, the backtesting session view 300 may further include a session balance 326 showing an account balance for the backtesting session, a realized profit and loss for the backtesting session, and an unrealized profit and loss for the backtesting session.

In one embodiment, the backtesting session view 300 may further include a display setting selector 328 operable to, when selected by the user via the primary user interface 30, cause the user processor 58 to modify a display size of the chart 302 and/or the graph 304.

In one embodiment, the backtesting session view 300 may further include a user settings menu 336 operable to display, on the primary user interface 30, an icon associated with a logged-in user account 76 for the user 14 and a settings menu. The user's user account 76 may include account information, such as a user's name, an email address, a username, custom settings, account properties, and/or the like.

In one embodiment, the Custom settings menu selection 358, when selected by the user via the primary user interface 30, causes the user processor 58 to display a custom settings dialog 400 (FIG. 5B, described below) on the primary user interface 30, for example, superimposed over the graph 304 of the backtesting session view 300.

Referring now to FIG. 5B, shown therein is an illustration of a third screenshot 200c of an exemplary embodiment of the user device 18 displaying the primary user interface 30 with the custom settings dialog 400 displayed and constructed in accordance with the present disclosure. The custom settings dialog 400 may include a plurality of settings categories having a plurality of custom settings, which may be user-configurable. For example, the plurality of settings categories may include a next session settings category 404 and a next day settings category 408. Additional settings categories are discussed below and shown in FIG. 5D. The next session settings category 404 may include one or more session goto options 412 having an option title 416, a time selector 420 (operable to set a goto time value for the simulation time) and a reference time 424 to convert a historic market (e.g., stock market) time-zone to a common time-zone, e.g., London Time (Greenwich Mean Time or British Summer Time) or Hong Kong Time to New York Time (i.e., Eastern Time).

In one embodiment, the next session settings category 404 includes a first session goto option 412a having a first option title 416a of “Start of Asian Session (New York Time)”, a first reference time 424a of “New York Time” as shown in parentheses of the first option title 416a, for example, and a first time selector 420a having a first goto time value of “19:00”; a second session goto option 412b having a second option title 416b of “Start of London Session (New York Time)” and a second time selector 420b having a second goto time value of “02:00”; and a third session goto option 412c having a third option title 416c of “Start of New York Session (New York Time)” and a third time selector 420c having a third goto time value of “07:00”. In one embodiment, the reference time 424 for each of the custom settings may be set in the user profile such that all custom settings for the user have the same reference time 424.

The next day settings category 408 may include one or more session goto options 412 such as a fourth session goto option 412d having a fourth option title 416d, a time selector 420 (shown as a fourth time selector 420d having a fourth goto time value of “17:00”) and a reference time 424 (shown as a fourth reference time 424d).

In one embodiment, values for each of the one or more session goto options 412 is stored in the backtesting memory 82, such as in the database 94, and is associated with the user account 76 of the user. In other words, the values for each of the one or more session goto options 412 may be the same between each backtesting session associated with each of the one or more backtesting item 212a-n of the backtesting application 90 (FIG. 4).

In one embodiment, each of the one or more session goto options 412 is created by the user or is prepopulated by the user processor 58 or the backtesting processor 86 on a historic market instrument (e.g., stock, option, or the like) 305 in the session data or time-series data of the historic market instrument 305. In one embodiment, the one or more session goto options 412 are not generated based on live stock data or live foreign exchange data. In one embodiment, the one or more session goto options 412 are not generated based on a data stream of live data. In one embodiment, the one or more session goto options 412 are not generated on a backtesting session-by-backtesting session basis, that is, the one or more session goto options 412 are not different between backtesting session for the same user. In one embodiment, the one or more session goto options 412 are not generated during recording of live stock data. In one embodiment, the one or more session goto options 412 are not generated during playback of the historic market instrument 305.

It should be understood that text names of the next session settings category 404 and the next day settings category 408 are provided for convenience, and in some embodiments, the text names may be the same or different from the text names shown.

In one embodiment, each setting of: the one or more session goto options 412, the next session settings category 404, and the next day settings category 408 may further include an activation indicator 444 operable to indicate whether the particular custom setting is in effect for the particular backtesting session (e.g., has an active/activated state or an inactive/deactivated state). The user, by interacting with the activation indicator 444 associated with a particular custom setting may cause the user processor 58 to activate that particular custom setting or deactivate that particular custom setting. When the particular custom setting is activated, the user may interact with the primary user interface 30 to advance to a time within the particular backtesting session corresponding to that particular custom setting.

That is, the goto menu 350 may only display goto jumps 354 when the activation indicator 444 associated with the custom setting corresponding to the particular goto jump 354 is activated. For example, activation of a first category activation indicator 442a corresponding with the next session settings category 404 causes the user processor 58 to include the Next Session jump 354a in the goto menu 350 shown in FIG. 5A. In this embodiment, because the first category activation indicator 442a is associated with a particular settings category (i.e., the next session settings category 404), the first category activation indicator 442a may be considered a category activation indicator.

As shown in FIG. 5B, the first session goto options 412a includes a second activation indicator 444b being activated; the second session goto options 412b includes a third activation indicator 444c being activated; and the third session goto options 412c includes a fourth activation indicator 444d being deactivated. Thus, upon selection of the Next Session jump 354a in the goto menu 350, the user processor 58 advances the graph 304 of the historic market instrument 305 to the goto time value of the next nearest and activated session goto options 412. The user processor 58 may determine a next nearest goto time value for the “next nearest” session goto options 412 by comparing the simulation time 310 to the goto time values for each session goto options 412 having an activation indicator 444 that is activated and selecting the session goto options 412 having the nearest goto time value that is greater than the simulation time 310.

For example, if the simulation time 310 was “00:01 (UTC)” and the user, interacting with the primary user interface 30 selected the Next Session jump 354a, the user processor 58 would cause the graph 304 of the historic market instrument 305 to advance by 6 hour and 59 minutes until the simulation time 310 is “07:00 (UTC)” because 00:01 UTC is one minute after 19:00 New York Time while 02:00 New York Time is the next nearest goto time value of an activated session goto options 412 that is greater than the simulation time 310 of “00:01 (UTC)”, thus, the user processor 58 advances to the goto time value of the second session goto options 412b. If the simulation time 310 is “07:00 (UTC)” and the user again selects the Next Session jump 354a, the user processor 58 would cause the graph 304 of the historic market instrument 305 to advance by 14 hours until the simulation time 310 is “00:00 (UTC)” because the third session goto options 412c is deactivated (e.g., not activated) so the next activated session goto options 412 is the first session goto options 412a having the goto time value of 19:00 New York Time (i.e., 00:00 (UTC)).

Further, activation of a second category activation indicator 442b corresponding with the next day settings category 408 causes the user processor 58 to include the Next Day Open jump 354b in the goto menu 350 shown in FIG. 5A. Thus, upon selection of the Next Day Open jump 354b in the goto menu 350, the user processor 58 advances the graph 304 of the historic market instrument 305 to the fourth goto time value of the fourth time selector 420d.

In one embodiment, upon selection of the time selector 420, the user processor 58 may cause the primary user interface 30 to display a time selection menu as shown in FIG. 5C.

Referring now to FIG. 5C, shown therein is an illustration of a fourth screenshot 200d of an exemplary embodiment of the user device 18 displaying the primary user interface 30 with the time selection menu displayed and constructed in accordance with the present disclosure. As shown, the time selection menu may be constructed, for example, as a time dropdown 450 having a plurality of times 454. While the time selection menu is shown as the time dropdown 450, other embodiments of the time selection menu may include any time selector or time picker UI element that enables the user to input a time to the time selector 420 and may include, for example, a number input field or clock-face selector.

In one embodiment, the user may interact with a first time 454a having a first goto time value of the time dropdown 450 to cause the user processor 58 to store the first goto time value of the first time 454a selected by the user as the goto time value for the corresponding time selector 420. As shown, the user has selected the first goto time value of “19:00” which is then stored as the first goto time value of the first time selector 420a (shown in FIG. 5B, for example).

In one embodiment, as shown in FIG. 5C, the time dropdown 450 may be disposed over at least a portion of the custom settings dialog 400.

Referring now to FIG. 5D, shown therein is an illustration of a fifth screenshot 200e of an exemplary embodiment of the user device 18 displaying the primary user interface 30 with the custom settings dialog 400 displayed and constructed in accordance with the present disclosure. As discussed above, the custom settings dialog 400 may include a plurality of settings categories having a plurality of custom settings. As shown in FIG. 5D, the custom settings dialog 400 further includes a next silver bullet session settings category 470 having a third category activation indicator 442c, a next news event category 474 having a fourth category activation indicator 442d, and a price category 478 having a fifth category activation indicator 442e.

In one embodiment, the next silver bullet session settings category 470 may include one or more session goto options 412e-g having an option title 416e-g, a time selector 420e-g (operable to set a bullet session time) and a reference time 424e-g to convert a historic market instrument timezone to a common timezone, as described above. As shown a fifth session goto option 412e having the activation indicator 444, a fifth option title 416e, with a fifth reference time 424e, and a fifth time selector 420e; a sixth session goto option 412f having the activation indicator 444, a sixth option title 416f, with a sixth reference time 424f, and a sixth time selector 420f; and a seventh session goto option 412g having the activation indicator 444, a seventh option title 416g, with a seventh reference time 424g, and a seventh time selector 420g.

In one embodiment, activation of the third category activation indicator 442c corresponding with the next silver bullet session settings category 470 causes the user processor 58 to include the Next Silver Bullet Session jump 354c in the goto menu 350; activation of the fourth category activation indicator 442d corresponding with the next news event category 474 causes the user processor 58 to include the Next News Event jump 354d in the goto menu 350; and deactivation of the fifth category activation indicator 442e corresponding with the next price category 478 causes the user processor 58 to not include a Next Price jump in the goto menu 350, as shown in FIG. 5A. In this way, the user may interact with each category activation indicator 442 to include or exclude one or more category from the goto menu 350.

In one embodiment, upon selection of the Next News Event jump 354d in the goto menu 350, the user processor 58 advances the graph 304 of the historic market instrument 305 to a next time value of a news event time value. For example, news events may be stored in the user memory 66 or in the backtesting memory 82 such as in the database 94, e.g., as a news event paired associated with a news event time value. The time value may be, for example, a timestamp also including a date and/or a time. The user processor 58 accessing the user memory 66 or the backtesting processor 86 accessing the backtesting memory 82 or the database 94 may retrieve a news event having a news event time value greater than the simulation time 310. The news event time value of the retrieved news event may be selected as the next time value such that the user processor 58 advances the graph 304 of the historic market instrument 305 to the next time value of the news event time value of the retrieved news event.

In one embodiment, the custom settings dialog 400 may further include a discard input 480 and a save input 484, each of the discard input 480 and the save input 484 constructed as a button, for example. In one embodiment, upon selection of the discard input 480, the user processor 58 may discard any change made within the custom settings dialog 400 from a time that the custom settings dialog 400 was opened, if any changes were made, and may close the custom settings dialog 400. In one embodiment, upon selection of the save input 484 the user processor 58 may save custom settings, such as a state of each activation indicator 444 and a time value from each time selector 420. The user processor 58 may save the custom settings with the user's user account 76 in the user memory 66, may transmit the custom settings, such as via the network 26, to the backtesting processor 86, or may otherwise associate the user account 76 with the custom settings. The backtesting processor 86 may receive the custom settings and save the custom settings with the user's user account 76 in the backtesting memory 82, such as in the database 94, or may otherwise associate the user account 76 with the custom settings.

In one embodiment, the technical solutions provided herein, by associating the custom settings with the user account (and, e.g., not with a particular backtesting session or within the values of the historic market instrument 305) and instead dynamically calculating the next nearest goto time value as requested by the user 14, overcome a technical problem of high memory requirements of storing references to specific instance in time for each historic market instrument. For example, requiring the user to generate references to specific instances in the simulation time for each backtesting session would require storage of each of those references for each user—and, when multiple users interact with such a system, the storage requirements to store each pre-determined reference to specific instances in time for each historic market instrument would be immense. Furthermore, the technical solutions provided herein, by associating the custom settings with the user account, overcome a technical problem of increased processing overhead in one or more of the processors 58, 86 caused by processing all historic market instruments and generating references to specific instances in the simulation time for each historic market instrument. Thus, in one embodiment, by not generating references to specific instances in the simulation time for all historic data, or as real-time data is received, and instead dynamically calculating the next nearest goto time value as requested by the user 14, the efficiency of the user processor 58 and the backtesting processor 86 may be increased and network traffic on the network 26 may be reduced, thereby further causing the primary user interface 30 to be more responsive to user inputs.

Referring now to FIGS. 5E-F in combination, shown therein are illustrations of a sixth screenshot 200f and a seventh screenshot 200g of exemplary embodiments of the user device 18 displaying the primary user interface 30 with the backtesting session view 300 at differing instants in simulation time 310, constructed and displayed in accordance with the present disclosure. Generally, the backtesting session view 300 displays a backtesting session, such as the backtesting session associated with a particular backtesting item 212 selected by the user 14 from the backtesting dashboard 204.

As shown, the backtesting session view 300 includes a first chart 302a having a first graph 304a at a first instant in simulation time 310a (FIG. 5E) and a second chart 302b having a second graph 304b at a second instant in simulation time 310b (FIG. 5F), such as a candlestick line graph. Each of the graphs 304a, 304b may show time-series values 307 of the historic market instrument 305 (e.g., actual stock data for a stock, financial market, or foreign exchange market that is at least one market-day old, or from a prior market-day) up to the particular instant in simulation time 310. As shown, the first graph 304a of the first chart 302a shows first time-series values 307a of the historic market instrument 305 up to the first instant in simulation time 310a and the second graph 304b of the second chart 302b shows second time-series values 307b of the historic market instrument 305 up to the second instant in simulation time 310b.

The historic market instrument 305 may be, for example, a time-series data having the market instrument value associated with a particular time value. The historic market instrument 305 may be provided with time granularity 308 within the graph 304 where the time granularity 308 is a time delta between consecutive market instrument values of the time-series values 307 in the time-series data. For example, the historic market instrument 305 may have a time granularity 308 of 5 minutes, resulting in the time-series data providing market instrument time-series values in 5-minute increments. In one embodiment, the backtesting processor 86 may calculate the market instrument time-series values for a particular time granularity 308.

In one embodiment, the backtesting processor 86 may retrieve the time-series values 307 of the historic market instrument 305 from the backtesting memory 82, such as from the database 94. In one embodiment, the database 94 storing the historic market instrument values is a non-relational database and/or a time-series database. The time-series values 307 of the historic market instrument 305 may be, for example, stored with, or associated with, the session data.

In one embodiment, the graph 304 may show historic market instrument values for the historic market instrument 305 that have a time value at, or before, a simulation time 310. As shown in FIG. 5E, the simulation time 310a is shown as “04:00:59 (UTC-4)” while, as shown in FIG. 5F, the simulation time 310b is shown as “23:00:59 (UTC-4).”

In one embodiment, the primary user interface 30 with the backtesting session view 300 loaded with session data of the associated backtesting session may show the time-series values 307 for the historic market instrument 305 only up to the first time-series values 307a of the market instrument having time-series values at or before the simulation time 310a of 04:00:59 (UTC-4), and may not, for example, display the market instrument time-series values having time-series values 307 greater than the simulation time 310a. In one embodiment, the backtesting processor 86 may provide one or more session timestamp indicator 490 on the chart 302, for example, as a first session timestamp indicator 490a in FIG. 5E and a second session timestamp indicator 490b further shown in FIG. 5F. Each of the session timestamp indicators 490 correspond to a particular one of the session goto options 412, e.g., correspond to a time value selected in the corresponding time selector 420, and provides an indication corresponding to a particular session time on the axis of abscissas 306a. For example, as shown in FIG. 5E, the backtesting processor 86 provides the first session timestamp indicator 490a on the first chart 302a when the simulation time 310 reaches and/or passes the time value of the second time selector 420b. Further, the backtesting processor 86 may provide the second session timestamp indicator 490b (FIG. 5F) on the second chart 302b when the simulation time 310 reaches and/or passes the time value of the second time selector 420b.

In some embodiments, such as shown in FIG. 5F, the backtesting processor 86 provides the first session timestamp indicator 490a on the second chart 302b when the simulation time 310 reaches and/or passes the time value of the second time selector 420b and provides the second session timestamp indicator 490b on the second chart 302b when the simulation time 310 reaches and/or passes the time value of the second time selector 420b, such that both the first session timestamp indicator 490a and the second session timestamp indicator 490b are shown on the same second chart 302b.

In one embodiment, each session timestamp indicator 490 includes both a graphic indicator 492 and a textual indicator 494. The backtesting processor 86 may provide the graphic indicator 492 as a graphical symbol on the chart 302. As shown in FIG. 5E, the backtesting processor 86 may cause the primary user interface 30 to include a first graphic indicator 492a and a first textual indicator 494a as the first session timestamp indicator 490a such that the backtesting processor 86 aligns the first graphic indicator 492a on the first chart 302a with the axis of abscissas 306a at the time value of the second time selector 420b to indicate a position within the first time-series values 307a of the first graph 304a corresponding with the time value of the second time selector 420b. The first textual indicator 494a may likewise be provided by the backtesting processor 86 and indicative of the time value of the second time selector 420b and displayed, for example, as a timestamp, a date-stamp, or a date/timestamp, e.g., depending on the time granularity 308, and may be provided in any textual format indicative of a particular time value. In some embodiments, the graphic indicator 492 (such as the first graphic indicator 492a) may be constructed as a line (such as a formatted line, or dashed line) extending from a particular time-value along the axis of abscissas 306a to a particular value of the time-series values 307 of the graph 304, and may extend beyond the particular value.

Similarly, as shown in FIG. 5F, the backtesting processor 86 may cause the primary user interface 30 to include a second graphic indicator 492b and a second textual indicator 494b as the second session timestamp indicator 490b such that the backtesting processor 86 aligns the second graphic indicator 492b on the second chart 302b with the axis of abscissas 306a at the time value of the first time selector 420a to indicate a position within the second time-series values 307b of the second graph 304b corresponding with the time value of the first time selector 420a.

Referring to FIGS. 5E-F in combination, in one embodiment, upon the user interacting with the primary user interface 30 and selecting the Next Session jump 354a, the user processor 58 would cause the first graph 304a of the historic market instrument 305, shown at the simulation time 310a of “04:00:59 (UTC-4),” which is after the time value of the second time selector 420b, to advance to (or until) the simulation time 310b of “23:00:59 (UTC-4)” because the simulation time 310b is the next nearest goto time value of an active session goto option 412 (as indicated by the activation indicator 444 and/or the category activation indicator 442) that is greater than the simulation time 310a. Therefore, the user processor 58 advances to the goto time value of the first time selector 420a of the first session goto option 412a. In other words, even though the third time selector