TECHNICAL FIELD AND BACKGROUND

The present disclosure concerns a data system, a method, and a computer storage medium.

In households and businesses money is spend frequently unexpectedly, unnecessary, mistakes made in paying beneficiaries resulting in budget excesses and bank overdrafts.

Further, trades are frequently accepted by beneficiaries unknown and unverified by the guarantor. In many cases resulting in monies used in manners not intended by a guarantor.

Existing technical implementations of trade methods in use do not provide sufficient techniques and methods that can be adapted to overcome the above-identified problems. Methods currently applied to structure and process the data are not able in assisting in the resolution of the earlier defined problem. Impact on existing data structures and data processing capabilities is related to performance degradation, increased complexity in maintaining the software and increased security vulnerability.

An electronic payment or trade system manages electronic transactions between a payer or a guarantor, e.g. customer, and a beneficiary, e.g. merchant. In one example, a payer can perform a monetary transaction by means of a payment or trade card that is accepted by the beneficiary. Typically, a payment card is electronically linked to a bank account associated with the payer. The association is e.g. stored in an account database with tables of the payment system wherein the payer, or the card used by the payer, is identified by his account data. There are a number of payment cards in use such as credit cards and debit cards. One feature of a debit card (also known as a bank card or check card) is that when a cardholder makes a purchase, funds are withdrawn directly from the bank account, with a pool of funds, of the cardholder and transferred to the beneficiary.

In one example, a payer initiates a transaction, e.g. purchase, by providing the payment card into a payment terminal of the beneficiary and entering a personal identification number (PIN). The payment system receives the order for the transaction including information indicating the payer, the intended beneficiary, and an amount to be transferred. The prepared transaction is then processed and the account database accessed to retrieve the respective account data of the payer account. When the specified amount of money is successfully transferred from the payer to the beneficiary a status signal may be sent to the payment terminal to indicate the successful transfer or a problem with the transfer e.g. as a result of insufficient funds on the payer account.

Unfortunately, due to the lack of a physical money transfer, many users of electronic payment systems experience that the threshold for spending money can be lowered and users realize afterwards that more money has been spent than was planned. Accordingly, there is a need for an improved payment system that allows better control over the money spending pattern of its users.

SUMMARY

The solution described in the present disclosure is based on capturing and storing amorphous data that will allow to arrange the data according to pre-set criteria. This allows the guarantor to add intentions to transactions on which basis they can be executed. Through the intentions the guarantor is able to create, and maintain the conditions in which it can fulfill economic, social and other requirements. The transactions can be stored including the added criteria. The intentions are configured through the addition of specific criteria and patterns (connections) that can be verified later. After the stored data has been added with the criteria new transaction strings (connections) can be computed. Allowing for each transaction to connect to any other transaction based on matching or common criteria. The transaction with all associated data can be connected to related transactions and accounts, the relationship therefore constitutes a credit and debit transaction. As an example, the by the guarantor prepared (debit) transaction can be used as a credit transaction by the beneficiary. As such the balance on an account is the sum of all to that account connected transactions. The solution is designed in such a manner that it allows for real-time online peer to peer transactions making clearing and settlement processes superfluous. The technical solution allows for the capture, processing and storage of amorphous data-sets.

A first aspect of the present disclosure provides a system for managing electronic transactions between a payer and a beneficiary, the payment system comprising an account database arranged for storing a multiple number of data sets and for relating a particular set of data sets to each other in an amorphous manner for defining a pre-set transaction right wherein the related set of data sets form criteria indicating at least an allowed beneficiary; the account database further arranged for defining a payer account by linking the defined pre-set transaction right to account data of a payer, and for periodically updating the data sets in the account database; a transaction receiver arranged to receive an order for a prepared transaction including information indicating at least the payer, the intended beneficiary, and an amount to be transferred; and a transfer processor arranged to process the prepared transaction from the transaction receiver; and to access the account database to retrieve the respective account data of the payer account; the transfer processor further arranged for comparing the information indicating the intended beneficiary included in the prepared transaction with the allowed beneficiaries indicated by the transaction right; and for effectuating the actual transaction only if, in the said comparing, the information indicating the intended beneficiary of the prepared transaction matches with the allowed beneficiaries of the transaction right. transfer processor

In this context it is noted that the user can also be a guarantor of the user. Further, the transaction right of a payer account may not only include payer information but also other information such as information about guarantor representatives.

Data sets include information about a variety of subjects, e.g. payer information, guarantor information, beneficiary information, product information, service information, budget information, time-related information, etc. Such information can be used to perform a verification whether a transaction request meets requirements defined in the data sets.

Advantageously, data sets are stored in an amorphous manner and pre-set transaction rights are formed by relating or connecting respective data sets. Then, information defining the pre-set transaction rights remains easily available, e.g. for the purpose of verifying an intended transaction.

Further, by linking at least one pre-set transaction right to payer account data, also pre-set transaction rights information remains easily available in relation to the payer account data. Preferably, all pre-set transaction rights that have been defined for a particular payer account are linked to said payer account data, thereby providing a complete overview of the pre-set transaction rights associated with said payer account.

Preferably, the data sets of the pre-set transaction right are permanently related to each other in an amorphous manner. Then, the information of the associated data sets remains easily available for future processing. In order to improve the reliability of the system, the account database can be arranged for monitoring modifications in data set relationships and/or linked pre-set transaction rights (TR).

By providing a payer account that only allows transfer of money according to a pre-set transaction right, the spending of money outside the parameters of the transaction right can be prevented. The account can be an individual transaction, such as a vertex, the first prepared by a guarantor, or a group of connected transactions. As such the money in the account is preferably earmarked only to be spend on pre-pared orders according to an eclectic selection process. By defining one or more allowed beneficiaries and/or pre-defined orders for products and services in the transaction right and only allowing the transfer of funds to these pre-selected beneficiaries, it can be prevented that money is spent elsewhere e.g. on unnecessary or forbidden purchases. In this way a better control over the money spending pattern of the user is achieved. It will be appreciated that information on the intended recipient is typically already sent during conventional electronic payment or trade. Therefore the presently disclosed data system may be easily integrated in current infrastructure.

In one embodiment, a guarantor of the payer account is authorized to set the transaction right for a guarantor representative who is then authorized to act as the payer for the payer account. By not allowing the guarantor representative to change the transaction right, the guarantor has an improved control over the spending of the guarantor representative. For example, a parent may act as guarantor for a payer account and create a transaction right for a child to act as guarantor representative, i.e.

authorized payer. The child can thus spend money from the account but only according to the pre-set transaction rights. In this way the parent maintains control over the spending of the child. It will be appreciated that the parent does not have to create a separately funded account for the child and any money not spent by the child is automatically retained by the parent.

In one embodiment, the account data may indicate multiple transaction rights of payers that are authorized for the payer account, e.g. by shared or separate transaction rights. By having multiple authorized payers in a single account and checking transaction rights for the said payers, control can be exercised over the spending pattern of a group of persons. For example, an employer may create an account with multiple transaction rights for his employees. The transaction rights can be shared between the employees or separate for each employee. Also combinations are possible, e.g. a total budget can be set for all employees, while the allowed beneficiaries can be set differently for different employees.

In one embodiment, the allowed beneficiary of the transaction right is associated with a plurality of beneficiary representatives that can receive transactions from the payer. For example, the beneficiary

representatives can be authorized by the beneficiary to receive transactions on behalf of the beneficiary. The beneficiary representatives can e.g. be part of a larger organization. This way the payer can have more choice of the beneficiary representatives, while a degree of control is maintained over the expenditure by the class of beneficiary representatives, e.g. all belonging to a particular type of store.

To provide better control over the money spending pattern of the user, the transaction right can set multiple transaction criteria of allowed transactions to be compared with transaction parameters included in the prepared transaction. By setting a maximum amount that is allowed to be transferred by the payer to the beneficiary, a budget for the specific beneficiaries can be controlled. By providing a maximum cumulative amount and a time period over which this amount can be transferred from the payer to the beneficiary, the budget can be controlled over time, e.g. providing a monthly budget. It will be appreciated that the combination of budgeting and allowed beneficiaries provides a synergetic control over what is spent where. When a time period is also specified, a synergetic control is achieved over what is spent where and when.

In one embodiment, the transaction right indicates a blocked amount that is available for transfer only by a designated payer in the transaction right. By blocking part of the payer account and reserving this for the designated payer, the payer is guaranteed to be able to spend the said amount. This can be particularly useful in a shared account wherein multiple payers are authorized to withdraw funds.

In one embodiment, the transaction right defines an expiration date after which date the transaction right can no longer be used. By setting an expiration date, a guarantor can control that the transaction right is not used after the expiration date. Advantageously, the expiration date can be combined with an irrevocable transaction right, i.e. wherein the transaction right can not be altered until the expiration date. In this way a payer and/or beneficiary can be guaranteed that the transaction right will exist until the expiration date. Furthermore, this can be combined with blocking an amount that is available for transfer only by a designated payer in the transaction right. In this way the payer and/or beneficiary can be

guaranteed that the said blocked amount will be available for transfer. By setting the expiration date, the amount will not be blocked indefinitely.

In one embodiment, a user device sends a transaction code to uniquely identify and/or specify a prepared transaction. The transaction code can provide an additional security for the transaction. In a further embodiment, the system transmits a status message to the user device including information whether the actual transfer was effectuated. The user device can include a transaction device of the payer and/or the beneficiary. By receiving transaction codes from the user devices to the payment system, each party can identify himself to the system for negotiating a prepared transfer. By sending the status messages from the payment system to the user devices, the involved parties can be informed of the status of the transfer.

In one embodiment, a transaction code is received from a handheld device and uniquely identifies the said handheld device. By associating a uniquely identified handheld device with a payer in a transaction right, the payer is provided with a unique means of identification for a transaction. In this way, the handheld device can replace a conventional bank card. When the handheld device e.g. comprises a mobile telephone or other network compatible device, the device may autonomously communicate with the payment system. Advantageously, if the handheld device is lost, e.g. stolen, it can only be operated within the parameters of the associated transaction right.

In one embodiment, the transaction right defines one or more allowed locations where transfer can occur. Advantageously, many handheld devices such as telephones are equipped to determine their location, e.g. by means of GPS. The system may thus receive a location signal and determine whether the transfer can occur based on the location signal. It will be appreciated that if a trusted device is detected by the system, such as a handheld device associated with the payer, an additional measure of security is provided that the location signal can indeed be trusted. A second aspect of the present disclosure provides a method for managing an electronic transaction between a payer and a beneficiary, the method comprising the steps of transfer processorproviding an account database storing a multiple number of data sets; relating a particular set of data sets to each other in an amorphous manner for defining a pre-set transaction right wherein the related set of data sets form criteria

indicating at least an allowed beneficiary; defining a payer account by linking the defined pre-set transaction right to account data of a payer; periodically updating the data sets in the account database; providing a transaction receiver receiving an order for a prepared transaction including information indicating at least the payer, the intended beneficiary, and an amount to be transferred; and providing a transfer processor processing the prepared transaction from the transaction receiver; accessing the account database to retrieve the respective account data of the payer account; the transfer processor further comparing the information indicating the intended beneficiary included in the prepared transaction with the allowed beneficiaries indicated by the transaction right; and the transfer processor effectuating an actual transaction only if, in the said comparing, the information indicating the intended beneficiary of the prepared transaction matches with at least the allowed beneficiaries of the transaction right.

The method can be advantageously implemented e.g. on the system according to the first aspect. Of course it will be appreciated that any of the embodiments of the payment system described herein can be rephrased according to a corresponding method by identifying the operational steps that the hardware elements and/or programming is arranged to achieve.

A third aspect of the present disclosure provides a non-transient computer storage medium encoded with a computer program, the program comprising instructions that if executed by one or more computers cause the one or more computers to perform the method as defined above.

The program instructions comprised on the storage medium may e.g. be executed on one or more computers that are optionally distributed and/or simultaneously part of a system according to the first aspect e.g. to perform a method according to the second aspect. Advantageously, the amorphous data can be stored in a specific way. During processing data-sets are compared, while additions, changes and deletions are made. Preferably, relationships between the datasets are ir-reversable or permanent, thereby contributing in creating and allowing fixation of earmarked transaction rights. The hence created transaction right can thus be defined as a set of data-sets of which the relationships between them are fixated. A particular data set can be denoted as a Vertex and the fixated relationship as an Edge. In a process of building the database, amorphous data is captured or collected and converted into Vertices and new Vertices when new (for the first-time) data-sets are captured. When a Vertex is created it will be compared against a pre-pared transaction right for further processing. Each Vertex and Edge will be assigned a Vertex ID (Vid) or Edge ID (Eid) respectively, the id's will be unique and once assigned preferably ir-reversable. Each Vertex and its Edges will be stored as a group, as such creating a pre-set transaction right that is preferably permanently connected. If and when a search for a transaction right is performed a single Vertex of a transaction right can therefore identify the transaction right as a whole. The Edge between two or more transaction rights implements the transaction right and defines a string of data sets.

BRIEF DESCRIPTION OF DRAWINGS

These and other features, aspects, and advantages of the apparatus, systems and methods of the present disclosure will become better understood from the following description, appended claims, and accompanying drawing wherein:

FIG 1 schematically illustrates an electronic payment system, method, and computer program;

FIG 2 schematically illustrates another embodiment of a payment system and user device interacting therewith;

FIG 3 shows a flowchart of an embodiment of a method according to the invention;

FIG 4 schematically illustrates a payer account; and

FIG 5 shows a further flowchart of an embodiment of a method according to the invention.

DESCRIPTION OF EMBODIMENTS

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly

understood by one of ordinary skill in the art to which this invention belongs as read in the context of the description and drawings. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein. In some instances, detailed descriptions of well-known devices and methods may be omitted so as not to obscure the description of the present systems and methods. Terminology used for describing particular embodiments is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "and/or" includes any and all combinations of one or more of the associated listed items. It will be understood that the terms "comprises" and/or "comprising" specify the presence of stated features but do not preclude the presence or addition of one or more other features. It will be further understood that when a particular step of a method is referred to as subsequent to another step, it can directly follow said other step or one or more intermediate steps may be carried out before carrying out the particular step, unless specified

otherwise. Likewise it will be understood that when a connection between structures or components is described, this connection may be established directly or through intermediate structures or components unless specified otherwise. Depending on the availability of networks and network

components, connections can be real-time or delayed, on-line or off-line. All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the present specification, including definitions, will control.

