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: QUERY PROCESSING IN A TRADING ENVIRONMENT
2, Applicant (s)
NAME NATIONALITY ADDRESS
TATA CONSULTANCY Indian Nirmal Building, 9th Floor, Nariman Point, SERVICES LIMITED Mumbai, Maharashtra 400021, 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 query processing and in
particular, to systems and methods for valuation and balance related query processing within an online trading environment.
BACKGROUND
Financial institutions, retail banks, and investment banks, in particular, allow
customers or account holders to view details pertaining to their accounts through online portals. The details pertaining to accounts include portfolio valuation, current balance, gain or loss incurred during a transaction, weighted average cost price, market value of commodities, and exchange rate of currencies. Usually during a day. prices of various commodities, such as shares, stocks, and security bonds, may change, based on various factors such as demand and supply, market capitalization, and rate of interest. Based on the changes in the price of commodities, an account holder may perform one or more business transactions, such as purchase or sell commodities, which further introduce changes in the details pertaining to his account. Further, the details pertaining to the account holder's account may also change without the account holder performing a business transaction. For example, due to developments in a market, such as launching of a new product, corporate action announcements, the prices of shares or stocks or acquisition cost of stocks may change resulting in change in the account balance or in the portfolio valuation of the account holder.
In general, the account holder obtains real time updated information regarding
the details pertaining to his account through the online portals. The information requested by the account holder results in querying of a database which stores the details pertaining to the accounts, retrieving information from the database based on the valuation and balance related query, henceforth referred to as trade query, and presenting the retrieved information to the account holder in various formats. Further certain financial institutions, retail banks, investment banks, etc.. facilitate the account holder to operate his account through various facilities such as phone banking, call centers, brokers, etc. The requests of the account holder are usually handled by an operator who queries information from the database, obtains information from the database, and conveys the same to the account holder.

SUMMARY
This summary is provided to introduce concepts related to systems and methods
for valuation and balance related query processing within a trading environment, which is 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.
In one implementation, the method includes identifying at least one resultant
value of a trade query, related to at least one account, based in part on an associated tag of the trade query, and ascertaining whether the at least one resultant value is stored in a cache data. If the at least one resultant value is ascertained to be stored in the cache data, the method further includes determining whether the at least one resultant value stored in the cache data is consistent with a corresponding value stored in a data repository, based on the ascertaining; and reading the value from the cache data to provide a response to the trade query.
BRIEF DESCRIPTION OF THE DRAWINGS
The detailed description is described with reference to the accompanying figures.
In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and components.
Fig. 1 illustrates an exemplary network implementation of a query processing
system, in accordance with an embodiment of the present subject matter.
Fig. 2 illustrates an exemplary method of processing trade related queries, in
accordance with an implementation of the present subject matter.
Fig. 3 illustrates an exemplary method of posting of trade related transactions, in
accordance with an implementation of the present subject matter.
Fig. 4 illustrates an exemplary method of management of cache data, in accordance with an implementation of the present subject matter.

DETAILED DESCRIPTION
Systems and methods for valuation and balance related query processing
within a trading environment are described herein. The systems and methods can be implemented in a variety of computing systems. The computing systems that can implement the described method(s) include, but are not restricted to, mainframe computers, workstations. personal computers, desktop computers, minicomputers, servers, multiprocessor systems, laptops and the like.
Conventionally, account holders of a financial institution, such as a retail bank,
an investment bank, a stock brokerage bank, an asset management firm, and an insurance company, use their accounts to perform various operations, such as business transactions including purchasing and selling commodities. The operations may also include allowing the account holder to view details pertaining to his accounts such as real-time account balance and portfolio valuation details. To facilitate the account holders to carry out business transactions, the financial institutions allow the account holders to view various details pertaining to their accounts, such as portfolio valuation, current balance, unrealized gain or loss due to change in market price or exchange rate, weighted average cost price, market value of commodities, exchange rate of currencies, etc., through various mechanisms. For example, certain financial institutions allow the account holders to operate their accounts and view or modify various details pertaining to their accounts through internet banking tools wherein the account holder operates his account, such as perform business transactions, and view details pertaining to his account, through an online portal associated with the financial institution. Conventionally, the online portal associated with the financial institution provides various facilities to perform business transactions, for example, bill payment, transfer of funds, purchase or sell of commodities, etc. Moreover, the online portal also provides the account holders with options to view account balance, recent transactions, download transaction history in one or more file formats, etc.
Typically the online portal associated with the financial institution stores the
details pertaining to the accounts of the account holders in a database. When the account holder makes a request, to perform a business transaction or to view details pertaining to his account, through the online portal, the request is serviced by querying the database. A

