WO2017205984A1 - Secure network that efficiently connects ad-hoc subnetworks of nodes having volatile and private connection criteria - Google Patents

Abstract

The present invention relates to a way to connect ad-hoc subnetworks of nodes having volatile and private connection criteria, comprising a plurality of borrower client nodes, a plurality of lender client nodes and a marketplace server in communication with the plurality of borrower client nodes and the plurality of lender client nodes. The marketplace server has a database management system operable to manage a borrower object, a lender object, a plurality of loan application objects and a plurality of loan offer objects.

Description

SECURE NETWORK THAT EFFICIENTLY CONNECTS AD-HOC SUBNETWORKS OF NODES HAVING VOLATILE AND PRIVATE CONNECTION CRITERIA

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority from United States provisional patent application serial number US 62/344,978 filed on June 2, 2016 entitled SECURE NETWORK THAT EFFICIENTLY CONNECTS AD-HOC SUBNETWORKS OF NODES HAVING VOLATILE AND PRIVATE CONNECTION CRITERIA, which is expressly incorporated herein, to the fullest extent permitted by law. BACKGROUND

Field

The present invention relates to systems and methods for connecting ad- hoc subnetworks of nodes having volatile and private connection criteria. One application of this invention is a network that is well adapted to provide a marketplace for loan transactions.

Description of Related Art

The unmet need for a secure network that efficiently connects ad-hoc subnetworks of nodes having volatile and private connection criteria is perhaps most clearly illustrated by an exemplary specific application, for example a marketplace for mortgages.

In Canada, a small country with a population of about 36 million people, there are about 1000 lenders and 15,000 mortgage brokers, both of which are subject to regulation and oversight.

Many of the lenders publish broad guidelines as to the kinds of mortgages they are willing to offer, essentially advertising to borrowers and brokers the general circumstances under which an application is or is not worthwhile. However, the specific criteria that lenders apply in vetting each individual loan are volatile and confidential. Such criteria include: • a lender's cost of offering a loan in relation to the expected return on the loan,

• the mix of loans and other transactions and assets needed to meet compliance constraints imposed by regulators,

• balance constraints to diversify a portfolio of loans to properly mitigate risk,

• strategic preferences to support financial goals (increasing return on capital) or marketing goals (penetrating an economic sector or geographic region),

• whitelisting certain borrowers, brokers, or classifications thereof, to pursue, and

• blacklisting certain borrowers, brokers, or classifications thereof, to avoid.

Criteria such as these are volatile and so cannot be effectively advertised to the market. Such criteria are also confidential, implying characteristics of the lender's state and strategy.

For their part, brokers, and even more so borrowers, have limited exposure to all but a few of the available lenders. Borrowers may therefore have trouble identifying the most suitable lenders available, and brokers will have trouble meeting their fiduciary duty to their borrower clients in advising them of the most suitable lenders available. Desirably, a broker would be able to:

• identify those lenders most suitable for his buyer client, and

• document that he has discharged this duty.

Conventionally, brokers and borrowers shortlist a few lenders based upon advertised criteria and past experiences and submit loan applications to each lender using that lender's application form and process. One solution proposed has been to match loan applications against a database of published lending guidelines to create a shortlist of prospective lenders regardless of actual prior experience; however, as discussed above, the published guidelines are of limited use. Furthermore this approach still requires that the borrower or broker apply to each lender individually, using that lender's application form and process.

Another solution proposed has been to complete a generic electronic application, automatically translate the captured data into the specific form required by each prospective lender, and to automatically submit the translated data using that lender's application form and process. This brute force approach doesn't help to identify appropriate lenders and may lead lenders to detect and block such SPAM-like submissions.

What is needed instead is a secure network of lender, broker and borrower nodes that efficiently connects ad-hoc subnetworks of nodes having volatile and private connection criteria, such that:

• compatible lenders, brokers and borrowers are matched based on current actual criteria,

• incompatible lenders, brokers and borrowers do not have their time wasted,

• confidentiality of lenders' lending criteria is protected, and

• documentation proves that brokers have met their fiduciary duty to their borrower clients.

SUMMARY

The present invention is directed to this need.