Data sets can be stored in an amorphous manner e.g. using graph theory. Then, data sets are represented by Vertices while relations are represented by Edges. A unique number can be allocated to each Vertex. As an example, the number is composed using so-called spanning trees being subgraphs.

Platform - In one embodiment, the communications of the payment system are distributed by means of telecommunication computer system records over IP on public or private telecommunication networks between different terminals connected to these networks. The networks could be fixed, wireless, and terrestrial. The terminals could be handheld, PC or any other computer device and may contain digital reading devices. The terminals may be connected to print devices. The transactions can be stored on any electronic device that can contain digital information.

Transactions can be presented to terminals by means of digitally stored data and by means of a unique transaction number and a barcode, QR code or RFID code. Transaction data can be created, read, changed, added and deleted. Transactions may be accompanied by an audit trail. The

transactions can be re stored on a central computer device and can be copied to peripheral devices.

Transaction application - Preferably, the implementation can be as follows; The transactions preferably cannot be copied/repeated without the approval of an authorized entity. The transaction(s) can be aggregated. The segregation of duties is defined within the different roles appointed to different entities. Transactions can be actively exercised by the different roles. Transactions can only be exercised if the transaction criteria are met. Between the different roles there are preferably no conflicting and duplicate transaction criteria. Each Transaction can be assigned a unique

identification number. Transactions can be protected and registered stored in a safe and secure central database . Copies of transactions can be stored decentralized by those entities that have performed a role in the transaction process. The stored transaction will be available for on-line reports.

Entity - An entity can be a known- person, company, organization, government etc. Entities are governed by one or more persons. Every entity has an Entity ID. Entities are either anonymous, or known. Entities are considered anonymous until thorough identification has taken place.

Entities can have a name, address, bank accounts, credit cards, phone number, e-mail address, etc. associated with it. A person acts on behalf of an entity.

Roles - An entity can have the following roles:

- Guarantor: An entity, which creates and guarantees the

transaction right and assigns a set of criteria to the transaction right for a Guarantor Representative. Only known entities can be Guarantors.

- Guarantor Representative (GR): An entity who makes use of the transaction right of the Guarantor and uses it on a prepared transaction for a specific Beneficiary, bounded by the criteria setup by the Guarantor. In one embodiment, a Guarantor can act as a Guarantor Representative.

- Beneficiary: An entity which receives the transaction. A

Beneficiary can create a Representation Right for its Beneficiary

Representatives. Only known entities can be Beneficiaries.

- Beneficiary Representative (BR): An entity who is allowed to engage in a transaction in behalf of a Beneficiary. Beneficiary

Representative is bounded by the criteria described in the Representation Right of the Beneficiary. In one embodiment, a Beneficiary can act as a Beneficiary Representative.

Identification - Identification of a person to the system can be done on several levels of security.

- High: unique user ID and pin code or a unique username and password from a specific device known by the System to be controlled by the user and checked by the System.

- Medium High: unique user ID and pin code or a unique username and password from a specific device assumed to be controlled by the user.

- Medium: unique user ID and pin code or a unique username and password from any device. - Low: a specific device known by the system to be controlled by the user.

- None: Any device only a identification Code

- Simple: User id only

In one embodiment, the Guarantor is identified by means of a unique user ID and PIN code, or a unique username and password. The Beneficiary is identified by means of a unique user ID and pin code, or a unique username and password. The unique user ID and pin code or a unique username and password in the Role of Guarantor / Beneficiary preferably differs from the unique user ID and pin code or a unique username and password in the Role of Guarantor Representative and Beneficiary Representative.

Transaction right - In one embodiment, a Guarantor creates a Transaction Right (TR). In one embodiment, the transaction right includes one or more of the following criteria:

- The Representative (role I) of the Guarantor (Guarantor

Representative, role II)

- The guaranteed value (amount) of the units purchased.

- The maximum number (number) of times a separate transaction can be made

- Transaction schedule (frequency): Transaction can only be made inside this schedule

- Method of identification of Guarantor Representative and with a set of devices if required (transaction type)

- A set of Beneficiaries with whom the transaction can be exercised. - Amount type: Variable, fixed.

- Transaction type; defines pre-set field formats

- Whether the Guarantor can revoke (guarantee) the transaction right.

- Whether a transaction is revocable or un-revocable (guarantee) - The location (location) or area where the transaction has to be exercised

- The product or service that will be purchased by the transaction (Budget Category)

- The duration of the transaction right (expiry date)

- If a Transaction Right is activated the Guarantor cannot change it and the Transaction Right is send to the Guarantor Representative. In one embodiment, only revocable Transaction Right can be cancelled by

Guarantor.

Transaction Devices - A transaction device can communicate with the System. Some device can verify the identity of the user. A Transaction

Device can ask the System to generate a Transaction Code or it can receive a Transaction Code and send it to the System for verification. In one embodiment the system comprises and/or communicates with one or more of

- a Guarantor Representative Transaction Device (GR TD): a device controlled by Guarantor Representative for exchanging Transaction Codes.

- a Beneficiary Representative Transaction Device (BR TD): a device controlled by Beneficiary Representative for exchanging Transaction Codes. Transaction - In one embodiment, a transaction goes through two phases: From a Prepared Transaction to an Actual Transaction.

- Prepared Transaction (PT): A Prepared Transaction is an intention to come to a transaction between a specific Guarantor Representative and a specific Beneficiary; e.g. bounded by the criteria set forth in the Transaction Right of the Guarantor. The following values of the Prepared Transaction can be assigned:

- The used Transaction Right (defines the Guarantor

Representative)

- The number of times as separate transaction can be to be made

- The value of the units

- Date and time when the transaction has to be finalized.

- Method of identification of Guarantor Representative and with a device if required

- Beneficiary

- Method of identification of Beneficiary and with a device if required

- Payment method

In one embodiment, after activation by the Guarantor Representative of a Prepared Transaction none of these values can changed. The Beneficiary Representative selects the Prepared Transaction on his Transaction Device.

- Actual Transaction (AT): If the system receives a Transaction Code through a Transaction Device and after verification of all criteria can an activated Prepared Transaction become an Actual Transaction. An Actual Transaction is immediately cleared by the System.

Transaction Code (TC) - A Transaction Code is a code which identifies a Prepared Transaction uniquely. In one embodiment, it is used to transform a Prepared Transaction into an Actual Transaction. The criteria of the Prepared Transaction dictates which device(s) need(s) to receive a

Transaction Code, and how the Transaction Code is generated and how many times it can be used. In one embodiment, either a Guarantor

Representative Transaction Code is transferred to the Beneficiary

Representative Transaction device or a Beneficiary Representative

Transaction code is transferred to the Guarantor Representative

Transaction device or both transaction codes are transferred to both devices depending on the criteria of the Prepared Transaction. A Guarantor

Representative Transaction Code can be different from a Beneficiary

Representative Transaction Code. After the System receives a Transaction Code or Codes through a Transaction Device or Devices and verifies that the criteria are met then the Prepared Transaction can be made Actual.

Transaction codes which are used to actualize a Prepared Transaction can be entered into the System or generated by the System Representation Right (RR) - The Beneficiary creates a Representation Right for its representative with the following criteria:

- The Beneficiary Representative (BR)

- The maximum value of the units

- The total maximum number of units which can be transferred.

