HK1168182A

HK1168182A - Prepaid account funds transfer apparatuses, methods and systems

Info

Publication number: HK1168182A
Application number: HK12108925.9A
Authority: HK
Inventors: B．瓦斯藤; V．马西亚斯
Original assignee: 维萨美国公司
Priority date: 2010-02-15
Filing date: 2011-02-15
Publication date: 2012-12-21

Description

Prepaid account funds transfer apparatus, method and system

This patent application publication (hereinafter "description") describes inventive aspects (hereinafter "innovations") directed to various novel innovations and contains material that is subject to copyright, masking work, and/or other intellectual property protection. The corresponding owner of such intellectual property rights has no objection to the facsimile reproduction by anyone of the patent document or the patent specification, as it appears in the issued patent office patent file or records, but otherwise reserves all copyright rights whatsoever.

RELATED APPLICATIONS

According to 35 USC § 119, the application herein claims priority from U.S. provisional patent application serial No.61/304,594 entitled "PREPAID ACCOUNT TRANSFEROR INVISTATION FOR ATRANSFEREE LINKED PREPAID ACCOUNT", attorney docket number 20270-. The entire contents of the aforementioned applications are expressly incorporated herein by reference.

Technical Field

The present invention relates generally to devices, methods, and systems for account-based transactions, and more particularly, to prepaid account funds transfer devices, methods, and systems ("PAFTs").

Background

Many users prefer to engage in account-based transactions, such as transfer-in or transfer-out transactions, because of the security and convenience they provide. Prepaid cards are particularly attractive because they provide additional advantages such as cost alarming and control. The range of account-based transactions is currently limited in the types of transactions that are possible, as well as the people with whom such transactions may be performed.

Drawings

The appendix and/or drawings show various non-limiting examples, inventive aspects, in accordance with the present disclosure:

FIG. 1 is a block diagram illustrating example aspects of prepaid account funds transfer in certain embodiments of PAFTs;

FIG. 2 is a data flow diagram illustrating an example process for generating a customized invitation for a user to open a new prepaid account in some embodiments of a PAFT;

3A-B are logic flow diagrams illustrating exemplary aspects of a generate a customized invitation for a user to open a new prepaid account in some embodiments of a PAFT, e.g., Prepaid Account Application Invitation (PAAI) component 300;

4A-C are data flow diagrams illustrating an example process of registering a new prepay account for a user in some embodiments of a PAFT;

FIGS. 5A-D are logic flow diagrams illustrating example aspects of registering a new prepaid account for a user, e.g., Prepaid Account Registration (PAR) component 500, in some embodiments of a PAFT;

6A-B are data flow diagrams illustrating an example process of transferring a prepaid account of one user to another in some embodiments of a PAFT;

FIG. 7 is a logic flow diagram illustrating exemplary aspects of implementing a transferor user-initiated trigger for a prepaid account funds transfer, e.g., a transferor-initiated funds transfer trigger (Tr-FTT) component 700, in some embodiments of a PAFT;

FIG. 8 is a logic flow diagram illustrating exemplary aspects of implementing an transferee user initiated trigger for prepaid account funds transfer in certain embodiments of a PAFT, e.g., an transferee initiated funds transfer trigger (Te-FTT) component 800;

FIG. 9 is a logic flow diagram illustrating exemplary aspects of server initiated triggers, e.g., server initiated funds transfer trigger (S-FTT) component 900, implemented for prepaid account funds transfers in certain embodiments of PAFTs;

FIGS. 10A-C are logic flow diagrams illustrating example aspects of a prepaid account transfer, e.g., prepaid account funds transfer processing (PA-FTP), component 1000 from one user's prepaid account to another user in some embodiments of a PAFT;

FIG. 11 is a user interface diagram illustrating example aspects of managing prepaid account funds transfers in certain embodiments of PAFTs; and

fig. 12 is a block diagram illustrating an embodiment of a PAFT controller.

The leading digit(s) of each reference number in the drawings indicates the figure in which the reference number is incorporated and/or described in detail. As such, a detailed discussion of reference numeral 101 will be found and/or incorporated in FIG. 1. Reference numeral 201 and the like are introduced in fig. 2.

Detailed Description

Prepaid Account Fund Transfer (PAFT)

Prepaid account funds transfer apparatus, methods and systems (hereinafter "PAFT") convert prepaid account invitation requests into pre-determined prepaid account transactions via various PAFT components.

Fig. 1 is a block diagram illustrating example aspects of prepaid account funds transfer in some embodiments of a PAFT. In some implementations, the prepaid account holder (e.g., 101) may owe the user (e.g., 102-104) money. For example, the prepaid account holder may, for example, owe money in the example of users 103 and 103 for the services provided. In some cases, users owed money may not be able to accept funds (see, e.g., 111) through account-based transactions such as credit card payments, for example, because they may not have an infrastructure to handle such transactions as merchants (e.g., gardeners, repairmen). Users may also be reluctant to accept the owed money in other forms, such as checks, because they may not even have a bank account, or because accepting such payment may subject them to higher levels of risk (see, e.g., 112 and 113), which may appear unacceptable to them (e.g., 116). In some cases, such users may, for example, be owed money periodically (see, e.g., 114). For example, some services may require multiple executions, perhaps on a regular, repeatable schedule, thus requiring payments on a regular, repeatable schedule. In another example, the issue of transferring funds from the prepaid account holder to the user may be exacerbated by the fact that a long schedule of payment owes may be predetermined. In some cases, the prepaid account holder may wish to transfer funds to a user (e.g., 104) (see, e.g., 117), but may wish to exercise cost control over the user to whom the prepaid account holder wishes to pay the debt (see, e.g., 118).

In some implementations, the PAFT may allow the prepaid account holder 101 to invite 104 the user 102 to whom the prepaid account holder wishes to pay the arrears to open the prepaid account through the PAFT. The PAFT may open a prepaid account for such a user and may provide a link between the prepaid account of the prepaid account holder 101 and the user 102 and 104. In some implementations, the PAFT may facilitate a quick, reliable, and secure transfer of prepaid accounts from the prepaid account holder 101 to the user 102 and 104. In some implementations, the PAFT may initiate the funds transfer immediately upon opening the prepaid account of the user 102 and 104. As such, if the user accepts the invitation from the prepaid account holder, the PAFT may, in some implementations, perform a real-time secure transfer from the prepaid account holder to the user. In some implementations, the PAFT may also allow account holders and/or users to create a transfer schedule for future funds transfers. In some implementations, the PAFT may allow a user receiving a new account to similarly invite others without a prepaid account to establish a new prepaid account with the PAFT to facilitate further funds transfers. Such prepaid account funds transfers may also allow the owed transferor to apply cost control to themselves via their prepaid account.

Figure 2 is a data flow diagram illustrating an example process for generating a customized invitation for a user to open a new prepaid account in some embodiments of a PAFT. In some implementations, the transferor user 201 may wish to invite the transferee user 206 to open a prepaid account for the funds transfer. The acquirer user may generate a customized prepaid account invitation for the acquirer user using an acquirer client 202, which the acquirer communicates with a PAFT server 203 ("server"). For example, the yielding user may provide a user input, such as the invitation request input 211, input to the client device. In implementations, the user input may include, but is not limited to: keyboard input, mouse clicks, pressing a button on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching a user interface element on a touch-sensitive display, and/or the like.

In some implementations, the user may provide an invitation request input (e.g., 211) to the transferor client indicating that the user wishes to invite the transferee user to apply for the prepaid account. For example, the transferor user may wish to open a prepaid account for the transferee user so that the transferor user may transfer funds to the transferee user's newly opened prepaid account. As another example, the transferor user may wish to obtain funds from the transferee user periodically (e.g., according to a predetermined schedule) and may wish to use a prepaid account to provide payment for the transfer of funds for risk minimization and/or security purposes.

In response to the transferor providing the invitation request input, the transferor client may generate a prepaid account invitation request (e.g., 21a) and provide (e.g., 213) the generated prepaid account invitation request to a server (e.g., 203). For example, a browser application executing on the transferor client may provide a (secure) hypertext transfer protocol ("http (s))" POST message including prepaid account invitation request details to the server on behalf of the user in the form of data formatted according to extensible markup language ("XML"). The following is an example HTTP (S) POST message that may be sent by a browser executing on the transferor client to provide the prepaid account invitation request to the server:

upon receiving a prepaid account invitation request from a transferor client, server 203 may parse the invitation request to extract the included invitation request data. The parsing process that the server may use is outlined in the description below with reference to fig. 12. In determining the parameters of the invitation request, the server may generate a unique ID associated with the invitation to be generated based on the request. In some implementations, the server may extract data regarding the messaging mode (e.g., SMS, email, voicemail, automated/manual telephone calls, postal mail, etc.) by which the transferor user wishes the PAFT to provide the transferee user with the prepaid account invitation based on the parsing of the request message. Based on the user messaging mode preferences, the server may generate a query (e.g., 214) as a template from a database that the server may use to generate a customized prepaid account invitation message for the transferee user according to the transferor user's messaging mode preferences. The server may issue a query (e.g., 215) to a database (e.g., forms database 204a) that stores the invitation template. For example, the server may execute a PHP script that includes structured query language ("SQL") commands to query a relational database that stores invitation templates. The following provides an example listing written substantially in the form of PHP/SQL commands that shows the substantive aspects of querying a database to obtain an invitation template:

in response to the invitation template query, the form database may provide (e.g., 216) the requested invitation template to the server. In some implementations, the server may parse (e.g., 217) the invitation request to determine information for the transferee user that will be the recipient of the prepaid account invitation. Based on the recipient information of the transferee user, the server may generate a customized prepaid account invitation. For example, the customized prepaid account invitation may take the form of a text message, SMS, email, electronic communication, facsimile, voicemail, automated telephone call, script printout for manual dialing by a customer service representative, automated/manual online conversation script, web page, and/or the like. In some implementations, the server may store (e.g., 218) the generated customized invitation, unique ID, and/or other invitation data to a database, such as the invitation database 204 b. The following provides an example list written substantially in the form of PHP/SQL commands for storing invitation data in a database:

in some implementations, the server may provide the generated customized prepaid account invitation (e.g., 219) to the transferee client (e.g., 205) of the transferee user (e.g., 206) specified by the transferor user's invitation request. For example, the server may send an email message to the assignee user's email message account. The following provides an example list written substantially in the form of PHP/SQL commands for a server to send an email message to an e-mail message account of an assignee user:

in some implementations, the transferee client may present a customized prepaid account invitation for presentation to the transferee user (e.g., 220). For example, the transferee client may present a web page, an electronic message, a text/SMS message, buffer a voicemail, ring a tone and/or play an audio message for the transferee user to answer, and the like. The transferee client may then present the customized prepaid account invitation (e.g., 221) to the transferee user. For example, the assignee client may provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a vibration-enabled client device such as a smartphone, etc.), and/or the like. In some implementations, the server may also provide an invitation confirmation message (e.g., 222) to the transferor client of the transferor user. For example, the server may send an email message to an email message account of the transferor user. The transferor client may present the customized prepaid account invitation for presentation to the transferor user (e.g., 223). For example, the transferee client may present a web page, an electronic message, a text/SMS message, buffer a voicemail, ring a tone and/or play an audio message for the transferee user to answer, and the like. The transferor client may then present the customized prepaid account invitation (e.g., 224) to the transferor user. For example, the transferor client may provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a vibration-enabled client device such as a smartphone, etc.), and/or the like.

