FORM 2
THE PATENTS ACT, 1970 (39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
1. Title of the invention: OPTIMIZATION OF SYSTEM RESOURCE ALLOCATION IN BROKERAGE
SYSTEMS
2. Applicant(s)
NAME NATIONALITY ADDRESS
T ATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point,
SERVICES LIMITED (Mumbai, Maharashtra 40002), India
3. Preamble to the description
COMPLETE SPECIFICATION
The following specification particularly describes the invention and the manner in which it
is to be performed.

TECHNICAL FIELD
The present subject matter relates, in general, to optimization of system resource allocation and, in particular, to optimization of system resource allocation in brokerage systems.
BACKGROUND
Trading environments, including trading exchanges, traders, and investors. involve sale and purchase of stocks, bonds, currencies, commodities, and other financial instruments. Architectures of the trading environments vary widely, and usually a brokerage unit act as a link between the traders/investors and the trading exchanges. Recent advances in computer and communications technology have led to electronic trading in the trading environments. In such electronic trading, the traders and investors trade various financial instruments over interfaces, such as web-based trading portals or call centers, with different components of a trading system at the stock exchanges, the brokerage units, and the traders' and inventors' ends interpJaying with each other. Further, a brokerage unit, with the help of a brokerage system, may perform front office and back office functions. Front office functions may include functions such as interacting directly with traders and investors, taking orders, and determining whether each order is allowable. Back office functions may include functions such as maintaining records as well as actual custody of the assets in an account of a trader or an investor. Typically, back office system of the brokerage system manages and transmits trade confirmation notices, account statements, etc., and processes and settles trades. Hence, transaction messages, such as new orders, modifications to the orders, cancellations of the orders, and acknowledgement messages, are received by front office and are provided to the back office for risk management checks. The transaction messages from the traders as well as the trading exchanges are received by the front office and sent to the back office.

Typically, the transaction messages received from the trading exchange by the brokerage system are bulky and use large amount of system resources for processing. In order to handle the load of the bulky transaction messages, the brokerage system manages the allocation of system resources for execution and processing of the transaction messages. Conventionally, the brokerage system allocates a system resource to one or more transaction messages based on the order identification numbers of the transaction messages.
SUMMARY
This summary is provided to introduce concepts related to optimization of system resource allocation in brokerage systems, which are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.
A method for optimization of the system resource allocation in a brokerage system is described herein. In one implementation, the method includes identifying an order ID and a message ID associated with a transaction message,, in response to receipt of the transaction message. Based on the order ID of the transaction message, it is determined whether the allocation of a system resource to the transaction message for processing entails a serialization conflict. Further, on the basis of the determining, a system resource is allocated to the transaction message for processing.
BRIEF DESCRIPTION OF THE DRAWINGS
The detailed description is described with reference to the accompanying figure(s). In the figure(s), the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference number in different figure(s) indicates similar or identical items. The features, aspects and advantages

of the subject matter will be better understood with regard to the following description, and
the accompanying drawings.
Fig. 1 illustrates an exemplary computing system for optimizing system
resource allocation in a brokerage system, in accordance with an implementation of the
present subject matter.
Fig. 2 illustrates an exemplary method for optimizing system resource
allocation in a brokerage system, in accordance with an implementation of the present
subject matter.
Fig. 3 illustrates an exemplary method for optimizing system resource
allocation in the brokerage system, in accordance with another implementation of the
present subject matter.
DETAILED DESCRIPTION
The subject matter described herein relates to systems and methods for optimizing system resource allocation in a brokerage system.
Generally, trading systems allow trading between trading exchanges and traders and investors using various portals, such as electronic web-based trading interface. The trading systems allow trading by allowing exchange of transaction messages between systems at the trading exchanges, brokerage systems at brokerage units, and user devices at the traders' ends. The transaction messages include order request messages, such as order confirmation request, order modification requests, and order cancellation requests. Such transaction messages are exchanged along a forward path, i.e., from the user devices to the trading exchanges through the brokerage system, and along a backward path, from the trading exchange to the brokerage system, finally to the user device, Such transaction messages generally contribute to message traffic in the brokerage system. A front office system of the brokerage system receives the transaction messages coming from various user devices and those coming from the trading exchanges and passes the transaction messages to a back office system for processing, before forwarding the transaction

messages. Hence, the front office system interacts with the user devices and receives orders in the form of transaction messages, and carries out risk management checks to ensure that sufficient funds and securities are available to successfully complete the transaction. The back office system, on the other hand, processes orders, manages transaction messages, other trade notifications, and account statements, and may also settle trades.
The transaction messages sent by the user devices generally include order messages, such as messages for confirmation of order, modification of order, and cancellation of order. Such transaction messages sent by the user device are easily processed by the brokerage system. On the other hand, the transaction messages sent by the trading exchange include acknowledgement messages, such as order confirmation acknowledgements, order modification acknowledgements, and order cancellation acknowledgements. Further, such acknowledgement messages include trade acknowledgements sent by the trading exchange to acknowledge the trade achieved in response to an order. Each transaction message, such as the order message or the acknowledgement message, has a message ID associated with it, and all the transaction messages relating to one trade are identified by a common order ID. The acknowledgement messages sent by the trading exchange are usually bulky and utilize a considerable amount of resources of the front office system and the back office system. Further, the large number of users, i.e., traders, investors, etc., involved in trading, enhances the message traffic of the transaction messages at the brokerage system. To regulate the message traffic, the brokerage system includes a computing system, which allocates resources, such as trade processes, of the brokerage system to one or more transaction messages for processing, based on various schemes. Such schemes can be based on a serialization constraint, for example, with respect to the order in which the transaction messages are received and processed by the brokerage system. In one example, the brokerage system follows a first-come-first-serve (FCFS) scheme starting from order confirmation acknowledgement, order modification acknowledgement, order cancellation

acknowledgement, and trade acknowledgement messages belonging to the same order ID. Based on the FCFS scheme, the brokerage system manages the allocation of system resources and the subsequent processing of the transaction messages. In certain conventional schemes of optimizing system resource allocation, the computing system allocates the resources to the transaction messages based on the order IDs of the various transaction messages and the number of system resources available for processing the transaction messages. For example, the system computes a mod N of the order ID of the transaction message to be allocated a system resource, N being the number of system resources available for allocation.
Further, the system allocates the system resources to the various transaction messages based on the computed mod N of the order ID of each transaction message. For example, when the brokerage system has 10 system resources for processing transaction messages, i.e., N=10, on the basis of the computation of mod N of the order IDs 1000123, 1000133, and 1000143 of three different messages yields the result 3. Hence, the three messages are allocated system resource marked as serial no. 3 and are processed in the FCFS order. The three transaction messages do not conflict any serialization constraint as they belong to different order IDs and can be allocated a system resource for processing at the same time. However, because of the above described scheme, these transaction messages are queued at system resource no. 3, even when other system resources are idle. Based on the above example, the FCFS serialization constraint for all types of transaction messages sharing the same order ID may be fulfilled by the above described scheme; however, the scheme may fail to prioritize certain types of transaction messages, such as acknowledgement messages, over the other transaction messages. Therefore, such schemes may conform to a certain serialization constraints but may not conform to certain other serialization constraints. As a result of this, the system may not optimally utilize the resources of the brokerage system.
The subject matter described herein relates to optimization of system resource allocation in a brokerage system. The methods and systems for optimizing system resource

allocation in the brokerage system as described herein conform to different serialization constraints. In one implementation, a first serialization constraint is adhered to, in which the transaction messages, such as acknowledgment messages received from the trading exchange, .i.e., along a reverse path, belonging to the same order ID, are processed in FCFS order. In one example, the order of processing could start from order confirmation acknowledgement and proceed to order modification acknowledgement, order cancellation acknowledgement, and trade acknowledgement messages.
In another implementation, a second serialization constraint is followed. According to the second serialization constraint the order confirmation acknowledgement, the order modification acknowledgement, the order cancellation acknowledgement messages associated with one order ID are allocated resources and processed according to the FCFS scheme. On the other hand, no particular order is followed in the processing of the trade acknowledgement messages for that particular order ID.
According to an implementation, a computing system allocates system resources, such as trade processes to different transaction messages. In one example, the computing system can be provided at the back office system. In one implementation, to achieve an optimized allocation and utilization of the system resources, the computing system creates and updates an order ID list to maintain a record of transaction messages being processed by the brokerage system, for example, by a back office system of the brokerage system. In said implementation, the computing system operates under the first serialization constraint, in which the acknowledgement messages, such as order confirmation acknowledgements, order modification acknowledgements, order cancellation acknowledgements, and trade acknowledgements, having different message IDs but belonging to the same order ID are processed in the FCFS order. According to said implementation, the order ID list includes the order IDs of all the transaction messages, from the trading exchange, received by the computing system and includes a status of the order IDs. The status of the order IDs indicate whether or not a transaction message having associated with a certain order ID is undergoing processing by

a system resource. On the receipt of each new transaction message, the order ID associated with that transaction message is inserted in the order ID list. Further, the order ID list can be linked to a pending list, which includes, for example, the order IDs of the various transaction messages pending in queues for being processed. The pending list can also include the message IDs associated with each order ID to identify the different messages associated with each order ID. Further, the pending list can also indicate the status of an order ID, i.e., the pending list can indicate whether a transaction message associated with a certain order ID is undergoing processing by a system resource or is idle. It will be understood that as the transaction messages are processed by the brokerage system, the pending list is updated by removing the message IDs of the transaction messages that have been processed. In cases where all transaction messages associated with an order ID have been processed, the order ID is removed from the pending list and the order ID list. It will also be understood that after the processing of an order ID with no associated pending message IDs in the pending list, the order ID is removed from the order ID list. In an implementation, when a new transaction message is received by the brokerage system, a message ID and an order ID of the transaction message is communicated in an input queue of the computing system. Based on the order ID of the new transaction message, the computing system checks for serialization conflict. The serialization conflict can be understood as a constraint for processing a transaction message associated with an order ID because of another transaction message associated with the same order ID pending for processing. In an implementation, to check for serialization conflict, the computing system determines whether the same order ID exists in the order ID list. In case the same order ID exists in the order ID list, then the new message ID is put into the pending list. As mentioned earlier, the message IDs associated with the same order ID are processed in FCFS order.
On the other hand, in case there is no serialization conflict, i.e., either all message IDs associated with the order ID of the new message ID are processed or that the order ID associated with the new message ID is not present in the order ID list, then the

computing system determines a system resource, for example, the trade process, which is idle and directly allocates the system resource for processing of the new transaction message received by the brokerage system. Further, in case the order ID associated with the new message ID is not present in the order ID list, in an implementation, the computing system creates an entry corresponding to the order ID in the order ID list and updates the status of the order ID to indicate that the transaction message associated with the order ID is being processed. Subsequently, other transaction messages associated with that order ID, received by the brokerage system and communicated to the computing system, are queued for processing and the message ID of those transaction message inserted in the pending list, associated with the order ID list.
According to an implementation, once the transaction message associated with the order ID has been processed, the computing system determines whether the same order ID exists in the pending list. In case the order ID is not present in the pending list, the computing system removes the order ID from the order ID list. However, in case the order ID exists in the pending list, the computing system updates the status of the order ID to indicate that there is no serialization conflict for processing the next transaction message having that message ID and associated with that order ID. In said implementation, the dispatcher can allocate an idle system resource to the next transaction message for processing when the transaction messages in the pending list are being allocated the system resources.
It will be understood that the transaction messages received by the brokerage system and being communicated to the input queue of the computing system are given priority over the transaction messages having message IDs listed in the pending list, for allocation of system resources, and hence, for processing. Hence, the transaction messages in the pending list and having the order ID status set to 'idle' are allocated system resources when the input queue of the computing system is empty, i.e., when the brokerage system does not receive any new transaction message from the trading exchange.

In another implementation, in which the computing system follows the second serialization constraint, the computing system creates an order ID list and a pending list for the order acknowledgments, received by the brokerage system, in the same manner as described before. Further, according to said implementation, the computing system creates a trade list which is associated with the order ID list and includes pending trade acknowledgement messages to be processed. According to an implementation, the transaction messages having message IDs listed in the pending list are given a priority over the transaction messages listed in the trade list for processing the pending transaction messages.
Hence, after the transaction messages directly received from the trading exchanges are allocated the system resources and the transaction messages having message IDs in the pending list of the computing system are processed, the trade acknowledgements are allocated system resources for processing. Subsequent to the processing of trade acknowledgments associated with an order ID, the order ID is removed from the trade list. Further, since the trade acknowledgements appear in large surges and may take a long time in processing, in an implementation, the computing system may be configured to allocate a predetermined number of system resources, such as the trade processes, to the trade acknowledgements for processing. Such a scheme of allocating the system resources avoids the clogging of the system resources by the trade acknowledgements. The rest of the system resources are available for processing the order acknowledgements. In yet another implementation, the brokerage system can include an auxiliary computing system for allocating auxiliary system resources to process trade acknowledgements. In said implementation, the trade list is created and maintained by the auxiliary computing system to allocate auxiliary system resources to the trade acknowledgements. In one example, the auxiliary system resources can be understood as those resources which can be allocated to trade acknowledgements. In one example, the auxiliary system resources may be separate from the other system resources.

It will be understood that the computing system is operational and regulates the message traffic in the brokerage system when at least one system resource is idle and available for allocation.
While aspects of described systems and methods for optimized allocation of system resources in a brokerage system can be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary system architecture(s).
Fig. 1 illustrates a computing system 100 for optimization of system resource allocation in a brokerage system (not shown in figure). The computing system 100 is illustrated as implemented in a network environment. The brokerage system can include a front office system and a back office system (both not shown in figure). The front office system receives orders in the form of transaction messages and carries out risk management checks to ensure that sufficient funds and securities are available to achieve a trade. The back office system processes orders, manages transaction messages and other trade notifications, manages account statements, and may also settle trades. The computing system 100 can be implemented in the front office system or in the back office system of the brokerage system. In other scenarios, the computing system 100 can be implemented partly in the front office system and partly in the back office system. In the latter implementation, few components of the computing system 100 can be present on the front office system and certain other components of the computing system 100 can be present on the back office system.
In the network environment, the computing system 100 in the brokerage system can, on one hand, communicate with various trading exchange systems 102-1, 102-2....102-N, individually referred to as trading exchange system 102 and collectively referred to as trading exchange systems 102. On the other hand, the computing system 100 can communicate with various user devices 104-1, 104-2, ...104-N, individually referred to as user device 104 and collectively referred to as user devices 104. In an

implementation, the computing system 100 can communicate with the trading exchange systems 102 and the user devices 104 over a network 106.
The network 106 can be a wireless network, a wired network, or a combination thereof. The network 106 can also be an individual network or a collection of many such individual networks, interconnected with each other and functioning as a single large network, e.g., the Internet or an intranet. The network 106 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), and the internet. The network 106 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP). Transmission Control ProtocoJ/Internet Protocol (TCP/IP), and Wireless Application Protocol (WAP), to communicate with each other. Further, the network 106 may include network devices, such as network switches, hubs, routers, host bus adapters (HBAs). for providing a link between the computing system 100, and the trading exchange systems 102 and the user devices 104. The network devices within the network 106 may interact with the computing system 100. the trading exchange systems 102, and the user devices 104 through the communication links.
In an implementation, the computing system 100 and the trading exchange systems 102 can be implemented as a variety of devices, such as servers, mainframe computers, personal computers (PCs), laptops, and personal digital assistants (PDAs). In one example, the trading exchange systems 102 are provided at various trading exchanges at which trading of different types of financial instruments can be achieved. Further, in an implementation, the user devices 104 can be implemented as any of a variety of conventional computing devices, including, for example, servers, desktop PCs, notebooks or portable computers, workstations, mainframe computers, mobile computing devices, cellular phones, entertainment devices, PDAs, and internet appliances. The user devices 104 can be present with various traders and investors, collectively referred to as users. involved in the purchase and sale of financial instruments on the trading exchanges.

