METHOD, APPARATUS, AND SYSTEM FOR AUTOMATED FUNDING, INCLUDING AUTOMATED REALLOCATION OF FUNDS

Abstract

Embodiments provided herein provide methods, apparatuses, and systems for automated funding transactions. A method, apparatus, and system are provided for an automated transfer or reallocation of funds based upon a second request and/or completion of a funding transaction.

Description

The present application claims the benefit under 35 U.S.C. 119(e) of prior-filed co-pending U.S. provisional patent application 61/883,939, filed Sep. 27, 2013, the disclosure of which is hereby incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to the fields of automated funding and, more particularly, automatic funding an expense payment infrastructure in response to a request, wherein the automatic funding may comprise automated reallocation of funds.

2. Description of the Related Art

There have been many advancements in the area of financial transactions. Often, organizations such as corporations rely on employees or agents to act on their behalf performing various tasks in the interest of the organization. When performing these tasks, the employees or agents may incur expenses. In some cases, state of the art methods for providing funding for such expenses include having the employee or agent incur the cost themselves, and then reimbursing that amount to the employee or agent. Other state of the art methods include providing funding prior to the performance of a task or travel on behalf of the organization, and having an employee, or agent, utilize the provided funds for expenses. These methods can be inaccurate and cumbersome, reducing efficiency.

Some organizations have attempted to make the funding process more efficient. For example, some organizations attempt to increase efficiency by providing for receiving a request for funding and then having the request manually studied and approved, after which such requested funding is possibly granted. However, this process can be slow and cumbersome, and thus problems may result, e.g., the proper funding may not arrive in time. Generally, state of the art processes for funding lacks efficiency and accuracy. For example, it may be difficult to obtain proper funding without accurately knowing the amount of expenses that may be incurred. Further, there may be a delay in receiving approval for funding, which may further interfere in efficient execution of various tasks and/or travel performed by an employee or agent.

In addition, there may be situations in which a first request for funds cannot be satisfied, even if funds are available, if the available funds are earmarked for another user or payment infrastructure.

Therefore, it would be desirable to have methods, systems, and apparatus for automated funding transactions.

Further, it would be desirable to have methods, systems, and apparatus for automated reallocation of funds.

SUMMARY OF EMBODIMENTS

In one embodiment, the present disclosure provides methods, apparatus, and systems for a method for providing an automated transfer of funds. Data relating to an unused amount account associated with a first payment mechanism is received. A determination is made as to whether a user of the first payment mechanism has a pending request for funding. A determination is made as to whether a user of a second payment mechanism has a pending request for funding. At least a portion of the unused amount is transferred from the account associated with the first payment mechanism to an account associated with a second payment mechanism in response to determining that the user of the second payment mechanism has a pending request for funding. Transferring at least a portion of the unused amount from the account associated with the first payment mechanism to a master account in response to determining that the user of the second payment mechanism does not have a pending request for funding.

BRIEF DESCRIPTION OF THE FIGURES

The following drawings form part of the present specification and are included to further demonstrate certain aspects of the present invention. The invention may be better understood by reference to one or more of these drawings, wherein like reference numerals denote like elements, in combination with the detailed description of specific embodiments presented herein.

FIG. 1 depicts a system for automated finding of transactions, according to some embodiments of the present disclosure.

FIG. 2 depicts a portion of the system of FIG. 1, according to some embodiments of the present disclosure.

FIG. 3 depicts the communications interface shown in FIG. 2, according to some embodiments of the present disclosure.

FIG. 4 depicts the program manager shown in FIG. 2, according to some embodiments of the present disclosure.

FIG. 5 depicts the user entity shown in FIG. 2, according to some embodiments of the present disclosure.

FIG. 6 provides a flowchart of a method of automated funding a transaction, according to some embodiments of the present invention.

FIG. 7 provides a flowchart of a method of automated reallocation of funds, according to some embodiments of the present invention.

FIG. 8 provides a flowchart of a method of requesting and approving funding of a transaction, including automated reallocation of funds, according to some embodiments of the present invention.

While the disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. The description herein of specific embodiments is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure as defined by the appended claims.

DETAILED DESCRIPTION

Illustrative embodiments of the disclosure are described herein. For clarity, not all features of an actual implementation are described. In the development of any actual embodiment, numerous implementation-specific decisions must be made to achieve design-specific goals, which will vary from one implementation to another. Such a development effort, while possibly complex and time-consuming, would nevertheless be a routine undertaking for persons of ordinary skill in the art having the benefit of this disclosure.

Embodiments herein provide for using remote devices (e.g., mobile phones such as smartphones, computers such as laptop computers tablet computers, desktop computers, etc.), as well as modules (e.g., software modules, hardware modules, firmware modules, etc) or applications (e.g., proprietary mobile application technology) to automatically and proactively manage the approval or rejection and distribution of funds within the workflow of an organization, such as a corporation. The workflow may refer to method associated with allocating funds for use by employees for spending required for the business. This automatic management of funds allocation based on pre-established rules set by the end users may be part of the broader communication component of the end to end expense management and reporting process automated by the integrated solution.

Embodiments herein provide for performing a funds reallocation process that includes detecting unused funds, timed-out funds, non-allocated funds, misallocated funds, etc., and redistributing such funds to users making valid and approved requests, or to a master balance account. This process may be made automatically on a periodic basis, when a funds request is detected, or when an instruction to perform a reallocation process is received.