Figures 3A-B are logic flow diagrams illustrating exemplary aspects of a generate a customized invitation for a user to open a new prepaid account, e.g., Prepaid Account Application Invitation (PAAI) component 300, in some embodiments of a PAFT. In some implementations, the transferee user may invite the transferee user to open a prepaid account for the transfer of funds. For example, the acquirer user may provide an invitation request input (e.g., 301) that is input to the acquirer client. In some implementations, the invitation request input provided by the user may indicate to the transferor client that the user wishes to invite the transferee user to apply for the prepaid account. For example, the transferor user may wish to open a prepaid account for the transferee user so that the transferor user may transfer funds to the transferee user's newly opened prepaid account. As another example, the transferor user may wish to obtain funds from the transferee user periodically (e.g., according to a predetermined schedule) and may wish to use a prepaid account to provide payment for the transfer of funds for risk minimization and/or security purposes. In response to the transferor providing an invitation request input, the transferor client may generate a prepaid account invitation request (e.g., 302) and provide the generated prepaid account invitation request to the PAFT server.

Upon obtaining (e.g., 303) a prepaid account invitation request from a transferor client, the server may parse the invitation request to extract included invitation request data (e.g., 304). The parsing process that the server may use is outlined in the description below with reference to fig. 12. Based on the parsing, the server may extract the following data fields, including, but not limited to: request _ id, timestamp, transfer _ id, client _ IP, transfer _ details _ list, transfer _ type, first _ name, last _ name, contact _ type, contact _ info, alt _ contact _ type, alt _ contact _ info, client _ type, num _ info _ attributes, account _ params _ list, same _ bank _ flag, same _ bridge _ flag, persistent _ link _ flag, transfer _ param _ list _ flag, on _ schedule _ flag, time _ one _ flag, estimate _ transit _ flag, input _ transfer _ flag, collection _ information, transfer _ details _ list, transfer _ type _ IP, and the like. In determining the parameters of the invitation request, the server may generate a unique ID, e.g., 306, associated with the invitation to be generated based on the request. For example, the server may execute a hypertext preprocess ("PHP") script that invokes the md5() command to generate a hash of the invitation request message and use the generated message hash as the unique invitation ID. As another example, the server may use the rand () command to generate a random number that is used as a unique invitation ID. In some implementations, the server may extract data regarding the messaging mode (e.g., SMS, email, voicemail, automated/manual telephone calls, postal mail, etc.) by which the transferor user wishes the PAFT to provide the transferee user with the prepaid account invitation based on the parsing of the request message. Based on the user messaging mode preferences, the server may generate a query (e.g., 307) for the template from a database that the server may use to generate a customized prepaid account invitation message for the transferee user according to the transferor user's messaging mode preferences. The server may issue a query to a database (e.g., a forms database) that stores the invitation template. In response to the invitation template query, the form database may provide (e.g., 308) the requested invitation template to the server.

In some implementations, the server may parse (e.g., 309) the invitation request to determine information for the transferee user that will be the recipient of the prepaid account invitation. For example, the server may extract the following data fields, such as, but not limited to: transfer _ ID, transfer _ type, first _ name, last _ name, contact _ type, contact _ info, alt _ contact _ type, alt _ contact _ info, client _ type, and/or the like. Based on the recipient information of the transferee user, the server may generate (e.g., 310) a customized prepaid account invitation. For example, the customized prepaid account invitation may take the form of a text message, SMS, email, electronic communication, facsimile, voicemail, automated telephone call, script printout for manual dialing by a customer service representative, automated/manual online conversation script, web page, and/or the like. In some implementations, the server can generate (e.g., 311) a custom invitation data record, including data fields, unique IDs, custom invitations, and/or other invitation data, and provide the invitation data record to a database (e.g., an invitation database for storing invitation data), e.g., 312. In some implementations, the server may provide the generated customized prepaid account invitation (e.g., 313) to the transferee client of the transferee user specified by the transferee user's invitation request. In some implementations, the transferee client may present (e.g., 314) the customized prepaid account invitation for presentation to the transferee user. The transferee client may then present the customized prepaid account invitation (e.g., 315) to the transferee user. In some implementations, the server may also provide an invitation confirmation message (e.g., 316) to the transferor client of the transferor user. The transferor client may present the customized prepaid account invitation for presentation to the transferor user (e.g., 317). The transferor client may then present the customized prepaid account invitation (e.g., 318) for the transferor user.

Figures 4A-C are data flow diagrams illustrating an example process of registering a new prepay account for a user in some embodiments of a PAFT. In some implementations, the transferee user may wish to accept an invitation offer made by the server to open a prepaid account to the PAFT. For example, the transferee user 406 may provide an invitation acceptance input (e.g., 411) to the transferee client to express acceptance of the invitation. In implementations, the user input may include, but is not limited to: keyboard input, mouse clicks, pressing a button on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching a user interface element on a touch-sensitive display, and/or the like. For example, the transferee user may activate a hyperlink including a custom prepaid account invitation in an email message sent by the server to the transferee user. Activating the hyperlink may serve as a signal that the transferee user of the transferee client wishes to accept the invitation to customize the prepaid account. In response to the transferee user input, the transferee client may generate a prepaid account invitation acceptance message (e.g., 412) for the server. For example, a browser executing on the transferee client may generate an http(s) GET message that includes a prepaid account invitation acceptance message. The following provides an example http(s) GET message that may be sent by a browser executing on the assignee client to provide the prepaid account invitation acceptance message to the server:

upon receiving the prepaid account invitation acceptance message from the transferee client, the server 403 parses the invitation acceptance to extract the included invitation acceptance data, e.g., 414. For example, the server may extract a unique invitation ID for the invitation accepted by the transferee user. Based on the extracted invitation data, in some implementations, the server may determine a type of the transferee user to respond with an acceptance of the invitation and a client type of the transferee user. In an alternative implementation, the server may query (e.g., 415) a database (e.g., the invitation database 404b) using the extracted invitation data (e.g., the unique invitation ID) to obtain the type of invitation. For example, the server may obtain the invitation type from the database by issuing PHP/SQL commands similar to those described above with reference to fig. 2. In response, the database may provide the invitation type, e.g., 416, to the server.

In some implementations, the server may generate a query for the prepaid account application form using the invitation type and the client type of the assignee user. For example, various assignee users and/or clients may require and/or prefer different types of prepaid account application forms. For example, the prepaid account application form may be treated as a (dynamic) hypertext markup language ("HTML") page, interactiveA Flash object,Application program and Android^TMAn application program, an interactive sound application program, and the like. Also, the audio/video processing can be based on screen size, number of pixels, audio/video processingCapabilities and/or similar attributes and/or the assignee client and/or the assignee user's preferences, the size, resolution, fidelity, and/or similar attributes of the prepaid account application form. As such, the server may generate a query for a pre-deposit application form customized for the assignee client and/or the assignee user and issue the query to a database (e.g., form database 404a), e.g., 418. In response to the prepaid account application form query, the database may provide prepaid account application forms, e.g., 419, for the attributes and/or preferences of the transferee client and/or the transferee user. The server may provide the acquired prepaid account application form, e.g., 420, to the assignee's client. For example, the server may provide an HTML page to the assignee's client, including an application for a prepaid account stored on the serverReference to a Flash object. The following provides an example HTML code list including references within an HTML pageJavaScript commands of the Flash object:

upon acquiring the prepaid account application, the transferee client may execute the prepaid account application for presentation to the user, e.g., 422. For example, referring to the example above, a web browser executing on the assignee's client device may render (e.g., 421) an HTML web page and may communicate with a server to downloadA Flash object. Installed on the client of the assignee and operating with a browserThe Flash browser plug-in may play/execute the downloaded Flash object for presentation to the assignee user, e.g., 422.

In some implementations, the assignee user may provide an application form input, e.g., 423, to the assignee client. For example, referring to the above example, an adobe flash object including a prepaid account application may provide interactive functionality and may allow a user to enter user input/feedback, e.g., 423, through various mechanisms (e.g., input into a keyboard into a command line interface, mouse input into a graphical user interface, gestures on a touch-sensitive interface, voice commands, etc.). Using the user application form input, the client may generate a filled-in prepaid account application, e.g., 424. For example, executeAssignee clients of Flash objects may generate, maintain, update, and/or store related users and objectsData of the interaction of the Flash object (e.g., application state, application data structure, a piece of memory with data variables, etc.). For example,the Flash object may store a prepaid account application data structure encoded according to a JavaScript object notation ("JSON") format. An example JSON encoded prepaid account application data structure is provided below:

in some implementations, the server may generate a secure communication session with the transferee client to facilitate communication between the transferee client and the server during the prepaid account application process. As an example, prepayThe account application may provide the server with data stored on the assignee's client as prepaid account application data, such as filled prepaid account application 425. E.g. running on the assignee's clientThe Flash object may comprise ActionScript^TM3.0 commands to create a secure sockets layer ("SSL") connection with the server, generate a message including JSON-encoded data such as shown in the example above, and send the message to the server over the secure SSL connection. The following provides a basic ActionScript^TM3.0 to create a secure SSL connection to the server, load prepaid account application data from a locally stored JSON encoded data file, and send a message including the JSON encoded data to the server over the SSL connection:

in some implementations, the server can execute a PHP script that implements an SSL socket server, which listens for incoming communications on the server port to which the assignee client can send data encoded according to the JSON format (e.g., prepaid account application 425). Upon identifying the incoming communication, the PHP script may read the incoming data from the transferee client into a memory variable, which may then be operated on by the transferee client. The following provides an example list written substantially in the form of PHP/SQL commands to accept JSON encoded prepaid account application data from an assignee client over an SSL connection:

in some implementations, the garmentThe server may parse the filled-in prepaid account application form obtained from the assignee's client and extract application data from the filled-in prepaid account application form. Based on the application data, the server may generate an application screening request, e.g., 426. In some implementations, the server may generate a request to perform a security and/or credit audit on the applicant. For example, the server may be for a network such asSuch a credit review service generates applicant screening requests, e.g., 427. In such an example, the server may provide an http(s) POST message, e.g., 407, to the screening server including the applicant details extracted from the filled prepaid account application. An example http(s) POST message including applicant screening request that may be sent to the screening server by the PAFT server is provided below:

upon receiving the applicant screening request, the screening server may process the applicant screening request and may generate an applicant screening report. For example, the screening server may determine that the applicant failed a screening test to obtain prepaid accounts from the PAFT. In such an example, the screening server may provide applicant screening failure reports, e.g., 428 a. If the screening server determines that the applicant passed the screening test for obtaining prepaid accounts from the PAFT, the screening server may respond to the applicant screening request with an applicant screening success report (e.g., 428 b). For example, the screening server may provide an http(s) POST message to the PAFT server including applicant screening reports indicating success or failure of the screening test with respect to the applicant. An example http(s) POST message including applicant screening reports is provided below:

upon receiving the applicant screening report, the PAFT server may determine whether the assignee user applicant passes the screening test. If the applicant fails the screening test, the server may generate a request denied notification, e.g., 429 a. For example, the server may generate an http(s) POST message similar to the examples described above. The server may provide an application denied notification to the assignee client, and the assignee client may present (e.g., 430a) and display (e.g., 431a) the application denied notification for the assignee user.

In some implementations, the server may determine that the assignee user applicant passed the screening test performed by the screening server based on the resolution of the applicant screening report. In such an implementation, the server may continue to create new prepay accounts for the transferee user. For example, the server may determine whether the new prepay account may be hosted locally, or whether the prepay account should be hosted on a different bank/branch/server. For example, the server may obtain prepaid account preferences from the acquirer user's prepaid account application invitation request and/or from the acquirer user's filled-in prepaid application. If the new prepay account can be hosted locally, the server may generate a new user profile and/or user account database record, e.g., 429b, for the transferee user reflecting the new prepay account. If the prepaid account needs to be hosted on another server (e.g., bank/branch server 408), the PAFT server may generate a prepaid account opening request message, e.g., 430b, for the bank/branch server. For example, the PAFT server may generate an http(s) GET message including a prepaid account opening request message similar to the example provided below:

in some implementations, the bank/branch server may require additional information about the transferee user, the invitation request, and/or the like, and may request additional user information, such as an additional user information request 432. For example, the bank/branch server may provide http(s) POST messages similar to the example above to the PAFT server. The PAFT server may parse any obtained additional user information requests and obtain the requested additional information from local memory, databases, and/or any PAFT affiliated entities and/or components, e.g., 433. The PAFT server may responsively generate (e.g., 434) an additional user information message, e.g., in the form of an http(s) POST message similar to the example above, and provide the message to the bank/branch server. In some implementations, the bank/branch server may create a new prepaid account for the transferee user based on information provided by the PAFT server, e.g., 435. The bank/branch server may provide an account issuance message (e.g., 436) to notify the PAFT server and/or other PAFT entities and/or components that a prepaid account has been created for the transferee user at the bank/branch server.

In some implementations, the PAFT server may generate a prepaid account link data record that provides a link between the acquirer's and the acquirer's user's prepaid accounts when the prepaid account is created for the acquirer user (e.g., locally, or on another server such as a bank/branch server). The server may also generate (e.g., 437) a transfer schedule that may specify the funds transfer attributes between the transferor and the transferee prepaid accounts, such attributes including, but not limited to: number of transfers, date of transfers, frequency of transfers, interval of transfers, amount of transfers, notification settings of transfers, and/or the like. An example transfer schedule encoded according to the XML format is provided below:

in some implementations, the server may store user profile records (e.g., 438), prepaid account link data records (e.g., 439), and prepaid account funds transfer calendar records (e.g., 440) to databases (e.g., user database 404c, link database 404d, and calendar database 404 e). For example, the server may issue PHP/SQL commands similar to the following example to store user profiles, prepaid account link data, and prepaid account funds transfer calendar records in a database:

in some implementations, the server may provide account issuance notifications, e.g., 441, to the transferee (and/or transferor) user. For example, the server may provide an http(s) POST message similar to the example above. The client may present (e.g., 442) the account issuance notification for presentation to the user. For example, the client may render a web page, electronic message, text/SMS message, buffer a voicemail, ring a tone for the user to answer and/or play an audio message, and so forth. The client may then present the user with an account issuance notification, e.g., 443. For example, the client may provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a vibration-enabled client device such as a smartphone, etc.), and/or the like.

Figures 5A-D are logic flow diagrams illustrating example aspects of a registration of a new prepaid account for a user, e.g., Prepaid Account Registration (PAR) component 500, in some embodiments of a PAFT. In some implementations, the transferee user may wish to accept an invitation offer made by the server to open a prepaid account to the PAFT. For example, the transferee user may provide an invitation acceptance input (e.g., 501) to the transferee client to express acceptance of the invitation. In response to the transferee user input, the transferee client may generate a prepaid account invitation acceptance message (e.g., 502) for the PAFT server. Upon obtaining (e.g., 503) a prepaid account invitation acceptance message from the transferee client, the server may parse the invitation acceptance message to extract the included invitation acceptance data (e.g., 504). For example, the server may extract the following data fields, including, but not limited to: request _ id, time _ amp, transfer _ id, client _ IP, transfer _ type, first _ name, last _ name, contact _ type, contact _ info, client _ type, account _ param _ list, same _ bank _ flag, same _ bridge _ flag, site _ link _ flag, transfer _ partition _ list, on _ schedule _ flag, one _ time _ flag, amplitude, install _ transfer _ flag, custom _ information, transfer _ details _ list, transfer _ client _ IP, client _ type, client _ MAC, client _ IP, rendering _ format, sample _ count _ list, transfer _ response _ list, transfer _ client _ IP, client _ MAC, transfer _ IP, transfer _ update _ format, transfer _ update _ list, transfer _ update. Based on the extracted data fields, the server may determine the type of the transferee client, e.g., 505. For example, the server may determine whether the transferee client is a desktop computer, a tablet computer, a mobile phone accessing email, text voice messages, and so on. For example, the server may determine attributes of the client device such as screen resolution, screen size, audio/video functionality, hardware configuration, software configuration, applications installed on the client, and/or the like. The server may also extract the unique ID of the invitation from the invitation acceptance, e.g., 506. Based on the extracted invitation data, the server may, in some implementations, generate a query for the type of invitation, e.g., 507, and provide the query to a database (e.g., an invitation database). For example, the server may query for invitation attributes such as, but not limited to: transfer _ type, account _ params _ list, account _ mode, account _ type, account _ expire, predicted _ bank, predicted _ branch, and/or the like. For example, using such data fields, the server may determine such things as whether the invitation has credited the individual/merchant, whether the account is a pre-deposit/savings/check/cash market account, and so on. In response to a query by the server, the database may provide the requested information, e.g., 508.

In some implementations, the server may generate a query for the prepaid account application form using the invitation type and the client type of the assignee user. The server may generate a query for a pre-deposit application form customized to the assignee client and/or the assignee user and issue the query to a database (e.g., form database 404 a). In response to the prepaid account application form query, the database may provide a prepaid account application form, e.g., 510, for the attributes and/or preferences of the transferee client and/or the transferee user. The server may provide the acquired prepaid account application form, e.g., 511, to the assignee's client. Upon obtaining the prepaid account application, the transferee client may present/execute (e.g., 512) the prepaid account application and present the prepaid account application to the transferee user, e.g., 513.

In some implementations, the assignee user may provide application form input to the assignee client, e.g., 514. Using the user application form input, the client may generate a filled-in prepaid account application, e.g., 515. The assignee client may provide the server with a filled prepaid account application. In some implementations, the server may obtain a filled-in prepaid account application form from the assignee's client, e.g., 516, and parse (e.g., 517) the filled-in application to extract application data from the filled-in prepaid account application form. For example, the server may obtain the following fields, such as, but not limited to: application _ ID, application _ firstname, application _ lastname, dob, ssn, credit _ check _ ok _ flag, address _ line1, address _ line2, zip code, city, state, account _ params _ list, account _ mode, account _ type, account _ expirry, bank _ name, bridge _ name, and/or the like. Based on the application data, the server may generate an application screening request, e.g., 518. In some implementations, the server may generate a request to perform a security and/or credit audit on the applicant. Upon receiving an applicant screening request, e.g., 519, the screening server may process (e.g., 520) the applicant screening request and may generate an applicant screening report, e.g., 521. For example, the screening server may determine whether the applicant passes or fails a screening test to obtain prepaid accounts from the PAFT. Upon obtaining and parsing (e.g., 522) applicant screening reports, the PAFT server may determine whether the assignee user applicant passed the screening test, e.g., 523. If the applicant fails the screening test (e.g., 523), option "no," the server may generate an application denied notification, e.g., 543. The server may provide an application denied notification to the transferee client, and the transferee client may present (e.g., 545) and display (e.g., 546) the application denied notification for the transferee user.

In some implementations, the server may determine that the assignee user applicant passed the screening test performed by the screening server, e.g., 523, with the option "yes," based on parsing the applicant screening report. In such an implementation, the server may continue to create new prepay accounts for the transferee user. The server may generate a user profile, e.g., 524, for the assignee user applicant. For example, the server may also determine whether the new prepay account may be hosted locally, or whether the prepay account should be hosted on a different bank/branch/server, e.g., 525. For example, the server may obtain prepaid account preferences from the acquirer user's prepaid account application invitation request and/or from the acquirer user's filled-in prepaid application. If the new prepay account can be hosted locally, e.g., 525, option "no," the server may generate a new user profile and/or user account database record, e.g., 526, for the transferee user reflecting the new prepay account. If the prepaid account needs to be hosted on another server (e.g., 525, option "yes"), the PAFT server may generate a prepaid account opening request message, e.g., 527, for the bank/branch server. The PAFT server may provide a prepaid account opening request message to the bank/branch server in which the account should be opened based on the applicant data extracted from the applicant's filled prepaid account application form. In some implementations, the bank/branch server may, upon obtaining the prepaid account opening request (e.g., 528), parse the prepaid account opening request (e.g., 529) and extract the request data. For example, the bank/branch server may extract the following fields, including, but not limited to: application _ firstname, application _ lastname, application _ address _ line1, application _ address _ line2, application _ clear _ flag, and/or the like. If the bank/branch server determines that it requires additional information, e.g., about the transferee user, the invitation request, and/or the like, e.g., 530, the bank/branch server may generate an additional user information request (e.g., 531) and provide the request for additional user information to the PAFT server. The PAFT server may parse (e.g., 532) additional user information requests from the bank/branch server and determine the additional user information requested, e.g., 533. The PAFT server may generate additional user information messages, e.g., 534, using information obtained, for example, from local memory, databases, and/or any entity and/or component to which the PAFT pertains. The PAFT server may provide the message to the bank/branch server. Upon obtaining the additional user information message (e.g., 535), the bank/branch server may, in some implementations, create a new prepaid account for the transferee user based on the information provided by the PAFT server, e.g., 536. The bank/branch server may generate an account issuance message (e.g., 537) and provide the account issuance message to notify the PAFT server and/or other PAFT entities and/or components that a prepaid account has been created for the transferee user at the bank/branch server.

In some implementations, the PAFT server may, upon obtaining a notification (and/or creating a prepaid account) for the transferee server (e.g., locally, or on another server such as a bank/branch server), generate a prepaid account link data record, e.g., 538, that provides a link between the transferee and transferee user's prepaid accounts. The server may also generate (e.g., 539) a prepaid account funds transfer schedule that may specify the funds transfer attributes between the transferor and the transferee prepaid accounts, such attributes including, but not limited to: number of transfers, date of transfers, frequency of transfers, interval of transfers, amount of transfers, notification settings for transfers, and/or the like. In some implementations, the server may also generate a user profile record, e.g., 540. The server may provide the user account data record, the prepaid account link data record, and/or the prepaid account funds transfer calendar record to a database, such as a user database, a link database, and/or a calendar database. In some implementations, the server may provide account issuance notifications to the transferee (and/or transferor) user, e.g., 543. The client can present (e.g., 545) the account issuance notification for presentation to the user. The client may then present the user with an account issuance notification, e.g., 546.

6A-B are data flow diagrams illustrating an example process of transferring a prepaid account from one user to another user in some embodiments of a PAFT. In some implementations, various inputs to a server (e.g., the PAFT server 603) may trigger a prepaid account funds transfer from a transferor user's prepaid account to an transferee user's prepaid account.

As an example, the server may initiate a prepaid account funds transfer spontaneously upon creation of a new prepaid account (e.g., an transferor and/or transferee user account) by the PAFT and/or affiliated entity and/or component.

As another example, the transferor user (e.g., 601) may provide a payment voucher input (e.g., 611a) to the transferor client (e.g., 602) requesting a transfer from the transferor user's prepaid account to the transferee user's prepaid account. The transferor client may use the transferor user's payment voucher input to generate a prepaid account payment voucher, e.g., 612 a. The transferor client may provide a prepaid account payment voucher (e.g., 613a) to the server (e.g., 603), which may trigger the server to perform the transfer requested by the transferor user.

As another example, the transferee user (e.g., 606) may provide an accounts receivable request input (e.g., 611b) to the transferee client (e.g., 605) requesting that funds owed be transferred from the transferor user's prepaid account to the transferee user's prepaid account. The transferee client may generate a prepaid account accounts receivable request, e.g., 612b, using the transferee user's receivable request input. The transferee client may provide a prepaid account accounts receivable request (e.g., 613b) to the server (e.g., 603), which may trigger the server to perform the transfer requested by the transferee user.

As another example, a server (e.g., 603) may query a database, such as calendar database 604e, to obtain a transfer calendar (e.g., 611 c). For example, the server may continuously, periodically, on-demand, and/or otherwise query the database. In response to the query, the database may provide a transfer schedule, e.g., 612 c. The server may retrieve the transfer calendar and parse it to extract calendar data relating to transfers between the transferor user (e.g., 601) and the transferee user (e.g., 606). The server may analyze the data (e.g., 613c) to determine whether a transfer should be initiated between the transferor user's prepaid account and the transferee user's prepaid account.