According to one aspect of the present invention, there is provided a system to connect ad-hoc subnetworks of nodes having volatile and private connection criteria, having: a plurality of borrower client nodes, a plurality of lender client nodes, and a marketplace server in communication with the plurality of borrower client nodes and the plurality of lender client nodes, wherein the marketplace server has a database management system (DBMS) operable to manage a borrower object corresponding to each respective borrower client node and a lender object corresponding to each respective lender client node, wherein the DBMS is operable to manage a plurality of loan application objects respectively made by a plurality of the borrower objects and vetted by a plurality of the lender objects, and wherein the DBMS is operable to manage a plurality of loan offer objects respectively offered by a plurality of lender objects in response to vetted loan application objects.

The loan application object may be vetted by a lender object only after the loan application object has been subject to a filter operation. The loan application object may be vetted by a lender object after the loan application object has been the subject of a notify operation. The system may further include a plurality of broker client nodes, wherein the DBMS is operable to manage a broker object corresponding to each respective broker client node, and wherein at least some of the plurality of loan application objects are respectively submitted by a plurality of the broker objects.

The DBMS may be further operable to manage at least one property object encumbered by one of the plurality of loan application objects.

The DBMS may be further operable to manage a respective audit record object documenting each loan application object. In this regard, the system may further include at least one regulator client nodes, wherein the DBMS is operable to manage a regulator object corresponding to the at least one regulator client node, and wherein the at least one regulator client object is operable to audit each respective audit record object.

The system may further include at least one external data supplier server, wherein the DBMS is operable to manage at least one external data supplier object corresponding to the at least one external data supplier server, and wherein the at least one external data supplier object is operable to supply data from the at least one externa data supplier server to at least some of the plurality of loan application objects.

According to another aspect of the present invention, there is provided a computer-implemented method of connecting ad-hoc subnetworks of nodes having volatile and private connection criteria, comprising: instantiating a plurality of borrower objects corresponding to respective borrower client nodes, instantiating a plurality of lender objects corresponding to respective lender client nodes, instantiating a plurality of loan application objects in response to make application operations of respective borrower objects, at least some of the lender objects filtering at least some of the plurality of loan application objects, at least some of the lender objects vetting the respective filtered plurality of loan application objects, and instantiating a plurality of loan offer objects in response to offer operations of respective lender objects for at least some of the respective vetted plurality of loan application objects. The method may further include instantiating an audit record object documenting each respective loan application object.

DESCRIPTION

The invention will be more fully illustrated by the following detailed description of non-limiting specific embodiments in conjunction with the accompanying drawing figures. In the figures, similar elements and/or features may have the same reference label. Further, various elements of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar elements. If only the first reference label is identified in a particular passage of the detailed description, then that passage describes any one of the similar elements having the same first reference label irrespective of the second reference label.

1. Brief Description of the Drawings

Figure 1 is a UML 2 use-case diagram of participants and their participation in a lending marketplace implemented through an embodiment of a system of internetworked computing and communication resources in accordance with aspects of the present invention.

Figure 2 is a UML 2 deployment diagram of the system of Figure 1 , the system including as nodes: a marketplace server, a borrower client, a broker client, a lender client, a regulator client, and an external data supplier server.

Figure 3 is a deployment diagram of a general purpose programmable computing and communication resource that is configurable in accordance with aspects of the present invention to be embodied in the nodes of Figure 2.

Figure 4 is a UML 2 deployment diagram of client nodes that are configurable in accordance with aspect of the present invention to be embodied in the system of Figure 1 , including the borrower client, the broker client, the lender client, the regulator client.

Figure 5 is a UML 2 deployment diagram of server nodes that are configurable in accordance with aspect of the present invention to be embodied in the system of Figure 1 , including the marketplace server and the external data supplier server.

Figure 6 is a UML 2 class diagram of one embodiment of a domain model for communications over the system of Figure 1.

2. Detailed Description of Specific Embodiments

(a) Structure of Specific Embodiments

The structure of the invention will now be illustrated by explanation of specific, non-limiting, exemplary embodiments shown in the drawing figures and described in greater detail herein. These include embodiments of computing and communication methods, systems, networks, nodes, resources, devices, classes, artifacts and objects specially characterized and configured to provide the technical solutions to support this kind of communication in this kind of application and to satisfy the constraints imposed. Those skilled in the art will recognize that the nature of this kind of communication and this kind of application produces specific technical problems that require solution, as will be described further below. Figure 1 shows participants and their participation in a lending marketplace implemented through an embodiment of a system of internetworked computing and communication resources in accordance with aspects of the present invention.