The solutions provided by embodiments herein may address the challenge of automating the process of controls necessary for organizations to distribute funds to employees in the field without having to generate paper forms and manually move the forms between resources. The solutions provided by embodiments herein may also use automation to automatically monitor and apply funds to payment mechanisms (e.g., a debit card, a pre-paid card, a credit card, an electronic payment device; a payment application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer, etc.) based on predetermined rules.

Though the term “card” is used herein for convenience, and is exemplified by credit cards, debit cards, and other payment cards, the person of ordinary skill in the art will recognize that “card” is often used herein in the more generic sense of a “payment mechanism.” Examples of payment mechanisms that are not “cards” in the strict sense may include, but are not limited to, electronic payment devices; payment applications capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer; etc.

Some embodiments herein provide for organizations (e.g., corporations) quickly and easily transfer company funds to and from employees in a real time or a near real time basis using a linked system of pre-paid debit cards or other payment mechanisms, such as credit cards, less payment devices, mobile phone payment modules or applications, etc. The component of automatic request and approval may be managed through a proprietary module, which may be standalone, intranet, Internet, and/or and mobile application based. The module may be a software module, a hardware module, a firmware module, or a combination thereof. Operation of the system may be facilitated by a graphical interface (GUI) that may provide interaction between the system and a user or a program manager via various avenues, such as a remote computer (e.g., a laptop) or a mobile device, such as a cellular phone.

In some embodiments, remote devices (e.g., mobile phones such as smartphones, computers such as laptop computers tablet computers, desktop computers, etc.), as well as modules (e.g., software modules, hardware modules, firmware modules, etc.) or applications (e.g., proprietary mobile application technology) to automatically and proactively send communications (e.g., notifications) regarding the need for, approval or rejection, reallocation, and distribution of funds within a workflow of an organization, such as a corporation. The notifications may be made via a variety of mediums, such as text messaging, email messages, social network venues, chat applications, paging applications, and/or the like.

In one embodiment, predetermined rules may be implemented to control the operation of notifications for request, approval, denial, modification requests, funds reallocation regarding allocating funds for use by employees for spending required for the business. This communication may be part of the broader communication component of the end to end expense management and reporting process automated by the integrated solution. In some embodiments, based on a trigger threshold or event detected by a funding system (e.g., a proprietary solution), funds may be redistributed and/or loaded onto a payment mechanism (e.g., debit card, pre-paid card, credit card, etc.) based upon predetermined rules established by the end user, account manager and/or other designated individual(s). The trigger event may be one of several events, such as a completion of a business trip, depletion of funds below a predetermined threshold in an account, a notice from a user, a filing of an expense report, a time threshold, and/or the like. In some embodiments, the triggering event may prompt a reallocation process described herein, wherein the reallocation process may redirect unused or misallocated funds to satisfy a triggered fund allocation and distribution process.

Embodiments provided herein may be applicable to a variety of contexts, such as corporation, organizations within a corporation, employee expense advances, third party funding (e.g., short-term loans, cash-advance operations, pay-check advance loans, title-advance loans, tax-refund loans, etc.). The funds provided by embodiments herein may include various forms of funding, including cash checks, pre-paid cards, credit cards, electronic payment devices or systems, and/or the like.

In some embodiments, a funding system may provide for reallocating funds from one account to another in an automated fashion. For example, if funds have been requested and approved for use by an employee or agent, upon a predetermined time frame or event, remaining or unused funds may be transferred back to a master account, or to another user account. Exemplary steps to perform this process may include: detecting unused amount for a first user; determining whether there are any other pending request for a second user; determining if the requested funding has been approved; moving unused amount from the first user's account to the second user's account based upon predetermined criterion. Alternatively, the unused amount may be transferred to a Master Balance Account. In alternative embodiments, the manager may set a maximum finding limit, and the funding system may automatically look for amount from other users that can be transferred to a requesting user.

Turning to FIG. 1, an overview of the system is shown. A card issuing entity 120 (e.g., a bank) may, under the direction of a card originator 110, send funds to a card processor 130. The card processor 120 may then provide funds to pay for desired transactions. The card issuing entity 120 may be a member of the card originator 110. The card originator 110 and the card issuing entity 120 may enter into an agreement with the program manager 140 for providing a business model to market and distribute various transaction mechanisms, such as the debit cards and credit cards. The program manager 140 may enter into an agreement with the card processor 130, wherein the agreement may be approved by the card issuing entity 120. This agreement may comprise provisions for interfacing with payment networks described herein for accounting of transactions performed using transaction mechanisms, authorization and settlement of accounts, etc.

A program manager 140 may facilitate interactions between the card issuing entity 120, card processor 130, and/or card originator 110, on the one hand, and a user entity 150 on the other. One example of a program manager 140 is Insperity, Inc. Particular components of the program manager 140 will be described in more detail below.

The user entity 150 may be any organization which desires to automatically fund employee transactions. For example, the user entity 150 may be a corporation, an LLC, a partnership, a sole proprietorship, or other business entity; an agency of a national, state/provincial, county/parish, or city/town government; a college or university, or another not-for-profit entity; among others. The user entity 150 may be any organization that utilizes the automated transaction request and approval provided by the system 100. For example, the user entity 150 may be a corporation that signs on with the program manager 140 to manage the automated request and transaction provided by the system 100. The program manager 140 may provide an infrastructure for members of the user entity 150 to request funding for an expense and receive automated approval, in some embodiments, in real time or near real time. In some embodiments, the approval may be provided manually and in other embodiments, the approval may be provided automatically. The approval may be provided automatically based upon rules-based, threshold-based, and/or event-based scenarios.

The user entity 150 may comprise an administrator 154 and at least one card holder unit 152. The administrator 154 may be the component of the user entity 150 that allocates funds, sets authorization rules, monitors employee transactions, etc., as will be discussed in more detail elsewhere.

