WO2000022561A2

WO2000022561A2 - System, method and article of manufacture for flexible billing over an open communication network

Info

Publication number: WO2000022561A2
Application number: PCT/US1999/023920
Authority: WO
Inventors: L. Keith Stephens; Reid Rutherford; Glenn Kramer; Robert Gardner
Original assignee: Stephens L Keith; Reid Rutherford; Glenn Kramer; Robert Gardner
Priority date: 1998-10-14
Filing date: 1999-10-14
Publication date: 2000-04-20
Also published as: AU1113400A; WO2000022561A3

Abstract

An architecture that provides a server that communicates bidirectionally with a gateway over a first communication link, over which service requests flow to the server (1700) for one or more Newcos and/or buyer or vendors is disclosed. Service requests result in Newco specific transactions that are transmitted to the gateway for further processing on existing host applications. By presenting the appropriate credentials, the Newco could utilize any other computer attached to the Internet utilizing a SSL or SET protocol to query the issuer remotely and obtain capture information, payment administration information (1780), inventory control information, audit information and process buyer or vendor satisfaction information. Then, digital certificates and a digital signature are exchanged to ensure that both parties are who they say they are. With an appropriate issuer gateway, the Newco can do an authorization routed directly to the issuer, without going through the acquirer.

Description

SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR

FLEXIBLE BILLING OVER AN OPEN COMMUNICATION NETWORK

Field Of The Invention The present invention relates to the secure, electronic processing of drafts issued by buyers for commercial transactions in exchange for goods and services, and more specifically, to a system, method and article of manufacture that creates, transmits and processes drafts in lieu of cash or credit card transactions.

The present invention relates to an electronic representation of a monetary system for implementing electronic money payments as an alternative medium of economic exchange to cash, checks, credit and debit cards, and electronic funds transfer. The Electronic-Monetary System is a hybrid of currency, check, card payment systems, and electronic funds transfer systems, possessing many of the benefits of these systems with few of their limitations. The system utilizes electronic representations of money which are designed to be universally accepted and exchanged as economic value by subscribers of the monetary system.

Today, approximately 350 billion coin and currency transactions occur between individuals and institutions every year. The extensive use of coin and currency transactions has limited the automation of individual transactions such as purchases, fares, and bank account deposits and withdrawals. Individual cash transactions are burdened by the need to have the correct amount of cash or providing change therefor. Furthermore, the handling and managing of paper cash and coins is inconvenient, costly and time consuming for both individuals and financial institutions.

Although checks may be written for any specific amount up to the amount available in the account, checks have very limited transferability and must be supplied from a physical inventory.

Paper-based checking systems do not offer sufficient relief from the limitations of cash transactions, sharing many of the inconveniences of handling currency while adding the inherent delays associated with processing checks. To this end, economic exchange has striven for greater convenience at a lower cost, while also seeking improved security.

Automation has achieved some of these qualities for large transactions through computerized electronic funds transfer ("EFT") systems. Electronic funds transfer is essentially a process of value exchange achieved through the banking system's centralized computer transactions. EFT services are a transfer of payments utilizing electronic "checks," which are used primarily by large commercial organizations.

The Automated Clearing House (ACH) where a user can enter a pre-authorized code and download information with billing occurring later, and a Point Of Sale (POS) system where a transaction is processed by connecting with a central computer for authorization for the transaction granted or denied immediately are examples of EFT systems that are utilized by retail and commercial organizations. However, the payments made through these types of EFT systems are limited in that they cannot be performed without the banking system. Moreover,

ACH transactions usually cannot be utilized during off business hours.

Home Banking bill payment services are examples of an EFT system used by individuals to make payments from a home computer. Currently, home banking initiatives have found few buyer or vendors. Of the banks that have offered services for payments, account transfers and information over the telephone lines using personal computers, less than one percent of the bank's buyer or vendors are using the service. One reason that Home Banking has not been a successful product is because the buyer or vendor cannot deposit and withdraw money as needed in this type of system.

Current EFT systems, credit cards, or debit cards, which are used in conjunction with an on-line system to transfer money between accounts, such as between the account of a Newco and that of a buyer or vendor, cannot satisfy the need for an automated transaction system providing an ergonomic interface.

To implement an automated, convenient transaction that can dispense some form of economic value, there has been a trend towards off-line payments. For example, numerous ideas have been proposed for some form of "electronic money" that can be used in cashless payment transactions as alternatives to the traditional currency and check types of payment systems.

The more well known techniques include magnetic stripe cards purchased for a given amount and from which a prepaid value can be deducted for specific purposes. Upon exhaustion of the economic value, the cards are thrown away. Other examples include memory cards or so called smart cards which are capable of repetitively storing information representing value that is likewise deducted for specific purposes.

It is desirable for a computer operated under the control of a buyer or seller to obtain a FlexiDraft in lieu of cash without tapping into an existing line of credit with a bank. It is another feature of a preferred embodiment in accordance with the invention to allow a vendor to select to have guaranteed payment by the issuer of the FlexiDraft to eliminate any risk of nonpayment. This guarantee service could be purchased on the basis of the credit rating of the client or other objective criteria. It is a further feature of a preferred embodiment in accordance with the invention to provide a collection of FlexiDrafts to be pooled to facilitate a large debt instrument to be transferred at better terms than each of the separate debts within the pool. Moreover, FlexiDrafts could be utilized to outsource a portion or all of the accounts at terms that were not previously available and line item detail on each transaction that was previously unavailable. In a preferred embodiment, the FlexiDraft is transmitted by a computer operating under the control of the buyer or vendor over a private or a publically accessible packet-switched network (e.g., the Internet) to the computer operating under the control of a FlexiDraft issuer, without risking the exposure of the information to interception by third parties that have access to the network, and to assure that the information is from an authentic source.

One such attempt to provide such a secure transmission channel is a secure payment technology such as Secure Electronic Transaction (hereinafter "SET"), jointly developed by the Visa and MasterCard card associations, and described in Visa and MasterCard's Secure Electronic Transaction (SET) Specification, February 23, 1996, hereby incorporated by reference. Other such secure payment technologies include Secure Transaction Technology ("STT"), Secure Electronic Payments Protocol ("SEPP"), Internet Keyed Payments ("iKP"), Net Trust, and

Cybercash Credit Payment Protocol. One of ordinary skill in the art readily comprehends that any of the secure payment technologies can be substituted for the SET protocol without undue experimentation. Such secure payment technologies require the buyer or vendor to operate software that is compliant with the secure payment technology, interacting with third-party certification authorities, thereby allowing the buyer or vendor to transmit encoded information to a Newco, some of which may be decoded by the Newco, and some of which can be decoded only by a payment gateway specified by the buyer or vendor. Another such attempt to provide such a secure transmission channel is a general-purpose secure communication protocol such as Netscape, Inc.'s Secure Sockets Layer (hereinafter "SSL") , as described in Freier, Karlton & Kocher (hereinafter "Freier"), The SSL Protocol Version 3.0, March 1996, and hereby incorporated by reference. SSL provides a means for secure transmission between two computers. SSL has the advantage that it does not require special- purpose software to be installed on the buyer or vendor's computer because it is already incorporated into widely available software that many people utilize as their standard Internet access medium, and does not require that the buyer or vendor interact with any third-party certification authority. Instead, the support for SSL may be incorporated into software already in use by the buyer or vendor, e.g., the Netscape Navigator World Wide Web browsing tool.

However, although a computer on an SSL connection may initiate a second SSL connection to another computer, a drawback to the SSL approach is each SSL connection supports only a two- computer connection. Therefore, SSL does not provide a mechanism for transmitting encoded information to a Newco for retransmission to a payment gateway such that a subset of the information is readable to the payment gateway but not to the Newco. Although SSL allows for robustly secure two-party data transmission, it does not meet the ultimate need of the electronic commerce market for robustly secure three-party data transmission. Other examples of general- purpose secure communication protocols include Private Communications Technology ("PCT") from Microsoft, Inc., Secure Hyper-Text Transport Protocol ("SHTTP") from Terisa Systems, Shen, Kerberos, Photuris, Pretty Good Privacy ("PGP") which meets the IPSEC criteria. One of ordinary skill in the art readily comprehends that any of the general-purpose secure communication protocols can be substituted for the SSL transmission protocol without undue experimentation.

More recently, banks desired an Internet payment solution that emulates existing Point of Sale

(POS) applications that are currently installed on their host computers, and require minimal changes to their host systems. This is a critical requirement since any downtime for a bank's host computer system represents an enormous expense. Currently, VeriFone supports over fourteen hundred different payment-related applications. The large number of applications is necessary to accommodate a wide variety of host message formats, diverse methods for communicating to a variety of hosts with different dial-up and direct-connect schemes, and different certification around the world. In addition, there are a wide variety of business processes that dictate how a Point of Sale (POS) terminal queries a user for data and subsequently displays the data. Also, various vertical market segments, such as hotels, car rental agencies, restaurants, retail sales, mail sales / telephone sales require interfaces for different types of data to be entered, and provide different discount rates to companies for complying with various data types. Moreover, a plethora of report generation mechanisms and formats are utilized by Newcos that banking organizations work with.

Internet-based payment solutions require additional security measures that are not found in conventional POS terminals. This additional requirement is necessitated because Internet communication is done over publicly-accessible, unsecured communication line in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional Newco and an acquiring bank. Thus, it is critical that any solution utilizing the Internet for a communication backbone, employ some form of cryptography.

As discussed above, the current state-of-the-art in Internet based payment processing is a protocol referred to as SET. Since the SET messages are uniform across all implementations, banks cannot differentiate themselves in any reasonable way. Also, since SET is not a proper superset of all protocols utilized today, there are bank protocols which cannot be mapped or translated into SET because they require data elements for which SET has no placeholder. Further, SET only handles the message types directly related to authorizing and capturing credit card transactions and adjustments to these authorizations or captures. In a typical POS terminal in the physical world, these messages comprise almost the entire volume of the total number of messages between the Newco and the authorizing bank, but only half of the total number of different message types. These message types, which are used infrequently, but which are critical to the operation of the POS terminal must be supported for proper transaction processing.

SUMMARY OF THE INVENTION

According to a broad aspect of a preferred embodiment of the invention, secure transmission of a draft is provided between a plurality of computer systems over a public communication system, such as the Internet. A connection is created between two computer systems using a public network, such as the Internet, to connect the computers. Then, digital certificates and a digital signature are exchanged to validate the parties.

The drafts are designed to scale from very small to very large payments. The drafts are issued from a third party entity which will be referred to as Newco for purposes of illustrating a preferred embodiment. Newco issues the drafts as a substitute for checks, credit cards, smart cards or cash. The drafts utilize payment terms that vary based on the size of the transaction, the credit rating of the requester and other commercial terms as described below. The draft combines a deposit account, payment instrument and short term loan into one convenient instrument that allows a company to better manage its cash flow. Existing fraud databases operated by Visa, Master Card, American Express and others may be utilized to adjust terms as a function of credit rating or other available information.

DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages are better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

Figure 1 is a block diagram of a representative hardware environment in accordance with a preferred embodiment;

Figure 2 is a block diagram of the system in accordance with a preferred embodiment;

Figure 3 is a block diagram of the system in accordance with a preferred embodiment;

Figure 4 is a block diagram of the system in accordance with a preferred embodiment;

Figures 5A-5D is a combined authorization block diagram in accordance with a preferred embodiment; Figure 6 is a certificate authorization form in accordance with a preferred embodiment;

Figure 7 is a diagram of the entities involved in a standard commercial purchase transaction in accordance with a preferred embodiment;

Figure 8 is a flowchart of a standard commercial purchase transaction in accordance with a preferred embodiment;

Figure 9 is a diagram of the entities involved in a commercial purchase involving a factor in accordance with a preferred embodiment;

Figure 10 is a flowchart of a commercial purchase involving a factor in accordance with a preferred embodiment;

Figure 11 is a diagram of the entities involved in a commercial purchase transaction involving securitized lending in accordance with a preferred embodiment;

Figure 12 is a flowchart of a commercial purchase transaction involving securitized lending in accordance with a preferred embodiment;

Figure 13 is a diagram of the entities involved in a commercial purchase transaction involving a factor and an investment management service in accordance with a preferred embodiment;

Figure 14 is a flowchart of a commercial purchase transaction involving a factor and an investment management service;

Figure 15 is a diagram of the entities involved in a commercial purchase transaction using FlexiDrafts, where some entity roles have been combined in accordance with a preferred embodiment;

Figure 16 is a diagram of the entities involved in a commercial purchase transaction using

FlexiDrafts, where entity roles have been separated in accordance with a preferred embodiment; Figure 17 is a flowchart of a commercial purchase transaction using FlexiDrafts, where entity roles have been separated in accordance with a preferred embodiment;

Figure 18 is a flowchart showing Buyer's actions when paying by check or wire, and when paying by FlexiDraft in accordance with a preferred embodiment;

Figure 19 is a representation of the Cash Flow Wizard interest rate curve screen for the Buyer in accordance with a preferred embodiment;

Figure 20 is a representation of the Cash Flow Wizard cash management screen for Buyer or Vendor in accordance with a preferred embodiment;

Figure 21 is a flowchart showing Vendor's actions when getting paid by check or wire, and when getting paid by FlexiDraft in accordance with a preferred embodiment;

Figure 22 is a representation of the Cash Flow Wizard interest rate curve screen for the Vendor in accordance with a preferred embodiment;

Figure 23 shows the calculation of Return on Assets for the case where the Vendor gets paid before the Buyer pays in accordance with a preferred embodiment;

Figure 24 shows the calculation of Return on Assets for the case where the Buyer pays before the Vendor gets paid in accordance with a preferred embodiment;

Figure 25 shows a matrix of the Return on Assets as a function of the percentage of total time that the Buyer pays early and the percentage of total time the Vendor gets paid early in accordance with a preferred embodiment;

Figure 26 is a representation of the Cash Flow Wizard ROA calculation screen for NewCo (or

ServiceCo and FinCo); and Figure 27 is a depiction of the OFX client/server model for financial transaction processing in accordance with a preferred embodiment.

DETAILED DESCRIPTION A preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a central processing unit 10, such as a microprocessor, and a number of other units interconnected via a system bus 12. The workstation shown in Figure 1 includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk storage units 20 to the bus 12, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen (not shown) to the bus 12, communication adapter 34 for connecting the workstation to a communication network (e.g., a data processing network) and a display adapter 36 for connecting the bus 12 to a display device 38. The workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the present invention may also be implemented on platforms and operating systems other than those mentioned.

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic messaging system such that a set of OOP classes and objects for the messaging interface can be provided. OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program. An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task. OOP, therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.

In general, OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run- time through a component integration architecture. A component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture.

It is worthwhile to differentiate between an object and a class of objects at this point. An object is a single instance of the class of objects, which is often just called a class. A class of objects can be viewed as a blueprint, from which many objects can be formed.

OOP allows the programmer to create an object that is a part of another object. For example, the object representing a piston engine is said to have a composition-relationship with the object representing a piston. In reality, a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.

OOP also allows creation of an object that "depends from" another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition. A ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic. In this case, the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it. The object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.

When the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class. However, the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons.

Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, etc.). To access each of these functions in any piston engine object, a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.

With the concepts of composition-relationship, encapsulation, inheritance and polymoφhism, an object can represent just about anything in the real world. In fact, our logical perception of the reality is the only limit on determining the kinds of things that can become objects in object- oriented software. Some typical categories are as follows:

• Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system.

• Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.

• An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities. • An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane. With this enormous capability of an object to represent just about any logically separable matters, OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.

If 90% of a new OOP software program consists of proven, existing components made from preexisting reusable objects, then only the remaining 10% of the new software project has to be written and tested from scratch. Since 90% already came from an inventory of extensively tested reusable objects, the potential domain from which an error could originate is 10% of the program. As a result, OOP enables software developers to build objects out of other, previously built, objects.

This process closely resembles complex machinery being built out of assemblies and sub- assemblies. OOP technology, therefore, makes software engineering more like hardware engineering in that software is built from existing components, which are available to the developer as objects. All this adds up to an improved quality of the software as well as an increased speed of its development.

Programming languages are beginning to fully support the OOP principles, such as encapsulation, inheritance, polymorphism, and composition-relationship. With the advent of the C++ language, many commercial software developers have embraced OOP. C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, common lisp object system (CLOS), and Eiffel. Additionally, OOP capabilities are being added to more traditional popular computer programming languages such as Pascal.

The benefits of object classes can be summarized, as follows:

• Objects and their corresponding classes break down complex programming problems into many smaller, simpler problems. • Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures. • Subclassing and inheritance make it possible to extend and modify objects through deriving new kinds of objects from the standard classes available in the system. Thus, new capabilities are created without having to start from scratch.

• Polymorphism and multiple inheritance make it possible for different programmers to mix and match characteristics of many different classes and create specialized objects that can still work with related objects in predictable ways.

• Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real- world objects and the relationships among them.

• Libraries of reusable classes are useful in many situations, but they also have some limitations. For example: • Complexity. In a complex system, the class hierarchies for related classes can become extremely confusing, with many dozens or even hundreds of classes.

• Flow of control. A program written with the aid of class libraries is still responsible for the flow of control (i.e., it must control the interactions among all the objects created from a particular library). The programmer has to decide which functions to call at what times for which kinds of objects.

• Duplication of effort. Although class libraries allow programmers to use and reuse many small pieces of code, each programmer puts those pieces together in a different way. Two different programmers can use the same set of class libraries to write two programs that do exactly the same thing but whose internal structure (i.e., design) may be quite different, depending on hundreds of small decisions each programmer makes along the way. Inevitably, similar pieces of code end up doing similar things in slightly different ways and do not work as well together as they should.

Class libraries are very flexible. As programs grow more complex, more programmers are forced to reinvent basic solutions to basic problems over and over again. A relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.

Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others. In the early days of procedural programming, the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.

The development of graphical user interfaces began to turn this procedural programming arrangement inside out. These interfaces allow the user, rather than program logic, to drive the program and decide when certain actions should be performed. Today, most personal computer software accomplishes this by means of an event loop which monitors the mouse, keyboard, and other sources of external events and calls the appropriate parts of the programmer's code according to actions that the user performs. The programmer no longer determines the order in which events occur. Instead, a program is divided into separate pieces that are called at unpredictable times and in an unpredictable order. By relinquishing control in this way to users, the developer creates a program that is much easier to use. Nevertheless, individual pieces of the program written by the developer still call libraries provided by the operating system to accomplish certain tasks, and the programmer must still determine the flow of control within each piece after it's called by the event loop. Application code still "sits on top of the system.

Even event loop programs require programmers to write a lot of code that should not need to be written separately for every application. The concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application. Application frameworks reduce the total amount of code that a programmer has to write from scratch. However, because the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit. The framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).

A programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.

Thus, as is explained above, a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.

There are three main differences between frameworks and class libraries:

• Behavior versus protocol. Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program. A framework, on the other hand, provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.

• Call versus override. With a class library, the code the programmer instantiates objects and calls their member functions. It's possible to instantiate and call objects in the same way with a framework (i.e., to treat the framework as a class library), but to take full advantage of a framework's reusable design, a programmer typically writes code that overrides and is called by the framework. The framework manages the flow of control among its objects. Writing a program involves dividing responsibilities among the various pieces of software that are called by the framework rather than specifying how the different pieces should work together.

Implementation versus design. With class libraries, programmers reuse only implementations, whereas with frameworks, they reuse design. A framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.

Thus, through the development of frameworks for solutions to various problems and programming tasks, significant reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes Hypertext Markup Language (HTML) to implement documents on the Internet together with a general-purpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol - HTTP/1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISO Standard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML).

To date, Web development tools have been limited in their ability to create dynamic Web applications which span from client to server and interoperate with existing computing resources. Until recently, HTML has been the dominant technology used in development of Web-based solutions. However, HTML has proven to be inadequate in the following areas:

• Poor performance;

• Restricted user interface capabilities; • Can only produce static Web pages;

• Lack of interoperability with existing applications and data; and

• Inability to scale.

Sun Microsystem's Java language solves many of the client-side problems by:

• Improving performance on the client side;

• Enabling the creation of dynamic, real-time Web applications; and

• Providing the ability to create a wide variety of user interface components.

With Java, developers can create robust User Interface (UI) components. Custom "widgets" (e.g. real-time stock tickers, animated icons, etc.) can be created, and client-side performance is improved. Unlike HTML, Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance. Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.

Sun's Java language has emerged as an industry-recognized language for "programming the Internet." Sun defines Java as: "a simple, object-oriented, distributed, inteφreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword- compliant, general-puφose programming language. Java supports programming for the Internet in the form of platform-independent Java applets." Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content" to Web documents (e.g. simple animations, page adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g. Netscape Navigator) by copying code from the server to client. From a language standpoint,

Java's core feature set is based on C++. Sun's Java literature states that Java is basically "C++, with extensions from Objective C for more dynamic method resolution".

Another technology that provides similar function to JAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the

Internet and personal computers. ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named

"Jakarta." ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention.

System software is provided in accordance with a preferred embodiment to facilitate the processing of electronic FlexiDrafts issued by buyers in commercial transactions. So, for example, the software under the control of the computer processor utilizes logic to create, transmit and receive the electronic FlexiDrafts. The FlexiDrafts are accumulated and sold in packages to financial institutions for resale in the aggregate. The FlexiDrafts are defined by commercial codes as conventional drafts that are payable on a specific future date, but with certain with predefined payment options for both the issuer and recipient of the FlexiDraft. So, for example, a buyer could prepay the FlexiDraft at a significant discount if the buyer were willing to pay the FlexiDraft off earlier than the maturation date of the FlexiDraft. Moreover, as described above, the payment obligations incurred by a set of buyers utilizing the FlexiDrafts may be aggregated and securitized, creating debt instruments that may be sold in financial markets.

Both the vendors and the buyers have increased flexibility for paying and receiving funds by utilizing the FlexiDraft model in accordance with a preferred embodiment. Vendors pay a discount fee to get money earlier and buyers can earn interest by paying early. Or, Vendors can earn interesy by accepting late payment, and Buyers can pay later, but with an interest penalty. The transfer process and approval process is also streamlined in accordance with a preferred embodiment by accommodating wire transfers, ACH, checks and electronic cash. Companies can utilize a FlexiDraft in accordance with a preferred embodiment to help to manage cash flow and outsourcing of accounts receivables and accounts payables through modular organization of the detailed FlexiDraft information. Vendors can obtain money rapidly without the overhead and inefficiency of negotiating funds by establishing a line of credit at a bank or other financial institution. For a high risk buyer, a FlexiDraft provides a company with better vendor payment terms with risk deferral through buyer payments into an insurance pool to offset the risk of a poor credit rating. This approach, facilitated by a preferred embodiment also allows the buyer to avoid utilizing an onerous Charge

On Delivery (COD) payment method. Alternatively, Vendors can pay guarantee fees, much like check guarantee fees to guarantee services, to ensure they will get paid no matter what the Buyer does.

Moreover, a buyer can obtain line item detail at the discretion of the vendor providing much of the information currently provided by a coφorate credit card at much better payment terms. Vendors can provide as much or as little detail as required to provide the quality of service the vendor feels is appropriate for the buyer. Finally, a buyer can outsource portions of their accounts payable utilizing one or more FlexiDrafts on payment terms negotiated with Newco.

FlexiDraft Initiation Figure 2 presents a block diagram of a system flow diagram in accordance with a preferred embodiment. A vendor 200 sells merchandise or provides services to a buyer 210. The buyer 210 contacts 250 Newco 220 to obtain a FlexiDraft which is issued by Newco on payment terms negotiated as a function of the amount of business buyer does with Newco, buyer's credit rating, payment history of buyer and other information available from commercially available databases. One of ordinary skill in the art will readily comprehend that this communication 250 can transpire in realtime over a communication link such as a wireless network, a dialup line, a TCP/IP link such as the Internet, or by mail, fax or other slower communication medium. Newco 220 sends the FlexiDraft 270 to the vendor 200 for the merchandise and transfers responsibility for collecting 275 from the buyer 210 to Newco 220. The payment terms and schedule can be negotiated as the FlexiDraft if issued or based on a pre-established relationship between the vendor 200 and Newco 220. Newco 220 in turn packages up a collection of one or more of the FlexiDrafts into a pool of collectable debt organized as a securitized debt instrument(s) and sells 265 the instrument to a financial institution 230. The financial institution

230 pays the vendor 200 according to the payment schedule associated with the FlexiDraft as relayed by Newco 220. The financial instution is paid 280 by the buyer in accordance with the payment terms of the FlexiDraft 260 to the vendor 200. In accordance with the embodiment presented in Figure 2, a buyer 210 utilizes Newco 220 as a service rather than installing sophisticated communication software on site to issue and reconcile FlexiDrafts. By utilizing Newco, it is impossible for a competitor to monitor buyer's internet transaction processing to ascertain who the buyer's vendors are. Because of the expectation of instant processing of FlexiDrafts at any hour of the day or night, it will be necessary for Newco to provide twenty-four hour a day, seven day a week processing with additional realtime confirmation of receipt of FlexiDraft issuance instructions. Additional security between the buyer and Newco may be required based on the requirements of the particular buyer. Vendors will interface with Newco via an application that allows realtime negotiation of terms for payment and FlexiDrafts. Ideally the interface will be provided utilizing a macro add on to existing email services.

A computer system at the buyer or vendor site initiates communication with the Newco computer system using any well-known access protocol, e.g., Transmission Control Protocol/Internet

Protocol ("TCP/IP"). A description of TCP/IP is provided in Information Sciences Institute, "Transmission Control Protocol DARPA Internet Program Protocol Specification (RFC 793)" (September, 1981), and Information Sciences Institute, "Internet Protocol DARPA Internet Program Protocol Specification (RFC 791)" (September, 1981). In a preferred embodiment in accordance with the invention, the buyer or vendor computer system acts as a client and a computer system at Newco acts as a server.

The buyer or vendor computer system initiates communication by sending a "client hello" message to the Newco computer system. When a client first connects to a server it is required to send the client hello message as its first message. The client can also send a client hello message in response to a hello request on its own initiative in order to renegotiate the security parameters in an existing connection. The client hello message includes a random structure, which is used later in the protocol. Specifically in accordance with a preferred embodiment, the random structure includes the current time and date in standard UNIX 32-bit format according to the sender's internal clock and twenty-eight bytes of data generated by a secure random number generator. The client hello message further includes a variable length session identifier. If not empty, the session identifier value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier may be from an earlier connection, the current connection, or another currently active connection. It is useful to specify the current connection if the client only wishes to update the random structures and derived values of a connection. It is useful to specify another currently active connection if the client wishes to establish several simultaneous independent secure connections to the same server without repeating the full handshake protocol. Client hello message further includes an indicator of the cryptographic algorithms supported by the client in order of the client's preference, ordered according to client preference.

In response to client hello message, if Newco computer system wishes to correspond with buyer or vendor computer system, it responds with server hello message. If Newco computer system does not wish to communicate with buyer or vendor computer system, it responds with a different message, indicating refusal to communicate.

Server hello message issued by a computer system at Newco includes a random structure, which is used later in the protocol. The random structure in the server hello message is in the same format as, but has contents independent of, the random structure in client hello message. Specifically, the random structure includes the current time and date in standard UNIX 32-bit format according to the sender's internal clock and twenty-eight bytes of data generated by a secure random number generator. Server hello message further includes a variable length session identifier. The session identifier value identifies a new or existing session between the same client and server. Server hello message further includes an indicator of the cryptographic algorithms selected from among the algorithms specified by client hello message, which is utilized in further encrypted communications.

Optionally, Newco computer system transmits a server certificate. If transmitted, server certificate enables the buyer or vendor computer system to authenticate the identity of Newco computer system.

If Newco computer system does not transmit a server certificate, or if server certificate is suitable only for authentication, it may optionally transmit a server key exchange message. Server key exchange message identifies a key that may be used by buyer or vendor computer system to decrypt further messages sent by Newco computer system. After transmitting server hello message, and optionally transmitting server certificate or server key exchange message, Newco computer system transmits a server hello done message and waits for a further response from a buyer or vendor computer system.

A buyer or vendor computer system may optionally transmit a client certificate to the Newco computer system. If transmitted, the client certificate enables the Newco computer system to authenticate the identity of the buyer or vendor computer system. Alternatively, the buyer or vendor computer systems may transmit a no-client-certificate alert, to indicate that the buyer or vendor has not registered with any certification authority.

If buyer or vendor computer system does not transmit a client certificate, or if the client certificate is suitable only for authentication, the buyer or vendor computer system may optionally transmit a client key exchange message. The client key exchange message identifies a key that may be used by the Newco computer system to decrypt further messages sent by the buyer or vendor computer system.

After optionally transmitting a client certificate, no-client-certificate alert, and/or client key exchange message, buyer or vendor computer system transmits a finished message.

At this point, buyer or vendor computer system and Newco computer system have:

1) negotiated an encryption scheme that may be commonly employed in further communications, and

2) have communicated to each other a set of encryption keys that may be used to decrypt further communications between the two computer systems.

Buyer or vendor computer system and Newco computer system may thereafter engage in secure communications with less risk of interception by third parties.

If the client does not support client-side certificates, further authentication of the client may be done at the application layer with passwords (encrypted under the encryption scheme just negotiated) or other secure hardware such as the SecurelD card from Security Dynamics, Inc. Among the messages communicated by buyer or vendor computer system to Newco computer system are messages that specify the payment amount and terms and other payment related information, such as credit rating information, collectively referred to as "payment information," that may be used to determine the terms for payment for the goods and/or services ordered utilizing the FlexiDraft. Payment information can also include terms for early payment and the identity of the financial institution such as a bank that the FlexiDraft is drawn from. In order to obtain payment, Newco must supply this information to the bank or other financial institution that is the ultimate recipient of the pooled FlexiDrafts. This enables Newco to offload payment processing. Payment authorization is the process by which permission is granted by a financial institution to authorize payment on behalf of the financial institution. This is a process that assesses transaction risk, confirms that a given transaction does not raise the account holder's debt above the account's credit limit, and reserves the specified amount of credit. Payment capture is the process that triggers the movement of funds from the financial institution to the Newco's account after settlement of the account.

The Newco server provides support for configuring and installing the Internet payment capability while leveraging existing host credit risk assessment technology such as that provided by Visa and American Express. The Newco server also provides an intuitive Graphical User Interface (GUI) with support built in to accommodate other payment instruments such as debit cards, electronic checks, electronic cash and micropayments. The payment gateway implements secure transactions using protocols such as RSA public-key cryptography and the MasterCard/Visa Secure Electronic Transaction (SET) protocol. The Newco server also provides full functionality for Newco payment processing including authorization, capture, settlement and reconciliation while providing creditor activity with reporting and tracking of transactions sent over the Internet. Finally, the Newco server also implements Internet payment procedures that match current processor business models to ensure consistency of transactions. Handling Internet transactions is destined to become a necessary function for every payment processing system. Today, Newco servers are required to transmit data received over the Internet inefficiently. To maintain support for legacy systems, including non-computer buyer or vendors, support for faxing the information instead of electronic transmission of the information is required. Figure 3 is a block diagram of the system in accordance with a preferred embodiment. Processing commences at block 310 when a vendor 300 provides goods or services 340 to a buyer 310. The buyer issues a FlexiDraft 375 to the vendor 300 for payment. The buyer 310 also sends a copy of the FlexiDraft 350 to Newco 320 to notice Newco that payment must be made to the vendor 300 in accordance with the terms of the FlexiDraft. The vendor 300 submits the FlexiDraft with appropriate terms and a payment schedule 370 to Newco 320. Newco aggregates vendor's FlexiDraft with other FlexiDrafts to create a secure debt instrument 365 which is sold to a financial institution 330 for terms more favorable to Newco than the original FlexiDraft 370. The financial institution pays vendor 300 according to the terms of the securitized debt instrument 365 as relayed by Newco 320 through the secure debt instrument

365. The buyer pays the financial institution according to the terms of the original FlexiDraft 375.

To accommodate processing in accordance with the preferred embodiment presented in Figure 3, the buyer must have software for issuing FlexiDrafts including software for processing digital signatures and support for Internet Protocol version 6 (IPv6) to ensure that sniffers cannot be utilized to determine the buyer's vendors by tracing transactions emanating from the buyer. Two messages are required by the buyer to facilitate this architecture. If both of the buyer's sends are non real-time messages, then there is a race condition in a situation where the vendor submits a FlexiDraft to Newco before Newco receives notification from the buyer. This condition can be alleviated if the buyer to Newco communication link is realtime. As in the preferred embodiment in accordance with Figure 2, the vendor can utilize an extension to e-mail to initiate an application that connects to Newco for payment term selection in realtime.

Figure 4 is a block diagram of the system in accordance with a preferred embodiment. A vendor

400 provides goods or services 440 to a buyer 410. The buyer 410 issues a FlexiDraft 475 to the vendor 400 in payment for the goods or services 440. The vendor submits the FlexiDraft 470 with payment terms and a payment schedule to Newco 420, which verifies the digital signature of buyer 410 on the FlexiDraft 470. Then, Newco 420 aggregates the FlexiDraft with the vendor's terms along with other vendors to create a secure debt instrument 465 which is sold to a financial institution 430. The financial institution 430 pays the vendor according to the payment schedule selected, as relayed by Newco 420. The buyer 410 pays the financial institution according to the terms of the original FlexiDraft 475. The implications of processing in accordance with a preferred embodiment in accordance with Figure 4, are consistent with that of Figure 3, with the added benefit of eliminating any race conditions.

Money Transfers In accordance with a preferred embodiment, a discount fee is provided to entice a vendor to pay money before the due date specified in the FlexiDraft. A schedule of discounts corresponding to how early the money is provided allows a vendor to realize significant savings if payment is received before the money is due. A guarantee fee is available to a vendor to guarantee payment in the event that a buyer fails to pay the financial institution. The guarantee fee varies in proportion to the credit risk posed by a particular buyer. An insurance premium may be required of a high risk buyer. This payment is similar to Principal Mortgage Insurance (PMI) that is required to insure against default for highly leveraged homes. An aggregated debt instrument interest rate representing the rate of return annualized for the secured debt instruments created by

Newco for sale to the Financial Institution in pools floated for sale.

1. Payment Authorization Request Generation

Figure 5 depicts the detailed steps of generating and transmitting a payment authorization request. In function block 500, a Newco computer system as illustrated in Figure 1 creates a basic authorization request 510. The basic authorization request is a data area that includes all the information for determining whether a request should be granted or denied. Specifically, it includes such information as the party who is being charged, the amount to be charged, the credit rating of the party to be charged, and any additional data, such as passwords, needed to validate the charge. This information is either calculated based upon prior buyer or vendor merchandise selection, or provided by the buyer or vendor over a secure link established in the buyer or vendor secure communication protocol session.

In function block 530, the Newco computer system combines basic authorization request 510, a copy of its encryption public key certificate 515 and a copy of its signature public key certificate

520. The Newco computer system calculates a digital signature 525 for the combined contents of the combined block 530 comprising basic authorization request 510, the encryption public key certificate 515 and the signature public key certificate 520, and appends it to the combination of the combined basic authorization request 510, the encryption public key certificate 515 and the signature public key certificate 520. The Newco computer system calculates digital signature 525 by first calculating a "message digest" based upon the contents of the combined basic authorization request 510, the encryption public key certificate 515 and the signature public key certificate 520. A message digest is the fixed-length result that is generated when a variable length message is fed into a one-way hashing function. Message digests help verify that a message has not been altered because altering the message would change the digest. The message digest is then encrypted using the Newco computer system's digital signature private key, thus forming a digital signature.

Figure 5B depicts the combined block 530 containing basic authorization request 510, the encryption public key certificate 515, the signature public key certificate 520, and digital signature 525.

In function block 530, Newco computer system generates a random encryption key RK-0 540, denoted as RK-0. Random encryption key RK-0 540 is a symmetric encryption key. A symmetric encryption key is a key characterized by the property that a message encrypted with a symmetric key can be decrypted with that same key. This is contrasted with an asymmetric key pair, such as a public-key/private-key key pair, where a message encrypted with one key of the key pair may only be decrypted with the other key of the same key pair. Figure 5C depicts random encryption key RK-0 540.

The Newco computer system 530 encrypts combined block 530 using random encryption key RK-0 540 to form encrypted combined block 550. Figure 5D depicts encrypted combined block 550. The encryption state of encrypted combined block 550 is graphically shown by random key lock 555, which indicates that encrypted combined block 550 is encrypted using random key RK-0 540.

Certificate Processing

A FlexiDraft may be certified by a "certificate issuing authority" before it can be used on a computer network. In the case of credit card payments, the issuer may be one of the card issuing banks, but it might also be a Newco, a transaction aquiring bank or an association such as VISA or Mastercard. The certificate which authorizes a FlexiDraft will be stored in a secured database. The process of acquiring a certificate is described below. A certificate can be delivered to a buyer or vendor in a preconfigured transaction. The buyer or vendor receives a transaction which contains the certificate together with the necessary details associated with a FlexiDraft[ which is authorized by a certificate issuing authority or the agencies represented by the issuing authority.

Obtaining a certificate

A buyer or vendor will deliver or cause to be delivered information to a certificate issuing authority. Figure 6 is an illustration of a certificate issuance form in accordance with a preferred embodiment. A user may fill out the form on-line, on paper and mail it in, or get his bank or credit card company to deliver it. The buyer or vendor delivered data will usually contain a public key belonging to a security key pair generated by buyer or vendor software. This information will normally be mailed to the buyer or vendor's address and actuated by a telephone call from the buyer or vendor. The certificate authority takes this information and uses it to validate that he is indeed entitled to use the payment method. This processing normally takes a few days to accomplish. Information will normally be exchanged with the organization issuing the payment method in the physical space if there is one, and with credit agencies. The certificate information is loaded into the buyer or vendor's software to enable payment processing to proceed online.

The associated certificate ( eg X509 standard ), an associated public key or in some cases public/private key pair ( eg RSA), and an approved bitmap representing the payment instrument are provided to the requesting buyer or vendor. The certificate includes a public key portion and a private key used as an irrebutable digital signature to authenticate the parties to the transaction.

The certificate also includes information on the level of credit risk which allows a Newco to conditionally decide on the authorization or rejection of credit under a particular payment instrument based on their risk level and the Newco's personal comfort level with the ability of the cardholder to pay. This processing has not previously been possible because the information returned from the authorizing bank did not include a level of credit risk a cardholder posed, it only contained credit rejected or approved. In order to describe the detailed transaction flows for FlexiDrafts, it is useful to place them in the context of payment flows for standard commercial transactions as paid by check or wire, standard commercial transactions that utilize factors, and those that utilize investment services.

Financial relationships for businesses

In the current state of the art, a business must establish a number of relationships with financial institutions as well as with its vendors and customers. First, the financial relationships include one or more of the following:

1. A commercial account (usually a checking account) by which the business makes payments to its vendors and suppliers.

2. An interest-bearing account (such as a money market account), in which cash needed in the near term is placed in order to earn interest.

3. A short-term line of credit, which may be secured (by a company's assets) or unsecured (a general obligation loan) to cover expenses incurred during periods of low or negative cash flow.

Many times, these three financial relationships will be with a single commercial bank, which is the business' primary financial institution.

Besides these basic relationships, a more sophisticated business may get into relationships with financial institutions to manage money which will not be needed in the very short term. This may include buying longer term treasury notes or other secure investments, or may involve active money management by a financial institution in concert with the Chief Financial Officer (CFO) of the business. Commercial terms (as governed by the UCC - Uniform Commercial Code) generally dictate that a Buyer shall pay a Vendor some number of days after the acceptance of the goods by the Buyer, as determined by mutual agreement. Typically, this will be thirty to sixty days, leading to the terms "net 30" or "net 60." Buyers may also offer to pay less money in a shorter period of time, giving them a discount in exchange for the Vendor's privilege of getting earlier access to the money. For example, terms of "net 30 or net 10 less 2 percent" means the Buyer will pay in full in thirty days, or will pay 98% of the amount in ten days, either of which will be considered payment in full for the goods or services.

Figure 7 shows the parties involved in a standard commercial transaction. The arrows depict actions performed between parties. In Figure 7, a request for delivery of goods or services is initiated by the Buyer 710. In the commercial world, this may involve the issuing of a purchase order, but it does not require that step. The Vendor 700 ships the goods or performs services 740. The Buyer issues acceptance 745 of the goods or services (this is usually implied by the act of the Vendor 700 shipping the goods, but may be more complex, depending on agreements between Buyer 710 and Vendor 700.) After acceptance, a period time passes ( "n days," typically 30 days) before the Buyer pays the Vendor. In the case of payment by check, the payment can be divided into two sub-steps. Action 750 is the act of the Buyer 710 sending the Vendor 700 a check in the amount of the order, while 755 consists of the Buyer ensuring there is sufficient funds in the account (at Buyer's Bank 730) on which the check is drawn. In action 760, the

Vendor deposits the check into Vendor's Bank 720. Omitted from these and future diagrams are the steps involved in the Vendor's bank 720 presenting the check to the Buyer's bank 730 for payment, the actual transfer of funds between banks, and the debiting of the Buyer's account and crediting of the Vendor's account. Figure 8 shows the same flow of actions as a flowchart. A request for delivery of goods or services is initiated by the Buyer in step 800. The Vendor ships the goods or performs services in step 840, and sends an invoice to the Buyer. The Buyer issues acceptance in step 845 of the goods or services. After acceptance, a period time passes (shown in delay oval 847 as "n days," typically 30 days) before the Buyer pays the Vendor. In the case of payment by check, the payment can be divided into two sub-steps. In step 850 the Buyer sends the Vendor a check in the amount of the order (shown as $X), while in step 855 the Buyer ensures there is sufficient funds in the account on which the check is drawn. In step 760, the Vendor deposits the check into Vendor's Bank.

Purchases made with the use of a factor Some businesses are highly sensitive to cash flow. Thus, whereas normal commercial terms may require a business to wait thirty days or more for payment for goods that have been accepted by the business' customer, the business may need the money earlier. An alternative to using a short- term line of credit, or accepting customer-suggested terms, is for the business to turn its receivables over to a third party, such as a. factor. The factor will give the business cash up front for the receivables, but will only pay a percentage of the receivables' face value. This discounting is the way that the factor makes its profit and insures itself against uncollectable accounts.

Examples of businesses that are highly sensitive to cash flow include temporary employment agencies and the garment manufacturing industry. In both cases, the businesses must pay their workers either daily, weekly, or bi-monthly, yet they will not get the cash for their workers' pay until at least thirty days after the goods or services have been provided to and accepted by their customers. The growth rates of such companies is severely cashflow-limited. Figure 9 shows the entities involved in the transaction between the Buyer 910 and Vendor 900. Besides these two, there are a factor 940, the factor's bank 950, the Buyer's bank 930, and the Vendor's Bank 920.

The steps in the process are shown in Figure 10. As in the simpler case, the initiation of the purchase 1000 by the Buyer may, but does not necessarily involve, the issuing of a purchase order. Then, in Step 1060, the Vendor ships the goods or provides the service to the Buyer; this corresponds to action 960 in Figure 9. The Buyer accepts the goods or services in Step 1065 (Figure 9, action 965). At this point, in Step 1066 (Figure 9, action 966), the Vendor 900 assigns the invoice to a Factor 940. The assignment of the invoice to the Factor means that the Factor may now require the Buyer 910 to pay the Factor for the invoice, rather than the Vendor. This notification is shown in Step 1067 (Figure 9, action 967). In return for the invoice, the Factor pays the Vendor and amount $Y, in Step 1068 (Figure 9, action 968), which is less than the $X value of the invoice. This discounting is how the Factor makes money (earning interest on the amount of the invoice) and also how the Factor mitigates risk (by discounting the reimbursement to the Vendor by even more, to account for the chance that the Buyer might default). The Vendor then deposits this money in its bank in Step 1069 (Figure 9, action 969). Alternatively, the Factor may deposit the money directly in the Vendor's bank, collapsing Steps 1068 and 1069 into a single step.

Steps 1065 through 1069 occur in a relatively short period of time (measured in days or even hours), and the exact order of these steps are subject to change. After this series of steps, though, the remaining actions are identical to those of Figure 7, except that the Buyer sends payment to the Factor (the legal owner of the account receivable denoted by the invoice), rather than to the Vendor.

Whether a business uses short-term credit or uses a factor may seem equivalent, but there are subtle yet important differences. A credit line is dependent upon the credit rating of the business.

In particular, if the credit line is a general obligation loan (i.e., an unsecured loan), the credit line is not likely to be large enough to cover payroll expenses, etc., for the business.

In contrast, when a factor is assigned receivables belonging to the business (in exchange for giving the business cash), the credit risk in receiving payment is primarily a function of the credit rating of the business' customers, not of the business itself. Thus, a factor is looking at a different set of credit issues than a bank offering a line of credit, even though they are dealing with providing cash to the very same business entity.

In particular, the case of a weak business (i.e., one with a poor or non-existant credit rating) which deals with a set of strong customers (i.e., ones with very high credit ratings) in a cash-flow dominated business, is the ideal situation for factors. They can charge high fees, since the business can't get money from a bank, and since the business needs as much cash as possible right away.

The reason a bank is unwilling to extend a large line of credit to a business even if it has receivables from a customer with a good credit rating is that the customer could still experience some problems. Thus, if the customer fails to pay, the business' bank winds up with bad debt. Securitization as a means of mitigating risk

This problem has been dealt with successfully in the home mortgage business by the technique of securitization. A sufficiently large group of individuals with similar credit ratings is pooled together, so that the individual failures and payment problems become statistical effects that are easy to calculate in the large pool, and may be compensated for by the slight adjustment of interest rates for the pool. In other words, in a large enough group of mortgage holders, the failure rate will be a known percentage of the total dollar volume of the debt, and can be priced into the aggregaged debt instrument.

In fact, securitization has revolutionized the home mortgage industry. It has allowed individuals to borrow money at rates that are cheaper than those at which individual leading US industrial companies can borrow.

The same securitization techniques used for home mortgages can be used to reduce risk in a pool of accounts payable, provided the pool is large enough. Generally, a large enough pool to be statistically invariant would be on the order of at least $30 Million to $50 Million, and could involve hundreds, if not thousands of companies. This pool of assets may be used to create a securitized debt instrument that can be sold on a financial exchange as a short-term bond, with very little risk either to the investors (purchasers of the bond) or to the financial institution that is underwriting the debt instrument.

It should be noted that the main reason factors are not involved in the securitization of receivables is the dollar size of the warehousing process (i.e., that they must have $30 Million to $50 Million in cash to fund vendors, before they have enough receivables to form a debt instrument). There are no technical reasons why securitization of receivables could not be done by a financial institution that had enough business relationships. Thus, the following observations can be made:

1. If a financial institution could grant credit to a business based on assets of that business, and if the assets were of sufficiently low risk and high predictability, then the bank could effectively take over the much higher-risk business currently dominated by factors.

2. The accounts receivable of a group of businesses (or alternatively the accounts payable of their customers) comprise a regular stream of assets that could be used for this puφose, if they could be made sufficiently low risk. The risk can be minimized via securitization. Note, however, that this is by its very nature a large institutional play, and not one suited to small financial institutions or factors.

3. If enough assets in the form of accounts payable from quality customers are pooled to form a securitized debt instrument, the cash generated from the sale of the debt instrument could reliably fund the exercise of credit lines by the businesses in point 1 above.

The business entities and the business process flows of such a securitization activity are shown in Figure 11 and Figure 12. Figure 11 once again has the Vendor 1100, Buyer 1110, the Vendor's

Bank 1120, and the Buyer's Bank 1130. However, there are now two new entities. One entity is called NewCo 1140, and handles the issuing and redemption of payment instruments used in securitized vendor lending. The other entity is the Bond Market 1150, which purchases securitized debt instruments created by NewCo and used to fund NewCo's business. A vehicle is needed to consolidate the ability of businesses to access the cash from their customer's payments. This vehicle needs to by tied to the customer's payment, and must allow the business to trade this promise of payment to a financial institution for some amount less than the face value of the payment, where the amount less is a function in part of the amount of time in advance of the payment due date that payment is requested by the business. Current payment options for a Buyer to pay a Vendor are:

1. Payment by check

2. Payment by wiring of funds 3. Payment by ACH (Automated Clearing House) transfer

4. Payment by draft

Only payment by draft can satisfy the criteria for a payment instrument that is presented to the Vendor as evidence of acceptance of the goods or services and of the Buyer's intent to pay, but which is also in the possesion of the Vendor immediately after receipt of goods or services by the

Buyer so that the Vendor may turn the payment instrument (and not an invoice) over to a financial institution for early payment at a discount.

Checks do not satisfy the criteria for the following reason: If a Buyer owes a Vendor money in 30 days, the Buyer does not write the check until those 30 days are up. Thus, there is no payment instrument for the Vendor to give to its financial institution in advance in order to secure early receipt of funds. Neither the wiring of funds nor payment by ACH transfer satisfy the criteria, either, for the same reason as for checks. They again force the Vendor to seek a factor to take possession of the invoice itself, and redirect the request for payment (to go to the factor, rather than the Vendor).

Payment by draft is capable of meeting the criteria outlined above. The draft is simply a promise to pay at a future date (e.g., the equivalent to a post-dated check). The draft may be endorsed to any third party (including financial institutions or factors), who may in turn provide cash to the payee. This works exactly the same as for ordinary checks.

Moving to Figure 12, we again see the steps in the payment process are similar to those shown in Figure 8. Purchase is initiated by the Buyer in step 1200, and the first step common to the process after the initiation is the provision of goods and/or services in Step 1255 (corresponding to action 1155 in Figure 11). Then, after Buyer acceptance in step 1257, the Buyer issues a draft in the amount of $X (the total price of the goods and/or services), in step 1260 (corresponding to action 1160 in Figure 11). This is issued by making a request of Newco 1140.

In a preferred embodiment, the draft is implemented as an electronic payment instrument. However, the scheme will work no matter what implementation option is chosen. The draft could be paper, in which case it would be sent by the Buyer to the Vendor directly. This would take significant time, and the Vendor wants its money as quickly as possible. Therefore, an electronic implementation is to be preferred. In fact, in the preferred embodiment, the computer-based software for issuing electronic drafts resides at NewCo, and is used in a client/server mode where the Buyer has client software for requesting drafts. This will be discussed in greater detail subsequently. Thus, in the preferred embodiment, the Buyer 1110 initiates the sending of the electronic draft utilizing client software that interacts with the server software at NewCo 1140. Therefore, at the end of Step 1260, the Vendor has not yet been notified of the existence of the draft. This occurs in Step 1265. In a preferred embodiment, the Vendor is notified in Step 1265 via secure electronic mail that a draft has been issued payable to the Vendor on a specified date, for $X.

This email also contains instructions for connecting to NewCo's server to request early payment of the draft. The Vendor either responds to the email or does not, in decision block 1268.

If the Vendor responds, it may select terms for early payment of the draft, shown in Step 1270 (corresponding to action 1170 in Figure 11). The payment will be subject to a discount schedule, in which NewCo agrees to pay some amount $Y, where Y<X, for the $X draft. The value of Y is a function of the number of days early that the Vendor wants the money. NewCo then arranges for the money to be transferred into Vendor's bank account, in Step 1275. In general, some number of days m, where m is less than the commercial terms of n days which the Buyer is taking to pay, may pass between Step 1270 and Step 1275. This is again a function of the terms selected by Vendor in Step 1270, and is shown as delay oval 1272.

In parallel with step 1265 / 1270 / 1275 chain of events, NewCo adds the dollar amount of the Buyer's draft into a "warehouse," in step 1266, in which the warehouse is simply a pool of money which is not yet large enough to be turned into a securitized debt instrument. If the addition of the new draft causes the warehouse dollar amount to cross a specified threshold, in decision block 1267, then NewCo will aggregate the debts in the warehouse, characterize them from the viewpoint of the credit ratings of the Buyers, and issue a debt instrument which it then sells on a bond market, as shown in step 1290. If the addition of the new draft does not cause the dollar amount in the warehouse to cross a specified threshold, then no further action occurs, and NewCo waits for the next draft to arrive, as shown in step 1295.

Combining payment, lending, and investment into a single instrument So far, however, all discussion has been concerned only with the Vendor having early access to the money. But there are several other alternatives as to which party to the transaction wishes to pay early or late, and which party wishes to receive payment early or late. In total, the possibilties are:

1. The Vendor may want early access to the money, by giving a small percentage of the amount to the party which is offering early payment. Thus, a Buyer may offer terms of "net 30 days or net 10 days less 2 percent." Or, a factor may offer 98% of face value for the receivable. This is a trade-off as to whether the Vendor's short-term borrowing capability is more attractive than the discount provided by a factor or other third party.

2. The Vendor may not need early access to the money, and in fact may be willing to take late payment if it can earn interest on the money for each day later than the due date of the draft. This becomes a pure trade-off of whether the Vendor makes more money by taking payment later, or taking payment on schedule and then investing it in some other vehicle.

3. The Buyer may want to pay early, if it can pay less than the face value of the amount due. This becomes a pure trade-off of whether the Buyer makes more money by paying the account earlier at a discount, or keeping the money until the due date and investing it until that time. 4. The Buyer may want to pay later than the due date of the draft, if it in fact has a cash flow problem. The Buyer would look at the interest rate it paid for that delay, and compare it to the rate on its short-term line of credit (provided there is enough credit outstanding in the line to cover this payment).

So the case most commonly observed, case number 1 above, is only one specialization of a general set of cases that can occur when businesses try to optimize their cash flow. Case 1 is also the only case in which a draft is an acceptable payment instrument. No existing payment instrument can handle all four of these cases.

Consider the case where the Buyer (and perhaps also the Vendor) uses an investment service to handle cash which is not needed in the short term. This service could be internal to the company (such as the accounting department performing actions like buying Treasury bills), or a department of the Buyer's bank investing the Buyer's excess cash, or a separate financial institution.

Figure 13 illustrates the relationships Buyer and Vendor have with investment services. These relationships similar to those of Figure 9 except that a few additional ones are added. Buyer 1310 now has a relationship with investment service 1352 in addition to its bank 1330. Similarly, Vendor 1300 has a relationship with investment management service 1351 (which could be the same as service 1352, or could be a different institution).

The flowchart of Figure 14 is very similar to that of Figure 10, with some exceptions: At some point 1411, which may be before or after the initiation of a purchase, the Buyer 1310 (of Figure 13) deposits excess cash with its investment service. Then, as in Figure 10, the initiation of the purchase by the Buyer may, but does not necessarily involve, the issuing of a purchase order (this is step 1400). Next, in Step 1401, the Vendor ships the goods or provides the service to the Buyer. The Buyer accepts the goods or services in Step 1402. At this point, in Step 1403, the Vendor assigns the invoice to a Factor. The assignment of the invoice to the Factor means that the Factor may now require the Buyer to pay the Factor for the invoice, rather than the Vendor.

This notification is shown in Step 1403 (corresponding to action 1367 in Figure 13). In return for the invoice, the Factor pays the Vendor and amount $Y, in Step 1405 (Figure 13 action 1368), which is less than the $X value of the invoice. This discounting is how the Factor makes money (earning interest on the amount of the invoice) and also how the Factor mitigates risk (by discounting the reimbursement to the Vendor by even more, to account for the chance that the

Buyer might default). The Vendor then deposits this money in its bank in Step 1406. Alternatively, the Factor may deposit the money directly in the Vendor's bank, collapsing Steps 1405 and 1406 into a single step.

Steps 1401 through 1406 occur in a relatively short period of time (measured in days or even hours), and the exact order of these steps may be subject to change. Then a period of n days passes in delay oval 1407, after which the Buyer must send payment to the Factor. As in previous examples, the Buyer must execute Steps 1417 and 1418 (corresponding to actions 1365 and 1380 in Figure 13) in a short period of time (the exact order is unimportant if the payment is made by check through the mails). However, in the situation where the Buyer's funds are coming from its investment service 1352 and not directly from the Buyer's bank 1330, the Buyer must first redeem sufficient funds, in Step 1413 (corresponding to action 1313 in Figure 13),, and obtain those funds in Step 1414 (Figure 13, action 1314). Depending on the types of investments, there may be a delay between these two steps. Finally, the Factor deposits the check in Step 1419. Thus, when short-term investment management comes into play, the timing of such investments, funds availability, and the payment of purchases becomes more complex, and the proper management of the business' cash flow becomes critical. The management of cash flow would be made substantially easier if the business could rely on a single source for short-term credit, short-term investment, and payment of accounts. Even when these are handled by a single financial institution, they are still three separate services handled by three separate operating units of the bank, so they are not integrated in any way.

Definition of FlexiDraft

We now define a new payment instrument, which we call a FlexiDraft, which does handle all four cases. The entity relationships are the same as in Figure 11, but the actions and responsibilities of the entity "NewCo" are more complex.

First, we define the properties of a FlexiDraft, and then describe the relationships between the various entities and the steps taken in processing the FlexiDraft. The properties of a FlexiDraft are:

1. A FlexiDraft may be written by a Buyer, made payable to a Vendor in exchange for goods or services delivered. The FlexiDraft specifies an amount, a reference (for example, to an invoice or purchase order number), and a payable date.

2. The Vendor may choose one of the following options when it recieves the FlexiDraft: a. It may choose to endorse the FlexiDraft to a third party (which may be the issuer of the FlexiDraft) who will pay cash (at a discount) to the Vendor in exchange for the full face value of the FlexiDraft. b. It may choose to deposit the FlexiDraft in its own account, where the funds will clear on the payable date of the FlexiDraft. c. It may endorse the FlexiDraft to a third party (which may be the issuer of the FlexiDraft), which will pay the Vendor the full face value of the FlexiDraft, plus interest, on a specified date later than the payable date of the FlexiDraft.

2. The Buyer may choose one of the following options when it sends the

FlexiDraft to the Vendor: a. It may choose to allow the FlexiDraft to be paid on schedule, with the Buyer's account being debited on the payable date of the FlexiDraft. b. It may choose to pay the FlexiDraft early at a fraction of its face value, per an agreement structured with a financial institution, usually, but not restricted to the one on which the FlexiDraft is drawn, c. It may choose to pay the FlexiDraft late, thereby adding interest charges to the

FlexiDraft' s face value, per an agreement structured with a financial institution, usually, but not restricted to the one on which the FlexiDraft is drawn.

It should be noted that the effects of the FlexiDraft can be achieved either via seamless integration of the financial products offered by different operating units of a single financial institution, or by modifying payment amounts between Buyer and Vendor to give the same effect as earning or charging interest on money borrowed or saved for short periods of time. In otherwords, the differential manipulation of the business' normal cash flows can be used to replace (in part) the traditional investment and credit functions (as long as the differential portions are smaller than or comparable in size to the business' cash flows). This is the preferred method of implementing FlexiDrafts. Figure 15 shows the entities participating in the FlexiDraft chain of events. These are exactly the same players as in Figure 11. However, it is useful to note that there are two roles being played by NewCo 1540 in this Figure 15. First, NewCo is a service provider, which interacts with the Buyer and the Vendor; second, NewCo is a financial company that interacts with the Vendor's bank, the Buyer's bank, and the bond market.

When these roles are separated, a number of new interactions occur. In Figure 16, NewCo has been separated into a service company called ServiceCo 1640, and a financial company called FinCo 1660. These could still be separate organizations in a single legal entity, but ServiceCo could be an independent company acting as an outsourcing service for FinCo. When the roles are separated, three of the interactions (denoted by actions 1560, 1570, and 1575 in Figure 15) become slightly more complex.

Figure 17 shows the flow of events between the entities in Figure "FlexiDraft [entity diagram (separated roles)]." In these charts, FlexiDrafts will be the payment instrument, rather than checks or drafts. A Buyer (1610 in Figure 16) may or may not issue a purchase order for the goods in step 1700, but regardless, when the goods are shipped by the Vendor in step 1711, an invoice is generated and presented to the Buyer. When using FlexiDrafts, the Buyer is required to acknowledge acceptance via the issuance of a FlexiDraft to the Vendor in step 1715.

In a preferred embodiment, the Buyer issues this FlexiDraft by using client software to access a

FlexiDraft issuing server at the ServiceCo site; this occurs in Step 1716. When the Buyer issues the draft, it also selects terms for payment. It can pay in full (an amount of $X) under the normal commercial terms (usually net 30 days), it can pay earlier and pay an amount less than $X (because of interest earned for advance payment), or it can notify ServiceCo that it intends to pay later than the normal commercial terms, and will pay more than $X. This last option may require the approval of ServiceCo (or of FinCo as relayed by it to ServiceCo).

In Step 1717, ServiceCo forwards the Buyer's payment terms (payment date and the amount of payment) to FinCo (this forwarding is action 1617 in Figure 16). The forwarding occurs so that at a future date, FinCo may request a transfer of funds from Buyer's bank to FinCo (this occurs in Step 1785, and is discussed later). ServiceCo also adds the Buyer's draft to the warehouse in step 1722.

In Step 1731, the Vendor is notified by ServiceCo that the Buyer has issued a FlexiDraft in the amount of $X to cover a specific invoice. In a preferred embodiment, the Vendor is notified electronically, via registered email, via an EDI message, or via push technology, as action 1631 in Figure 16. The Vendor might also be notified via fax or regular mail, although those options do not guarantee delivery to a specific individual at the Vendor's business. Furthermore, regular mail incurs a delay which is not beneficial to the Vendor if it wants to choose early receipt of funds from the FlexiDraft.

If the Vendor chooses in decision block 1732 to respond to the message (Figure 16, action 1631) from ServiceCo telling it that the Buyer has issued a FlexiDraft, the Vendor may choose the terms for receipt of payment. In Step 1741 (corresponding to action 1641 in Figure 16), the

Vendor chooses early, late, or on-time receipt of funds, with a corresponding penalty for early receipt or an interest payment for late receipt. In Step 1742 (corresponding to action 1642 in

Figure 16), ServiceCo forwards this information to FinCo, so that FinCo may credit the Vendor's account in the Vendor's bank (in Step 1751). This may occur some number of days earlier or later than the due date on the FlexiDraft. This is represented in the delay oval 1743, as n +/- p days, where n is the number of days between the origination of the FlexiDraft and its due date, and p is a differential dependent upon the terms chosen by the Vendor.

At the time the Vendor chooses payment terms, ServiceCo adds a notation to the funds warehouse regarding the Vendor's payment terms, in step 1723. This is used to balance the payments required to the Vendor with the cash obtained from Buyers who choose to pay early. Warehouse imbalances will be covered shortly.

The Vendor may choose not to respond to ServiceCo's notification of the FlexiDraft in decision block 1732, or it may delay substantially in its response. In either case, a specified "timeout" period is inteφreted to mean that, by default, the Vendor has chosen to take normal payment terms, with the FlexiDraft paid in its due date of n days. Thus, in the absence of a message from the Vendor (Step 1741, or action 1641 of Figure 16), ServiceCo will still send a message to FinCo (Step 1742) specifying the default funding date. At a future time, the Vendor may respond, having chosen terms. At that time, Step 1741 is executed, and a new notification from

ServiceCo to FinCo is sent (Step 1742), overriding any previous notification of the Vendor's funding date.

In parallel to all of the actions concerning the Vendor, ServiceCo is also performing actions to track the Buyer's intent and to transfer funds from the Buyer at the appropriate time. Thus, after

Step 1716, two parallel actions are taken. The first, in Step 1717, has already been mentioned, which is the notification of the Buyer's payment terms to the Vendor. This also leads to FinCo transferring funds from Buyer's bank in Step 1785. This may be done via ACH transfer or by wire transfer. A prerequisite to this step is the Buyer ensuring there are adequate funds available in the account, in Step 1780. Both of these steps may take place a substantial amount of time after the buyer issues the FlexiDraft. This is represented as the delay oval n ± m days, where m is a differential from the nominal payable date of the FlexiDraft, based upon the payment terms selected by the Buyer.

The second of the parallel actions is that the Buyer's FlexiDraft is added to the funds warehouse, in step 1722. After each addition to the funds warehouse, whether from the Buyer's FlexiDraft payment terms being added, or the Vendor's payment schedule being added, a balance check is performed to see if the warehouse dollar amount has crossed a threshold. The occurs in decision block 1765.

This balance check is now more complex than the analogous threshold check performed in Figure 12. In the flowchart of Figure 12, a threshold check was performed, and if the dollar volume of debt in the warehouse exceeded the threshold, a debt instrument was created and issued to the bond market.

In Figure 17, this threshold check is still performed. If the dollar volume of debt exceeds the threshold, exit point "Vendor" is chosen, and step 1771 is executed. ServiceCo, which is managing the warehouse, signals FinCo in Step 1771 that it needs to issue a debt instrument, and it provides all the parameters of that debt instrument. In Step 1790, FinCo issues the debt instrument to the bond market (1650 in Figure 16). If the dollar volume does not exceed the threshold, there are now two possibilities.

The first possibility is that the warehouse is in a net debit position, i.e., the dollar volume required to pay Vendors who have requested early receipt of funds exceeds the dollar volume paid early by Buyers. In this case, the exit point for the warehouse balance check is the exit point marked "OK." Nothing further need be done, and ServiceCo waits for the next FlexiDraft in step

1799.

The second possibility is that the warehouse is in a net credit position, i.e., the dollar volume paid early by Buyers exceeds the dollar volume required to pay Vendors who have requested early receipt of funds. Since FinCo will need to pay interest to the Buyers, and since it cannot obtain funds for the interest payments from the discount rates charged to Vendors for early receipt of funds, it must invest the suφlus to generate income with which to pay the Buyers. This exit point is marked "Buyer." In this situation, an alternative message is sent from ServiceCo to FinCo. In lieu of Step 1771, there is Step 1773, in which ServiceCo notifies FinCo that is must invest a certain amount of funds. This leads to Step 1774, in which FinCo invests the excess cash, most likely in, though not limited to, the bond market.

Either, but not both, of the sequences of steps 1771, 1790 or 1773, 1774 can occur. The correspond to message flow 1671 in Figure 16.

With any warehouse imbalances (net debit or net credit) thus being cleared, ServiceCo waits for the next FlexiDraft to be issued by a Buyer in step 1799. Thus, the following benefits accrue from the actions taken in Figure 17:

1. Securitization of a pool of payables from a set of Buyers with good credit ratings, thus minimizing risk to investors.

2. Providing Vendors with early payment options at more attractive discount rates than can be obtained from factors. 3. Providing Buyers with better interest rates for early payment than can be obtained from other short-term investments.

4. Providing all businesses with higher-yield alternatives for short-term investment needs, without adding undue risk.

The ability to provide more attractive interest rates to the parties comes from the fact that the usual margins for return on assets that would have to be generate by two different business units of a financial institution (the lending unit and the commercial accounts unit), but here in a combined business, need only be collected once to still yield a profitable business. The savings can be split among the Vendor, the Buyer, and the financial institution, to improve all of the parties' margins. This will be discussed in more detail below.

Note also, in Figure 16, that with the separation of roles between ServiceCo and FinCo, the Buyers 1610 and Vendors 1600 only need to interact with ServiceCo 1640, while the financial instituions (Buyer's bank 1630 and Vendor's bank 1620) need only interact with FinCo 1660.

This makes it possible for ServiceCo 1640 to be a service provider to multiple FinCo's, in a way that is transparent to Buyers and Vendors. The clean separation also makes it possible for one FinCo to be serviced by several different ServiceCo's.

While the flowchart of Figure 17 is complex, most of that complexity is hidden from the end customers, namely the Buyer and the Vendor. We now examine the actions required of Buyer and Vendor when using FlexiDrafts. The Buyer's experience in using FlexiDrafts

The Buyer's actions are depicted in Figure 18 The chart is divided into left- and right-hand portions. The left-hand portion shows the actions for payment by check or by wire. The Buyer initiates a purchase in step 1800, typically, but not always, by issuing a purchase order. The purchase order specifies the commercial terms, such as when the Buyer must pay for the goods and services (normally, a period of n days after acceptance), and the purchase price of $X. Once the Buyer receives the goods or services in step 1801, which is defined as acceptance 1810, it waits the n days as specified in the commercial terms, shown in delay oval 1820, then cuts a check (or equivalently, initiates a wire transfer), and the $X is deducted from the Buyer's bank account in step 1825.

The right-hand side of Figure 18 shows the process for payment by FlexiDraft. The first two steps are the same as the left-hand side. After acceptance 1810, though, the Buyer immediately issues a FlexiDraft in step 1840. The Buyer chooses one of three actions:

1. Step 1841 : Pay the FlexiDraft in m days, where m < n. In this case, the Buyer pays less than $X, where the difference is the interest earned by paying early. The money is deducted from the Buyer's account in step 1851.

2. Step 1842: Pay the FlexiDraft in n days, on schedule. In this case, the Buyer pays exactly $X. The money is deducted from the Buyer's account in step 1852.

3. Step 1843: Pay the FlexiDraft in m days, where m > n. This must be done with the permission of the FinCo on which the FlexiDraft is drawn. In this case, the Buyer pays more than $X, where the difference is interest charged for late payment. (Note: alternatively, the Buyer could assign the FlexiDraft to a third party, which agreed to pay the amount due on the due day, and which then allowed the Buyer to pay late. This would allow other parties, rather than FinCo, to take the credit risk on the Buyer's possible nonpayment.) The money is deducted from the Buyer's account in step 1853.

In order for the Buyer to make a decision as to which of these three options to choose, it must be able to compare the discounts it will receive or the penalties it will pay for early or late payment, respectively. It can then compare the effective interest rate of these options with the interest rates of investing or borrowing money from a financial institution. If the rates are more attractive with the FlexiDraft, especially taking into account whether its money has to be tied up for fixed periods of time to get better returns, the Buyer will likely opt to use the FlexiDraft.

In a preferred embodiment, the Buyer has access to a set of screens in a client/server system, where the server is run by ServiceCo and calculates the discounts and penalties associated with early or late payment, and the client displays these results graphically. Such a screen forms part of a set of services from ServiceCo, that will be called a "Cash Flow Wizard."

Figure 19 depicts such a screen. In this particular example, the FlexiDraft is for a due date 30 days from date of issue. The Cash Flow Wizard shows that, if the Buyer chooses to pay immediately (i.e., on Transaction Date 1910), it will make 1% interest (this equates to an annualized rate of slightly more than 12%). This rate falls to 0.5% very quickly (in the first 3 days), and from there tails off to 0% on the Payment Due Date. If the Buyer wishes to extend the payment terms, it may do so at rates that hit 1.5% after 60 days. In other words, the Buyer will pay 1.5% for extending payment by 30 days (from the 30 day due date to 60 days), or will pay an annualized rate of slightly more than 18%. All numbers here are for the sake of illustration, and would be functions of the economic climate as well as the credit rating of the Buyer.

The Buyer determines these factors by reading the rate curves 1915 and 1925. These show the interest paid or due as a function of the number of days into the payment cycle (depicted by legend 1906 of axis 1905). The interest rates are shown on axis 1900, using legend 1901. On the nominal payment due date 1920, the amount due is exactly 100% of the face value of the FlexiDraft.

Note that the rate curves 1915, 1925 do not have to be linear. In fact, the effective APR on interest for early or late payment could be an arbitrary function. This allows ServiceCo and FinCo to inject bias into the system, to influence the Buyer's behavior. In the case of Figure 19, it is clear that if the Buyer is going to pay early, it is going to pay in the first or second day; otherwise there is nothing to be gained financially.

Managing cash flow for a series of payments Figure 20 shows another screen from the Cash Flow Wizard. The horizontal axis 2005 defines a timeline, as indicated by the months 2012. The vertical axis indicates the total cash available to the business, either as net positive, zero, or net negative, shown as legend 2001. Note that this scale should be labeled numerically, but is not for simplicity's sake.

The solid bars 2030 indicate payments by others into the business, while the lighter bars 2020 indicate payments made by the business to others. The shaded area (2040 when positive, 2042 when negative) indicates the total cash position of the company. Thus, it can be seen that, in early March, the company runs in a negative cash position for a short while, until payments made by others to the company in April.

The screen of Figure 20 can be used either to measure actual payments into and out of the company accounts, or to predict cash needs into the future, based on anticipated payments and receipts. The screen can also indicate significant periods of time where a block of cash is available for investing in an instrument that can't easily be cashed quickly. For example, the arrow 2050 indicates such a block of cash. The cash below the arrow is available of 2.5 months and is not needed. The differential above the arrow could be invested in a more liquid vehicle.

These types of screens allow a business to manage its cash flow more efficiently than is currently done. The accounting for such screens can be outsourced to a ServiceCo, especially if the primary payment mechanism for the business is FlexiDrafts.

The Vendor's experience in using FlexiDrafts

Similarly, for the Vendor, a set of actions is shown in Figure 21. Again, the chart is divided into left- and right-hand portions. The left-hand portion shows the actions for getting paid by check or by wire. The Buyer initiates a purchase in step 2100, typically, but not always, by issuing a purchase order. The purchase order specifies the commercial terms, such as when the Buyer must pay for the goods and services (normally, a period of n days after acceptance), and the purchase price of $X. Once the Vendor provides the goods or services in step 2101 and the buyer accepts in step 2110, it waits the n days as specified in the commercial terms (delay oval 2120), then receives a check (or a wire transfer) from the Buyer (step 2122), and the $X is deposited into the Vendor's bank account (step 2125). The right-hand side of Figure 21 shows the process for receiving payment by FlexiDraft. The first two steps are the same as the left-hand side. After acceptance 2110, though, the Vendor immediately receives a FlexiDraft (step 2140). The Vendor chooses one of three actions:

1. Step 2141 : Redeem the FlexiDraft in m days, where m < n. In this case, the Vendor receives less than $X, where the difference is the interest charged for receiving payment early. Funds are deposited in Step 2151.

2. Step 2142: Redeem the FlexiDraft in n days, on schedule. This is achieved simply by depositing the FlexiDraft, as any normal draft. In this case, the Vendor gets exactly $X after n days. Funds are deposited in Step 2152.

3. Step 2143: Redeem the FlexiDraft in m days, where m > n. In this case, the Vendor receives more than $X, where the difference is interest earned for taking late receipt of the funds. Funds are deposited in Step 2153.

In order for the Vendor to make a decision as to which of these three options to choose, it must be able to compare the discounts it will receive or the penalties it will pay for choosing late or early receipt of funds, respectively. It can then compare the effective interest rate of these options with the interest rates of investing or borrowing money from a financial institution. If the rates are more attractive with the FlexiDraft, the Vendor will likely opt to use the FlexiDraft.

In a preferred embodiment, the Vendor (like the Buyer) has access to a set of screens in a client/server system, where the server is run by ServiceCo and calculates the discounts and penalties associated with late or early receipt of funds, and the client displays these results graphically.

Figure 22 depicts such a screen. In this particular example, the FlexiDraft is for a due date 30 days from date of issue. The Cash Flow Wizard shows that, if the Vendor chooses to redeem the

FlexiDraft immediately (i.e., on Transaction Date), it will pay 1.5% interest (this equates to an annualized rate of slightly more than 18%). This rate remains near 1.5% for the first 22 days of the payment schedule, and then falls very quickly for the remaining days, hitting 0% on the Payment Due Date. If the Vendor wishes to delay receipt of funds until after the Due Date, it may do so and earn interest rates that hit 1% by 60 days after the Transaction Date. In other words, the Vendor will receive 1% for holding off on receiving payment for 30 days (from the 30 day due date to 60 days), or will earn an annualized rate of slightly more than 12%. All numbers here are for the sake of illustration, and would be functions of the economic climate as well as the credit rating of the Vendor and Buyer.

Again, a nonlinear rate curve 2215, 2225 allows ServiceCo and FinCo to inject bias into the system, to influence the Vendor's behavior. In the case of Figure 22, it is clear that if the Vendor is going to request early receipt of funds, it is going to request it in the first or second day; there is nothing to be gained financially by waiting another 20 days, and interest is being lost.

It is thus demonstrated that FlexiDrafts are simpler instruments, from the Buyer and Vendor perspectives, than having a number of different relationships with financial institutions. Because there is a single operating unit of a financial institution to deal with, the sum of the operating margins required to sustain business in the financial institution is lowered, which should allow all parties to have more favorable margins when using FlexiDrafts, compared to using a variety of financial instruments.

Optimizing Return on Assests for Financial Institutions using FlexiDrafts

However, financial institutions that issue FlexiDrafts will want to optimize the return on assets

(ROA) used in operating the business. It will now be shown that the key to optimizing profitability is to adjust the rate curves in the Buyer's and Vendor's Cash Flow Wizard screens so as to induce behavior that balances Buyer pre-payment cash flows with Vendor early redemption cash flows.

Calculation of average return on assets (ROA) for the ServiceCo/FinCo combination requires the following variables:

on money that is parked there is (R-F)

Transaction fee paid to ServiceCo (by the Vendor in most embodiments), expressed as a percentage of the dollar value of the FlexiDraft.

The assumption is that ServiceCo and FinCo could be two separate companies, where ServiceCo provides transaction processing services and FinCo actually performs the financial transactions. If the two were merged into a single company, NewCo, the margins (approximately 50%) on the transaction fee T would become part of the combined company NewCo's ROA, rather than operating margin for ServiceCo.

A model is developed, initially assuming a single Buyer and a single Vendor, in one transaction. Then, it is shown that the model holds in the aggregate for a group of Buyers and Vendors. For simplicity of analysis, the equations developed for a model of profitability are driven by dividing the analysis into two cases, illustrated by the following two figures:

Figure 23 shows the case where the Vendor chooses to receive payment prior to a Buyer paying the amount due; the Buyer may choose to pay earlier to earn (R-B) % interest. The Vendor receives payment after vv days, and the buyer pays after bb days. The time to pay the draft at face value is tt days.

Figure 24 shows the case where the Buyer chooses to pre-pay the draft (and thereby earn interest), prior to the Vendor choosing to receive payment. In this case, ServiceCo/FinCo must pay interest to the Buyer prior to receiving the Vendors request for payment. Hopefully, the

Vendor requests early, so ServiceCo receives some premium. In the worst case, the Vendor receives payment on schedule, but the Buyer pays immediately. In Figures 23 and 24, the term NewCo will refer to the combined entity ServiceCo/FinCo, regardless of how the returns or payments are divided between the two sub-entities. Separate timelines are provided for the Buyer (timeline 2306 and 2406), Vendor (2304 and 2404) , and Newco (2302 and 2402). When a shaded bar appears above a timeline (in the '+' side), it means that NewCo is receiving money. When a shaded bar appears below a timeline (in the '-' side), it means that NewCo is paying out money.

In Figure 23 the Buyer decides to make payment after bb days. From that point on, NewCo pays the Buyer interest at an annual rate of (R-B)% 2340. The Vendor, meanwhile, has elected to take payment early, after w days, for which it pays a premium calculated as the interest on the money from day w until day tt. The rate the vendor pays is (R+V)% per annum, for payment 2320.

In order to pay Vendor, NewCo creates a debt instrument to finance the payment. NewCo pays an investor in this debt instrument (R-A)% annual percentage rate 2330. Note that for a single payment from a Buyer to a Vendor, the amount is unlikely to be large enough to warrant creating a debt instrument. However, when the analysis is extended to the aggregation of transactions from multiple Vendors and Buyers, creation of a debt instrument is reasonable.

ANALYSIS: From day 0 to day vv, no money moves and NewCo doesn't make any money.

From day w to day bb, NewCo makes (V+A)%, its "normal" ROA 2350. Since the Buyer has paid early, NewCo does not have to float a debt instrument for the days after bb. It still has to pay the Buyer interest, but generally B should be greater than A. Therefore, NewCo makes (V+B)% during the time from bb until tt. This is called "high-yield" 2351. In Figure 24 , the Buyer pays the FlexiDraft in bb days. From that point onward, NewCo must pay the Buyer (R-B)% interest 2430. NewCo has the money from the Buyer, so NewCo is investing this money, and is making (R-F)% interest on it 2420. Thus, the net cash flow for NewCo is (B-F)% on the money during the time from bb to vv. This is "low-yield" 2450. Assuming B and F are roughly comparable, NewCo is not making significant money during this time. Only if F is larger than B (which would be the case if NewCo were giving very aggressive rates to the Buyer) would NewCo lose money. However, after vv days, NewCo is back in "high- yield" mode 2451, making (V+B)% annually.

The equations for the profitability analysis are developed as follows:

Assume ServiceCo gets its transaction fee T from somewhere. For the moment, we'll take it out of FinCo's top line, but it is more likely to be paid by the Vendor (like a charge for paying by coφorate purchase card). This fee would cover all processing of FlexiDrafts, plus the profits for ServiceCo if it were operated as a separate company. If ServiceCo and FinCo were actually a single, combined entitity (NewCo), the difference between T and the actual operating expenses for ServiceCo would be added to the ROA generated by NewCo.

When w is less than bb:

ROA over the full period is:

[ (bb-w) /tt ] * (V+A) + [ ( tt -bb) /tt ] * (V+B) However, the assets are only used by NewCo for the period from w to tt, so the entire equation gets multiplied by

tt

(tt-w)

Also, it is desirable to describe the equation in terms of the percentage of time between when the Buyer pays and the term of the note, rather than in actual number of days with respect to term tt. So, note that, if we define bp as the percentage of time from start of terms until the Buyer pays, then:

bb = bp*tt

Similarly, if vp is the percentage of time from start of terms until the Vendor requests payment, then:

w = vp*tt

So our multiplication term tt/(tt-w) has become l/(l-vp). Then the ROA, annually adjusted is:

(bp-vp) * (V+A) + ( l -bp) * (V+B)

( 1 -vp) Similarly, when w is equal to or greater than bb, the annually adjusted ROA is:

(vp-bp) * (B- F) + ( 1 -vp) * (V+B)

( 1 -bp)

By expressing the equations as percentages of time before a Buyer pays or a Vendor gets paid, the same equations can model a group of Buyers and Vendors in the aggregate, where the percentages now refer to the averages for the groups of Buyers and Vendors.

More sophisticated models can be derived by replacing scalar variables with stochastic expressions, and performing a statistical analysis to determine spreads on the ROA as a function of the standard deviations of the aggregated Buyer/Vendor model from the means expressed in the scalar equation. However, in the current context, the scalar model is more than adequate to illustrate the concepts.

Figure 25 shows a simple spreadsheet, which contains all of the constants in the scalar equations 2500 and also a matrix 2510 of the solutions for all values of vp and bp stepped from 0 to 1 in 0.1 increments. Note that:

1. The maximum ROA in the matrix occurs on the major diagonal of the matrix. In otherwords, in order to maximize ROA, a financial institution should seek to influence Buyer and Vendor so that their desire to pay early or receive payment early are equal. Note that it doesn't matter whether they both pay or receive payment 10% into the payment term or 60% in, only that they do so at the same time. This may be confirmed by examination of the equations. The goal is to maximize the "high-yield" terms while minimizing the "low-yield" terms, and that occurs when vp equals bp.

2. With the initial numbers in the spreadsheet, the ROA spreads are substantially above a typical financial insitution's aggregate ROA of approximately 1% to 1.5%, if on average the Vendors choose early payment 50% or earlier into the payment terms.

Tools to assist the Financial Institution in optimizing ROA Influencing the Buyer and the Vendor to pay (in aggregate, on average) approximately the same percentage of time into the terms of the FlexiDraft may be done by NewCo by setting the rate curves as seen by the Buyer and Vendor in their Cash Flow Wizards. The two rate curves from Figure 19 and Figure 22 are shown superimposed in Figure 26. From this figure, it is readily apparent that the rate curves have been shaped to influence both Buyer and Seller to pay and/or redeem their FlexiDrafts either very close to the Transaction Date 2610, or at the Payment Due

Date 2620. The relative number of Vendors or Buyers choosing either of these options may be altered by increasing or decreasing the interest rates, in relation to general market conditions. Thus, the financial insitition can influence Buyers and Vendors to behave in a way that, in aggregate, maximizes the spread between rate curves 2615 and 2616, leading to profit maximization 2650.

Details of messaging between ServiceCo and Buyer and Vendor

The requirements influencing the technical implementation of the messaging beween Buyer and

ServiceCo, and between Vendor and ServiceCo are very similar to those for conventional forms of on on-line payment, such as that provided by Open Financial eXchange (OFX), as described in "Open Financial Exchange Specification 1.5," published by Microsoft Coφoration on June 29, 1998 (incoφorated herein by reference).

A prefened embodiment of the FlexiDraft payment instrument is done in electronic form, for reasons of transaction cost reduction and for reducing the time it takes to notify parties that they can request early redemption of a FlexiDraft, as described previously. Furthermore, a specific electronic embodiment should utilize existing infrastructure wherever possible, so that users of FlexiDrafts can use existing software and interaction paradigms. For these reasons, OFX has been chosen.

Figure 27 depicts the OFX server and client in the context of the Internet as a transport medium. Copies of the OFX client software reside at both the Buyer site or the Vendor site. A Profile Server 2710 provides information to the client about the capabilities of specific Financial Institutions (FI's), such as which message sets it can handle, and what URL may be used to located the FI's web server 2720 on the Internet. The use of public key certificates for the client to identify both the profile server and the FI's server are described in the OFX specification document.

Referring to Figure 27, the client first sends a query (message 2740) to a Profile Server 2710, which includes the FI identifier. The Profile Server returns a response (message 2745) to the client 2700, indicating various properties of the FI, including the URL of the FI's Web Server 2720.

Further interactions then occur directly with the FI's Web Server 2720. This Web Server and the OFX Server may be run directly by the FI, or may be run on behalf of the FI by a third party 2722. The OFX model is a request/response pair model. A request (message 2750) travels to the FI's Web Server, encrypted using SSL with appropriate encryption strength (e.g., 128-bit RC-4 in the United States). The Web Server 2720 decrypts the channel encryption layer, but does not decrypt passwords or other application-level encryption. Instead, the message is passed on to the OFX Server 2721, which handles application-level security issues. This ensures that security breaches between the Web Server and the OFX Server internal to an FI or third party's operations center do not compromise the security of individual OFX interactions.

The OFX Server 2721 produces an OFX response (message 2755) in response to the OFX request. Again, application level security is handled by the OFX Server and the OFX client. The

Web Server 2720 adds channel security (via SSL channel encryption) to the path between it and the client.

Specifically, OFX is used for the Buyer-to-ServiceCo and Vendor-to-ServiceCo interactions of Figure 16 and related figures. Specifically in that figure, interactions 1616, 1631, and 1641 are effected using OFX messages. The interactions between FinCo and ServiceCo (1617, 1642, and 1671) may be totally proprietary, or may be OFX-based for consistency of implementation, but they do not affect the Buyer or Vendor in any way. Funds transfers in interactions between FinCo 1660 and the Buyer's and Vendor's banks 1630 and 1620 may be via ACH transfer, check, wire transfer, or any other acceptable means of transferring funds. Interaction 1680 between Buyer and Buyer's bank may be via any method supported by the Buyer's bank, which may also include OFX. Interaction 1690 occurs according to established practice in the issuing of debt instruments. For interaction 1616 in Figure 16 the payment process is much like the payment process for an OFX payment. However, several new fields are required to convey the additional information required for FlexiDrafts. These fields are added, using the namespace conventions of OFX. For the remainder of this document, it is assumed that the prefix "FD." is used to denote FlexiDraft- specific additions to the OFX message set.

Thus, for a FlexiDraft payment request, the following structure describes the OFX portions of the message sent in message 1616 of Figure 16. Note that the HTTP headers, MIME encapsulation information, etc., is not shown here.

This example is for creating a FlexiDraft payment to "Widgets R Us" for $10,321.98 to be paid on October 1, 1998, using funds in the originator's checking account. The request is being made on September 1, 1998, for payment in net 30 days. However, the Buyer is paying ServiceCo/FinCo in three days, rather than in 30 days, so according to its rate curve in its Cash Flow Wizard, the total amount to be paid is only $10,228.50.

<OFX>

<DTCLIENT>19980901101000 <USERID>123-45-6789-01 <USERPASS>MyPass ord <LANGUAGE>ENG <FI>

<APPID>MyApp <APPVER>0700

</SONRQ> </SIGNONMSGSRQV1> <FD .DRAFTPAYMSGSRQ> <FD.P TTRNRQ> <TRNUID>1001

<FD.P TRQ>

<FD.PMTINFO>

<BANKID>123432123 <ACCTID>516273 <ACCTTYPE>CHECKING </BANKACCTFROM> <TRNAMT>10321.98 <FD.PMTOPTS> <FD.ADJTRNAMT>10228.50

<FD.DTFDP T>19980904

<FD.RTCURVID>19980901.123 -45-6789- 01 </FD.PMTOPTS> <FD. PAYEE> <NAME> idgets R Us

<ADDR1>100 Industrial Blight Road <CITY>Brisbane <STATE>CA <POSTALCODE>90101 <PHONE>415.987.6543

<FD.EMAIL>dorothy@widgets .com </FD. PAYEE> <PAYACCT>10101 <DTDUE>19981001 <FD.INVOICENO>120013

<MEMO>payment in full </FD.PMTINFO> </FD.PMTRQ> </FD.PMTTRNRQ> </FD.DRAFTPAYMSGSRQ> </OFX>

Most of this request message looks like standard OFX. The Sign On message set request <SIGNONMSGS QVI> . . . </SIGNONMSGSRQVI> is unchanged from the normal OFX syntax.

However, because of added information, denoted by some new tags, the OFX message set for Bill Payment is changed to a set of tags in the "FD." namespace that work for FlexiDraft payment. The specific tags which are changed are FD . DRAFTPAYMSGSRQ , FD . PMTTRNRQ , FD.PMTRQ, FD . PMTINFO, FD . INVOICENO , and FD . PAYEE . The first four of these are all

changed only because of the addition of a new container tag, called FD . PMTOPTS , inside of what

was previously called PM INFO, requiring that wrapper and all sunounding ones to have a different name.

The PAYEE container tag name is changed to FD . PAYEE to bring it into the FlexiDraft

namespace so a new field named FD . EMAIL could be added. This is becaue the OFX version 1.5 specification does not provide for an email address to be associated with a payee, and this information is necessary for ServiceCo to inform the Vendor that it has one or more FlexiDrafts pending, for which it can select various options on when to be paid by ServiceCo. If the OFX specification is amended, this change won't be required.

An FD . I VOICENO tag was added inside of FD . PMTINFO, since this is a crucial part of commercial transactions that was omitted from the OFX payment specification.

The additional tags inside of FD . PMTINFO are all enclosed in the FD . PMTOPTS container tag, as described in this table:

The server responds indicating that it will make the payment on the date requested and that the payee is a standard payee:

<STATUS> <CODE>0

</SIGNONMSGSRSVl> <FD .DRAFTPAYMSGSRS> <FD.PMTTRNRS> <TRNUID>1001 <STATUS> <CODE>0

<BANKID>123432123 <ACCTID>516273 <ACCTTYPE>CHECKING </BANKACCTFROM> <TRNAMT>10321.98

<FD. PMTOPTS>

<FD.ADJTRNAMT>10228.50 <FD.DTFDPMT>19980904

<FD.RTCURVID>19980901.123-45-6789-01 </FD. PMTOPTS>

<FD. PAYEE>

<NAME>Widgets R Us <ADDR1>100 Industrial Blight Road <CITY>Brisbane <STATE>CA

<POSTALCODE>90101 <PHONE>415.987.6543 <FD.EMAIL>dorothy®widgets .com </FD. PAYEE> <PAYACCT>10101

<DTDUE>19981001 <FD.INVOICENO>120013 <MEMO>payment in full </FD. PMTINFO> <EXTDPAYEE>

<PAYEEID>9076 <IDSCOPE>USER <NAME> idgets R Us <DAYSTOPAY>3 </EXTDPAYEE>

<PMTPRCCODE>WI LPROCESSON <DTPMTPRC>19981001 </PMTPRCSTS>

</FD.PMTRS> </FD.PMTTRNRS> </FD . DRAFTPAYMSGSRS> </OFX>

Again, when compared with a standard OFX bill payment, the updated tags are

FD .DRAFTPAYMSGSRQ, FD . PMTTRNRQ , FD . PMTRQ , and FD . PMTINFO . In addition, the

CHECKNTJM tag in the payment response has been changed to FD . DRAFTNUM, since the name

"check" is no longer conect. Message 1631 in Figure 16 is typically initiated via an email message from ServiceCo to Vendor. This email message contains information about a new FlexiDraft that has been issued to the Vendor, as well as information on how to contact ServiceCo to modify the date on which the Vendor gets paid. An example of such a message might be:

Date: Ol-Sep-98 03:04:12 +0800GMT To: dorothvo idqets . com From: flexidraft- infoaserviceco . com Re: New payment arrival

This email message is to inform you that you have a payment pending from: Almighty Buyer, Inc.

World Trade Center, Suite 4043 New York, NY 10053 (212) 555-0011 regarding invoice number 120013

You may get more information about this payment, and arrange for altering the date on which payment will be made to you (either earlier or later) , by pointing your FlexiDraft client at http : //www. serviceco.com/flexidraft/vendorsignon.

To learn more about the FlexiDraft payment system, or to enroll in the FlexiDraft program, please visit http: //www. flexidraft . com.

Thank you,

FlexiDraft Payment Systems

When the Vendor receives this mail, the person receiving it may invoke the client software simply by clicking on the appropriate URL in the email message. If this software does not exist at the Vendor site, the Vendor will be given options on how to get it and on how to sign up for the FlexiDraft program. Again, this is similar to the account activation methods employed in standard OFX. Assuming the Vendor is already a FlexiDraft user, the client software will send a message to ServiceCo's server, requesting a download of all recent FlexiDrafts issued to the Vendor (the client can effectively ask for all FlexiDrafts not yet seen). The original email message from ServiceCo to Vendor, plus the Vendor's request/response in OFX as described below, constitute action 1616 in Figure 16.

A sample message follows, based on the OFX Bill Delivery Message Set, with the non-standard portions moved into the FlexiDraft "FD." namespace. The request message is as follows:

<OFX>

<SONRQ>

<DTCLIENT>19980902090000 <! --Current date --> <USERID>123-45-6789 <! --Vendor user id--> <USERPASS>VendorPassword

< ANGUAGE>ENG <APPID>EndUserApp <APPVER>0700 </SONRQ> </SIGNONMSGSRQV2>

The response to this message contains the information about any new FlexiDrafts not yet seen by the Vendor's client software:

<OFX>

<STATUS> <CODE>0

<DTSERVER>19980902090000 </SONRS> </SIGNONMSGSRSV2> <FD . DRAFTDLVMSGSRS> <FD . DRAFTLISTTRNRS> <TRNUID>12345 <STATUS> <CODE>0 <SEVERITY>INFθ

</STATUS> <FD . DRAFTLISTRS>

<USERID>123 -45-6789 <DTSTART>19980824000000  <DTEND>19980902090000 <! --Value for DTSTART next time--

<FD. DRAFTLIST> <FD.DRAFTINFθ>

<FD.DRAFTNUM>20111 <FD .DRAFTACCTFROM> <FD.PAYOR>Almighty Buyer, Inc.

<FD.PAYORID>1001  <FD.ACCTID>1245678GL7 <! --Vendor' s acct with Almighty Buyer--> </FD . DRAFTACCTFROM> <FD . INVOICENO>120013 <FD.MEMO>payment in full

<FD.TRNAMT>10321.98 <FD.DTPMTDUE>19981001 </FD.DRAFTINFO> </FD.DRAFTLIST> </FD.DRAFTLISTRS>

</FD .DRAFTLISTTRNRS> </FD . DRAFTDLVMSGSRS> </OFX>

The following table describes the major additions in the FlexiDraft namespace (aside from minor tag additions and name changes) to provide FlexiDraft information to the Vendor:

The final message covered in the OFX syntax is Step 1641 of Figure 16. This message has no analog in cunent OFX, and so is mostly in the FlexiDraft "FD." namespace, although signon is still unchanged:

<OFX>

<DTCLIENT>19980902090000 <! --Current date --; <USERID>123-45-6789 <! --Vendor user id-- <USERPASS>VendorPassword

<LANGUAGE>ENG <APPID>EndUserApp <APPVER>0700 </SONRQ> </SIGNONMSGSRQV2>

<BANKID>1234567789 <ACCTID>12345 <ACCTTYPE>CHECKING </BANKACCTTO>

<FD.DRAFTINFO>

<FD . PAYOR>Almighty Buyer, Inc . <FD.PAYORID>1001

<FD.ACCTID>1245678GL7 </FD . DRAFTACCTFROM>

<FD . INVOICENO>120013 <FD.MEMO>payment in full <FD.TRNAMT>10321.98

<FD.DTPMTDUE>19981001 </FD.DRAFTINFO> <FD.RDMOPTS>

<FD.ADJTRNAMT>10228.50 <FD.DTFDPAID>19980904

<FD.RTCURVID>19980901.123-45-6789-01 </FD.RDMOPTS> </FD.RDMINFO> </FD . DRAFTRDMRQ> </FD .DRAFTRDMTRNRQ>

</FD .DRAFTRDMMSGSRQ> </OFX>

In this message, the signon portions are the same as in previous messages. The BANKACCTTO and

FD .DRAFTINFO containers are the same as in standard OFX or in previous messages described

above. The new tags are described in the table below:

The response for a server acceptance of the Vendors terms is as follows:

<STATUS> <CODE>0

<TRNUID>12345 <STATUS> <CODE>0

<FD.DRAFTRDMRS>

<SRVRTID>1030156

<CURDEF>USD

<FD.RDMINFO> <BANKACCTTO>

<BANKID>1234567789 <ACCTID>12345 <ACCTTYPE>CHECKING </BANKACCTTO>

<FD.DRAFTINFO>

<FD.PAYOR>Almighty Buyer, Inc. <FD.PAYORID>1001

<FD.INVOICENO>120013 <FD.MEMO>payment in full <FD.TRNAMT>10321.98

<FD.DTPMTDUE>19981001 </FD.DRAFTINFO> <FD.RDMOPTS>

<FD.ADJTRNAMT>10228.50 <FD.DTFDPAID>19980904

<FD.RTCURVID>19980901.123-45-6789-01 </FD.RDMOPTS> </FD.RDMINFO> </FD . DRAFTRDMRS> </FD .DRAFTRDMTRNRS>

</FD . DRAFTRDMMSGSRS> </OFX>

At present, the security options for OFX are either "no security" or "Type 1" security, which involves the use of passwords. The use of passwords involves the server sending a nonce that must be encrypted by the client software and sent back. This mechanism may be easily extended to allow for a client application to use client-side digital certificates, or hardware-based security solutions such as the SecurelD card from Security Dynamics, Inc.

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a prefened embodiment should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

CLAIMSWhat is claimed is:

1. A method for creating a draft with one or more payment terms, comprising the steps of: (a) retrieving a plurality of terms from a storage; (b) calculating a payment schedule based on the terms;

(c) creating a draft with a payment schedule based on the terms; and

(d) dynamically adjusting the terms based on payment timings.

2. A method for creating a draft with one or more payment terms as recited in claim 1 , including the step of adjusting the terms based on whether a payment was received early, on time or late.

3. A method for creating a draft with one or more payment terms as recited in claim 2, including the step of adjusting the interest rate of a payment based on whether a payment was received early, on time or late.

4. A method for creating a draft with one or more payment terms as recited in claim 1, including the step of adjusting the terms based on when the draft is cashed by a vendor.

5. A method for creating a draft with one or more payment terms as recited in claim 4, including the step of adjusting the payment terms based on whether the draft was cashed early, on time or late.

6. A method for creating a draft with one or more payment terms as recited in claim 1, wherein the terms emulate a deposit account.

7. A method for creating a draft with one or more payment terms as recited in claim 1, wherein the terms emulate a payment instrument.

8. A method for creating a draft with one or more payment terms as recited in claim 1, including the step of utilizing a digital signature to secure the draft.

9. A method for creating a draft with one or more payment terms as recited in claim 8, wherein the digital signature utilizes a random number sequence.

10. An apparatus that creates a draft with one or more payment terms, comprising; (a) a processor; (b) a memory that stores information under the control of the processor;

(c) logic that retrieves a plurality of terms from the memory;

(d) logic that calculates a payment schedule based on the terms;

(e) logic that creates a draft with a payment schedule based on the terms; and

(f) logic that dynamically adjusts the terms based on payment timings.

11. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, comprising:

(a) a code segment that retrieves a plurality of terms from a storage;

(b) a code segment that calculates a payment schedule based on the terms;

(c) a code segment that creates a draft with a payment schedule based on the terms; and (d) a code segment that dynamically adjusts the terms based on payment timings.

12. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11, including a code segment that adjusts the terms based on whether a payment was received early, on time or late.

13. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11, including a code segment that adjusts the interest rate of a payment based on whether a payment was received early, on time or late.

14. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11, including a code segment that adjusts the terms based on when the draft is cashed by a vendor.

15. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11, including a code segment that adjusts the payment terms based on whether the draft was cashed early, on time or late.

16. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11 , wherein the terms emulate a deposit account.

17. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11 , wherein the terms emulate a payment instrument.

18. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11, including a code segment that utilizes a digital signature to secure the draft.

19. A computer program embodied on a computer-readable medium that creates a draft with one or more payment terms, as recited in claim 11, wherein the digital signature utilizes a random number sequence.