valuation and balance related query, henceforth referred to as a trade query, is a code that is run on a database to retrieve historical transactions related data from the database or compute net balance, weighted average cost price, cost value in account currency, market currency in a trading environment etc. Subsequently, the data is retrieved from the database based on the trade query and presented to the account holder in various formats. For example, if an account holder requests the generation of transaction history for the year 2010, the database is queried to retrieve the opening balance in the year 2010, details of transactions performed in the year 2010. and closing balance of the year 2010. Moreover, certain details pertaining to the account of the account holder, such as account balance, portfolio valuation, change with every business transaction carried out by the user.
Further certain details such as account balance, portfolio valuation, cash
balance, and security balance may change without the account holder actually performing a business transaction. For example, changes in price of shares or stocks held by the account holder, changes in the exchange rate in currencies, etc., may change the account balance or portfolio valuation of the account holder. An account holder may wish to view the details of his accounts at regular time intervals and accordingly perform transactions. However, trade queries made by such an account holder may result in generation of a huge number of trade queries to be run on the database. Running a huge number of queries and exchanging high volume of data between the database and application server reduces the performance of the servers, which further translates into delayed response time or connection timeout, etc. Moreover trade queries pertaining to details of the account usually involve retrieval or scanning of multiple records or multiple rows of one or more tables of the database. Accessing multiple records in the database, which is usually large is size, consume a lot of system resources in terms of processor and memory usage, which results in a significant degradation in the response and throughput of the database and the online trading applications running on the database.
Moreover, certain financial institutions facilitate the account holders to obtain
details pertaining to their accounts from the support staff of the financial institutions such as through call centers, tele-services, etc. On instructions or authorization from the account holder, an executive of the financial institution retrieves details pertaining to the account of

the account holders and conveys the same to the account holder. This also adds to the number of trade queries to be run on the database and hence increases the load on the database resulting in even slower response making it difficult for account holders to operate their accounts. Moreover, the high volume of trades in an online trading system also generates high processing load in the database and the application system. The high volume of trade processing load, demands very high response time so as to ensure that the account holders do not face any financial impact because of the change in market conditions.
The present subject matter describes systems and methods for trade query
processing within a trading environment. In one implementation, the query processing system is configured to store values associated with trade queries in a cache data. In said implementation, the query processing system is further configured to track changes in the values stored in the cache data. For example, the query processing system is configured ro maintain a status indicator indicating whether a value associated with a parameter of an account of an account holder and stored in the cache data is consistent with the corresponding value associated with the same parameter in a data repository.
In operation, when the account holder requests the details pertaining to his
account through a user interface, a trade query is generated so as to retrieve the details from the data repository, which stores all details pertaining to accounts. The values retrieved as a result of running the trade query on the data repository is saved in the cache data and a status indicator is set indicating that the value as stored in the data repository and as saved in the cache data, are the same. After a time interval, the account holder may request for the updated details pertaining to his account. During the time interval, the details may have been updated due to various reasons such as the account holder performing a business transaction, etc. or the details may have remained unchanged. When the request for the updated details pertaining to the account holder's account is received, the query processing system determines if the values that would be associated with the trade query is available in the cache data. If the values are available in the cache data, the query processing system determines if the values are consistent with corresponding values in the data repository. For example, the query processing system may ascertain in the status indicator is set to ensure that the values are

