METHOD, APPARATUS AND SYSTEM FOR AUTOMATED NOTIFICATION OF FUNDING REQUEST AND/OR APPROVAL

Abstract

Embodiments herein provide for performing notification function relating to an automated transaction. A request for funding is received. A request processing is performed in response to the request. The request processing comprises routing the request to an approval unit, determining by the approval unit that the funding is authorized, and determining that sufficient amount of funds are available for providing the funding. The funding is either approved or denied the funding based upon the request processing.

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 notifications of funding requests, approval, and or changes to approval or funding status.

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.

Further, when a funding request is made, the person to whom the request is made may not immediately receive the request, particularly if the person is at a remote location. Moreover, when the request is approved, the sender of the request may not appreciate that the request has been approved. Still further, prior to approving the funding, a counter-request to change one or more aspects of the funding may be made. In such a case, if the person making the funding request does not promptly receive the request for change, further delays in the funding approval may occur. Moreover, the manual approval and change-request may cause delays, which may interfere in efficient execution of various tasks and/or travel performed by an employee or agent.

SUMMARY OF EMBODIMENTS

Generally, the present disclosure is directed to various methods, apparatus and system for performing notification function relating to an automated transaction. A request for funding is received. A recipient of the request is determined. A request communications process is performed in response to the request. The request communication process comprising providing an automated notification to the recipient of the request.

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 flowchart depiction of a process of performing a funds flow process, in accordance with some embodiments of the present disclosure;

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

FIG. 8 illustrates a flowchart depiction of a request process of FIG. 7, in accordance with some embodiments of the present disclosure;

FIG. 9 illustrates a request communication process of FIG. 8, in accordance with some embodiments of the present disclosure; and

FIG. 10 illustrates flowchart depiction of a method of performing the request processing step of FIG. 8, in accordance with some embodiments herein.

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 automated notification of a request and approval of funds to an entity within an organization. For example, using a mobile device comprising a mobile application, automated notification and management of approval or rejection of a request for funds may be performed. A first notification to the receiver of the request may be automatically sent. The message may include a text message, an email message, a message via a social network system, an alarm, a chat room message, and/or the like. A second notification back to the sender may indicate an approval of the request. A third notification back to the sender may indicate a funding of the request. A fourth request back to the sender may indicate a counter-request to change one or more aspects of the original request, e.g., the amount requested, the timing of funding, the project to which the funding should be directed, etc.

In some embodiments, a request for funding may cause the generation of a notification that is sent to an automated system that may use predetermined rules to automatically approve or disapprove the request. Additionally, the same notification and/or another notification may then be sent to a person to inform that person of the request and/or the approval of the request. Further, a notification that requests a modification to the original request may be sent back to the sender of the original notification.

In some embodiments, a module, such as a mobile application, may interact with a module at a central location (e.g., a server) within an organization to control the request, notification, approval or rejection of requested distribution of funds, for example, to be used by employees during travel on behalf of the organization. The automated management of funds provided by the embodiments herein may be allocated based on predetermined rules implemented by an organization, such as an end-user of a large funds transaction system, to perform automated expense management.

The notification process provided by embodiments herein provide for increasing efficiency in automating the process or controls necessary for an organization to distribute funds to employees in the field, while reducing the amount of paper forms and manual movement of the forms between resources. The notifications descried herein provide for increasing the efficiency of performing a real time or near real time processing a funds request, wherein the processing may include at least one of distribution of the funds, denial of the funds, and/or a request to modify and resubmit the request. The notifications of embodiments herein provide for more efficiently, automatically monitoring and applying funds to a spendable account, such as a debit card, a credit card, and the like, based upon rules established by users of the automation process.

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

In some embodiments, the disclosure provides 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 and distribution of funds within a workflow of an organization, such as a corporation. The notifications may be made via a variety of media, such as text messaging, email messages, social network venues, chat applications, paging applications, and/or the like.

Turning now to FIG. 1, a block diagram depiction of a funds management system for providing or automating request, notification, and approval of funding, 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 funding for an expense and receive automated approval, in some embodiments, in real time or near real time. In some embodiments, the approval may be provided manually and in other embodiments, the approval may be provided automatically. The approval may be provided automatically based upon rules-based, threshold-based, and/or event-based scenarios.