As described herein, such a marketplace places significant technical demands on an underlying computing and communication network. In other words, unless the underlying computing and communication network addresses certain technical challenges, it will be difficult to successfully conduct the intended business over that network.

Some of the technical solutions taught by the present invention will be described through exemplary applications in the context of a loan marketplace; however, those skilled in the art will recognize that such technical solutions can be applied more broadly to deliver useful benefits in other sectors and applications.

A borrower seeking a loan from a lender submits a loan application in the marketplace. The borrower may do so directly (a direct borrower) or indirectly through a broker. In the latter case, the borrower (a physical borrower) and broker (a physical broker) may interact in person, for example at the borrower's home or the broker's office, or else the borrower (an online borrower) and the broker (an online broker) may interact electronically. In any of these arrangements, the borrower provides information about himself, the desired loan and any collateral property as appropriate for a loan application.

The submission of a loan application also creates an audit record of the application and begins negotiation of a loan. An external data supplier, for example a land title office, a real estate board, a valuator or a data broker may engage with the marketplace to augment the loan application by supplying additional value-added data, for example data about finances of the borrower, the value or title-state of collateral property, or relevant economic trends.

A lender filters loan applications submitted to the marketplace in accordance with the lenders volatile and private lending criteria and vets any of those loan applications that meet the filtering criteria. For loan applications that pass vetting, the lender may offer a loan, thus engaging with the borrower and/or broker in negotiating a loan.

A regulator is able to audit broker and lender compliance with regulation and obligation by reviewing audit records.

Figure 2 shows an internetwork (hereinafter "network") of computing and communication resources according to one embodiment of aspects of the present invention. This network is the foundation of a computing and communication system, for example an ecommerce system, for example a loan marketplace system.

The network connects together a number of nodes, some of which nodes may be categorized for convenience as servers and some of which nodes may be categorized for convenience as clients. The server nodes might include a marketplace server node and one or more external data supplier server node. The client nodes might include many borrower client nodes, many broker client nodes, many lender client nodes, and one or more regulator client nodes. The nodes may communicate via hypertext transfer protocol secure or other secure protocol.

The participants of Figure 1 participate in the system through appropriate nodes in the network. For example, a borrower would participate through a borrower client node, a broker would participate through a broker client node, a lender would participate through a lender client node and a regulator would participate through a regulator client node. Similarly, an external data supplier would participate through an external data supplier server node and an administrator of the marketplace itself would participate though a marketplace server node. Those skilled in the art will recognize that the network topology depicted in

Figure 2 has been simplified for clarity. For example, the network could be scaled to include multiple servers for each node. Furthermore, a particular server might be spread across multiple physical locations (or jurisdictions), which might increase, decrease or change over time, including on-the-fly, depending on resource demands and network management decisions. The network could be provided as a managed network service.

Those skilled in the art will understand that in an internetworked system an action is often the result of coordinated activities occurring at multiple nodes in the system. In the case of a system built on the Internet, these nodes are often distributed ad hoc and unpredictably across multiple jurisdictions. The actions as described and claimed herein are intended to encompass at least: (a) actions performed directly and completely within the jurisdiction of the patent, (b) actions coordinated within the jurisdiction but with at least some activities performed outside the jurisdiction, (c) actions coordinated outside the jurisdiction but with at least some activities performed within the jurisdiction, and (d) actions performed for the benefit of a node within the jurisdiction or a person within the jurisdiction using that node. An example of such coordination would be serving a layout for a web page from one node and serving content for insertion into the layout from one or more other nodes, including through the use of server-side scripting, client- side scripting, and Asynchronous JavaScript and XML (AJAX) techniques.

In general, each of the clients might be a duly configured general purpose programmable computing and communication resource, sometimes called a processing unit or a computing or communication device, for example a workstation, a desktop computer, a laptop computer, a tablet or a smartphone. Alternatively, a client might be a more specific or purpose-built device, for example a wearable device, a media viewer, a home entertainment system, a gaming system, a smart appliance, a point-of-sale device, a payment authorization terminal such as a PIN pad, or a kiosk.

Each server might similarly be a duly configured general purpose programmable computing and communication resource, including a farm of computing devices or one or more virtualized computers embodied as processes operating on a physical general purpose programmable computing and communication device. Such farmed or virtualized computers might themselves be distributed over their own local or wide area network, not shown. In essence, the servers and the clients are roles or functions performed in the system by properly configured computing and communication resources. Multiple roles or functions could be performed by one device and one role or function could be distributed over multiple devices. The specific character and configuration of a device (and more generally the hardware) and the network topology is important to the extent that it supports the performance of the assigned roles or functions.