consistent. If it is ascertained, the values are ascertained to be consistent; the query processing system retrieves the values from the cache data and conveys the same to the account holder.
However, if the values are not present in the cache data or if the values are
determined to be inconsistent with the corresponding values stored in the data repository, the query processing system retrieves the values from the data repository and conveys the same to the account holder. Further, the query processing system also stores the value or updates the value in the cache data and sets the status indicator indicating the values in the cache data are now consistent with the corresponding values in the data repository. Additionally, in the said embodiment, whenever, there is a change in any of the values stored in the cache data, the status indicator associated with the corresponding value is unset indicating that the value in the cache data is not consistent with the corresponding value stored in the data repository.
Further, in said embodiment, the query processing system may be configured
to determine the source of the trade query and prioritize the processing of the trade query based on the source of the trade query. For example, the query processing system may be configured to process trade queries from account holders on a priority basis and give less priority to trade queries received from the support staff or the call centre associated with the financial institution. In yet another embodiment, the query processing system may be further configured to prioritize trade queries based on the type of operations generating the trade query. For example, trade queries resulting due to a business transaction such as purchase or sell of commodities may be given more priority than trade queries resulting due to request for viewing transactions performed with a time interval.
Thus the query processing system optimizes the response time and
performance of trade queries run on a data repository in a trading environment. These and other advantages of the query processing system would be described in greater detail in conjunction with the following figures. While aspects of described systems and methods for the query processing system within a trading environment 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(s).

Fig. 1 illustrates an exemplary network environment ]00 implementing a query
processing system 102 within a trading environment, according to an embodiment of the present subject matter. In said embodiment, the network environment 100 includes the query processing system 102 configured to process trade queries pertaining to details of accounts of account holders in a financial institution, for example a retail bank, an investment bank, a stock brokerage bank, an asset management firm, an insurance company, etc. In one implementation, the query processing system 102 may be included within an existing banking system associated with the financial institution. The query processing system 102 may be implemented in a variety of computing systems such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server and the like. It will be understood that the query processing system 102 may be accessed by account holders through one or more client devices 104 or applications residing on client devices 104, such as online banking applications, mobile banking applications, etc. Examples of the client devices 104 include, but are not limited to, a portable computer 104-1, an ATM 104-2, a handheld device 104-3, a workstation 104-N, etc. As shown in the figure, such client devices 104 are communicatively coupled to the query processing system 102 through a network 106 for facilitating one or more account holders to access and operate their accounts.
The network 106 may be a wireless network, wired network or a combination
thereof. 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), the internet, and such. 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 Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc.. to communicate with each other. Further the network 106 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.
In one implementation, the query processing system 102 includes a
processor(s) 108, input-output (I/O) interface(s) 110. and a memory 112, The processor(s) 108 are coupled to the memory 112. The processor(s) 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(s) 108 are configured to fetch and execute computer-readable instructions stored in the memory 112.
The I/O interface(s) 110 may include a variety of software and hardware
interfaces, for example, a web interface, a graphical user interface, etc., allowing the query processing system 102 to interact with the client devices 104. Further, the I/O interface(s) 110 may enable the query processing system 102 to communicate with other computing devices, such as web servers and external data servers (not shown in figure). The I/O interface(s) 110 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example LAN, cable, etc., and wireless networks such as WLAN, cellular, or satellite. The I/O interface(s) 110 may include one or more ports for connecting a number of devices to each other or to another server.
The memory 112 can include any computer-readable medium known in the art
including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g., EPROM, flash memory, etc.). In one embodiment, the memory 112 includes module(s) 114 and program data 116. The module(s) 114 further include a query analysis module 118, a data status module 120, a tag association module 122, and other module(s) 124. It will be appreciated that such modules may be represented as a single module or a combination of different modules. Additionally, the memory 112 further includes data 116 that serves. amongst other things, as a repository for storing data fetched processed, received and generated by one or more of the module(s) 114. The data 116 includes, for example, cache data 126, analysis data 128, and other data 130. In one embodiment, the cache data 126, the analysis data 128. and the other data 130, may be stored in the memory 112 in the form of data structures. Additionally, the aforementioned data can be organized using data models, such as relational or hierarchical data models.
In one implementation, the network environment 100 also includes a data
repository 132, which stores details of one or more accounts of account holders within the financial institution. The details include account balance, portfolio valuation, cash balance, security balance, etc. Though the query processing system 102 has been shown to be