In general, it is contemplated that various events and/or data changes in any of the PAFT components and/or affiliated entities may cause the PAFT to perform a prepaid account funds transfer from the transferor user's prepaid account to the transferee user's prepaid account.

In some implementations, the PAFT server may obtain triggers, such as those described above, to perform a prepaid account funds transfer from the transferor user's prepaid account to the transferee user's prepaid account. In response to the trigger, the server may generate a query for the linked data records and provide (e.g., 614) the query to a database, e.g., linked database 604 d. For example, the server may issue PHP/SQL commands similar to the examples provided below:

in response to obtaining the query from the server, the database may provide transfer link data records, e.g., 615. In some implementations, the server may generate a query for one or more user profile data records (e.g., user profile data records of an acquirer user and/or an acquirer user). The server may provide a user profile data query (e.g., 616) to a database (e.g., user database 604 c). For example, the server may issue PHP/SQL commands to the user database similar to the example above. In response to the query, the user database may provide the requested user profile data record.

In some implementations, the server may initiate a transfer of funds from the transferor user's prepaid account to the transferee user's prepaid account using the link data record and/or the user profile data record. For example, the server may determine whether both the acquirer user and the acquirer user's prepaid accounts are stored locally. If both prepaid accounts are stored locally, the server may roll out from the transferor user's prepaid account and roll in to the transferee user's prepaid account, e.g., 618. Alternatively, in another example, if the acquirer user and/or the acquirer user's prepaid account are not stored locally, the server may use the link data and/or user profile data to generate one or more transaction request messages and provide the transaction request messages (e.g., 619) to one or more bank/branch servers (e.g., 608). For example, the server may provide a bank/branch server with http(s) POST messages similar to the examples provided below:

in response, the bank/branch server may process the transaction request (e.g., 620) and provide a transaction complete message (e.g., 621) to the PAFT server. Upon obtaining a transaction completion message from a bank/branch server participating in the prepaid account funds transfer, the PAFT server may generate and provide a transaction notification message (e.g., 623a-b) to the transferor client and/or the transferee client. For example, the server may provide an http(s) POST message similar to the example above. The client may present (e.g., 442) the transaction notification message for presentation to the user. For example, the client may render a web page, electronic message, text/SMS message, buffer a voicemail, ring a tone for the user to answer and/or play an audio message, and so forth. The client may then present the user with a transaction notification message, e.g., 443. For example, the client may provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a vibration-enabled client device such as a smartphone, etc.), and/or the like.

Fig. 7 is a logic flow diagram illustrating exemplary aspects of implementing a transferor user-initiated trigger for a prepaid account funds transfer, e.g., a transferor-initiated funds transfer trigger (Tr-FTT) component 700, in certain embodiments of a PAFT. In some implementations, the transferor user may provide payment voucher input to the transferor client, e.g., 701. In response, the transferor client may generate a prepaid account payment voucher, e.g., 702. The transferor client may provide the generated prepaid account payment voucher to the PAFT server. In some implementations, the server may parse the obtained prepaid account payment voucher, e.g., 704, upon obtaining the voucher, e.g., 703. The server may extract the details of the prepaid account payment voucher and determine (e.g., 705) whether a transfer should be made from the transferor user's prepaid account to the transferee user's prepaid account based on the details provided in the prepaid account transfer voucher. For example, the server may perform security checks to ensure that the voucher was issued by an authorized entity, that the amount of the transfer passed anti-fraud checks, and/or the like. The server may also determine whether account information, amount information, etc. is normally provided in the prepaid account transfer voucher. If the server determines that a prepaid account funds transfer must be performed (e.g., 706, option "yes"), the server may generate a prepaid account funds transfer trigger, e.g., 710. In some implementations, the server may push the generated prepaid account funds transfer trigger into a queue of prepaid account funds transfer triggers. In some implementations, the server may determine that a prepaid account funds transfer should not be made, e.g., 706, option "no". In such implementations, the server may generate a payment voucher cancellation notification, e.g., 707, and provide the generated payment voucher cancellation notification to the transferor client. The transferor client may present the obtained payment voucher cancellation notification, e.g., 708, and provide the presented payment voucher cancellation notification, e.g., 709, to the transferor user. For example, the client may provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a vibration-enabled client device such as a smartphone, etc.), and/or the like.

Fig. 8 is a logic flow diagram illustrating exemplary aspects of implementing an transferee user initiated trigger for prepaid account funds transfer, e.g., an transferee initiated funds transfer trigger (Te-FTT) component 800 in some embodiments of a PAFT. In some implementations, the transferee user may provide an accounts receivable request input, e.g., 801, to the transferee client. In response, the transferee client may generate a prepaid account accounts receivable request, e.g., 802. The transferee client may provide the generated prepaid account accounts receivable request to the PAFT server. In some implementations, the server may parse the obtained prepaid account accounts receivable request, e.g., 804, upon obtaining the prepaid account receivable request, e.g., 803. The server may extract the details of the prepaid account accounts receivable request and determine (e.g., 805) whether a transfer should be made from the transferor user's prepaid account to the transferee user's prepaid account based on the details provided in the prepaid account receivable request. For example, the server may perform security checks to ensure that the voucher was issued by an authorized entity, that the amount of the transfer passed anti-fraud checks, and/or the like. The server may also determine whether account information, amount information, etc. is normally provided in the prepaid account accounts receivable request. If the server determines that a prepaid account funds transfer must be performed (e.g., 806, option "yes"), the server may generate a prepaid account funds transfer trigger, e.g., 810. In some implementations, the server may push the generated prepaid account funds transfer trigger into a queue of prepaid account funds transfer triggers. In some implementations, the server may determine that a prepaid account funds transfer should not be made, e.g., 806, option "no". In such an implementation, the server may generate an account receivable refusal notification, e.g., 807, and provide the transferee client with the generated account receivable refusal notification. The transferee client may present the obtained account receivable refusal notification, e.g., 808, and provide the transferee user with the presented account receivable refusal notification, e.g., 809. For example, the client may provide output including, but not limited to: sound, music, audio, video, images, haptic feedback, vibration alerts (e.g., on a vibration-enabled client device such as a smartphone, etc.), and/or the like.

Fig. 9 is a logic flow diagram illustrating example aspects of a server initiated trigger, e.g., a server initiated funds transfer trigger (S-FTT) component 900, implemented for prepaid account funds transfer in certain embodiments of a PAFT. In some implementations, the PAFT server may generate (e.g., 901) requests for transfer schedules for designated transferor and transferee users, and may provide requests for a database (e.g., a calendar database). For example, the server may continuously, periodically, on-demand, and/or otherwise query the database. In response to the request, the database may provide the requested transfer schedule, e.g., 902. The server may obtain a transfer schedule (e.g., 903) and parse it to extract schedule data relating to transfers between the transferor user and the transferee user, e.g., 904. The server may analyze the data (e.g., 905) to determine whether a transfer should be initiated between the transferor user's prepaid account and the transferee user's prepaid account. If the server determines that a transfer should be initiated between the transferor user's prepaid account and the transferee user's prepaid account, e.g., 906, option "yes," the server may generate a prepaid account funds transfer trigger, e.g., 907. However, if the server determines that a transfer should not be initiated between the transferor user's prepaid account and the transferee user's prepaid account, e.g., 906, option "no," the server may reset the process and repeat the process as necessary.

Fig. 10A-C are logic flow diagrams illustrating example aspects of a prepaid account transfer, e.g., prepaid account funds transfer processing (PA-FTP) component 1000, from one user's prepaid account to another user in some embodiments of a PAFT. In some implementations, the PAFT server may obtain a prepaid account funds transfer trigger, e.g., 1001, to transfer between the transferor's pre-deposited user account and the transferee's pre-deposited user account. For example, the server may retrieve the trigger from a queue of prepaid account funds transfer triggers, from a Tr-FTT component, e.g., 700, a Te-FIT component, e.g., 800, an S-FTT component, e.g., 900, and/or similar PAFT entity and/or component. Upon acquiring the prepaid account funds transfer trigger, the server may determine the amount of funds to be transferred from the transferor user's prepaid account to the transferee user's prepaid account, e.g., 1002. For example, the server may parse a payment voucher, accounts receivable request, transfer schedule, and/or similar data record to obtain the amount of funds to be transferred. In determining the amount of the transfer, the server may generate a transfer link query, e.g., 1003, for link data relating to a link between the transferor user and the transferee user's prepaid account. The server may provide the transfer link query to a database (e.g., a linked database). In response, the database may provide the requested link data, e.g., 1004. In some implementations, the server may generate a query, e.g., 1005, for the user profile data of the transferee and/or transferee user. The server may issue a user profile data query to a database (e.g., a user database). In response to receiving the user profile data query, the database may provide the requested user profile data, e.g., 1006. Upon retrieving the link data and/or user data from the database, the server may determine whether the prepaid accounts of the acquirer and the acquirer user are stored locally, e.g., 1007.

If the server determines that both prepaid accounts are stored locally, e.g., 1008, and the option "yes," the server may transfer the amount of the determined prepaid account funds transfer from the transferor user's prepaid account and transfer the amount of the determined prepaid account funds transfer to the transferee user's prepaid account, e.g., 1009. In some implementations, the server may determine that neither prepaid account is stored locally, e.g., 1008, with option "no". In such implementations, the server may generate one or more transaction request messages to perform prepaid account actions (e.g., transfer in and/or out). The server may provide the transaction request message to one or more bank/branch servers. The bank/branch server, upon obtaining the transaction request message, e.g., 1011, may perform the transaction according to the request message, e.g., 1012. The bank/branch server may generate a transaction complete message, e.g., 1013, and provide the transaction complete message to the PAFT server.

In some implementations, the PAFT server may obtain an indication that the funds transfer has been successfully completed between the transferor user and the transferee user's prepaid accounts. If the server determines that the funds transfer has been successful (e.g., 1014, option "yes"), the server may generate a funds transfer notification message, e.g., 1016, for the transferee and/or transferee user. If the server determines that the funds transfer was not successful (e.g., 1014, option "no"), the server may generate a funds transfer failure notification message for the transferee and/or transferee user, e.g., 1015. The server may provide the generated notification to the acquirer and/or the transferee client. The client can present (e.g., 1017) the notification and present (e.g., 1018) the notification to the user. In some implementations, the server may generate (e.g., 1019) updated transaction data, user profile data, and/or calendar data records based on the prepaid account funds transfer (or failure) and provide the data records to the database. Databases, e.g., calendar databases and/or user databases, may store (e.g., 1020) data records provided by the server.

Fig. 11 is a user interface diagram illustrating example aspects of managing prepaid account funds transfers in certain embodiments of a PAFT. In some implementations, the PAFT may allow the user to manage the prepaid account through the interface (e.g., manage transfers to and from the prepaid account). For example, the user can manage a prepay account through a web browser interface, e.g., 1101. In some implementations, a user can transfer an application (e.g.,application program and Android^TMApplication program, HP Palm OS application program, Windows^TMMobile application program,Applications, etc.) are downloaded to their client device, which may provide an interface for prepay account management (see, e.g., 1112). The interface may provide notification of the status of one or more prepay accounts, for example 1102. For example, the interface may provide details such as, but not limited to: account number, account balance, account transaction history, transaction history statistics (e.g., number of transactions within a predetermined/flexible time window, frequency of transactions, cumulative transaction amount across time, account and/or other user, transaction made by user, indication of amount of bidirectionality of transfer), upcoming scheduled transfers, and/or the like. In some implementations, a screen such as those listed above may be provided on a single screen at the same timeThose information of (a). In an alternative implementation, the user interface may be designed as a complex multi-screen interface that can present detailed information across various types of analysis using multiple screens. In some implementations, the interface may provide a contact list, e.g., 1103. For example, the contact list may include a list of other users with whom the user has made a prepaid account funds transfer (e.g., as an acquirer and/or an acquirer). In some implementations, the user can activate a link (see, e.g., 1104a) to initiate a transfer with another user and/or create a transfer schedule for a prepaid account funds transfer with the user. For example, one or more users listed in the contact list may be selected simultaneously (e.g., by clicking on a single user, selecting multiple users and activating a graphical user interface element for initiating/scheduling transfers with each of the simultaneously selected users), which when activated, provides the user with an interface in which the user may initiate and/or schedule transfers of prepaid account funds with the selected users (see, e.g., 1104 b). In some implementations, the user interface may include one or more graphical user interface elements to provide information regarding upcoming scheduled transfers, such as a graphical calendar 1105 and a text calendar list 1106. The graphical user elements may provide indications, alerts, notifications of expired and/or upcoming transfers. In some implementations, the PAFT may send alerts, notifications, and/or the like (e.g., pager number, mobile phone number, email address, mailing address) to the user's contacts for the user.

In some implementations, the user interface may provide various elements for inviting (see, e.g., 1107) other users to apply for obtaining a new prepay account with the PAFT. For example, the user interface may provide a hyperlink, e.g., 1108, which when activated, may provide the user with a graphical user interface element that generates and sends an invitation request for the PAFT. In implementations, users can invite other users to create prepaid accounts with a PAFT via text messages (e.g., 1109), phone (e.g., 1110), chat, social network (e.g., 1111), and/or the like.

PAFT controller

Fig. 12 illustrates in a block diagram aspects of the invention of a PAFT controller 1201. In this embodiment, the PAFT controller 1201 may be intended to aggregate, process, store, search, serve, identify, indicate, generate, match, and/or perform interactions with a computer through various techniques and/or other relevant data.

In general, a user, who may be a person and/or other system, may engage in an information technology system (e.g., a computer) to perform information processing. The computer in turn uses a processor to process the information; such a processor 1203 may be referred to as a Central Processing Unit (CPU). One form of processor is known as a microprocessor. The CPU uses the communication circuit to pass binary-coded signals, which serve as instructions, to perform various operations. These instructions may be data instructions that are operable and/or contain and/or reference other instructions and data in various processor and operable areas of memory 1229 that are accessible (e.g., registers, caches, random access memory, etc.). Such communication instructions may be stored and/or transmitted as a batch of program and/or data components (e.g., a batch of instructions) to perform desired operations. These stored instruction codes, e.g., programs, may cause the CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, which may be executed by a CPU on a computer; the operating system allows and facilitates user access to and operation of computer information technology and resources. Some resources that may be used in information technology systems include: input and output mechanisms that can be used to pass data into and out of the computer; a memory store to which data may be saved; and a processor that may be used to process information. These information technology systems can be used to collect data for later retrieval, analysis, and manipulation, which can be facilitated by database programs. These information technology systems provide interfaces that allow users to access and operate various system components.

In one embodiment, the PAFT controller 1201 may be connected to and/or in communication with the following entities, such as, but not limited to: one or more users from user input devices 1211; peripheral devices 1212; an optional cryptographic processor device 1228; and/or a communication network 1213.

A network is generally viewed as comprising the interconnection and interoperation of clients, servers, and intermediate nodes in a graph topology. It should be noted that the term "server" as used in this application generally refers to a computer, other device, program, or combination thereof that processes requests from and responds to remote users across a communication network. The servers serve their information to the requesting "client". The term "client," as used herein, generally refers to a computer, program, other device, user, and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communication network. Computers, other devices, programs, or combinations thereof that facilitate processing information and requests, and/or that facilitate transferring information from a source user to a destination user are often referred to as "nodes". Networks are generally considered to facilitate the transfer of information from a source point to a destination. Nodes that are specifically tasked with facilitating the transfer of information from a source to a destination are often referred to as "routers". There are many forms of networks, such as Local Area Networks (LANs), pico networks, Wide Area Networks (WANs), wireless networks (WLANs), and so forth. For example, the Internet is generally accepted as being an interconnection of networks, such that remote clients and servers can access and interoperate with each other.

The PAFT controller 1201 may be based on a computer system that may include, but is not limited to, components such as the computer system 1202 connected to a memory 1229.

Computer system

The computer system 1202 may include a clock 1230, a central processing unit ("CPU" and/or "processor") (unless specifically stated otherwise, these terms are used interchangeably throughout the specification)) 1203, a memory 1229 (e.g., a read-only memory (ROM)1206, a Random Access Memory (RAM)1205, etc.), and/or an interface bus 1207, which most frequently, although not necessarily, all are interconnected and/or communicate via a system bus 1204 on the motherboard 1202 having one or more electrically conductive and/or otherwise transmissive circuit paths through which instructions (e.g., binary encoded signals) may propagate to perform communications, operations, storage, etc. Optionally, the computer system may be connected to an internal power supply 1286; for example, optionally, the power source may be internal. Optionally, a cryptographic processor 1226 and/or a transceiver (e.g., IC)1274 may be connected to the system bus. In another embodiment, the cryptoprocessor and/or transceiver may be connected through an interface bus I/O as an internal and/or external peripheral device 1212. The transceiver, in turn, may be connected to an antenna 1275, thereby enabling wireless transmission and reception of various communication and/or sensor protocols; for example, the antenna may be connected to: texas Instruments WiLink WL1283 transceiver chip (e.g., providing 802.11n, bluetooth 3.0, FM, Global Positioning System (GPS) (thereby allowing the PAFT controller to determine its location)); broadcom BCM4329FKUBG transceiver chips (e.g., providing 802.11n, bluetooth 2.1+ EDR, FM, etc.); BroadcomBCM4750IUB8 receiver chip (e.g., GPS); infineon technologies X-Gold 618-PMB9800 (e.g., providing 2G/3G HSDPA/HSUPA communications); and/or the like. The system clock typically has a crystal oscillator and generates the base signal through the circuit paths of the computer system. The clock is typically coupled to a system bus and various clock multipliers that increase or decrease the fundamental operating frequency of other components interconnected in the computer system. The clock and various components in the computer system drive signals that embody information throughout the system. The transmission and reception of such instructions embodying information throughout the computer system may generally be referred to as communication. These communication instructions may further be transmitted, received, and result in return and/or reply communications with an instant computer system between: communication networks, input devices, other computer systems, peripheral devices, and/or the like. Of course, any of the above components may be directly connected to each other, to the CPU, and/or organized in many ways for use, as exemplified by various computer systems.

The CPU includes at least one high speed data processor adapted to execute program components for performing user and/or system generated requests. The processor itself will often include various specialized processing units such as, but not limited to: an integrated system (bus) controller, a memory management control unit, a floating point unit, even specialized processing subunits, a graphics processing unit, a digital signal processing unit, and/or the like. Additionally, the processor may include internal fast access addressable memory and be able to map and address memory 529 outside of the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache (e.g., levels 1, 2, 3, etc.), RAM, and so forth. The processor may access this memory by using a memory address space that is accessible by an instruction address, which the processor may build and decode, allowing it to access a circuit channel to a particular memory address space having a memory state. The CPU may be a microprocessor such as: athlon, Duron and/or Opteron of AMD; an ARM application program, an embedded and secure processor; DragonBall and PowerPC from IBM and/or Motorola; IBM's and Sony's Cell processors; celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale from Intel; and/or the like. The CPU interacts with the memory through instructions transferred via electrical and/or transmission conduits (e.g., (printed) electronic and/or optical circuits) to execute stored instructions (i.e., program code) according to conventional data processing techniques. Such instruction passing facilitates communication within and outside of the PAFT controller through various interfaces. Distributed processors (e.g., distributed PAFTs), mainframe, multi-core, parallel, and/or supercomputer architectures may similarly be used where processing requirements dictate greater speed and/or capacity. Alternatively, a smaller Personal Digital Assistant (PDA) may be used where deployment requires greater portability.

Depending on the particular implementation, the functionality of the PAFT may be implemented by implementing an R8051XC2 microcontroller such as CAST; intel's MCS 51 (i.e., 8051 microcontroller) and/or the like. Also, to implement certain functions of the PAFT, certain functional implementations may rely on embedded components, such as: application specific integrated circuits ("ASICs"), digital signal processing ("DSPs"), field programmable gate arrays ("FPGAs"), and/or similar embedded technologies. For example, any one and/or function of the set of PAFT components (distributed or otherwise) may be by a microprocessor and/or by an embedded component; for example, by ASICs, co-processors, DSPs, FPGAs, and/or the like. Alternatively, certain implementations of PAFTs may be implemented with embedded components configured to implement various functions or signal processing.

Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of hardware/software solutions. For example, the PAFT functionality discussed herein may be implemented by implementing an FPGA, which is a semiconductor device containing programmable logic components called "logic blocks," and programmable interconnects such as the high performance FPGA Virtex family and/or the low cost Spartan family manufactured by Xilinx. The logic blocks and interconnects may be programmed by a customer or designer after the FPGA is manufactured to implement any of the PAFT functions. The hierarchy of programmable interconnects allows logic blocks to be interconnected according to the needs of the PAFT system designer/administrator, somewhat like a single chip programmable test board. The logic blocks of the FPGA can be programmed to perform the functions of basic logic gates such as AND, XOR, or more complex combinatorial functions such as decoders or simple mathematical functions. In most FPGAs, the logic blocks also include memory elements, which can be simple flip-flops or relatively complete blocks of memory. In some cases, a PAFT may be developed on a conventional FPGA and then migrated to a fixed version more similar to an ASIC implementation. An alternative or coordinated implementation may migrate the PAFT controller functionality to the last ASIC in place of or in addition to the FPGA. Depending on the implementation, all of the embedded components and microprocessors as previously described may be considered "CPUs" and/or "processors" of PAFTs.

Power supply

Power source 1286 may be of any standard form for powering small electronic board devices, such as the following batteries: alkaline, lithium monohydrogen, lithium ion, lithium polymer, cadmium-nickel, solar cells, and/or the like. Other types of AC or DC power sources may also be used. In the case of a solar cell, in one embodiment, the housing provides a gap through which the solar cell can capture photon energy. A battery 1286 is connected to at least one of the interconnected subsequent components of the PAFT, thereby providing current to all of the subsequent components. In one example, a power supply 1286 is connected to the system bus component 1204. In an alternative embodiment, an external power supply 1286 is provided through a connection across the I/O1208 interface. For example, USB and/or IEEE 1394 connections transmit data and power across the connection and are therefore suitable power sources.

Interface adapter