The administrator 154 may exercise various controls over the operation of the card program, which includes evaluating a funding request, providing approvals for the requests, prompting modification of the requests, providing funding responsive to the requests, scheduling a transfer of funds, managing expense cards, managing groups that may use one or more expense cards, withdrawing or pulling back funds from previously allowed expense funding, etc. The administrator 154 may perform the function of various administrative tasks over an individual user or a group of users. In alternative embodiments, a separate group administrator may provide for performing various administration functions for controlling the group expense activities.

In some embodiments, the user entity 150 may also comprise a group manager. The group manager may be part of the administrator 154, or in alternative embodiments may be a separate entity. In some embodiments, the group manager may be limited to the tasks of managing cards, approval or denial of expense requests, status views, report generation, etc. In some embodiments, the group manager may be restricted to controlling the operation of approvals, etc. within one or more groups that is managed by the group manager. Alternatively, the functions of the group manager may be encompassed by the administrator 154. The duties of the administrator 154 may be performed manually and/or automatically using software, hardware, and/or firmware modules that may he programmed to implement rules-based, threshold-based, and/or event-based protocols.

The card holder unit 152 may be any employee or other component of the user entity 150 for which it is desirable to allow access to business funds for the payment of business expenses.

In order to deploy the system described in FIG. 1, a set-up and configuration process may be performed. For example, the configuration and set-up process may include confirming and/or creating a payment method for one or more expense cards. In some embodiments, a group may be created, wherein a plurality of expense cards may be funded. from a single account or a group of accounts that are controlled by a single entity, e.g., a group administrator. Further, the payment method may be associated with a financial institution such as the card issuing entity 120. An expense card management role may be assigned to an expense card administrator, such as the administrator 154. Further, an expense card group manager role may be assigned to managers of the user entity 150. The group manager may be able to approve and manage the expense card groups. The expense card groups may include one or more card holder units 152. The expense card group manager may be an automated entity and may be comprised of software or hardware module that is capable of receiving requests, demanding modifications to the requests, providing approval of funds requests, and/or prompting funding of an expense card upon approval of a funding request.

In an alternative embodiment, once expense card groups are created, a card holder role may be assigned to a card holder unit 152, e.g., an employee of a corporation. The employee may be issued an expense card and further, the employee may be assigned to a particular expense card group. Funds may then be transferred to the expense cards in the group and an automated request and approval process may be facilitated by the program manager 140 and the user entity 150. The administrator 154 may provide for a graphical user interface (GUI) for performing the set up described above.

FIG. 2 depicts in more detail interactions between the program manager 140 and components of the user entity 150. In addition to the administrator 154 and the card holder unit 152 described above, the user entity 150 may comprise a communications interface 156. The communications interface 156 may allow communication between the user entity 150 and the program manager 140. Alternatively or in addition, the communications interface 156 may also communication, via a communications network 220, to a remote unit 210.

FIG. 3 depicts in more detail the communications interface 156. The communications interface 156 may comprise one or more hardware devices and/or software products allowing communication between the various elements shown in FIG. 2.

For example, the communications interface 156 may comprise a mobile device interface 310. The mobile device interface 310 may comprise a software product configured to operate on a particular mobile device, a website optimized for operation on the mobile device, etc.

Alternatively or in addition, the communications interface 156 may comprise a cloud computing interface 320. The cloud computing interface 320 may comprise a software product configured to allow access, such as secure access, to a cloud computing infrastructure, etc.

Alternatively or in addition, the communications interface 156 may comprise an internet interface 330. The internet interface 330 may comprise a software product configured to allow access, such as secure access, via the internet to an automated funding infrastructure, a website configured to allow access, such as secure access, via the internet to the automated funding infrastructure, etc.

Alternatively or in addition, the communications interface 156 may comprise a program manager interface 340. The program manager interface 340 may comprise a software product configured to allow an administrator access, such as secure access, via any communications modality to administrator-specific component of an automated funding infrastructure, a website configured to allow an administrator access, such as secure access, via the internet or an intranet to the administrator-specific component of the automated funding infrastructure, etc.

Alternatively or in addition, the communications interface 156 may comprise an intranet interface 350. The intranet interface 350 may comprise a software product configured to allow access, such as secure access, via an intranet to an automated funding infrastructure, a website configured to allow access, such as secure access, via an intranet to the automated funding infrastructure, etc.

Alternatively or in addition, the communications interface 156 may comprise a wireless interface 360. The wireless interface 360 may comprise a WiFi network, a Bluetooth-accessible gateway, or the like.

Alternatively or in addition, the communications interface 156 may comprise a wired interface 370. The wired interface 370 may comprise an Ethernet component, a USB component, or the like.

Turning back to FIG. 2, the communications network 220 may be one or more public, semi-public, or private infrastructures capable of transferring data therethrough. For example, the communications network 220 may comprise one or more of interact, intranet, a virtual private network (VPN), a cellular network, a radio network, a cloud computing network, or the like.

The remote unit 210 may be any device usable by a remote employee of the user entity 150, such as a remote employee of card holder unit 152, to send and/or receive communications from user entity 154 relating to transactions which the remote employee may desire to conduct using business funds. The remote unit 210 may comprise a remote desktop computer, a remote laptop computer, a tablet computer, a smartphone, or the like.

As mentioned, FIGS. 1-2 also depict a program manager 140. FIG. 4 depicts the program manager 140 in more detail.

