US20150095231A1

US20150095231A1 - Method, apparatus and system for automatically triggering a transaction

Info

Publication number: US20150095231A1
Application number: US14/494,442
Authority: US
Inventors: Michelle Harold; Mark Breuer; John F. Tangredi
Original assignee: Insperity Services LP
Current assignee: Insperity Services LP
Priority date: 2013-09-27
Filing date: 2014-09-23
Publication date: 2015-04-02
Also published as: US11250502B2; US20150095076A1; WO2015048585A1; US11216871B2; US20150095229A1; US20150095230A1; WO2015048581A1; WO2015048579A1; WO2015048587A1; US20150095075A1; WO2015048586A1

Abstract

Embodiments herein provide for a method, system, and apparatus for automatically triggering a funding transaction. Data associated with an activity relating to a user of an account is received. A determination is made as to whether the activity relates to funding of the account. In response to determining that the activity relates to funding of the account, a determination is made as to whether the funding is approved. In response to determining that the funding is approved, automatically triggering a funding transaction for providing funding into the account. The funding transaction is performed in response to the triggering.

Description

The present application claims the benefit under 35 U.S.C. §119(e) of prior-filed co-pending provisional 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
Generally, the disclosed embodiments relate to automated funding, and, more particularly, to provide automated triggering of transactions, such as automatically replenishing funding into an account.
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.
In order to initiate a transaction, a range of actions generally have to take place. This may include cumbersome paperwork, requests, approvals, etc. For example, if a funding for a particular activity (e.g., a project, recurring business travel, etc.) is approved, additional funding of that activity may require manual steps such as seeking approval and awaiting approval for additional funding, etc. This may create an additional administrative burden on an organization. Further, needless delays may occur as a result of manually seeking additional funding or funding of recurring activities. Moreover, certain activities may be incentivized, such as submitting an expense report, if replenishing of funding of an activity were tied to such activities. The state of the art lacks an efficient means to prevent delays in approval of funding or replenishing of funding. These delays may interfere in performing efficient execution of various tasks and/or travel performed by an employee or agent of an organization.

SUMMARY OF EMBODIMENTS

Generally, the present disclosure is directed to various methods, apparatus and system for automatically triggering a funding transaction. Data associated with an activity relating to a user of an account is received. A determination is made as to whether the activity relates to funding of the account. In response to determining that the activity relates to funding of the account, a determination is made as to whether the funding is approved. In response to determining that the funding is approved, automatically triggering a funding transaction for providing funding into the account. The funding transaction is performed in response to the triggering.

BRIEF DESCRIPTION OF THE FIGURES

The disclosed subject matter will hereafter be described with reference to the accompanying drawings, wherein like reference numerals denote like elements, and:

FIG. 1 provides a system for providing an automated funding process, in accordance with some embodiments of the present disclosure;

FIG. 2 illustrates a stylized depiction of a remote unit in communications with a user entity of the system of FIG. 1, in accordance with some embodiments of the present disclosure;

FIG. 3 illustrates a stylized block diagram depiction of a communications interface of the user entity of FIG. 2, in accordance with some embodiments of the present disclosure;

FIG. 4 illustrates a stylized depiction of a program manager of FIG. 1, in accordance with some embodiments of the present disclosure;

FIG. 5 illustrates a stylized block diagram depiction of the user entity of FIG. 2, in accordance with some embodiments of the present disclosure

FIG. 6 illustrates a stylized block diagram depiction of the notification unit of FIG. 5, in accordance with some embodiments of the present disclosure;

FIG. 7 illustrates a flowchart depiction of a performing a funds flow process, in accordance with some embodiments of the present disclosure;

FIG. 8 illustrates a flowchart depiction of a process of performing a triggered transaction, in accordance with some embodiments of the present disclosure;

FIG. 9 illustrates a flowchart depiction of a process of performing an activity-trigger analysis of FIG. 8, in accordance with some embodiments of the present disclosure;

FIG. 10 illustrates a flowchart depiction of a process of performing an initiation of a transaction of FIG. 8, in accordance with some embodiments of the present disclosure; and

FIG. 11 illustrates a flowchart depiction of a process of performing an automatic replenishment of FIG. 8, in accordance with some embodiments of the present disclosure.

While the disclosed subject matter 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. It should be understood, however, that the description herein of specific embodiments is not intended to limit the disclosed subject matter 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 disclosed subject matter as defined by the appended claims.

DETAILED DESCRIPTION

