Claims:1. A transaction system, said system comprising:
a processor; and
a memory module comprising a plurality of instructions, said plurality of instructions configured to cause the processor to:
receive a transaction request by a transition gateway of the transaction system;
identify that the transaction request is to be processed by at least one legacy component and at least one new component of the transaction system; and
process the transaction request by the at least one legacy component and the at least one new component, comprising:
orchestrating processing of the transaction request between the at least one legacy component and at least one new component, by the transition gateway; and
providing compensation for each transaction being handled by the at least one legacy component and at least one new component, if required, by the transition gateway.

2. The transaction system as claimed in claim1, wherein the transition gateway is configured to identify that the transaction request is to be processed by the at least one legacy component and the at least one new component of the transaction system based on data in a reference database, further wherein the reference database possesses information pertaining to one or more components responsible for handling different transaction requests.

3. The transaction system as claimed in claim1, wherein the transition gateway is configured to orchestrate processing of the transaction request between the at least one legacy component and at least one new component by:
sending the transaction request to the at least one legacy component and the at least one new component;
interfacing between the at least one legacy component and the at least one new component during processing of the transaction request, wherein the interfacing involves transmitting data generated during the processing of the transaction request, between the at least one legacy component and the at least one new component; and
collecting and transmitting at least one response to the transaction request, from at least one of the at least one legacy component and the at least one new component.

4. A method for processing transaction requests, said method comprising:
receiving a transaction request, via one or more hardware processors, by a transition gateway of a transaction system;
identifying that the transaction request is to be processed by at least one legacy component and at least one new component of the transaction system, via one or more hardware processors, by the transition gateway; and
processing the transaction request by the at least one legacy component and at least one new component, comprising:
orchestrating processing of the transaction request between the at least one legacy component and at least one new component, by the transition gateway; and
providing compensation for each transaction being handled by the at least one legacy component and at least one new component, if required, by the transition gateway.

5. The method as claimed in claim 4, wherein identifying that the transaction request is to be processed by the at least one legacy component and the at least one new component of the transaction system further comprises:
comparing the transaction request with a reference database, wherein the reference database possesses information pertaining to one or more components responsible for handling different transaction requests;
identifying at least one match for the transaction request, in the reference database; and
identifying at least one legacy component and at least one new component to handle the transaction request, based on data in the reference database.

6. The method as claimed in claim 4, wherein orchestrating processing of the transaction request between the at least one legacy component and at least one new component comprises:
sending the transaction request to the at least one legacy component and the at least one new component, by the transition gateway;
interfacing between the at least one legacy component and at least one new component during processing of the transaction request, by the transition gateway, wherein the interfacing involves transmitting data generated during the processing of the transaction request, between the at least one legacy component and at least one new component; and
collecting and transmitting at least one response to the transaction request, from at least one of the at least one legacy component and the at least one new component.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
GATEWAY TO SUPPORT CO-EXISTENCE OF LEGACY COMPONENTS AND NEW COMPONENTS IN A FINANCIAL TRANSACTION SYSTEM

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is
to be performed.
TECHNICAL FIELD
[0001] The disclosure herein generally relate to legacy system update, and, more particularly, to co-existence of legacy components and new components in a system.

BACKGROUND
[0002] These days, automation or system support has been facilitated in most of the domains, and it has simplified our lives. Such systems are built to serve (one or more) specific requirements. However, with the requirements dynamically changing, such systems get outdated regularly (in short span of time). In order to serve new requirements, an existing system needs to be replaced with a new system, or is to be updated to serve the new needs.
[0003] The transition from an old/outdated system to a new/upgraded system can happen in different ways. Some of the existing transition approaches are phased adoption, parallel adoption, and big-bang adoption. In the phased adoption, transition happens in a phased way such that different stages/steps of the transition is being carried out in different time-slots. However, the phased adoption strategy has the disadvantage that it requires several adjustments, which in turn can lead to several mistakes. Further, with every phase being implemented, rolling back to original version, if needed, is difficult. The parallel adoption is a strategy in which both the legacy system and a new system run in parallel, and after making sure that the new system satisfies requirements/works as expected, disabling the legacy system. Disadvantage of this strategy is that running two systems in parallel requires additional human resources to handle the systems, and further increases expenses (for maintaining both systems at the same time, and in the form of wages paid to the additional people hired to handle the systems). The additional cost and any complication in terms of managing both systems together (even though for a while) can adversely affect performance of an organization where the transition is happening.
[0004] In the third approach, which is the big bang approach, switch between the legacy system and the new system happens in one shot i.e. on a given date, the legacy system is disabled and use of new system is commenced. While this is the fastest transition approach, there are certain disadvantages associated with this approach. One disadvantage is that as it is pretty much an instant changeover, the transition is to be completed within a fixed time-schedule, which is risky. Further, while migrating from one system to other in a flash, employees (whoever had been using the legacy system and who are supposed to use the new system) are prone to have certain confusions, thus affecting (though temporarily) throughput of the system.