Figure 3 shows an exemplary architecture for a typical computing and communication device embodying a node of Figure 2. These devices have a bottom hardware layer, a middle operating system layer and a top application program layer. Those skilled in the art will recognize the aspects in which like virtualized hardware and devices depart from like physical ones.

The hardware layer provides the device with computing and communication hardware, including: (a) a processor to execute processes of instructions and to compute data, (b) user-input hardware to receive input from a user, such as a keyboard (real or virtual), a selection device (for example a mouse, touchpad, touchscreen or other haptic sensor), or a microphone, (c) environmental sensors to receive input from the environment, such as a camera, a location sensor (e.g. GPS global positioning satellite receiver or cellular radio), an orientation sensor (e.g. compass, gyroscope), a movement sensor (e.g. GPS, accelerometer), or a scanner (e.g. an optical scanner, a magnetic scanner, a chip- and-PIN scanner, a field scanner (e.g. radio frequency identification - RFID, near field communication - NFC), a chemical scanner, or a biometric scanner), (d) user- output hardware to provide information to a user, such as a video display, a printer or a speaker, (e) mass storage such as electromagnetic, optical or nonvolatile solid-state media to store data and processing instructions, (f) memory such as read only memory and random access memory to store data and processing instructions, and (g) a network interface to support communication with other devices in accordance with known protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long term evolution (LTE), IEEE standard 802.1 1 (Wi-Fi), IEEE standard 802.3 (Ethernet), and transmission control protocol / internet protocol (TCP/IP), all interconnected by buses such as address and data buses and control lines such as interrupt and clock lines and such other connections and components as is conventionally required and known in the art.

Stored in a portion of the read only memory and the mass storage are the components of the operating system layer, for example LINUX^® or Microsoft^® Windows^® server^® or Mac^® OS X server^® for a device such as general purpose programmable computer configured as a server or LINUX^® or Microsoft^® Windows^® or Mac^® OS X^® for a general purpose programmable computer configured as a client or even Microsoft® Windows Phone^®, Apple^® iOS^®, Google^® Android^®, BlackBerry^® QNX^® or Symbian^®, for a portable such client device. The operating system layer provides the basic instructions to direct the processor how to interact with the other hardware described above and more generally how to perform the functions of a communication and computing device, including storing, accessing and computing data, and communicating with other devices. The operating system may be configured or extended to provide a web services framework, such as for distributed computing, such as the Windows Communication Foundation application programming interface in the .NET Framework. Those skilled in the art will recognize that some of the functionality described herein can be well-implemented using advanced HTML standards with related caching and client-side logic. Much like HTML 5 now has standards to adhere to various screen resolutions and other controls, those skilled in the art will appreciate that future versions of HTML may have standardization around device accessibility for cameras, accelerometers, biometric receivers, compasses and other input, output and sensing components, and that future evolutions of HTML may have the ability for browser plug-ins or browser extended session support that provide similar services to current app notifications, even after a browser window might have been closed.