The program manager 140 may comprise a payment set-up unit 410. The payment set-up unit 410 may be configured to request and receive payments from user entity 150 into a fund pool from which funds for particular card holder units and/or particular users therein may be allocated, de-allocated, or re-allocated. The payment set-up unit 410 may be configured to setup an infrastructure for funding an expense card. The method of payment, for example, may be set-up by the payment set-up unit 410. The payment set-up unit 410 is capable of receiving predetermined rules from the card processor 130, the card issuing unit 120, and/or the user entity 150. These rules may be dynamically modified. The payment method may include mechanisms for electronically transferring funds from a predetermined account to an expense card, and/or to a group account, which in turn may provide funding to expense cards associated with the group. In some embodiments, a graphical user interface (GUI) may be set up to allow for an administrator to log in and set-up a payment system. One example of GUI for setting up a payment method is exemplified in Appendix A. The exemplary GUI illustrated in Appendix A is provided for exemplary purposes, and those skilled in the art having benefit of the present disclosure may implement various other interfaces and remain within the spirit and scope of the present invention.

The program manager 140 may comprise an institution association unit 420. The institution association unit 420 may be configured to associate one or more set-up, management, and/or day-to-day funding transaction requests relating to a particular user entity 150 with that user entity 150. This may enhance the ability of the program manager 140 to sequester a first user entity's funds and records from access by a second user entity and vice versa. Alternatively or in addition, the institution association unit 420 may be configured to associate a user with at least one institution, e.g., at least one user entity 150. A particular expense card may be classified as a particular type of card, such as a corporate expense card for example, and may be associated with a particular financial entity, such as the card issuing entity 120. The institution association unit 420 may be associated with one or more graphical user interface screen that may allow for an administrator to set-up an association for a particular expense card with a particular financial institution, One example of a GUI that may be used by the institution association unit 420 is provided in Appendix B.

The program manager 140 may comprise a card assignment unit 430. The card assignment unit 430 may fulfill a request by user entity 150 for one or more new cards to be provided to card holder unit 152. In other words, the card assignment unit 430 may be capable of assigning a payment mechanism to a user. A particular user may be assigned an expense card wherein various limitations and rules may be set-up for usage of the expense card. An Administrator may set-up the assignment of an expense card to a particular user. The card assignment unit 430 is capable of providing information regarding the card user to the administrator or a card group, and is capable of correlating an expense card to the user-profile of the user. One example of a GUI utilized for assigning an expense card to a user is exemplified in Appendix C.

The program manager 140 may comprise a group management unit 440. The group management unit 440 may create and manage a card group, e.g., a card holder unit 152. Management of a card holder unit 152 may comprise adding authorized users, removing unauthorized users, combining two or card holder units 152, dividing a card holder unit 152 into two or more successor units, or the like. An expense card group may be used to combine various card holders into a predetermined group; wherein rules may be set-up to control the operation of automated expense approvals for the group. For example, one division of a corporation may be selected for using expense cards. A subset of employees of that division may be assigned individual expense cards, wherein a set of rules may be used to provide guidance for usage of the expense cards. These rules may include limitations regarding maximum expenses, prior approvals being required for expenses, and/or automated approvals of expenses, among other. For example, particular rules may be set-up for providing a maximum amount that may be transferred to a particular card holder's expense account. The maximum amount be a function of a limit on allowable expenses by a user per unit of time (e.g., per day) and/or a function of the maximum amount of funding that is available to that particular group. The group management unit may utilize a GUI for allowing an administrator to set-up groups, and/or set up a group manager fur controlling expense accounting of the group. Appendix D illustrates an exemplary GUI that may be utilized for creating and/or managing a card group. The group management unit 440 may also allow for adding or deleting individuals from a particular expense group.

Alternatively or in addition, the group management unit 440 may perform at least one of approving a user request or prompting the user to modify the request.

The program manager 140 may comprise a user interface unit 450. The user interface unit 450 may provide the administrator 154 or another authorized person or persons of user entity 150 access to one or more components implemented by one or more of the various other units of program manager 140. Such access may comprise the ability to send a request to one or more of the various other units of program manager 140, the ability to modify the operations of one or more of the various other units of program manager 140 as those operations may relate to the particular user entity 150, particular card holder units 152, particular users, and/or the administrator 154 of a user entity 150.

Alternatively or in addition, the user interface unit 450 may provide a user, such as a member of a cardholder unit 152, access to the system to request funding for a particular transaction.

The program manager 140 may comprise a funding unit 460. The funding unit 460 may receive requests to fund one or more transactions, to allocate, de-allocate, or reallocate funds to one or more card holder units 152 and/or one or more users of the card holder unit(s) 152, or the like; may approve, deny, or request more information relating to such requests; and may disburse funds relating to one or more approved requests. In other words, the funding unit 460 may control at least one aspect of the funding of a request.

The program manager 140 may comprise a database unit 470. The database unit 470 may be configured to receive, store, organize, report, and provide access to information relating to one or more of the user entity 150, one or more card holder units 152, one or more users of the card holder unit(s) 152, one or more transactions involving a user, information relating to available funding, rules for funding, or other data of interest to the administrator 154 and/or the program manager 140.

The program manager 140 may comprise a program manager interface 480. The program manager interface 450 may provide an authorized person or persons of program manager 140 accesses to one or more components implemented by one or more of the various other units of program manager 140. Such access may comprise the ability to send a request to one or more of the various other units of program manager 140, the ability to modify the operations of one or more of the various other units of program manager 140 as those operations may relate to the particular user entity 150, particular card holder units 152, particular users, and/or the administrator 154 of a user entity 150, and/or one or more persons or other elements of program manager 140.