In order to carry out a trade, the users communicate with the trading exchange systems 102 at the trading exchanges through the user devices 104. The communication between the user devices 104 with the trading exchange systems 102 includes exchange of transaction messages through the computing system 100. The transaction messages from the user devices 104 are received by the computing system 100. processed for risk management checks, etc.. and then forwarded to the trading exchange system 102. These transaction messages are said to follow a forward path and include order messages, such as order confirmation, order modification, and order cancellation messages. Further, the transaction messages exchanged along a reverse path, i.e., from the trading exchange systems 102 to the computing system 100 for processing and finally to the user devices 104, include acknowledgement messages, such as order acknowledgments and trade acknowledgements. In one example, the order acknowledgments include order confirmation acknowledgements, order modification acknowledgements, and order cancellation modifications, sent by the trading exchange systems 102. Each transaction message, for example, the acknowledgement message has a message ID and an order ID associated therewith to identify the transaction message. Further, different transaction messages relating to a single order share the same order ID. According to an implementation, the computing system 100 regulates the message traffic of the transaction messages exchanged along the reverse path.
In an implementation, the computing system 100 includes a processor 108 and memory 110. The processor 108 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor 108 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 108 is configured to fetch and execute computer-readable instructions and data stored in the memory 110.

The memory 110 may include any computer-readable medium known in the art including, for example, volatile memory such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
Further, the memory 110 includes module(s) 112 and data 114. The module(s) 112 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types. In one implementation, the module(s) 112 include a determination module 116, an updating module 118, and an allocation module 120, and other modules 122. The other modules 122 may include programs or coded instructions that supplement applications and functions of the computing system 100. for example, programs in the operating system. On the other hand, the data 114, amongst other things, serves as a repository for storing data processed, received, and generated by one or more of the module(s) 112. In one implementation, the data 114 includes listed data 124, system resource data 126, and other data 128. The other data 128 includes data generated as a result of the execution of one or more modules in the other modules 122. The listed data 124 can include, for example, order ID lists and pending lists. In another example, the listed data can also include trade lists. In an implementation, the listed data 124, such as the order ID lists, the pending Jists, and the trade lists, can be provided in the form of linked lists. However, it will be understood that the listed data 124 can also be provided as other types of data structures. The order ID lists, pending lists, and trade lists will be explained in detail with reference to operation of the computing system 100.
Further, the computing system 100 can also include I/O interfaces (not shown in figure). The I/O interfaces may include a variety of software and hardware interfaces, for example, interface for peripheral device(s) such as a keyboard, a mouse, an external memory, a printer, etc. Further, the I/O interfaces may enable the computing system 100 to communicate with other computing devices, such as web servers and external databases.