The 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 notification unit 160, a card holder unit 152 and an administrator 154. The notification unit 160 may utilize a remote-device communication application to provide various automated notifications. These notifications may include notifying a recipient of a request for funding, notifying the sender of the request of a counter-request for modifying the original notification, notifying the sender and/or other entities of an approval, and/or notifying an automated system of a request, which may be automatically processed. The notification unit 160 is described in further details 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 sonic 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 may comprise various hardware, firmware and/or software modules that provide for digital and/or analog 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 notification unit 160 of the user entity 150 may also be coupled to the communications interface 156. The various notifications described herein may be provided to one or more remote units 210 via the communications interface 156. Moreover, notifications in the opposite direction, e.g., notification of a counter-request to modify an original request) may be received by the notification unit 160 and forwarded to the original sender (e.g., user of the user entity 150).

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 tier 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 notification unit 160, the communication network 220, as well as with the program manager 140.

Various notifications may be sent and/or received by the user entity 150 via the communications interface 156. For example, notification of a request may be sent to another entity (e.g., remote unit 210) via the communications interface 156 in response to an initiation of a funding request by a user. 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.

Moreover, a counter-request to modify an original request may be received by the notification unit 160 via the communications interface 156. Further, an approval of a funding request may be received by the user entity 150. This notification may then be processed and correlated with an appropriate request notification. Information regarding this correlation may be sent from the notification unit 160 to the approval unit 520 for approval processing and funding, as described below.

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 520 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. 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 notification unit of FIG. 1, in accordance to embodiments herein is illustrated. The notification unit 160 may comprise a remote application interface 610 to communicate with a plurality of remote devices. Communications between various modules of the notification unit 160 and modules external to the notification unit 160 may be facilitated by the remote application interface 610. The notification unit 160 may also comprise a request message unit 620, a request modification message unit 630, an approval message unit 640, and an auto approval unit 650.

The request message unit 610 is capable of generating a notification of a funding request upon determining that a user has made such a request. The notification may be of one of a number of predetermined types of message that may comprise one or more parameters that convey various types of information. For example, the notification may be message that indicates a low funding request, a medium funding request, or a high funding request. Further, the notification may indicate the category of funding, such as high-priority funding, medium-priority funding, or low-funding priority (as compared to a predetermined reference value).

Further, the notification may be indicative of the source of funding, such as a low-level employee, a management-level employee, or an executive-level employee. Other types of information, such as the urgency of the request, the priority-level of the project relating to the request, etc. may also be conveyed in the message. Those skilled in the art having benefit of the present disclosure may implement a variety of parameters that convey other types of information. These details of the notification may be used by the receiver of the request to prioritize, approve, modify, or deny the request.

Further, the request message unit 620 may also determine the identity of the recipient(s) of the notification based upon the request. In one embodiment, based upon various details relating to the request, the request message unit 620 may determine which entities to route the request. For example, based upon one or more factors (e.g., the priority level of the request, the amount of the request, and/or the level of the person initiating the request) the request message unit 620 may select one or more predetermined recipients of the notification relating to the request. The recipient may be a person, an application, and/or a device that may automatically assess, approve, deny or provide a counter-request for modification of the original request.

The request modification message unit 630 is capable of providing a notification of a counter-request for modifying an earlier request for funding. For example, the recipient of a funding request may determine that the request cannot be approved in its current state. The recipient, which may be a person, software module, firmware module, and/or a hardware module, may determine that the request has one or more issues that need to be resolved (e.g., the amount requested is excessive, the timing of the request is improper, the request need further authentication or acknowledgement from a manager, etc.). In this case, the request modification message unit 630 may provide a counter-request to modify the request. The request modification message unit 630 is capable of receiving the counter-request, deciphering the message within, and determining which entity to forward the counter-request. The request modification message unit 630 may then forward to the counter-request comprising the instructions/requests for modification of the earlier request.

The approval message unit 640 is capable of receiving and interpreting an approval of a request. The approval message unit 640 may correlate a received approval to a particular request and to a particular recipient. In this manner, the approval is provided to the requestor. The approval may be received from a person or an automated entity. The approval notification may be sent to the remote device of a user.