The operating system layer presents an application program interface to the application program layer, so the processor can execute more sophisticated combinations of processes under the direction of higher level application programs stored in mass storage and loaded into random access memory for execution, for example the processes that will be elaborated below. This layer may also include more purpose-specific application programming interfaces. Figure 4 shows an embodiment of one of the client nodes. The client node may include a general purpose programmable computing and communication resource, for example a device hosting an operating system as an execution environment supporting a browser component and/or a dedicated application component for computing and communicating with the marketplace server. Figure 5 shows an embodiment of one of the server nodes. The server node may be include a general purpose programmable computing and communication resource, for example one or more devices hosting an operating system as an execution environment supporting a web server and/or an application server for computing and communicating with client nodes. The server node may also include a database management system ("DBMS) as an execution environment nested within the operating system. As illustrated, the DBMS manages artifacts corresponding to classes and hence objects that will be detailed below in the description of Figure 6, including borrower artifacts, broker artifacts, lender artifacts, regulator artifacts, external data supplier artifacts, property artifacts, loan application artifacts, loan offer artifacts, and audit record artifacts. Although this resource is named and described as a database for convenient illustration, those skilled in the art will recognize that other implementations could be used to provide the same function and such are contemplated within the scope of the present teaching, for example a key-value or persistent object store, and such other implementations are intended to be included within the broader meaning of the word database, to include any sustaining record storage, whether state-driven, transactional or otherwise.

The structure of software aspects of the system will now be described using an object-oriented paradigm. Those skilled in the art will recognize that there are many programming paradigms and analogous systems can be programmed in accordance with such paradigms without departing from the spirit of the present invention. For example, other programming paradigms include: agent-oriented, automata-based, component-based (including flow-based and pipelined), concatenative, concurrent computing (including relativistic programming), data-driven, declarative (including constraint, functional, dataflow (including cell-oriented and reactive) and logic (including abductive logic, answer set, constraint logic, functional logic, inductive logic, and uncertain inference (including markov logic and probabilistic logic))), event-driven (including service- oriented and time-driven), expression-oriented, feature-oriented, function-level, generic, imperative (including procedural), language-oriented (including discipline-specific, domain-specific, grammar-oriented (including dialecting) and intentional), metaprogramming (including automatic, reflective (including attribute-oriented) and template (including policy-based)), non-structured (including array and iterative), nondeterministic, parallel computing (including process-oriented), programming in the large/small, semantic, non-object oriented structured programming paradigms (including modular and recursive) and value- level.

Figure 6 shows an exemplary domain model for a loan marketplace hosted on the system and more specifically on the marketplace server. The domain model includes classes that correspond to the database artifacts managed by the marketplace server DBMS, namely a borrower class, a lender class, a loan application class, a broker class, a property class, and external data supplier class, a loan offer class, an audit record class, and a regulator class. The domain model also includes an external data class that is not managed by the marketplace server DBMS but by an external system. For simplicity and clarity, attributes and operations considered basic, utilitarian, or otherwise conventional have been omitted from Figure 6, for example setting, getting and CRUD type operations.

The borrower class includes attributes relevant to assessing the creditworthiness of the borrower, for example the financial strength of the borrower, the type of borrower (natural person, corporation, partnership, etc.) and the economic sector in which the borrower operates (residential, commercial, industrial, mining, forestry, oil & gas, retail, etc.). The borrower class includes operations relevant to applying for and obtaining a loan, for example a make application operation to prepare an application, a submit application operation to submit an application to the marketplace when unrepresented by a broker, and a respond to offer operation to negotiate with a lender.

The broker class exists for situations when a borrower is represented by a broker. The broker class includes attributes relevant to representing a borrower, for example a whitelist of lenders who in a broker's judgement have performed well in the past or otherwise have a good reputation or a blacklist of lenders who in a broker's judgement have performed poorly in the past or otherwise have a bad reputation, to prioritize or filter such lenders. The broker class includes operations relevant to representing a borrower, for example an edit application operation to edit an application initiated by a borrower, a submit application operation to submit an application to the marketplace, and a respond to offer operation to negotiate with a lender.

The loan application class includes attributes relevant to assessing the desirability of a loan to a lender, for example an amount, a type, a description, a priority, an advance structure, a cash flow, an exit strategy, a borrower mandate and a borrower covenant strength. The loan application class may also include attributes relevant to the borrower, for example a whitelist of lenders who in a borrower's or broker's judgement have performed well in the past or otherwise have a good reputation or a blacklist of lenders who in a borrower's or broker's judgement have performed poorly in the past or otherwise have a bad reputation, to prioritize or filter such lenders. This attribute might also filter for other criteria, such as a lender's experience with a particular market, sector or the like. The loan application class includes operations relevant to advancing a loan application, for example a check completeness operation to ensure all mandatory data is present and all having designated formats, ranges or the like are compliant, a list application operation to list complete applications on the marketplace, and a delist application operation to delist applications from the marketplace, for example stale applications or applications for which loans have been made.

The property class includes attributes relevant to assessing property offered as collateral in a loan application, for example a location of the property, a value for the property, and an asset class for the property (detached house, vacant land, office tower, factory, etc.). In this regard, a borrower would have an interest in a property, and the property would be encumbered by the borrower's loan application.

The external data supplier class exists to facilitate the merger of data external to the marketplace into borrower, broker, loan application, or property objects as appropriate. Such external data would be in addition to data provided by a borrower and/or broker, and might include financial information regarding a borrower, valuation or encumbrance data about a property, or more macroscopic trend data generally relevant to assessing loan applications. In this regard, the external data supplier class functions as an interface collecting structured data from an external database and supplying it in an appropriate form to the DBMS maintained on the marketplace server. The lender class attributes and operations, as illustrated private for confidentiality, are relevant to identifying and vetting only those loan applications of most interest to a lender. The lender class includes attributes for: the lender's cost of loans, compliance constraints mandated by regulators, balance constraints for asset allocation and risk mitigation, strategic preferences (loan size, borrower type, etc.) and whitelist / blacklist of borrowers and/or brokers who in the lender's judgement have performed well / poorly in the past or otherwise have a good / bad reputation, to prioritize or filter such borrowers or brokers. The lender class includes operations for: filtering the loan applications listed on the marketplace server to include only those meeting the lender's current criteria, notifying the lender when new loan applications are listed on the marketplace server that meet the lender's current criteria, vetting loan applications that are the subject of such filtering or notifying (for example presenting such loan applications for review and analysis), and offering a loan when a loan application has passed such vetting.

Those skilled in the art will recognize that filtering operations may include user-configurable tests, for example threshold tests, ratio tests, and stress tests, in single or multiple dimensions, whether configured by an individual end-user or propagated by an administrator. Those skilled in the art will recognize that filtering operations may also include data-driven automated or semi-automated filters generated with the assistance of artificial intelligence, expert systems, or machine-learning, for example reflecting a lender's past interest, behaviour or success, or volatile market changes.

The loan offer class includes attributes for defining an offered loan, for example: an amount, an interest rate, a term, conditions, an offer expiry time, and an indication whether the offer has been accepted. In some embodiments, the loan offer might be countered by the relevant broker or borrower until convergence or expiry. The loan offer also may include a charge commission operation, wherein a commission on the loan amount is charged to the lender by the marketplace when a loan offer has been designated as accepted. The audit record class documents a timestamped history state of a loan application, including when it was listed, what universe of lenders it was available to (whitelist / blacklist), and when it was delisted, and in some embodiments, which lender filters / notifications it matched, and in some embodiments, which lenders vetted it, and in some embodiments which lenders extended loan offers.

The regulator class includes attributes and operations relevant to auditing the compliance of market participants, most notably brokers and lenders, through auditing audit records.

(b) Operation of Specific Embodiments

With reference now to Figure 6, the operation of these specific embodiments will now be described. In general, the marketplace server instantiates, maintains, operates and destroys objects of the appropriate classes corresponding to borrowers, lenders, brokers, regulators and external data suppliers interacting with the system with respect to loan applications, property, loan offers and audit records.

When a new borrower, lender, or broker joins the marketplace, the marketplace server instantiates a corresponding object as part of a registration process in which registration information is solicited to initialize the attributes of the instantiated object.

New regulators and external data suppliers joining the marketplace would also lead to the instantiation of corresponding objects; however, this process would in general be performed by marketplace administrators for reasons respectively of security (regulator access permissions to audit records) and customization (mapping external databases to the marketplace server DBMS).

Borrowers, either on their own or through brokers, will make and edit loan applications, which may include property as collateral, such that the marketplace server will instantiate and maintain corresponding loan application and property objects. The attributes of borrower, loan application and property objects may be further affected as a result of the supply data operation of external data supplier objects, which collect and supply data from databases external to the marketplace server. When such loan applications have been submitted and successfully checked for completeness, they are listed on the marketplace.

Particularly in a fast-moving, hot sellers' market, a borrower may wish to apply to prequalify for a loan, in other words, prequalify for a loan having specific characteristics based on the borrower's attributes without reference to a specific property. Those skilled in the art will recognized that the marketplace server is configured to handles this subset of transaction.

The operations relevant to a loan application (eg make application, edit application, submit application, check completeness) may provide more than just syntactic completeness, but may further include a screening analysis of the application against current or historic market data or benchmarks, for example to provide early feedback on an application, recommendations for improving the application, and an opportunity to help a borrower manage his expectations.

Lenders, interacting with the marketplace server via their lender objects, can establish current criteria (lender object attributes) for operating loan application filters within the marketplace and also generating notifications, including external push notifications (e.g. email, sms, mms) of newly listed loan applications.

When a lender identifies a loan application of interest, it can be vetted (reviewed and evaluated) and should it pass vetting, a loan offer object can be instantiated and made available to the broker and/or borrower who submitted the associated loan application object. Should negotiations on the loan offer converge, a loan will be designated as accepted and a commission may be charged to the lender by the marketplace.

Throughout these operations, audit record objects are instantiated and maintained to document the history state of each loan application. A regulator can audit these audit records. (c) Description Summary

Thus, it will be seen from the foregoing embodiments and examples that there has been described a way to provide computing and communication infrastructure to support connecting ad-hoc subnetworks of nodes having volatile and private connection criteria.

While specific embodiments of the invention have been described and illustrated, such embodiments should be considered illustrative of the invention only and not as limiting the invention. In particular, all quantities described have been determined empirically and those skilled in the art might well expect a wide range of values surrounding those described to provide similarly beneficial results.

It will be understood by those skilled in the art that various changes, modifications and substitutions can be made to the foregoing embodiments without departing from the principle and scope of the invention. For example, systems having more or less types of participants, nodes, artifacts, and classes may still fall within the scope of the invention. For example, such a system might have no regulator, regulator node, regulator artifact, or regulator class. For example, such a system might have no external data supplier, external data supplier node, external data supplier artifact, or external data supplier class. For example, such a system might have no property class where no loans will be secured with collateral, and some loan application objects may not be associated with property objects where such loan applications don't offer security or collateral. For example, such a system might be restricted to assisting lenders to identify (filter, notify, vet) loans of interest and identify the associated broker and/or borrower, but not assist in presenting, negotiating or closing a loan offer, which activity would occur outside the system, and hence such a system would not have loan offer artifacts or classes; in such as system, a commission might still be due upon acceptance of an offer outside the system, and such acceptance might be verified by the system via an external data supplier with reference to borrower, broker, lender, loan and property objects. While the invention has been described as having particular application for a loan marketplace, those skilled in the art will recognize it has wider application.

Claims

1 . A system to connect ad-hoc subnetworks of nodes having volatile and private connection criteria, comprising: a) a plurality of borrower client nodes, b) a plurality of lender client nodes, and c) a marketplace server in communication with the plurality of borrower client nodes and the plurality of lender client nodes, wherein the marketplace server has a database management system (DBMS) operable to manage a borrower object corresponding to each respective borrower client node and a lender object corresponding to each respective lender client node, wherein the DBMS is operable to manage a plurality of loan application objects respectively made by a plurality of the borrower objects and vetted by a plurality of the lender objects, and wherein the DBMS is operable to manage a plurality of loan offer objects respectively offered by a plurality of lender objects in response to vetted loan application objects.