- The maximum number of times a separate transaction can be made

- Transaction schedule: Transaction can only be made inside this schedule

- Method of Identification Beneficiary Representative and with a set of devices if required

- A set of Guarantors, Guarantor Representatives with whom the transaction can be exercised.

- Method of Identification Guarantor Representative and with a set of devices if required

In one embodiment, also the Beneficiary can create a representation right for its representative and assign a set of criteria to it.

Payment Method - e.g. Payment with confirmation of receipt of the goods or services by GR and/or Outright payment.

Process - In one embodiment, the process can be as follows:

- Guarantor log into his own account on the System using his own credentials.

- The Guarantor creates a Transaction Right (TR) for a specific Guarantor Representative.

- The Guarantor activates the Transaction Right after which the equivalent value in money of the maximum number of units is blocked in his account.

- Only revocable Transaction Right can be cancelled by the

Guarantor. Otherwise a Transaction Right can expire or be returned by the Guarantor Representative to the Guarantor. An un revocable transaction can only be revoked by default if the transaction criteria or exercise date expires.

- When Transaction Rights schedule has expired or it is declined by the Guarantor Representative or cancelled by the Guarantor, any remaining amount of blocked money left is returned to the Guarantor.

- A Guarantor Representative can use his Transaction Right to create a Transaction for a specific Beneficiary bounded by the Transaction Right criteria of the Guarantor; or the Guarantor Representative can accept a Prepared Transaction from a Beneficiary Representative and assign a Transaction Right to it.

- A Guarantor Representative can activate the Prepared Transaction only if all the criteria of Transaction Right of the Guarantor and

Representation Right of the Beneficiary are met.

- When a Prepared Transaction is activated the equivalent value in money of the number of units is blocked from its Transaction Right.

- An activated Prepared Transaction cannot be revoked or cancelled by the Guarantor Representative, it can only expire or be declined by the Beneficiary or Beneficiary Representative.

- The units and corresponding value of an expired or declined Prepared Transaction is returned to the Transaction Right from which it was derived.

- If the Beneficiary is unknown to the system it can make itself known at a later stage by, after identification, specifying the Beneficiary transaction criteria. For example, a Beneficiary / Beneficiary Representative can see which Guarantor Representative has prepared a transaction for him, what the number of units are, what the value is and when the transaction has to be finalized.

- On delivery of goods or services by the Beneficiary Representative, and depending on the criteria of the Prepared Transaction, the Guarantor Representative, if required, identifies himself on his Transaction Device. Just as the Beneficiary Representative, if required, identifies himself on his Transaction Device. If the Guarantor Representative accepts the goods, the Guarantor Representative Transaction Device receives Beneficiary

Representative Transaction Code and / or Beneficiary Representative Transaction Device receives a Guarantor Representative Transaction Code. After the system verifies the Transaction Code(s) and that all the criteria of the associated Prepared Transaction are met, then the Prepared

Transaction will be changed to an Actual Transaction. All devices involved with the Prepared Transaction will receive a status message of the verification.

Accordingly, in one embodiment, the Guarantor Representative and Beneficiary Representative approve the Transaction by exchanging the Transaction Code(s). If the goods are not properly delivered, the Guarantor Transaction Representative withholds its approval, the Prepared

Transaction and its counter value is kept in trust until the goods or services are delivered as agreed and the approval of the Guarantor Representative is given or the Prepared Transaction expires.

The invention is described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The description of the exemplary embodiments is intended to be read in connection with the accompanying drawings, which are to be considered part of the entire written description. In the drawings, the absolute and relative sizes of systems, components, layers, and regions may be exaggerated for clarity. Embodiments may be described with reference to schematic and/or cross-section illustrations of possibly idealized embodiments and intermediate structures of the invention. In the

description and drawings, like numbers refer to like elements throughout. Relative terms as well as derivatives thereof should be construed to refer to the orientation as then described or as shown in the drawing under discussion. These relative terms are for convenience of description and do not require that the system be constructed or operated in a particular orientation unless stated otherwise.

FIG 1 schematically illustrates an electronic payment system 10 for managing electronic transactions between a Guarantor and a

beneficiary. The payment system 10 comprises an account database 1 arranged for storing user accounts defined by respective account data Al,A2,A3, wherein the Guarantor GR is associated with a Guarantor account by the respective account data Al. The payment system 10

comprises a transaction receiver 2 arranged to receive an order for a prepared transaction PT including information indicating the Guarantor GR, the intended beneficiary BR, and an amount X to be transferred. The payment system 10 comprises a transfer processor 3 arranged to process the prepared transaction PT from the transaction receiver 2 and to access the account database 1 to retrieve the respective account data Al of the

Guarantor account. The respective account data Al of the Guarantor account comprises a pre-set transaction right TR that indicates allowed beneficiaries B for the said Guarantor GR. The transfer processor 3 is arranged for comparing the information indicating the intended beneficiary BR included in the prepared transaction PT with the allowed beneficiaries B indicated by the transaction right TR. The transfer processor 3 is arranged for effectuating the actual transfer AT only if, in the said comparing, the information indicating the intended beneficiary BR of the prepared transaction PT matches with the allowed beneficiaries B of the transaction right TR (e.g. BR == B). The transaction of the amount X from the payer account Al to the beneficiary account A4 is illustrated by the references "AT=-X" and

"AT=+X". In the shown embodiment, the beneficiary account A4 is part of a separate account database la, e.g. not part of the payment system 1.

Alternatively, the beneficiary account can also be comprised in the same account database 1 of the payment system 10 that holds the payer account. In one embodiment, the transaction receiver 2 of the payment system 10 is located at a remote location different from a location of a user device 8 sending the prepared transaction PT. The prepared transaction PT can e.g. be sent via an electronic network such as the Internet. By having the payment system as an independent third party to manage the transactions, the Guarantor and beneficiary can rely on the impartiality of the said payment system.

In one embodiment, the respective account data Al of the Guarantor account defines a guarantor G that is authorized for setting the transaction right TR of the Guarantor account. In the embodiment, the system comprises a rights management terminal 9 arranged to receive instructions from the guarantor G for setting the transaction right TR for defining a guarantor representative GR that is authorized to act as the Guarantor for the payer account Al. In one embodiment, the guarantor representative GR that is authorized to act as the payer for the payer account is not authorized (i.e. unauthorized) for setting the transaction right TR of the payer account Al. The guarantor G and guarantor representative GR can be identified to the system by different login identification. In one embodiment, the guarantor G and guarantor representative GR can be different identities of the same person or entity.

In one embodiment, the respective account data Al of the payer account comprises a plurality of transaction right TR,TR2 each indicating one or more guarantor representatives GR that are authorized to act as payers for the payer account according to the respecting transaction rights TR. In the embodiment, the transfer processor 3 is arranged to access the account database 1 to retrieve one or more transaction rights TR from the account information Al of the payer account, which transaction rights TR are associated with the payer GR of the prepared transaction PT. The transfer processor 3 is arranged to compare each of the one or more transaction right TR with parameters of the prepared transaction PT. The transfer processor 3 is arranged to effectuate an actual transaction AT only if, in the said comparing, the prepared transaction complies with

transaction criteria of one or more of the transaction rights TR associated with the payer GR.

In one embodiment, the allowed beneficiary B of the transaction right TR is associated with a plurality of beneficiary representatives that can receive transactions from the payer GR. In the embodiment, the transfer processor 3 is arranged for effectuating the actual transaction AT only if, in the said comparing, the information indicating the intended beneficiary of the prepared transaction PT is a beneficiary representative BR of the plurality of beneficiary representatives.

In one embodiment, the transaction right TR sets one or more further transaction criteria of allowed transactions. In the embodiment, the transfer processor 3 is arranged for comparing further transaction parameters included in the prepared transaction PT with the one or more further transaction criteria of allowed transactions. In the embodiment, the transfer processor 3 is arranged for effectuating the actual transaction AT only if, in the said comparing, the transaction parameters included in the prepared transaction PT comply with all the one or more further transaction criteria of allowed transactions.

In one embodiment, the transaction right TR indicates a maximum amount that is allowed to be transferred by the payer GR to the beneficiary B. In the embodiment, the transfer processor 3 is arranged for comparing the amount X included in the prepared transaction PT with the maximum amount indicated by the transaction right TR. In the embodiment, the transfer processor 3 is arranged for effectuating the actual transaction AT only if, in the said comparing, the amount X included in the prepared transaction PT is smaller than the maximum amount.

In one embodiment, the payer account is arranged to store dates and amounts of past transactions of the payer GR to the beneficiary B. In the embodiment, the transaction right TR indicates a maximum cumulative amount and a time period over which the maximum cumulative amount can be transferred from the payer GR to the beneficiary B. In the embodiment, the transfer processor 3 is arranged for calculating the cumulative amount transferred in the said past transactions for the said time period; the transfer processor 3 is arranged for comparing the calculated cumulative amount to the maximum cumulative amount of the transaction right TR; and the transfer processor 3 is arranged for effectuating the actual transaction AT only if, in the said comparing, the calculated cumulative amount is smaller than the maximum cumulative amount.

In one embodiment, the transaction right TR indicates a blocked amount that is available for transfer only by a designated payer indicated in the transaction right TR. In the embodiment, the transfer processor 3 is arranged to identify a payer indicated in the prepared transaction PT; and effectuating the actual transaction AT from the blocked amount only if, in the said comparing, the identified payer is the designated payer in the transaction right TR.

In one embodiment, the transaction right TR defines an expiration date after which date the transaction right TR is removed from the account database 1 and/or the transfer processor 3 is arranged to ignore the said transaction right TR after said expiration date.

In one embodiment, the transaction right TR is irrevocable until the transaction right TR is utilized and/or until an expiration date of the transaction right TR is passed. In one embodiment, the transaction receiver 2 is arranged to receive a transaction code TC from a user device 8 which transaction code TC uniquely identifies and/or defines the prepared transaction PT. In the embodiment, the system comprises a status transmitter 4 arranged for transmitting a status message "AT_msg" to the user device 8 including information whether the actual transaction AT was effectuated. The user device 8 may accordingly comprise a transaction transmitter 6 and a status receiver 7. In one embodiment, the transaction receiver 2, the transfer processor 3, and the status transmitter 4 are comprised in a transaction actuator 5.

In one embodiment, the transaction receiver 2 is arranged to receive a transaction code TC from a handheld device; wherein the transaction code TC uniquely identifies the handheld device. In the embodiment, the uniquely identified handheld device is associated with the payer GR in the transaction right TR. In the embodiment, the transfer processor 3 identifies the payer GR by means of the transaction code TC of the handheld device.

In one embodiment, the transaction receiver 2 is further arranged to receive a location signal, In the embodiment, the transaction right TR defines one or more allowed locations. In the embodiment, the transfer processor 3 is arranged for effectuating the actual transaction AT only if, in the said comparing, the location signal complies with the one or more allowed locations of the transaction right TR.

FIG 1 can also serve to illustrate a method for managing an electronic transaction between a payer GR and a beneficiary BR. The method comprises providing an account database 1 storing user accounts defined by respective account data Al,A2,A3, wherein the payer GR is associated with a payer account by the respective account data Al. The method comprises providing a transaction receiver 2 receiving an order for a prepared transaction PT including information indicating the payer GR, the intended beneficiary BR, and an amount X to be transferred. The method comprises providing a transfer processor 3 processing the prepared transaction PT from the transaction receiver 2; accessing the account database 1 to retrieve the respective account data Al of the payer account. The respective account data Al of the payer account comprises a pre-set transaction right TR that indicates allowed beneficiaries B for the said payer GR. The transfer processor 3 compares the information indicating the intended beneficiary BR included in the prepared transaction PT with the allowed beneficiaries B indicated by the transaction right TR. The transfer processor 3 effectuates an actual transaction AT only if, in the said comparing, the information indicating the intended beneficiary BR of the prepared transaction PT matches with the allowed beneficiaries B of the transaction right TR. FIG 1 can also serve to illustrate a computer program, e.g. stored on a non-transient computer storage medium. The computer programs comprises instructions that if executed by one or more computers cause the one or more computers to

- store user accounts defined by respective account data Al,A2,A3 in an account database 1, wherein a payer GR is associated with a payer account by the respective account data Al;

- to receive an order for a prepared transaction PT including information indicating the payer GR, an intended beneficiary BR, and an amount X to be transferred;

- to process the prepared transaction PT;

- to access the account database 1 to retrieve the respective account data Al of the payer account; wherein the respective account data Al of the payer account comprises a pre-set transaction right TR that indicates allowed beneficiaries B for the said payer GR;

- to compare the information indicating the intended beneficiary BR included in the prepared transaction PT with the allowed beneficiaries B indicated by the transaction right TR; and

- to effectuate an actual transaction AT only if, in the said

comparing, the information indicating the intended beneficiary BR of the prepared transaction PT matches with the allowed beneficiaries B of the transaction right TR.

In one embodiment, a method comprises inputting transaction criteria (transaction right) in a database; having a smart phone or other portable device being activated based on a location; providing a push message to the portable device to indicate that a transaction at the location is allowed by the transaction criteria; having the user of the portable device accept activation of a prepared transaction, e.g. by scanning a QR code of the store; having the user of the portable device scan purchases e.g. by means of a barcode in a shop or web shop; have the system check the store/purchases against the transaction criteria; and approve/refuse the message or QR code scan, credit/debit card swipe based on the said criteria

FIG 2 schematically illustrates another embodiment of a payment system 10 and user device 8 interacting therewith. The system is largely similar to the payment system of FIG 1 but with additional details. As shown, the payment system 10 comprises an account database 1, a transaction actuator 5, and a rights management terminal 9.

The account database 1 comprises a number of payer accounts and/or more generally, user accounts which can also be owned by

beneficiaries. In this embodiment, one payer accounts comprises a number of transaction category registers A1-A4. A first transaction category register Al comprises two transaction rights TR1 and TR2, each with their own associated guarantor G, representative GR, and beneficiary B. Similarly, a second transaction category register comprises two transaction rights. The transaction actuator 5 comprises a transaction receiver 2, a transfer processor 3, and a status transmitter 4. The status transmitter 4 is arranged to transmit messages Msg to a user device 8, in particular to the status receiver 7 comprised in the user device 8. The transaction receiver 2 is arranged to receive activated transactions AT and transaction codes TC from a user device 8, in particular from the transaction transmitter 6, comprised in the user device 8. The transaction receiver 2 is further arranged to send input PT (prepared transaction) to the rights management terminal 9 and to send input AT (actual or activated transaction) to the transfer processor 3. The transfer processor 3 accesses the respective transaction rights TR from the account database 1 and processes them to provide feedback Bl to the status transmitter 4.

The rights management terminal 9 is arranged to handle the transaction rights and payer accounts in the account database 1 and can optionally be used to provide a unique transaction number for an activated transaction AT.

In the following, embodiments of transaction rights are discussed with reference to the appended tables. Of course these serve to illustrate the present disclosure by means of example only for elucidating possible applications of the present disclosure. The skilled artisan having the benefit of the present disclosure will appreciate that many variations of the disclosed examples can be envisaged. In the tables:

Tables 1-4 illustrate examples of transaction right definitions. Table 5 illustrates the use of templates for the creation of transaction rights.

Table 6 illustrate the authorization rights of various parties in altering fields of the transaction right.

Table 1

Table 3

Table 4 Field Name B POSB Giro B Escrow B CoupoB Gift B RandoiB

Role 1 M M M M

Role I I M M M C

Guarantee I rrevocable Irrevocable Revocable I rrevocable C

Transaction Type PO Gi ro Escrow Cou pon Gift c

Amount M % C c

Amount Type M Fixed Variable Variable c

Frequency Date Date c

Duration M M Year c

Number M M C c

Role I II M M c

Role IV N/A C N/A N/A c

Budget Category N/A M C M c

Location N/A M M

Table 5

Table 6 In the tables, the transaction rights have the following fields:

- "Role I": indicates the guarantor that created the transaction right.

- "Role Π": identification of the guarantor representative GR that is allowed to use the transaction right. This field allows the user to enter the beneficiaries from pre-set lists or random from predefined formats or a mnemonic related to a format. The contact or address list can be created or used from an existing application on the PC or smartphone. The beneficiary (III) is validated against the databases if the beneficiary is unknown an extra validation is invoked through a confirmation by the beneficiary.

- "Guarantee": indicates whether the transaction right is revocable or irrevocable; The guarantee field offers a choice between revocable and irrevocable transactions. If revocable the transaction can be undone by the guarantor if the transaction constitutes a series earlier transaction cannot be undone. If the transaction is not executed it can be undone. If irrevocable the transaction can only be undone when the criteria are not met.

Transactions are automatically revoked if the transaction criteria are not met.

- "Transaction type": e.g. point of sale (POS), Giro, Escrow, Coupon, Gift, Random; The transaction type field allows for a choice between POS (point of sale), Escrow, Giro, Coupon or Gift transaction types. This transaction type indicates how the transaction will be exercised. POS transaction will be initiated at the point of sale and held against the criteria held in this record and according to the pre-defined transaction flow for POS. Escrow transaction types will be initiated at the point of sale or internet and held against the criteria in this record plus a confirmation of delivery of the product by the guarantor. The frequency date is the date at which the goods or services have to be delivered. Giro transactions are bank transfers and will be initiated by the guarantor and held against the criteria held in this record. Coupon transactions are transactions that will be initiated at the point of sale or internet, but are multiple transactions with the same criteria and the same guarantor. Gift transactions are

transactions that will be initiated at the point of sale or internet, but is allocated to a single product or service or beneficiary or a combination thereof.

- "Amount": the amount of money allowed to be spent in connection with the transaction right. The amount field can be entered with a single amount, a list of amounts or a bandwidth at which the transaction can be exercised. Band with can be a % of the price offered.

- "Amount type": e.g. variable or fixed; The amount type field allows for a choice, whether the transaction amount is fixed or variable. It is checked against the amount field, it only needs to be filled in if there are multiple amounts or an amount bandwidth entered.

- "Frequency": indicates e.g. a time period or a number of times that a transaction can be performed using the transaction right. The frequency field allows input days, weeks, months years and it defines the frequency at which the transaction will be exercised. If an exact date is entered the transaction will be exercised on that date. A number of dates can be entered that will be checked against the number field

- "Duration": indicates whether the transaction right has an expiration date or is open. The duration field allows input in hours, days, years and it defines the period at which the transaction can be exercised. If the duration expires and the transactions is not executed it will be revoked. If the transaction is open it will not expire unless the guarantor revokes it.

- "Number": Amount of times the transaction has to be executed, or on going. The number is checked against the amount type, whether the amount is fixed or variable. If the transaction number is 1 the amount type is always fixed. If the transaction amount is more than 1 tit can be fixed or variable.

- "Role III": indicates an allowed beneficiary;

- "Role IV": indicates an allowed beneficiary representative; - "Budget Category": indicates a category for the transaction right. This field allows the user to define the budget category under which the transaction has to be executed. The budget category is checked against a combination of the, Universal Product Code (Bar-,QR-, RFID code),

Merchant ID and industry code or international standard of industrial classification (ISIC). The beneficiary and its products or services have to be coded in this fashion. In one embodiment, a budget category may be used alternatively or in addition to an allowed beneficiary wherein the payment system only effectuates an actual transaction if information of the prepared transaction indicates that a purchase category falls within an allowed budget category of the transaction right;

- "Location": e.g. a GPS location of an allowed beneficiary or a point of sale where a purchase is allowed. This field allows the user to define where the transaction may take place, this could be an exact location or a region based on multiple location codes. Location code can be exclusive or inclusive, i.e. limited to the location (inclusive) or the transaction may not take place in the specific location (exclusive). Location can also be based on the location of the device where the transaction will be executed Table 1 illustrates a first example of a transaction right. In the example a parent creates a transaction right to allow a child to spend 450 each month at point of sale (POS) ""Company XX" in "City YY"". This may e.g. include the following aspects:

1. Guarantor (parent) prepares the transaction.

2. Parent assigns Guarantor Representative to daughter's account

(e.g. by means of her phone number).

3. Guarantor chooses to make transaction revocable (can be undone) or irrevocable (guaranteed) . Executed transactions cannot be revoked. 4. The transaction can only be exercised at the point of sale (in the store).

5. The transaction amount is 450.

6. The amount is variable as to use the amount in a series of transactions.

7. The transaction will be exercised during a month.

8. The transaction will be repeated until it is revoked.

9. The number of transactions under this transaction is open (undefined).

10. The beneficiary is "Company XX".

11. The beneficiary Representative is "Company XX".

12. Budget type is groceries, based on product codes assigned

13. "Company XX" in "City YY" Table 2 illustrates a second example of a transaction right. In the example a company enters a monthly budget to earmark 500 spending limit for petrol and parking for one of its employee's.

Table 3 illustrates a third example of a transaction right. The example illustrates a transaction right that is used for a simple POS transaction at market stool to purchase vegetables. Usage of the transaction right may e.g. include the following aspects:

l.Intiate transaction, scan Random merchant QR code.

2. Push confirmation message from merchant to smartphone.

3. Open transaction and enter purchase amount Send transaction. 4. Check balance against transaction right. If no match send return message.

5. Transaction received by merchant handover purchase.

6. Close transaction , hand over receipt.

7. Exercise transaction. Debit account guarantor, Credit account beneficiary. Accordingly, in this example, the customer initiates the

transaction by scanning the merchant QR code displayed on the stool. The customer enters the transaction amount and sends a message containing the transaction details to the merchant. Transaction is displayed in a smartphone or a computer screen and accepted by the merchant by means of handing over the purchase. The merchant will be allowed to use the transaction details for later use if the customer profile allows for

information sharing. Table 4 illustrates a fourth example of a transaction right. The example illustrates a transaction right that is used for POS transaction via checkout at grocery store to purchase groceries. Usage of the transaction right may e.g. include the following aspects:

l.Intiate transaction, scan Random merchant QR code. 2. Push confirmation message from merchant to smartphone.

3. Open transaction at checkout by scanning or entering checkout number.

4. Check-out enters purchases in POS device en sends balance due to smartphone.

5. Balance due checked against transaction right. If no match send return message.

6. Customer confirms purchase Transaction approval received by merchant hands over purchase.

7. Effectuate transaction: Debit the account of the guarantor and credit the account of the Beneficiary.

8. Close transaction , send or hand over receipt.

Accordingly, in this example, the customer initiates the transaction by scanning the merchant QR code displayed at the store entrance. The customer opens transaction at checkout . Checkout registers purchases and creates balance due. Transaction is displayed for confirmation on customer smartphone. The merchant will be allowed to use the transaction details for later use if the customer profile allows for information sharing. If self scanning app on a smartphone is steps 3 and 4 may change order.

Table 5 illustrates the use of templates. The system allows a user to build templates based on a number of formats. This example shows the transaction types that trigger fields to be mandatory (M), a choice (C), or not allowed (N/A) to be used. Templates can be built in association with beneficiaries, budget categories, etc.

Table 6 illustrates roles and rights of the various parties: Guarantor G, Guarantor Representative GR, Beneficiary B, Beneficiary Representative BR. For each role is defined what fields it can add (A), delete (D), change (C), or whether modification of the field is not allowed (N/A).

By allocating the transaction right to a pre-defined category and/or earmark the transaction right, it is prevented that money is spent elsewhere e.g. on unnecessary or forbidden purchases. Preferably, the transaction right is earmarked upon activation of the transaction right. As such, the amount may comprise a pledge.

Advantageously, the transaction right (TR) comprises an instruction to the beneficiary (Role III and IV) to deliver the in the budget category defined goods and services. If the transaction type is escrow, the beneficiary is guaranteed the amount upon receipt of defined goods and services, and/or the beneficiary is advised in advance of delivery of the goods and service upon the scheduled execution of the amount, and/or the guarantor (role I and II) is guaranteed the delivery as soon as the

transaction right is accepted by the beneficiary (Role III and IV). Further, the transaction right TR may comprise a schedule of a string of transactions, preferably with a defined number and/or a defined duration, such as end or exact time, and/or a defined frequency, such as day of the week, weekly, monthly, quarterly or annually.

Preferably, the user device 8 is arranged to capture data via photographic means, a machine readable card, RFID technology, QR technology, Bar coded standards and/or keyboard input. Further, the user device 8 can be arranged to decompose captured data into a pre-defined record format (see Table 1, 2, 3, 4) in the transaction transmitter 6, and to transmit the record format to the transfer processor 3, via the transaction receiver 2, for comparison. Optionally, the transaction transmitter 6 is arranged to encrypt the record format before transmission, and the transaction receiver 2 is arranged to de-cypher the encrypted record format based on an assigned IP number and a unique key. The transaction transmitter may add an algorithm to the transaction which will not be the same as any previous algorithm or any other user device. Further, the transaction transmitter 6 may transmit the encrypted record format to a multiple number of hosts CPU until it is deciphered. The transaction transmitter may offer the transaction sequentially to all transaction receiver objects to all hosts until it is deciphered.

In an advantageous embodiment, the system comprises a multiple number of transaction actuators 5 located on different hosts CPU, each transaction receiver 2 having a unique IP number. Further, the transaction transmitter 6 on the user device 8 contains an algorithm that is calculated based on allocated and pre-defined IP numbers stored in each transaction receiver 2. The transaction receiver may be multiplied and operated on different hosts, being provided with a unique IP number. The transaction receiver may contain a unique key per user device 8 to decipher the algorithm to compare the unique IP number, while the deciphered

transaction is offered to the transfer processor for comparison and approval.

Advantageously, the transaction transmitter may offer an algorithm for deciphering to the available receiver objects at random. If desired, the communication between the transmitter and the receivers is encrypted by standard methods. Further, the transaction receiver may be provided with a time-out function to decline transactions that have exceeded a predefined time limit for this type of transaction.

Interface - A program, app or web application on a computer or any other computing device whether mobile or fixed can give a user access to the System. In one embodiment, an interface for interacting with the present systems and methods is structured as follows:

1. The Home menu shows the user which role he wants to login to the

system

1.1. The user logs into the System using Guarantor Identification

credentials in the role of Guarantor

1.1.1. The user logs off as Guarantor. Goto 1:

1.1.2. Transaction Rights

1.1.2.1. Guarantor can create a new Transaction Right

1.1.2.2. Guarantor can edit a non activated Transaction Right

1.1.2.3. Guarantor can activate a Transaction Right

1.1.2.4. Guarantor can revoke a revocable Transaction Right

1.1.2.5. Guarantor can list, search, report, all Transaction Right, Prepared Transaction and Actual Transaction

1.1.2.6. Guarantor can build template Transaction Right

1.1.3. Manage Guarantor Representatives

1.1.3.1. Search for a Guarantor Representatives 1.1.3.2. Create, edit and remove short lists of Guarantor Representative

1.1.3.3. Create, edit and remove groups of Guarantor

Representatives

1.1.4. Manage Beneficiaries

1.1.4.1. Create, edit and remove short lists of Beneficiaries representatives

1.1.4.2. Create, edit and remove groups of Beneficiaries

representatives

1.1.5. Options

1.1.5.1. Create a profile with transaction preferences

1.1.5.2. Manage representatives

1.1.5.3. Manage budget

1.1.5.3.1. Create, Edit and remove Spending limits 1.1.5.3.2. Create, edit and remove Product-service budgets

1.1.5.3.3. Create, edit and remove Merchant preferences The user logs into the System using Guarantor Representative Identification credentials in the role of Guarantor Representative 1.2.1. The user logs off as Guarantor Representative. Goto 1:

1.2.2. Transactions Rights / Prepared Transaction

1.2.2.1. Guarantor Representative can list, search all

Transaction Right assigned to him.

1.2.2.2. Guarantor Representative can create a Prepared Transaction based on a Transaction Right.

1.2.2.3. Guarantor Representative can edit a non activated Prepared Transaction.

1.2.2.4. Guarantor Representative can activate a Prepared Transaction 1.2.2.5. Guarantor Representative can list search, report, all his Transaction Rights, Prepared Transaction and Actual Transaction. 1.3. The user logs into the System using Beneficiary Identification

credentials in the role of Beneficiary

1.3.1. The user logs off as Beneficiary. Goto 1:

1.3.2. Prepared Transaction

1.3.2.1. Beneficiary can list all Prepared Transaction assigned to him.

1.3.2.2. Beneficiary can reject Prepared Transaction

1.3.2.3. Beneficiary can edit Prepared Transaction if allowed (ie assign Beneficiary Representative, input a field) 1.3.2.4. Beneficiary can see all Actual Transaction

1.3.3. Beneficiary Representative

1.3.3.1. Search for a BR

1.3.3.2. Create, edit and remove short lists of Beneficiary

Representative

1.3.3.3. Create, edit and remove groups of Beneficiary

Representative

1.4. The user logs into the System using Beneficiary Representative Identification credentials in the role of Beneficiary Representative

1.4.1. The user logs off as Beneficiary Representative Goto 1:

1.4.2. Prepared Transaction

1.4.2.1. Beneficiary Representative can list all Prepared

Transaction assigned to him. 1.4.2.2. Beneficiary Representative can reject Prepared

Transaction

1.4.2.3. Beneficiary Representative can edit Prepared Transaction if allowed (i.e. assign Beneficiary Representative, input or change a field)

1.4.2.4. Beneficiary Representative can see all Actual Transaction

1.4.3. Beneficiary Representative

1.4.3.1. Search for a Beneficiary Representative

1.4.3.2. Create, edit and remove short lists of Beneficiary Representative

1.4.3.3. Create, edit and remove groups of Beneficiary Representative

Figure 3 shows a flowchart of an embodiment of a method according to the invention. The method protects the system against external attacks trying to violate the integrity of the system operation. Also, sabotage is prevented.

According to an aspect of the invention, an algorithm is calculated in the transaction transmitter 6 and deciphered in the transaction receiver 2. The transaction receivers 2 can be located on a multitude of hosts and can be arranged to decipher the algorithm to release any transaction data. The figure shows that the algorithm can only be deciphered by transaction receivers 2 that have not deciphered the algorithm for the particular user device before (the number of iterations between the unique objects is defined in a table in the transmitter). The transaction circulates within all the known IP numbers of the attached software objects (transaction receivers) and the processors that execute the programs involved. Further, the algorithm has a timestamp attached to by which the receiver and the message transmitter may deliver a status message to the transaction transmitter. If the transaction deciphering process exceeds a pre-set time period (the time stamp) it can be timed out and a new transaction can be created. The algorithm is based on a set of known IP numbers (IP1 etc) of the transaction receivers as well as the IP numbers and a prime number stored on the user device. The transaction receiver may have a list of prime numbers and its unique IP number. Further, the transaction transmission can be encrypted.

Figure 4 schematically illustrates a payer account, and Figure 5 shows a further flowchart of an embodiment of a method according to the invention.

In particular, Fig. 4 illustrates the composition of the transaction data and the connections between the amorphous data. The data is stored in a database that uses the structures with vertices (the first transaction right prepared by the guarantor), transaction rights, and properties to represent and store the data. Each pre-set transaction right TR is represented as a graph 110; 112 including a multiple number of data sets 120-127; 131- 137. The data sets are connected via connections 160. Further, the pre-set transaction rights 110, 112 are linked via links 150 to form a payer account 100. Each data set may include a subgraph with sub-data 131, 141, 132, 142, 143, 144. In principle, these subgraphs can be split into further sub- subgraphs. Thus, data sets and sub-data sets are represented by vertices and sub-vertices, respectively. The connections 160 and links 150 are represented by edges. The database can be any storage system that is constructed for storing vertexes and edges e.g. in the form of an adjacency matrix meaning that every element contains a permanent direct connection, such as in an electrical circuit, to its adjacent elements and no

index lookups are necessary. Each element (transaction right and

connection) may have an ID whereas the transaction right will have Vectrice ID (vid) and a transaction ID, the connection will have a connection ID (cid).

In the flow chart of Fig. 5, a process of populating and using the database is shown. The database can be built or filled as follows. After starting the process in step 201, data sets are captured, stored in an amorphous manner and related to other data sets, e.g. in related transaction rights, related category registers and/or related guarantor accounts to form pre-set transaction rights TR, in steps 202-215. Upon receiving an order for a prepared transaction or an activation request, the order or request is compared with a pre-set transaction right in steps 216 and 222.

Subsequently, after successful verification, status information is exchanged in steps 217-200 and 223-226, and the prepared transaction is executed in steps 227-231.

From the above description it will be appreciated that the present disclosure proposes a robust transaction system which gives the guarantor of a transaction control over a transaction of its representative. It controls the transaction from creation to the point of exercise without a physical presence of the guarantor. It also gives the beneficiary of the transaction the security that the representative of the guarantor is able to meet his financial obligations in advance of delivery of the goods or services. In general it reduces delivery-, financial risk and fraud. In one aspect a

Guarantor creates a transaction right for its representative (i.e. the

"Guarantor Representative" GR) and assigns a set of criteria to it. In one embodiment, the Guarantor Representative (GR) can use this right to buy goods or services from a Beneficiary if and only if all the criteria associated with the transaction right have been met.

While example embodiments were shown for the transaction systems, methods and implementation in software, including database structuring and interfaces, alternative ways may be envisaged by those skilled in the art having the benefit of the present disclosure for achieving a similar function and result. E.g. the account database 1, transaction receiver 2, transfer processor 3, and/or transaction transmitter 4 may be combined or split up into one or more alternative components or integrated devices. The data structure may be altered, e.g. some fields of the

transaction right as illustrated may be omitted and/or additional fields can be added. In addition or alternatively to using an intended beneficiary to determine the compliance of a transaction, also other fields of the

transaction right can be used and checked against respective transaction parameters indicated e.g. in the prepared transaction.

The various elements of the embodiments as discussed and shown offer certain advantages, such as improved control over monetary

transactions by requiring the transaction to adhere to pre-set parameters prior to exercise. Of course, it is to be appreciated that any one of the above embodiments or processes may be combined with one or more other embodiments or processes to provide even further improvements in finding and matching designs and advantages. It is appreciated that this disclosure offers particular advantages to monetary transactions, and in general can be applied for any application wherein a first party (Guarantor Representative) comes to an agreement with a second party (Beneficiary or Beneficiary Representative) on behalf of a third party (Guarantor). In stead of a monetary transaction, also other transactions or even more general

(inter)actions can be managed, negotiated, and/or effectuated. For example a system can manage the allowance or refusal of interactions according to preset conditional parameters stored by the system. The effectuated action may include a physical interaction, e.g. activation of an actuator.

While the present systems and methods have thus been described in particular detail with reference to specific exemplary embodiments thereof, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the scope of the present disclosure. For example, embodiments wherein devices or systems are disclosed to be arranged and/or constructed for performing a specified method or function inherently disclose the method or function as such and/or in combination with other disclosed embodiments of methods or systems. Furthermore, embodiments of methods are considered to inherently disclose their implementation in respective hardware, where possible, in combination with other disclosed embodiments of methods or systems. Furthermore, methods that can be embodied as program instructions, e.g. on a non-transient computer-readable storage medium, are considered inherently disclosed as such embodiment.

Finally, the above-discussion is intended to be merely illustrative of the present systems and/or methods and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments. The specification and drawings are accordingly to be regarded in an illustrative manner and are not intended to limit the scope of the appended claims. In interpreting the appended claims, it should be understood that the word "comprising" does not exclude the presence of other elements or acts than those listed in a given claim; the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements; any reference signs in the claims do not limit their scope; several "means" may be represented by the same or different item(s) or implemented structure or function; any of the disclosed devices or portions thereof may be combined together or separated into further portions unless specifically stated otherwise. The mere fact that certain measures are recited in mutually different claims does not indicate that a combination of these measures cannot be used to advantage. In particular, all working combinations of the claims are considered inherently disclosed.