The auto-approval unit 650 is configured to provide a notification of a request to an automatic approval entity to prompt a response. This notification may be placed into a predetermined format using information provided by the entity making the request. The response may be approval, a request to modify the request, or a denial of the request. The auto-approval unit 650 is capable of detecting a request, determining one or more characteristic(s) of the request, and directing a notification of the request to an appropriate automatic approval entity based upon the characteristic(s). The notification to the automatic approval entity may be of a format that conveys the amount requested, the source of the request, the priority to be placed on the request, etc. For example, a notification of a request for funding may be sent to the approval unit 520 (FIG. 5) for auto approval. Upon receiving an automated approval, the auto-approval unit 650 may provide a notification to the user that the request has been approved. For example, based upon the actions of the auto-approval unit 650 with regard to auto-approval of a request, a user may quickly receive a response regarding the request via a mobile phone.

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 for performing a funds request notification process, in accordance with some embodiments herein, is illustrated.

The user entity 150 may receive a request for funds from a user (block 810). The user may have prior instructions as to the appropriate procedures for requesting funds. For example, the user may be under a direction to request funds only when traveling on behalf of the user entity 150, or spending funds on behalf of the user entity 150. Other examples may include threshold requirements, such as a requirement for funds greater than a predetermined amount.

Upon receiving a funds request, a request communication process may be performed (block 820). A more detailed description of the step of performing the request communication process is provided in FIG. 9 and accompanying description below. Continuing referring to FIG. 8, the request communication process may include providing an automated notification of the request. In some embodiments, a number of requests may be received substantially simultaneously. In this case, the request may be categorized and correlated to appropriate requests or projects. This process may include providing an automated notification to the recipient (block 822). The target of the request and other data relating to the request may be determined, and based upon this determination; information relating to the request is appropriately distributed. The request communication process may also include receiving a message from the recipient of the request (block 824). This message may be a message or approval, denial, or a request to modify the request.

After a request has been made and a message is received in response, a determination may be made as to whether the request was approved (block 840). In this case, the approval unit 520 may provide approval data to the approval protocol module 530 for performing the approval process. Upon determining that the request has been approved, the request may be processed (block 850). A more detailed description of the step of performing the processing of the request is provided in FIG. 10 and accompanying description below.

Upon processing the request, a notice of the processing may be provided (block 855). The notice of processed request may be sent to the requestor as well as to other parties, such as the supervisor of the requestor, the person overseeing the approval process, an accounting personal, and/or to other persons interested in the transaction. These notices may be sent automatically to one or more devices, such as a mobile device.

In the event the request is not approved (block 840), a determination may be made as to whether a change to the request has been prompted (block 860). For example, if a manual or automated comparison of the amount requested is made to a predetermined limit and it's found that the requested amount exceeds the predetermined limit, a counter-request for a change in the amount of the request may be made. If a request has not been approved and a change-request (i.e., counter-request) is not made, a determination may be made that the request has been denied (block 865). Further, the denial of the request may be noticed to various entities, for example as described above.

If a determination is made that the request was not approved (block 840) and a change to the request was prompted, an automated notification may be sent to the user/requestor indicating the type of changes that are being requested (block 870). The user/requestor may receive this notice automatically at one or more locations, such as on a mobile device. This may provide for prompt attention by the requestor for efficient completion of the transaction.

Subsequently, a modified request may be received from the requestor/user (block 880). In some embodiment, if a modified request is not received within a predetermined time period, an automatic denial of the request is issued, along with a notification of the denial. Upon receiving the modified request from the requestor, the process may move to block 820 for performing a request communication process, as described above.

Turning now to FIG. 9, a more detailed flowchart of the step of performing the request communication process of FIG. 8, in accordance with embodiments herein is provided. Based upon detecting a transaction request (e.g., request for funding), a look up function may be performed to look up the target recipient for delivering an automated notification of the receipt (block 910). The recipient target lookup may be based upon one or more parameters associated with the request, such as requestor name, requestor status, amount of request, reason for the request, recipient name, and/or the like.