The interface bus 1207 may accept, connect to, and/or communicate with a number of interface adapters, typically, though not necessarily, in the form of adapter cards, such as, but not limited to: input output interface (I/O)1208, memory interface 1209, network interface 1210, and/or the like. Optionally, a cryptographic processor interface 1227 may similarly be connected to the interface bus. The interface bus is used for the interface adapters to communicate with each other and with other components of the computer system. The interface adapter is adapted for a compatible interface bus. The interface adapter is connected to the interface bus by a socket architecture in a conventional manner. Conventional socket architectures may be used, such as, but not limited to: accelerated Graphics Port (AGP), card bus, (extended) industry Standard architecture ((E) ISA), Micro Channel Architecture (MCA), NuBus, peripheral component interconnect (extended) (PCI (X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.

The memory interface 1209 may accept, communicate, and/or connect to a number of storage devices, such as, but not limited to: storage 1214, a removable disk device, and/or the like. The memory interface may use the following connection protocols, such as, but not limited to: (super) (family) advanced technology attachment (packet interface) ((super) (family) ata (pi)), (enhanced) integrated drive electronics ((E) IDE), Institute of Electrical and Electronics Engineers (IEEE)1394, fibre channel, Small Computer System Interface (SCSI), Universal Serial Bus (USB), and/or the like.

The network interface 1210 may accept, communicate and/or connect to a communication network 1213. The PAFT controller is accessible by a user 1233a through a remote client 1233b (e.g., a computer with a web browser) over a communication network 1213. The network interface may use the following connection protocols, such as, but not limited to: direct connections, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), token ring, wireless connections such as IEEE 802.11a-x, and/or the like. Where processing requirements dictate greater speed and/or capacity, a distributed network controller (e.g., distributed PAFT) architecture may similarly be used to consolidate, load balance, and/or otherwise increase the communication bandwidth required by the PAFT controller. The communication network may be any one and/or combination of the following: a direct interconnection; the internet; a Local Area Network (LAN); metropolitan Area Networks (MANs); an operational task (OMNI) as a node on the internet; a secure custom connection; a Wide Area Network (WAN); a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A network interface may be considered a special form of input-output interface. Further, multiple network interfaces 1210 may be used to interface with various communication network types 1213. For example, multiple network interfaces may be used to allow communication over broadcast, multicast, and/or unicast networks.

Input/output interface (I/O)1208 may accept, communicate, and/or connect to user input devices 1211, peripheral devices 1212, cryptographic processor device 1228, and/or the like. The I/O may use the following connection protocols, such as, but not limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: apple Desktop Bus (ADB), IEEE 1394a-b, Serial, Universal Serial Bus (USB); infrared rays; a joystick; a keyboard; midi; optics; PC AT; PS/2; parallel connection; a radio; video interface: apple Desktop Connectors (ADC), BNC, coaxial, component, composite, digital, Data Video Interface (DVI), High Definition Multimedia Interface (HDMI), RCA, RF antenna, S-video, VGA, and/or the like; a wireless transceiver: 802.11 a/b/g/n/x; bluetooth; cellular (e.g., Code Division Multiple Access (CDMA), high speed packet access (HSPA (+), High Speed Downlink Packet Access (HSDPA), global system for mobile communications (GSM), Long Term Evolution (LTE), WiMax, etc.); and/or the like. A typical output device may include a video display, which typically includes a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor, with an interface (e.g., DVI circuitry and cabling) that receives signals from the video interface. The video interface synthesizes information generated by the computer system and generates a video signal based on the synthesized information in the video memory frame. Another output device is a television that receives signals from a video interface. Typically, the video interface provides the composite video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector that accepts an RCA composite video cable; a DVT connector that accepts a DVI display cable, etc.).

The user input devices 1211 is often one type of peripheral device 512 (see below), and may include: a card reader, dongle, fingerprint reader, glove, tablet, joystick, keyboard, microphone, mouse, remote control, retina reader, touch screen (e.g., capacitive, resistive, etc.), trackball, track pad, sensor (e.g., accelerometer, ambient light, GPS, gyroscope, proximity, etc.), stylus, and/or the like.

Peripheral devices 1212 may be connected to and/or communicate with I/O (and/or other similar entities) such as a network interface, memory interface, direct connection to an interface bus, system bus, CPU, and/or the like. The peripheral devices may be external, internal and/or part of the PAFT controller. The peripheral device may include: an antenna, an audio device (e.g., line-in, line-out, microphone-in, speaker, etc.), a camera (e.g., still, video, webcam, etc.), a dongle (e.g., for copy protection, to ensure secure transactions with digital signatures, and/or the like), an external processor (for added capability; e.g., password 528), a force feedback device (e.g., a vibration motor), a network interface, a printer, a scanner, a storage device, a transceiver (e.g., cellular, GPS, etc.), a video device (e.g., goggles, a monitor, etc.), a video source, a visor, and/or the like. Peripheral devices often include various types of input devices (e.g., cameras).

It should be noted that while user input devices and peripherals may be used, the PAFT controller may be embodied as an embedded, dedicated and/or monitor-less (i.e., headless) device, wherein access would be provided through a network interface connection.

Encryption units such as, but not limited to, microcontrollers, processors 1226, interfaces 1227, and/or devices 1228 may be attached to, and/or in communication with, the PAFT controller. An MC68HC16 microcontroller manufactured by Motorola inc. The MC68HC16 microcontroller uses 16-bit multiply-and-accumulate instructions in a 16MHz configuration and requires less than one second to perform 512-bit RSA private key operations. The encryption unit supports authentication of communications from the interaction agent and allows anonymous transactions. The encryption unit may also be configured as part of the CPU. Equivalent microcontrollers and/or processors may also be used. Other commercially available specialized cryptographic processors include: broadcom's CryptoNetX and other security processors; nShield from nCipher, Luna PCI (e.g., 7100) series from SafeNet; 40MHzRoadrunner 184 by Semaphore Communications; sun's crypto Accelerator (e.g., Accelerator 6000 PCIe board, Accelerator 500 Daughtercard); a Via Nano Processor (e.g., L2100, L2200, U2400) line capable of executing 500+ MB/s cryptographic instructions; 33MHz 6868 for vlsi technology; and/or the like.

Memory device

Generally speaking, any mechanism and/or embodiment that allows a processor to perform storage and/or retrieval of information is considered memory 1229. However, memory is an alternative technology and resource, and as such, any number of memory embodiments may be used in place of or in conjunction with each other. It is to be appreciated that the PAFT controller and/or the computer system may employ various forms of memory 1229. For example, a computer system may be configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices is provided by a punched paper or punched card mechanism; of course, such an embodiment would result in a very slow operating rate. In a typical configuration, the memory 1229 will include ROM 1206, RAM 1205, and storage 1214. Storage 1214 may be any conventional computer system memory. The storage device may include a magnetic drum; (fixed and/or removable) disk drives; a magneto-optical driver; optical drives (i.e., Blueray, CD ROM/RAM/recordable (R)/Rewritable (RW), DVD R/RW, HD DVD R/RW, and the like); an array of devices (e.g., a Redundant Array of Independent Disks (RAID)); solid state memory devices (USB memory, Solid State Drives (SSDs), etc.); a storage medium readable by another processor; and/or the like. As such, computer systems typically require and utilize memory.

Component collections

Memory 1229 may contain programs and/or database components and/or data sets such as, but not limited to: operating system component 1215 (operating system); information server component 1216 (information server); user interface component 1217 (user interface); a web browser component 1218(web browser); a database 1219; a mail server component 1221; a mail client component 1222; an encryption server component 1220 (encryption server); PAFT assembly 1235; and/or the like (i.e., collectively, the set of components). These components may be stored and accessed from a storage device and/or from a storage device accessible through an interface bus. While non-procedural components, such as those in a set of components, are typically stored in local storage 1214, they may also be loaded and/or stored in memory, such as: peripheral devices, RAM, remote storage facilities over a communications network, ROM, various forms of memory and/or the like.

Operating system

The operating system component 1215 is an executable program component that facilitates operation of the PAFT controller. Generally, an operating system facilitates access to I/O, network interfaces, peripherals, storage devices, and/or the like. The operating system may be a highly fault-tolerant, scalable, and secure system, such as: apple Macintosh OS X (server); AT & T Plan 9; be OS; unix and Unix-like system distributions (e.g., UNIX by AT & T; Berkley Software Distribution (BSD) variants such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distribution such as Red Hat, Ubuntu, and/or the like); and/or the like. However, operating systems that are relatively limited and/or less secure may also be used, such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like. The operating system may communicate with other components in the set of components, including itself, and/or the like. The operating system often communicates with other program components, user interfaces, and/or the like. For example, an operating system may contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may allow interaction with communication networks, data, I/O, peripherals, program component storage, user input devices, and/or the like. The operating system may provide a communication protocol that allows the PAFT controller to communicate with other entities over the communication network 1213. Various communication protocols may be used by the PAFT controller as a subcarrier transmission mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.

Information server

Information server component 1216 is a stored program component that is executed by the CPU. The information server may be a conventional internet information server such as, but not limited to: apache by Apache software foundation, microsoft's internet information server, and/or the like. The information server may allow the program components to be executed by: such as Active Server Pages (ASPs), ActiveX, (ANSI) (Objective-) C (++), C #, and/or NET, Common Gateway Interface (CGI) scripts, dynamic (D) HyperText markup language (HTML), FLASH, Java, JavaScript, actual fetch and report language (PERL), HyperText preprocessor (PHP), pipes, Python, Wireless Application Protocol (WAP), WebObjects, and/or the like. The information server may support a secure communication protocol such as, but not limited to, File Transfer Protocol (FTP); hypertext transfer protocol (HTTP); secure hypertext transfer protocol (HTTPS), Secure Sockets Layer (SSL), messaging protocols (e.g., america online (aol) Instant Messenger (AIM), application exchange (APEX), ICQ, Internet multi-line chat (IRC), Microsoft network (MSN) Messenger services, presence and Instant messaging Protocol (PRIM), Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP), SIP for Instant messaging and presence with extensions (simple), open XML-based extensible messaging and presence protocol (XMPP) (i.e., Instant Messaging and Presence Service (IMPS) of jaber or Open Mobile Alliance (OMA)) Yahoo | Instant Messenger services, and/or the like.) after the domain name resolution system (DNS) portion of the resolution request is manipulated into a particular information server, the information server parses the request for information at the specified location on the PAFT controller based on the rest of the HTTP request. For example, a request such as http://123.124.125.126/myinformation. html can resolve the IP portion "123.124.125.126" of the request to an information server at the IP address by a DNS server; the information server may further parse the http request for "/myinformation. In addition, other information provision protocols may be used across the various ports, such as FTP communications across port 21, and/or the like. The information server may communicate with other components in the collection of components, including itself, and/or similar facilities. Most frequently, the information server communicates with the PAFT database 1219, operating system, other program components, user interface, web browser, and/or the like.

Access to the PAFT database may be achieved through several database bridging mechanisms, such as through a scripting language (e.g., CGI) as listed below, through an inter-application communication channel (e.g., CORBA, WebObjects, etc.) as listed below. Any data requests through the web browser are parsed into the appropriate syntax by the bridging mechanism according to the PAFT requirements. In one embodiment, the information server is a Web form that is accessible by a Web browser. Input to a field provided in the Web form is marked as having been entered into a particular field, and so parsed. The entered entry is then passed along with the field tag, which acts to instruct the parser to generate a query directed to the appropriate table and/or field. In one embodiment, the parser may generate a standard SQL query by instantiating a search string with appropriate connect/select commands based on tagged text input, where the resulting commands are provided as a query to the PAFT through a bridging mechanism. After generating query results from the query, the results are passed through the bridging mechanism and may be parsed for formatting and new result web pages generated through the bridging mechanism. Such a new resulting web page is then provided to the information server, which may provide it to the requesting web browser.

Likewise, an information server may contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

User interface

The computer interface is similar in some respects to the car operating interface. Automotive operator interface elements, such as a steering wheel, a shifter, and a speedometer, perform access, operation, and display of automotive resources, as well as status. Computer interactive interface elements (collectively widgets), such as checkboxes, cursors, menus, scroll bars, and windows similarly perform access, manipulation, and display of data and computer hardware and operating system resources, and states. The operation interface is generally called a user interface. Such as Aqua of Apple Macintosh operating system, OS/2 of IBM, Windows2000/2003/3.i/95/98/CE/Millenium/NT/XP/Vista/7 of Microsoft (i.e., Aero), X-Windows of Unix (which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV, and GNU Network Object Model Environment (GNOME)), web interface libraries (e.g., ActiveX, AX, (D) HTML, FLASH, Java, JavaScript, etc.), interface libraries, such as, but not limited to, Dojo, jQuery (UI), MooTools, Prototype, script. Any of which may be used) provides a reference and means to access and graphically display information to a user.