2. A system as claimed in claim 1 , wherein a loan application object is vetted by a lender object only after the loan application object has been subject to a filter operation.

3. A system as claimed in claim 2, wherein a loan application object is vetted by a lender object after the loan application object has been the subject of a notify operation.

4. A system as claimed in claim 1 , further including a plurality of broker client nodes, wherein the DBMS is operable to manage a broker object corresponding to each respective broker client node, and wherein at least some of the plurality of loan application objects are respectively submitted by a plurality of the broker objects.

5. A system as claimed in claim 4, wherein the DBMS is further operable to manage at least one property object encumbered by one of the plurality of loan application objects.

6. A system as claimed in claim 5, wherein the DBMS is further operable to manage a respective audit record object documenting each loan application object.

7. A system as claimed in claim 6, further including at least one regulator client nodes, wherein the DBMS is operable to manage a regulator object corresponding to the at least one regulator client node, and wherein the at least one regulator client object is operable to audit each respective audit record object.

8. A system as claimed in claim 7, further including at least one external data supplier server, wherein the DBMS is operable to manage at least one external data supplier object corresponding to the at least one external data supplier server, and wherein the at least one external data supplier object is operable to supply data from the at least one externa data supplier server to at least some of the plurality of loan application objects.

9. A computer-implemented method of connecting ad-hoc subnetworks of nodes having volatile and private connection criteria, comprising: a) instantiating a plurality of borrower objects corresponding to respective borrower client nodes, b) instantiating a plurality of lender objects corresponding to respective lender client nodes, c) instantiating a plurality of loan application objects in response to make application operations of respective borrower objects, d) at least some of the lender objects filtering at least some of the plurality of loan application objects, e) at least some of the lender objects vetting the respective filtered plurality of loan application objects, and f) instantiating a plurality of loan offer objects in response to offer operations of respective lender objects for at least some of the respective vetted plurality of loan application objects.

10. The method of claim 9, further including instantiating an audit record object documenting each respective loan application object.