Upon selecting the target recipient, the type of notification to be sent may be selected (block 920). The type of notification to be sent may be based upon the one or more factors regarding the recipient, such as name of the recipient, preferences indicated by the recipient, urgency of the request, amount of the request, etc. Upon selecting the notification type, the notice of the request may be sent to the recipient of the request (block 930).

A responsive message from the recipient may be automatically or manually received. The message from the recipient may be interpreted to determine the content of the message (block 940). This function may be made in a variety of manners, such a performing a look up function to decipher the message. For example, the message provided by the recipient may be coded, wherein the coded signal may be used to perform a lookup function to decipher the corresponding meanings of the codes. Deciphering or interpreting the message from the recipient, which may be a person or an automated device, may be performed automatically by a device that comprises a software module, hardware module, firmware module, and/or any combination thereof.

Upon deciphering the message from the recipient, a determination may be made as to whether an approval message was received (block 950). If an approval message was received, in one embodiment, an automatic approval may be provided (block 960). If a determination is made that an approval message was not been received, a determination may be made as to whether a counter-request to modify the request is provided (block 970). If a determination is made that a counter-request to modify the request is provided, an indication that a change is requested is made (block 980), otherwise an indication that the request may be denied is provided (990).

Turning now to FIG. 10, a flowchart depiction of a method of performing the request processing step (block 850, FIG. 8), in accordance with some embodiments, is illustrated. Upon receiving a request for funds from a user, the request may be routed from the card holder to an entity responsible for making one or more decisions with regard to the request (block 1010). In some embodiments, a plurality of card holders may be grouped together. This group may be monitored by a group manager who may be in charge of approving, denying or modifying a request. In one embodiment, the group manager may be a person who manually makes a decision and provides a response via a computing system. In another embodiment, the group manager may be a hardware module, a software module, a firmware module, or a combination thereof, that may be programmed or configured to perform automated tasks of a group manager. The automated tasks of the group manager may include approving a request, denying a request, requesting a modification, and/or sending notifications of the approvals, denials, or request for modifications. In this manner, the entire process of evaluating, modifying and/or approving or denying a request may be performed automatically in real time or in near real time by a computing system.

Once a funds request is routed to an appropriate entity, such as a group manager, an approval process may be performed (block 1020). The approval process may comprise checking one or more rules, thresholds or events to determine whether the requested funds should be approved. In some embodiments, the approval unit 520 in conjunction with the approval protocol module 530 (FIG. 5) may check various rules, thresholds or events to determine if appropriate to approve the requested funds. One example of a GUI for approving requested funds is provided in Appendix E, as described above.

Upon performing the approval process, a determination may be made as to whether approval of the funds requested has been granted (block 1030). If the approval has not been granted, a rejection process step is performed (block 1060). A rejection processing step may comprise providing a notification of a rejection and/or checking for various contingencies. A more detailed description of the rejection processing is provided in FIG. 9 and accompanying description below.

Continuing referring to FIG. 10, upon a determination that the approval has been granted in block 1030, a determination is made whether sufficient funds in an account capable of funding the request, is available (block 1040). For example, a determination may be made as to whether a client master account, which may hold an amount that is used to distribute thuds in response to funds requests, has sufficient funds to fulfill the request. Upon a determination that sufficient funds in the client master account or equivalent account is found, the amount requested may be transferred to the requestor's expense card (block 1050). As described above, the fund flow process described in FIG. 6 may be implemented to perform the transfer of the funds to the expense card.

Referring back to block 1040, upon a determination that sufficient funds in the master account is not found, a request may be made for replenishing the master account (block 1070). Various checks and balances may be implemented, which may manually or automatically determine whether to grant a replenishment of a master account, The checks and balances may include determining whether the entity making the request for replenishment is indeed authorized to make such a request. Further, the checks and balances may include sufficient funding has been authorized to provide the replenishment of the master account.

After a request for replenishment of the master account has been made (see block 1070), a determination is may be made as to whether the master account has been sufficiently replenished (block 1080). Upon a determination that sufficient amount has been replenished into the master account, the step of transferring the requested amount to the expense card may be performed, as indicated by the connection between block 1080 and block 1050. Upon a determination that the master account has not been sufficiently replenished, a denial of request may be issued (block 1090). In alternative embodiments, a further message may be sent to the user indicating that current master account finds are insufficient and a later request may be made.

