Patent Application
20210311788
The present disclosure embraces a system and methods for processing, authorization, and automation of resource requests and resource transfer.
Current solutions for processing resource requests, particularly in the context of entity resource requests, do not embrace most efficient methods and systems for processing and automation. As such, there is a need for solutions that implement most efficient methods of resource transfer in the context of entity resource requests.
The following presents a simplified summary of one or more embodiments of the invention in order to provide a basic understanding of such embodiments. This summary is not an extensive overview of all contemplated embodiments, and is intended to neither identify key or critical elements of all embodiments, nor delineate the scope of any or all embodiments. Its sole purpose is to present some concepts of one or more embodiments in a simplified form as a prelude to the more detailed description that is presented later.
Resource requests in the context of entity expenses such as business expenses and reimbursements are typically processed for resource transfer using traditional methods such as paper checks. In light of development of more efficient resource transfer technologies and payment rails, there is a clear need for innovative solutions for automating and more efficiently executing resource transfers and entity resource transfer reimbursements. The present invention embraces efficient resource transfer technologies to create an automated resource transfer loop that integrates modern invoicing systems for payment of resources in a business resource expense context. Such solutions automate the process for users of the system saving users time, increases efficiency, reliability, tracking ability, and accuracy, and reduces the amount of time between the point at which resource requests are generated and received, and the point at which resources are disbursed and accounted for. In addition, by nature of automating the described processes in a completely digital approach, the invention provides accessible and reliable historic data trail for optimizing response times and accuracy of information in situations where such information may be required from a regulator, auditor, and the like.
For instance, in some embodiments, use cases might involve executive repayment of resource requests, such as resource requests related to travel expenses, lodging expenses, development expenses and the like. The system may provide an interface wherein a requesting entity or the user (e.g., executive or employee of an entity), may submit a request for resource disbursement. The system may receive such resource requests directly from requesting entities or users in electronic form, allowing the system to analyze, and review the resource request for disbursement qualifications. One or more messages or metadata may be generated in association with the resource request in order to request additional information or inform the requesting entity or user of disbursement qualification details and decisions. The system may determine routing of messages and generate a user interface display for direct resource disbursement review by the requesting entity or user, or user administrator of the system. The system may process the resource transfer for disbursement of resources using one or more resource transfer rails, and may integrate such processing with existing technologies for resource transfer.
In some embodiments, the system for processing and authorization of electronic resource requests via a resource platform generally may include at least one memory device with computer-readable program code stored thereon; at least one communication device; at least one processing device operatively coupled to the at least one memory device and the at least one communication device, wherein executing the computer-readable program code is configured to cause the at least one processing device to: receive electronic resource request data for an electronic resource request from the one or more entities; extract resource transfer metadata from the electronic resource request data; generate and store a user configuration for a user, wherein the user configuration comprises authorization preferences and selection of a digital channel for transmission of resource request data; transmit electronic resource request data to the user via the digital channel; receive soft user authorization of the electronic resource request data via the digital channel; transmit the soft user authorization to a second user for hard authentication based on the user configuration; receive hard authentication data from the second user for the electronic resource request data; perform confirmation, settlement, and reconciliation of the electronic resource request; and transmit a confirmation message to the one or more entities, wherein the confirmation message indicates confirmation, settlement, and reconciliation of the electronic resource request is complete.
In some embodiments, the communicable link for secure data transfer is established via an application programming interface.
In some embodiments, resource transfer metadata comprises one or multiple of a resource transfer type, a resource transfer purpose, an entity identification, itemized product or service cost information, a date, a time, geolocation data, a total resource amount, a resource type, user identification information, or resource account information.
In some embodiments, the digital channel further comprises a communication channel such as a web portal, mobile application, email message, or a text message.
In some embodiments, the system is further configured to convert the electronic resource request data to a format compatible with the digital channel.
In some embodiments, authorization preferences further comprise the identification of the second user for proxy authentication of electronic resource requests.
In some embodiments, the electronic resource request data transmitted to the user comprises a batch of multiple resource requests.
The features, functions, and advantages that have been discussed may be achieved independently in various embodiments of the present invention or may be combined with yet other embodiments, further details of which can be seen with reference to the following description and drawings.
Having thus described embodiments of the invention in general terms, reference will now be made to the accompanying drawings, wherein:
Embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all, embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to elements throughout. Where possible, any terms expressed in the singular form herein are meant to also include the plural form and vice versa, unless explicitly stated otherwise. Also, as used herein, the term “a” and/or “an” shall mean “one or more,” even though the phrase “one or more” is also used herein.
A “user” as used herein may refer to any customer of an entity or individual that interacts with an entity. The user may interact with the entity as a customer, such as a customer purchasing a product or service. Furthermore, as used herein the term “user device” or “mobile device” may refer to mobile phones, personal computing devices, tablet computers, wearable devices, and/or any portable electronic device capable of receiving and/or storing data therein.
As used herein, “resource platform” refers to the primary platform of the invention that is responsible for the device, processes, and methods of supporting and providing generation and analysis of real-time resource requests from one or more user accounts to other accounts, such as from entity accounts to merchant accounts, user accounts, vendor accounts, and the like. In some embodiments, the resource platform may be managed by the same entity that manages one or more user resource accounts, or may be managed by a separate entity in other embodiments. The resource platform is designed to operatively communicate with one or more entities, users, and systems over a network via one or more user devices or third party devices.
As used herein, an “third party system” may be a system managed by an entity other than the entity that manages the resource allocation platform. In other embodiments, the third party system may be a user device belonging to a user who is not associated with the resource allocation platform or vendor service systems, but has been granted access to a web portal, application, or other resource provide data or interface with the resource allocation platform or vender service systems. In some embodiments, an authorized third party device may refer to a device that has been previously identified as used by an authorized user for accessing the resource allocation platform resources.
As used herein, a “user interface” generally includes a plurality of interface devices and/or software that allow a customer to input commands and data to direct the processing device to execute instructions. For example, the user interface may include a graphical user interface (GUI) or an interface to input computer-executable instructions that direct the processing device to carry out specific functions. Input and output devices may include a display, mouse, keyboard, button, touchpad, touch screen, microphone, speaker, LED, light, joystick, switch, buzzer, bell, and/or other user input/output device for communicating with one or more users.
As used herein, the term “resource” may refer to physical currency, electronic data, or an exchangeable currency having a value (e.g., funds) or the like. A computing resource may refer to elements of one or more computing devices (e.g., processor, memory, communication device, and the like) networks, or the like available to be used in the execution of tasks or processes. A computing resource may be used to refer to available processing, memory, and/or network bandwidth and/or power of an individual computing device as well a plurality of computing devices that may operate as a collective for the execution of one or more tasks (e.g., one or more computing devices operating in unison). As used herein, a “resource vehicle” may refer to any medium for resource conveyance from one resource location to another. As used herein, a “resource transfer” may refer to a transfer of resources between accounts, such as the movement of funds or currency from one account to another via a crediting or debiting process. A “request” or “request for resource distribution” or “request for resource transfer” may refer to an invoice or request for payment of resources for goods, services, and the like. A “resource rail” may refer to a payment rail such as an automated clearinghouse (ACH) rail, real-time payment rail, a virtual or digital payment rail, a peer to peer payment rail, and the like.
As used herein, an “interaction” or “connection” may refer to any communication between one or more users or systems within the system environment described herein. For example, an interaction may refer to a transfer or exchange of user information (e.g., data, information, passwords, PIN codes, and the like) between systems, devices, and/or application; an accessing of stored data by one or more devices; a transmission of a requested task; a sharing or leveraging of resources (e.g., computing resources) between device; or the like. An interaction may include user interactions with a user interface (e.g., clicking, swiping, text or data entry, and the like), authentication actions (e.g., signing-in, username and password entry, PIN code, and the like), account actions (e.g., account access, and the like) and the like. In a specific embodiment, an “interaction” may refer to a resource transfer executed between one or more users and/or entities (e.g., a transaction).
As used herein, the term “entity” may be used to include any business or vendor system that the platform may interact with to complete a real-time resource request or resource distribution activity. The terms “financial institution” and “financial entity” may be used to include any organization that processes financial transactions including, but not limited to, banks, credit unions, savings and loan associations, investment companies, stock brokerages, insurance companies, and the like. In other embodiments, an entity may be a business, organization, a government organization or the like that is not a financial institution. In a specific embodiment, an entity is a resource providing entity such as a financial institution that provides a resource vehicle and/or service (e.g., finance associated account) to a user. The resource vehicle and/or location may include supplementary resources.
As used herein, “authentication information” may refer to any information that can be used to identify a user. For example, a system may prompt a user to enter authentication information such as a username, a password, a personal identification number (PIN), a passcode, biometric information (e.g., voice authentication, a fingerprint, and/or a retina scan), an answer to a security question, a unique intrinsic user activity, such as making a predefined motion with a user device. This authentication information may be used to at least partially authenticate the identity of the user (e.g., determine that the authentication information is associated with the account or particular user device) and determine that the user has authority to access a resource account, service, or system. In some embodiments, the system may be owned or operated by an entity. In such embodiments, the entity may employ additional computer systems, such as authentication servers, to validate and certify resources inputted by the plurality of users within the system.
As used herein, “web portal” may refer to a secure web site or web-accessible interface provided by the resource allocation platform to users, authorized third parties, and vendor service systems. In some embodiments, the web portal may be accessed via a provided user application on the user device or may be a secure web page accessible via a browser on a user device. In some embodiments, the web portal may used to display information from the application of the resource allocation platform, such as PIN codes, user resource account authorization information (e.g., username, password, account number, security questions, and the like). In specific embodiments, the web portal may be accessible only to users which have been granted access by the resource allocation platform or the vender service system, provided account information to the resource allocation platform, or set up an account with the resource allocation platform during an on-boarding process, and these specific users may be referred to as “on-boarded users.” In some embodiments, accessing the web portal or user application may require further authentication steps such as three-step authentication (e.g., via use of an authentication application, responding to an email link, and the like) biometric authentication (e.g., leveraging capability of the user device itself via biometric readers and processing), and the like
As illustrated in
The network 201 may be a system specific distributive network receiving and distributing specific network feeds and identifying specific network associated triggers. The network 201 may also be a global area network (GAN), such as the Internet, a wide area network (WAN), a local area network (LAN), public switched telephone network (PSTN), or any other type of network or combination of networks. The network 201 may provide for wireline, wireless, or a combination wireline and wireless communication between devices on the network 201.
In some embodiments, the user 202 is an individual or entity that has one or more user devices 204. The user 202 may be an employee of an entity. The user 202 may wish to complete a resource transaction with the third party system 208, or submit a resource request to the resource platform 206, which in some embodiments may be submitted via the entity systems 207. In some embodiments, the user 202 has a user device, such as a mobile phone, tablet, computer, or the like.
As further illustrated in
The processing device 248 is operatively coupled to the communication device 246 and the memory device 250. The processing device 248 uses the communication device 246 to communicate with the network 201 and other devices on the network 201, such as, but not limited to the third party system 208, the entity systems 207, and the user device 204. As such, the communication device 246 generally comprises a modem, server, or other device for communicating with other devices on the network 201.
As further illustrated in
In one embodiment of the resource allocation platform 206 the memory device 250 stores an application 258. In one embodiment of the invention, the application 258 may associate with applications having computer-executable program code. Furthermore, the resource allocation platform 206, using the processing device 248 codes certain communication functions described herein. In one embodiment, the computer-executable program code of an application associated with the application 258 may also instruct the processing device 248 to perform certain logic, data processing, and data storing functions of the application. The processing device 248 is configured to use the communication device 246 to communicate with and ascertain data from one or more third party system 208, entity systems 207, and/or user device 204.
As illustrated in
As illustrated in
It is understood that the servers, systems, and devices described herein illustrate one embodiment of the invention. It is further understood that one or more of the servers, systems, and devices can be combined in other embodiments and still function in the same or similar way as the embodiments described herein. The third party system 208 may generally include a processing device communicably coupled to devices as a memory device, output devices, input devices, a network interface, a power source, one or more chips, and the like. The third party system 208 may also include a memory device operatively coupled to the processing device. As used herein, memory may include any computer readable medium configured to store data, code, or other information. The memory device may include volatile memory, such as volatile Random Access Memory (RAM) including a cache area for the temporary storage of data. The memory device may also include non-volatile memory, which can be embedded and/or may be removable. The non-volatile memory may additionally or alternatively include an electrically erasable programmable read-only memory (EEPROM), flash memory or the like. The memory device may store any of a number of applications or programs which comprise computer-executable instructions/code executed by the processing device to implement the functions of the third party system 208 described herein.
Next, as shown in block 106, the system may submit the resource request information using an internal system message format, which in some embodiments may be an international organization for standardization (ISO) 20022 format. For instance, ISO 20022 is an ISO standard for electronic data interchange between financial institutions. It describes a metadata repository containing descriptions of messages and business processes, and a maintenance process for the repository content. Conversion of the resource request data and metadata to ISO 20022 or a similar industry standard internal format at this stage allows the information of the resource request to be quickly processed throughout the resource platform 207, and retains data and metadata in a manner that allows for cross compatibility and ease of integration of the resource platform with third party system 208. In some embodiments, the original resource request submission may contain data such as transaction identifiers, invoice numbers, uniform resource locator (URL) data, and the like which is converted to the internal standardized format of data and metadata for increased compatibility and ease of processing.
Next, at block 108, the system may make a determination of resource routing based on the resource request information, such as through an enterprise payments hub, or a resource payment orchestration system of the entity or resource platform. In doing so, the system may identify “on-us” recipients or senders of the resource request, or in other words, resource accounts associated with the resource request that may be located at or managed by the same entity that manages the resource platform. In other embodiments, the system may determine that the resource recipient of the resource request is “off-us,” or is not an account located at or managed by the entity that manages the resource platform. At this stage, the system may also determine a user for which the resource platform will route a detailed display of resource request information, as shown in block 110. The resource request information is then routed via a digital channel, as shown in block 112. The digital channel used in block 112 may differ based on user set preferences, entity preferences, or third party system preferences, and may include electronic notifications of many types, including, but not limited to, user resource management mobile applications, email messaging, SMS messaging, multimedia messaging, and the like. In some embodiments, block 112 may also involve an additional message conversion component, as the digital channel may likely have a different message format than the industry standard format used internally by the resource platform.
As shown in block 114, the digital channel may then display the resource request details. In some embodiments, the resource platform 206 may route resource request information on a periodic basis in batch format, wherein information for multiple resource requests may be forwarded via the digital channel. For instance, the system may route resource request information on a daily basis at a certain time of day, as determined by the resource platform or user preferences. In this embodiment, the digital channel may transmit and display information for multiple resource requests at one time, which the user may decide to complete, as shown in block 116. In some instances, the decision to complete resource requests may be a bifurcated process, wherein the user appoints or pre-authorizes another user for proxy review or approval of resource requests of an assistant or one or more other users pursuant to some simple indication from the user that one or more of the resource requests should be further reviewed and approved if possible. In some embodiments, the user may review and fully authorize the resource requests themselves. In other embodiments, some resource requests in a batch may be authorized, while others are not.
The process of authorizing resource requests may also include security measures implemented by the resource platform as well, such as the entering of a user password, a three way authentication mechanism (e.g., pre-shared key, transmission of authentication code to previously authenticated device associated with the user, transmission of a secure code to a secure digital address of the user such as an entity email address, and the like), biometric authentication, and the like. In embodiments where the user authorizes resource requests to be authenticated via proxy, the user may pre-authorize someone on the user's behalf to fully review and authorize distribution of resources for resource requests. For instance, a particular user may be enabled to reply to the resource platform with a simple “yes, authorize all,” or select, via the user interface of a user device, specific resource requests that the user would like to proceed with authorizing, which would then route the selected resource request details to the particular user's appointed or assigned proxy approval assistant for full review and authorization.
Next, as shown in block 118, the system routes the authorized resource request for execution, or the process of crediting or debiting the resource amount of the resource request to or from the designated accounts. In some embodiments, this step may again include conversion to an internal message language based on industry standard for such purposes, such as, but not limited to, PACS.008 extensible markup language (XML) routing format. In some embodiments, this may be done based on the digital channel formatted resource request information, or the system may refer back to the previous internal format ISO standard for easier and more detailed conversion (e.g., ISO internal standard format may contain additional metadata not transmitted in the digital channel message).
Next, as shown in block 120, the system performs the execution of the resource transfer based on the authorized resource request details, which is discussed further in regard to
Reconciliation may include an additional confirmation of data regarding one or more resource transfers, and may involve more detailed metadata that offers valuable insight to entities or third parties utilizing the resource platform. For instance, the system may conduct data analytics during the reconciliation process to determine a number of resource transfers in a given category, for a given purpose, for a specific user or group of users, for a specific geographical area, and the like. In some embodiments, this reconciliation process may offer valuable insight for which entity or third party system procedures may respond or adapt to. For instance, in some cases the reconciliation data may indicate that resources were heavily utilized by users located in one geographical area to frequently travel to a second geographical area. This data may indicate to the entity or resource platform that resource expenditure may be reduced by relocating such users to an office in the second geographical area. In another embodiment, the data may indicate that a certain group of users appears to prefer one method of travel to another, and the system may compare user data for the certain group of users to ascertain other common data points that may indicate an insightful trend. For instance, the certain group of users may all reside in a particular geographic area, and the entity may use this data to predict that users from that geographic area may tend to prefer a specific means of travel, and may adapt to be more proactively accommodating to perceived regional preference.
Next, as shown in block 304, the resource platform then extracts resource transfer metadata from the electronic resource request, as shown in block 304. Metadata extracted from the resource request may include, but is not limited to, transaction type, transaction purpose, merchant identification information, itemized product or service cost information, date, time, geolocation data, resource amount, resource type or currency, user identification information, resource account information (e.g., source or destination account information), routing information, preferred resource transfer rail information, and the like. The resource platform may perform conversion of the electronic resource request data to an industry standard resource messaging format used by the resource platform. As discussed, in some embodiments, this may include ISO 20022 standard formatting, but it is understood that the standard formatting could be adapted based on advances in technology or industry standard, widespread adoption of a different standard, a need for a different standard by a third party entity that utilizes the resource platform, and the like. It is understood that the conversion would ideally be completed in such a manner as to retail all metadata transaction details for the resource request, and may even provide greater functionality for additional metadata to be appended. Once the resource request data has been converted, the system determines resource request authorization routing information, as shown in block 308, based on resource platform hub instructions. The authorization routing information may comprise identification of one or more users and a selection of a digital channel for transmitting the resource request information.
As shown in block 306, the resource platform may generate and store a user configuration for a user, wherein the user configuration comprises authorization credentials and preferences for resource request routing via digital channels. The user configuration may contain authorization details as dictated by an entity such as an employer, such as the ability to authorize resource requests up to a certain amount, at a given frequency, or for a limited number of categories of goods and services (e.g., a user who is a top executive of an entity may have the authority to charter a private jet, whereas a user who is a VP may be limited to authorizing resource requests for smaller items such as company dinners, and the like). The user configuration may also contain other preference based information as set by the user or an entity protocol or administrator, such as the preferred digital channel for which resource requests should be submitted, and transmitted for authorization and approval (e.g., an executive may prefer to receive resource requests in daily or weekly batches via email to their work email address, or an entity may dictate that resource requests may only be transmitted via secure web portal or user device application, and the like). As shown in block 308, the user configuration may also contain authorization proxy information. In some embodiments, review and authorization of resource requests may be handled in split manner, wherein multiple users actually operate to provide full authorization. For instance, while a user may be able to provide indication that the user would like to approve a resource request, entity policy or industry regulation, best practice, and the like may not allow for fully secure authentication of the resource request on the chosen digital channel (e.g., the user approves resource requests by responding “yes” to a text message, without authenticating their identity). In these instances, the decision to complete resource requests may be a bifurcated process, wherein the user appoints or pre-authorizes another user for proxy review or approval of resource requests of an assistant or one or more other users pursuant to some simple indication from the user that one or more of the resource requests should be further reviewed and approved. In this situation, the initial simple indication from the user may be considered a “soft” authentication, while the later review and approval by the appointed proxy is considered a “hard” authentication.
In some embodiments, the user may review and fully authorize the resource requests themselves. In other embodiments, some resource requests in a batch may be authorized, while others are not. The process of authorizing resource requests may also include security measures implemented by the resource platform as well, such as the entering of a user password, a three way authentication mechanism (e.g., pre-shared key, transmission of authentication code to previously authenticated device associated with the user, transmission of a secure code to a secure digital address of the user such as an entity email address, and the like), biometric authentication, secure authentication received from the user device, and the like. In embodiments where the user authorizes resource requests to be authenticated via proxy, the user may pre-authorize someone on the user's behalf to fully review and authorize distribution of resources for resource requests. For instance, a particular user may be enabled to reply to the resource platform with a simple soft authorization such as “yes, authorize all,” or select, via the user interface of a user device, specific resource requests that the user would like to proceed with authorizing, which would then route the selected resource request details to the particular user's appointed or assigned proxy approval assistant for full review and hard authorization. This process is reflected in blocks 312 and 314 of
The resource platform then executes the authorized resource requests, and performs confirmation, settlement, and reconciliation, as shown in block 316. Finally, as shown in block 318, the process concludes wherein the resource platform transmits a notification of completion of the authorized resource request via the API, and may perform subsequent analysis for reconciliation data insights. As previously discussed, reconciliation may include an additional confirmation of data regarding one or more resource transfers, and may involve more detailed metadata that offers valuable insight to entities or third parties utilizing the resource platform. For instance, the system may conduct data analytics during the reconciliation process to determine a number of resource transfers in a given category, for a given purpose, for a specific user or group of users, for a specific geographical area, and the like. In some embodiments, this reconciliation process may offer valuable insight for which entity or third party system procedures may respond or adapt to. For instance, in some cases the reconciliation data may indicate that resources were heavily utilized by users located in one geographical area to frequently travel to a second geographical area. This data may indicate to the entity or resource platform that resource expenditure may be reduced by relocating such users to an office in the second geographical area. In another embodiment, the data may indicate that a certain group of users appears to prefer one method of travel to another, and the system may compare user data for the certain group of users to ascertain other common data points that may indicate an insightful trend. For instance, the certain group of users may all reside in a particular geographic area, and the entity may use this data to predict that users from that geographic area may tend to prefer a specific means of travel, and may adapt to be more proactively accommodating to perceived regional preference.
As shown at block 402, the process begins whereby electronic resource request data is received at the resource platform. The electronic resource may be submitted to the resource platform by any number of users or entities depending on the embodiment of the invention, including by entity employees, merchants, third party entities, and the like. The resource platform then extracts resource transfer metadata from the electronic resource request, as shown in block 404. Metadata extracted from the resource request may include, but is not limited to, resource type or currency type, request purpose, merchant identification information, itemized product or service resource expenditure information, date, time, geolocation data, resource amounts, user identification information, resource account information (e.g., source or destination account information), routing information, preferred resource transfer rail information, and the like.
Next, as shown in block 406, the resource platform may perform conversion of the electronic resource request data to an industry standard resource messaging format used by the resource platform. As discussed, in some embodiments, this may include ISO 20022 standard formatting, but it is understood that the standard formatting could be adapted based on advances in technology or industry standard, widespread adoption of a different standard, a need for a different standard by a third party entity that utilizes the resource platform, and the like. It is understood that the conversion would ideally be completed in such a manner as to retain all metadata transaction details for the resource request, and may provide greater functionality for additional metadata to be appended. For instance, in some embodiments, the originally received data may include only a resource request invoice, while the converted formatting may append a date, time, merchant code, category, user comments, and the like. This data, as with all resource request data and related data, is stored on the resource platform data storage for later use and analysis. Once the resource request data has been converted, the system determines resource request authorization routing information based on resource platform instructions (e.g., route back to user listed in resource request invoice). In some embodiments, the authorization routing information may comprise identification of one or more users and a selection of a digital channel for transmitting the resource request information. For example, in some embodiments, the user listed on the resource request or associated with the resource request may have a configured preference for transmitting authorization instructions (e.g., resource platform may be configured to route resource requests to “user 1” via email for further review and authorization).
It is understood that in some embodiments, the resource platform may perform a second or multiple subsequent conversions of resource request data as determined by the selected digital channel on which the data is to be transmitted to a user, back to the resource platform from the user, within the resource platform system, or between the resource platform and other entities. For instance, if the resource data is to be transmitted to a user device via SMS text, email message, and the like, the resource platform may convert the data into plaintext, HTML, XML, and the like in order to comply with the selected digital channel formatting requirements. It is understood that these are limited embodiments and that any number of digital channels may be used depending on the destination device type and user or entity preferences. In some embodiments, the resource platform may transmit more than one resource request for authorization at one time in a batch format, and may automatically perform the combination of the multiple resource requests in the bath during the digital channel conversion process. This data, and all resource request data is stored on the resource platform data stores for later access and analysis.
Next, as shown in block 408, the resource platform may authorize the resource request via one or more users, as described in the detailed process of
As shown in block 414, the resource platform may receive and process a request for stored resource request history data. For instance, the resource platform may receive a request by the entity that manages the resource request platform to generate a report on the resource request data associated with a particular time period, user, group of users, merchant, group of merchants, category of goods and services, and the like. It is understood that the resource request history data may be compiled and accessed based on any number of metadata characteristics stored on the resource platform data stores. Based on the requested resource request history information, the resource platform may access compiled data and generate a resource request history report, as shown in block 416. Generation of the resource request history report may include converting relevant data for transmission over a digital channel preferred by a requestor. For instance, a user or entity may submit a request to the resource platform to generate a report for transmission via a secure data channel in a number of formats. In some embodiments, data requested by an entity, user, or third party entity may be submitted through a provided API interface, wherein a user accessing the resource platform via the API may be authorized to access a certain subset of resource request history information. In other embodiments, the API interface may provide a series of drop-down menus for selection of resource request history data (e.g., a drop down menu for a time period, a user group, an entity, a category of resource requests, preferred data format for the report, and the like).
In some embodiments, if the resource data is to be transmitted to a user device via email message, and the like, the resource platform may convert the data into plaintext, HTML, XML, and the like in order to comply with the selected digital channel formatting requirements. It is understood that these are limited embodiments and that any number of digital channels may be used depending on the destination device type and user or entity preferences. In some embodiments, the resource platform may transmit more than one resource request for authorization at one time in a batch format, and may automatically perform the combination of the multiple resource requests in the bath during the digital channel conversion process. This data, and all resource request data is stored on the resource platform data stores for later access and analysis. In some embodiments, the resource platform may maintain a number of mapping tables that are used to automate the conversion process from industry standard format into the requested format. For instance, in one embodiment, the resource platform may contain a mapping table that determines how metadata is mapped from ISO 20022 format to an XML format for display on a user device. As shown block 418, once the resource platform has generated the resource request history report, it then transmits the generated report in the preferred digital channel format.
As will be appreciated by one of ordinary skill in the art, the present invention may be embodied as an apparatus (including, for example, a system, a machine, a device, a computer program product, and/or the like), as a method (including, for example, a business process, a computer-implemented process, and/or the like), or as any combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely software embodiment (including firmware, resident software, micro-code, and the like), an entirely hardware embodiment, or an embodiment combining software and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product that includes a computer-readable storage medium having computer-executable program code portions stored therein. As used herein, a processor may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more special-purpose circuits perform the functions by executing one or more computer-executable program code portions embodied in a computer-readable medium, and/or having one or more application-specific circuits perform the function. As such, once the software and/or hardware of the claimed invention is implemented the computer device and application-specific circuits associated therewith are deemed specialized computer devices capable of improving technology associated with the in authorization and instant integration of a new credit card to digital wallets.
It will be understood that any suitable computer-readable medium may be utilized. The computer-readable medium may include, but is not limited to, a non-transitory computer-readable medium, such as a tangible electronic, magnetic, optical, infrared, electromagnetic, and/or semiconductor system, apparatus, and/or device. For example, in some embodiments, the non-transitory computer-readable medium includes a tangible medium such as a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), and/or some other tangible optical and/or magnetic storage device. In other embodiments of the present invention, however, the computer-readable medium may be transitory, such as a propagation signal including computer-executable program code portions embodied therein.
It will also be understood that one or more computer-executable program code portions for carrying out the specialized operations of the present invention may be required on the specialized computer include object-oriented, scripted, and/or unscripted programming languages, such as, for example, Java, Perl, Smalltalk, C++, SAS, SQL, Python, Objective C, and/or the like. In some embodiments, the one or more computer-executable program code portions for carrying out operations of embodiments of the present invention are written in conventional procedural programming languages, such as the “C” programming languages and/or similar programming languages. The computer program code may alternatively or additionally be written in one or more multi-paradigm programming languages, such as, for example, F#.
It will further be understood that some embodiments of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of systems, methods, and/or computer program products. It will be understood that each block included in the flowchart illustrations and/or block diagrams, and combinations of blocks included in the flowchart illustrations and/or block diagrams, may be implemented by one or more computer-executable program code portions. These one or more computer-executable program code portions may be provided to a processor of a special purpose computer for the authorization and instant integration of credit cards to a digital wallet, and/or some other programmable data processing apparatus in order to produce a particular machine, such that the one or more computer-executable program code portions, which execute via the processor of the computer and/or other programmable data processing apparatus, create mechanisms for implementing the steps and/or functions represented by the flowchart(s) and/or block diagram block(s).
It will also be understood that the one or more computer-executable program code portions may be stored in a transitory or non-transitory computer-readable medium (e.g., a memory, and the like) that can direct a computer and/or other programmable data processing apparatus to function in a particular manner, such that the computer-executable program code portions stored in the computer-readable medium produce an article of manufacture, including instruction mechanisms which implement the steps and/or functions specified in the flowchart(s) and/or block diagram block(s).
The one or more computer-executable program code portions may also be loaded onto a computer and/or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer and/or other programmable apparatus. In some embodiments, this produces a computer-implemented process such that the one or more computer-executable program code portions which execute on the computer and/or other programmable apparatus provide operational steps to implement the steps specified in the flowchart(s) and/or the functions specified in the block diagram block(s). Alternatively, computer-implemented steps may be combined with operator and/or human-implemented steps in order to carry out an embodiment of the present invention.
While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations and modifications of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.
To supplement the present disclosure, this application further incorporates entirely by reference the following commonly assigned patent application:
