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

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 ofFIG. 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 ofFIG. 2, in accordance with some embodiments of the present disclosure;
• FIG. 4 illustrates a stylized depiction of a program manager ofFIG. 1, in accordance with some embodiments of the present disclosure;
• FIG. 5 illustrates a stylized block diagram depiction of the user entity ofFIG. 2, in accordance with some embodiments of the present disclosure
• FIG. 6 illustrates a stylized block diagram depiction of the notification unit ofFIG. 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 ofFIG. 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 ofFIG. 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 ofFIG. 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 toFIG. 1, a block diagram depiction of a funds management system for providing an automated triggered transaction, in accordance with some embodiments, is illustrated. Thesystem100 may comprise acard originator110, which provides a financial transaction mechanism for performing financial transactions. Thecard originator110 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. Thecard originator110 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. Thecard originator110 may be in communication with acard issuing entity120, such as a bank. Thecard issuing entity120 may be a principal member of thecard originator110. For example, thecard issuing entity120 may enter into an agreement with thecard originator110 to provide funding for the transaction mechanism provided by thecard originator110.
• Thesystem100 may also comprise aprogram manager140, which may be an entity that is capable of managing manual and automated financial transactions between auser entity150 and acard processor130. Thecard processor130 may be capable of processing a financial transaction initiated by a user utilizing a transaction mechanism provided by thecard originator110.
• Theuser entity150 may be an organization, such as a corporation, that utilizes the automated transaction request and approval provided by thesystem100. For example, theuser entity150 may be a corporation that signs on with theprogram manager140 to manage the automated request and transaction provided by thesystem100. Theprogram manager140 may provide an infrastructure for members of theuser entity150 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.
• Theprogram manager140 may be an entity that provides management services that facilitates automated request and approval of funding. One example of aprogram manager140 is Insperity, Inc. Thecard issuing entity120 may be a member of thecard originator110. Thecard originator110 and thecard issuing entity120 may enter into an agreement with theprogram manager140 for providing a business model to market and distribute various transaction mechanisms, such as the debit cards and credit cards. Theprogram manager140 may enter into an agreement with thecard processor130, wherein the agreement may be approved by thecard issuing entity120. 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. Theprogram manager140 supports automatic request, notification and approval of funding within theuser entity150.
• Theuser entity150 may comprise atransaction trigger unit160, acard holder unit152 and anadministrator154. Thetransaction trigger unit160 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 theuser entity150 may be performed. Further, thetransaction trigger unit160 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, theprogram manager140, thecard processor130, an administrator of the funding matters of the trigger transaction, etc. A more detailed description of thetransaction trigger unit160 is provided inFIG. 6 and accompanying description below.
• Thecard holder unit152 may be a user of the financial transaction mechanism. Theadministrator154 may be an entity that is capable of approving (a) request(s) for funds. Theadministrator154 may prompt funding of transaction mechanism, e.g., the card, in response to the approval of a request for funding.
• Theadministrator154 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. Theadministrator154 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, theuser entity150 may also comprise a group manager. The group manager may be part of theadministrator154, 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 theadministrator154. The duties of theadministrator154 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 inFIG. 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 thecard issuing entity120. An expense card management role may be assigned to an expense card administrator, such as theadministrator154. Further, an expense card group manager role may be assigned to managers of theuser entity150. The group manager may be able to approve and manage the expense card groups. The expense card groups may include one or morecard holder units152. 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 acard holder unit152, 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 theprogram manager140 and theuser entity150. Theadministrator154 may provide for a graphical user interface (GUI) for performing the set up described above.
• Turning now toFIG. 2, a stylized, blocked diagram depiction of a remote unit in communication with the user entity ofFIG. 1, in accordance with some embodiments, is illustrated. Aremote unit210 may be one of several types of communications and/or computing devices that may interface with theuser entity150. For example, theremote unit210 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.
• Theremote unit210 may communicate with theuser entity150 via acommunications network220. Thecommunications network220 may comprise the Internet, an intranet, a cloud computing network, a peer-to-peer network, a closed communication network system, and/or the like. Thecommunication network220 provides for communications links between theremote unit210 and theprogram manager140 and theuser entity150.
• In order to facilitate communications with theuser entity150, theuser entity150 may comprise acommunications interface156. Thecommunications interface156 is capable of providing a communications link between theremote unit210 and theuser entity150. Thecommunications interface156 may comprise various hardware, firmware and/or software modules that provide for digital and/or analog communications communications between theremote unit210 and theuser entity150. In this manner, theremote unit210 may be able to perform various functions involving thecardholder unit152 and theadministrator154, such as requesting or providing approvals for expenses, funding an expense card associated with a card holder, and/or various activities concerning theadministrator154. Therefore, a user utilizing theremote unit210 may be able to achieve real time or near real time approval of an expense and/or funding of an expense card via thecommunications network220. 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 thecommunications network220. In alternative embodiments, theremote unit210 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.
• Thetransaction trigger unit160 of theuser entity150 may also be coupled to thecommunications interface156. Various notifications described herein may be provided to one or moreremote units210 via thecommunications interface156. Various data (e.g., user data, event data, threshold data, etc.) may be received by thetransaction trigger unit160 via thecommunication interface156. These data sets may be used by thetransaction trigger unit160 to trigger the performance of a transaction.
• Turning now toFIG. 3, a stylized block diagram depiction of thecommunications interface156 ofFIG. 2, in accordance with some embodiments, is illustrated. Thecommunications interface156 provides for communications between theuser entity150 and theprogram manager140 and/or thecommunications network220. Through the communications network220 (FIG. 2), theuser entity150 is capable of communicating with a remote device210 (e.g., a mobile device). Thecommunications interface156 may comprise various interfaces that are capable of communicating with electronic devices using various types of communications methods. Thecommunications interface156 may comprise amobile device interface310 that will allow cellular network communications between theuser entity150 and a mobile device. Thecommunications interface156 may also comprise acloud computing interface320 that is capable of facilitating communications between theuser entity150 and any device via a cloud network. Thecommunications interface156 may also comprise anInternet interface330 that provides for communications between theuser entity150 and any device via the Internet.
• Aprogram manager interface340 in thecommunications interface156 may provide for direct communications between theuser entity150 and theprogram manager140. In some embodiments, a private communications network may be set up between theprogram manager140 and theuser entity150. Anintranet interface350 in thecommunications interface156 provides for communications between theuser entity150 and an intranet network, such as a private network.
• Thecommunications interface156 may also comprise awireless interface360 and awired interface370. Thewireless interface360 provides for communications between theuser entity150 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. Thewired interface370 may provide for wired communications between theuser interface150 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 thecommunications interface156 may comprise other types of communications interfaces that provide for communications between theuser entity150 and other devices.
• Turning now toFIG. 4, a block diagram depiction of theprogram manager140 of the system100 (FIG. 1), in accordance with embodiments herein is presented. Theprogram manager140 may be an entity that interfaces with thecard issuing entity120, thecard processing unit130 and the user entity150 (FIG. 1) in order to facilitate transaction approval and automated funding of an expense card. In one embodiment, theprogram manager140 provides for controlling financial transactions and/or approvals of financial transactions between auser entity150 and acard processor130. In one embodiment, theprogram manager140 may interface with theadministrator154 of theuser entity150 for providing control over a card program that provides for automated approval and funding of expense cards.
• Theprogram manager140 may comprise a payment set-upunit410, aninstitution association unit420, acard assignment unit430, agroup management unit440, auser interface unit450, afunding unit460, adatabase unit470, and aprogram manager interface480. The units410-480 of theprogram manager140 may be comprised of hardware modules, software modules, and/or firmware modules.
• Theuser interface unit450 may provide for communications between theprogram manager140 and theuser entity150, and more specifically, theadministrator154 and a user of an expense card. The payment set-upunit410 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-upunit410. The payment set-upunit410 is capable of receiving predetermined rules from thecard processor130, the cardissuing unit entity120, and/or theuser entity150. 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.
• Theinstitution association unit420 of theprogram manager140 may provide for associating an expense card payment method to a particular financial institution, such as the card issuing entity120 (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 thecard issuing entity120. Theinstitution association unit420 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 theinstitution association unit420, is provided in Appendix B.
• Thecard assignment unit430, along with theprogram manager140 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. Thecard assignment unit430 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.
• Thegroup management unit440 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. Thegroup management unit440 may also allow for adding or deleting individuals from a particular expense group.
• Thefunding unit460 of theprogram manager140 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, thefunding unit460 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, thefunding unit460 may prompt movement of funds from a master account to a group account, wherein another entity such as the group manager, may prompt thefunding unit460 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.
• Thedatabase470 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. Thedatabase470 may hold information with regard to theuser entity150, theadministrator154, thecard holder152, etc. Thedatabase470 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 theprogram manager140, theuser entity150, thecard processor130, thecard issuing entity120, and/or thecard originator110. Thedatabase470 may store information utilized by the various units410-460 of theprogram manager140. In some embodiments,database470 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 toFIG. 5, a more detailed stylized block diagram depiction of theuser entity150, in accordance with some embodiments, is presented. As illustrated inFIG. 5, thecommunication interface156 may communicate with thetransaction trigger unit160, thecommunication network220, as well as with theprogram manager140.
• Various types of data may be sent and/or received by theuser entity150 via thecommunications interface156. Thecardholder unit152, which may comprise a request unit510 (described below), may provide request-information to thenotification unit160, which may process the request and provide notification information to thecommunications interface160.
• Thecard holder unit152 described above may comprise arequest unit510. Therequest unit510 may be capable of processing a request received from a user via thecommunications network220 and/or theprogram manager140. Therequest unit510 is capable of providing feedback based on a request for funding. Therequest unit510 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 therequest unit510 and other data from thecard holder unit152 may be provided to theapproval unit520. The approval unit52.0 may be capable of making a determination whether to approve a request for funds. Theapproval unit520 may be configured to perform various checks (rules test, threshold test, event test, etc.) prior to approving a request for funds. Theapproval unit520 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, theuser entity150 may comprise anapproval protocol module530 that is capable of providing indications to theapproval unit520 for determining whether to approve or deny a request for funding. Theapproval protocol module530 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, theapproval unit520 may also interface with theadministrator154 in order to determine whether a request should be approved or denied. For example, theadministrator154 may comprise anaccounting unit540. Theaccounting unit540 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, theapproval unit520 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 theaccounting unit540 provides information indicating there is a lack of funds in the master account, theapproval unit520 may reject the request. Further, theapproval unit520 may provide a reason for the rejection and an invitation to either modify the request or attempt the request at a later time.
• Theuser entity150 may also comprise afunds transfer unit550. The funds transferunit550 may be in communication with theadministrator154 as well as theapproval unit520. Based upon an approval provided for funding, thefund transfer unit550 may perform a fund transfer process in order to transfer funds to thecard holder unit152. The funds transferunit550 may receive instructions from theadministrator154 to perform a fund transfer transaction. Thefund transfer unit550 may also provide information to theapproval unit520 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, theapproval unit520 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 inFIG. 5, a plurality of types of transactions may be triggered by thetransaction trigger unit160. In embodiment, thetransaction trigger unit160 may receive user data from thecardholder unit152. This data may include information as one or more activity of the user of a card. This data may be used by thetransaction trigger unit160 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 thetransaction trigger unit160. However, prior to performing this transaction, additional checks, such as a check with an approval protocol from theapproval protocol module530 may be made. Theapproval protocol module530 and theapproval unit520 may provide an approval to perform the triggered transaction to thetransaction trigger unit160.
• Upon receiving approval to perform the triggered transaction, thetransaction trigger unit160 may communicate with theaccounting unit540 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, thetransaction trigger unit160 may prompt thefund transfer unit550 to provide the funds to satisfy the triggered transaction. Upon performing the transaction, thetransaction trigger unit160 may notify various entities of the transaction via thecommunications interface156.
• The various portions of theuser entity150 may be automated using one or more computing devices comprising hardware, software, and/or firmware modules. Further, the various portions of theuser entity150 illustrated inFIG. 5, may be comprised of hardware, firmware, and/or software modules.
• Turning now toFIG. 6, a stylized block diagram depiction of thetransaction trigger unit160 ofFIG. 1, in accordance to embodiments herein is illustrated. Thetransaction trigger unit160 comprises an auto-fund criteria unit610, auser input unit620, a triggerevent detection unit630, athreshold detection unit640, and afunding trigger unit650.
• The auto-fund criteria unit610 may comprise various rules, thresholds, trigger points, etc., that may prompt thetransaction trigger unit160 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, thefunding trigger unit650 may prompt the funding of the transaction. That is, thefunding trigger unit650 is capable of causing theuser entity150 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 unit610, theuser input unit620, the triggerevent detection unit630, and/or thethreshold detection640.
• In one embodiment, theuser input unit620 may scan for user data that may be used to determine whether or not to trigger a particular transaction. For example, theuser input unit620 may scan for user activity, e.g., email, reporting of a user activity requiring funding, user schedule indications, etc. Alternatively, theuser input unit620 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 triggerevent detection unit630 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 triggerevent detection unit630 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 unit610. Any number of events may be programmed such that they could cause the triggering of a transaction.
• Thethreshold detection unit640 may scan for one or more data sets that may be compared to (predetermined corresponding threshold. Based upon this threshold, thethreshold detection unit640 may determine that a threshold-triggering circumstance has occurred, in light of the rules and threshold of the auto-fund criteria unit610. 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 unit610.
• Data from one or more of theuser input unit620, the triggerevent detection unit630 and/or thethreshold detection unit640 may be used by the auto-find criteria unit610 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, thefunding trigger unit650 may prompt the execution of the trigger, e.g., providing funding as prescribed by the rules and thresholds.
• Turning now toFIG. 7, a flowchart depiction of a funds flow process, in accordance with embodiments herein, is illustrated. In one embodiment, theprogram manager140 may interface with a client operating account to the user entity150 (block710). In one embodiment, this interaction may be prompted by theuser entity150 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, thecard issuing entity120, such as a bank, may interact with theuser entity150 via aprogram manager140. The interfacing of theprogram manager140 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 (block720). 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 entity120 (e.g., a bank) to send funds to the card processor (block730). The prompting of thecard issuing entity120 may be performed by theprogram manager140. The transfer of the funds to thecard processor130 may be performed under the direction of the card originator via theprogram manager130.
• A virtual card account, e,g., a client master account, may be credited upon funding (block740). The client master account may be part of thecard holder unit152 of theuser entity150. Once a virtual card account is funded, automated transfer of funds to and from user cards may be allowed (block750). 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 theuser entity150. 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 toFIG. 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 (block810). 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 (block820). In some embodiments, the transaction schedule may be stored locally (e.g., within the user entity150), or at a remote location (e.g., the remote unit210). 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, theuser entity150 may monitor one or more activities (block840). 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. Theuser entity150 may make a determination that an activity that may be relevant to one or more transactions has been detected (block840). If no such activity is detected, the process reverts back to block830, wherein activity is further monitored.
• If a relevant activity is detected, an activity-trigger analysis is performed (block850). 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 inFIG. 7, and accompanying description below. Based upon the activity-trigger analysis, if an activity is triggered, theuser entity150 may initiate the triggered activity (block860). A more detailed description of initiating the triggered activity is provided inFIG. 10 and accompanying description below.
• Turning now toFIG. 9, a flowchart depiction of performing the activity-trigger analysis ofFIG. 8, in accordance with some embodiments herein. Theuser entity150 may receive activity data that may be used to perform the activity-trigger analysis (block910). 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, theuser entity910 maybe may receive activity data by polling via thecommunications interface156 to determine if such data have been sent by one or more modules in thesystem100. In other embodiments, theuser entity910 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 theuser entity910. 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, theuser entity910 may determine whether the activity data relates to predetermined rules and/or thresholds (block920). 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, theuser entity150 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 (block930).
• Upon applying the rules to the activity data, several checks or determinations may be performed. These checks (block942-948) may be performed simultaneously, i.e., in parallel, or alternatively, in a serial fashion. For example, theuser entity150 may determine whether the activity indicated by the activity data has been completed based upon rules corresponding to the activity data (block942). 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 (block944). 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 theuser entity150 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 (block946). For example, theuser entity150 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 theuser entity150 is an inquiry to determine whether a threshold has been crossed (block948). 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 blocks942-948 indicate in the negative, no corrective action, such as no auto-replenishing of the account, is taken (block950). Theuser entity150 may then continue pulling or pushing for activity data. Upon determining that the queries of blocks942-946 indicate in the affirmative, a transaction trigger (e.g., replenishment trigger) may be initiated (block950).
• Turning now toFIG. 10, a flowchart depiction of the method of initiating a triggered transaction ofFIG. 8, in accordance with embodiments herein. A trigger signal is received indicating that a particular transaction may be performed (block1010). A determination is made as to whether the trigger has been activated (i.e., whether the transaction has been initiated) (block1020). If the trigger has not been activated, the corresponding transaction is not performed (block1030). 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 (block1040). 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 (block1050). For example, upon triggering a replenishing transaction, the replenish process may be performed. A more detailed description of performing the triggered transaction ofFIG. 10 is provided inFIG. 11 and accompanying description below.
• Turning now toFIG. 11, a flowchart depiction of the method of performing a triggered transaction ofFIG. 8, in accordance with embodiments herein. Information relating to the type of transaction to be performed is received (block1110). 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 (block1120). 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) (block1030).
• 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 (block1140). A determination whether the master account has been sufficiently updated for the transaction is subsequently made (block1150). If the master account has been sufficiently updated for the transaction, the transaction is performed (path fromblock1150 to block1130). If the master account has not been sufficiently updated for the transaction, the transaction is not performed (e.g., no auto-replenishment) (block1160). In this manner, an automated triggering of a transaction is performed in accordance with embodiments herein.
• The methods depicted inFIGS. 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 inFIGS. 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 (21)

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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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

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

10. The non-transitory computer readable program storage unit ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 14, wherein said triggering unit is further 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 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 ofclaim 15, wherein said card issuing entity is a bank.

17. The system ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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.

Images