Alternatively or in addition, the program manager interface 480 may comprise an interface at least with the user entity 150 and/or the communications network 220.

As should be apparent, access granted to administrator 154 of user entity 150 via user interface unit 450 may be different from access granted to an authorized person or persons of program manager 140 via program manager interface 480. For example, it may be desirable for the administrator 154 to have access to the funding unit 460 in order to provide funds for future use and/or to allocate, de-allocate, or reallocate funds to one or more users of one or more card holder units 152, and to be denied access to card assignment unit 430 in order to prevent possible mis-assignment of a card to an unauthorized user. On the other hand, it may be desirable for an authorized person of program manager 140 to have access to institution association unit 420 to ensure proper management of a user entity 150's private data, and to be denied access to funding unit 460 to prevent possible misallocation of funds.

Turning to FIG. 5, a block diagram of the user entity 150 is depicted. In the depicted embodiment, the user entity 150 is shown as comprising two card holder units 152a, 152b. As should be apparent, the user entity 150 may comprise any number of card holder units 152. The precise number of card holder units 152 may be selected as a matter of routine experimentation by the person of ordinary skill in the art.

A card holder unit 152a, 152b may comprise a request unit 510a, 510b. A request unit 510 may be configured to request funding of a transaction by a user of the card holder unit 152. The request for funding may be routed from request unit 510 to approval unit 520.

The approval unit 520 may be configured to provide at least one of an approval or denial of the request. For example, the approval unit 520 may process the request in one or more ways. The approval unit 520 may communicate with an approval protocol module 530. The communication may comprise one or more of an identification of the cardholder unit 152, the request unit 510, and/or the user from which the request originated; the amount of the requested funding; the type of vendor and/or the name of the vendor to be paid in the transaction; or the like.

The approval protocol module 530 may also receive information from the administrator 154, e.g., with an accounting unit 540 thereof. Such information may relate to a total amount of funds available and/or allocated to the user entity 150, to the cardholder unit 152, and/or to the user. Alternatively or in addition, such information may relate to a per-day, per-week, and/or per-month allocation of funds to the user entity 150, to the cardholder unit 152, and/or to the user.

Alternatively or in addition, the approval unit 520 may request such information from the administrator 154, e.g., with an accounting unit 540 thereof, and may relay such information to approval protocol module 530.

Upon receipt of all desired information, the approval protocol module 530 may then approve the request for funds, reject the request for funds, or request more information in order to approve or reject. The approval protocol module 530 may provide at least one protocol for performing the approval or denial. In some embodiments, the approval protocol module 530 may provide a plurality of protocols by which approvals and denials may be performed. Which of a plurality of protocols may be used in a given circumstance may depend on one or more of the user, the cardholder unit 152, the amount of funds available in a master account, the amount of funds allocated to the user and/or the cardholder unit 152, the type and/or amount of an intended transaction, etc.

In certain circumstances, funds required or desired to fund a transaction may not be allocated to a particular cardholder unit (e.g., 152a) or user thereof, though unused or excess funds may have been previously allocated to another cardholder unit (e.g., 152b). In some examples, funds allocated to the 1^st cardholder unit 152a may have not been used by a predetermined time period, thereby expiring. In other embodiments, funds allocated to the 1^st cardholder unit 152a may have been for an approved activity that is no longer approved. In these circumstances, the administrator 154, e.g., the accounting unit 540 thereof may request the transfer and/or reallocation of funds by communicating the request to a funds transfer unit 550. In other embodiments, funds may be reallocated in response to detecting a request for funds. In this case, a reallocation process may be initiated by a triggering event that triggered an approval action to satisfy a request for funds. For example, if the approval unit 520 determines that a request for funds has been approved, the approval unit 520 may prompt a reallocation unit 560 to initiate a reallocation process to assist in satisfying the request. Prior to providing funding from a master account, the approval unit 530 and/or the fund transfer unit 550 may allow the reallocation unit 560 to find unused/unallocated funds. If sufficient funds are not found by the reallocation unit 560, the shortage may then be provided by the fund transfer unit 550 to the user's account.

The funds transfer unit 550 may provide a transfer of funds to a payment mechanism. Such funds may be previously allocated to the payment mechanism, the user, and/or the cardholder unit making the request (e.g., 152a).

In some embodiments, wherein available funds may be provided by transfer from an outside entity (e.g., an operating account of user entity 150), the funds transfer unit 550 may transfer and allocate funds to the cardholder unit making the request (e.g., 152a).

Alternatively or in addition, the funds transfer unit 550 may relay a request for reallocation to reallocation unit 560. The reallocation unit 560 may then determine whether available funds allocated to e.g. cardholder unit 152b are unused or excess and may be reallocated to e.g. cardholder unit 152a.

Upon approval or rejection of a request for funds by a user of a cardholder unit 152, the approval or rejection may be relayed via communications interface 156 and communications network 220 to the user, and relevant information relating to the approval or rejection may be relayed via communications interface 156 and communications network 220 to the program manager 140. For example, an approval may be relayed to the program manager 140 in order for the program manager 140 to authorize the transaction.

Alternatively or in addition, in some embodiments, the reallocation unit 560 may perform reallocation in the absence of a funds request. The reallocation unit 560 may periodically monitor funds allocated to each cardholder unit 152 and/or user thereof, such as on a daily, weekly, or monthly basis, and reallocate funds based on one or more parameters. Alternatively or in addition, the reallocation unit 560 may receive requests from an administrator 154 to reallocate funds based on non-periodic factors, e.g., an expectation that one cardholder unit 152 and/or one or more users thereof will have an unusually high or low need for funds in an upcoming period (e.g., if user(s) of a cardholder unit 152 normally working from a main office of the user entity 150 will be engaging in travel, funds may be reallocated such that these user(s) and this cardholder unit 152 will receive more during the period of travel).

