WO2023244769A1 - Automated rights management - Google Patents

Abstract

Automated rights management is provided. A plurality of delivery confirmations for a product are received. Each of the plurality of delivery confirmations is allocated among one or more contracts of sale, each of the one or more contracts of sale indicating at least a payor. Proceeds of the one or more contracts of sale are determined based on the allocation. A plurality of payment rules is read, each payment rule indicating at least a payee. Based on the proceeds of the one or more contracts of sale and the plurality of payment rules, a transaction list is constructed that minimizes the total number of transactions among the payors and payees.

Description

AUTOMATED RIGHTS MANAGEMENT

RELATED APPLICATION(S)

[0001] This application claims the benefit of priority to U.S. Provisional Application No. 63/352986, filed June 16, 2022, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Farmers producing agricultural commodities plan the production, delivery and sale of commodities to optimize their profitability based on many factors, including selection and payment for inputs such as seed and seed treatments, complex tenancy and partnership obligations (for example, the USDA reports that over fifty percent of crop land in the United States is rented), volatile commodity markets, and the time and location of delivery of commodities. Farmers often enter into contracts to sell agricultural commodities well before the commodities are harvested, and the volume of commodity specified in the contract often is far greater than can be delivered all at once. For example, multiple truck or barge loads may be required to deliver a volume of grain or oilseed sold under a single contract. Upon completion of each partial delivery the recipient issues a delivery confirmation (e.g., a scale ticket), the farmer must associate each delivery confirmation with a contract in order to initiate payment under the terms of that contract. However, a farmer’s (payee’s) payment preferences are generally not fully reflected in a contract for the sale of an agricultural commodity.

[0003] Embodiments of the present disclosure relate to automated rights management, and more specifically, to improving the operation efficiency of electronic systems processing grain sales by integrating multiple layers of payee constraints within a matrix of transactions to produce a minimum set of transactions necessary to fulfill grain contracts. BRIEF SUMMARY

[0004] According to embodiments of the present disclosure, methods of and computer program products for automated rights management are provided. A plurality of delivery confirmations for a product are received. Each of the plurality of delivery confirmations is allocated among one or more contracts of sale, each of the one or more contracts of sale indicating at least a payor. Proceeds of the one or more contracts of sale are determined based on the allocation. A plurality of payment rules is read, each payment rule indicating at least a payee. Based on the proceeds of the one or more contracts of sale and the plurality of payment rules, a transaction list is constructed that minimizes the total number of transactions among the payors and payees.

[0005] In various embodiments, each of the plurality of delivery confirmations comprises a scale ticket. In some embodiments, the scale ticket indicates a quantity of product delivered. In some embodiments, the scale ticket indicates a quality of product.

[0006] In various embodiments, the product is an agricultural product. In some embodiments, the agricultural product is a grain, oilseed, or primary processed product thereof.

[0007] In various embodiments, the product is an ecosystem attribute .

[0008] In various embodiments, the product is a coupled agricultural product and an ecosystem attribute.

[0009] In various embodiments, allocating each of the plurality of delivery confirmations among the one or more contracts of sale comprises optimizing allocation based on overall value. In some embodiments, said optimizing comprises maximizing overall value while conforming to one or more constraints. In some embodiments, said optimizing comprises maximizing cashflow while conforming to one or more constraints. In some embodiments, said optimizing cashflow comprises maximizing cashflow over a period of time specified in a one or more producer payment rules. In some embodiments, said optimizing comprises maximizing value over a period of time specified in a one or more producer payment rules. [0010] In various embodiments, allocating each of the plurality of delivery confirmations among the one or more contracts of sale comprises obtaining farm management data for the production area of the delivered product. In some embodiments, the farm management data comprises current, historical, or current and historical data related to the production location of the agricultural product. In some embodiments, the farm management data comprises one or more of production locations, field boundaries, management zones, planting dates, harvest dates, agricultural practices, agricultural practice dates, inputs, input costs, equipment type, equipment run time, and costs of production.

[0011] In various embodiments, the one or more constraints comprise product characteristics required to meet a contract of sale. In some embodiments, the product characteristics comprise humidity, quantity of breakage kernels, kernel size, color, test weight, no foreign material, protein level, oil content, milling quality, and /or hardness.

[0012] In various embodiments, constructing the transaction list comprises generating a data structure reflecting a plurality of transactions, each having a payor and a payee. In some embodiments, the data structure is a matrix or a directed graph. In some embodiments, constructing the transaction list comprises simplifying the data structure to reduce the number of transactions while conforming to one or more constraints. In some embodiments, simplifying the data structure comprises bin packing, clusterization, random forest, subset sum, or min-cost flow.

[0013] In various embodiments, allocating each of the plurality of delivery confirmations among one or more contracts of sale comprises determining if the set of one or more contracts is eligible for allocation of a scale ticket. In some embodiments, contracts are eligible for allocation when a contract pricing structure has been applied to the some or all of the amount of the product to be delivered under a contract. In some embodiments, contracts are eligible for allocation when the amount of delivery confirmations previously applied to the contract are less than the total amount of the product to be delivered under the contract. In some embodiments, contracts are eligible for allocation when the amount of delivery confirmations previously applied to the contract are less a threshold amount in excess of the volume of the product to be delivered under the contract. In some embodiments, contracts are eligible for allocation when the amount of product specified in delivery confirmations previously applied to the contract are less than the total volume of product to be delivered under the contract and more than a threshold amount in less than the volume of the product to be delivered under the contract. In some embodiments, contracts are eligible for allocation when allocation when the amount of product specified in delivery confirmations previously applied to all contracts between payor and producer are equal to the total volume of the product to be delivered under all the contracts, and the volume of delivery confirmations applied to at least one of the contracts between payor and producer is less a threshold volume in excess of the volume of the product to be delivered under the contract.

[0014] In various embodiments, reading the plurality of payment rules comprises determining a priority of execution of payment rules. In some embodiments, producer payment rules that conflict with third-party rules are canceled. In some embodiments, third- party payment rules cancel conflicting payee payment rules and payee payment rules cancel conflicting producer payment rules.

[0015] In various embodiments, a full or partial overlap between payor payment rules and producer payment rules or payor payment rules and third-party rules trigger a request for modification of producer payment rules be sent to the producer. In some embodiments, a full or partial overlap between payor payment rules and third-party rules trigger a request for modification of producer payment rules be sent to the payor. In some embodiments, the contracts to which the conflicting rules apply are removed from the allocation. In some embodiments, the request for modification of producer rules comprises the set of potential modifications permitted under the conflicting rules.

[0016] In various embodiments, a plurality of payment rules comprises payor payment rules. In some embodiments, at least one of the payor payment rules comprises one or more accepted method of payment. In some embodiments, the one or more accepted method of payment comprises one or more of a paper check, a wire transfer, a credit card, and peer-to- peer payment and money exchange.

[0017] In various embodiments, a producer’s global payment rules are consolidated with the producer’s contract specific payment rules if the rules are not in conflict.

[0018] In various embodiments, a producer’s contract specific payment rules replace the producer’s conflicting global payment rules for the contract to which the contract specific payment rules apply.

[0019] In various embodiments, the reading a plurality of payment rules is performed before allocating each of the plurality of delivery confirmations among one or more contracts of sale.

[0020] In various embodiments, the one or more constraints additionally comprise the plurality of payment rules.

[0021] In various embodiments, the method additionally comprises receiving, for each of the one or more contracts of sale, verification of a type of agricultural product, a price of agricultural product, and a producer of an agricultural product for each contract from the payor of that contract.

[0022] In various embodiments, the method additionally comprises receiving, for each of the one or more contracts of sale, verification of a type of agricultural product, a price of agricultural product, for each contract from the producer of the agricultural product of that contract. In some embodiments, receiving verification comprises using one or more API. [0023] In various embodiments, reading a plurality of payment rules comprises reading payment rules from an electronic system of a payor.

[0024] In various embodiments, reading a plurality of payment rules comprises reading payment rules from an electronic system of a producer.

[0025] In various embodiments, reading a plurality of payment rules comprises reading payment rules from an electronic system of a third-party other than a payor or producer. In some embodiments, the payment rules are accessed automatically via an API.

[0026] In various embodiments, the method is initiated automatically upon receipt of at least one delivery confirmation and determination that at least one contract is open for allocation. [0027] In various embodiments, the method is initiated automatically at least once a minute, at least one an hour, at least once a day, at least once a week, at least once every two weeks, at least once a month.

[0028] In various embodiments, the method further comprises subsetting the transaction list by payor.

[0029] In various embodiments, the method further comprises aggregating the transaction list by payor to compute the total amount to be paid by payor to all payees, generating a payment schedule corresponding to the transaction list for each payor, and a ledger of each payor’s contracts that are fully or partially satisfied by the transaction list.

[0030] In various embodiments, a delivery confirmations is an image of a physical scale ticket.

[0031] As used herein, the quantity of a product may be measured in terms of weight or volume. [0032] As used herein, “quality” or a “quality metric” may refer to any aspect of an agricultural product that adds value. In some embodiments, quality is a physical or chemical attribute of the crop product. For example, a quality may include, for a crop product type, one or more of: a variety; a genetic trait or lack thereof; genetic modification of lack thereof; genomic edit or lack thereof; epigenetic signature or lack thereof; moisture content; protein content; carbohydrate content; ash content; fiber content; fiber quality; fat content; oil content; color; whiteness; weight; transparency; hardness; percent chalky grains; proportion of corneous endosperm; presence of foreign matter; number or percentage of broken kernels; number or percentage of kernels with stress cracks; falling number; farinograph; adsorption of water; milling degree; immature grains; kernel size distribution; average grain length; average grain breadth; kernel volume; density; L/B ratio; wet gluten; sodium dodecyl sulfate sedimentation; toxin levels (for example, mycotoxin levels, including vomitoxin, fumonisin, ochratoxin, or aflatoxin levels); and damage levels (for example, mold, insect, heat, cold, frost, or other material damage).

[0033] As used herein an “ecosystem attribute” is a beneficial environmental characteristic (for example, as a result of agricultural production) that may be quantified and valued (for example, as an ecosystem credit or sustainability claim). Examples of ecosystem benefits include without limitation reduced water use, reduced nitrogen use, increased soil carbon sequestration, greenhouse gas emission reduction or avoidance, biodiversity, etc.

