Dynamic Software Object Transfer Engine for Financial Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing bill pay systems face constraints due to the need for interaction with multiple disparate systems during money transfers, which can be cumbersome and require system updates, leading to delays and potential downtime.
Innovation Solution
A system comprising a transaction processor, object execution engine, and data store that dynamically configures and executes transfer operations by retrieving and executing software objects, allowing for seamless interaction with various financial systems without the need for constant updates, using a transfer engine to handle requests and interface with multiple systems through pre-configured system interfaces.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If standard transfer systems (ACH or wire) are used to transfer money between systems, then the transfer can be completed with established protocols, but the system must interact with multiple disparate systems requiring frequent updates and causing downtime
Solution Approach 1:
The patent introduces a transfer engine as an intermediary component that sits between the user access system and multiple external financial systems. This transfer engine provides a standardized interface layer that handles all interactions with disparate systems (ACH, wire, Fedwire, etc.), eliminating the need for other systems to directly interface with each external system. The intermediary absorbs the complexity of multiple system interactions while providing a simple, unified interface to users.
Solution Approach 2:
The transfer engine is designed as a universal system that can handle multiple types of financial transfers (ACH, wire, Fedwire, etc.) through a single platform. Rather than requiring separate specialized systems for each transfer type, the universal transfer engine can dynamically configure and execute any transfer operation by retrieving appropriate software objects from the data store, reducing the number of discrete systems needed.
2Adaptability or versatility
If the system interacts with multiple disparate systems for money transfers, then various transfer types can be supported, but frequent system updates are required leading to delays and downtime
Solution Approach 1:
The patent segments the transfer system into three independent components: (1) the transfer engine that handles transfer logic, (2) the data store that contains software objects defining system interfaces, and (3) the user access system that receives requests. This segmentation allows the data store to be updated independently with new software objects for different transfer types without requiring updates to the transfer engine or causing system downtime. Each software object is a self-contained unit that can be added, modified, or removed independently.
Solution Approach 2:
The system employs dynamic configuration where the transfer engine retrieves software objects from the data store at runtime based on the specific transfer operation needed. Rather than having static, hard-coded connections to each external system, the system dynamically loads and configures the appropriate software object for each transfer type (ACH, wire, Fedwire, etc.), allowing the system to adapt to new transfer types without recompilation or reconfiguration of the core engine.
3Reliability
If standardized transfer systems are used, then established protocols can be followed, but the systems require frequent updates when new systems are deployed or upgraded
Solution Approach 1:
The patent uses software objects as reusable templates or copies that define the interface specifications for different external systems. Instead of creating custom integration code for each new system or protocol update, the system retrieves and instantiates appropriate software objects from the data store that already contain the standardized protocol implementations. This copying approach ensures protocol adherence while eliminating the need to modify the core transfer engine when new systems are deployed.
Data Source
AI summary
Systems and methods for providing the dynamic configuration of software agents for transfer operations are described. The apparatus may include a transaction processor to receive and execute transfer requests, an object execution engine to retrieve one or more software objects and a data store to store the one or more software objects. The method may include receiving a transfer transaction request, retrieving a software object, executing the software object, performing a transfer and terminating the software object.