connected with the data repository 132, it should be appreciated by those skilled in the art. that in other implementations, the data repository 132 may be an integral part of the query processing system 102 or the data repository 132 may be connected to the query processing system 102 through a network such as the network 106.
In operation, the query analysis module 118 receives a request requesting the
details pertaining to an account. For example, an account holder may use an online portal or an application running on a mobile home or an application running on automatic teller machine (ATM) 104-2 to request the details pertaining to the account of the account holder. In another example, a support staff of the financial institution may request information pertaining to an account so as to comply with the requests of the account holders of the financial institution. Each request results in generation of at least one trade query which, when run on the data repository 132, retrieves values related to the details requested by the account holder. In one implementation, the query analysis module 118 determines whether the trade query was generated as a result of a request by an account holder or by a support staff. For example, in one implementation, the query analysis module 118 may determine the whether the trade query was generated as a result of a request by an account holder or by a support staff based on the access channel through which the request was received. In said implementation the access channel may be an additional field, along with the trade query, based on which the analysis module 118 determines the source of generation of the request. Based on the determination, the query analysis module 118 assigns a priority to the trade query and processes the trade query. For example, the query analysis module 118 may be configured to prioritize trade queries generated as a result of requests made by the account holders. In another implementation, the query analysis module 118 is further configured to determine the type of request which resulted in generation of the trade query and assigns the trade query a priority value based on the type of request. For example, trade queries related to a business transaction, such as purchase or sell of commodities, may be assigned a higher priority than trade queries pertaining to requests to view account statement, etc.
In one implementation, the query analysis module 118 determines whether the
values associated with the trade query are already saved in the cache data 126. For example, if a previous trade query involving the retrieval of the same values was run in the recent past

within a specified time interval; say six hours from the time the trade query is received, the values may be present in the cache data 126. On the other hand, if the trade query received has not been run before, the values associated with the trade query have to be retrieved from the data repository 132. Further the tag association module 122 may generate one or more tags to be associated with the values pertaining to the trade query received. In another implementation, the query analysis module 118 may also analyze the trade queries to determine behavioral patterns of one or more account holders. Based on the behavioral pattern, the query analysis module 118 determines the frequency of refreshing the cache data 126. whether to query the data repository 132 or retrieve data from the cache 126, etc. For example, in a scenario where an account holder, say user A, repeatedly sends requests to view his account balance at very short interval of time, say two minutes without carrying out any business transaction, it is very unlikely that there will be any change in the account balance of the user X. In such a scenario, the query analysis module 118 may retrieve the value associated with the account balance of user X from the cache data 126 and convey the same to user X. The value associated with the account balance of user X can be present in the cache data 126, since the trade query retrieving the value associated with the account balance has already been run once. In another scenario, where another account holder, say user Y, is actively performing business transactions such as purchasing or selling stocks, the account balance would change very rapidly. In such a scenario the query analysis module 118 may retrieve the value associated with the account balance ot a user Y from the data repository 132 and convey the same to the user Y.
Further, a value, such as the current account balance of an account holder, may
be further tagged to the trade queries related to business transactions, trade queries related to transaction history, etc. In one implementation, the tags assigned to a value are saved in the analysis data 128. If the values associated with the trade query are already saved in the cache data 126, the data status module 120 determines whether the value in the cache data 126 is consistent with the corresponding value in the data repository 132. In one implementation, the data status module 120 may maintain a status indicator to indicate whether the value in the cache data 126 is consistent with the corresponding value in the data repository 132. For example, the status indicator may be set to indicate that the value in the cache data 126 is consistent with the corresponding value in the data repository 132 and the status indicator

may be reset to indicate that the value in the cache data 126 is stale and is not consistent with the corresponding value in the data repository 132.
In case the data status module 120 determines the status indicator to be set
indicating that the value in the cache data 126 is consistent with the corresponding value in the data repository 132, the value is retrieved from the cache data 126 and conveyed to the account holder. The retrieval of the value from the cache data 126 eliminates querying of the data repository 132. thus, reducing load on the data repository 132 and resulting in better performance and response time of the data repository 132.
On the other hand, if the data status module 120 determines that the value in
the cache data 126 is stale and inconsistent with the corresponding value in the data repository 132, the data status module 120 retrieves the corresponding value from the data repository 132. The retrieval of the value from the data repository 132 may involve scanning through multiple records or rows stored in one or more tables of a database. Further the retrieval of value may also involve performing conventional database operations such as joining of multiple tables, etc. The data status module 120 updates the stale value in the cache data 126 to make the cache data 126 consistent with the corresponding value in the data repository 132 and sets the status indicator to indicate consistency the values in the cache data 162 and the data repository 132. In case the values associated with the trade query are not saved in the cache data 126, the data status module 120 retrieves the values from the data repository 132 and saves the same in the cache data 126. Further, the data status module 120 also sets the status indicator to indicate consistency in the values present in the cache data 126 and the data repository 132. Moreover, in one embodiment, the tag association module 122 is configured to generate one or mode tags to be associated with the values retrieved from data repository 132 and save the same as analysis data 128. The tags associated with the values facilitate the identification of future trade queries which may require one or more of the values retrieved from data repository 132 and saved in the cache data 126.
Further in case of failure of the query processing system 102 or in case of
flushing of the cache data 126 of the query processing system 102, the query processing system 102 may be moved to an offline mode. In the offline mode, the query processing