The I/O interfaces may facilitate multiple communications within a wide variety of protocols and networks, such as the network 106. The I/O interfaces may include one or more ports for connecting the computing system 100 to a number of computing devices. such as the trading exchange systems 102 and the user devices 104. In one implementation, during operation, the computing system 100 receives transaction messages from the trading exchange systems 102 and the allocation module 120 allocates system resources, such as trade processes, for processing the transaction messages. In one implementation, the computing system 100 regulates message traffic and allocates system resources when system resources are available for allocation, which can be indicated by the system resource data 126. As mentioned earlier, the transaction messages include order acknowledgements and trade acknowledgements. According to an implementation, the allocation module 120 allocates the system resources to the transaction messages according to a first serialization constraint. In said implementation. the allocation of the system resources to the transaction messages, including both order acknowledgments and trade acknowledgements and having the same order ID, is achieved based on a first-come-first-serve (FCFS) scheme.
In an implementation, when a transaction message is received by the brokerage system, the transaction message is stored in a cache memory of the front office system. Further, the order ID and the message ID of the transaction message are communicated to the computing system 100. In one example, the order ID and the message ID of the transaction message are sent to an input queue of the determination module 116. In one example, in case the transaction message is received by the computing device 100 for the first time, the updating module 118 creates an order ID list and stores it in the order ID list in the listed data 124. Further, the order ID list can also include a status of the order ID, which indicates whether a transaction message associated with that order ID is being processed or not. the status in the two scenarios being 'processing' or 'idle' respectively. In another example, when the order ID list is already created and stored in the listed data 124, the determination module 116 determines whether or not the order ID of