Alternatively or in addition, the reallocation unit 560 may de-allocate funds from a cardholder unit 152 by transferring funds to a master balance account (not shown). This de-allocation process may be based on one or more factors, such as completion of the activity for which the previous funding was provided, suspension of the activity for which the previous funding was provided, cancelation of the activity for which the previous funding was provided, a request by the user or another entity to cancel the previous funding, etc.

FIG. 6 provides a flowchart of a method 600 of providing funds to the systems of FIGS. 1-5, according to some embodiments of the present disclosure. A client (e.g., user entity 150) operating account may be interfaced with (block 610) and funds sent to the operating account, such as by ACH, direct deposit, etc. (block 620).

With funds available in the operating account, a card issuing entity 120 (e.g., a bank) may be prompted (block 630) to send funds to a card processor 130 under the direction of a card originator 110. The card processor 130 may then credit (block 640) a virtual card account, such as a client master account. Upon crediting of the virtual card account, automatic (e.g., real-time) transfer of funds to and from user cards may be allowed (block 650).

FIG. 7 provides a flowchart of a method 700 of reallocating funds between cardholder units 152, according to some embodiments of the present disclosure. In the depicted method, a reallocation processes may be initiated or triggered (block 705). The triggering of the reallocation process may be made automatically on a periodic basis, when a funds request is detected, or when an instruction to perform a reallocation process is received. Upon triggering the reallocation process, an unused or an unusable amount for a first cardholder unit (e.g., 152a) may be detected (block 710). The unused amount may be an amount that is in surplus with respect to a requested funding after the funding activity was concluded, a failure to use the remaining amount, a cancellation of the activity for which the funding was allocated, or the like, etc. The unusable amount may be an amount that cannot be used by the cardholder due to a variety of reasons, such as cancelation of a project, withdrawal of funding approval, policy changes, budget changes, etc.

Upon detecting an unused or unusable amount, a determination may be made (block 720) regarding a pending fund request from a second cardholder unit e.g., 152b). If the second cardholder unit does indeed have a pending fund request, and if that request is approved (as determined at block 730), then the unused amount for the first cardholder unit may be transferred (block 740) to the second cardholder unit. On the other hand, if the second cardholder unit does indeed have a pending fund request, but that request is denied (also determined at block 730), then the unused amount for the first cardholder unit may be transferred (block 750) to the master balance account, or alternatively, may be used to satisfy yet another approved fund request.

Also, if the determination (block 720) is that the second cardholder unit has no pending fund request, then the unused amount for the first cardholder unit may also be transferred (block 750) to the master balance account or alternatively, may be used to satisfy another approved fund request. After the excess amount is transferred (either to another cardholder or the master balance account), the reallocation process may be concluded or temporarily terminated until another reallocation process is initiated or triggered (block 760).

FIG. 8 provides a flowchart of a method 800 of a funding request and approval/rejection process, with reallocation of unused funds, according to some embodiments of the present disclosure. A funds request from a user may be received (block 810). The request may come one or more of a variety of sources, such as an user who's given an account, another person who's authorized for making the request on behalf of the user, an automated module that may be programmed to generate a request based upon a project requirement or schedule, and/or the like. The request may then be processed (block 820). Processing the request (block 820) may comprise one or more of reviewing the request, approving the request, modifying the request, or instructing the user to modify the request, etc. In some embodiments, the request may be reviewed, approved, or tagged for modification by an automated system that may compare various parameters for performing such tasks. These parameters may include a check to determine: whether the user is authorized to make the request; whether the requested amount is within predetermined specifications in light of one or more details of the request; whether there are sufficient funds to satisfy the request, whether the request contains sufficient parameters to process the request, and/or the like.

As noted above, request processing step may also include a modification request that is sent back to the user initiating the funds request. For example, an administrator may require that the initial funds request is modified to reduce the requested amount, further explain the justification for the request, and/or provide further information regarding the request. Moreover, the request processing step may include providing an approval of the funding request. A graphical user interface example of approving funds based upon a request or a plurality of requests is provided in Appendix E. In some embodiments, the history of funds request approvals may be displayed and viewed by an administrator, as illustrated in Appendix E. Those skilled in the art would appreciate that other GUI may be provided to perform the approval of funds requests.

After the request is processed (block 820), and if the request is approved, whether the request can be funded by reallocation of unused or under-utilized funds from another user (e.g., cardholder unit 152 or user thereof) may be determined (block 830). In some embodiments, a reallocation process may be initiated at this point. Upon performing the reallocation process, another determination may be made as to whether the request can be funded by reallocation of other funds. If the determination (block 830) is that the request can be funded by reallocation from another user, then the unused funds may be transferred (block 840) to the user making the funds request via reallocation. On the other hand, if the determination (block 830) is that the request cannot be funded by reallocation from another user, then the funds flow process of FIG. 6 may be used (block 850) to fund the user's card or otherwise fulfill the funds request.

Regardless of the origin of the funds provided to the user at 840-850, a determination may be made (block 860) if the user has made any further request(s) for additional funds or has modified the original request such as by increasing the requested amount of funds). If the determination (block 860) is that the user has made a further request or modified the original Request, then the further/modified original request is subjected to processing (block 820) and subsequent operations.

If the determination (block 860) finds the user made no further request(s) and did not modify the original request, then the transaction may be logged (block 870), such as by entering the transaction into database 470 of program manager 140, and the funding process may be ended.