The methods depicted in FIGS. 7-10 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-10 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

1. A method for performing a transaction, comprising:

receiving a request for funding;

determining a recipient of said request; and

providing an automated notification to said recipient of said request.

2. The method of claim 1, further comprising providing, based upon said request, an automated reply indicating at least one of approving said funding, requesting modification of said request, or denying said funding.

3. The method of claim 1, wherein determining said recipient of said request comprises determining at least one of a funding amount associated with said request, an identity of said request, a group identification associated with said request, a timing period of funding associated with said request.

4. The method of claim 1, wherein providing said automated notification to a recipient comprises providing at least one of a text message, an email, a page, or a social networking message regarding said request.

5. The method of claim 1, further comprising providing at least one of an approval of said request, a prompt to modify said request, or a rejection of said request based upon a reply to said automated notification.

6. The method of claim 5, wherein providing said prompt to modify said request comprises providing a prompt to modify at least one of the amount requested, the time period of funding, or the project of funding.

7. 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 request for funding;

determining a recipient of said request; and

performing a request communications process in response to said request, said request communication process comprising providing an automated notification to said recipient of said request.

8. The non-transitory computer readable program storage unit of claim 7, wherein said request communications process further comprising providing, based upon said request, an automated reply indicating at least one of approving said funding, requesting modification of said request, or denying said funding.

9. The non-transitory computer readable program storage unit of claim 7, wherein determining said recipient of said request comprises determining at least one of a funding amount associated with said request, an identity of said request, a group identification associated with said request, a timing period of funding associated with said request.

10. The non-transitory computer readable program storage unit of claim 7, wherein providing said automated notification to a recipient comprises providing at least one of a text message, an email, a page, or a social networking message regarding said request.

11. The non-transitory computer readable program storage unit of claim 7, further comprising providing at least one of an approval of said request, a prompt to modify said request, or a rejection of said request based upon a reply to said automated notification.

12. The non-transitory computer readable program storage unit of claim 11, wherein providing said prompt to modify said request comprises providing a prompt to modify at least one of the amount requested, the time period of funding, or the project of funding.

13. An apparatus for performing a transaction, comprising:

a request unit for providing a request for funding; and

a notification unit configured for determining a recipient of said request and performing a request communications process in response to said request, said request communication process comprising providing an automated notification to said recipient of said request;

14. The apparatus of claim 13, further comprising

a funding unit for providing a reply to said recipient indicating at least one of approving said funding or denying said funding, based upon said request; and

a communications unit for forwarding said automated notification to a remote device.

15. The apparatus of claim 13, wherein said notification unit is further configured to perform at least one of an automated response to said request or a manual response to said request, wherein said automated response comprises:

forwarding said request;

receiving a response from said recipient;

determining whether said response is a message indicating an approval of said request, a prompt to modify said request, or a denial of said request; and

providing said indicating said approval, said prompt, or said denial of said request to a user of said request unit.

16. The apparatus of claim 13, wherein said notification unit comprises:

a remote application interface for interfacing with an application on a remote device;

a request message unit operatively coupled to said remote application interface, said request message unit to receive and process said request;

a request modification unit operatively coupled to said remote application interface, said request modification unit to provide a prompt for modifying said request;

an approval message unit operatively coupled to said remote application interface, said approval message unit to provide an approval message and an automated funding in response to said request; and

an auto approval unit operatively coupled to said remote application interface, said auto approval unit to provide an automated approval of said request.

17. 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 user entity in communication with said program manager and said remote unit, said user entity comprising:

a notification unit for performing a request communications process in response to said request, said request communication process comprising providing an automated notification to a recipient of said request and performing at least one of receiving a message from said recipient indicating at least one of approving said funding or denying said funding, based upon said request processing; and

a funding unit for providing a reply to said recipient indicating at least one of approving said funding or denying said funding, based upon said request.

18. The system of claim 17, wherein said card issuing entity is a bank.

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

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

21. The system of claim 17, wherein said program manager 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 with at least said user entity and a communications network.

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

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