[0034] In various embodiments, an environmental attribute may be linked to an agricultural product at a variety of scales of spatial resolution and or according to the identity of an originating organization; an agricultural product linked to an environmental attribute is sometimes referred to as a “coupled crop.” For example, at the field level, an environmental attribute is attributed to a particular field and linked to the crop coming from that field (“field coupling”). In some embodiments, a coupled crop is segregated from commodities coming from other fields during the harvest and post-harvest period or only aggregated with production from fields associated with similar environmental attributes. Optionally field coupled agricultural products remain segregated from the initial point of delivery, and in some cases, the remaining supply chain to the end use. In various embodiments, fields may be grouped at the farm level (for example, nearby fields of a single farming operation, fields of one or more farmers that are members of an organization such as a co-op, fields of one or more farmers participating in a single program, such as a program adopting a common standard of farming practices, and linked to the crop coming from those fields (“farm coupling”).

[0035] In another embodiment, an environmental attribute is attributed to a particular region (for example, a supply shed) and linked to the crop acquired from that region (“supply shed coupling”). A supply shed coupled crop is not generally segregated during the harvest or post-harvest period to the point of initial delivery, or throughout the supply chain. Supply shed coupling does not require that the crops and the environmental attributes come from the same fields or even the same farmers so long as both came from the same region. In another embodiment, an environmental attribute may be attributed to more than one region (for example, multiple supply sheds) and linked to the crop acquired from those regions (“multiple supply shed coupling”). In various embodiments, a coupled crop is linked according to the identity or characteristics of an originating organization, for example agricultural production can be linked to agricultural products produced by a particular farmer (where a farmer may be an individual or any variety of formal or informal business entities) or characteristics of an organization (for example, small farming operations, farming operations in Alaska, etc.) (“farmer coupling”).

[0036] In some embodiments, a quantity of agricultural products having quantified environmental attributes are directly used to produce a processed product having a sustainability claim based on the agricultural product's quantified environmental attributes. For example, a producer of pasta purchases wheat produced using agronomic practices associated with sequestration of three metric tons of carbon dioxide equivalent emissions, produces pasta using processes producing one metric ton of carbon dioxide equivalents (for example, Scope 1 emissions), and markets the pasta with a sustainability claim of sequestering two metric tons of carbon dioxide equivalent emissions. The pasta maker would need to have a dedicated system from processing sustainable wheat, if they produced other products using conventionally produced wheat (wheat not associated with quantified environmental attributes, /.< ., not a coupled crop).

[0037] In some embodiments, a quantity of agricultural products having quantified environmental attributes enter the supply stream of an entity (for example, a manufacturer of processed products) and are combined with non-coupled agricultural products. For example, a producer of dog food purchases 1 metric ton of rice produced using agronomic practices associated with quantified water conservation, produces two products A and B, where product A utilizes 1 metric ton of rice. The producer of dog food does not segregate the coupled rice from the conventional (non-coupled) rice in their supply chain, and produces product A, including a sustainability claim of water conservation associated with the quantity of coupled crop purchased.

[0038] In some embodiments, a quantity of agricultural products having quantified environmental attributes is transacted separately from its environmental attribute. For example, a quantity of agricultural products having quantified environmental attributes is delivered to a grain elevator and the product enters an unsegregated supply chain. An environmental credit may be generated relating to the quantification of the environmental attribute (for example, an absolute quantification, an estimate, or a difference from a measured or inferred baseline). The environmental attribute may be transferred to an entity purchasing an uncoupled agricultural product, for example at a geographically distinct location. In some embodiments, the purchased uncoupled agricultural product is the same crop, optionally the same variety, optionally the same quality as the agricultural products having quantified environmental attributes.

[0039] As used herein, a primary processed product of an agricultural product includes at least meal (e.g., soybean meal, cottonseed meal) or oil (e.g., com oil, soybean oil, canola or rape oil, cottonseed oil, lint, dried distillers grains).

[0040] As used herein, maximizing overall value refers to maximizing, e.g., profit, value utility, time cost of money, or maximal money by certain time.

[0041] As used herein, management data refer to any data relating to yield production operations, such as planting dates, harvest dates, inputs, costs of production.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS [0042] Figs. 1A-B illustrate an exemplary manual settlement process.

[0043] Fig. 2 illustrates a system for automated rights management according to embodiments of the present disclosure.

[0044] Figs. 3A-C illustrates an exemplary account creation method according to embodiments of the present disclosure.

[0045] Figs. 4A-4D illustrate contract fulfillment management according to embodiments of the present disclosure.

[0046] Fig. 5 illustrates a method for automated rights management.

[0047] Fig. 6 depicts a computing node according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0048] The US grain merchandizing industry revenue is estimated to be around $95 Billion every year, of which the settlement process is very inefficient and manual. The settlement system is managed by buyers in a complex workflow through legacy systems in an inconvenient process where buyers need to juggle and maintain multiple accounts for each individual farmers, to attend their payment structure needs. They don’t have tools that addresses its problems nor simplify the workflows.

[0049] Despite the digital revolution in systems and algorithms for transaction management, farmers still collect their money through paper checks from buyers. They often don’t have a consolidated view of their finances, and need to manage their collections across multiple buyers.

[0050] Referring now to Figs.lA-B, an exemplary manual settlement process is illustrated. These figures provide a general overview of manual settlement from the moment of delivery to payment, and the key decision that a grower and a buyer have to make.

[0051] After delivery 101, growers (or intermediaries) collect from the buyer a scale ticket 102, which provides proof of delivery. A given grower receives many tickets from many buyers, as growers often execute delivery in segregated loads. Each load can be executed on different days, and are often not linked at the time of delivery with an individual contract. A grower must therefore determine which contract a given delivery satisfies, and then inform the buyer.

[0052] For unpriced contracts 103, a grower must perform analysis 104, determining pricing trends and weighing cashflow considerations before arriving at an actual price 105. Both priced 106 and unpriced 107 deliveries must be further analyzed by the grower to determine how to allocate proceeds (e.g., a grower must determine how much they own, and to whom and must assess cash on hand). [0053] Because farmers sell their crops in different days, in different parcels (volumes), under different pricing structures, each contract carries different price and volume commitments. Therefore, choosing which contract a given delivery should be allocated to 108 becomes an important decision, with an impact on cash generation and tax burden. [0054] In addition to choosing a contract allocation, the grower also needs to choose an account 109 from which the buyer is to pay them. A grower often has several accounts with a buyer (often more than 10). Each account may carry payment information for the grower, as well as multiple additional payees under that same account, each one with a unique bank account and split payment information. Farmers in the US often rent all or part of their fields, and the lease payment structure considers paying the landlords a portion of the gains from harvest. In addition, sometimes farmers operate part or all of their fields with other family members (who either share ownership of the fields or contribute to the production costs). They also need to get paid as they share the proceeds of selling the harvested crops. Growers need to reconcile all of those data and decisions across different buyers, which have their own logic and decision to inform the decision, and then inform the buyer 110.

[0055] There are numerous factors that influence the reconciliation between scale ticket, contract, and account reconciliation. These include:

1. The grower commitments (e.g., volume to deliver, lease, bank debt, partnerships)

2. Optimal timing of collection with regard to cash flow

3. Payment obligations and timing

4. Accounts to which divided payments should be routed

5. The number of open scale tickets

[0056] Key challenges to a manual approach include:

1. A lack of access to data needed to make reconciliation decisions 2. Multiple buyer standard — e.g., some small buyers or coops only give paper receipts, while others provide data through web portals, which required that growers manage different accounts and passwords

3. A lack of aggregated contract data, e.g., outstanding amounts to be fulfilled

4. No unified process for creation and management of accounts with buyers

5. No consolidated ledger across buyers showing total amount settled, ready to settle, or not ready

6. Lack of flexibility on rules and when they are executed

