Patent ID: 12205087

DETAILED DESCRIPTION OF DRAWING

The present disclosure is now described in detail with reference to the drawings. In the drawings, each element with a reference number is similar to other elements with the same reference number independent of any letter designation following the reference number. In the text, a reference number with a specific letter designation following the reference number refers to the specific element with the number and letter designation and a reference number without a specific letter designation refers to all elements with the same reference number independent of any letter designation following the reference number in the drawings.

The present invention relates to the transferring of payments to one or more payees by a sender using the software. The software sends a payment summary to the payee. The payee/sender then sends banking details and the preferred mode of payment to receive the payment(s). The software then processes the payment automatically as per the preferred mode of payment.

FIG.1illustrates a schematic diagram of a system100communicating with a financial institution102over a communication network to manage payments of payee initiated by a sender using a sender computing device104. The system100includes a database106for storing a plurality of modules108, a central server110for monitoring and updating the plurality of modules108, and a processing unit112coupled to the database106and the financial institution102through the central server110for processing the plurality of modules108. In a preferred embodiment, the central server110is a cloud-based server.

The plurality of modules108include a payee module114, a notification module116, a dashboard module602, a refunds module702, a payment process module120, and a remittance summary module1100. The notification module116allows the sender to send a payment summary to each payee over the communication network. Examples of the sender include but are not limited to insurance companies, companies, factories, higher education, institutions, healthcare providers, commercial real estate providers, etc.

A payee could be an individual, a small business, or a company that does not routinely receive payments from the sender. For instance, an insurance company, the sender, could make payments to claimants who rarely receive a claim payment. Another example is utilities who are required by law to make refunds to customers when the utility does not provide the service. Still another example is a class action litigation manager, who needs to make a large number of one-time payments to a large number of claimants.

The payee module114displays the payment summary to the payee. Further, the payee module114allows the payee to upload the payee's details in the central server110. The payee module114further allows the payee to input banking details of the financial institution.

In another embodiment of the present invention, the payee provides banking details via tokenization e.g. payment transaction mobile applications such as Zelle. It would be readily apparent to those skilled in the art that various modes of input of banking details by the payee may be envisioned without deviating from the scope of the present invention.

Furthermore, the payee module114allows the payee to select a mode of payment to receive the payment. The notification module116and the payee module114are explained in detail in conjunction withFIG.2andFIGS.3A &3B, respectively of the present invention.

The dashboard module602is coupled to the payee module for allowing the sender to receive a funds request from the sender for the payments send to the payee. The refunds module702is coupled to the dashboard module602for allowing the sender to receive funds of the payment sent to the payee. The dashboard module602and the refunds module702are explained in detail in conjunction withFIG.6A,6B, andFIG.7respectively.

The payment process module120processes the payment as per the mode selected by the payee in the payee module114. Further, the payment process module120processes the payment via cheque (alternatively may be referred to as a check) mode if the payee fails to update the mode of payment in a pre-defined duration. The payment process module120is explained in detail in conjunction withFIG.4of the present invention.

In another embodiment of the present invention, it would be readily apparent to those skilled in the art that the sender may also cancel the payment request, in case the payee fails to select a mode of payment within a pre-defined time period. In another embodiment of the present invention, it would be readily apparent to those skilled in the art that the system may automatically cancel the payment request on behalf of the sender based on a pre-configured setting if so desired, in case the payee fails to select a mode of payment within a pre-defined time period.

In another embodiment of the present invention, the plurality of modules further includes a customizable payment summary template module, a verification module, a logo module, a financial institution module, a reminder module, an encryption module, an account verification module, a payment status module, a registration module, a preferred payment module, a refunds module, and a dashboard module.

In another embodiment of the present invention, the notification module116allows the sender to send the payment summary of each payee to the financial institution to initiate the payments. The financial institution module allows the financial institution to process the payments as per the mode selected by the payee in the payee module. It would be readily apparent to those skilled in the art to envision financial institutions as banks, credit unions, member-owned financial cooperatives, FinTech companies, etc. without deviating from the scope of the present invention.