system 102 is unavailable for serving responses to trade queries generated to retrieve details pertaining to one or more accounts. In the offline mode, the cache data 126 may be flushed, or the date of the query processing system 102 may be switched to a new date. etc. In offline mode a first file, say in form of a batch file or a stored procedure file, is uploaded to the query processing system 102 to reflect or post transactions occurring during a day. For example, the first file may run trade queries for interest calculation, generation of reports and data sets, printing of statements, payment processing, etc.
A second file, which may also be in the form of a batch file or a stored
procedure file, may be uploaded to the query processing system 102. The second file has trade queries which are pending at the inter process communication (IPC) queue. The trade queries may be pending because of various reasons such as rate or receiving requests or trade queries is more than the rate at which the requests or trade queries are processed, a trade query taking longer time to execute due to gradual increase in the size of the data repository 132, etc. Further, in some implementations, a third file pertaining to business transactions which were carried out during the time for which the query processing system 102 was offline, is also uploaded to update the data repository 132. Moreover, the cache data 126 is also updated to reflect the processing of the files.
Thus the query processing system 102 facilitates optimization of query
processing, prioritizing trade queries to be run on a data repository 132, etc., resulting in better performance of the data repository 132, reduced response time of the data repository 132, etc.
Fig, 2 illustrates a method 200 of processing trade related queries, in
accordance with an implementation of the present subject matter. The exemplary method 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, and the like 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 communication 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 method is 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 alternate methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. The method described herein is with reference to the query processing system 102; however, the method can be implemented in other similar systems albeit with a few variations as will be understood by a person skilled in the art.
At block 202, at least one request to retrieve details pertaining to an account is
received. For example, the request may be generated by an account holder or by a support staff of the financial institution. Further, the request may be pertaining to carrying out a business transaction such as purchase or sell or commodities, or may be pertaining to viewing transaction history of the account, etc. In one embodiment, the query analysis module 118 is configured to determine the source of generation of the trade query. In one implementation, the query analysis module 118 may detect the channel through which the request is received.
At block 204, one or more tags associated with the trade query pertaining to
the request are determined. Every request to retrieve details pertaining to an account may result in generation of one or more new trade queries. In one implementation, various tags may be associated with the trade queries. For example, a trade query requesting retrieval of the account balance may be tagged with business transaction, account statement, transaction history, etc. In one embodiment, the tag association module 122 tags the trade queries based on various factors such as values being retrieved, type of request, etc. In one implementation, the query analysis module 118 further analyzes the tags to determine if a second trade query, requesting the retrieval of the same values, has been run within a pre-defined time interval of the trade query.
At block 206, at least one value associated with the trade query is determined.
In one implementation, the query analysis module 118 determines the values associated with

trade query and further determines the nature of the values. For example, certain values such as account balance, portfolio valuation, exchange rate of currencies may change frequently, whereas certain values such as rate of interest on investment, transactions carried out in the past do not change or change after a relatively longer period of time..
At block 208, it is determined whether the values pertaining to the trade query
are present in the cache data 126. In one implementation, the query analysis module 118 is configured to determine if the values are present in the cache data 126. For example, say an account holder requests a business transaction to be carried out. After the completion of the business transaction, the account balance is updated in the data repository 132 and is conveyed to the account holder. If the same account holder generates a request to view his last available account balance, the query analysis module 118 would determine if the account balance is already present in the cache data 126 as a trade query pertaining to account balance was executed before.
If at block 208, it is determined that the values are present in the cache data
126 (the'yes' path), as illustrated in block 210 it is further determined if the values in the cache data 126 are consistent with the values in the data repository 132. For example, the data status module 120 may be configured to maintain a status indicator to determine if the values in the cache data 126 are consistent with the corresponding values in the data repository 132. The data status module 120 may be configured to set a status indicator to indicate that the values in the cache data 126 are consistent with the corresponding values in the data repository 132 and unset the status indicator to indicate that the values in the cache data 126 are inconsistent with the corresponding values in the data repository 132.
If at block 208, it is determined that the values are not present in the cache data
126 (the 'No' path) or if at block 210 it is determined that the values in the cache data 126 are inconsistent with the corresponding values in the data repository 132 (the 'No' path), the trade query is executed to retrieve the values from the data repository 132 as illustrated in block 212.
Further, as illustrated in block 214, the values in the cache data 126 are
updated with the corresponding value in the data repository 132. Further the data status