The user interface component 1217 is a stored program component that is executed by the CPU. The user interface may be a conventional graphical user interface as provided by an operating system and/or operating environment such as has been discussed. The user interface may display, execute, interact with, manipulate, and/or operate the program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility by which a user can influence, interact with, and/or operate the computer system. The user interface may communicate with other components in the collection of components, including itself, and/or similar facilities. Most frequently, the user interface communicates with an operating system, other program components, and/or the like. The user interface may contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

Web browser

The Web browser component 1218 is a stored program component that is executed by the CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. The secure Web browsing may be provided with 128bit (or greater) encryption via HTTPS, SSL, and/or the like. The web browser may allow program components to be executed through facilities such as ActiveX, AJAX, (D) HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., FireFox, Safari plug-in, and/or the like) and/or the like. web browsers and similar information access tools may be integrated into PDAs, cell phones, and/or other mobile devices. The web browser may communicate with other components in the collection of components, including itself, and/or similar facilities. Most frequently, the web browser communicates with an information server, an operating system, integrated program components (e.g., plug-ins), and/or the like; for example, it may contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses. Of course, instead of a web browser and an information server, a combined application may be developed to perform similar functions of both. The combined application will similarly obtain information from the PAFT-enabled node and provide the information to the user, user agent, and/or the like. The combined application may not be effective on systems using standard web browsers.

Mail server

The mail server component 1221 is a stored program component executed by the CPU 1203. The mail server may be a conventional internet mail server such as, but not limited to, sendmail, Microsoft Exchange, and/or the like. The mail server may allow the program components to be executed by: such as ASP, ActiveX, (ANSI) (Objective-) C (++), C #, and/or NET, CGI script, Java, JavaScript, PERL, PHP, pipe, Python, WebObjects, and/or the like. The mail server may support communication protocols such as, but not limited to: the mail server may route, forward, and process incoming and outgoing mail messages that have been sent, relayed, and/or otherwise traversed and/or to the PAFT.

Access to PAFT mail may be achieved through several APIs provided by a single web server component and/or operating system.

Likewise, a mail server may contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, information, and/or responses.

Mail client

Mail client component 1222 is a stored program component that is executed by CPU 1203. The Mail client may be a conventional Mail viewing application such as Apple Mail, Microsoft Enterprise, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. The mail client may support several transport protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. The mail client may communicate with other components in the collection of components, including itself, and/or similar facilities. Most frequently, the mail client communicates with a mail server, operating system, other mail clients, and/or the like; for example, it can contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, information, and/or responses. Generally, mail clients provide a facility for composing and transmitting electronic mail messages.

Encryption server

The cryptographic server component 1220 is a stored program component that is executed by the CPU 1203, cryptographic processor 1226, cryptographic processor interface 1227, cryptographic processor device 1228, and/or the like. The cryptographic processor interface will allow for acceleration of encryption and/or decryption requests made by the encryption component; however, the cryptographic component may alternatively run on a conventional CPU. The encryption component is used to encrypt and/or decrypt provided data. The encryption component may be used for symmetric and asymmetric (e.g., well-protected (PGP)) encryption and/or decryption. The encryption component may use the following encryption techniques, such as, but not limited to: digital certificates (e.g., x.509 authentication framework), digital signatures, double signatures, envelopes, cryptographic access protection, public key management, and/or the like. The encryption component will implement many (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), elliptic curve Encryption (ECC), International Data Encryption Algorithm (IDEA), message digest 5(MD5, which is a one-way hash function), cipher, Rivest cipher (RC5), Rijndael, RSA (which is an internet encryption and authentication system using algorithms developed by Ron Rivest, AdiShamir, and Leonard Adleman in 1977), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), secure hypertext transfer protocol (HTTPS), and/or the like. By using such an encryption security protocol, the PAFT may encrypt all incoming and/or outgoing communications and may act as a node within a Virtual Private Network (VPN) with a wider communications network. The encryption component performs a process of "secure authorization" such that access to the resource is inhibited by the security protocol, wherein the encryption component performs authorized access to the secured resource. In addition, the encryption component may provide a unique identifier for the content, for example, using an MD5 hash to obtain a unique signature for the digital audio file. The cryptographic component may communicate with other components in the set of components, including itself, and/or similar facilities. The encryption component supports an encryption scheme for secure transmission of information across a communication network to enable the PAFT component to engage in secure transactions (if desired). The encryption component performs secure access to resources on the PAFT and performs access to secure resources on the remote system; that is, it may act as a client and/or server for the secure resource. Most frequently, the encryption component communicates with an information server, operating system, other program components, and/or the like. The cryptographic components may contain, communicate, generate, obtain, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

PAFT database

The PAFT database component 1219 may be embodied in a database and the data stored therein. The database is a stored program component executed by the CPU; the stored program component part configures the CPU to process the stored data. The database may be a conventional, fault-tolerant, relational, scalable, secure database such as Oracle or Sybase. Relational databases are extensions of flat files. The relational database comprises a series of related tables. The tables are interconnected by key fields. The use of key fields allows tables to be combined by indexing against the key fields; that is, the key field acts as a dimension pivot point for combining information from various tables. Relationships generally identify the links maintained between tables by matching primary keys. The primary key represents a field that uniquely identifies a row of a table in a relational database. Rather, they uniquely identify rows of the table on the "one" side of a one-to-many relationship.

Alternatively, the PAFT database may be implemented using various standard data-structures, such as arrays, hashes, (linked) lists, structures, structured text files (e.g., XML), tables, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative embodiment, object-oriented databases such as Frontier, ObjectStore, Poet, Zope, and/or the like may be used. An object database may include several sets of objects grouped and/or linked together by common attributes; they may be associated with other sets of objects by some common attribute. An object-oriented database behaves like a relational database, with the exception that objects are not just pieces of data, but may have other types of functionality encapsulated within a given object. If the PAFT database is implemented as a data structure, the use of the PAFT database 1219 may be integrated into another component such as the PAFT component 1235. Also, databases may be implemented as a mixture of data structures, objects, and relational structures. The collection of components can be consolidated and/or distributed in myriad schemes by standard data processing techniques. Portions of the database, e.g., tables, may be exported and/or imported, such as scattered and/or integrated.

In one embodiment, the database component 1219 includes a plurality of tables 1219 a-k. User table 1219a may include the following fields, such as, but not limited to: user _ id, application _ id, firstname, lastname, address _ line1, address _ line2, dob, ssn, credit _ check _ flag, zip, city, state, account _ params _ list, account _ mode, account _ type, account _ exception, referenced _ bank _ name, referenced _ bridge _ name, referenced _ report, and/or the like. The User table may support and/or track multiple entity accounts on the PAFT. The Clients table 1219b may include the following fields such as, but not limited to: client _ ID, client _ type, client _ MAC, client _ IP, presentation _ format, pixel _ count, resolution, screen _ size, audio _ fidelity, hardware _ settings _ list, software _ compatibility _ list, instruction _ apps _ list, and/or the like. The invocations table 1219c may include the following fields such as, but not limited to: request _ id, timestamp, transfer _ id, client _ IP, transfer _ details _ list, transfer _ type, first _ name, last _ name, contact _ type, contact _ info, alt _ contact _ type, alt _ contact _ info, client _ type, num _ info _ attributes, account _ params _ list, same _ bank _ flag, same _ bridge _ flag, persistent _ link _ flag, transfer _ param _ list _ flag, on _ schedule _ flag, time _ one _ flag, estimate _ transit _ flag, input _ transfer _ flag, collection _ information, transfer _ details _ list, transfer _ type _ IP, and the like. The Forms table 1219d may include the following fields such as, but not limited to: an association _ template _ list, association _ type, association _ data, and/or the like. The Clearance table 1219e may include the following fields such as, but not limited to: application _ firstname, application _ lastname, application _ address _ line1, application _ address _ line2, consumer _ burst _ data _ list, consumer _ burst _ data, application _ clear _ flag, credit _ limit, credit _ score, account _ balance, delinquency _ flag, quality _ flags, and so forth. Links table 1219f may include the following fields, such as, but not limited to: timing, link _ ID, bidirectional _ flag, transferor _ ID, transferor _ account _ num, transferor _ bank, transferor _ branch, transferor _ ABA, transferee _ ID, transferee _ account _ num, transferee _ bank, transferee _ branch, transferee _ ABA, and/or the like. The Schedules table 1219g may include the following fields such as, but not limited to: time, transfer _ ID, link _ ID, num _ transfers transfer _ date, transfer _ frequency, transfer _ interval, notify _ transfers _ settings, and the like. The Bank Accounts table 1219h may include the following fields such as, but not limited to: account _ id, account _ firstname, account _ lastname, account resolver _ type, account _ type and contact _ type; contact _ info, open _ balance, current _ balance, and/or the like. The Transfers table 1219i may include the following fields such as, but not limited to: transfer _ ID, link _ ID, transfer _ amount, timestamp, notify _ transfers _ flags, and/or the like. The App Modules table 1219j may include the following fields such as, but not limited to: app _ ID, app _ name, app _ ype, OS _ compatibilities _ list, version, timestamp, devilpid, and/or the like. The Market Data table 1219k may include the following fields such as, but not limited to: mark _ data _ feed _ ID, asset _ symbol, asset _ name, spot _ price, bid _ price, ask _ price, and/or the like; in one embodiment, the marktdata table is populated by market data feeds (e.g., Bloomberg's pharmanip, Dun & Bradstreet, road agency's Tib, Triarch, etc.), e.g., by microsoft's ActiveTemplate Library and demisting Object Technology's real-time toolkit rt.

In one embodiment, the PAFT database may interact with other database systems. For example, using a distributed database system, queries, and data access by searching the PAFT component may treat the combination of the PAFT database, the integrated data security layer database as a single database entity.

In one embodiment, the user program may contain various user interface primitives that may be intended to update the PAFT. Also, various accounts may require custom database tables, depending on the environment and the type of client that the PAFT may need to service. It should be noted that any unique field may be designated as a key field. In an alternative embodiment, the tables have been distributed to their own databases and their respective database controllers (i.e., a single database controller for each of the tables above). The database may further be distributed among multiple computer systems and/or storage devices using standard data processing techniques. Similarly, the configuration of the decentralized database controller may be changed by merging and/or distributing the various database components 1219 a-k. The PAFT may be configured to track various settings, inputs, and parameters through the database controller.

The PAFT database may be in communication with other components in the set of components, including itself, and/or similar facilities. Most frequently, the PAFT database communicates with PAFT components, other program components, and/or the like. The database may contain, maintain, and provide information about other nodes and data.

PAFT

The PAFT component 1235 is a stored program component that is executed by the CPU. In one embodiment, the PAFT assembly includes any and/or all combinations of aspects of a PAFT discussed in previous figures. As such, PAFT affects access, acquisition, and provision of information, services, transactions, and/or the like across various communication networks.

The PAFT component may convert the prepaid account invitation request into a predetermined prepaid account transaction, and/or the like, and use of a PAFT via the PAFT component. In one embodiment, PAFT component 1235 takes input (e.g., invitation request input 211, invitation template 216, invitation acceptance input 411, invitation type 416, prepaid account application form 419, application form input 423, applicant screening failure report 428a, applicant screening success report 428b, payment voucher input 611a, accounts receivable request input 611b, transfer schedule 612c, transfer link data 615, user profile data 617, and/or the like) and the like and converts the input to output (e.g., invitation data 218, custom account invitation 219, Tr-FTT component 1243, Te-FTT component 1244, S-FTT component 5, PA-FTP component 1246, and/or the like) via various components (e.g., PAAI component 1241, PAR component 1242, Tr-FTT component 1246, Te-FTT component 1246, and/or the like) and converts the input to output (e.g., prepaid account request input 219, custom invitation message 222, prepaid account application form 420, application rejection notification 429a, Prepaid account opening request message 430b, account issuance message 436, user profile 438, prepaid account link data 439, prepaid account funds transfer calendar 440, transaction data 622, transaction notifications 623a-b), and/or the like).