the transaction message is present in the order ID list. If the order ID is not present in the order ID list, then the updating module 118 updates the order ID list by inserting the order ID. Further, the allocation module 120 allocates an idle system resource, for example, a trade process, to the transaction message associated with the order ID for processing of the transaction message. In such a scenario, the transaction message is retrieved from the cache memory of the front office system and sent to an input queue of the idle system resource. At the same time, in one implementation, the update module 118 updates a status of the system resource in the system resource data 126 to indicate that the system resource is occupied.
On the other hand, if the order ID is present in the order ID list, then the update module 118 inserts the message ID of the transaction message in a pending list associated with the order ID list. Each order ID in the order ID list is associated with the corresponding order ID in the pending list. In one implementation, the pending list can be created by the update module 118 when a first instance of a serialization conflict for allocation of resource is encountered by the determination module 116, i.e. an order ID similar to the order ID of the transaction message is preseni in the order ID list indicating either processing of another transaction message with same order ID, or presence of other transaction messages with same order ID and stored in the pending list. Further in an implementation, the pending list can include a status of the order ID, As mentioned before, in case the order ID of the transaction message is not present in the order ID list, no serialization conflict exists and the allocation module 120 allocates an idle system resource to the transaction message. Further, the update module 118 updates the order ID in the order ID list and also updates the status of the order ID to 'processing'. Further, any transaction message received from the trading exchange with the same order ID, the update module 118 inserts the message ID of the transaction message in the pending list. Furthermore, the updating module 118 also updates the status of the system resource in the system resource data 126 to indicate that the system resource is occupied.