Illustrative embodiments of the invention are described herein. In the interest of clarity, not all features of an actual implementation are described in this specification. In the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the design-specific goals, which will vary from one implementation to another. It will be appreciated that 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 automatically triggering a transaction. The transaction may include providing a funding to a user of a payment mechanism, such as: a debit card, a pre-paid card, a credit card, an electronic payment device; or a payment en application capable of being executed in a mobile device, a tablet computer, a laptop computer, or a desktop computer.
In some embodiments, information from a user regarding an activity ay be used to trigger a transaction. For example, a module may automatically scan across various data sets tier a funding trigger based upon the scanned data and/or information from a user of an account or card. In some cases relevant emails, project entries, trip schedules, etc., may be detected by a module and a funding transaction may be triggered. The funding transaction may include obtaining relevant information to the funding, seeking manual or automated approval,and providing appropriate funding.
In some embodiments, a module (e.g., a processor coupled to memory comprising a program that can be executed) may automatically scan for a triggering event that may trigger a transaction. For example, a module may detect an occurrence of an event that requires a transaction. In some cases, approval of a trip, approval of a project, conclusion of a trip, submission of a request, submission of an expense report, etc., may trigger a transaction. This transaction may include providing a funding into an account of into a payment mechanism, moving excess funds from an account or payment mechanism, replenishing of an account, etc.
In other embodiments, a module may automatically monitor a threshold for triggering a transaction. For example, a temporal threshold may be monitored such that after passing of a threshold time period, a transaction providing funding into an account may be periodically made. For example, the expense account of a traveling employee may be automatically replenished based upon the passing of 30-days, tempered with an ongoing check to determine if the auto-replenishing of the account is still approved. Another example of triggering a transaction based upon a threshold may include the depletion of funds in a project or card account below a predetermined amount. In such cases, pending other approval procedures, an automatic replenishment transaction may be performed to restore adequate funding for on-going or upcoming activities of a user of an account or card.
Some embodiments herein provide for organizations (e.g., corporations) to quickly and efficiently 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, wireless 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 user 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 etc., 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 distributed 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 approval 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.
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.
Turning now to FIG. 1, a block diagram depiction of a funds management system for providing an automated triggered transaction, in accordance with some embodiments, is illustrated. The system 100 may comprise a card originator 110, which provides a financial transaction mechanism for performing financial transactions. The card originator 110 may provide a transaction mechanism that is a spendable transaction card, such as a debit card or a credit card issued by an entity such as Visa, Master Card, American Express, Discover Card, etc. The card originator 110 may provide other transaction mechanisms for facilitating transactions, e.g., wireless transfer of funds from an electronic device, such as a stand-alone transaction electronic device, an application on a remote portable computer, or a mobile device, such as a cell phone. The card originator 110 may be in communication with a card issuing entity 120, such as a bank. The card issuing entity 120 may be a principal member of the card originator 110. For example, the card issuing entity 120 may enter into an agreement with the card originator 110 to provide funding for the transaction mechanism provided by the card originator 110.
The system 100 may also comprise a program manager 140, which may be an entity that is capable of managing manual and automated financial transactions between a user entity 150 and a card processor 130. The card processor 130 may be capable of processing a financial transaction initiated by a user utilizing a transaction mechanism provided by the card originator 110.
The user entity 150 may be an organization, such as a corporation, 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 finding 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 program manager 140 may be an entity that provides management services that facilitates automated request and approval of funding. One example of a program manager 140 is Insperity, Inc. 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 networks described herein for accounting of transactions performed using transaction mechanisms, authorization and settlement of accounts, etc. The program manager 140 supports automatic request, notification and approval of funding within the user entity 150.
The user entity 150 may comprise a transaction trigger unit 160, a card holder unit 152 and an administrator 154. The transaction trigger unit 160 is capable of triggering a transaction based upon various factors, such as an input from a user, data relating to an activity of a user, a triggering event, a threshold that is met, etc. Upon triggering a transaction, funding for a user associated with the user entity 150 may be performed. Further, the transaction trigger unit 160 may provide various notifications of a triggered transaction to various entities, such as a user of the payment mechanism that is subject to the trigger transaction, the program manager 140, the card processor 130, an administrator of the funding matters of the trigger transaction, etc. A more detailed description of the transaction trigger unit 160 is provided in FIG. 6 and accompanying description below.
The card holder unit 152 may be a user of the financial transaction mechanism. The administrator 154 may be an entity that is capable of approving (a) request(s) for funds. The administrator 154 may prompt funding of transaction mechanism, e.g., the card, in response to the approval of a request for funding.
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 be programmed to implement rules-based, threshold-based and/or event-based protocols.
The term “card” as used herein, may include various financial transaction mechanisms, such as credit cards, debit cards, auto payment, electronic devices, and transaction applications (apps) residing on an electronic device, such as a mobile device, or portable computer, a tablet computer, etc. In some embodiments, the term “expense card” may be utilized to signify the card described above.
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.
Turning now to FIG. 2, a stylized, blocked diagram depiction of a remote unit in communication with the user entity of FIG. 1, in accordance with some embodiments, is illustrated. A remote unit 210 may be one of several types of communications and/or computing devices that may interface with the user entity 150. For example, the remote unit 210 may be a mobile device, a remote computer, a tablet computer, a smart watch device, a wearable computing device, a desktop computer, or any other device that has communications and/or computing capabilities. The term “communications” may include audio communications, radio communications, electronic communications, data communication, and/or analog communications.
The remote unit 210 may communicate with the user entity 150 via a communications network 220. The communications network 220 may comprise the Internet, an intranet, a cloud computing network, a peer-to-peer network, a closed communication network system, and/or the like. The communication network 220 provides for communications links between the remote unit 210 and the program manager 140 and the user entity 150.
In order to facilitate communications with the user entity 150, the user entity 150 may comprise a communications interface 156. The communications interface 156 is capable of providing a communications link between the remote unit 210 and the user entity 150. The communications interface 156 may comprise various hardware, firmware and/or software modules that provide for digital and/or analog communications communications between the remote unit 210 and the user entity 150. In this manner, the remote unit 210 may be able to perform various functions involving the cardholder unit 152 and the administrator 154, such as requesting or providing approvals for expenses, funding an expense card associated with a card holder, and/or various activities concerning the administrator 154. Therefore, a user utilizing the remote unit 210 may be able to achieve real time or near real time approval of an expense and/or funding of an expense card via the communications network 220. Therefore, a manager in charge of approving transactions or funding may, in real time, provide such funding and approvals. Similarly, an automated approval may also be provided based upon a request received via the communications network 220. In alternative embodiments, the remote unit 210 may be a computer system, which may be comprise a software, hardware and/or firmware module that is configured to provide for automated approvals, funding based upon a funding request, and/or seek approvals or funding.
The transaction trigger unit 160 of the user entity 150 may also be coupled to the communications interface 156. Various notifications described herein may be provided to one or more remote units 210 via the communications interface 156. Various data (e.g., user data, event data, threshold data, etc.) may be received by the transaction trigger unit 160 via the communication interface 156. These data sets may be used by the transaction trigger unit 160 to trigger the performance of a transaction.
Turning now to FIG. 3, a stylized block diagram depiction of the communications interface 156 of FIG. 2, in accordance with some embodiments, is illustrated. The communications interface 156 provides for communications between the user entity 150 and the program manager 140 and/or the communications network 220. Through the communications network 220 (FIG. 2), the user entity 150 is capable of communicating with a remote device 210 (e.g., a mobile device). The communications interface 156 may comprise various interfaces that are capable of communicating with electronic devices using various types of communications methods. The communications interface 156 may comprise a mobile device interface 310 that will allow cellular network communications between the user entity 150 and a mobile device. The communications interface 156 may also comprise a cloud computing interface 320 that is capable of facilitating communications between the user entity 150 and any device via a cloud network. The communications interface 156 may also comprise an Internet interface 330 that provides for communications between the user entity 150 and any device via the Internet.
A program manager interface 340 in the communications interface 156 may provide for direct communications between the user entity 150 and the program manager 140. In some embodiments, a private communications network may be set up between the program manager 140 and the user entity 150. An intranet interface 350 in the communications interface 156 provides for communications between the user entity 150 and an intranet network, such as a private network.
The communications interface 156 may also comprise a wireless interface 360 and a wired interface 370. The wireless interface 360 provides for communications between the user entity 150 and any device via a wireless communications network, such as a wireless router attached to a device, e.g., 802.11xx communications, Bluetooth communications, etc. The wired interface 370 may provide for wired communications between the user interface 150 and an electronic device. Wired communications may include an Ethernet wired communications link, a USB communications link, etc. Those skilled in the art, having benefit of the present disclosure would appreciate that the communications interface 156 may comprise other types of communications interfaces that provide for communications between the user entity 150 and other devices.
Turning now to FIG. 4, a block diagram depiction of the program manager 140 of the system 100 (FIG. 1), in accordance with embodiments herein is presented. The program manager 140 may be an entity that interfaces with the card issuing entity 120, the card processing unit 130 and the user entity 150 (FIG. 1) in order to facilitate transaction approval and automated funding of an expense card. In one embodiment, the program manager 140 provides for controlling financial transactions and/or approvals of financial transactions between a user entity 150 and a card processor 130. In one embodiment, the program manager 140 may interface with the administrator 154 of the user entity 150 for providing control over a card program that provides for automated approval and funding of expense cards.
The program manager 140 may comprise a payment set-up unit 410, an institution association unit 420, a card assignment unit 430, a group management unit 440, a user interface unit 450, a funding unit 460, a database unit 470, and a program manager interface 480. The units 410-480 of the program manager 140 may be comprised of hardware modules, software modules, and/or firmware modules.
The user interface unit 450 may provide for communications between the program manager 140 and the user entity 150, and more specifically, the administrator 154 and a user of an expense card. 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 entity 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 institution association unit 420 of the program manager 140 may provide for associating an expense card payment method to a particular financial institution, such as the card issuing entity 120 (FIG. 1). 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 card assignment unit 430, along with the program manager 140 is capable of providing for assigning an expense card to a card 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 group management unit 440 provides for creating and managing an expense card group. 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 rules. 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 for 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.
The funding unit 460 of the program manager 140 may provide for funding of the expense cards. The funding may be based upon pre-determined rules that may apply uniquely for different card holders or for different groups. Once an expense card has been authorized for funding, the funding unit 460 may prompt movement of funds from a master account to an expense card. In another embodiment, once an expense card has been authorized for funding, the funding unit 460 may prompt movement of funds from a master account to a group account, wherein another entity such as the group manager, may prompt the funding unit 460 to move funds from the group account to the individual expense card. Alternatively, once a certain amount of funds are provided to the group account, all members of the group may use individual expense cards so long as individual limits associated with each expense card are not exceeded, and the total expenses of the group do not exceed the amount available in group account.
The database 470 may comprise one or more sub-databases of data portions that may store various rules and card holder data, as well as financial institution data and card issuance data. The database 470 may hold information with regard to the user entity 150, the administrator 154, the card holder 152, etc. The database 470 may also store funding data, account data, transaction history data, and/or information with regard to individual cardholder users. The database may store data for, and/or provide data to, various portions of the program manager 140, the user entity 150, the card processor 130, the card issuing entity 120, and/or the card originator 110. The database 470 may store information utilized by the various units 410-460 of the program manager 140. In some embodiments, database 470 may be a standard database accessible by normal addressing. In other embodiments, the database may be a relational database and/or a hierarchical database.
Turning now to FIG. 5, a more detailed stylized block diagram depiction of the user entity 150, in accordance with some embodiments, is presented. As illustrated in FIG. 5, the communication interface 156 may communicate with the transaction trigger unit 160, the communication network 220, as well as with the program manager 140.
Various types of data may be sent and/or received by the user entity 150 via the communications interface 156. The cardholder unit 152, which may comprise a request unit 510 (described below), may provide request-information to the notification unit 160, which may process the request and provide notification information to the communications interface 160.
The card holder unit 152 described above may comprise a request unit 510. The request unit 510 may be capable of processing a request received from a user via the communications network 220 and/or the program manager 140. The request unit 510 is capable of providing feedback based on a request for funding. The request unit 510 may process a funding request for further approval, process an inquiry regarding additional information, provide a message to modify the request, and/or deny the request.
Information from the request unit 510 and other data from the card holder unit 152 may be provided to the approval unit 520. The approval unit 52.0 may be capable of making a determination whether to approve a request for funds. The approval unit 520 may be configured to perform various checks (rules test, threshold test, event test, etc.) prior to approving a request for funds. The approval unit 520 may comprise one or more rules that may be checked when determining whether to provide an approval or rejection of the request. In alternative embodiments, a separate module may be used to stores rules, thresholds, and/or event tests, and may be configured to receive further programming. For example, the user entity 150 may comprise an approval protocol module 530 that is capable of providing indications to the approval unit 520 for determining whether to approve or deny a request for funding. The approval protocol module 530 may be configured with one or more rules, thresholds, event checking functions, etc., in order to determine whether approval should be provided.
In addition to checking for rule based, event based or threshold based tests, the approval unit 520 may also interface with the administrator 154 in order to determine whether a request should be approved or denied. For example, the administrator 154 may comprise an accounting unit 540. The accounting unit 540 may comprise information relating to the account that may be used to provide the funding, the amount of funds available, and the amount of funds allowable for a particular user, etc. Therefore, in addition to rules protocol or threshold or event protocol, the approval unit 520 may also check accounting parameters in order to determine whether to provide an approval for a funding request. For example, if the rules, events or threshold protocols indicate that an approval can be made, but the accounting unit 540 provides information indicating there is a lack of funds in the master account, the approval unit 520 may reject the request. Further, the approval unit 520 may provide a reason for the rejection and an invitation to either modify the request or attempt the request at a later time.
The user entity 150 may also comprise a funds transfer unit 550. The funds transfer unit 550 may be in communication with the administrator 154 as well as the approval unit 520. Based upon an approval provided for funding, the fund transfer unit 550 may perform a fund transfer process in order to transfer funds to the card holder unit 152. The funds transfer unit 550 may receive instructions from the administrator 154 to perform a fund transfer transaction. The fund transfer unit 550 may also provide information to the approval unit 520 that a fund transfer cannot be made for one or more reasons, e.g., lack of funds, delay in replenishing funds into the master account, etc. Upon receiving such information, the approval unit 520 may reject a request, withdraw a prior approval of the request, or provide instructions to modify or resubmit the request at a later time.
Using the various modules shown in FIG. 5, a plurality of types of transactions may be triggered by the transaction trigger unit 160. In embodiment, the transaction trigger unit 160 may receive user data from the cardholder unit 152. This data may include information as one or more activity of the user of a card. This data may be used by the transaction trigger unit 160 to determine if a funding transaction is warranted, based upon predetermined rules. For example, if the user data indicates that a trip has been scheduled, a transaction to provide funding to the expense account of the user may be triggered by the transaction trigger unit 160. However, prior to performing this transaction, additional checks, such as a check with an approval protocol from the approval protocol module 530 may be made. The approval protocol module 530 and the approval unit 520 may provide an approval to perform the triggered transaction to the transaction trigger unit 160.
Upon receiving approval to perform the triggered transaction, the transaction trigger unit 160 may communicate with the accounting unit 540 to ensure that sufficient funding is available prior to providing the funding for the triggered transaction. Upon determining that sufficient funds are available to perform the triggered transaction, the transaction trigger unit 160 may prompt the fund transfer unit 550 to provide the funds to satisfy the triggered transaction. Upon performing the transaction, the transaction trigger unit 160 may notify various entities of the transaction via the communications interface 156.
The various portions of the user entity 150 may be automated using one or more computing devices comprising hardware, software, and/or firmware modules. Further, the various portions of the user entity 150 illustrated in FIG. 5, may be comprised of hardware, firmware, and/or software modules.
Turning now to FIG. 6, a stylized block diagram depiction of the transaction trigger unit 160 of FIG. 1, in accordance to embodiments herein is illustrated. The transaction trigger unit 160 comprises an auto-fund criteria unit 610, a user input unit 620, a trigger event detection unit 630, a threshold detection unit 640, and a funding trigger unit 650.
The auto-fund criteria unit 610 may comprise various rules, thresholds, trigger points, etc., that may prompt the transaction trigger unit 160 to perform an automated triggering of a transaction based upon data relating to activities of a user. Upon determination that criteria for triggering a particular transaction has been met, the funding trigger unit 650 may prompt the funding of the transaction. That is, the funding trigger unit 650 is capable of causing the user entity 150 to perform a funding transaction based upon satisfaction of the criteria to perform an auto-funding process. The affirmative prompt to performing a funding process based upon a triggering event signal provided by the auto-fund criteria unit 610, the user input unit 620, the trigger event detection unit 630, and/or the threshold detection 640.
In one embodiment, the user input unit 620 may scan for user data that may be used to determine whether or not to trigger a particular transaction. For example, the user input unit 620 may scan for user activity, e.g., email, reporting of a user activity requiring funding, user schedule indications, etc. Alternatively, the user input unit 620 may look for information from the user, such as requests relating to an activity requiring funding or other user activity information, in order to determine whether the activity warrants triggering a predetermined, corresponding transaction.
The trigger event detection unit 630 may scan for an event that warrants the triggering of a transaction. For example, based upon a particular event, such as a mandate to an employee to perform a certain task, an automatic triggering of a transaction may be promoted. The trigger event detection unit 630 may scan for various predetermined events to determine whether or not to trigger a transaction. For example, upon expiration of a predetermined time period, an automated replenishment of an expense account may be performed. Another example of an event that may trigger a transaction is the completion and submission of an expense report, which may prompt a replenishment of an expense account. These transactions may be tempered by one or more rules associated with the auto-fund criteria unit 610. Any number of events may be programmed such that they could cause the triggering of a transaction.
The threshold detection unit 640 may scan for one or more data sets that may be compared to (predetermined corresponding threshold. Based upon this threshold, the threshold detection unit 640 may determine that a threshold-triggering circumstance has occurred, in light of the rules and threshold of the auto-fund criteria unit 610. For example, if the expense account of a user falls below a threshold level, an automated replenishment of the account may be performed. The triggering of the transactions may be tempered by the rules and threshold levels of the auto-find criteria unit 610.
Data from one or more of the user input unit 620, the trigger event detection unit 630 and/or the threshold detection unit 640 may be used by the auto-find criteria unit 610 to determine whether a transaction should be triggered. In some cases the various criteria, rules, thresholds may be modified and/or updated by a remote entity. Upon satisfying the criteria for triggering a threshold, the funding trigger unit 650 may prompt the execution of the trigger, e.g., providing funding as prescribed by the rules and thresholds.
Turning now to FIG. 7, a flowchart depiction of a funds flow process, in accordance with embodiments herein, is illustrated. In one embodiment, the program manager 140 may interface with a client operating account to the user entity 150 (block 710). In one embodiment, this interaction may be prompted by the user entity 150 in response to an expense funding request. In another embodiment, this interaction may be prompted by an indication to automatically replenish an expense account. The automatic replenishment may be responsive to the detection of an event (e.g., the end of a business trip), or passing of a predetermined time window (e.g., replenishment at the end of every month).
In some embodiments, the card issuing entity 120, such as a bank, may interact with the user entity 150 via a program manager 140. The interfacing of the program manager 140 with the client operating account may include establishing a communications protocol with the client operating account. Upon establishing a communications protocol with the client operating account, one or more transactions may be made, e.g., providing funding to the account or extracting funds from the account.
Upon interfacing with the client operating account, funds may be provided to the account (block 720). In some embodiments, the funds may be transferred electronically, e.g., an automated clearing house (ACH) electronic network may provide a direct deposit to the client operating account. Upon providing the funds, a prompt may be made to the card issuing entity 120 (e.g., a bank) to send funds to the card processor (block 730). The prompting of the card issuing entity 120 may be performed by the program manager 140. The transfer of the funds to the card processor 130 may be performed under the direction of the card originator via the program manager 130.
A virtual card account, e,g., a client master account, may be credited upon funding (block 740). The client master account may be part of the card holder unit 152 of the user entity 150. Once a virtual card account is funded, automated transfer of funds to and from user cards may be allowed (block 750). The automated transfer of funds to and from the user cards may be performed in a real-time or a near real-time manner. Exemplary embodiments of performing the automated real-time transfer and approval are described below. The automated transfer of funds may be made to user cards of employees, for example, for funding various activities, (e.g., travel, other expenditures) performed by the employee on behalf of the user entity 150. Those skilled in the art, having benefit of the present disclosure would appreciate that other methods of providing funds to a virtual card account, such as a client master account, may be performed while remaining within the spirit and scope of the embodiments disclosed herein.
Turning now to FIG. 8, a flowchart depiction of a method of performing a triggered transaction, in accordance with some embodiments herein, is illustrated. The transaction schedule is received (block 810). The transaction schedule may comprise one or more thresholds, rules, activity data, etc., that may be compared to received or detected data in order to determine whether a transaction should be triggered. For example, an amount-threshold may be provided, such that if the funds in an account fall below the threshold, an automated transaction may be triggered for automatically replenishing the funds into the account. In some embodiments, the transaction schedule may also comprise temporal information as to the timing of various activity or events associated with a user having an account. The transaction schedule may be stored for comparison when certain activities are detected (block 820). In some embodiments, the transaction schedule may be stored locally (e.g., within the user entity 150), or at a remote location (e.g., the remote unit 210). In some embodiments, the transaction schedule may be adjusted dynamically, e.g., using a remote device, such a mobile phone.
Once the transaction schedule is in place, the user entity 150 may monitor one or more activities (block 840). Monitoring activity may include monitoring data sets associated with account activity, travel activity, data from a user regarding an activity that may require funding, transaction activity, and/or various other types of data sets. The user entity 150 may make a determination that an activity that may be relevant to one or more transactions has been detected (block 840). If no such activity is detected, the process reverts back to block 830, wherein activity is further monitored.
If a relevant activity is detected, an activity-trigger analysis is performed (block 850). The activity-trigger analysis may be used to determine whether a transaction should be triggered. A more detailed description of the activity-trigger analysis is provided in FIG. 7, and accompanying description below. Based upon the activity-trigger analysis, if an activity is triggered, the user entity 150 may initiate the triggered activity (block 860). A more detailed description of initiating the triggered activity is provided in FIG. 10 and accompanying description below.
Turning now to FIG. 9, a flowchart depiction of performing the activity-trigger analysis of FIG. 8, in accordance with some embodiments herein. The user entity 150 may receive activity data that may be used to perform the activity-trigger analysis (block 910). The activity data may comprise one or more data sets relating to a variety of activities associated with the user of an account. For example, a module (e.g., a hardware module, a software module, a firmware module, or a module of any combination thereof) may detect details of a user's travel schedule, a request by the user, an indication of a submission of an expense report, and/or the like. In one embodiment, the user entity 910 maybe may receive activity data by polling via the communications interface 156 to determine if such data have been sent by one or more modules in the system 100. In other embodiments, the user entity 910 may actively seek or perform a push function to find/acquire activity data. In some embodiments, a periodic check for activity data that may be used to trigger a transaction may be performed. In some examples, upon occurrences of certain activities (e.g., finalizing a travel plan), an automated message may be sent to the user entity 910. In some embodiments, based upon this message, initiation of further acquisition of activity data that may be used for the activity trigger analysis may be performed.
Upon receiving activity data, the user entity 910 may determine whether the activity data relates to predetermined rules and/or thresholds (block 920). For example, certain rules may be generated to govern triggered transactions. The activity data may be examined to determine whether one or more rules are related to the activity data. For example, upon finalizing travel plans of a user, the data relating to such activity may be compared to various stored rules. For example, if the travel is to occur within 30 days, and the person traveling is an approved user of an account, rules may dictate that funding of such travel activity may be provided within 15 days. In other cases, activity data may be compared to one or more thresholds. For example, with regard to a user that frequently travels and requires an ongoing expense account, activity data related to stored rules may dictate that the replenishing of the account should be performed from within 15 days. The rules may also require that other checks be made (e.g., checks to determine if the travel plans have been approved and the previous expense report has been submitted) prior to performing the replenishing of the account.
In other embodiments, if a user has an expense account that should be maintained above a certain level, upon depletion of that account below a threshold amount, the user entity 150 may perform a check to determine whether the user entity should replenish the account. This determination may be based on one or more factors, such as approval from the user's supervisor, available funds, etc. Various other rules and/or thresholds may be used to determine whether the received activity data is indicative of prompting a transaction trigger. In this manner, the rules and/or thresholds are applied to the activity data (block 930).
Upon applying the rules to the activity data, several checks or determinations may be performed. These checks (block 942-948) may be performed simultaneously, i.e., in parallel, or alternatively, in a serial fashion. For example, the user entity 150 may determine whether the activity indicated by the activity data has been completed based upon rules corresponding to the activity data (block 942). For example, a check may be made to determine whether an expense report has been submitted.
Another example of a check may be to determine whether the activity data indicates that a predetermined time has elapsed based upon rules corresponding to the activity data (block 944). For example, an account of a user may be automatically replenished every month, therefore, a time-period check may be made.
Another example of a query made by the user entity 150 is a determination as to whether the activity data indicates that a predetermined required event has taken place, based upon rules corresponding to the activity data (block 946). For example, the user entity 150 may determine that a business trip has been concluded and may be required by the rules to extract any unused funds from the expense account of the user.
Yet another example of the query made by the user entity 150 is an inquiry to determine whether a threshold has been crossed (block 948). For example, if the funds in an account cross below a low threshold, an action may be taken. As such, upon determining that the queries of blocks 942-948 indicate in the negative, no corrective action, such as no auto-replenishing of the account, is taken (block 950). The user entity 150 may then continue pulling or pushing for activity data. Upon determining that the queries of blocks 942-946 indicate in the affirmative, a transaction trigger (e.g., replenishment trigger) may be initiated (block 950).
Turning now to FIG. 10, a flowchart depiction of the method of initiating a triggered transaction of FIG. 8, in accordance with embodiments herein. A trigger signal is received indicating that a particular transaction may be performed (block 1010). A determination is made as to whether the trigger has been activated (i.e., whether the transaction has been initiated) (block 1020). If the trigger has not been activated, the corresponding transaction is not performed (block 1030). In some embodiments, this may include a message that the trigger has not been active and/or the any triggering of a transaction has been canceled.
Upon a determination that the trigger has been activated, the type of transaction is to be triggered is determined based upon one or more characteristics or parameters of the trigger (block 1040). In some embodiments, the trigger signal may comprise various information such as the type of transaction to trigger (based upon rules or threshold), the amount involving the transaction, the timing or deadline of the action, etc. The transaction that is the subject of the trigger may then be automatically performed (block 1050). For example, upon triggering a replenishing transaction, the replenish process may be performed. A more detailed description of performing the triggered transaction of FIG. 10 is provided in FIG. 11 and accompanying description below.
Turning now to FIG. 11, a flowchart depiction of the method of performing a triggered transaction of FIG. 8, in accordance with embodiments herein. Information relating to the type of transaction to be performed is received (block 1110). For example, the type of auto-replenishment (one-time, periodic, based upon request, etc.) to be performed is received. A check may then be made to determine whether there are sufficient funds in the client master account to satisfy the transaction (block 1120). If sufficient funds are available, the transaction is performed, e.g., the specified amount of funds is provided to a user's card from the client master account) (block 1030).
If a determination is made that sufficient finds are not available for satisfying the transaction, a request for increasing the funds (e.g., in the client master account) for the performing the transaction may be made (block 1140). A determination whether the master account has been sufficiently updated for the transaction is subsequently made (block 1150). If the master account has been sufficiently updated for the transaction, the transaction is performed (path from block 1150 to block 1130). If the master account has not been sufficiently updated for the transaction, the transaction is not performed (e.g., no auto-replenishment) (block 1160). In this manner, an automated triggering of a transaction is performed in accordance with embodiments herein.
The methods depicted in FIGS. 7-11 and described above may be governed by instructions that are stored in a non-transitory computer readable storage medium and that are executed by, e.g., a processor in a computing device. Each of the operations shown in FIGS. 7-11 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 includes 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.
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

What is claimed:

1. A non-transitory computer readable program storage unit encoded with instructions that, when executed by a computer, perform a method for performing a transaction, comprising:

receiving data associated with an activity relating to a user of an account;

determining if said activity relates to funding of said account;

determining if said funding is approved in response to determining that said activity relates to funding of said account;

triggering, automatically, a funding transaction for providing funding into said account in response to determining that said funding is approved; and

performing said funding transaction in response to said triggering.

2. The method of claim 1, wherein determining if said activity relates to funding of said account comprises at least one of:

monitoring at least one transaction performed by said user;

scanning, automatically, a plurality of data sets to determine whether at least one of said data sets is indicative of said activity relating to said user; or

receiving a plurality of data sets for determining whether at least one of said data sets is indicative of said activity relating to said account.

3. The non-transitory computer readable program storage unit of claim 1, wherein determining if said activity relates to funding of said account comprises determining if said activity relates to at least one of: an approved travel; an approved purchase; or a periodic replenishing of an expense account.

4. The non-transitory computer readable program storage unit of claim 1, wherein determining if said activity relates to funding of said account comprises comparing at least one parameter associated with said data associated with said activity with at least one of a predetermined rule or a predetermined threshold.

5. The non transitory computer readable program storage unit of claim 4, wherein determining if said funding is approved comprises at least one of:

determining if said activity is an approved activity based upon said at least one predetermined rule; or

determining if an amount of funding associated with said activity is below said at least one predetermined threshold.

6. A method for performing a transaction, comprising:

receiving a transaction schedule that comprises at least one rule for triggering a funding transaction;

detecting an activity relating to said funding transaction;

determining whether an activity qualifies as a triggering based upon said transaction schedule; and

performing said funding transaction based upon determining that said activity qualifies as a triggering event.

7. The method of claim 6, wherein determining whether said activity qualifies as a triggering event based upon said transaction schedule comprises;

determining whether a predetermined activity has been performed;

determining whether a predetermined time period has elapsed;

determining whether a required activity has been completed; or

determining whether a fund amount in an account is below a predetermined threshold.

8. The method of claim 6, wherein performing said funding transaction based upon determining that said activity qualifies as a triggering event comprises:

receiving a trigger signal;

determining whether said trigger has been activated based upon said trigger;

determining a transaction type based upon said trigger; and

automatically replenish an account based upon said transaction type.

9. A non-transitory computer readable program storage unit encoded with instructions that, when executed by a computer, perform a method for performing a transaction, comprising:

receiving a transaction schedule comprising at least one rule for triggering a funding transaction;

detecting an activity relating to said funding transaction;

determining whether an activity qualifies as a triggering event based upon said transaction schedule; and

10. The non-transitory computer readable program storage unit of claim 9, wherein determining whether said activity qualifies as a triggering event based upon said transaction schedule comprises;

determining whether a predetermined activity has been performed;

determining whether a predetermined time period has elapsed;

determining whether a required activity has been completed; or

determining whether an amount is below a predetermined threshold in an account.

11. The non-transitory computer readable program storage unit of claim 9, wherein performing said funding transaction based upon determining that said activity qualifies as a triggering event comprises:

receiving a trigger signal;

determining whether said trigger has been activated based upon said trigger;

determining a transaction type based upon said trigger; and

automatically replenish an account based upon said transaction type.

12. An apparatus for performing a transaction, comprising a triggering unit, said triggering unit configure to:

receive a transaction schedule comprising at least one rule for triggering a funding transaction;

detect an activity relating to said funding transaction;

determine whether an activity qualities as a triggering event based upon said transaction schedule; and

perform a funding transaction based upon determining that said activity qualifies as a triggering event.

13. The apparatus of claim 12, wherein said triggering unit comprises:

a user input unit for receiving a triggering signal from a user;

a trigger event detection unit for detecting a triggering activity;

a threshold detection unit providing a threshold for determining whether an activity is a triggering activity;

an auto funding criteria unit for providing at least one rule for determining whether an activity is a triggering activity; and

a funding trigger unit for providing a funding of an account based upon said triggering activity.

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

a card originator for providing a payment mechanism;

a card issuing entity in communication with said card originator, wherein said card issuing entity configured for providing funding for said payment mechanism;

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 payment mechanism;

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

a triggering unit configured to automatically trigger a funding transaction based upon an activity of a user of said card that would require funding.

15. The system of claim 14, wherein said triggering unit is further configure to:

detect an activity relating to said funding transaction;

determine whether said activity qualifies as a triggering event based upon said transaction schedule; and

perform said funding transaction based upon determining that said activity qualifies as a triggering event.

16. The system of claim 15, wherein said card issuing entity is a bank.

17. The system of claim 15, 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.

18. The system of claim 15, 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.

19. The system of claim 18, wherein said program interface 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.

20. The system of claim 15, 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.

21. The system of claim 15, 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.