[0057] This approach requires that buyers handle complex, costly operations in order to handle different splits of payments to different payees at different times. Buyers have to invest on building back-office operations 111 (sometimes similar to a small bank) to be able to handle the complexity of growers payments and avoid operations risks. Unlike a small bank, these investments do not provide additional revenue streams to buyers. Commodities merchandizing is a thin margin business, where buyers obtain value by operating massive volume at scale and efficiently.

[0058] As the complexity of accounting and compliance rules grows, types of contract structures also grow (e.g., HTA, NPEs, Accumulators, c/c.). As the total numbers of facilities grows, the payment process complexity grows exponentially. The challenge is even bigger for small to medium merchandizers or coops, who observe their G&A (General and Administrative) expenses grow disproportionately to their volume. This cost of inefficiency makes the market less competitive for a grower, as small to medium merchandizers cannot keep up with the administrative complexities and costs.

[0059] The lack of appropriate systems and a homogenous process across players forces the industry add headcount to these manual systems to attend to customer needs.

[0060] Buyer challenges thus include: 1. Time consuming process to collect and organize farmers account data and split payment preferences, which requires careful handling to avoid errors

2. Lack of systems that integrated the payment with the contracts and farmers payment designation

3. Reporting is complex and takes time

4. Very manual and people intensive process — more people creates more complex structures to take care of that which increases costs

5. Complexity on executing changes when a farmer asks

[0061] To address these and other shortcomings of alternative approaches, the present disclosure provides automated rights management systems and methods.

[0062] Referring to Fig. 2, an exemplary system for automated rights management is illustrated.

[0063] In some aspects, the methods of the present invention include combination of one or more of: a user interface (201); a data store containing payee constraints (202); a data store containing delivery confirmation (e.g., scale tickets, the terms delivery confirmation and scale ticket are used interchangeably) of one or more producers (203); a data store containing one or more executed contracts for the sale of grain (204); an optimization engine for allocation of delivered quantities of commodities to contracts for sale of commodities (205), where optimization maximizes the recognized value to the producer within a set of constraints applied to all or one or more of a producer’s deliveries, contracts, production geographies, or periods of time; an account information store (206); a reconciliation optimization engine (207), where optimization comprises flattening the transaction structure to make the minimum number of transactions in order to make meet the constraints; and payment execution module (208). [0064] The user interface (201) allows for efficient entry, confirmation, modification, and approval of inputs to the system. In some embodiments, the user is displayed on a device of a payee (for example, a farmer, a payee designated by a farmer, or a payee designated by a payee). The terms farmer, grower and producer are used equivalently throughout, and may refer to any business entity (formal or informal) engaged in the production and sale of an agricultural commodity, for example, a grain or oilseed crop. In some embodiments the user interface (201) is used to enter, confirm, or edit payee constraints (202) and or account data (206). In some embodiments, payees designated by a producer may specify their own payment rules. In some embodiments, a first user may designate a second user as a third- party payee. The second user may or may not be an existing user of the system. The designated third-party payee may be sent a request to enter their payment information (such as account information, payment timing, payment amount, a linked production location, a contract, efc.), or confirm payment details entered by a farmer, for example, via a user interface. Verification of third-party payment details may occur one or more times, for example, verification may be requested the first time a third-party payee is designated within the system, every time a third-party payee is designated within the system, after assignment of one or more scale tickets to a contract, after transaction reconciliation, or before payment execution.

[0065] The data store containing payment constraints, also referred to as payee constraints or payment rules, for many producers or other payees (202). Constraints include, for example: designation of payees (for example, a producer may designate that payment be made to one or more third parties, a landlord payee may designated by a farmer may designate payees of amounts paid to the landlord, etc.), priority of payees (for example a producer may designate that payments first be made to a landlord, next to a seed distributor or other input provider, next to a business partner), timing of payment (for example, before or after delivery of physical product, within a current or future calendar or fiscal year), amount or proportion of a payment. For example, a producer may designate that a partner or landlord be paid all or a portion of a payment.