In one implementation, subsequent to the completion of processing of the transaction message, the updating module 118 updates the status of the system resource in the system resource data 126 to indicate that the system resource is available for allocation. Subsequent to the completion of processing of the transaction message, in an implementation, the determination module 116 determines whether any other transaction message is received by the computing system 100. In one example, the determination module 116 checks the input queue for the order ID and the message ID from the front office system to determine whether any other transaction message is received. The new transaction message received is processed in the same way as described above. Conversely, if the determination module 116 determines that no other transaction message is received, then, in one implementation, the allocation module 320 begins allocating the idle system resources to the transaction messages having message IDs in the pending list. In said implementation, the allocation module 120 begins allocating the idle system resources to the transaction messages based on the FCFS scheme, for example, the order ID of the transaction messages for which the message ID was first inserted in the pending list is given priority.
In another implementation, the allocation module 120 allocates the system resources to the transaction messages for processing based on a second serialization constraint. According to the second serialization constraint, the order acknowledgements, such as the order confirmation, order modification, and order cancellation acknowledgements are allocated the system resources and processed in the same manner as achieved under the first serialization constraint, for example, in an FCFS manner. However, the allocation module 120 allocates the system resources to the trade acknowledgements without following any particular order. In an example, according to the second serialization constraint, the processing of the trade acknowledgements is given lowest priority amongst the order acknowledgements being received by the brokerage system, those added in the pending list, and the trade acknowledgements in order to prevent the system resources from being blocked for long durations.

According to said implementation, the transaction message received by the brokerage system, having the order ID and the message ID queued in the input queue of the determination module 116, are first checked for type of message by the determination module 116. In case the transaction message is an order acknowledgement, the transaction message is processed by the computing system 100 in the same manner as described above with reference to the first serialization constraint.
Further, if the received transaction message is identified to be a trade acknowledgement, then the updating module 118 updates the trade list with the order ID of the trade acknowledgement. The trade list generally includes the order IDs of the trade acknowledgements received from the trading exchanges, which may be associated with the same order ID in the order ID list. In case the order ID is not present in the trade list, the updating module 118 creates an order ID and associates the list of trade acknowledgements for that order ID with the created order ID in the trade list. It would be understood that for the order ID, for which the trade acknowledgement is received, a corresponding order ID entry is created in the order ID list, (if an entry for the order ID did not exist previously) and subsequently the trade list is updated with the order ID of the trade acknowledgement. As mentioned earlier, in one implementation, the trade acknowledgements are given low priority in comparison to order acknowledgements. In an implementation, the first priority is given to new incoming transaction messages such as order acknowledgements, and the order acknowledgements waiting in the pending list to be allocated the system resource are given next preference. Hence, in the said implementation, after each system resource becomes free and the updating module 118 updates the status of the system resource in the system resource data 126, the determination module 116 checks whether there are order acknowledgements in the input queue or in the pending list. In case there are no order acknowledgements, the allocation module 120 allocates system resources to the trade acknowledgements pending in the trade list, for example, on a FCFS basis.

Further, according to an implementation, the allocation module 120 can be configured to allocate a share of the system resources to the trade acknowledgements. For example, during allocation of the system resources to trade acknowledgements for processing, the allocation module 120 can be configured to allocate m system resources from the total n system resources of the computing device 100. In said example, the rest n-m system resources are made available for the order acknowledgements. As a result of such a configuration of the allocation module 120. the trade acknowledgements do not block all the system resources at the same time and the processing ability of the computing system is not considerably affected.
According to another implementation, the computing system 100 can include auxiliary system resources identified from the total system resources available in the computing system 100. As will be understood, the auxiliary system resources are those system resources which are allocated to trade acknowledgements. In one example, they may reside on the computing system 100; however, in other exemplary implementations, the auxiliary system resources may reside on an auxiliary system (not shown in figure) connected to the computing system 100 over the network 106. In said implementation, the allocation module 120 can allocate the auxiliary system resources to the trade acknowledgments and rest of the system resources to the order acknowledgements. In this manner, the computing system 100 can allocate the system resources and achieve the processing of the transaction messages based on the second serialization constraint. At the same time, considerable amount of system resources remain available for being allocated to the order acknowledgements.
In addition, according to an aspect of the present subject matter, the updating module 118 achieves a clean-up function during which the order ID list and the pending list are cleared of those order IDs for which all the transaction messages have been processed. According an implementation, upon the completion of processing of each transaction message, the updating module 118 checks whether there is any message ID associated with the order ID of the processed transaction message. In case there is no other