The methods depicted in FIGS. 6-8 and/or described elsewhere herein may be governed by instructions that are stored in a non-transitory computer readable storage medium and that are executed by, e.g., one or more components of the program manager 140. Each of the operations shown in FIGS. 6-8 and/or described elsewhere herein may correspond to instructions stored in a non-transitory computer memory or computer readable storage medium. In various embodiments, the non-transitory computer readable storage medium may include a magnetic or optical disk storage device, solid state storage devices such as flash memory, or other non-volatile memory device or devices. The computer readable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted and/or executable by one or more processors.

Turning now to various embodiments, in one embodiment, the present disclosure relates to a method for providing an automated transfer of funds, comprising receiving data relating to an unused amount in an account associated with a first payment mechanism; determining if a user of the first payment mechanism has a pending request for funding; determining is a user of a second payment mechanism has a pending request for funding; transferring at least a portion of the unused amount from the account associated with the first payment mechanism to an account associated with a second payment mechanism in response to determining that the user of the second payment mechanism has a pending request for funding; and transferring at least a portion of the unused amount from the account associated with the first payment mechanism to a master account in response to determining that the user of the second payment mechanism does not have a pending request for funding.

In one embodiment, the present disclosure relates to a non-transitory computer readable program storage unit encoded with instructions that, when executed by a computer, perform a method for providing an automated transfer of funds, as described above.

In one embodiment, the present disclosure relates to an apparatus for providing an automated transfer of funds, comprising a reallocation unit, wherein the reallocation unit is configured to receive data relating to an unused amount in an account associated with a first payment mechanism; determine if a user of the first payment mechanism has a pending request for funding; determine is a user of a second payment mechanism has a pending request for funding; transfer at least a portion of the unused amount from the account associated with the first payment mechanism to an account associated with a second payment mechanism in response to determining that the user of the second payment mechanism has a pending request for funding; and transfer at least a portion of the unused amount from the account associated with the first payment mechanism to a master account in response to determining that the user of the second payment mechanism does not have a pending request for funding.

In one embodiment, the present disclosure relates to a system for performing a transaction, the system comprising a card originator for providing a payment mechanism; a card issuing entity in communication with the card originator, wherein the card issuing entity is configured for providing funding for the payment mechanism; a program manager in communication with the card issuing entity, the program manager configure for managing at least one funding operation of the system; a card processor in communication with the program manager the card processor configured for processing a transaction of the payment mechanism; a remote unit in communication with the program manager, the remote unit comprising a request unit for providing a funding request; and a reallocation unit configured to receive data relating to an unused amount in an account associated with a first payment mechanism; determine if a user of the first payment mechanism has a pending request for funding; determine is a user of a second payment mechanism has a pending request for funding; transfer at least a portion of the unused amount from the account associated with the first payment mechanism to an account associated with a second payment mechanism in response to determining that the user of the second payment mechanism has a pending request for funding; and transfer at least a portion of the unused amount from the account associated with the first payment mechanism to a master account in response to determining that the user of the second payment mechanism does not have a pending request for funding.

In the system, in one embodiment, the card issuing entity may be a bank. In other embodiments, the card issuing entity may be other institutions permitted to issue cards under the laws of a jurisdiction of interest.

In one embodiment of the system, the user entity may comprise a communications interface for providing for communications between the remote unit and at least one of the user entity or the program manager; a card holder unit comprising a second request unit for providing the funding request; and an administrator for administrating the funds request and the funding.

In one embodiment, the communications interface may comprise at least one of a mobile device interface; a cloud computing interface; an Internet interface; a program manager interface; an Intranet interface; a wireless interface; or a wired interface.

In one embodiment, the program manager may comprise a payment set-up unit for setting up a funding payment; an institution association unit associating a user with at least one institution; a card assignment unit capable of assigning a payment mechanism to the user; a group management unit to perform at least one of an approval, a prompt for modifying the request; a user interface unit for interfacing with at least one user; a funding unit to control at least one aspect of the funding; a database comprising at least one of rules fur funding; information of a user; or information relating to available funding; and a program manager interface for interfacing at least with the user entity and a communications network.

In one embodiment, the user entity may further comprise an approval unit to provide at least one of an approval or denial of the request; an approval protocol module for providing at least one protocol for performing the approval or denial; and a funds transfer unit for provide a transfer of funds to a payment mechanism.

In one embodiment, the payment mechanism may be at least one of a debit card, a pre-paid card, a credit card, an electronic payment device; a payment application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer.

The particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

1. A method for providing an automated transfer of funds, comprising:

receiving data relating to an unused amount in an account associated with a first payment mechanism;

determining if a user of a second payment mechanism has a pending request for funding;

transferring at least a portion of said unused amount from said account associated with said first payment mechanism to an account associated with a second payment mechanism in response to determining that said user of said second payment mechanism has a pending request for funding; and

transferring at least a portion of said unused amount from said account associated with said first payment mechanism to a master account in response to determining that said user of said second payment mechanism does not have a pending request for funding.

2. The method of claim 1, wherein said receiving data is performed over a communications interface comprising at least one of:

a mobile device interface;

a cloud computing interface;

an Internet interface;

a program manager interface;

an Intranet interface;

a wireless interface; or

a wired interface.

3. The method of claim 1, further comprising at least one of:

approving said pending request of said user of said second payment mechanism, or rejecting said pending request of said user of said second payment mechanism.

4. The method of claim 1, wherein said first and second payment mechanisms each is at least one of a debit card, a pre-paid card, a credit card, an electronic payment device; a payment application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer.

5. A non-transitory computer readable program storage unit encoded with instructions that, when executed by a computer, perform a method for providing an automated transfer of funds, comprising:

receiving data relating to an unused amount in an account associated with a first payment mechanism;

determining if a user of said payment mechanism has a pending request for funding;

transferring at least a portion of said unused amount from said account associated with said first payment mechanism to an account associated with said user in response to determining that said user has a pending request for funding; and

transferring at least a portion of said unused amount from said account associated with said first payment mechanism to a master account in response to determining that said user does not have a pending request for funding.

6. The non-transitory computer readable program storage unit of claim 6, wherein said receiving data is performed over a communications interface comprising at least one of:

a mobile device interface;

a cloud computing interface;

an Internet interface;

a program manager interface;

an Intranet interface;

a wireless interface; or

a wired interface.

7. The non-transitory computer readable program storage unit of claim 6, wherein said method further comprises at least one of:

approving said pending request of said user of; or

rejecting said pending request of said user.

8. The non-transitory computer readable program storage unit of claim 6, wherein said payment mechanism is at least one of a debit card, a pre-paid card, a credit card, an electronic payment device; a payment application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer.

9. An apparatus for providing an automated transfer of funds, comprising a reallocation unit, said reallocation unit configured to:

receive data relating to an unused amount in an account associated with a first payment mechanism;

determine if a user of a second payment mechanism has a pending request for funding;

transfer at least a portion of said unused amount from said account associated with said first payment mechanism to an account associated with a second payment mechanism in response to determining that said user of said second payment mechanism has a pending request for funding; and

transfer at least a portion of said unused amount from said account associated with said first payment mechanism to a master account in response to determining that said user of said second payment mechanism does not have a pending request for funding.

10. The apparatus of claim 9, wherein said reallocation unit comprises a communications interface configured to receive said data relating to said unused amount, said communications interface comprising at least one of:

a mobile device interface;

a cloud computing interface;

an Internet interface;

a program manager interface;

an Intranet interface;

a wireless interface; or

a wired interface.

11. The apparatus of claim 9, wherein said payment mechanism is at least one of a debit card, a pre-paid card, a credit card, an electronic payment device; a payment application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer.

12. A system for performing a transaction, said system comprising:

a card originator for providing a first payment mechanism and a second payment mechanism;

a card issuing entity in communication with said card originator, wherein said card issuing entity is configured for providing funding for said first and second payment mechanisms;

a program manager in communication with said card issuing entity, said program manager configure for managing at least one funding operation of said system;

a card processor in communication with said program manager said card processor configured for processing a transaction of said first and second payment mechanisms;

a remote unit in communication with said program manager, said remote unit comprising a request unit for providing a funding request; and

a reallocation unit configured to determine an unused amount in a first account associated with said first payment mechanism and transfer said unused amount to a second account associated with said second payment mechanism in response to said funding request.

13. The system of claim 12, wherein reallocation unit is further configured to:

receive data relating to said unused amount;

determine, based upon said data, whether there is an unused amount said first account associated with said first payment mechanism;

determine if said second payment mechanism is associated with a pending request for funding;

transfer at least a portion of said unused amount from said first account associated said second account in response to determining that said user of said second payment mechanism has a pending request for funding; and

transfer at least a portion of said unused amount from said first account associated to a master account in response to determining that said second payment mechanism is not associated with a request for funding.

14. The system of claim 12, wherein said card issuing entity is a bank.

15. The system of claim 12, wherein said user entity comprises:

a communications interface for providing for communications between said remote unit and at least one of said user entity or said program manager;

a card holder unit comprising a second request unit for providing said funding request; and

an administrator for administrating said funds request and said funding.

16. The system of claim 12, wherein said communications interface comprises at least one of:

a mobile device interface; a cloud computing interface; an Internet interface; a program manager interface; an Intranet interface; a wireless interface; or a wired interface.

17. The system of claim 12, wherein said program manager comprises:

a payment set-up unit for setting up a funding payment;

an institution association unit associating a user with at least one institution;

a card assignment unit capable of assigning a payment mechanism to said user;

a group management unit to perform at least one of an approval, a prompt for modifying said request;

a user interface unit for interfacing with at least one user;

a funding unit to control at least one aspect of said funding;

a database comprising at least one of rules for funding; information of a user; or information relating to available funding; and

a program manager interface for interfacing at least with said user entity and a communications network.

18. The system of claim 12, wherein said user entity further comprises:

an approval unit to provide at least one of an approval or denial of said request;

an approval protocol module for providing at least one protocol for performing said approval or denial; and

a funds transfer unit for provide a transfer of funds to a payment mechanism.

19. The system of claim 12, wherein said first and second payment mechanism each is at least one of a debit card, a pre-paid card, a credit card, an electronic payment device; a payment application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer.

20. A non-transitory computer readable program storage unit encoded with instructions that, when executed by a computer, perform a method for providing an automated transfer of funds, comprising:

receiving a request for funding from a user of a first account;

initiating a reallocation process in response to receiving said request for funding, wherein said reallocation process comprises: determining whether a second account comprises an unused amount; and reallocating said unused amount from said second account to said first account;

determining whether sufficient amount has been transferred to said first account to satisfy said request for funding; and

transferring funding from a master account to first account in response to a determination that an insufficient amount has been reallocated to said first account to satisfy said request for funding.

21. The non-transitory computer readable program storage unit of claim 20, further comprising:

transferring funding from a second account to a master account in response to a determination that an sufficient amount has been reallocated to said first account to satisfy said request for funding.