Abstract:
The present automated trustee payments system implements a series of automated processes which significantly reduce, and in many cases, eliminate a creditor user&#39;s work that is required to accurately and timely process incoming Chapter 13 Trustee remittances. The automated trustee payments system also effects application of the funds to the proper bankrupt debtor accounts and accounts for the funds against the proper creditor&#39;s loan account segments (e.g., the bankruptcy estate pre-petition indebtedness or the post-petition ongoing payments).

Description:
STATEMENT OF RELATED APPLICATION 
       [0001]    This application claims the benefit of provisional patent application Ser. No. 62/137,569 entitled “Automated Trustee Payments System” filed Mar. 24, 2015. 
     
    
     BACKGROUND 
       [0002]    The conventional processing of payments from Chapter 13 Trustees to a creditor can often be time-consuming and error prone due to the need to cross-reference numerous entries on a given remittance check to locate the correct loan and debtor loan data on the creditor&#39;s internal systems and properly identify the nature of the payment. New systems are desired to reduce a creditor&#39;s workload while improving accuracy and timeliness of the remittance processing and properly identify the nature of payment being remitted with regard to pre-petition indebtedness, post-petition payments, and/or applicable fees. 
         [0003]    This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above. 
       SUMMARY 
       [0004]    The present automated trustee payments system implements a series of automated processes which significantly reduce, and in many cases, eliminate a creditor user&#39;s work that is required to accurately and timely process incoming Chapter 13 Trustee remittances. The automated trustee payments system also effects application of the funds to the proper bankrupt debtor accounts and accounts for the funds against the proper creditor&#39;s loan account segments (e.g., the bankruptcy estate pre-petition indebtedness, interest on a claim, or the post-petition ongoing payments). 
         [0005]    In various illustrative examples, the automated trustee payments system enables automated logging of the check&#39;s receipt and tracking its disposition by capturing the salient check information from the minimum data amount required to be input, for example by retrieving, parsing, and storing the check voucher data automatically from the Trustees&#39; data repository, and queuing it for processing. 
         [0006]    The automated trustee payments system may further enable automated cross-referencing of each remittance item to internal loans using Trustee case record identifiers, avoiding the requirement for a user to make inquiries to the Trustees&#39; data repository for each remittance item on the Trustee&#39;s check, or make inquiries to the creditor&#39;s loan system for each remittance item on the Trustee&#39;s check, or needing to compare the two systems&#39; data and assess the cross-reference of the case and claim data elements against the possible loan data elements, or make a determination of the correct case-to-loan reference from the possible loans. For example, an automated system-to-system interface is typically implemented to retrieve each remittance item&#39;s case and claim information and to interface with and interrogate the user&#39;s loan system and to analyze and rate matches of case information to loan information based on multiple-system, multiple loan borrower and loan status based business rules, and queuing each remittance item for processing. 
         [0007]    The automated trustee payments system may further enable automated determination of the proper application or alternate disposition of each remittance item to the proper loan account segment, avoiding the requirement for a user to analyze the Trustee&#39;s claim data to determine whether the remittance item is for a pre-petition plan payment, a post-petition ongoing loan payment, interest on the claim, or for a post-petition fee based on identifiers which are vague, ambiguous, and/or inadequate to effect proper determination, or needing to timely and correctly calculate claimed and ongoing loan fees and loan payments to be applied from the remittance items in combination with suspensed funds (from prior partial receipts). For example, an automated system-to-system interface may be implemented to interrogate the user&#39;s loan system to determine suspensed debtor funds, suspensed Trustee funds, claimed and unpaid fees, interest on claims, claimed and unpaid delinquent loan payments, unpaid post-petition fees, unpaid post-petition loan payments, analyzing the remittance item and its voucher descriptions along with Trustee case and claim information and making the calculation of fee and payment applications based on multiple-system, multiple loan borrower, loan status indicator and case/claim status indicator based business rules and queuing each item for further processing. 
         [0008]    The automated trustee payments system may further enable automated routing, review, analysis, disposition, tracking and alternate-routine processing of exceptions in all categories, with re-entry to processing paths. For example, exception handling for out-of-balance checks or unretrieved checks is supported. In addition, the system supports an escalation feature so that any item presented to a user may be selected for an additional higher level reviews. 
         [0009]    The automated trustee payments system may further enable automated application of each payment&#39;s component to each loan account, avoiding the requirement for a user to make multiple-step, often time-constrained multiple-day payment application entries to the loan account, or make update entries to the loan&#39;s ledger(s) for the pre-petition, post-petition, and full contractual loan histories. For example, an automated system-to-system interface may be implemented to execute payment and update transactions to the user&#39;s loan system and alternate application exception re-processing of payment application transactions due to post-analysis pre-application loan system status changes based on business rules. Such interface can advantageously enable automated handling of conflicting activities. 
         [0010]    The automated trustee payments system may further enable automated support of daily remittance balancing, avoiding manual batch tallies and control log entries. The automated trustee payments system may further enable automated handling of transactions involving inter-company fund transfers to areas associated with portfolios that are typically handled separately and funds returns that are determined not be processed by any area. 
         [0011]    The automated trustee payments system may further enable automated tracking of the each remittance item&#39;s disposition, avoiding the manual entry of all the remittance advice information (e.g., by only entering a check number, amount, date, and payor). 
         [0012]    The automated trustee payments system may further enable self-check and follow-up when a voucher entry disposition includes one or more payment applications to ensure proper post-application loan condition and status are verified, and exceptions are presented to the user for disposition or further processing, for example, by decision or additional entries. 
         [0013]    The automated trustee payments system may further implement a self-learning function in which, as exceptions are resolved and/or as actions are validated, the system “learns” the characteristics of the payment (pre-/post-/fees, cross-referenced system/loan and application route) and, based on the user&#39;s configuration, applies the end-state to the next processing of a payment for the same case and claim with the same identifiers, thus eliminating redundant handling of exceptions or validations. The configuration supports a multiple-affirmation threshold limit before auto-applying the prior decision. Prior to the satisfaction of the threshold, the system will present the subsequent exception or validation items with the prior dispositions noted for reference. If the threshold has not been met and a subsequent user action contradicts a prior, then the user is presented with a decision—reset prior event learning for the case/claim remittance item or a one-time variance and don&#39;t count against the threshold. 
         [0014]    The automated trustee payments system may further implement user-configurable review-level threshold settings, auto-processing thresholds and secondary-review settings. This feature enables the remittance items to be, based on characteristics, routed for human review only when needed based on variable characteristics and further enables management control of changes, deviations from tolerances, and the like. 
         [0015]    This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0016]      FIG. 1  shows an illustrative computing environment in which the present automated trustee payments system may be implemented; 
           [0017]      FIGS. 2A, 2B and 2C  show a flowchart of a first illustrative method in which remittance checks from a bankruptcy trustee are processed; 
           [0018]      FIGS. 3-13  show various illustrative screen captures of sources of information that are accessed as the first illustrative method is practiced; 
           [0019]      FIGS. 14A, 14B, 14C and 14D  show a flowchart of a second illustrative method in which remittance checks from a bankruptcy trustee are processed and associated details are retrieved; 
           [0020]      FIGS. 15-20  show various illustrative screen captures of sources of information that are accessed as the second illustrative method is practiced; 
           [0021]      FIGS. 21A and 21B  show a flowchart of a third illustrative method in which data is retrieved from a client loan system and processed; 
           [0022]      FIGS. 22-26  show various illustrative screen captures of user interfaces that are displayed on a client computer as the third illustrative method is practiced; 
           [0023]      FIGS. 27A and 27B  show a flowchart of a fourth illustrative method in which data is retrieved from a client loan system and processed; 
           [0024]      FIG. 28  shows an illustrative screen capture of a user interface that is displayed on a client computer as the fourth illustrative method is practiced; 
           [0025]      FIG. 29  shows a flowchart of a fifth illustrative method in which collected case, claim, and loan data elements are analyzed using logical comparison and fractal analyses to determine eligibility for payment application decision-making; 
           [0026]      FIG. 30  shows an illustrative screen capture of a user interface that is displayed on a client computer as the fifth illustrative method is practiced; 
           [0027]      FIGS. 31A and 31B  shows a flowchart of a sixth illustrative method in which payment applications are made to a loan and loan fields are updated in records held in a client loan system; 
           [0028]      FIG. 32  shows a flowchart of a seventh illustrative method in which daily balancing of check remittances is controlled; 
           [0029]      FIGS. 33-37  show various illustrative screen captures of user interfaces that are displayed on a client computer as the seventh illustrative method is practiced; 
           [0030]      FIG. 38  shows a flowchart of an eighth illustrative method in which detailed data elements, processing paths, intermediate and final statuses, user entries, and user comments are maintained as a detailed supplement to loan processing records for audit purposes; 
           [0031]      FIGS. 39A and 39B  show a flowchart of a ninth illustrative method for performing a self-check and follow-up when a voucher entry disposition includes one or more payment applications to ensure verification of proper post-application loan condition and status; and 
           [0032]      FIGS. 40-43  shows various illustrative screen captures of user interfaces that are displayed on a client computer as the ninth illustrative method is practiced. 
       
    
    
       [0033]    Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated. 
       DETAILED DESCRIPTION 
       [0034]      FIG. 1  shows an illustrative computing environment  2  in which the present automated trustee payments system may be implemented. The environment includes a client computer  5  that is operatively connected to a network such as the Internet  10 . The Internet connection facilitates communication with an automated trustee payments system  15  that exposes various features, capabilities, and functionalities via web services to the client computer  5 . A trustee data repository  20 , for example a National Data Center site, a client loan system  25 , and a remote database  27  are also located in the computing environment  2 , as shown. 
         [0035]    The present automated trustee payments system is further described in the flowcharts and screen captures shown in the drawings. More particularly,  FIGS. 2A, 2B and 2C  show a flowchart of a first illustrative method  200  in which remittance checks from a bankruptcy trustee are processed. Unless specifically stated, the methods or steps shown in the flowcharts and described in the accompanying text are not constrained to a particular order or sequence. In addition, some of the methods or steps thereof can occur or be performed concurrently and not all the methods or steps have to be performed in a given implementation depending on the requirements of such implementation and some methods or steps may be optionally utilized. 
         [0036]    Step  205  in method  200  comprises creating a processing worklist from the remittance check data. Step  210  comprises navigating to a web-based trustee data repository system. Step  215  comprises executing a login to the trustee data repository system. Step  220  comprises capturing the login response from the trustee data repository system. Step  225  comprises assessing the captured response to verify success of the login. 
         [0037]    If the login is unsuccessful, then step  230  comprises re-performing the steps of executing and capturing the login. Step  235  comprises navigating to a voucher page on the trustee data repository system. Step  240  comprises capturing a response to the voucher page navigation. Step  245  comprises assessing the captured response to verify that the navigation to the correct page was successful. 
         [0038]    If the navigation was unsuccessful, then step  250  comprises re-performing the steps of if navigation unsuccessful, re-performing steps of navigating to the voucher page and capturing the response. Step  255  comprises executing a voucher search. Step  260  comprises capturing a response to the voucher search. Step  265  comprises assessing the captured response. Step  270  comprises executing a voucher download. 
         [0039]    Step  270  comprises capturing a response to the voucher download. Step  280  comprises assessing the captured response. Step  285  comprises saving data from the voucher download. Step  290  comprises generating a remittance item worklist and step  295  comprises summing entries in the worklist. 
         [0040]      FIGS. 3-13  respectively show various illustrative screen captures  300 ,  400 ,  500 ,  600 ,  700 ,  800 ,  900 ,  1000 ,  1100 ,  1200 , and  1300  of sources of information that are accessed as the first illustrative method  200  described above is practiced. 
         [0041]      FIGS. 14A, 14B, 14C and 14D  show a flowchart of a second illustrative method  1400  in which remittance checks from a bankruptcy trustee are processed and associated details are retrieved. Step  1402  comprises receiving input from a client. Step  1404  comprises creating a processing worklist. Step  1406  comprises navigating to a web-based trustee data repository system. Step  1408  comprises executing a login to the trustee data repository. Step  1410  comprises capturing the response to the login. Step  1412  comprises assessing the captured response to verify the success of the login. If the login was unsuccessful, the step  1414  comprises re-performing the steps of executing and capturing the login. 
         [0042]    Step  1416  comprises executing a case search. Step  1418  comprises capturing a response to the case search. Step  1420  comprises assessing the captured response to verify that the correct case was retrieved. Step  1422  comprises navigating to a case summary page. Step  1424  comprises capturing a response to the case summary page navigation. Step  1426  comprises assessing the captured response to verify that the navigation to the correct case summary page was successful. If navigation was unsuccessful, then step  1428  comprises re-performing the steps of navigating to the case summary page and capturing the response. 
         [0043]    Step  1430  comprises storing results data from the case summary page. Step  1432  comprises parsing the stored results data. Step  1434  comprises navigating to a claim summary page. Step  1436  comprises capturing a response to the claim summary page. Step  1438  comprises assessing the captured response to verify that navigation to a correct account ledger page with a correct case was successful. Step  1440  comprises storing results data from the claim summary page. Step  1442  comprises parsing the stored results data to create claim data elements populated into processing database and appending results. 
         [0044]    Step  1444  comprises navigating to a remittance item claim on the claim summary page. Step  1446  comprises capturing a response to the remittance item claim navigation. Step  1448  comprises assessing the captured response to the remittance item claim navigation to verify that navigation to correct remittance item claim was successful. Step  1450  comprises storing results data from the remittance item claim and step  1452  comprises parsing the stored results data to create remittance item claim data elements populated into processing database. 
         [0045]      FIGS. 15-20  respectively show various illustrative screen captures  1500 ,  1600 ,  1700 ,  1800 ,  1900 , and  2000  of sources of information that are accessed as the second illustrative method  1400  described above is practiced. 
         [0046]      FIGS. 21A and 21B  show a flowchart of a third illustrative method  2100  in which data is retrieved from a client loan system and processed. Step  2102  comprises performing an automated login to a client loan system. Step  2104  comprises executing an inquiry to the client loan system. Step  2106  comprises utilizing processing rules and criteria to implement multiple-pass searches for data to cross reference. Step  2108  comprises storing results data from the retrieved presented data. Step  2110  comprises parsing the stored results data. Step  2112  comprises assessing the validity of the stored results data. Step  2114  comprises executing analyses to determine a creditor asset basis. Step  2116  comprises executing analyses to determine a discreet loan match or multiple possible loan matches. If multiple possible loan matches are indicated, then step  2188  comprises presenting the result on the user interface. 
         [0047]      FIGS. 22-26  respectively show various illustrative screen captures  2200 ,  2300 ,  2400 ,  2500 , and  2600  of user interfaces that are displayed on a client computer as the third illustrative method  2100  described above is practiced. 
         [0048]      FIGS. 27A and 27B  show a flowchart of a fourth illustrative method  2700  in which data is retrieved from a client loan system and processed. Step  2702  comprises performing an automated login to a client loan system. Step  2704  comprises executing an inquiry to the client loan system. Step  2706  comprises utilizing processing rules and criteria to acquire detailed loan information. Step  2708  comprises storing results data from the retrieved presented data. Step  2710  comprises parsing the stored results data. Step  2712  comprises assessing the validity of the stored results data. Step  2714  comprises executing analyses to determine if the remitted item is a pre-petition plan payment. Step  2716  comprises executing analyses to determine payment applications and updates and step  2718  comprises presenting results of analyses in an online user interface. 
         [0049]      FIG. 28  shows an illustrative screen capture  2800  of a user interface that is displayed on a client computer as the fourth illustrative method  2700  described above is practiced. 
         [0050]      FIG. 29  shows a flowchart of a fifth illustrative method  2900  in which collected case, claim, and loan data elements are analyzed using logical comparison and fractal analyses to determine eligibility for payment application decision-making. Step  2902  comprises accessing a client loan system to retrieve and store results data. Step  2904  comprises parsing stored results data. Step  2906  comprises executing iterative analysis routines. Step  2908  comprises flagging remittance item worklist entries determined eligible. Step  2910  comprises presenting exceptions. Step  2912  comprises flagging remittance item worklist entries that are determined as being ineligible. Step  2914  comprises iterating exceptions until no remaining exception conditions are evident. 
         [0051]      FIG. 30  shows an illustrative screen capture  3000  of a user interface that is displayed on a client computer as the fifth illustrative method  2900  described above is practiced. 
         [0052]      FIGS. 31A and 31B  shows a flowchart of a sixth illustrative method  3100  in which payment applications are made to a loan and loan fields are updated in records held in a client loan system. Step  3102  comprises connecting to client loan system. Step  3104  comprises executing inputs through an API (application programming interface) or web services. Step  3106  comprises capturing results. Step  3108  comprises validating success of each payment application input entry. Step  3110  comprises storing results of the validating step. If the payment application routine is successful, the step  3112  comprises marking the status as complete. 
         [0053]    If any payment application input routine has an unsuccessful result, then step  3114  comprises resetting remittance item worklist status to incomplete. Step  3116  comprises executing analyses of remittance items. Step  3118  comprises analyzing a remittance item aggregate worklist. Step  3120  comprises determining any required alternate payment application routines. Step  3122  comprises re-executing payment applications. Step  3124  comprises performing iterations until all remittance item worklist entries achieve a status of being complete. Step  3126  comprises generating payment application or non-application reports. 
         [0054]      FIG. 32  shows a flowchart of a seventh illustrative method  3200  in which daily balancing of check remittances is controlled. Step  3202  comprises maintaining a hierarchal association. Step  3404  comprises maintaining remittance item processing status. Step  3406  comprises maintaining check processing status, and step  3408  comprises performing a drill down. 
         [0055]      FIGS. 33-37  respectively show various illustrative screen captures  3400 ,  3500 ,  3600 , and  3700  of user interfaces that are displayed on a client computer as the seventh illustrative method  3200  described above is practiced. 
         [0056]      FIG. 38  shows a flowchart of an eighth illustrative method  3800  in which detailed data elements, processing paths, intermediate and final statuses, user entries, and user comments are maintained as a detailed supplement to loan processing records for audit purposes. Step  3802  comprises enabling an online inquiry and step  3804  comprises providing search result population and data. 
         [0057]      FIGS. 39A and 39B  show a flowchart of a ninth illustrative method  3900  for performing a self-check and follow-up when a voucher entry disposition includes one or more payment applications to ensure verification of proper post-application loan condition and status. Step  3902  comprises working from a post-application follow-up worklist. Step  3904  comprises connecting to a client loan system. Step  3906  comprises executing a login or connection. Step  3908  comprises executing an inquiry using APIs or web services. Step  3910  comprises storing results data. Step  3912  comprises executing comparisons and analyses. If a result of the executing is that expected client loan conditions and data is present, then step  3914  comprises performing tagging as appropriate. 
         [0058]    If a result of the executing is that expected client loan conditions and data is not present, then step  3916  comprises performing tagging as appropriate. Step  3918  comprises presenting an entry in an online user interface. 
         [0059]      FIGS. 40-43  respectively show various illustrative screen captures  4000 ,  4100 ,  4200 , and  4300  of user interfaces that are displayed on a client computer as the ninth illustrative method  3900  described above is practiced. 
         [0060]    The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.