message ID associated with the order ID then the updating module 118 removes the order ID from the pending list and from the order ID list in the listed data 124. As described earlier, in case there is at least one message ID associated with the order ID. the updating module 118 updates the status of the order ID to 'idle' to indicate that there is no serialization conflict in processing the next transaction message belonging to that order ID and the messages associated with this order ID can be processed during the processing of the pending list.
Fig. 2 and Fig. 3 illustrate exemplary methods 200 and 300 for optimizing system resource allocation in a brokerage system, according to different implementation of the present subject matter. In one example, the methods 200 and 300 are carried out by the computing system 100 in the brokerage system. According to an aspect, the computing system 100 executes the methods 200 or 300 when system resources are available in the computing system 100 for allocation. The exemplary methods may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.
The order in which the methods are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method, or an alternative method. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. The methods are presently provided for position-keeping in a multi-market environment. It would be appreciated that the same

methods can also be implemented for position-keeping in other market environments without deviating from the scope of the present subject matter.
Fig. 2 illustrates an exemplary method 200 of optimizing system resource allocation in the brokerage system, according to an implementation of the present subject matter. According to an implementation, method 200 is implemented to regulate message traffic based on a first serialization constraint. According to the first serialization constraint, transaction messages, such as acknowledgement messages, received from the trading exchanges are allocated system resources and processed based on first-come-first-serve (FCFS) basis.
At block 202, an order ID and a message ID of a transaction message are received, in response to a receipt of a transaction message at the brokerage system. In an example, the order ID and the message ID of the transaction message are received in an input queue of the determination module 116. In said example, the transaction message is received in a cache memory of a front office system of the brokerage system and the order ID and the message ID of the transaction message are communicated to the input queue of the determination module 116. The transaction messages can include acknowledgement messages, such as order acknowledgements and trade acknowledgements. Further, the order acknowledgments can include order confirmation acknowledgements, order modification acknowledgements, and order cancellation acknowledgements. Further, in an example, the transaction message is received from the trading exchange communicating with the brokerage system
At block 204, it is determined whether the order ID of the transaction message already exists in an order ID list. In one example, the determination of whether the order ID of the transaction message already exists in the order ID list is done by the determination module 116 from the order ID list stored in the listed data 124. The order ID list contains the order IDs of all the transaction messages received by the brokerage system, and are either under processing or pending for processing with the computing system 100. The order ID list may also include a status of the order ID. The status of the

order ID indicates either' processing' or 'idle', both of which mean that at least one
message ID belonging to this order ID is present in the order ID list.
If it is determined at block 204 that the order ID exists in the order ID list (YES
path from block 204). then at block 206. the message ID of the received transaction
message is inserted in a pending list associated with the order ID list. For example, the
updating module 118 inserts the message ID in the pending list and stores the update in the
listed data 124.
On the other hand, if at block 204, it is determined that the order ID does not
exist in the order ID list (NO path from block 204). then the order ID of the transaction
message is inserted in the order ID list at block 208. For example, the updating of the order
ID list in the listed data 124 by inserting the order ID is achieved by the updating module
118.
Further, at block 210, an idle system resource, such as a trade process, is
allocated to the transaction message for processing of the transaction process. In one
exemplar)' scenario, the allocation of the system resource to the transaction message is
achieved by the allocation module 120. In an implementation, upon the allocation of the
system resource to the transaction message, the status of the order ID associated with the
order ID is updated in the order ID list to indicate that the transaction message belonging
to this order ID is under processing. As explained earlier, any other transaction message,
received by the brokerage system, belonging to the same order ID is put on wait and the
message ID of the other transaction message inserted in the pending list.
Further, in an implementation, when the system resource is allocated to the
transaction message for processing, the status of the system resource, for example, in the
system resource data 126, is updated to indicate that the system resource is occupied and
not available for allocation. In one example, the system resource data 126 is updated by the
updating module 118.
In an implementation, after the completion of processing of the transaction
message, at block 212 it is determine whether any other transaction message is received