PAFT components that allow access to information between nodes can be developed using the following standard development tools and languages, such as, but not limited to: apache components, assembly language, ActiveX, binary executable, (ANSI) (Objective-) C (+ +), C #, and/or NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, process and object-oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, Web application server extensions, Web development environments, and libraries (e.g., Microsoft's ActiveX; Adobe AIR, FLEX & FLASH; AJAX; (D) HTML; Dojo, Java; JavaScript; JQuery (UI), MooTools; Prototype; ptaco. us; Simple Object Access Protocol (SOAP); SWFObject; Yahoo!and/or the like), WebObjects, and/or the like. In one embodiment, the PAFT server uses an encryption server to encrypt and decrypt communications. The PAFT component may communicate with other components in the set of components, including itself, and/or similar facilities. Most frequently, the PAFT component communicates with a PAFT database, an operating system, other program components, and/or the like. The PAFT may contain, communicate, generate, retrieve, and/or provide program components, systems, users, and/or data communications, requests, and/or responses.

Distributed PAFT

The structure and/or operation of any of the PAFT node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, a collection of components can be combined in any number of ways to facilitate deployment and/or development. To this end, the components may be integrated into a common code base or may be dynamically loaded in an integrated manner in a facility where the components are loaded on demand.

The collection of components can be consolidated and/or distributed in myriad schemes by standard data processing and/or development techniques. Multiple instances of any of the program components in the collection of program components can be instantiated on a single node, and/or across many nodes, through load balancing and/or data processing techniques to improve performance. Further, multiple controllers and/or storage devices may also be spanned; e.g., a database, to distribute a single instance. All program component instances and controllers working in tandem can achieve this through standard data processing communication techniques.

The configuration of the PAFT controller will depend on the context of the system deployment. Factors such as, but not limited to, budget, capacity, location, and/or use of underlying hardware resources may affect deployment requirements and configuration. Data may be transferred, obtained, and/or provided regardless of whether the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between consolidated and distributed configurations. An instance of a component that is merged from a collection of program components into a common code base may pass, obtain, and/or provide data. This may be done through data processing communication techniques within the application, such as, but not limited to: data references (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable communication, and/or the like.

If the component assembly components are separate, apart, and/or external from each other, then communicating with and/or to other components, obtaining, and/or providing data can be accomplished through data processing communication techniques between applications, such as, but not limited to: application Programming Interface (API) information transfer; (distributed) component object model ((D) COM), (distributed) object linking and embedding ((D) OLE) and/or the like), Common Object Request Broker Architecture (CORBA), Jini local and remote application programming interfaces, JavaScript object notation (JSON), Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between separate components for inter-application communication or within the memory space of a single component for intra-application communication may be facilitated by creating and parsing grammars. The grammar can be developed through the use of development tools such as lex, yacc, XML, and/or the like, which have grammar generation and parsing capabilities that can in turn form the basis for communication messages within and between components.

For example, the grammar may be configured to recognize tokens for HTTP post commands, such as:

w3c-post http://... Value1

where Value1 is identified as a parameter because "http://" is part of the syntax of the grammar and is immediately followed by a part of the post Value. Similarly, with such syntax, the variable "Value 1" can be inserted into the "http://" post command and then sent. The syntactic syntax itself may be presented as structured data that is interpreted and/or otherwise used to generate a parsing mechanism (e.g., a syntactic description syntax description text file processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it may itself process and/or parse structured data, such as, but not limited to: text described by characters (e.g., tabs), HTML, structured text streams, XML, and/or similar structured data. In another embodiment, the inter-application data processing protocol itself may have an integrated and/or readily available parser (e.g., JSON, SOAP, and/or the like) that may be used to parse (e.g., communicate) data. In addition, the parsing syntax may be used for other than message parsing, but may also be used for parsing: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend on the context, environment, and requirements of the system deployment.

For example, in some implementations, the PAFT controller may execute a PHP script that implements a secure socket layer ("SSL") socket server through the information server, which listens for incoming communications on the server port to which the client may send data (e.g., data encoded in JSON format). After identifying the incoming communication, the PHP script may read the incoming message from the client device, parse the received JSON-encoded text data to extract information from the JSON-encoded text data to PHP script variables, and store the data (e.g., client identification information, etc.) and/or the extracted information in a relational database accessible using structured query language ("SQL"). The following provides an example list written substantially in the form of PHP/SQL commands to accept JSON encoded input data from a client device over an SSL connection, parse the data to extract variables, and store the data in a database:

also, the following resources may be used to provide information about the SOAP parser implementation:

http://www.xav.com/perl/site/lib/SOAP/Parser.html

http://publib.boulder.ibm.com/infocenter/tivihelp/v2rl/index.jsptopic＝/com.ibm

.IBMDI.doc/referenceguide295.htm

and other resolver implementations:

.IBMDI.doc/referenceguide259.htm

they are expressly incorporated herein by reference.

To address various problems and improve technology, the entirety of this application (including covers, headings, sub-headings, technical fields, background, summary, brief description of the drawings, detailed description, claims, abstract, soil, appendix and/or others) of prepaid account funds transfer apparatus, methods and systems shows by way of illustration embodiments in which the claimed invention may be practiced. The advantages and features of the present application are merely representative examples of embodiments and are not intended to be exhaustive and/or exclusive. They are merely useful in understanding and teaching the principles of the claims. It should be understood that they are not intended to be a representation of all claimed inventions. As such, certain aspects of the present disclosure are not discussed herein. Alternate embodiments may not be presented for a particular portion of the invention or may be further undescribed for a portion may not be considered to be disclaimer of those alternate embodiments. It is to be understood that many of those undescribed embodiments incorporate the same principles of the invention, and that other embodiments are equivalent. As such, it is to be understood that other embodiments may be utilized and that functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope of the invention. As such, all examples and/or embodiments are to be considered non-limiting throughout this disclosure. Likewise, no inference should be made regarding those embodiments discussed herein relative to those not discussed herein, and as such, it is intended to reduce space and repetition. For example, it is to be understood that the logic and/or topology of any combination of any program components (collection of components), other components, and/or any set of existing features, as depicted in the figures and/or throughout the specification is not limited to a fixed order and/or arrangement of operations, but rather any disclosed order is exemplary and that the disclosure contemplates all equivalent practices regardless of order. Further, it is to be appreciated that such features are not limited to being performed serially, and that any number of threads, processes, services, servers, and/or the like may be performed asynchronously, concurrently, in parallel, concurrently, synchronously, and/or the like is contemplated by the present disclosure. As such, some of these features may be mutually inconsistent and may not be present in a single embodiment. Similarly, certain features are applicable to one aspect of the invention and not to others. In addition, this disclosure also includes other inventions not presently claimed. Applicants reserve all rights in those inventions not presently claimed, including claims, supplemental applications, continuing applications, portions of continuing applications, and/or the like. As such, it should be understood that advantages, embodiments, examples, functionality, features, logic, organization, structure, topology, and/or other aspects of the disclosure are not to be considered as limiting of the disclosure as defined by the claims or as equivalents to the claims. It will be appreciated that embodiments of the PAFT may be implemented that allow for great flexibility and customization depending on the specific needs and/or characteristics of individual and/or enterprise users of the PAFT, database configuration, relational models, data types, data transport and/or network frameworks, syntactic structures, and/or the like. For example, aspects of a PAFT may be applicable to credit cards, Deposit Slips (CDs), cash market accounts, stock purchases, trading systems, mortgages, insurance policies, and/or the like. In general, it is contemplated that aspects of the PAFT may be applicable to any mode of transferring wealth from one entity to another. Although embodiments and discussion of PAFT relate to account-based transactions, it is understood that embodiments described herein may be readily configured and/or customized for various other and/or implementations.

Claims

1. A prepaid account funds transfer processor-implemented method comprising:

obtaining a prepaid account invitation request from a transferor user holding a transferor prepaid account specifying a transferee user and a prepaid funds transfer amount;

generating a customized prepaid account invitation for the transferee user based on the prepaid account invitation request;

providing a customized prepaid account invitation for the transferee user;

obtaining an invitation acceptance from the transferee user in response to the provided customized prepaid account invitation;

creating, by a processor, an transferee prepaid account for the transferee user; and is

After the transferee prepaid account is created, a prepaid funds transfer amount for the funds specified in the prepaid account invitation request is transferred from the transferor prepaid account to the created transferee prepaid account.

2. The method of claim 1, further comprising:

providing a prepaid account application to the transferee user; and is

Obtaining the filled prepaid account application;

wherein the transferee prepaid account is created based on the filled prepaid account application.

3. The method of claim 2, wherein the creation of the transferee prepaid account is contingent upon the transferee user passing a screening test based on the filled prepaid account application.

4. The method of claim 1, wherein the transferee prepaid account is created locally.

5. The method of claim 1, wherein the customized prepaid account invitation is customized based on attributes of the transferee client device of the transferee user.

6. The method of claim 1, further comprising:

generating a prepaid account funds transfer schedule for a funds transfer between the transferor prepaid account and the transferee prepaid account; and is

A predetermined transfer amount is transferred from the transferor prepaid account to the created transferee prepaid account based on the generated prepaid account funds transfer schedule.

7. The method according to claim 6, wherein the at least one predetermined funds transfer included in the prepaid account funds transfer schedule specifies transferring funds from the transferee prepaid account to the transferor prepaid account.

8. A prepaid account funds transfer system comprising:

a memory; and

a processor disposed in communication with the memory and configured to issue processing instructions stored in the memory that perform the following operations:

providing a customized prepaid account invitation for the transferee user;

creating an transferee prepaid account for the transferee user; and is

In response to creating the transferee prepaid account, a prepaid funds transfer amount for the funds specified in the prepaid account invitation request is transferred from the transferor prepaid account to the created transferee prepaid account.

9. The system of claim 8, wherein the memory further stores processing instructions to:

providing a prepaid account application form for the assignee user; and is

Acquiring the filled prepaid account application form;

wherein the transferee prepaid account is created based on the filled prepaid account application form.

10. The system of claim 9, wherein the creation of the transferee prepaid account is contingent upon the transferee user passing a screening test based on the filled prepaid account application.

11. The system of claim 8, wherein the transferee prepaid account is created locally.

12. The system of claim 8, wherein the customized prepaid account invitation is customized based on attributes of the transferee client device of the transferee user.

13. The system of claim 8, wherein the memory further stores processing instructions to:

A predetermined transfer amount is transferred from the transferor prepaid account to the created transferee prepaid account according to the generated prepaid account funds transfer schedule.

14. The system according to claim 13, wherein the at least one predetermined funds transfer included in the prepaid account funds transfer schedule specifies transferring funds from the transferee prepaid account to the transferor prepaid account.

15. A processor-readable tangible medium storing processor-issuable prepaid account funds transfer instructions, the processor-issuable prepaid account funds transfer instructions to:

providing a customized prepaid account invitation for the transferee user;

creating an transferee prepaid account for the transferee user; and is

16. The medium of claim 15 further storing processing instructions to:

providing a prepaid account application to the transferee user; and is

Obtaining the filled prepaid account application;

17. The medium of claim 16, wherein creating the transferee prepaid account is contingent upon the transferee user passing a screening test based on the filled prepaid account application.

18. The medium of claim 15, wherein the transferee prepaid account is created locally.

19. The medium of claim 15, wherein the customized prepaid account invitation is customized based on attributes of the transferee client device of the transferee user.

20. The medium of claim 15 further storing processing instructions to:

21. The medium of claim 20 wherein the at least one predetermined funds transfer included in the prepaid account funds transfer schedule specifies transferring funds from the transferee prepaid account to the transferor prepaid account.