module 120 is also configured to set the status indicator to indicate the consistently of the values in the cache data 126 and the data repository 132.
At block 216. the response to the request received is generated and conveyed
to the account holder or the support staff generating the request. Also if at block 230. it is determined that the values in the cache data 126 are consistent with the corresponding values in the data repository 132 (the 'Yes' path), the query analysis module 118 is configured to use the values in the cache data 126 to generate the response to be sent to the account holder or the support staff generating the request. This saved executing the trade query on the data repository 132, this reducing load on the data repository 132. This improves the performance of the data repository and enhances the throughput of the applications associated with the data repository 132.
Fig. 3 illustrates an exemplary method 300 for posting of transactions, in
accordance with one embodiment of the present subject matter. The exemplary method 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, and the like 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 communication 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 method is 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 alternate methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. The method described herein is with reference to the query-processing system 102; however, the method can be implemented in other similar systems albeit with a few variations as will be understood by a person skilled in the art.

At block 302, a request for a business transaction is received. For example, a
request for business transaction, such as a purchase or selling of commodities, is received. Based on the request, the business transaction is carried out.
At block 304. the business transaction along with one or more trade queries, is
stored in the data repository 132. For example, the query analysis module 118 may save the business transaction as one or more rows in one or more tables of the data repository 132 so that the business transaction may be referred to in the future.
At block 306, it is determined, if the business transaction impacts or changes
any values present in the cache data 126. As illustrated in block 308, if it is determined that the business transactions impacts or changes any values present in the cache data 126 (the 'Yes' path), the values in the cache data 126 are marked to be inconsistent with the corresponding values in the data repository at block 308. As stated before, in one implementation, the data status module 120 may reset a status indicator to indicate the same. For example, the account balance of an account holder may change due to purchase of commodities. The account balance in the data repository 132 is updated to reflect the same. If the account balance is also present in the cache data 126, the data status module 120 is configured to determine that the account balance in the cache data 126 is no more consistent with the account balance in the data repository 132.
If at block 308, it is determined if the business transactions does not impacts
or changes any values present in the cache data 126 (the 'No' path), the response to the request is generated and conveyed to the account holder or the support staff generating the request which is depicted in block 310.
Fig. 4 illustrates an exemplary method 400 for cache data 126 management, as
per one embodiment of the present subject matter. The exemplary method 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, and the like 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

communication 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 method is described is not intended to be construed as a
limitation, and any number of the described method blocks can be combined in any order ro implement the method, or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. The method described herein is with reference to the query processing system 102; however, the method can be implemented in other similar systems albeit with a few variations as will be understood by a person skilled in the art.
At block 402, the query processing system 102 is put in an offline mode. For
example, due to failure of the query processing system 102 or due to routine activity of flushing the cache data 126 at regular time interval, say at the end of the day for generation of end of day report (EOD Report), the query processing system 102 may be moved to an offline mode. In the offline mode, the query processing system 102 is not available to serving responses to trade queries generated to retrieve details pertaining to one or more accounts. In the offline mode, the cache data 126 may be flushed, or the date of the query processing system 102 may be switched to a new date, etc.
As shown in block 404, a first file, say in form of a batch file, is uploaded to
the query processing system 102 to reflect or post transactions occurring during the day. For example, the first file may run trade queries for interest calculation, generation of reports and data sets, printing of statements, payment processing, etc. As will be understood by those skilled in the art, the processing of the first file my change various parameters associated with the accounts of the account holders.
At block 406, a second file, which may also be in the form of a batch file, is
uploaded to post pending requests and queries. In one implementation the query processing system 102 receives the second file to post pending requests and queries at the end of the day. For example, the trade queries may be pending because of various reasons such as rate or receiving requests or trade queries is more than the rate at which the requests or trade queries