from the trading exchange. Further, the determination at block 212 is also achieved, in another scenario where the message ID of the transaction message is inserted in the pending list. In one example, the receipt of the other transaction message from the trading exchange is determined from the input queue of the determination module 116. In said example, a non-empty input queue indicates that at least one other transaction message is received by the computing system 100. In such a case (YES path from block 212), the procedure as described with reference to block 202 onwards is followed by the method 200.
Further, in another case, in which the input queue of the determination module 116 is empty, it indicates that no other transaction message is received by the computing system 100. In such a case (NO path from block 212), the system resources are allocated to the waiting transaction messages, i.e., those transaction messages having the message IDs in the pending list, at block 214. In one example, the allocation module 120 allocates the system resources to the transaction messages having message IDs in the pending list based on the first serialization constraint, i.e., based on an FCFS scheme. Hence, in said example, the allocation module 120 allocates the system resources to that transaction message for which the order ID status is set as 'idle' in the order ID list. Further, in one implementation, subsequent to the processing of the transaction message, the message ID of the processed transaction message is removed from the pending list. Further, as explained earlier, when the transaction messages based on the pending list are being allocated system resources, at the same time new transaction messages received from the trading exchanges and not having an order ID already in the order ID list are also allocated system resources, as explained with reference to blocks 204, 208, and 210.
Fig. 3 illustrates an exemplar)' method 300 for optimizing system resource allocation in the brokerage system, according to another implementation of the present subject matter. According to an implementation, the method 300 is implemented to regulate the message traffic based on a second serialization constraint. In one example.

according to the second serialization constraint, the allocation of the system resources to the order acknowledgements, such as order confirmation, order modification, and order cancellation acknowledgements, is achieved based on the FCFS scheme. On the other hand, according to the second serialization constraint, while allocating the system resources to the trade acknowledgements, no particular order is followed. Further, in one example, the trade acknowledgements are given the lowest priority for allocation of system resources, the order acknowledgements in waiting, i.e., those in the pending list are given a higher priority than the trade acknowledgements, and the order acknowledgements received from the trading exchange are given highest priority.
At block 302, the transaction message is received from the trading exchange. As mentioned earlier, the transaction messages include acknowledgement messages, such as order acknowledgements and trade acknowledgements. Further, in one example, the transaction message is received in a cache memory of a front office system of the brokerage system and the order ID and the message ID of the transaction message are communicated to the input queue of the determination module 116.
At block 304, a message type of the transaction message is determined by, for example, the determination module 116. In one example, the message type of the transaction message is identified based on a tag included in the transaction message by the trading exchange.
Further, at block 306, it is ascertained, based on the message type of the message, whether the transaction message is trade acknowledgement or not. In case, the transaction message is not a trade acknowledgement (NO path from block 306), which, in one example, means that the transaction message is an order acknowledgment, the transaction message is processed for allocation of the system resource at block 308. According to an implementation, since the order acknowledgements are allocated system resources according to the FCFS scheme, i.e., according to the first serialization constraint, at block 308, the transaction message is processed in the same manner as described with reference to blocks 202, 204, 206, 208, and 210, of method 200.

In case the transaction message is a trade acknowledgement (YES path from block 306). then at block 310, it is determined whether the order ID associated with the transaction message exists in a trade list. In an example, the trade list includes the order ID of the trade acknowledgements and a list of message IDs, such as trade acknowledgement IDs, associated with the order ID. pending for execution. Further, the trade list is associated with the order list, and as explained earlier, the order list includes the order IDs of the transaction messages pending for processing, and the status of the order IDs is either 'processing' or 'idle'. Hence, according to said example, the trade list can be understood as a pending list of trade acknowledgements.
Further, if it is determined, at block 310. that the order ID associated with the transaction message does not exist in the trade list (NO path from block 310). then the order ID associated with the transaction message is inserted in the order ID list, at block 312. Further, in an implementation, subsequent to the entry of the order ID in the order list, the trade list is also updated. In one example, the message ID of the transaction message is associated with the order ID in the trade list, at block 314.
On the other hand, if, at block 310, it is determined that the order ID associated with the transaction message exists in the trade list (NO path from block 310). then the trade list is updated, at block 314, for example, by inserting the message ID of the transaction message in the trade list and associating the message ID with the identified order ID.
In an implementation, subsequent to updating of the trade list at block 314, at block 316. it is determined whether any other transaction message is received from the trading exchange. In an implementation, the determination at block 316 is also made subsequent to the allocation of the system resource to the transaction message at block 308. As described previously, the determination of the receipt of the other transaction message from the trading exchange, at block 316, is achieved from the input queue of the determination module 116. In said example, a non-empty input queue indicates that at least one other transaction message is received by the computing system 100, and in such a case

(YES path from block 316), the procedure as described onwards from block 304 in method 300 is followed.
Further, in the other case, in which the input queue of the determination module 116 is empty, it indicates that no other transaction message is received by the computing system 100. In such a case (NO path from block 316), at block 318, it is determined whether there is any message ID in the pending list, corresponding to the transaction message waiting to be processed. In an example, the determination at block 318 is achieved by the determination module 116.
If the determination at block 318 yields the result that the pending list has at least one message ID, i.e., there is at least one pending transaction message, then the system resources are allocated to the pending transaction message at block 320. In one example, in case there are a plurality of message IDs in the pending list, and hence pending transaction messages, then the allocation module 120 allocates the system resources to the transaction messages based on the first serialization constraint, i.e.. based on an FCFS scheme. Further, as explained earlier, subsequent to the processing of the transaction message, the message ID of the processed transaction message is removed from the pending list.
Further, if the determination at block 318 yields the result that the pending list does not have any message IDs, which means that there are no pending transaction messages waiting for allocation of system resources, then at block 322, the system resources are allocated to the transaction messages having message IDs in the trade list. Hence, in one example, the trade acknowledgements pending for processing are allocated the system resources by the allocation module 120 for processing, at block 322. In an implementation, upon the completion of processing of each transaction message in accordance with method 200 and 300, for example, subsequent to the procedure at block 214 in method 200 and subsequent to the procedure at block 320 in method 300, a clean-up of the order ID list is carried out. According to said implementation, upon completion of processing of the transaction message, it is