SUMMARY
[0005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a transaction system is provided. The transaction system includes a processor; and a memory module comprising a plurality of instructions, wherein the plurality of instructions are configured to cause the processor to receive a transaction request by a transition gateway of the transaction system. The transaction system then identifies by processing the transaction request that the transaction request is to be processed by at least one legacy component and at least one new component of the transaction system, and then processes the transaction request by the at least one legacy component and at least one new component. The processing of the transaction request further includes orchestrating processing of the transaction request between the at least one legacy component and at least one new component, by the transition gateway; and providing compensation for each transaction being handled by the at least one legacy component and at least one new component, if required, by the transition gateway.
[0006] In another aspect, a method for processing transaction requests is provided. In this method, upon identifying by processing a transaction request that the transaction request is to be processed by at least one legacy component and at least one new component of the transaction system, a transition gateway facilitates processing of the transaction request by the at least one legacy component and at least one new component, wherein processing of the transaction request comprises of orchestration of processing of the transaction request between the at least one legacy component and at least one new component, by the transition gateway; and providing compensation for each transaction being handled by the at least one legacy component and at least one new component, if required, by the transition gateway.
[0007] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[0009] FIG. 1 illustrates an exemplary block diagram of a transaction system in which legacy components and new components co-exist to serve incoming transaction requirements, according to some embodiments of the present disclosure.
[0010] FIG. 2 is a functional block diagram depicting components of a transition gateway of the transaction system, according to some embodiments of the present disclosure.
[0011] FIG. 3 is a flow diagram depicting steps involved in the process of routing transaction requests to legacy components and new components of a transaction system, in accordance with some embodiments of the present disclosure.
[0012] FIG. 4 is a flow diagram depicting steps involved in the process of processing a transaction request using a combination of legacy components and new components of the transaction system, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
[0013] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[0014] Referring now to the drawings, and more particularly to FIGS. 1 through 4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[0015] In systems that manage financial transactions, most of the incoming requests are time sensitive and require dynamic processing and response. Such requests further require response in the form of acknowledgements as well. Further, when more than one system (legacy components and new components in this scenario) are together handling a transaction, their operations have to be synchronized so as to make ensure smooth processing of the requests. Further, in transaction systems, it is possible that certain transactions fail in the mid-way. In such cases, appropriate compensation measures are to be taken to ensure that appropriate correction(s) is made in the records to nullify any loss a user may encounter due to the transaction failure. The embodiments herein disclose how legacy components and new components co-exist and co-work in a system to serve financial transaction requests.
[0016] FIG. 1 illustrates an exemplary block diagram of a transaction system in which legacy components and new components co-exist to serve incoming transaction requirements, according to some embodiments of the present disclosure. The transaction system 100 includes a transition gateway 101, a legacy sub-system 102, and a new sub-system 103. The legacy sub-system 102 includes one or more legacy components, and the new sub-system 102 includes one or more new components. Components of the legacy sub-system 102 and the new sub-system 102 are configured to share functionalities of the transaction system 100.
[0017] The transition gateway 101 acts as an interface that collects any incoming transaction request to the transaction system 100. The term ‘transaction request’ can refer to a request pertaining to any service; such as but not limited to money withdrawal, money deposit, and money transfer; in a financial service environment. By processing the transaction request, the transition gateway identifies one or more components of the legacy sub-system and/or the new sub-system that are to be used to process the transaction request received. The transition gateway 101 further routes the requests to the identified component(s). In an embodiment, the transition gateway 101 identifies one or more components for processing an incoming transaction request, based on data/information stored in a reference database. If the transaction request is identified as one to be processed by one or more legacy components, then the transition gateway forwards the transaction request to identified one or more legacy components. If the transaction request is identified as to be processed by one or more new components, then the transition gateway forwards the transaction request to identified one or more new components.
[0018] In an embodiment, when a transaction request is to be processed by the legacy sub-system 102 as well as by the new sub-system 103, the transition gateway 101 sends the transaction request to identified components of the legacy sub-system 102 as well as by the new sub-system 103. Processing of the transaction request by components of both the legacy subsystem and the new subsystem mean that the request processing involves multiple stages, which are shared between the legacy and new subsystem components, with the role of the components as well as the data and control signal flow pre-defined. The transition gateway 101 is configured to orchestrate processing of the transition request between appropriate components of the legacy subsystem and the new subsystem. During the orchestration process, the transition gateway 101 acts as an interface that ensures appropriate and timely flow of data and control signals between the legacy and new subsystems.
[0019] Further, it is possible that a transaction (being done in response to a transaction request received) fails due to certain reason. In such cases, appropriate compensation measures are initiated by the transition gateway 101. For example, assume that a user is attempting to book train tickets online, and made an online money transfer for this purpose. Now, the transaction fails due to certain reason. As the user has already made the transaction, and as money has got deducted from his/her account, now appropriate compensation measures are to be executed to make sure that the money gets credited back to the user’s account. The transition gateway 101 executes appropriate compensation mechanism and compensates for the user’s loss.
[0020] The legacy sub-system 102 and the new sub-system 103 host various components of the transaction system 100, which are required to carry out one or more tasks associated with functions handled by the transaction system 100. As part of upgrading the transaction system 100, certain components are newly added and some other components are changed/replaced. Such components which are new to the transaction system 100 are being hosted by the new sub-system 103. Components of the transaction system 100 that are retained during the upgrade are hosted in the legacy sub-system 102. All components of the legacy sub-system 102 and the new sub-system 103 are assigned specific functions/responsibilities, and appropriate communication channels (with appropriate communication protocols) are provided to facilitate communication between the legacy sub-system 102 and new sub-system 103 whenever needed.
[0021] FIG. 2 is a functional block diagram depicting components of a transition gateway of the transaction system, according to some embodiments of the present disclosure. The transition gateway 100 includes an interface module 201, a request handling module 202, a memory module 203, a routing module 204, an orchestration module 205, a compensation module 206, and a processing module 207.
[0022] The interface module 201 is configured to provide one or more communication channels with appropriate communication protocols, to facilitate communication and data transfer between the transition gateway 101 and one or more external entity. Here, the term ‘external entity’ can refer to a hardware and/or a software or a combination thereof. In another embodiment, the ‘external entity’ can be a user, wherein the user is provided with an appropriate interface to interact with the transition gateway 101. The interface module 201 is further configured to support communication between components of the transition gateway, by providing appropriate communication channels. The interface module 201 is configured to collect data or control signals from external entities as input, and provide the collected input to one or more other components of the transition gateway 101 for further processing.
[0023] The request handling module 202 is configured to collect one or more transaction requests as input, and further processes the collected input to determine/identify one or more components of the legacy subsystem 102 and/or new subsystem 103 that is configured to handle the received one or more transaction requests. Further, upon identifying the component(s), the request handling module 202 forwards the transaction request to the identified component(s) for further processing, by sending a routing request to the routing module 204. In an embodiment, the request handling module 202 determines/identifies the component(s) responsible for handling each request received, based on information in a reference database in the memory module 203. Additionally, based on the type of request and/or processing time, for a request that has been identified as to be processed both by the legacy subsystem 102 and the new subsystem 103, request handling module 202 sends the request to the legacy subsystem 102 and the new subsystem 103, simultaneously or one after another in a sequential manner, as per a defined logical sequence.
[0024] The memory module 203 is configured to store all/selected data related to the transactions being handled by the transaction system 100, permanently or temporarily as configured, in a storage space. For example, the memory module 203 stores information pertaining to component(s) that is expected to handle a particular transaction request. Similarly for each type of transaction request that is to be handled by the transaction system 100, one or more components are assigned, and this information is stored in the memory module 203 as a reference database. In essence, the reference database has a mapping between different types of transaction requests, and corresponding components. In an embodiment, the memory module 203 provides suitable options and interfaces for updating contents of the reference database. The memory module 203 can utilize volatile as well as non-volatile memory spaces as per needs. The memory module 203 can be further configured to provide (restricted/unrestricted) access to data that has been stored, in response to valid data access requests received from any external entity or from one or more components of the transition gateway 101.
[0025] The routing module 204 is configured to route an incoming transaction to one or more components of the legacy sub-system 102 and/or the new sub-system 103, as per instructions received from the request handling module 202 and/or based on the nature of the financial transaction. The routing module 204 is configured to use any suitable routing protocol/method as per requirements, for the routing purpose.
[0026] The orchestration module 205 is configured to orchestrate processing of a transaction request (that is being handled by the legacy subsystem 102 and the new subsystem) between the legacy subsystem 102 and the new subsystem. When responsibility of processing of a transaction request is being shared between one or more components of the legacy subsystem 102 and the new subsystem, during the processing of the transaction request, multiple data and control signals are to be exchanged between the components, failure/delay to which can adversely affect the transaction. The orchestration module 205 is configured to handle these functions. Based on the instruction received as part of the request as well as the nature of the financial transaction the primary sub-system for processing is determined by the orchestration module 205, based on an orchestration algorithm. Additionally inputs like default processing sub-system based on source system, debit leg first for transfer transactions are used by the orchestration module 205 to determine the primary processing sub-system. Based on selection made by the orchestration module 205, based on the orchestration algorithm, the primary processing sub-system can be the legacy sub-system 102 or the new sub-system 103.
[0027] The compensation module 206 is configured to handle compensation requirements that arise while handling a transaction request. It is possible that a transaction (being done in response to a transaction request received) fails due to certain reason. In such cases, appropriate compensation measures are initiated by the compensation module 206. For example, assume that a user is attempting to book train tickets online, and made an online money transfer for this purpose. Now, the transaction fails due to certain reason. As the user has already made the transaction, and as money has got deducted from his/her account, now appropriate compensation measures are to be executed to make sure that the money gets credited back to the user’s account. The compensation module 206 executes appropriate compensation mechanism and compensates for the user’s loss. It also has a best effort processing to re attempt compensation if the first iteration for compensation was unsuccessful due to certain reason. In the scenarios of failure of multiple iterations of best effort processing the details are logged and later reported for manual intervention. Sub-system features of correction or reversal of financial transactions are used for compensation to ensure that the end customer does not see the intermittent transactions and its reversals.
[0028] The processing module 207 is configured to execute functionalities of the other components of the transition gateway, using one or more hardware processors. The processing module 207 is configured to collect instruction(s) with respect to execution of one or more steps associated with any functionality being handled by the other components of the transition gateway 101, and then execute the steps using the one or more hardware processors. It may have to translate and/or transform the messages to suit the processing sub-system determined by the request handling module 202. In various embodiments, the number and configuration of hardware processors in the processing module 207 can vary according to requirements.
[0029] FIG. 3 is a flow diagram depicting steps involved in the process of routing transaction requests to legacy components and new components of a transaction system, in accordance with some embodiments of the present disclosure. The transition gateway 101 collects (302) any incoming transaction request from any external entity connected with the transaction system 100. The transition gateway 101 then processes the received transaction request, and determines/identifies (304) one or more components of the transaction system 100 that is expected to process the transaction request that has been received. The transition gateway 101, based on data in the reference database, determines whether the transaction request is to be forwarded to the legacy subsystem 102 or the new subsystem 103 or both. If the transaction request is identified as to be handled by the legacy subsystem 102, then the transition gateway 101 routes (308) the transaction request to appropriate components of the legacy subsystem 102, and the components of the legacy subsystem 102 process (314) the transaction request. If the transaction request is identified as to be handled by the new subsystem 103, then the transition gateway 101 routes (312) the transaction request to appropriate components of the new subsystem 103, and the components of the new subsystem 103 process (318) the transaction request. If the transaction request is identified as to be handled by the legacy subsystem 102 and new subsystem 103, then the transition gateway 101 routes (310) the transaction request to appropriate components of the legacy subsystem 102 and the new subsystem 103, and the components that received the transaction request process (316) the transaction request. Various actions in Fig. 3 can be performed in the same order or in a different order. Further, or one or more of the actions in method 300 can be omitted.
[0030] FIG. 4 is a flow diagram depicting steps involved in the process of processing a transaction request using a combination of legacy components and new components of the transaction system, in accordance with some embodiments of the present disclosure. Upon identifying (402) that a transaction request received is to be processed by one or more components of the legacy subsystem 102 as well as by one or more components of the new subsystem 103, the transition gateway 101 of the transaction system 100 routes the transaction request to the identified components. Further, the transaction request is processed (404) by the legacy subsystem 102 as well as by the new subsystem 103, wherein the transaction request is processed sequentially and/or in parallel, by the legacy subsystem 102 as well as by the new subsystem 103.
[0031] When a request is being handled and processed by different components, the request processing is to be orchestrated between the components. The transition gateway 101 orchestrates (406) the processing of the transaction request between the legacy subsystem 102 and the new subsystem 103. Similarly, for any transaction that is failed during the processing stage, the transition gateway 101 provides (408) compensation, using appropriate compensation measures. Various actions in Fig. 4 can be performed in the same order or in a different order. Further, or one or more of the actions in method 400 can be omitted.
[0032] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[0033] The embodiments of present disclosure herein addresses unresolved problem of co-existence of legacy and new components as part of a system upgrade. The embodiment, thus provides a mechanism and a system in which legacy components as well as new components co-exist and manage transaction requests.
[0034] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0035] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0036] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[0037] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[0038] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.