The encryption module encrypts the banking details provided by the payee in the payee module114. The account verification module is coupled with the payee module114for confirming the payee banking details with the details of the payee held by the financial institution. The central server110sends the banking details to the financial institution to confirm the payee details. The registration module (not shown in FIGURES) registers sender and payee, on the central server110. The plurality of modules are explained in detail in conjunction withFIG.2toFIG.7of the present invention.

FIG.2illustrates a schematic diagram of the payee module114in an exemplary embodiment of the present invention. The payee module114displays sender information202including but not limited name of the sender, address of the sender, tax ID of the sender, etc.

The payee module114allows the payee to add payee details204related to how the payee would prefer to receive a payment, including but not limited to payee name, payee company name and address, purpose of payment, payee banking details, user ID, and password, etc. The payment summary (304, shown inFIG.3) is generated automatically by the central server and is sent by the notification module116.

Further in another embodiment of the present invention, the payment summary (304, shown inFIG.3) is customized as per the likings of the sender through the customizable payment summary template module (not shown in FIGURES). It would be readily apparent to those skilled in the art that various types of customization depending upon the requirement of the sender such as different phone numbers for different disbursements may be envisioned without deviating from the scope of the present invention. In some embodiments, the remittance summary module is the payment summary template module.

Further, the sender may add a logo (e.g. company's logo) in the payment summary through the logo module (not shown in FIGURES). The logo may help the payee to recognize or confirm the sender of the payment Further, the logo module may include details of the phone number and email address of the sender. It would be readily apparent to those skilled in the art that various types of logos may be envisioned to differentiate different types of disbursements of the payments without deviating from the scope of the present invention.

The notification module116allows the sender to send the payment summary (304, shown inFIG.3A) over the communication network. In an embodiment of the present invention, the sender sends the payment summary through Email. However, it would be readily apparent to those skilled in the art that various other means for communication such as SMS, Whatsapp, Hike, other similar social media platforms, etc. may be envisioned without deviating from the scope of the present invention.

FIG.3Aillustrates a screenshot viewing of a graphical user interface for the payee module114. The payee module114displays the payment summary304to the payee and further allows selecting a mode of payment302to receive the payment in the provided banking details.FIG.3Billustrates another screenshot viewing of a graphical user interface for the payee module114showing modes302for receiving the payments. Examples of the mode to receive the payments include but are not limited to direct deposit, wire transfer, ACH, debit card, cheque/checks, etc. The system is configurable to cater to varying payment types as desired by a sponsoring sender.

FIG.4illustrates a screenshot viewing of a graphical user interface for the payment process module120. The payment process module120processes the payment as per the mode selected by the payee in the payee module (114, shown inFIG.3A). In an exemplary embodiment, the payee selects cheque/check as a mode of payment in the payee payment module. Then as shown inFIG.4, the payment process module120processes the payment via cheque402.

It would be readily apparent to those skilled in the art that payment process module120processes the payment as per the mode selected in the payee module114. Hence, the payment process module120may process the payment via electronic means such as ACH, PayPal, Debit, Wire-transfer, direct deposit, cards, etc, depending upon the mode selected by the payee.

The payment process module120further processes the payment via cheque if the payee fails to select the mode of payment within a pre-defined time. In an embodiment of the present invention, the pre-defined duration is 3 days, however, it would be readily apparent to those skilled in the art that various duration (number of days) may be configured without deviating from the scope of the present invention.

A reminder is sent to the payee at regular intervals to select a mode of payment via the reminder module (not shown in FIGURES). The reminder may be sent via email, SMS, internet messages, etc. The duration of intervals may be customized such as 1 message in each day or 2 messages in each day or ‘n’ messages in each day. It would be readily apparent to those skilled in the art that various modes and intervals of reminder may be envisioned without deviating from the scope of the present invention.

The payee module (114, as shown inFIG.3A) displays instructions404for releasing the payment within a pre-defined duration. The payment process module120further displays another instruction406to receive payments electronically to receive payments immediately.

The payment status module (not shown in FIGURES) is coupled to the payment process module120for sending updates on the status of payments to the payee via the communication network. For example, the payment status module may send status in numerous ways such as but not limited to the number of days in which the payment would be credited in the provided banking details, the number of days left to receive the cheque/check, etc.

FIG.5illustrates a screenshot viewing of a graphical user interface for the verification payee account module502. The verification payee account module502verifies the identification of the payee before allowing to choose a mode of payment. The verification may be done by asking questions such as but not limited to postal code504(postal code is a ZIP Code in the USA). In another embodiment of the present invention, the verification options such as shared secrets including but are not limited to a utility account numbers, a social security number (all or a portion of the number), a driver's license number, a phone number, insurance claim number, student identification number or other means for verifying the payee identification.

It would be readily apparent to those skilled in the art that various questions may be envisioned to ensure verification of payee before releasing the payments by the sender to verify the payee without deviating from the scope of the present invention.

FIG.6Aillustrates a screenshot viewing of a graphical user interface for the dashboard module602for informing the sender of the status of the payments. The dashboard module602displays payment method activities604, allows the sender to search606for payments and allows the sender to track outgoing payments608. The payment method activities604shows the total payments released in a particular time frame such as the current day or a configurable timeframe. Further, the payment method activities604show segregation of payments made by either ACH, Card, Check, Debit, PayPal, Zelle, or other payment types desired by the sender.

The payment search606allows the sender to search for payments using various parameters such as payment date, payer, vendor, payment number, etc. The payment tracker608allows the sender to view payments in their current payment status such as awaiting processing, in-process, processed successfully, and exceptions. Further, the dashboard module602allows the sender to make new payments610.

FIG.6Billustrates another screenshot viewing of a graphical user interface for the dashboard module602for reviewing refunds request from the sender for the payments send to the payee, as in the utility example above. The dashboard module602allows the sender to check claim type612, top claims614, and summary of claims616.

The claim type612indicates that the claim initiated by the sender is a refund or a complaint. The top claims614shows the list of top payees from which the request of refunds is initiated. The summary of claim616shows the total number of claims, cleared payments, un-cleared payments, average time to pay, most common disbursements, etc.

FIG.7illustrates a screenshot viewing of a graphical user interface for the refunds module702. The refunds module702allows the sender to receive refunds of the payment sent to the payee. The refunds module702allows the sender to select the payment method704to receive a refund.

FIG.8Ais a screenshot showing a graphical user interface of the preferred payment module802. The preferred payment module802requests access804to contacts, SMS, media access, and media files of the payee. The preferred payment module802analyzes either phone text messages; and social media accounts, to detect the preferred mode of payment of the payee.

For exemplary purposes, the preferred payment module802seeks a request to access the contact list, messages, social media accounts stored in the payee's communicating device at the time of registering the payee on the central server. The preferred payment module802extracts preferred mode of payments such as PayPal by analyzing the common mode of receiving payments in the payee communicating device.

FIG.8Bis another screenshot showing a graphical user interface of the preferred payment module802. The preferred payment module802further displays a message806to the payee communicating device indicating the mobile application used by the payee to receive payments and suggesting the payee opt for the preferred mobile application to receive the payments.

FIG.9illustrates a flowchart of a method900for communicating with a financial institution over a communication network to manage payments of payee initiated by a sender. The method900initiates with a step902of storing a plurality of modules using a database. The step902is followed by a step904of monitoring and updating the plurality of modules using a central server.

The step904is then followed by a step906of processing the plurality of modules through a processing unit, wherein the processing unit is coupled to the database and the financial institution through the central server. The step906is then followed by a step908of sending a payment summary by the sender to each payee over the communication network using a notification module.

The step908is then followed by a step910of uploading the payee's details by the payee using a payee module in the central server. The step910is then followed by a step912of selecting a mode of payment using the payee module to receive the payment by the payee.

The step912is then followed by a step914of inputting banking details of the financial institution using the payee module. The step914is then followed by a step916of reviewing refunds requested by the sender for the payments send to the payee using a dashboard module. The step916is then followed by a step918of receiving refunds by the sender of the payment send to the payee using a refunds module.

The step918is then followed by a step920of processing the payment as per the mode selected by the payee in the payee module using a payment process module. The step920is then followed by a step922of processing the payment via cheque mode if the payee fails to update the mode of payment in a pre-defined duration.

The step922is then followed by a step924of displaying a summary of the payments made by the sender to the payee using a remittance summary module. The remittance summary module1100is explained in detail in conjunction withFIG.11of the present invention.

In another embodiment of the present invention the method900further includes step of customizing the format of the payment summary using a customizable payment summary template module, and adding a logo on the payment summary using a logo module.

In another embodiment of the present invention, the method900further includes the step of verifying identification by using shared secrets of the payee's details added through the payee module using a verification payee account module; sending follow up notification to the payee to select the mode of payment using a reminder module; confirming the payee banking details with the details of payee held by the financial institution using an account verification module; and sending updates on the status of payments to the payee via the communication network.

In another embodiment of the present invention, the method900further includes the steps of sending payment summary of each payee added through the payee module for payments to the financial institution using the notification module; and processing the payments as per the mode selected by the payee in the payee module using a financial institution module.

In another embodiment of the present invention, the method900further includes the steps of analyzing at least one of: phone text messages; and social media accounts, to detect the preferred mode of payment of the payee using a preferred payment module, and displaying payment method activities, allows the sender to search for payments, and allows the sender to track outgoing payments using a dashboard module. The method900is explained in detail in conjunction withFIG.1toFIG.8Bof the present invention.

FIG.10illustrates a block diagram of an electrical diagram of a central server110in accordance with an embodiment of the present invention. Since this software solution is required to handle a large volume of transactions with near real-time performance, a typical computer is not sufficient to perform the tasks. A processing device with a plurality of cores1001a-delectrically or optically connected to a bus1002is used to handle the performance requirements.

A high speed data storage device1003, a datastore, with solid state, optical or magnetic media, is electrically or optically connected to the bus1002. The bus1002may be an electrical or optical bus, configured either serially or in parallel. The bus1002is also connected to a rail interface1004for connection to the banking rail1006and to a network interface1008, the network interface1008interfacing to the internet1009. The network and rail interfaces1004,1006are high performance interfaces and may be combined into a single network interface in some embodiments. In some embodiments, the banking rail1006could be replaced with a payment rail or a card rail.

FIG.11illustrates a screenshot showing of a remittance summary module1100. The remittance summary module1100displays a summary of the payments made by the sender/payer to the payee. The payment summary shows various categories of the payments. Examples of the categories include but not limited to a Company Name, Vendor #, PO #, Contract #, Invoice #, Invoice Date, Original Invoice Amount, Paid Invoice Amount, Discount Amount, Comments, etc.

For exemplary purposes as shown inFIG.11, invoice # is ‘15656’, invoice date is ‘26.5.21’, and invoice amount is ‘1546.00’. The payment summary is customizable1102to allow the payor/sender to customize the categories displayed in the payment summary. The customization may be done by selecting/deselecting the categories. Further, the payment summary module1100allows the sender to rename/add/remove the categories.

In an exemplary embodiment where a payer is in logistic business, is able to edit the categories into field names like: truck number, ticket, customer, product description, date, quantity, rate, UoM, extended, etc. It would be readily apparent to those skilled in the art that various types and number of fields may be created depending upon the nature of industry or business without deviating from the scope of the present invention.

It should be appreciated that many of the elements discussed in this specification may be implemented in a hardware circuit(s), a circuitry executing software code or instructions that are encoded within computer readable media accessible to the circuitry, or a combination of a hardware circuit(s) and a circuitry or control block of an integrated circuit executing machine readable code encoded within a computer readable media. As such, the term circuit, module, server, application, or other equivalent description of an element as used throughout this specification is, unless otherwise indicated, intended to encompass a hardware circuit (whether discrete elements or an integrated circuit block), a circuitry or control block executing code encoded in a computer readable media, or a combination of a hardware circuit(s) and a circuitry and/or control block executing such code.

All ranges and ratio limits disclosed in the specification and claims may be combined in any manner. Unless specifically stated otherwise, references to “a,” “an,” and/or “the” may include one or more than one, and that reference to an item in the singular may also include the item in the plural.

Although the inventions have been shown and described with respect to a certain embodiment or embodiments, equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In particular regard to the various functions performed by the above-described elements (components, assemblies, devices, compositions, etc.), the terms (including a reference to a “means”) used to describe such elements are intended to correspond, unless otherwise indicated, to any element which performs the specified function of the described element (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary embodiment or embodiments of the inventions. In addition, while a particular feature of the inventions may have been described above with respect to only one or more of several illustrated embodiments, such feature may be combined with one or more other features of the other embodiments, as may be desired and advantageous for any given or particular application.