determined whether a message ID associated with the order ID of the transaction message exists in the pending list or not. If there is no message ID associated with the order ID in the pending list then the order ID is removed from the pending list and the order ID list. On the other hand, if there is at least one message ID in the pending list associated with the order ID, then the status of the order ID is set to 'idle' to indicate that the transaction message corresponding to that order ID is pending for processing without any serialization conflict.

I/We claim:
1. A method for optimization of system resource allocation in a brokerage system, the
method comprising:
identifying an order ID and a message ID associated with a transaction message in response to receipt of the transaction message;
determining, based on the order ID and an order ID list, whether the allocation of a system resource for processing the transaction message entails a serialization conflict; and
allocating the system resource for processing the transaction message when the allocation of the system resource for processing thf transaction message does not entail the serialization conflict.
2. The method as claimed in claim 1. wherein the allocating comprises:
inserting the order ID of the transaction message in an order ID list; and updating a status o? foe order YD m foe order l£> 'As*, -wherein Yrie states of Vnt
order ID is indicative of the transaction message associated with the order ID being
processed.
3. The method as claimed in claim 1 wherein the allocating comprises inserting the message ID of the transaction message in a pending list, based on the allocation of the system resource to the transaction message entailing the serialization conflict.
4. The method as claimed in claim 3. further comprising:
ascertaining whether another transaction message is received; and processing at least one message ID from the pending list for allocation of the system resource to a subsequent transaction message associated with the at least one message ID, when ascertained that the another transaction message is not received.
5. The method as claimed in claim 1, wherein the determining is based on a first serialization constraint, and wherein the first serialization constraint comprises processing the transaction messages in a first-come-first-serve order.
6. A method for optimizing system resource allocation in a brokerage system, the method comprising:

identifying a message type of a transaction message, in response to receipt of the transaction message;
processing the transaction message for allocating a system resource to the transaction message based on a first serialization constraint, when the transaction message is an order acknowledgement; and
updating a trade list with a message ID of the transaction message, in response to determining whether an order ID of the transaction message is present in the trade list, when the transaction message is a trade acknowledgement.
7. The method as claimed in claim 6. wherein the processing the transaction message
based on the first serialization constraint comprises:
determining whether the allocation of the system resource to the transaction message involves a serialization conflict, wherein the determining is based on the order ID of the transaction message;
allocating the system resource to the transaction message when the allocation does not involve the serialization conflict.
8. The method as claimed in claim 6, wherein the updating the trade list further
comprises:
identifying whether another transaction message is received;
ascertaining, in response to the identifying, whether at least one message ID is associated with a pending list;
allocating the system resource to the transaction message based on the ascertaining, wherein the transaction message is the trade acknowledgement.
9. A computing system (100) for optimizing system resource allocation in a brokerage
system, the computing system (100) comprising:
a determination module (116) configured to.
determine a message type of a transaction message, in response to receipt of the transaction message;
ascertain, based on the message type, whether an order ID of the transaction message is present in a trade list; and

identify, in response to the order ID not being present in the trade list, whether the order ID is present in an order ID list; and
an allocation module (320) to allocate the system resource to the transaction message, based on the identifying by the determination module (116).
10. The computing system (100) as claimed in claim 9, wherein the determination
module (116) is further configured to:
identify the order ID and a message ID of the transaction message, wherein the determination module (116) determines the order ID and a message ID of the transaction message from an input queue of the determination module (116); and
ascertain whether an allocation of the system resource to the transaction message involves a serialization conflict, based on the order ID list.
11. The computing system (100) as claimed in claim 10, wherein the allocation module (120) is further configured to allocate the system resource to the transaction message when the determination module (116) ascertains that the allocation of the system resource to the transaction message does not involve the serialization conflict.
12. The computing system (100) as claimed in claim 10, wherein the allocation module (120) is further configured to insert the message ID of the transaction message in a pending list when the determination module (116) ascertains that the allocation of the system resource to the transaction message involves the serialization conflict.
13. The computing system (100) as claimed in claim 9, wherein the determination module (116) is further configured to determine whether a new transaction message is received for processing.
14. The computing system (100) as claimed in claim 13, wherein the allocation module (120) is further configured to allocate the system resource to at least one transaction message having a message ID in a pending list when the determination module (116) determines that the new transaction message is not received.
15. The computing system (100) as claimed in claim 13, wherein the allocation module (120) is configured to allocate the system resource to the transaction message having the order ID in the trade list when the determination module (116) ascertains that the new transaction message is not received and a pending list is empty.

16. A computer-readable medium having a set of computer readable instructions that, when executed, perform acts comprising:
determining whether an order ID associated with a transaction message is present in an order ID list;
inserting a message ID associated with the transaction message in a pending list when the order ID is not present in the order ID list; and
allocating an idle system resource for processing the transaction message having the message ID in the pending list when no new transaction message is received for processing.