are processed, a trade query taking longer time to execute due to gradual increase in the size
of the data repository 132, etc. Further, if there is a third file pertaining to business
transactions which were carried out during the time for which the query processing system
(102) was offline, the same is also uploaded so as to update the data repository 132.
Furthermore, as shown in block 408, the query processing system 102 is now
brought online and activated so as to process requests received from account holders, support
staff of the financial institution. Furthermore, the cache data 126 is also updated to reflect the
changes made in the data repository 132 as a result of the processing of the files.
Although embodiments for a query processing system 102 have been described
in language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary embodiments for the query processing system 102.

I/We claim:
1. A computer implemented method for trade query processing in a trading environment, the method comprising:
identifying at least one value as a response to a trade query related to at least one account wherein the identification is based in part on an associated tag of the trade query;
determining whether the value is stored in a cache data (126); and
ascertaining whether the value stored in the cache data (126) is consistent with a corresponding value stored in a data repository (132), if the value is determined to be stored in the cache data (126); and
providing the value from the cache data (126) in response to the trade query.
2. The computer implemented method as claimed in claim 11. wherein the consistency of the value stored in a data repository (132) and the corresponding value stored in a data repository (132) is indicated by a state of a status indicator.
3. The computer implemented method as claimed in claim 11 further comprising determining a source of generation of the trade query to be one of an account holder and an executive associated with a financial institution.
4. The computer implemented method as claimed in claim 32 further comprising assigning a priority to the trade query based in part on the source of generation of the trade query.
5. The computer implemented method as claimed in claim 2 further 1 comprising:
determining a behavioral pattern associated with a source of generation of the trade query;
ascertaining if a business transaction was performed on the at least one account by the account holder based on the determination of the behavioral pattern; and
providing the value from the cache data (126) if the business transaction was ascertained to have not been performed.
6. The computer implemented method as claimed in claim 11, further comprising:
flushing the cache data (126) after a pre-defined time interval; uploading a first file comprising at least one trade query to post business transactions completed during the pre-defined time interval; and

uploading a second file comprising at least one trade query to post pending requests pertaining to business transactions.
7. A query processing system (102) for processing trade related queries, the system
(102)comprising:
a processor (108); and
a memory (112) coupled to the processor (108), the memory (112) comprising a query analysis module (118) configured to,
identify at least one value as a response to a trade query related to at least one account, wherein the identification is based in part on a tag associated with the trade query; and
determine if the at least one value is present in a cache data (126); providing the value in response to the trade query, if the value is determined to be present in the cache data (126).
8. The query processing system (102) as claimed in claim 76 further comprising a data status module (120) configured to determine consistency in the value present in the cache data (126) and a corresponding value stored in a data repository (132), wherein the corresponding value stored in a data repository (132) is an updated data based on business transactions performed on the at least one account.
9. The query processing system (102) as claimed in claim 76 further comprising a tag association module (122) configured to associate one or more tags with at least one value.
10. A computer-readable medium having embodied thereon a computer program for executing a method comprising:
identifying at least one value as a response to a trade query related to at least one account wherein the identification is based in part on an associated tag of the trade query;
determining whether the value is stored in a cache data (126); and
ascertaining whether the value stored in the cache data (126) is consistent with a corresponding value stored in a data repository (132), if the value is determined to be stored in the cache data (126); and
providing the value from the cache data (126) in response to the trade query.

11. The computer-readable medium as claimed in claim 10, wherein the method further
comprises
determining a behavioral pattern of a source of generation of the trade query;
ascertaining if a business transaction was performed on the at least one account by an account holder, based in part on the determination of the behavioral pattern; and
providing the value from the cache data (126) if the business transaction was ascertained to have not been performed.
12. The computer-readable medium as claimed in claim 10, wherein the consistency of the value stored in a data repository (132) and the corresponding value stored in a data repository (132) is indicated by a state of a status indicator.
13. The computer-readable medium as claimed in claim 10, wherein the method further comprises further comprises determining the source of generation of the trade query to be one of the account holder and an executive associated with a financial institution.