[0066] Payees may designate that certain sets of constraints apply to all or a portion of their production in the absence of other sets of constraints, referred to as “default rules”. In one embodiment, one or more sets of default rules may apply to different portions of a producer’s production. For example, default rules may apply to all production locations owned or operated by a particular producer, partnership relationship, or legal entity (e.g., corporation, limited liability company, etc.); all locations within the same tenancy relationship; all production locations within a particular boundary (e.g., a management zone, a field, township, county, state, country); all production locations enrolled in a program (e.g., a production contract, an sustainability program such as for generation of an ecosystem benefit (e.g., carbon credit, low nitrogen crop, low water crop, e/c.).

[0067] The data store containing one or more executed contracts for the sale of grain (204) is also referred to as the transaction store. The contracts may or may not be priced (for example, deferred pricing or price later contracts) or fully priced at the time of execution (for example, hedge-to-arrive contracts, basis only contracts). The transaction store contains contracts of many producers and buyers. For each executed contract, at least account information and one set of default rules exists for each producer.

[0068] An account information store (206) contains the information necessary to process payments to one or more payees designated in the rules store (202). This may include one or more persons to receive payment, one or more bank accounts identifiers and other payment information for each payee.

[0069] The data store containing delivery confirmation, may also be referred to as the scale ticket store (203). Delivery confirmation contains at least a quantity of product delivered, and optionally may include a quality of the product delivered. Population of scale tickets within the data store can occur by the producer via the user interface 201, for example by entry of the delivery data (e.g., one or more of: the delivery date, quantity, quality, etc.), alternately a user of the interface (for example on a mobile device) may take a picture or video showing verification of a quantity delivered (e.g., a picture of a scale, digital scale ticket, paper scale ticket, etc.), and or otherwise capture or upload the verification using the interface (201). [0070] The optimization engine for allocation of delivered quantities of commodities to contracts for sale of commodities, is also referred to as the scale ticket assignment engine (205). Optimization maximizes the value to the producer within a set of constraints applied to all or one or more of a producer’s deliveries (e.g., scale tickets), contracts, production geographies, or periods of time. Constraints for one or more growers can be retrieved from the scale ticket store (203). In some embodiments, the producer may, via the user interface: assign one or more scale tickets to one or more contracts, assign one or more constraint sets to one or more scale tickets or one or more contracts. In some examples, a farmer may partially assign scale tickets to fulfill a contract and the scale ticket optimization assignment engine assigns the remainder.

[0071] Open contracts for one or more growers can be retrieved from the transaction store (204). Aspects of delivery information (e.g, from one or more scale tickets, or as otherwise designated by a user of the system regarding a particular delivery) that may be the basis for the optimal allocation of deliveries (for example as documented on scale tickets) to contracts, include without limitation: the crop, plant variety, crop production practices, crop quality (e.g, broken kernels, protein content, fat content, carbohydrate content, amino acid or fatty acid profile, ecosystem attribute (e.g., GHG sequestration, GHG emissions abated, nitrogen use attributes, water use attributes), crop quantity, storage location, storage duration, and storage facility type. Aspects of a contract that may be the basis for the optimal allocation of deliveries to contracts include without limitation: a price (for example, cash price, a futures price or basis price), a discount schedule, a delivery date or window, a contract month, a quantity, a crop, plant variety, crop quality, and crop production practices. Other factors affecting optimization include commodity market conditions and expectations. The allocation may be optimized over time (for example, to meet a payment schedule for a payee’s debts, to equalize a payee’s income over time) and or over price (for example, to maximize income, to maximize income during a period of time, to maximize a total return, etc.)

[0072] In some cases, optimizations are applied to a single grower. Optimization of allocation of delivery quantities proceeds from multiple scale tickets of a single grower and allocates those. These optimizations may proceed in parallel between multiple growers. Optimization of payments may implicate multiple growers, and payment rules may therefore be applied and optimized collectively.

[0073] In some embodiments of the methods of the present invention, an optimization of scale tickets to particular contracts can be applied to deliveries of crop produced at any or all production locations owned or operated by a particular producer, partnership relationship, or legal entity (e.g., corporation, limited liability company, efc.); all locations within the same tenancy relationship; all production locations within a particular boundary (e.g., a management zone, a field, township, county, state, country); all production locations enrolled in a program (e.g., a production contract, an sustainability program such as for generation of an ecosystem benefit (e.g., carbon credit, low nitrogen crop, low water crop, etc.); or combinations thereof. In some embodiments of the methods of the present invention, an optimization of scale tickets to particular contracts can be applied to deliveries of crop produced and or delivered during a growing season, a crop year, a calendar day/month/year (or range thereof), a fiscal year, a delivery date (or range), a contract month, or combination thereof. Optionally the optimization of allocation of scale tickets to contracts occurs as scale tickets are populated in the data store, on request of a user of the system (e.g., the producer, a buyer party to all or one or more contracts with the producer, a creditor of the producer, the operator of the system), at a prescheduled periodicity, automatically to optimize the efficiency of the system (e.g., for optimal allocation of computing resources), or automatically upon occurrence of an event (for example a market event, a pricing of a contract, a close of a market day, quarter, delivery window, an algorithmic determination of a probability of a benefit to the producer being increased by immediate allocation).

[0074] In some embodiments, the scale ticket assignment engine produces a matrix of the optimal delivery identifier (e.g., scale ticket) and contract pairings (note that more than one delivery identification may be applied to one contract) and the associated constraint sets of one or more producers. A matrix of the optimal delivery identifier and contract pairing and the associated constraint set of a single producer is that producer’s “initial transaction matrix.” In some embodiments, a farmer’s optimized transaction matrix is displayed with the graphical user interface of a farmer device and a farmer may accept all or part of the initial transaction matrix without change, or edit the transaction matrix. In some embodiments, a buyer’s initial transaction matrix is displayed with the graphical user interface of a buyer device and a buyer may accept all or part of the initial transaction matrix without change, or edit the transaction matrix.

[0075] In various embodiments, a buyer may resolve conflicts manipulating the transaction matrix or by setting additional rules. For example, a buyer can define policy maximum limits for overage or not allow overage at all, in which case a grower would need to renegotiate the price on the volume. Where the buyer does not accept a volume the grower and seller need to negotiate the price. In the case of underage, the buyer may also set a policy. For example, buyers can allow sellers to trigger settlement at 80% of delivery, 90% above, 100%, etc. [0076] A reconciliation optimization engine (207) is connected via a network to at least one of the scale ticket assignment engines (205), the account information store (206), and one or more financial institutions. Reconciliation optimization may include verification and or validation of account information (e.g., account numbers, controlling entity associated with the account, efc.) and payment processing instructions. In some embodiments, the delivery and contract requirements are verified. In some embodiments, validation and or verification occur before account information is entered into the account information store (206), before account information is retrieved from the account information store (206), after account information is retrieved from the account information store (206), or combinations thereof. Validation, in some embodiments, may include sending a test deposit to the specified account. In some embodiments, the reconciliation optimization engine comprises steps of verifying the creditworthiness of a producer.

[0077] Creditworthiness is evaluated, for example, if the producers selected preferences (their payee rules or constraint set) specify that they receive advance payment at the time of delivery. For example, a producer’s constraint set may specify that payment be made before the delivery confirmation (a scale ticket) is associated with a contract, or before a contract has been priced. In some cases, a buyer will advance payment of the expected value of the producer’s open contracts with the buyer or a proportion of the expected value. In some aspects, a credit verification comprises training a credit risk model on prior transaction records, and applying the trained model to prior transaction records of a payee and or open contracts of a producer. In some aspects, a credit verification comprises accessing a credit report generated by a bank or other financial institution.

[0078] In some embodiments, the reconciliation optimization engine retrieves one or more initial transaction matrices. The optimization engine reduces the initial transaction matrices to an efficient set of transaction instructions which minimize the number of transactions necessary to execute payments for the delivered products based on the obligations of the contracts and associated constraint sets.

[0079] In some embodiments, an optimized transaction matrix is displayed with the graphical user interface of a user’s (for example, a producer’s or buyer’s) device and the user may accept all or part of the optimized transaction matrix without change, or edit the transaction matrix.

[0080] In various embodiments, the systems and methods provided herein are integrated into an overall marketplace platform including an app. In exemplary embodiments, the combined platform may perform tasks including:

1. Onboarding

2. Account Management

3. Contract Fulfillment Management

4. Settlements Execution

5. Growers Money Transfer

[0081] These tasks reflect a full customer journey through an overall platform.

[0082] During onboarding, a buyer integrates with the platform via an API and performs ERP integration. Deployment starts with a merchant who owns the growers’ customers and their data. As first steps Merchants integrated with the platform APIs and integrates their ERPs using those APIs.

[0083] Buyers may send a link to their growers to download the app, or functionality may be provided via other apps through API integration. Buyers may send an email notifying their growers about the platform functionality now available, and the grower will be prompted to download an app, or will be provided a notification that new functionality is enabled in an existing app. [0084] Grower may then download the app and create an account, or opt-in to the new functionality in an existing app.

[0085] Referring now to Figs. 3A-C, an exemplary account creation method is illustrated.

[0086] At 301, grower create account occurs. A grower downloads the app and creates an account or access a pre-existing platform account.

[0087] At this stage, the platform needs the following metadata from the grower, to be able to pull their accounts with the buyers:

• Name

• Entity Name

. TIN

• Address

• Phone

• Email

[0088] At 302, grower buyer account information is connected. Based on the grower identification data, the platform accesses Merchandize^ s) ERP systems to pull all their account data.

[0089] In various embodiments, the metadata include:

• Account(s) ID(s)

• Payment category ( check of transfer)

• Linked Bank Accounts(s) o Linked Related Individuals Name(s)

• Linked Related Individuals Name(s)

[0090] At this stage, the platform connects all available Payment data the Merchandizer have stored in their databases. That information normally comprises Accounts ID(s) which is how the corresponding grower account information is uniquely identified in merchandizers ERP. For some Merchants, the Payment category is one of the accounts attributes as not all growers have bank accounts registered with them and linked to the accounts, as they want to be paid with manual paper checks. For most of the Account information, growers Bank Account information is linked. The bank account information may or may not be from the grower themselves. Sometimes, the linked bank account is from another Related Individual, which normally have a share on the settlement proceeds.

[0091] At 303-A, growers see and manage (CRUDE functions - create, edit, delete) payment account settings information. Once connected to their accounts, growers will have CRUDE functions over their Payment Account information. They are able to see all of their account data information from multiple merchandizers, and delete, edit or create new information.

[0092] At 303-B, when a grower performs any action from create, delete or edit the platform connects back to a Merchandizers ERP to write back the data that was managed by the grower.

[0093] In various embodiments, metadata at this stage include:

• Account Name

• Associated Individual Names under Account

• Split Payment preference by Individuals

• Associated Individuals Bank Account Information

• Associated Individuals Phone number

• Associated Individual Address/ZIP code (-> mandatory in case the payment preference for individual is Paper check, zipcode is mandatory in case the payment preference for individual is credit card)

• Associated preference of Related Individual o Paper check o Wire Transfer o Pay+ Credit o Credit Card

[0094] At 304, a grower can opt-in to link external accounts to the platform in order to enjoy additional analytics about margin, cashflow analysis and financial metrics. In various embodiments, growers not only can manage and see the settlement status of their contract, but they can enjoy enhanced analytics features that show useful information about their cashflow projections, expected margin and other financial metrics.

[0095] Referring to Figs. 4A-4D, contract fulfillment management is illustrated according to embodiments of the present disclosure.

[0096] In Fig. 4A, a grower sells grains to Merchandize^ s) and the platform provides contract status. Growers sell their crops to multiple merchandizer(s) and different time of the year. When they sell, contracts are generated that are stored in the Merchandizer systems. The platform acquires the contract information, either direct from Merchandizing ERP system or when they are executed inside the platform. A record of contract attributes is stored in the DB and data is processed in the front end to provide to Growers showing their equivalent basic attributes and settlement Status.

[0097] In various embodiments, the Contract Settlement Status is selected from:

1- Open (Unpriced) — contract is partially priced or fully unpriced and grain was not delivered.

2- Open (Priced) — contract is fully priced and grain was not delivered.

3-Partially Fulfilled (Priced) — contract is fully priced and grains was partially delivered (a scaled ticket was applied to it)

4- Fulfilled (Ready to be settled) — contract is fully priced and grain volume was fully delivered, meaning scale tickets were applied to it. 5- Settled — contract was settled and money paid. ST cannot be applied to this contract anymore.

[0098] In some embodiments, a contract can only be considered ready to settle when the two following conditions are met:

1- Contract is fully priced.

2-A corresponding volume of scale tickets (in bushels) are assigned and matching to the total contract volume.

[0099] In Fig. 4B, a grower delivers physical grains and scale tickets are generated and made available on the platform. After selling a contract, a grower delivers the correspondent volume to the Merchandizer silo. The proof of delivery and action triggers the creation of a scale ticket, which is a receipt generated from the merchandizer scale with the time, hour, crop and volume. The Scale Ticket is normally generated by a software linked with the merchandizer scale and fully integrated and stored in the Merchandizer ERP. When a scale ticket is generated and stored in ERP the platform retrieves the associated data, linking back to the grower account and showing the available Scale Tickets IDs and information back to grower’s app.

[0100] In various embodiments, the metadata include:

• Scale Ticket ID

• Merchandizer Name

• Volume

• Crop Type

• Date and time

[0101] The Scale ticket metadata are also checked to see if they are applied to a contract or not. In various embodiments, a scale ticket (ST) - contract link may have an associated status selected from: Unapplied — a Scale Ticket was not applied to a contract

Applied — a Scale Ticket was applied to a contract.

[0102] At this stage the Scale Ticket will be immediately made available into the app, as the APIs may be used to sync with the ERP.

[0103] In cases where the grower delivered but the ST is not available in the APP, it may be that the ERP system has failed to generate the ST or has fallen out of sync with the platform. In such cases, when the grower has delivered the Grain but can’t find the ST in the app, they can open up a claim in the app. They may then be asked to manually upload, by taking a picture of the ST that was delivered to him upon delivery. If the grower has lost the ST, they will be asked to fill a form with the data about the delivery so the buyer can search and resolve the issue. In either case, the buyer will receive an email with the notification and they can approve or reject the claim. To approve, the buyer will be asked to confirm or fill the ST data form that will feed back into the system and then it will made available to the grower.

[0104] In Fig. 4C, scale ticket assignment to contracts is illustrated. Once the Scale Ticket is available they can be assigned to a contract. In some embodiments, Scale Tickets can only be assigned to contracts with a status of open or partially fulfilled. For scale tickets that are unpriced, the ST can be assigned (which means a physical delivery obligation under that contract was fulfilled) but until pricing happens, they cannot be settled. A grower can assign the ST any time they want, but the action is considered permanent, which means that a ST cannot be un-assigned by the grower in case they changed their mind. A ST may or may not match a contract volume obligation in full. A grower can accordingly assign several ST to a contract. In the case of overages or underages, the contract will calculate the balance, which can be positive or negative. The grower may be provided the option to close the contract or extend the pricing conditions of a given contract to the excess volume. [0105] The Merchandizer in that case will define which are those conditions and rules of overage and underage that a grower can self-service manage. In case the overage volume exceeds the pre-defined limits stablished by a merchandizer, the grower will not be able to assign the excess volume to any existing contract and will need to execute a new contract with the merchant. In case of underage, the grower will not be able to settle the contract and the settlement status will remain pending until the grower resolve with the buyer either by delivering the volume or washing out the previous contract.

[0106] In Fig. 4D, updating of the settlement and cash analytics dashboard is illustrated. Once an ST is assigned , the contract settlement status is automatically updated. The information is made available to the grower in a consolidated dashboard, which contains useful and advance analytics view in connection with the total cash view from their contracts. [0107] Each contract settlement status is displayed. In exemplary embodiments, a portfolio view provides a global display, by buyer, by crop, or by futures reference. An individual view provides contract level status.

[0108] Referring to Fig. 5, a method for automated rights management is illustrated. At 501, a plurality of delivery confirmations for a product are received. At 502, each of the plurality of delivery confirmations is allocated among one or more contracts of sale, each of the one or more contracts of sale indicating at least a payor. At 503, proceeds of the one or more contracts of sale are determined based on the allocation. At 504, a plurality of payment rules is read, each payment rule indicating at least a payee. At 505, based on the proceeds of the one or more contracts of sale and the plurality of payment rules, a transaction list is constructed that minimizes the total number of transactions among the payors and payees. [0109] Referring now to Fig. 6, a schematic of an example of a computing node is shown. Computing node 10 is only one example of a suitable computing node and is not intended to suggest any limitation as to the scope of use or functionality of embodiments described herein. Regardless, computing node 10 is capable of being implemented and/or performing any of the functionality set forth hereinabove.

[0110] In computing node 10 there is a computer system/server 12, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

[0111] Computer system/server 12 may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server 12 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0112] As shown in Fig. 6, computer system/server 12 in computing node 10 is shown in the form of a general-purpose computing device. The components of computer system/server 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory

28 to processor 16.

[0113] Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, Peripheral Component Interconnect (PCI) bus, Peripheral Component Interconnect Express (PCIe), and Advanced Microcontroller Bus Architecture (AMBA).

[0114] Computer system/server 12 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server 12, and it includes both volatile and non-volatile media, removable and non-removable media.

[0115] System memory 28 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and/or cache memory 32. Computer system/server 12 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system 34 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to bus 18 by one or more data media interfaces. As will be further depicted and described below, memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the disclosure.

[0116] Program/utility 40, having a set (at least one) of program modules 42, may be stored in memory 28 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules 42 generally carry out the functions and/or methodologies of embodiments as described herein.

[0117] Computer system/server 12 may also communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24, etc.; one or more devices that enable a user to interact with computer system/server 12; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server 12 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces 22.

Still yet, computer system/server 12 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter 20. As depicted, network adapter 20 communicates with the other components of computer system/server 12 via bus 18. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server 12. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc. [0118] The present disclosure may be embodied as a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.

[0119] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD- ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiberoptic cable), or electrical signals transmitted through a wire.

[0120] Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

[0121] Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user’s computer, partly on the user’s computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0122] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

[0123] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

[0124] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0125] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0126] The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

CLAIMS What is claimed is:

1. A method of automated rights management, comprising: receiving a plurality of delivery confirmations for a product; allocating each of the plurality of delivery confirmations among one or more contracts of sale, each of the one or more contracts of sale indicating at least a payor; determining proceeds of the one or more contracts of sale based on the allocation; reading a plurality of payment rules, each payment rule indicating at least a payee; based on the proceeds of the one or more contracts of sale and the plurality of payment rules, constructing a transaction list minimizing the total number of transactions among the payors and payees.

2. The method of claim 1, wherein each of the plurality of delivery confirmations comprises a scale ticket.

3. The method of claim 2, wherein the scale ticket indicates a quantity of product delivered.

4. The method of claim 2, wherein the scale ticket indicates a quality of product.

5. The method of claim 1, wherein the product is an agricultural product.

6. The method of claim 1, wherein the product is an ecosystem attribute.

7. The method of claim 1, wherein the product is a coupled agricultural product and an ecosystem attribute.

8. The method of claim 5, wherein the agricultural product is a grain, oilseed, or primary processed product thereof.

9. The method of claim 1, wherein allocating each of the plurality of delivery confirmations among the one or more contracts of sale comprises optimizing allocation based on overall value.

10. The method of claim 9, wherein said optimizing comprises maximizing overall value while conforming to one or more constraints.

11. The method of claim 9, wherein said optimizing comprises maximizing cashflow while conforming to one or more constraints.

12. The method of claim 11, wherein said optimizing cashflow comprises maximizing cashflow over a period of time specified in a one or more producer payment rules.

13. The method of claim 9, wherein said optimizing comprises maximizing value over a period of time specified in a one or more producer payment rules.

14. The method of claim 1, wherein allocating each of the plurality of delivery confirmations among the one or more contracts of sale comprises obtaining farm management data for the production area of the delivered product.

15. The method of claim 14, wherein the farm management data comprises current, historical, or current and historical data related to the production location of the agricultural product.

16. The method of claim 14, wherein the farm management data comprises one or more of production locations, field boundaries, management zones, planting dates, harvest dates, agricultural practices, agricultural practice dates, inputs, input costs, equipment type, equipment run time, and costs of production.

17. The method of claim 10 or 11, wherein the one or more constraints comprise product characteristics required to meet a contract of sale.

18. The method of claim 17, wherein the product characteristics comprise humidity, quantity of breakage kernels, kernel size, color, test weight, no foreign material, protein level, oil content, milling quality, and /or hardness.

19. The method of claim 1, wherein constructing the transaction list comprises generating a data structure reflecting a plurality of transactions, each having a payor and a payee.

20. The method of claim 19, wherein the data structure is a matrix or a directed graph.

21. The method of claim 20, wherein constructing the transaction list comprises simplifying the data structure to reduce the number of transactions while conforming to one or more constraints.

22. The method of claim 21, wherein simplifying the data structure comprises bin packing, clusterization, random forest, subset sum, or min-cost flow.

23. The method of claim 1, wherein allocating each of the plurality of delivery confirmations among one or more contracts of sale comprises determining if the set of one or more contracts is eligible for allocation of a scale ticket.

24. The method of claim 23, wherein contracts are eligible for allocation when a contract pricing structure has been applied to the some or all of the amount of the product to be delivered under a contract.

25. The method of claim 23, wherein contracts are eligible for allocation when the amount of delivery confirmations previously applied to the contract are less than the total amount of the product to be delivered under the contract.

26. The method of claim 23, wherein contracts are eligible for allocation when the amount of delivery confirmations previously applied to the contract are less a threshold amount in excess of the volume of the product to be delivered under the contract.

27. The method of claim 23, wherein contracts are eligible for allocation when the amount of product specified in delivery confirmations previously applied to the contract are less than the total volume of product to be delivered under the contract and more than a threshold amount in less than the volume of the product to be delivered under the contract.

28. The method of claim 23, wherein contracts are eligible for allocation when allocation when the amount of product specified in delivery confirmations previously applied to all contracts between payor and producer are equal to the total volume of the product to be delivered under all the contracts, and the volume of delivery confirmations applied to at least one of the contracts between payor and producer is less a threshold volume in excess of the volume of the product to be delivered under the contract.

29. The method of claim 1, wherein reading the plurality of payment rules comprises determining a priority of execution of payment rules.

30. The method of claim 29, wherein producer payment rules that conflict with third- party rules are canceled.

31. The method of claim 29, wherein third-party payment rules cancel conflicting payee payment rules and payee payment rules cancel conflicting producer payment rules.

32. The method of claim 25, wherein a full or partial overlap between payor payment rules and producer payment rules or payor payment rules and third-party rules trigger a request for modification of producer payment rules be sent to the producer.

33. The method of claim 27, wherein a full or partial overlap between payor payment rules and third-party rules trigger a request for modification of producer payment rules be sent to the payor.

34. The method as in either claim 28 or 29, wherein the contracts to which the conflicting rules apply are removed from the allocation.

35. The method as in either claim 30 or 31, wherein the request for modification of producer rules comprises the set of potential modifications permitted under the conflicting rules.

36. The method of claim 1, a plurality of payment rules comprises payor payment rules.

37. The method of claim 36, wherein at least one of the payor payment rules comprises one or more accepted method of payment.

38. The method of claim 37, wherein the one or more accepted method of payment comprises one or more of a paper check, a wire transfer, a credit card, and peer-to-peer payment and money exchange.

39. The method of claim 1, wherein a producer’s global payment rules are consolidated with the producer’s contract specific payment rules if the rules are not in conflict.

40. The method of claim 1, wherein a producer’s contract specific payment rules replace the producer’s conflicting global payment rules for the contract to which the contract specific payment rules apply.

41. The method of claim 1, wherein the reading a plurality of payment rules is performed before allocating each of the plurality of delivery confirmations among one or more contracts of sale.

42. The method of claim 11, wherein the one or more constraints additionally comprise the plurality of payment rules.

43. The method of claim 1, wherein the method additionally comprises receiving, for each of the one or more contracts of sale, verification of a type of agricultural product, a price of agricultural product, and a producer of an agricultural product for each contract from the payor of that contract.

44. The method of claim 1, wherein the method additionally comprises receiving, for each of the one or more contracts of sale, verification of a type of agricultural product, a price of agricultural product, for each contract from the producer of the agricultural product of that contract.

45. The method of claim 43 or 44, wherein receiving verification comprises using one or more API.

46. The method of claim 1, wherein reading a plurality of payment rules comprises reading payment rules from an electronic system of a payor.

47. The method of claim 1, wherein reading a plurality of payment rules comprises reading payment rules from an electronic system of a producer.

48. The method of claim 1, wherein reading a plurality of payment rules comprises reading payment rules from an electronic system of a third-party other than a payor or producer.

49. The method of any one of claims 46 to 48, where the payment rules are accessed automatically via an API.

50. The method of claim 1, wherein the method is initiated automatically upon receipt of at least one delivery confirmation and determination that at least one contract is open for allocation.

51. The method of claim 1, wherein the method is initiated automatically at least once a minute, at least one an hour, at least once a day, at least once a week, at least once every two weeks, at least once a month.

52. The method of claim 1, wherein the method further comprises subsetting the transaction list by payor.

53. The method of claim 1, wherein the method further comprises aggregating the transaction list by payor to compute the total amount to be paid by payor to all payees, generating a payment schedule corresponding to the transaction list for each payor, and a ledger of each payor’s contracts that are fully or partially satisfied by the transaction list.

54. The method of claim 1, wherein a delivery confirmation is an image of a physical scale ticket.

55. A system comprising: a computing node comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor of the computing node to cause the processor to perform a method according to any one of claims 1 to 54.

56. The system of claim 55, wherein the system is not collocated with a payor or producer.

57. A computer program product for automated rights management, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to perform a method according to any one of claims 1 to 54.