WO2001089285A2 - Methods and apparatus for developing an optimized livestock production plan, for automatically executing commercial transactions in support thereof and for analyzing economic factors pertaining thereto - Google Patents

Description

METHODS AND APPARATUS FOR DEVELOPING

AN OPTIMIZED LIVESTOCK PRODUCTION PLAN,

FOR AUTOMATICALLY EXECUTING COMMERCIAL

TRANSACTIONS IN SUPPORT THEREOF

AND FOR ANALYZING ECONOMIC FACTORS

PERTAINING THERETO

RELATED APPLICATIONS

This patent claims priority from U.S. Provisional Application Serial No. 60/205,405 which was filed on May 19, 2000.

FIELD OF THE INVENTION

The invention relates generally to animal production, and, more particularly, to methods and apparatus for developing financial and/or

production information of interest to an animal producer, suppliers to an animal producer and/or buyers from an animal producer.

BACKGROUND OF THE INVENTION

Although certain technological advances have placed tools for

increasing the efficiency of animal production systems at the disposal of

animal producers, at present the animal production industry is still

characterized by information shortages and delays that inevitably lead to non-

optimal decision making. To explain this point, FIG. 1 illustrates the ingredient purchasing process typically performed by current animal

production systems. The typical animal producing entity includes one or more purchasing

agents and one or more nutritionists. As part of his/her responsibility, the

purchasing agent will telephone outside vendors of ingredients (e.g., amino acids, antibiotics, corn, etc.) to obtain pricing information. These telephone 5 calls can occur at varying time intervals (e.g., daily, weekly, monthly, or on an as-needed basis, etc.) whose frequency is largely left to the purchasing agent's discretion.

The pricing information developed by the purchasing information is typically recorded in some fashion. The animal production system typically

10 includes an electronic data storage device such as a hard drive on a personal computer or a networked server where the ingredient pricing information is stored. This database is occasionally updated by the purchasing agent. Again, the frequency at which these updates occur is largely left to the discretion and

time availability of the purchasing agent, which, in reality, means that

-. j sometimes substantial time lags occur between the time when new pricing information is received by the purchasing agent and the time when that information is reflected in the ingredient prices database. In current systems, the least cost formulation (LCF) databases allow for only one price for an

ingredient (typically the spot price for delivery as soon as possible). In reality,

0 most ingredients are purchased over time and at future points in time. As a

result, prices may be very different from the spot delivery price. The animal production system also includes two other databases of

interest here, namely a nutrient profile database and a nutrient requirements

database. The nutrient profile database is typically informally developed by

the nutritionist based upon information he/she culls from various sources of information concerning average ingredient compositions. For example, if the animal production system has fed com in the past, the nutrient profile database will typically include an entry for com which reflects the typically nutritional composition of that ingredient in percentages (e.g., 3% fat, 2% protein, etc.). Unfortunately, this nutrient database is typically less scientific than it could be

if accurate and current information was available in that it includes an

incomplete list of possible ingredients and it is usually limited to average data for generic ingredient types (e.g., com, bone meal, etc.) that may very well be inaccurate for the actual ingredient purchased and used by the animal producer. Moreover, not only is the data in the nutrition database inaccurate, but it is typically infrequently updated as new information becomes available.

To address some of these issues, the nutritionist may be permitted to adjust the data in the nutrient profile to allow for the variances between the average ingredient and the ingredient actually received. This flexibility is, however,

based on educated guesses made on historical data and experiences that may or

may not reflect actual future occurrences.

The nutrient requirements database is also usually informally

developed by the nutritionist. It typically includes entries for each type of animal grown by the animal producer (e.g., chicken, cow, etc.) and

corresponding nutrition requirements of each such species (e.g., fat, amino

acids, protein, etc.) broken down on a growth stage basis. This data can be

"average" data taken from various sources (e.g., the U.S.D.A.) reflecting the optimum requirements for the animal in question (e.g., the average chicken, the average cow). The data is not tailored to seasonal differences, does not reflect husbandry differences, and is not inclusive of the latest research. Like

the nutrition profile database, the nutrition requirements database is infrequently updated, often fails to reflect the most recent data, and frequently uses "average" data that inaccurately corresponds to the actual animals being

grown. To counter the latter issue, the nutritionist may have the ability to adjust the nutrition requirements data based on his/her experience, but again,

such adjustments are based on historical data and experiences that may not reflect actual future occurrences.

The animal producer system usually includes a least cost formulation program which is run on a personal computer or networked server with access to the nutrient profile database, the nutrient requirements database and the

ingredient prices database. Examples of such least cost formulation programs

include the commercially available program sold under the tradename

BRILL™ and the program described in Liu et al., U.S. Patent 5,668,718 which

is hereby incoφorated herein by reference in its entirety. The least cost formulation program accesses the data in the database

and performs mathematical calculations to produce ration reports reflecting a

schedule of ingredients to purchase. The ingredients identified in the ration reports are selected based on cost and nutrition requirements. The nutritionist will typically review the ration reports developed by the least cost formulation program, adjust them if he/she thinks it appropriate, and forward the finalized reports to the purchasing agent.

The purchasing agent will then place purchase orders with outside vendors for the desired ingredients based upon the ration reports and upon inventory and pipeline reports indicating ingredients on hand and ingredients

purchased but not yet delivered. Because of the delays in updating the ingredient pricing database and the delays inherent in producing, reviewing

and delivering ration reports to the purchasing agent, the least cost formulation program will optimize based on prices that no longer prevail in the actual marketplace and, thus, the ration reports may not actually reflect the lowest cost combination of ingredients by the time the purchasing agent places the orders. If such is the case, the animal producer purchasing the ingredients may

not be able to purchase one or more ingredients at volumes reflected in the

least cost formulation program and will not optimize its profit margins. A

similar failure to optimize can occur if the data in the nutrient profile database

and/or the data in the nutrient requirement database proves inaccurate. In the latter case, profit margins can shrink because animal outputs undeφerform

when provided with sub-optimal ingredients from a nutrition standpoint.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic illustration of a prior art animal producer system.

FIG. 2 is a schematic illustration of an exemplary system constructed in accordance with the teachings of the instant invention.

FIG. 3 is a chart illustrating exemplary quality trait data for example

ingredients. FIG. 4 is a chart illustrating exemplary nutritional requirement and performance characteristic data for example animals.

FIG. 5 is a more detailed schematic illustration of portions of FIG. 2. FIG. 6 is a more detailed view of FIG 5. FIG. 7 is a flowchart illustrating an exemplary program for

implementing the apparatus of FIG. 5.

FIGS. 8a-8b are flowcharts illustrating an exemplary program for implementing the production planner of FIG. 5.

FIG. 9 is a flowchart illustrating an exemplary program for

implementing the nutrition planner of FIG. 5.

FIG. 10 is a flowchart illustrating an exemplary program for

implementing a portion of the optimizer of FIG. 5. FIGS. 11 A- 1 IB are flowcharts illustrating an exemplary program for

implementing a second portion of the optimizer of FIG. 5.

FIG. 12 is a flowchart illustrating an exemplary program for implementing the selling plan controller of FIG. 5. 5 FIG. 13 is a flowchart illustrating an exemplary program for implementing the process bid controller of the selling plan controller of FIG. 5.

FIG. 14 is a flowchart illustrating an exemplary program for implementing the process offer controller of the selling plan controller of FIG.

10 5.

FIG. 15 is a flowchart illustrating an exemplary program for implementing the buying plan controller of FIG. 5.

FIG. 16 is a flowchart illustrating an exemplary program for implementing the process bid controller of the buying plan controller of FIG.

ι5 5.

FIG. 17 is a flowchart illustrating an exemplary program for implementing the process offer controller of the buying plan controller of FIG. 5.

FIGS. 18A-18C are flowcharts illustrating an exemplary program for 0 implementing the nutrition planner of FIG. 6. FIG. 19 is a flowchart illustrating an exemplary program for

implementing the database population module of the feed registration service

of FIG. 2.

FIG. 20 is a flowchart illustrating an exemplary program for

implementing the access controller of the feed registration service of FIG. 2.

FIGS. 21A-21B are flowcharts illustrating an exemplary program for implementing the market monitor of FIG. 5.

FIGS. 22A-22B are flowcharts illustrating an exemplary program for developing economic information across a plurality of animal producers.

DESCRIPTION OF THE PREFERRED EMBODIMENTS A. System Overview

An exemplary system constructed in accordance with the teachings of the invention is shown generally in FIG. 2. Although the system of FIG. 2 employs the Internet as its wide area computer network for communicating

between various entities, persons of ordinary skill in the art will readily appreciate that the teachings of the invention are not limited to use with the Internet or to use with any other particular computer network. Similarly,

although the illustrated system primarily focuses upon animal production,

persons of ordinary skill in the art will readily appreciate that the teachings of

the invention are not limited to any particular environment of use. Additionally, although for ease of discussion, the following description utilizes the example of poultry production, persons of ordinary skill in the art

will readily appreciate that the teachings of the invention are not limited to use

in producing any particular type of livestock, but on the contrary can be

applied to raising any type of livestock including, by way of examples, not limitations, poultry, beef, fish and pork without departing from the scope or spirit of the invention. In keeping with this adaptability, the term animal producer is used throughout to refer to any entity that raises livestock of any type for meat, fish or dairy product sales. In addition to one or more bams or ponds, an animal producer 8 may optionally include one or more initial meat processing facilities (e.g., kill plants) and/or one or more final meat processing facilities (e.g., a sausage making facility or a fish breeding facility).

As used herein, the term "different type of livestock" refers to different breeds, different species, different variants and/or different genotypes of

livestock. As also used herein the term "modified livestock" refers to livestock which has been changed from its naturally occurring condition through either selective breeding, transgenetic modification or both.

In the marketplace today, a number of companies exist which produce and sell genetically engineered and/or quality bred seeds to farmers to produce

crops with various improved quality traits. By way of example, a genetically

engineered and/or quality bred com might have a higher protein content (i.e.,

improved quality trait) than non-improved com. Crops with enhanced quality

traits, whether achieved through breeding or genetic engineering or other techniques are referred to herein as enhanced crops. Companies which

produce seeds and plants (whether enhanced or otherwise) for use in

producing ingredients for animal production are referred to herein as

"ingredient suppliers" 2. However, not all ingredient suppliers 2 produce seeds and plants. For example, both a lender of money and a manufacturer of an antibiotic can also be an ingredient supplier 2. Thus, as used herein, the term ingredient supplier refers to any business that sells a product that is input to an animal production system to produce an animal.

A number of companies also exist in the marketplace for producing improved strains of livestock. Such improved livestock can be produced, for example, by breeding or by genetically engineering animals. By way of

example, a properly nourished, genetically engineered chicken might produce more breast meat than a properly nourished, non-engineered chicken.

Companies which produce livestock (improved strains or otherwise) are referred to herein as "animal stock providers" 4.

In order to achieve acceptance in the marketplace, animal stock providers 4 who sell enhanced strains of livestock have an incentive to provide

animal producers 8 (e.g., ranchers and farmers) with information about the animals they sell. For example, an animal stock provider 4 must convince the

animal producers 8 that its livestock offers advantages over its competitors'

livestock and must also provide animal producers 8 with information as to the nutritional requirements of this livestock. The latter information is important because its livestock has unique nutritional requirements that, if unmet, could

result in sub-optimal output and, possibly, the loss of the advantage provided by breeding or engineering. As a result, animal stock providers 4 currently

provide animal producers 8 with nutritional requirements information in the form of printed literature which often includes nutrition charts. As explained

in the background section of this document, the nutritionist of the animal producer 8 may or may not promptly input this information into a computer

based, least cost formulation program at the animal producer facility for use in developing livestock production plans. Indeed, because the information

delivery process is human dependent, inaccurate and/or stale data is often used by the prior art least cost formulation systems.

Many ingredient suppliers 2 have an incentive similar to the animal

stock providers 4 in delivering information to animal producers 8. For example, similar to animal stock providers 4, each ingredient supplier 2 that sells enhanced crops must convince its potential customers that its enhanced crop(s) offer advantages over the crop(s) of its competitors. As mentioned above, these advantages can lie in the nutritional content of the enhanced crop

or in other quality traits of the enhanced crop. In the past, this information has largely been distributed in the form of printed materials that are delivered to

the animal producers 8. As mentioned above, the nutritionist of the animal

producer 8 may or may not enter this data into their least cost formulation

program in a prompt fashion. Furthermore, prior art least cost formulation tools only capture information about the nutrient content of various

ingredients. They do not account for the impact of non-nutrient attributes on

the performance of an animal. Such non-nutrient attributes could include:

specific mycotoxin level in the grain, presence of an enzyme to aid in digestion, presence of a pigment, etc.

The Internet has provided a means to deliver data and information between entities that far suφasses traditional channels of information delivery. In theory, therefore, the Internet has provided an improved vehicle for ingredient suppliers 2 and animal stock providers 4 to deliver information to

animal producers 8. However, while the Internet provides a channel for communication, it does not, in and of itself, provide an engine for ensuring the right people correspond or for ensuring information is promptly entered into the nutritionists' least cost formulation program. Nor does it provide any mechanism for verifying that the information provided to animal producers 8 by ingredient suppliers 2 and animal stock providers 4 is accurate.

To address these issues, as shown in FIG. 2, the disclosed system proposes the utilization of the Internet to deliver information to animal

producers 8 via a third party ingredient registration service 14. In the simplest

case shown in FIG. 2, the third party ingredient registration service 14 is a

business entity that receives data of interest from animal stock providers 4 and

ingredient suppliers 2 and makes that data available on-line to animal

producers 8. However, in the preferred embodiment, the ingredient registration service 14 also performs a data verification function by testing or

contracting with additional independent third parties to test the products of

ingredient suppliers 2 and/or the products of the animal stock providers 4 to

ensure the accuracy of the data it places on-line. In the latter approach, samples of the products to be listed would be transferred from the subject ingredient supplier 2 or animal stock provider 4 to the ingredient registration service 14 or to other third party testing agencies for testing on a periodic basis to ensure the data listed by the ingredient registration service 14 remains accurate.

Regardless of where the data is developed (e.g., at a provider 2, 4 or at a testing entity), the data stored and placed on-line by the ingredient registration service 14 preferably includes: a) quality trait data indicative of at least the nutritional specifications (e.g., it could also include non-nutrient

attributes such as, for example, mycotoxin level, pigments, enzymes, etc.) of a plurality of different ingredients sold by one or more third party ingredient

providers 2; b) animal nutrition requirements data indicative of the nutrition requirements of animals associated with one or more animal stock providers 4;

and/or c) performance data indicative of a correlation between a listed quality trait (e.g., protein, mycotoxin level, and/or other factors related to the desired

performance attribute (e.g., growth, color, etc.) of the animal) of an ingredient

listed by the registration service 14 and a performance characteristic (e.g.,

breast meat yield) of an animal listed by the service 14. An example chart reflecting exemplary quality trait data for an ingredient is shown in FIG. 3. An

example chart reflecting exemplary nutritional requirements and exemplary

performance characteristic data for an animal is shown in FIG. 4.

Returning to FIG. 2, although the ingredient registration service 14 can be implemented in many ways without departing from the scope or spirit of the invention, in the illustrated system, the service 14 is implemented by one or more servers coupled to the Internet. As schematically illustrated in FIG. 2, the server of the ingredient registration service 14 is programmed to include a database population module 16, an access controller 18 and a revenue module 20. As will be explained in further detail below, the database population module 16 manages the data stored in the database and cooperates with the access controller 18 to deliver data to third parties (e.g., animal producers 8)

and to update the database as appropriate.

As its name suggests, the access controller 18 limits access to the database to persons registered with the service 14. This security control is preferably implemented on at least two levels. Persons with the lowest level

of security clearance can only download data from the database. Animal producers 8 would typically fall into this low level clearance category.

Persons in the second level of security clearance can change data on the

database and/or upload data to the database. Only persons internal to the

ingredient registration service 14 and/or trusted testing agencies would

typically be placed in this category. The first level of security clearance is included to control access to the

data and to ease use of the service 14 and to reduce access time to the

database. In particular, the ingredient registration service 14 includes a large

amount of data. Some of that data is relevant to some animal producers 8 but irrelevant to others. For example, a chicken producer 8 is unlikely to be interested in cattle ingredients, and a cattle rancher 8 in South America will only be interested in cattle ingredients available in his/her geographic region. Accordingly, in the preferred implementation of the ingredient registration service 14, all users of the on-line data are assigned a user registration code (which may optionally be stored on the user's personal computer as a cookie) and are asked to provide certain profile data concerning their business (e.g.,

type of animal producer, location, etc.). Thus, when an animal producer 8 or other user contacts the ingredient registration service 14, the user identification code is used to access the user's profile data (which is preferably stored at the registration service 14 but could alternatively be stored on the user's personal

computer) and the profile data is used to limit the user's access to only data of practical interest. Of course, implementing such a user screen requires coding

of the data stored in the database (e.g., the data must be classified in groups and tagged accordingly, the ultimate information provider such as ingredient

supplier A must supply information to be used in the classification process

(e.g., specify regions where their product is available for sale), etc.)). Although users can browse the data at the ingredient registration

service site 14, preferably the data of interest to a user is downloaded to that

user's local data storage device 22 for later use, for example, in developing a

livestock production plan as explained below. Because the entire database can be substantial, it is preferable to limit the amount of data downloads as much as possible while maintaining data currency on the local storage device 22. To this end, the data in the database is preferably time stamped and a "last download date" is saved in association with each user identification code so that, when a user logs onto the ingredient registration service 14, only new and/or modified data which is relevant to that particular user and which has been placed on-line at a time occurring after the last download performed by

that user will be downloaded to the user's local storage device. In other words, rather than providing the user with a completely new database every

time he/she logs on, the ingredient registration service 14 is programmed to synchronize the user's data with the current data in the database by downloading all relevant changes to the user. Of course, if the user 8 requests a complete download, the service 14 will accommodate him her.

Persons of ordinary skill in the art will readily appreciate that the data

synchronization approach described above is dependent upon the user's

personal computer contacting the service 14 periodically to request a database

update. To ensure the data at the local data storage devices 22 of the users 8

remains current (i.e., the user does not wait too long between requests for updates), the user's personal computer can be programmed to automatically

initiate the synchronization process at predetermined intervals (e.g., every

night at 3:00 AM, etc.). Alternatively, the ingredient registration service 14 can be programmed to function as a "push" type engine which automatically delivers data updates to the users 8 without departing from the scope or spirit of the invention.

As mentioned above, the ingredient registration service 14 is also

provided with a revenue module 20. The revenue module 20 is programmed to charge fees to users utilizing the service 14. For example, the revenue

module 20 is preferably implemented to charge a fee to each ingredient provider 2 and/or animal stock provider 4 for storing the data associated with their product (e.g., ingredient, antibiotic, animal, etc.); a fee to each ingredient provider 2 and animal stock provider 4 for downloading a portion of their data to a user such as an animal producer 8; a fee to an advertiser, and a fee to users (e.g., animal producers 8) for downloading data from the service 14. The fees can be calculated in many ways without departing from the scope or spirit of the invention. For example, the fees can be levied on a data size basis, a

storage time basis, a monthly fee, and/or an access time basis without

departing from the scope or spirit of the invention. Of course, a fee charged to

a party can also equivalently be charged to an agent of a party without

departing from the scope or spirit of the invention. Returning to FIG. 2, the data downloaded to each animal producer 8

effectively forms two or more databases on the local storage device 22,

namely, an ingredient database containing data indicative of possible

ingredients available to the animal producer and data indicative of the nutritional content or rations and other important attributes (e.g., mycotoxin levels) of those possible ingredients, a nutrition requirements database containing data indicative of possible livestock the animal producer can raise and data indicative of the nutritional requirements of that livestock, and a non- nutritional requirements database containing data indicative of possible livestock and data indicative of the non-nutritional requirements of that

livestock. These databases are made available to a computer of the animal producer 8 which is programmed to develop a livestock production plan.

In particular, the animal producer's computer is programmed to receive an input indicative of an objective to optimize. Examples of objectives that an animal producer 8 might select include: a) maximizing profits, b) maximizing production, c) maximizing use of ingredients on hand; d) minimizing use of predefined ingredients (e.g., ingredients having a purchase price above $100

per ton, etc.); e) minimizing use of physical space in defined facilities (e.g., hatchery space, etc.); f) minimizing the number of days until a saleable

product is produced; g) maximizing cash flow; h) maximizing defined facility

(e.g., kill plant, feed mill, etc.) usage; and i) minimizing cost per unit (e.g., per

Kg, per pound) of saleable product. In view of these exemplary objectives, it will be evident to a person of ordinary skill in the art that "optimizing" can be

done toward a maximum and/or a minimum without departing from the scope

or spirit of the invention.

Once the objective is identified, the animal producer's computer selects an animal from the local nutrition requirements database and develops a matrix relating candidate ingredients to the nutritional and, possibly, the non- nutritional requirements of the selected animal by consulting the local ingredient database.

The computer of the animal producer 8 is coupled to the Internet and is programmed to contact one or more on-line exchanges 26 to ascertain realtime pricing information for the ingredients (or nutritional rations as explained

below) in the matrix and for the animal to be produced (preferably both in terms of whole animals and parts of animals). This pricing information can include prices for future points in time (i.e., not just spot prices), which allows the system to optimize relevant decisions for a future time period (i.e., not just the current time period). Another animal will then be selected and the ingredient (ration) identification and pricing process will be repeated until all

possible animals are evaluated. Once the real-time pricing information is

obtained, the computer of the animal producer 8 will evaluate all possible

combinations of animal types and ingredient (or rations) lists against the

objective to develop and identify the production plan which optimizes the objective based on the real-time pricing information. To develop a production plan that is optimized to the specific animal

producer 8 in question, it is necessary to provide the computer of the animal

producer 8 with data concerning the production constraints faced by that

animal producer 8. To this end, the animal producer computer 8 is preferably

provided with access to one or more production constraint databases containing data indicative of: (a) physical production constraints associated with the animal producer (e.g., bam capacity, etc.); (b) physical production constraints of one or more feed processing facilities (e.g., can only process 10,000 chickens in July); (c) current sales commitments associated with the animal producer (e.g., 10,000 chickens by July 1); and (d) current purchase

commitments associated with the animal producer (e.g., 1,000 tons of com under contract and to be delivered to the animal producer July 15). Of course, some of these production constraints can vary as a function of time. For

constraints of this type, the stored data reflects this time dependence. The production constraint data can be manually entered by the animal producer 8 or can be electronically downloaded via a computer network from an on-site computer at, for example, a meat processing facility (e.g., capacity data such

as "capacity to process 5,000 chickens in October") or a hatchery (e.g., "space to grow 3,000 more chicks as of October 1"). In any event, the computer of

the animal producer 8 is programmed to request this production constraint data

to assist in building the production constraint database. Once a livestock production plan is developed by the computer of the

animal producer 8, the plan is output to a nutritionist and/or other business

personnel for approval. If the plan is approved, the computer 8 is preferably

authorized to electronically contract to purchase the ingredients (and/or

rations) identified as needed in the livestock production plan and/or to

electronically contract to sell livestock to be produced via the developed

livestock production plan by contacting one or more on-line exchanges 26 via

the Internet. If the human review of the proposed plan did not interject

significant delay into the process, the computer 8 should be able to execute

contracts to purchase and/or sell at prices close to those determined during the

development of the livestock production plan. If, however, significant market

changes have occurred (e.g., due to delay in the plan review process or

unusually large, short term market fluctuations), the computer is programmed

to abort the contracting process and to develop a new livestock production

plan based on the new prevailing market conditions. Preferably, the computer

executes contracts to buy and sell as a block (e.g., substantially

simultaneously) to reduce the possibility of entering into a contract in one area

and subsequently determining that market changes in another area have

rendered it necessary to reconsider the production plan (which could render

the executed contract unfavorable).

Moreover, the computer of the animal producer 8 is preferably

programmed to continue to electronically monitor the markets 26 for the ingredients purchased pursuant to the livestock production plan. If the

computer detects a change in an ingredient market of sufficient magnitude

(e.g., beyond a predetermined threshold amount), it is preferably programmed

to automatically sell out (e.g., enter into a new contract to sell the original contract or goods that form the subject of the original contract to another entity) of at least one contract to purchase an ingredient and/or to enter into at least one contract to buy a substitute ingredient (which may or may not be the

same type of ingredient that is being sold out of) if possible. In this way, the animal producer computer 8 attempts to minimize costs anαVor maximize

value to the producer 8 on all ingredients up to the time of delivery.

Preferably, the determination of the advisability of changing contractual positions is based on, for example, selling price, nutritional content and/or delivery costs.

With respect to the nutritional content inquiry, the animal producer

computer 8 is also preferably programmed to evaluate whether a market change with respect to one or more ingredients (e.g., a feed such as com) occurring after a contract under a first livestock production plan has been executed for such ingredient(s) is sufficient to make a different combination of

ingredients a lower cost mechanism to provide the same nutrition rations as

the initial combination of ingredients specified by the production plan. If such

is the case, the animal producer computer 8 is preferably programmed to

develop a new livestock production plan based on the new combination of ingredients and to electronically contract to implement that new plan. This

midstream adjustment of the production plan preferably requires human

approval to effectuate.

The illustrated system has many advantages and ramifications that will

be evident to persons of ordinary skill in the art upon reviewing this document.

One ramification of significance is the illustrated system's capacity to create a market for nutrient rations. By way of explanation, in the prior art, the basic commodities of trade purchased by animal producers 8 are ingredients such as

com, bone meal, etc. Each of these ingredients has a nutritional profile comprising a plurality of nutrients (usually reflected on a percentage basis such as 3% protein, 2% oil, 5% amino acids, etc.). The nutrients of an

ingredient are of extreme interest to a nutritionist at an animal producer. Typically, the nutritionist is less concerned which ingredients he/she is feeding the livestock, than that the nutrient values of the ingredients fed meet the nutritional requirements of the animals.

In view of this focus, the present disclosure contemplates the creation

of an on-line market exchange for nutrient rations. This rations exchange 28 (schematically illustrated in FIGS. 5-6) will function like current market

exchanges, with a very significant difference. The new exchange 28 will

function to permit buyers and sellers to contract to buy and sell nutrient rations

which may be standardized to particular genetics and growth stage of animals. In this marketplace, the buyer is less interested in the delivery vehicle (e.g., com or soy beans) than ensuring the nutrient profile he or she requires is met.

As a result, the exchange 28 will post bids to sell nutrient profiles (e.g., 5% or

greater protein, 3% or higher oil, etc.) and/or bids to purchase such nutrient

profiles, and will facilitate matching buyers with sellers of this new commodity which will result in a rations contract (i.e., a contract to purchase a profile of rations).

Once this market 28 is established, the ration exchange 28 will provide an on-line market information source for ingredient providers 2 which will enable them to develop information concerning the desired nutritional content of ingredients in the marketplace. It will assist ingredient suppliers in valuing the products they offer because the rations market 28 will provide information

as to the value of quality traits present in those rations.

B. Detailed Example

1. Terminology and Notation a) Terminology

"Production system" is used to denote the entire physical animal production system being modeled (e.g., hatcheries through further processing).

"Automatically optimized variables" means those variables whose

values may be modified by the optimizer 46. "Discretely optimized variables" means those variables whose values

must be set outside the optimizer 46. Typically these variables are discrete

(non-continuous) variables. b) Notation Scalars variables and functions are denoted by lower case characters,

(e.g., a).

Vector variables and functions are denoted by underlined lower case characters, (e.g., a).

Multidimensional variables and functions (e.g., matrices) are denoted by upper case characters, (e.g., A). f(x,, ..., x„; y„..., y_m) is a function where the values of the variables y ,,..., y_m do not change during computation of the function, but where the

values of the variables x,, ..., x_n may be changed by the function. Specifically, the goal of optimization is to find the values of x,, ..., x_n which optimize (e.g., maximize or minimize) the value of the function.

2. Refresher on Optimization a) Unbounded optimization

The goal of unbounded optimization is, given a function f(x,, ..., x_n),

find those values of the parameters x,, ..., x_n which cause the function to

achieve an optimal value (maximum or minimum). The function may also have parameters (or variables) which are considered fixed, or constant over the

optimization. Such a function is denoted f(x„ ..., x_n; y„..., y_m), where

y,,..., y_m are fixed outside the optimization.

b) Constrained optimization 5 With constrained optimization, constraints are placed on the parameters, or functions of the parameters. For example, equality constraint requires a function of the parameters to satisfy an equality such as

C_j(x„ ..., x_n; y_1;..., y_m) = 0. An inequality constraint requires a function of the parameters to satisfy an inequality such as C^x,, ..., x_n; y„..., y_m) > 0 or

10 C_i(x₁, ..., x_n; y„..., y < 0.

3. System Construction Data Flow

More detailed illustrations of an apparatus 30 for developing a livestock production plan for an animal producer 8 are provided in FIGS. 5

ι5 and 6. FIG. 6 is a more detailed view of the apparatus 30 than FIG. 5 in that it includes additional production constraint databases (e.g., an environmental waste database 32, a feed mill database 34, a food storage capacity database 36, and a kill plant database 38), and an inventory planner 40 (discussed

below).

0 In addition to the inventory planner 40, the apparatus 30 preferably

includes a production planner 42, a nutrition planner 44, an optimizer 46, a selling plan controller 48 and a buying plan controller 50. Apparatus 30 also preferably includes a communication device (not shown) such as a modem for

accessing a computer network such as the Internet to obtain real-time pricing information for ingredients and animals (whole, parts further processed whole

and/or further processed parts). As shown in FIGS. 5 and 6, the apparatus 30 also includes the ingredient database 52 containing data indicative of possible ingredients and data indicative of the nutritional content of the possible ingredients, the nutrition requirements database 54 containing data indicative of possible

livestock and data indicative of nutritional requirements of the possible livestock, and the non-nutritional requirements database containing data associating the possible livestock with data indicative of non-nutritional

requirements of that livestock, all of which were mentioned above. It also includes a production constraint database implemented by a barn database(s) 56, a bird genetics database 58, a processing plant database 60, a hatchery database 62, a current ingredient positions database 64, a current meat positions database 66, environmental waste database 32, feed mill database 34, food storage capacity database 36 and kill plant database 38. As discussed

above, preferably these databases are resident on one or more local storage devices 22 such as a hard drive associated with the computer of the animal

producer 8.

The apparatus 30 also preferably includes a market monitor 67 for

electronically monitoring at least one ingredient market via the computer network. The market monitor cooperates with the electronic selling agent 48,

the electronic buying agent 50 and at least one of: (a) the nutrition planner 44;

(b) the production planner 42; and (c) the optimizer 46 to perform at least one

of selling out of a contract to purchase an ingredient and entering into a new contract to buy an ingredient if a change in the at least one ingredient market merits a modification to the previously developed livestock production plan.

Although the market monitor 67, the inventory planner 40, the production planner 42, the nutrition planner 44, the optimizer 46, the selling plan controller 48 and the buying plan controller 50 are all preferably

implemented by software executing on a personal computer associated with animal producer 8, persons of ordinary skill in the art will readily appreciate that any or all of these components can be implemented by hardware or firmware without departing from the scope or spirit of the invention. An exemplary implementation of each of these components of apparatus 30 will

now be described. a) Production Planner - Description i) Purpose

The production planner 42 constructs a plan for the use of the production system to satisfy production goals. Usage of resources over time is

determined by the production planner 42. To perform this function, the

production planner 42 models the production system capabilities and performs

a flow analysis to ensure that production system capacities are not exceeded. In the case that capacities are exceeded, production goals are modified inside

the planner 42 and a feasible plan is produced for the modified goals. As

shown in FIGS. 5-6, the production planner 42 has access to the barn database 56, the bird genetics database 58, the processing plant database 60 (e.g., kill

plant database 38) and the hatchery database 62. ii) Inputs

The production planner 42 preferably has the following inputs: Total Yield (y).

Mix and type of meat to produce (b_M).

Genetics (b_G).

Delivery schedule (b .

Current production plan for birds already in the production

system.

Production system model data preferably including capability, current state, and established plans for a) feed mills (pelleting capacity, storage, production line restrictions), b) hatcheries, c) bams, d) processing plants, and e) transportation networks.

iii) Outputs The production planner 42 preferably outputs the production plan

which preferably includes:

Final processing quantities and schedule for each processing plant. Distribution from initial processing to final processing plants

including: origination plant, destination plant, quantities and types, and

schedule.

Initial processing quantities and schedule for each initial processing

plant.

Distribution from ba s to initial processing plants including: origination bam, destination plant, quantities and types, and schedule.

Growing schedule and bird production quantities and types for each barn. Distribution from hatcheries to bams preferably including: a) origination hatchery, b) destination bam, c) quantities and types, and d)

schedule.

Hatchery production schedule, quantities, and types.

iv) Note Feed mills preferably are not included in the control flow, under the assumption that normally feed mills are built to service a given set of bams with known capacity. In the case that this assumption is incorrect for a particular application, feed mills can easily be added to the program flow.

b) Nutrition Planner - Description

i) Purpose

The nutrition planner 44 determines a nutrition plan (over time) to

achieve best production. The nutrition planner 44 is in communication with the production planner 42, the ingredient database 52, the nutrition

requirements database 54, and the non-nutrition requirements database 53 for

developing at least one ingredient list for at least one animal selected by the

production planner 42.

ii) Inputs

The nutrition planner 42 preferably includes the following inputs: Production plan including: number of birds to produce, bird genetics, type of meat desired, and growing schedule.

Standard animal nutrition requirements (based on genetics, geography, and other necessary factors).

Ingredient nutrition information. Environmental information (e.g. climate).

iii) Outputs The nutrition planner 42 preferably outputs a nutrition plan comprising a matrix relating candidate ingredients to nutrients and non-nutrient attributes specified in the nutrition plan.

c) Optimizer - Description

i) Purpose

The optimizer 46 cooperates with the production planner 42 and the

nutrition planner 44 to develop a livestock production plan based at least in

part upon real time pricing information retrieved from the on-line exchanges

26 (e.g., meat exchange 70, freight exchange 72, grain exchange 74, currency exchange 76, credit exchange 78 and/or ration exchange 28). The optimizer

46 produces a set of outputs determined to best satisfy a business goal. A business goal can be, for example, to maximize profits, to maximize facility use, etc. The set of outputs of the optimizer 46 is used to drive the production

system, and includes a finalized production plan, a time phased feed plan describing ration formulation from specific ingredients, a buying plan for the ingredients, and a selling plan for the final products. Much of the effort in the optimizer is in formulating the problem statement. Once the problem is stated,

a variety of optimization algorithms is available to produce a solution. ii) Inputs

Time phased nutrition plan (includes quantities). Time phased inventory plan (takes into account cuπent feed inventory and current livestock & consumption plan). Nutrition/ingredient mapping.

Cuπent & future ingredient pricing.

Cuπent & future freight pricing.

iii) Constraints Ingredient storage capacity (over time, if necessary, to take into account storage unavailability (e.g., cleaning)).

Unavailability of ingredients on the market (e.g., offer placed at future

price, but not accepted by anyone). iv) Output

Bid sheet (contains recommended purchasing actions to take,

preferably over time and over ingredients).

Ration plan for all periods (preferably provided for nutritionist approval/override and includes a plan for cuπent period provided to feed mill).

d) Selling Plan Controller Description i) Purpose

The apparatus 30 also preferably includes an electronic purchasing agent for electronically contracting to purchase ingredients identified in the livestock production plan (preferably via a computer network such as the

Intemet). The electronic purchasing agent is implemented in the example of FIG. 5 by the selling plan controller 48. The selling plan controller 48 executes a sales plan, and informs the rest of the system 30 when bids are

accepted, rejected, or unexecutable.

ii) Inputs

The inputs to the selling plan controller 48 preferably include: Sales plan (sales sheet) stating what market positions to take. Meat market offers to buy (type, quantity, asking price, requested

delivery schedule) (i.e., offers placed on market by other parties).

Bid acceptance/rejection (i.e., acceptance/rejection of this system's

bids by the offerers). Meat market bids (coπesponding to output offers to sell) (type,

quantity, asking price, requested delivery schedule) (i.e., bids placed by others

against offers from this system 30). iii) Parameters The selling plan controller 48 requires specification of the time to wait before reporting that a position is unexecutable in the market. iv) Outputs

The selling plan controller 48 preferably has the following outputs: Bids against meat market offers to buy (type, quantity, asking price, requested delivery schedule) (i.e., bids placed by this system 30 against offers

from other parties).

Meat market offers to sell (type, quantity, asking price, requested

delivery schedule) (i.e., offers placed on the market by this system 30).

Accepted bids (i.e., notification to market/bidder that a bid has been accepted by this system; also recorded for other use within this system 30).

Rejected bids (i.e., notification to market/bidder that a bid has been

rejected by this system 30).

Unaccepted offers (i.e., offers placed by this system 30 on the market for which no acceptable bids have been received).

v) Notes

Much of the work of the selling plan controller 48 can be done

concuπently, (e.g., multiple offers/bids can be in process simultaneously). There are multiple well known techniques for handling this concuπent

processing (i.e., multiple "threads", one for each offer/bid running

simultaneously which waits for responses - one continuously looping "thread" polling for responses with a control mechanism for keeping everything straight). For simplicity of explanation, the details of these techniques are not captured in FIGS. 12-14 but are well known by persons of ordinary skill in the art.

Such persons will also appreciate that communications with markets depend upon the market. Online markets typically implement communications in one of two basic ways, namely, data push, or query/response.

In the "push" technique, the market informs other systems of offers,

bids, acceptances, and rejections as they occur, initiating the transmission itself. In the query/response technique, the market waits for queries from the

"client" system (e.g., the animal producer 8), and responds to the queries. For example, a query could be "what are all open offers for purchase of whole birds". Some markets mix the techniques, for example, using data push for notification of accepted/rejected bids, and query/response for all other

transactions. Some markets may not be online and, thus, manual entry of

telephonically related market information may be required (or the information

may be faxed, mailed, ...). For ease of illustration the control flow diagrams

assume use of "data push", but persons of ordinary skill in the art will appreciate that the disclosed system is really not dependent upon this

particular communication mechanism.

Offers and bids can be against combinations of individual products (e.g., breasts and legs combined into one offer/bid).

e) Buying Plan Controller - Description i) Purpose

The apparatus 30 also preferably includes an electronic purchasing agent for electronically contracting to buy ingredients to be used in the livestock production plan (preferably via a computer network such as the Internet). The electronic buying agent is implemented in the example of FIG.

5 by the buying plan controller 50. The buying plan controller 50 executes an ingredient purchase plan, and informs the rest of the system 30 when bids are

accepted, rejected, or unexecutable.

ii) Inputs The buying plan controller 50 preferably has the following inputs:

Buying plan (bid sheet) stating what market positions to take. Ingredient market offers to sell (type, quantity, asking price, requested

delivery schedule) (i.e., offers placed on market by other parties).

Bid acceptance/rejection (acceptance/rejection of this system's bids by

the offerers). Ingredient market bids (coπesponding to output offers to buy) (type,

quantity, asking price, requested delivery schedule) (i.e., bids placed by others

against offers from this system 30). iii) Parameters The buying plan controller 50 requires specification of the time to wait before reporting that a position is unexecutable in the market.

iv) Outputs The buying plan controller 50 preferably has the following outputs:

Bids against ingredient market offers to sell (type, quantity, asking price, requested delivery schedule) (i.e., bids placed by this system 30 against

offers from other parties).

Ingredient market offers to buy (type, quantity, asking price, requested delivery schedule) (i.e., offer placed on the market by this system 30).

Accepted bids (i.e., notification to market/bidder that a bid has been accepted by this system 30; also recorded for other use within this system 30).

Rejected bids (i.e., notification to market/bidder that a bid has been

rejected by this system 30).

Unaccepted offers (i.e., offers placed by this system 30 on the market for which no acceptable bids have been received).

Much of the work of the buying plan controller 50 can be done

concurrently, (e.g., multiple offers/bids can be in process simultaneously).

There are multiple well known techniques for handling this concurrent process (i.e., multiple "threads", one for each offer/bid running simultaneously which

waits for responses - one continuously looping "thread" polling for responses

with a control mechanism for keeping everything straight). The details of

these techniques are not captured in FIGS. 15-17 but are well known by

persons of ordinary skill in the art.

Such persons will also appreciate that communications with markets depend upon the market. Online markets typically implement communications in one of two basic ways, namely, data push, or query/response. In the "push" technique, the market informs other systems of

offers, bids, acceptances, and rejections as they occur, initiating the transmission itself. In the query/response technique, the market waits for queries from the "client" system (e.g., the animal producer 8), and responds to the queries. For example, a query could be "what are all open offers for

purchase of whole birds". Some markets mix the techniques, for example, using data push for notification of accepted/rejected bids, and query/response for all other transactions. Some markets may not be online and, thus, manual entry of telephonically related market information may be required. (Or the information may be faxed, mailed, ...). For ease of illustration, the control

flow diagrams assume use of "data push", but persons of ordinary skill in the

art will appreciate that the technique is really not dependent upon this

particular communication mechanism. Offers and bids can be against combinations of individual products

(e.g. breasts and legs combined into one offer/bid).

f) Inventory Manager Description

i) Purpose The inventory manager 40 maintains a database or databases 64, 66 storing the current inventory position of both meat and ration ingredients, and the plan for deliveries of inventory both into and out of the system. The inventory manager 40 may perform inventory planning on a finer time scale than other system components (e.g., the production planner 42 or the optimizer

46). ii) Inputs The inventory manager 40 preferably has the following inputs: Feed plan (portion of production plan) including ration (ingredients) and schedule. Changes to inventory (can be manual or automatic).

Accepted bids/sales.

iii) Outputs The inventory manager 40 preferably has the following outputs:

Cuπent inventory levels. Current and future meat and ingredient market positions.

Projected future inventory levels. iv) Notes

The inventory manager 40, or a significant portion of it, is optionally

used by the optimizer 46 to assist in constraint checking and in planning

ingredient purchase needs over time. The databases 64, 66 used by the inventory manager 40 may have real time feeds (e.g., silo capacity sensors). Changes to these databases 64, 66 could trigger the inventory manager control flow.

4. System Construction Control Flow Note: for simplicity of notation, time phasing of individual variables will be ignored in the mathematical descriptions below (e.g., to respond to the delivery schedule the need for ingredients varies over time; this is not captured

in the notation.) For completeness, it should be noted that each quantity/function has a time parameter: x(t, ...). Referring to FIG. 7, at block 1 , initial critical variable values are entered into the apparatus either manually, from tables, or via on-line exchanges. In particular, for "empty space" ("empty space" means that bird inventory in progress (growing) is taken into account) in the production

system, the optimizer 46 sets the following initial values of variables: bird

genetics (denoted by b_G), total yield (denoted by y), mix of meat (parts vs.

whole and/or processed or unprocessed) (denoted by b_M), delivery schedule (denoted by b_), and planning window (what time frame to perform planning

over) (denoted by w).

At block 2, starting from the initial critical values, the production

planner 42 produces a production plan (P), which describes the usage of the

production system (resources) and the production of products over time. In creating the plan, some of the input values are modified, while others are treated as fixed parameters. In this example, the input values which are modified are yield (y) and delivery schedule (b.). The input values which are treated as fixed parameters are bird genetics b_G, mix of meat b_M, and planning window w. This can be mathematically stated as P = f,(y, b.; b_G b_M , w, other

production system based parameters).

Input variables whose values are critical assumptions for the production planner 42 are stored for later comparison in block 6. "Critical"

means that if the input value has changed, the production planner 42 might make significant changes in the production plan.

At block 3, the production planner 42 determines the production constraints based on the model of the production system stored in the local

database 22.

k constraints are denoted as C,(^«), ..., C_k(^») Example: maximum amount of feed storage.

At block 4, the nutrition planner 44 determines the nutrition

requirements, and satisfaction of the nutrition requirements by different

ingredients from bird genetics b_G, yield y, mix of meat b_M, delivery schedule b., planning window w, the production plan P, nutrition models, and weather

(climate) information. The output nutrition requirements are denoted by the

vector b_nul. The output ingredient/nutrient satisfaction matrix is denoted by I-,_ut This can be mathematically stated as:

b_nut ⁼ f_.G b_G, y, b_M, b., w, P, other Production System based parameters)

L,_ut ⁼ f₃(. b_G, y, b_M, b., w, P, other Production System based parameters).

Input variables whose values are critical assumptions for the nutrition manager 44 are stored for later comparison in block 6. "Critical" means that if the input value was changed, the nutrition manager 44 might make significant changes in the nutrition plan.

At block 5, the optimizer 46 optimizes the system goal (e.g., profit) over the parameters meat sales (the vector m.), and ingredient purchases (the vector i_b) using the fixed variables b_G, w, b-,.,., L,_ut, and meat and ingredient prices ni_p, i_p, current ingredient inventory i„ and transportation prices i_τ subject to the constraints C,(^»), ..., C_k(«). (Actually, some of these vectors could be a

more complex structure since different quantities of the same ingredient may be available at different prices at different locations). Mathematically this can be stated as: optimize f^rn., k,, y, b_M, b.; b_G, w, b„_ut, L,_ut, m,,, L, i„ P) subject to

C,(-), ..., C_k(.).

At block 6, the optimizer 46 determines if the final values of the

critical variables specified in step 1 have changed. If not, control proceeds to

block 8. Otherwise, control proceeds to block 7. At block 7, the optimizer 46 adjusts the critical variable values.

Control then proceeds to block 2 (i.e., iterate the process). Persons of ordinary

skill in the art will appreciate that there are multiple techniques for adjusting

the variables. Using the values produced in step 5 is the simplest method, but may lead to non-convergence (e.g., the loop never finishes). More sophisticated well known adjustment techniques may also be used (e.g., well known techniques used in gradient search optimization methods).

When control reaches block 8, the optimizer 46 stores the current value of all variables, and the corresponding evaluation value. At block 9, the optimizer 46 determines if all values of bird genetics b_G

have been tested. If so, control proceeds to block 10. Otherwise, control proceeds to block 11.

At block 10, the optimizer 46 sets bird genetics b_G to the next value. Control then proceeds to block 2. Control continues to loop through blocks 2- 10 until all values of bird genetics b_G have been tested. Then control proceeds to block 11.

At block 11, the optimizer 46 reviews all variable sets stored in block 7, and chooses the set with the optimum evaluation value as the optimum

solution and outputs the solution for human review.

If the optimum solution is approved, the sales and purchase plan

controllers 48, 50 explained below are then called to execute the plan. 5. Notes on the System Construction Process

The previous description assumes a start initiated by human agency,

(e.g., someone deciding it is time to plan for October). However, there are other events that can trigger the process. Examples of such events include: a

change in market conditions for meat & ingredients, an unsuccessful acquisition of ingredients, an unsuccessful sale of meat, and an unexpected change to inventory (disease, spoilage, etc.).

There are other processes running asynchronously to the plan construction process which are not shown in FIG. 7. Their impact occurs

through items which are discussed or shown on the data flow diagram (FIGS.

5 and 6). For example, updating of the ingredient nutrition database 52 is not shown, nor are the effects of the buying plan controller 50 and the selling plan controller 48.

In this description, the delivery schedule b. is assumed to be modifiable by the algorithm. However, there are cases when the delivery schedule b. may be considered a constant. For example, when responding to the spot market

the delivery schedule b. may be considered variable (different offers on the spot market with different schedules may be considered for acceptance). But

in the case when the system 30 is being used to analyze the feasibility of

accepting a specific contract offer, the schedule may be unchangeable. The

system 30 preferably allows for either possibility. Interactions of operators/users are not depicted. The process is

intended to run automatically when started, with operator/user override

possible at several points in the process, both between and within steps

depicted in the control flow.

6. Production Planner - Control Flow

An exemplary program for implementing the production planner 42 is shown in FIGS. 8A-8B. The operations illustrated in FIGS. 8A-8B are performed at blocks 2 and 3 of FIG. 7.

When the production planner 42 is called, it first saves the initial values of the critical variables (block 100). The initial values of critical

variables used by the production planner 42 must be saved to support later overall optimization convergence tests in the optimizer 46. These values may have been set by the production planner 42 itself via step 111. This step ensures that the values are stored.

Next, the production planner 42 attempts to allocate the production requirements of the production goals (e.g., yield, meat mix, delivery schedule) to the final processing plants (e.g., sausage making facilities, breading

facilities, etc.). (Block 101). More specifically, it identifies the production

demands to be placed on each of these plants as a function of time and then

compares those requirements to the abilities (e.g., capacity) of the plants to ensure the production plan can actually be accommodated by the final processing plants. If the production planner 42 determines that one or more of

the final processing plants is incapable of meeting the delivery schedule (b_s),

the yield, or other requirements of the plan, control proceeds to block 1 1 1

(FIG. 8A). At block 1 1 1 , the production planner 42 modifies the production

goals and control returns to block 100 where the production planner 42 again

saves the critical variable values and then checks to determine whether the

final processing plants can meet the cuπent production goals (block 101).

Once the production plan is modified such that it falls within the

capacity of the final processing plants (block 101), control proceeds to block

102. At block 102, the production planner 42 determines the supply

requirements for the final processing plants. In other words, the production

planner 42 develops a delivery schedule specifying quantities and timing for

delivering the inputs to the final processing plants (e.g., chicken breasts).

Control then proceeds to block 103.

At block 103, the production planner 42 accesses the processing plant

database 60 to ascertain the production capabilities of the initial processing

plants as a function of time. Based on this information, the production planner

42 attempts to allocate processing requirements under the production plan

being considered to the available initial processing plants. If the production

planner 42 determines that the initial processing plants are incapable of

meeting the demands under the production plan (block 103), control proceeds

to block 1 10. At block 110, the production planner 42 determines if changes in the

allocations to the final processing plants can be made within the cuπent

production plan. If not, control proceeds to block 111 where the production planner 42 modifies the production goals. Control then returns to block 100

where the critical variable values are stored and the process of attempting to allocate production responsibilities to the final and initial processing plants begins anew (block 101).

Returning to block 110, if other (previously untried) allocations to the final processing plants are possible, control proceeds to block 101 where the

production planner 42 redistributes the final processing plant responsibilities as explained above.

If at block 103, the production planner 42 is able to allocate the production requirements of the current production plan to the initial processing

plants, control proceeds to block 104. At block 104, the production planner 42 determines the supply requirements (e.g., quantity, type, and timing) for the initial processing plants. Control then proceeds to block 105.

At block 105, (FIG. 8B) the production planner 42 accesses the bam database 56 and attempts to allocate the production requirements under the

current production plan to the available bams. If the production planner 42

determines that available bam capacity does not meet the requirements of the

current production plan, control proceeds to block 112 (FIG. 8 A). At block 112, the production planner 42 determines whether changes in the initial processing plant allocation are possible within the current production plan. If

so, control returns to block 103. Otherwise, control proceeds to block 110.

Assuming that bams are available to meet the requirements under the current production plan (block 105), control proceeds to block 106. At block

106, the production planner 42 determines the supply requirements (e.g., quantity and delivery dates) for the bams under the current production plan. Control then proceeds to block 107.

At block 107, the production planner 42 accesses the hatchery database

62 to determine if the available hatcheries are capable of meeting the production requirements of the cuπent production plan. If the hatcheries cannot meet the production requirements, control proceeds to block 113 where the production planner 42 determines if other bam allocations can be made under the current production plan. If so, control returns to block 105. Otherwise, control returns to block 112 (FIG. 8 A). If the hatcheries are capable of meeting the production requirements under the current production plan (block 107), control proceeds to block 108.

At block 108, the production planner 42 saves the current production goals and the current production plan. The production planner 42 then determines

system optimization constraints under the newly developed production plan

(block 109). Control then proceeds to block 4 of FIG. 7. 7. Production Planner - Control Flow Notes

Each of blocks 101, 103, 105 and 107 in FIGS. 8A-8B takes into

account facility specific planning (e.g., bird density for bams in block 105). They also normally take into account transportation times. Time phasing is

also taken into account (as implied by delivery dates).

Each block in FIGS. 8A-8B may pass through requirements to a later step (e.g., final processing may pass requirements through to initial processing, indicating that the product is NOT to be delivered to final processing, but to some other location).

Facility databases (e.g., processing plant, bam, and hatchery databases) contain information on the cuπent plan underway for the facilities.

Preferably, a "dismemberment function" in block 103 (and optionally block 101) relates bird size & genetics to product.

Percent yield comes from the processing plant database 60 (e.g. historical numbers).

Preferably, an operator can override variables in the process, although for simplicity of illustration, this interaction is not shown.

8. Nutrition Planner - Control Flow Description An exemplary program for implementing the nutrition planner 44 is

shown in FIG. 9. The operations shown in FIG. 9 are performed at block 4 of

FIG. 7. At block 200 of FIG. 9, the nutrition planner 44 receives inputs from

the production planner 42 which factor into nutrition determination. For

example, the nutrition planner 44 preferably receives data indicative of:

number of birds, genetics, type of meat desired, schedule, and husbandry effects (i.e., density).

At block 201, the nutrition planner 44 saves the initial values of critical variables. The initial values of critical variables used by the nutrition planner

44 must be saved to support later overall optimization convergence tests by the optimizer 46. These values may not be provided directly in the production plan but can be derived from the plan, such as: bird density, grow out days, and grow out weights.

At block 202, the nutrition planner 44 fetches standard nutrition plans from the standard animal nutrition database 54 to form part of the template of the final nutrition plan (for example, carbohydrates, fat, protein, amino acids, vitamins, other nutrients). The nutrition planner 44 also fetches modeling information from the animal non-nutrition database 53 to identify which non-

nutrition components should be used to achieve production goals. These non- nutrition components are added to the final nutrition plan.

At block 203, the nutrition planner 44 gets environmental factors data

(e.g. climate) which can affect nutrition planning. This data can be retrieved

from a database or from externally available systems (e.g., over the Internet). At block 204, the nutrition planner 44 modifies the nutrition plan

template and, optionally, the non-nutritional plan template based upon the

retrieved environmental factors.

At block 205, the nutrition planner 44 preferably allows a nutritionist to manually examine and modify the plan. However, this step may optionally be omitted.

At block 206, the nutrition planner 44 examines the ingredient nutrition database 52 to selectively determine ingredients which supply nutrients and/or non-nutrient components specified in the plan. Selection of

ingredients can be performed by, for example, omitting ingredients which have no or negligible nutrients contained in the plan, ingredients which are not available locally, and omitting ingredients based on any other pertinent selection factors.

At block 207, the nutrition planner 44 constructs an output matrix relating selected ingredients to nutrients, and specifying how much of each nutrient is supplied by the ingredient.

9. Optimizer - Input Data Collection Control Flow Description

An exemplary program for implementing a first portion of the

optimizer 46 is shown in FIG. 10. The program of FIG. 10 implements block

1 of FIG. 7. At block 301, the optimizer 46 queries the operator for an optimization

goal (e.g., maximize profit, maximize usage, etc.). Persons of ordinary skill in

the art will readily appreciate that any of the well known mechanisms for

inputting data can be used to obtain the optimization goal including, by way of examples, not limitations, a menu which can be selected by a point and click device, and a keyboard. Once the optimization goal is input by the operator, the optimizer 46 stores the goal, and control proceeds to block 302.

At block 302, the optimizer 46 requests the operator to input the planning window (e.g., what time frame to perform planning over such as October-December, 2001). Once the planning window is inputted by the

operator, the optimizer 46 stores the data and proceeds to block 303.

At block 303, the optimizer 46 requests the operator to input an initial estimate of the total yield. Once the operator inputs that data, the optimizer 46

stores the total yield and control proceeds to block 304.

At block 304, the optimizer 46 requests the operator to input an estimate of the mix of meat (e.g. whole chickens, breast meat, and legs, etc.). Once the operator inputs that data, the optimizer 46 stores the meat mix data, and control proceeds to block 305.

At block 305, the optimizer 46 requests the operator to input a

proposed delivery schedule. Once the operator supplies that data, the delivery

schedule is stored and control proceeds to block 306. At block 306, the optimizer 46 determines the set of available bird

genetics for producing the desired mix of meat and total yield within the desired planning window. The optimizer 46 performs this step by accessing

the bird genetics database 58. Once the set of available bird genetics is

identified and stored, control proceeds to block 307 where the optimizer 46 selects one bird genetic type from the set of available bird genetics as the initial genetic setting. Control then proceeds to block 2 of FIG. 7.

The foregoing inputs should be made for "empty space" in the production system ("empty space" means that bird inventory in progress

(growing) is taken into account).

10. Optimizer - Optimize Control Flow Description

FIGS. 11 A-l IB illustrate blocks 5-11 of FIG. 7 in greater detail.

Blocks 401-406 correspond to block 5 of FIG. 7. Block 407 corresponds to block 6 of FIG. 7. Block 409 corresponds to block 8 of FIG. 7. Block 410 coπesponds to block 9 of FIG. 7. Block 411 coπesponds to block 10 of FIG.

7. Block 412 corresponds to block 11 of FIG. 7. This process can be triggered by: an operator, an unachieved purchase in the buying plan, an unachieved sale

in the sales plan, a meat/ingredient inventory over/underrun, and/or a

production system "capacity exceeded" condition.

Regardless of the condition triggering the process, at block 401, the optimizer 46 retrieves the plan inputs and constraints. At block 402, the optimizer 46 retrieves the real-time market inputs.

Via this process, the optimizer 46 obtains market information on meat sales

(offers, bids, prices, quantities, delivery schedules) and ingredient purchases (offers, bids, prices, quantities, delivery schedules). Specific offers may be

used in generating goals and the buying and selling plans. This information may also be used at block 403.

Multiple markets may be interfaced to, even for the same product. Each entry contains information about the pertinent market. For example, if

chicken wings are being offered on Market 1 at Price 1, and on Market 2 at Price 2, then there will be two entries for chicken wings, one for each market.

Direct offers are two party arrangements, a buyer and seller. Interaction may be entirely point to point online (e.g., using EDI), through an electronic market, negotiated via other electronic means (e.g., telephone, fax), or even face to face. At block 403, the optimizer estimates the market input(s) where actual data is unavailable. The market information may not definitively cover the

full set of possibilities. For example, quotes for a particular time period may not be available. In this step, holes in the information are preferably filled

with estimated market conditions (either electronically or via human input).

At block 404, all inputs are assigned a function which maps the value

of the input to an evaluation value, (e.g., dollar value). For example, a current

ingredient inventory is assigned a cost, which can include the cost of NOT using the cuπent inventory (the cost may be zero if desired). A (possible)

contract for future delivery of an ingredient is also assigned a value. The risk

of that future position is accounted for in the value assignment (e.g., the

ingredient may be valued at replacement cost, the cost of the future, the cash

price at the same time, and or delivery costs). Mapping of these inputs to a common value scale permits the system to trade off resource usage (e.g., is it better to discard cuπent inventory and use a new ingredient than to use the current inventory?) The mapping of an input to value can merge multiple inputs (for example, the cost of an ingredient may factor in transportation

costs).

At block 405, the optimizer 46 may optionally output the current

variable value to provide the system user with an opportunity to modify those values.

At block 406, the optimizer 46 executes an optimization algorithm. As will be appreciated by persons of ordinary skill in the art, there are many well known algorithms available from the fields of operations research, mathematical optimization, and artificial intelligence which can implement

this step. Because most of the variables are functions of time (e.g., production

plan, nutrition plan), the optimization algorithm must be selected to work with

time-varying variables. One well known technique is to perform optimization

at each point in time, although this usually leads to a solution which is not the

global optimum. At block 407, the optimizer 46 executes a convergence test. This step

is part of a larger overall loop involving the production planner and nutrition

planner (see block 6 of FIG. 7). The convergence test is to determine if the

larger loop has been completed for the current set of initial conditions or if another iteration is required. The test compares the initial values of critical variables to the final values, and determines if significant changes in the values have occuπed. If they have, the process has not yet converged and another iteration through the loop is required via Exit 2, which invokes the previous steps of the process of FIG. 7 on adjusted critical variables. If the process has not converged, control proceeds to block 408. Otherwise, control proceeds to block 409 (FIG. 10B).

At block 408, the optimizer 46 adjusts the critical variables. Since reaching block 408 indicates that the process has not converged, a new set of initial conditions needs to be tried. This step sets those values for the automatically optimized variables. (The automatically optimized variables include: total yield (y), meat mix (parts vs. whole (b^, and delivery schedule (b_s)). Setting the initial values of the variables directly to the current (output) value of the variables is one technique. However, many systems will not

converge using this simplistic logic. Variable update techniques are dependent

upon the optimization algorithm used in block 406. If the process has converged (block 408), the optimizer 46 stores the final evaluation and

variable values indexed by initial values (block 409) (FIG. 1 IB). On the other hand, exit 2 is used from block 408 when the

optimization process has not yet completed (i.e., a different set of initial

variables is to be tried). The next step of the process is to invoke the production planner 42 with the new set of variables (see block 2 of FIG. 7).

Assuming the process has converged, after the variable values are stored (block 409), the optimizer 46 next determines whether there is a need to try new initial conditions (block 410 of FIG. 1 IB). The overall process has converged for the cuπent set of initial conditions, but perhaps not all combinations of discretely optimized variables have been tried (e.g., bird genetics). This block tests for this situation.

If more iterations are required (e.g., the process has converged for the current set of discretely optimized variables, now specify the next set of

variables (e.g., the next type of bird genetics) to optimize), the optimizer 46 adjusts the initial variables at block 411 and the next step of the process is to invoke the production planner 42 with the new set of variables (see block 2 of

FIG. 7). Otherwise, control proceeds to block 412 where the optimizer 46 selects the best plan with the best evaluation.

After the best plan is selected, the operator is given an opportunity to

review and commit to or reject the select plan (block 413). If a commitment is

made to the plan, pertinent parts of the generated plans (e.g., production and

feed plans) are stored in the appropriate databases. If the plan is rejected, the process is aborted at block 413 and the entire process is started over again by

selecting new input data at block 1 of FIG. 7 (i.e., block 301 of FIG. 10).

If a commitment is made to the plan (block 413), the optimizer 46

saves the market conditions (e.g., the ingredient prices) under which the plan 5 was developed for later user by the market monitor 67. The optimizer 46 also

calls the buying and selling plan controllers 50, 48 to access the market and attempt to execute the plan (block 414). If the plan is rejected, the process aborts and the user is offered the opportunity to re-execute using different parameters. 0 Exit 3 is used when the optimization process has completed.

11. Miscellaneous Notes Concerning Optimizer Flow

Note that the nutritionist and the purchaser both have approval authority. This implies that each of them may have cause to rerun the j optimizer 46 after making changes to the input data/parameters. Not shown

on the diagram is the capability for the purchaser to input modifications to prices/availability at any time, not just during the approval process.

12. Selling Plan Controller - Control Flow Description FIGS .12-14 illustrate an exemplary program for implementing the

selling plan controller 48. At block 501, the selling plan controller 48 obtains the sales plan from

the optimizer 46. By way of explanation, the sales plan is a list of meat

products to sell. Each entry in the list identifies a desired selling price. Once the sales plan is obtained, control proceeds to block 508. At block 508, the selling plan controller 48 processes the entries in the sales plan to identify offers to sell in the plan which should be combined into a single, combined entry in the sales plan (i.e., block offer(s)). Once such block offer(s) are developed and the sales sheet modified to reflect their presence,

control proceeds to block 502. At block 502, the selling plan controller 48 retrieves the first entry in the sales plan. The selling plan controller 48 then enters a loop defined by

blocks 503-507 where the selling plan controller 48 processes every bid and every offer in the sales plan. In particular, at block 503, the selling plan controller 48 examines the cuπent entry from the sales plan to determine if it is a bid received from a third party to purchase goods or an offer to sell to be made to the market. If it is a bid to purchase received from a third party,

control proceeds to block 504 where the bid is processed (i.e., attempt to accept offer) in accordance with the flowchart shown in FIG. 13. If the entry

is an offer to sell to be made to the market (block 503), control proceeds to

block 505 where the offer to sell is processed in accordance with the flowchart

shown in FIG. 14. After the bid/offer is processed at block 504/block 505, control

proceeds to block 506. If all entries in the sales plan have been processed,

control returns to block 501 where the selling plan controller 48 awaits arrival

of another sales plan to process. Otherwise, control proceeds to block 507 where the selling plan controller 48 selects the next entry for processing through blocks 503-506.

13. Selling Plan Controller -

Process Bid Control Flow Description At block 511 , the selling plan controller 48 accesses the appropriate online exchange 26 to determine if the offer to purchase associated with the

current entry is still open. If the offer to purchase is not still open, control

proceeds to block 517 where the entry is recorded as a rejected bid. Control then proceeds to block 518 where the selling plan controller 48 optionally

determines if an alternative to the rejected bid exists in the sales plan. If so, control retums to block 506 (FIG. 12). Otherwise, a trigger is sent to the optimizer 46 to reoptimize the plan in view of the market change. The selling

plan controller 48 then stops processing the current sales plan and control returns to block 501 of FIG. 12.

Returning to block 511 of FIG.13, if the selling plan controller 48

determines that the offer to purchase is still open, control proceeds to block

512. At block 512, the selling plan controller 48 forwards a bid to accept the

offer to the relevant online exchange(s) 26. Control then proceeds to block 513. At block 513, the selling plan controller 48 waits for a response from the

relevant exchange(s). If no response is received within a predetermined time,

the selling plan controller 48 times out (block 516) and assumes the bid to sell was rejected. (The selling plan controller 48 may then optionally withdraw the

5 bid by contacting the relevant exchange.) Control then proceeds to blocks 517 and 518 as explained above.

If at block 513, the selling plan controller 48 receives a message from the relevant exchange 26 within the predetermined time, the selling plan controller 48 examines the response to determine if the bid to sell has been accepted (block 514). If the bid is rejected, control proceeds to block 517 where the rejected bid is recorded. If the bid is accepted (block 514), control

proceeds to block 515 where the accepted bid is recorded. Control then returns to block 506 of FIG. 12.

) 14. Notes Concerning Selling Plan Controller Bid Process

This process may be executed against a direct offer as well as a market offer.

A variation of this process would place offers at higher than the plan

price, and if not accepted, place additional offers lowering the price in steps

until an offer is accepted, or, finally, the plan price is offered and accepted or

rejected. 15. Selling Plan Controller -

Process Offer Control Flow Description

At block 522, (FIG. 14) the selling plan controller 48 extends the

current offer (block or single) to the market contacting the appropriate on-line exchange(s) 26.

The selling plan controller 48 then waits for a response for a predetermined length of time (block 523). If the predetermined time expires without a response from the on-line exchange(s) 26 (block 527), the selling plan controller 48 assumes that the offer was not accepted and the selling plan controller times out (block 527). (Optionally, the selling plan controller 48 will then send a message to the on-line exchange 26 indicating that the offer is

withdrawn.) Control then proceeds to block 528 where the selling plan

controller 48 records the rejected offer. Control then proceeds to block 529.

At block 529, the selling plan controller 48 optionally determines whether the selling plan includes an alternative (i.e., a substitute offer to be made in place of the unaccepted offer). If so, control retums to block 506 of

FIG. 12. Otherwise, the selling plan controller 48 sends a trigger message to

the optimizer 46 requesting the optimizer 46 to develop a new optimized livestock production plan based on the new market information (block 529),

and control returns to block 501 of FIG. 12.

Returning to block 523, if a message is received from the on-line

exchange(s) 26 in the predetermined time period, the selling plan controller 48

reviews the message to determine if the received bid to purchase is acceptable (block 524). If the bid is not acceptable, the selling plan controller 48 sends a

message to the on-line exchange 26 rejecting the bid. Otherwise, control

proceeds to block 525. At block 525, the selling plan controller 48 accepts the bid by contacting the on-line exchange 26. Control then proceeds to block 526

where the selling plan controller 48 records the accepted bid. Control then returns to block 506 of FIG. 12.

It should be noted that the bid acceptance inquiry at block 524 can be a

complex decision process if not all of the terms (quantity, schedule) match the offer. The simplest decision is to accept the bid if type, quantity, and schedule match and the bid price is equal to or greater than the asking price. However, persons of ordinary skill in the art will appreciate that other decision models could alternatively be employed without departing from the scope or spirit of the invention.

16. Notes

Offers may be executed as direct contracts as well as market offers. A variation of this offer process would place offers at higher than the plan price, and if not accepted , place additional offers lowering the price in

steps until the offer is accepted, or, finally, the plan price is offered and

accepted or rejected. 17. Buying Plan Controller - Control Flow Description

FIGS. 15-17 illustrate an exemplary program for implementing the buying plan controller 50.

At block 601 , the buying plan controller 50 obtains the buying plan from the optimizer 46. By way of explanation, the buying plan is a list of ingredients to purchase. Each entry in the list identifies a desired purchase price. Once the buying plan is obtained, control proceeds to block 608.

At block 608, the buying plan controller 50 processes the entries in the buying plan to identify offers to purchase in the plan which should be combined into a single, combined entry in the buying plan (i.e., block offer(s)).

Once such block offer(s) are developed and the buying sheet modified to reflect their presence, control proceeds to block 602.

At block 602, the buying plan controller 50 retrieves the first entry in the buying plan. The buying plan controller 50 then enters a loop defined by blocks 603-607 where the buying plan controller 50 processes every bid and every offer in the buying plan. In particular, at block 603, the buying plan

controller 50 examines the current entry from the buying plan to determine if it is a bid to purchase goods from a specific third party or an offer to buy goods

to be made to the market in general (e.g., a request for bids). If it is a bid,

control proceeds to block 604 where the bid (i.e., attempt to accept offer) is

processed in accordance with the flowchart shown in FIG. 16. If the entry is

an offer to buy from the market (i.e., a bid solicitation) (block 603), control proceeds to block 605 where the offer is processed in accordance with the

flowchart shown in FIG. 17.

After the bid/solicitation is processed at block 604/block 605, control

proceeds to block 606. If all entries in the buying plan have been processed, control returns to block 601 where the buying plan confroller 50 awaits arrival of another buying plan to process. Otherwise, control proceeds to block 607 where the buying plan controller 50 selects the next entry for processing through blocks 603-606.

18. Buying Plan Controller -

Process Bid Control Flow Description

At block 611, the buying plan controller 50 accesses the appropriate online exchange(s) 26 to determine if the offer to sell associated with the current entry is still open. If the offer to sell is not still open, control proceeds

to block 617 where the entry is recorded as a rejected bid. Control then proceeds to block 618 where the buying plan controller 50 optionally

determines if an alternative to the rejected bid exists in the sales plan. If so, control returns to block 606 (FIG. 15). Otherwise, a trigger is sent to the optimizer 46 to reoptimize the plan in view of the market change. The buying

plan controller 50 then stops processing the cuπent sales plan and control

returns to block 601 of FIG. 15.

Returning to block 611 of FIG. 16, if the buying plan controller 50 determines that the offer to sell is still open, control proceeds to block 612. At block 612, the buying plan controller 50 forwards a bid to accept the offer to

the relevant online ex change(s) 26. Control then proceeds to block 613. At

block 613, the buying plan controller 50 waits for a response from the relevant

exchange(s). If no response is received within a predetermined time, the

5 buying plan controller 50 times out (block 616) and assumes the offer was no longer open. (The buying plan controller 50 may then optionally withdraw the offer by contacting the relevant exchange.) Control then proceeds to blocks 617 and 618 as explained above.

If at block 613, the buying plan controller 50 receives a message from 0 the relevant exchange(s) 26 within the predetermined time, the buying plan controller 50 examines the response to determine if the bid to purchase has been accepted (block 614). If the bid is rejected, control proceeds to block 617

where the rejected bid is recorded. If the bid is accepted (block 614), control proceeds to block 615 where the accepted bid is recorded. Control then j returns to block 606 of FIG. 15.

19. Notes Concerning The

Buying Plan Controller Offer Process

This process may be executed against a direct offer as well as a market

offer.

A variation of this process would extend bids to buy at lower than the

plan price, and if not accepted, place additional offers raising the price in steps until a bid is accepted, or, finally, the plan price is offered and accepted or

rejected.

20. Buying Plan Controller - Process Offer Control Flow Description

At block 622 (FIG. 17) , the buying plan controller 50 extends the cuπent offer (block or single) to the market by contacting the appropriate online exchange(s) 26.

The buying plan controller 50 then waits for a response for a predetermined length of time (block 623). If the predetermined time expires

without a response from the on-line exchange(s) 26 (block 627), the buying plan controller 50 assumes that the offer was not accepted and the buying plan controller 50 times out (block 627). (Optionally, the buying plan controller 50

will then send a message to the on-line exchange(s) 26 indicating that the offer is withdrawn.) Control then proceeds to block 628 where the buying plan confroller 50 records the unaccepted offer. Control then proceeds to block 629.

At block 628, the buying plan controller 50 determines whether the buying plan includes an alternative (i.e., a substitute for the unaccepted offer

such as a higher priced offer). If so, control returns to block 606 of FIG. 15.

Otherwise, the buying plan controller 50 sends a trigger message to the

optimizer 46 requesting the optimizer 46 to develop a new optimized livestock production plan based on the new market information (block 629), and control

returns to block 601 of FIG. 15.

Returning to block 623, if a message is received from an on-line

exchange 26 in the predetermined time period, the buying plan confroller 50 reviews the message to determine if the received bid to sell is acceptable

(block 624). If the bid is not acceptable, the buying plan controller 50 sends a message to the on-line exchange 26 rejecting the bid and then waits for further bids. Otherwise, control proceeds to block 625. At block 625, the buying plan controller 50 accepts the bid by contacting the on-line exchange 26. Control then proceeds to block 626 where the buying plan controller 50 records the accepted bid. Control then returns to block 606 of FIG. 15.

It should be noted that the bid acceptance inquiry at block 624 can be a

complex decision process if not all of the terms (quantity, schedule) match the offer. The simplest decision is to accept the bid if type, quantity, and schedule match and the bid price is equal to or less than the offered price. However, persons of ordinary skill in the art will appreciate that other decision modules could alternatively be employed without departing from the scope or spirit of the invention.

21. Notes

Offers may be executed as direct contracts as well as market offers. A variation of this offer process would place offers at lower than the

plan price, and if not accepted place additional offers raising the price in steps

until the offer is accepted, or, finally, the plan price is bid and accepted or rejected.

5

22. Inventory Manager - Control Flow Description

An exemplary program for implementing the inventory planner 40 (FIG. 6) is shown in FIGS. 18A-18C. The inventory planner 40 cooperates with the optimizer 46 to ensure that the feed plan associated with the new livestock production plan can, in fact, be implemented given the constraints of

the animal producer 8. To this end, the inventory manager 40 is preferably called to check the new feed plan after block 412 and before block 413 of FIG. 11B.

Turning to FIG. 18A, blocks 700-702 define a monitoring loop ^') wherein the inventory manager watches for new information. If at block 700 a new feed plan is received, control proceeds to block 703 of FIG. 18B. If not, control proceeds to block 701 (FIG. 18A). At block 701, the inventory levels

are examined. If the inventory level(s) change outside of the expected value(s)

for an executing feed plan (block 702), the optimizer 46 is invoked to re-plan.

(Optionally, other actions such as manual entry can be used to invoke a re-plan

here and/or at other points throughout the system). Otherwise, control continues to loop through blocks 700-702 until a triggering event occurs at

block 700 or block 702.

As mentioned above, when a new feed plan is received (block 700),

control proceeds to block 703 of FIG. 18B. At block 703, the inventory

manager 40 retrieves the new feed plan (i.e., the quantities of ingredients to be used with an associated schedule). Control then proceeds to block 704 where the inventory manager 40 accesses the feed mill database 34 to determine if the output demands placed on the feed mill under the proposed feed plan can

be met by the feed mill. If output demands on the feed mill are too high, the inventory planner 40 triggers the optimizer 46 to initiate the process of

developing a new production plan and/or nutrition plan that can be met by the feed mill. If output demands on the feed mill are not too high, control proceeds to block 705.

At block 705, the inventory planner 40 accesses the current ingredients position and current inventory database 64 to retrieve data indicating current ingredient inventories and the accepted ingredient bids and offers. At block

706, the inventory planner 40 sums or compiles the retrieved data into a supply schedule reflecting the amount of each ingredient expected to be on hand

(including ingredients under contract) as a function of time. Control then

proceeds to block 707.

At block 707, the inventory planner 40 subtracts the inventory

requirements of the feed plan from the supply schedule. Control then proceeds to block 708. At block 708, the inventory planner 40 determines if any

ingredient is expected to go below or above the storage capacity of the feed

mill at any time. If so, the inventory planner 40 sends a message to the

optimizer 46 requesting development of a new feed plan. Otherwise, control

proceeds to block 709 (FIG. 18C).

At block 709, the inventory planner 40 determines if any of the ingredient handling capabilities of the feed mill are exceeded under the current plan. That determination is made by accessing the feed mill database 34. This can be a more detailed analysis than elsewhere, for example, taking into

account transportation restrictions (e.g., loading dock space constraining frequency of shipment departure/arrival). If any ingredient handling capability is exceeded, the optimizer 46 is notified and a new livestock production plan is developed. Otherwise, control proceeds to block 710.

At block 710, the inventory planner 40 retrieves the relevant portions of the production plan. Control then proceeds to block 711 where the

inventory planner 40 determines whether any of the meat facility production line capabilities are exceeded by the proposed plan. This determination is made by accessing the processing plant database 60. This can be a more

detailed analysis than that used in the production planner, for example, taking

into account transportation restrictions (e.g., loading dock space constraining

frequency of shipment departure/arrival). If any of these capabilities are

exceeded, the optimizer 46 is notified and a new livestock production plan is developed. Otherwise, confrol proceeds to block 712 where the inventory

planner 40 updates the inventory database 64 as needed. Control then returns

to block 700 of FIG. 18 A.

23. Ingredient Registration Service

FIGS. 19 and 20 illustrate an exemplary program for implementing the ingredient registration service 14 shown in FIG. 2. FIG. 19 focuses on the process for developing the population database. When the ingredients registration service 14 receives an input, it first determines whether the received message relates to an ingredient or animal already identified in the

database (block 800). If it does, the database population module 16 determines whether the received message is a request to update the data associated with that ingredient or animal or a message of a different type (e.g.,

an administrative message that a fee has been paid and data associated with the fee payment should be made available on-line) (block 802). If it is not such a

request, control proceeds to block 810. At block 810, the database population module 16 determines whether the fee associated with planning the subject

data on the database has been paid. If not, the database population module 16 authorizes issuance of a request for payment to the user associated with the

data to be listed (block 812) and control returns to block 800. Otherwise, the

database population module 16 makes the data available on-line by, for example, changing a flag associated with the data in the database (block 814).

Control then returns to block 800.

If at block 800, it is determined that the message does not relate to an ingredient or animal already listed in the database, or if at block 802, it is

5 determined that the message relates to updating data pertaining to an ingredient or animal already listed in the database, control proceeds to block 804. At block 804, the database population module 16 determines whether the submitted data has a verification (e.g., a digital signature) indicating that the submitted data has been tested (block 804). If the data does not contain a

10 verification that the product associated with the submitted data has been tested, confrol proceeds to block 806 where the database population module 16 authorizes transmission of a message to request verification of the submitted data. If at block 804, the database population module 16 determines that the submitted data has been verified, control proceeds to block 808.

, j At block 808, the database population module 16 stores the submitted data in the database in indexed fashion and a "dissemination" flag indicating that the data should not be placed on-line is set. Control then proceeds to block 810 where the revenue module 20 determines whether the fee for

placing the new data on-line has been paid and changes the status of the

0 dissemination flag as appropriate as explained above.

As shown in FIG. 20, when the ingredient registration service 14

receives a message from a user requesting access to the on-line data, the access controller 18 first attempts to identify the user (block 900). If the access

confroller 18 cannot identify the user (block 902) the access controller 18

sends a message to the user requesting that they sign up for the service (block

904). The user is then afforded an opportunity to provide profile data (preferably including contact data and billing information) which is stored by the system 14. Control then retums to block 900.

If at block 902, the access confroller 18 determines that the user is

known to the system 14, control proceeds to block 906. At block 906, the user profile information of the user is retrieved. As mentioned above, the user

profile information will include a date-time stamp indicating the last time that the user requested a download from the system 14. Control then proceeds to block 908.

At block 908, the database population module 16 determines whether the user has requested a full data download. A user might wish to download all relevant data if, for example, they are a new user, or if their local data

storage device has been corrupted or replaced. If the user requests a full download control proceeds to block 914. Other wise, confrol proceeds to block 910.

At block 910, the database population module 16 determines whether

any relevant data change has occurred since the last time the user downloaded

data. This determination is made based on the user profile information which determines the universe of "relevant data" in the database. If there has not been any relevant data change since the last download to the user, confrol then

proceeds to block 912.

At block 912, the ingredient registration service 14 sends a message to

the user indicating that there is no new data to download to the user. Confrol returns to block 900.

If at block 910, the database population module 16 determines that a relevant data change has oecuπed, or if the user requests a full download (block 908) confrol proceeds to block 914. At block 914, the database

population module 16 downloads the requested data. (Of course, only data with an appropriately set dissemination flag (i.e., one that indicates fee payment) will be downloaded.) Control then proceeds to block 916 where the user's profile is updated with the date-time stamp of the current download.

Confrol then proceeds to block 918. At block 918, the revenue module 20

issues one or more invoices and/or charges the credit card(s)/bank account(s) J of the appropriate entity or entities for downloading the data. Control then returns to block 900.

24. Market Monitor - Control Flow

An exemplary program for implementing the market monitor 67 is

shown in FIGS. 21A-21B. The market monitor 67 monitors the meat markets

and the ingredient markets for changes relative to the market conditions stored

at block 413 of FIG. 1 IB. To this end, the market monitor 67 first creates the parallel threads to perform the desired monitoring (block 1100). These threads

monitor the relevant meat and ingredient markets (blocks 1102 and 1104) for

changes that are "significant" (i.e., greater than a predetermined (user

definable) threshold). If a significant change is detected (block 1102 or block 1104), the separate threads are terminated (block 1106). The market monitor 67 will then take steps to perform planning using the new market conditions as explained below.

Specifically, the market monitor 67 causes the system to develop a new plan given the current market conditions (block 1108). In other words, the

loop shown in FIG. 7 is executed, but no commitment to the plan is requested or permitted.

Once the new plan is developed, the market monitor 67 compares the new plan to the previous plan (i.e., the plan being executed when the market change was detected) (block 1110). This comparison is preferably focused on the object of optimization (e.g., cash flow, profit, etc.) which was used to develop the plans. If the comparison between the two plans reveals a

difference that is greater than a predetermined (and, preferably, user definable)

threshold, control proceeds to block 1114 of FIG. 21B. Otherwise, the current

plan is deemed acceptable and control returns to block 1100 of FIG. 21 A where market monitoring is again initiated. Assuming control reaches block 1114 of FIG. 2 IB, the market monitor

67 identifies the changes to outstanding market positions needed to convert to

the new plan (block 1114). For example, the new plan may make some or all

of the outstanding contracts to buy or sell unnecessary or undesirable. If such is the case, the market monitor 67 determines the buying and/or selling actions needed to eliminate such contracts (block 1114).

Control then proceeds to block 1116 where one or more managers are afforded an opportunity to approve or disapprove the action(s) identified at block 1114. The manager(s) in this step can be a human and/or the automated managers (e.g., the production manager, the nutrition manager, etc.) If the manager(s) disapproves, control proceeds to block 1118 where the market

manager 67 temporarily modifies the definition(s) of "significant market changes" used in blocks 1102 and 1104 so that the same market conditions do not re-trigger the reevaluation process. The modifications are temporary in the sense that once a new plan is approved (e.g., at block 1128) at some point in the future, then the original defϊnition(s) of "significant market change(s)" are

restored. In any event, if the definition(s) are modified at block 1118, control returns to block 1100 of FIG. 21 A.

Assuming the manger(s) approve the new plan (block 1116), control

proceeds to block 1120. At block 1120, the market monitor 67 appends the

changes to the outstanding positions identified at block 1114 to the proposed

selling and bid sheets. The new plan, the new bid sheet and the new selling sheet are then saved in the appropriate databases and the buying and selling

plan controllers 48, 50 are invoked to execute the new plan (block 1126). The

market conditions under which the new plan was approved are saved (block 1128) and control returns to block 1100 of FIG. 21A where market monitoring begins anew.

25. Exemplary System Modifications

Although for ease of explanation, the foregoing description has focused upon a distributed system wherein each animal producer 8 is provided with (a) software for maintaining local databases with data which is downloaded from the ingredient registration service 14 and/or loaded locally,

and (b) software for locally developing a livestock production plan based upon the data in the local databases and real-time market information gathered over the Internet, persons of ordinary skill in the art will readily appreciate that the teachings of the invention are equally applicable to more centralized systems. In the latter case, the optimization software (e.g., the nutrition planner 44, the inventory planner 40, the production planner 42 and the optimizer 46) is

executed by a centralized server. The centralized server uses production constraint data uploaded (on at least one occasion) by the animal producer 8,

data from the ingredient registration service 14, and real-time pricing data

retrieved from one or more on-line exchanges 26 to develop an optimized

livestock production plan for animal producer 8 requesting such a plan. In this implementation, the ingredient registration service 14 can optionally be owned

by the same entity that owns the centralized server and/or fees can be levied

for developing production plans for animal producers 8. The fee structures discussed above can optionally be used and/or additional fees can be levied on,

for example, a fee per livestock production plan basis.

Persons of ordinary skill in the art will further appreciate that, although for ease of explanation, the foregoing description has focused on implementing the various components of the system using software, any, some

or all of the components described herein as software can be implemented by hardware and/or firmware without departing from the scope or spirit of the invention.

Persons or ordinary skill in the art will further appreciate that, as used

herein, the term "computer" refers to one or more computers, the term "server" refers to one or more servers, and the term "database" refers to one or more databases. Similarly, referring in the singular to any other component (or step) that can be implemented by one or more components (or steps) is meant to encompass the singular and/or the plural.

26. Economic Analysis

From the foregoing, persons of ordinary skill in the art will appreciate

that the disclosed apparatus can be used in many ways without departing from

the scope or spirit of the invention. For example, the disclosed apparatus may be used as an economic analysis tool to develop information of interest to an

animal producer 8, an ingredient supplier 2 (including, for example, a money

lender), and/or an animal stock provider 4. In other words, the disclosed

apparatus can be used as a predictive tool to enable parties of interest to make

informed economic decisions.

By way of example, not limitation, a user of the apparatus can first run the apparatus to develop a livestock production plan based on cuπent conditions (market, production capacities, etc.). Then, the user can adjust data in the ingredient database which is indicative of at least one predefined ingredient and re-execute the apparatus to develop a new production plan. By

comparing the newly developed production plan with the previously developed production plan, the user can determine what, if any, effect

adjusting the data has on the production plan. This information can be important because it reflects how the modeled animal producer 8 will likely react to the adjustment in the ingredient database. This information would be

of interest to, for example, an ingredient supplier 2 who is considering making a new ingredient available in the marketplace, modifying an existing

ingredient available in the marketplace, and/or removing an ingredient from the marketplace. In particular, this information can be used by the ingredient

supplier 2 to predict the economic value of the proposed ingredient change.

Such infoπnation can then be used to make informed economic decisions. In another example, the disclosed apparatus can be employed to

estimate the economic value of producing an ingredient having different

nutritional content or a different attribute (e.g., an enzyme that aids digestion,

a specific mycotoxin level, etc.) than an existing ingredient. For example, a

producer of genetically modified and/or quality bred com could use the model to estimate the expected return of improving the protein content of its com (e.g., from 5% to 6%). The ingredient supplier 2 would perform this analysis in much the same way explained above. In particular, the ingredient supplier 2 would first execute the model to develop a production plan given current conditions. Then the ingredient supplier 2 would adjust the data in the ingredient database indicative of the nutritional content of the product of interest (e.g., increasing the protein content of its com from 5% to 6%), and

then cause the apparatus to develop a new production plan based on the modified data. A comparison of the second production plan with the first production plan will provide the ingredient supplier 2 with information concerning the animal producer's likely response to the presence of the improved ingredient (e.g., com with 6% protein) in the marketplace. This

information can be useful, for example, in pricing the new ingredient, in

setting research and production goals for new ingredients, and in estimating

the cost effectiveness of embarking on a research or breeding program to

achieve a product with the improved nutritional content or attribute. An animal stock provider 4 can also use the disclosed methods and

apparatus as a predictive tool for making informed business decisions. For

example, the animal stock provider 4 can run the apparatus to develop a

production plan using the cuπent conditions. The animal stock provider 4 can then adjust data in the nutrition requirements database which is indicative of at least one possible livestock, and then re-run the apparatus to develop a second production plan based on the modified data. Comparison of the new production plan with the previous production plan will provide the animal stock provider 4 with information concerning the animal producer's likely response to the change in availability of the possible livestock. The change in availability can be, for example, making a new livestock available, making a genetically modified or quality bred livestock available, or removing a

possible livestock from the marketplace. As with the ingredient supplier 2, the animal stock provider 4 can use the predictive information developed by employing the apparatus in this manner to make informed economic decisions.

By way of a further example, the animal stock provider 4 could employ the apparatus to predict the economic effect of making livestock having a

modified nutritional requirement available in the marketplace. This analysis is

performed by first executing the apparatus to develop a production plan based

on the cuπent conditions, subsequently adjusting data in the nutrition

requirements database which is indicative of at least one nutritional

requirement (e.g., x% protein) of at least one of the possible livestock, and then re-executing the apparatus based on the new data to develop a new

production plan. Comparing the new production plan with the old production

plan will provide the animal stock provider 4 with information concerning the

likely response of the animal producer 8 to the proposed change in the marketplace. This information can be used to place an economic value on actually implementing the change in the marketplace which, as explained above, can be used to make informed economic decisions.

From the foregoing, persons of ordinary skill in the art will further

appreciate that the disclosed apparatus and methods can be used as a predictive tool in many other ways without departing from the scope or spirit of the invention. By way of a further example, the animal stock provider 4 can

use the apparatus to determine the value of producing a livestock with an improved quality trait (e.g., a chicken with more breast meat or higher

resistance to disease) and to use that infoπnation to make informed economic decisions on how to direct their business in the future.

By way of a further example, the animal producer 8 can also use the disclosed apparatus as a predictive tool for growing their business. Under

such an approach, the animal producer 8 can run the apparatus to develop a

production plan based on the current conditions. Then, the animal producer 8

can adjust data in the production constraint database and re-run the apparatus

to develop a second production plan. By comparing the second production

plan with the first production plan, the animal producer 8 can obtain information concerning the effect on its business of making a modification to

its physical production capabilities (e.g., opening a new kill plant, closing a

barn, expanding a hatchery, etc.). Employing the apparatus in this manner will

enable the animal producer 8 to identify bottlenecks in its production process and ascertain the economic value of changing those constraints without actually making the investment. This ability to make economic predictions enables the animal producer 8 to make more informed economic decisions and

lowers the risk of investment. For example, the animal producer 8 can use the system to determine the desirability of expanding to a new location before actually investing any resources in performing the expansion. By way of

another example, employing the apparatus as a predictive tool enables the animal producer 8 to better understand the implications of executing a long- term contract with a supplier and/or customer before the contract is actually executed by running the model once assuming the contract is present and once assuming it is not, and comparing the results. Again, this ability to ascertain predictive information should lead to more informed economic decisions. In

addition, an animal producer 8 interested, for example, in expanding their operation could employ the apparatus to identify an optimized location for

growing and/or selling a predefined ingredient. This analysis would preferably

be performed across a plurality of animal producers as explained below and

could, for example, seek to minimize freight costs. Although the foregoing approach to employing the disclosed apparatus

as a predictive tool provides valuable economic data, even better data can be

produced by providing the apparatus with access to data concerning a group of

animal producers, rather than a single animal producer 8. In particular, if the

production constraints database includes data for a plurality of different animal producers 8 (e.g., all animal producers, a statistical sampling of animal users, animal users in a particular region, etc.), the apparatus can be iteratively executed to develop a first set of production plans based on the current conditions, and a second set of production plans based on an adjustment of one

or more inputs in one or more of the ingredients database, the nutrition

requirements database and/or the production constraints database. Comparing the two sets of production plans provides data identifying the effect of making the proposed adjustments in the marketplace. Because this information is developed by considering a wider segment of the market (or perhaps the entire market) than was considered in the single animal producer examples discussed above, the economic information and conclusions derived therefrom should be

more accurate than the conclusions developed from the single animal producer model.

FIGS. 22A-22B illustrate a flowchart for developing economic

information across a plurality of animal producers 8 as explained above.

Turning to FIG. 22A, the apparatus first requests the user to identify the set of animal producers 8 which are to be used in performing the predictive analysis. (Block 1000). For example, the set of animal producers 8 can include all

animal producers 8 in the system, all animal producers 8 in a specific

geographic region, all animal producers 8 of a particular type of livestock, etc.

In any event, after the user identifies the set of animal producers 8, a counter X

5 is set to zero and control proceeds to block 1002.

At block 1002, the apparatus develops a production plan for the first animal producer 8 in the set of animal producers 8 based on the current conditions. The production plan is developed as explained above in connection with FIGS. 2-20. The developed production plan is then saved

10 (block 1004). The apparatus then determines whether a production plan based on the current market conditions has been developed for each animal producer 8 in the set of animal producers (block 1006). If so, control proceeds to block

1010. Otherwise, control proceeds to block 1008 where the counter X is incremented by one. Control will continue to loop through blocks 1002-1008

^' *» until a production plan based on the current market conditions has been developed for each of the animal producers 8 in the set (block 1006).

At block 1010, the apparatus requests the user to input the data to be

used for the predictive analysis. Once the user inputs this data, the counter

variable X is set to zero and confrol proceeds to block 1012 (FIG. 22B).

0 The apparatus then enters the loop defined by blocks 1012-1018 in

which it iteratively develops a production plan for each of the animal

producers 8 in the set based on the modified conditions entered at block 1010. The production plan is developed at block 1012 in the same manner that the

production plans were developed at block 1002 except, the new data submitted

at block 1010 is used in place of the coπesponding data in the databases and

with one further possible exception explained below. After each plan is

developed (block 1012), it is saved (block 1014). If a production plan based on the new conditions has been developed for each of the animal producers 8 in the set (block 1016), control proceeds to block 1020. Otherwise, control proceeds to block 1018 where the counter X is incremented. The loop defined by blocks 1012-1018 continues executing until a production plan is developed and saved for each of the animal producers 8 in the set (block 1016).

At block 1020, the apparatus compares the first set of production plans

(i.e., those plans developed via the loop defined by blocks 1002-1008) with the second set of production plans (i.e., the plans developed by the loop defined by blocks 1012-1018). The apparatus then outputs the differences between the plans to the user (block 1022). As explained above, these differences can be

used to perform economic analysis using standard economic tools well known in the art. Persons of ordinary skill in the art will appreciate that the apparatus can be programmed to perform such economic analysis without departing from

the scope or spirit of the invention. Alternatively, the economic analysis can

be left to the user who receives the output reflecting the differences between

the two sets of plans. Persons of ordinary skill in the art will also readily appreciate that,

preferably the actual data in the databases is not changed by the data input by the user at block 1010 of FIG. 22 A or in any of the examples given above.

Instead, a flag is set in the appropriate database(s) in association with the original data to be "modified" as an indication to the apparatus that substitute

data stored at another location (perhaps at a pathname specified by the flag) is to be used in place of the original database data for prediction puφoses. The

adjusted data submitted by the user is then stored at the specified location where it can be accessed for use in developing the second set of production

plans as needed. This approach ensures that the data in the databases remains accurate and is not lost by using the apparatus as a predictive tool.

Persons or ordinary skill in the art will also appreciate that, when used

as a predictive tool for, for example, making a new or modified ingredient or animal available on the market, the system will preferably not present the new or modified ingredient or animal directly to the market to solicit pricing information via, for example, a dummy request for solicitation. Instead, the

system preferably assumes that the new or modified ingredient or animal is priced at a level commensurate with a substitute product available on the

market, develops predictive production plan(s) based on this assumption, and

employs the difference(s) in the predictive production plan(s) developed with

the adjusted input and the production plan(s) developed under current conditions to estimate the value and, thus, the appropriate pricing level for the adjusted input (e.g., the new or modified ingredient or animal). By way of a

more concrete example, if the user has developed com with 6% protein

content whereas existing com has 4% protein content, the user can first

employ the system to develop production plan(s) based on current conditions assuming the new com does not exist. Next, the user makes the new com available to the system assuming the price of the new com (e.g., 6% protein com) is the same as the existing com (e.g., 4% protein com) and uses the system to develop predictive production plan(s). The user then compares the developed production plans to identify the result of making the improved com available. If, for example, the difference shows that X ton of the new com is

utilized in the predictive production plan(s) and the user of this new com lowers the costs of the animal producer(s) by $1,000,000.00, the user knows that the new com adds $1,000,000.00 of value over the existing com. By

dividing this value over the tonnage ("X") used in the predictive production plan(s), the user can determine the incremental price increase per ton relative to existing com and can price their new com (e.g. 6% protein com) accordingly. Of course, persons of ordinary skill in the art will appreciate that

although in the example given above, a positive price change in the new product (e.g., 6% protein com) was indicated, predictions will not always be

positive and the system may indicate that no price difference or even a

negative price difference from the existing product (e.g., 4% protein com) is

dictated by the market. This latter possibility points out the value of the system's predictive capabilities in planning and/or setting goals for research

programs. Specifically, the goals of a proposed research program can be

analyzed before the program is implemented to determine if, given a

successful program, the new product developed by that program will achieve sufficient market acceptance to justify the costs of the program.

Persons of ordinary skill in the art will further appreciate that, when the apparatus is implemented with the predictive capabilities described above and shown in FIGS. 22A-22B, it is preferable to implement the apparatus as a centralized device having a centralized ingredient database 52, a centralized nutrition requirements database 54, and a centralized production constraints

database. The centralized databases reduce processing time in performing the predictive analysis across multiple animal producers 8.

Because animal producers 8 may find it undesirable to provide their physical production constraints data to their competitors, the data stored in the physical production constraint database is preferably stored without specific reference to the associated animal producer's identity (e.g., a pseudonym or number is employed). To further enhance the privacy of the centralized

physical production constraints database, the apparatus is preferably configured to prevent direct downloads from that database, and the apparatus

only downloads the differences between the production plans to the user

(block 1022 of FIG. 22B), again, devoid of the identities of the animal producers. Persons of ordinary skill in the art will readily appreciate that any of

the foregoing examples of using the apparatus as a predictive tool for an

individual animal producer 8 are equally applicable to using the apparatus as a

predictive tool across a plurality of animal producers. Thus, by way of examples, not limitations, any or all of the following types of data can be modified at block 1010 of FIG. 22 A: (a) data in the ingredient database indicative of at least one predefined ingredient; (b) data in the ingredient database indicative of the nutritional content and/or other attribute(s) of at least one of the possible ingredients; (c) data in the nutritional requirements database indicative of at least one possible livestock; (d) data in the nutrition requirements database indicative of at least one nutritional requirement and/or other attribute(s) of at least one of the possible livestock, and (e) any of the

data in the production consfraints databases.

Persons of ordinary skill in the art will readily appreciate that the differences between the first and second sets of the production plans developed by the process illustrated in FIGS. 22A-22B can be used for a wide variety of economic analysis. For example, the differences between the production plans can be used to calculate a value of an ingredient including an

adjusted nutritional content (i.e., the nutritional content value is adjusted at

block 1010 of FIG. 22A) or an adjusted attribute. By way of another example,

the identified differences between the sets of production plans can be used to

determine a substitution price for a product that can be substituted for at least one of the possible ingredients identified in the database. Once this

substitution price is developed, the user can take economic action based upon

this information. For example, the user can optionally sell the substitution

product as a hedge to reduce price risk associated with selling the possible ingredient.

By way of another example, a user can employ the difference between the first and second sets of production plans to estimate total use of one or more of the possible ingredients to thereby estimate the demand curve for that ingredient(s). The user can also employ the identified differences between the sets of production plans to determine a substitution price for one or more

products that can be substituted for one or more of the possible ingredients to thereby estimate a supply curve for those possible ingredients. The estimated supply and demand curves can then optionally be used to calculate market clearing prices.

Whether the apparatus is used to predict economic effects based on a single animal producer or a plurality of animal producers, the user can respond to the calculated difference between the production plans by taking a market

position based on the modified production plan (i.e., the predicted plans based on the modified data). For example, one can take a market position that

hedges against risk in future sales of meat produced pursuant to the developed

production plan. Examples of possible market positions include selling on a

futures market, selling on a cash market, and selling on a derivative market. From the foregoing, persons of ordinary skill in the art will further

appreciate that the development of a ration exchange as explained above

provides a completely new way of trading. In particular, the ration exchange

is preferably operated to receive a solicitation via a computer network for bids to purchase a given nutrition ration from a first party, and to make that solicitation for bids available to potential purchasers via the computer network. Then, when the rations exchange receives from a second party an electronic bid to purchase a quantity of that nutrition ration from the first party, it delivers the bid to the first party. Subsequently, a contract may be created between the first and second parties for the sale of a quantity of the given nutrition ration from the first party to the second part. This ration

contract can be a futures contract or a cash contract.

The presence of a ration exchange also provides new business opportunities. For example, a user interested in purchasing metabolic energy

(i.e., a ration) on the ration exchange, could access the appropriate ration exchange via a computer network to determine a current price of that nutrition ration. That entity could also access a commodity exchange via the computer

network to determine a current price of a predetermined commodity (e.g.,

com) carrying the predetermined nutrition ration (in this instance, metabolic

energy). The user can then compare the current prices of the commodity (in

this instance, com) and the nutrition ration (in this instance, metabolic energy)

and take market action based upon that comparison. Preferably, the cuπent prices of the commodity and the nutrition ration being analyzed are

normalized to ensure an appropriate comparison is performed (i.e., the

compared prices are adjusted to ensure they are being compared on a one-for-

one basis).

Although certain exemplary apparatus and methods constructed or performed in accordance with the teachings of the invention have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all apparatus and methods fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.

Claims

What is claimed is:

1. An apparatus for developing a livestock production plan for an

animal producer comprising: a communication device for accessing a computer network to obtain

first substantially real-time pricing information for ingredients and second substantially real-time pricing information for animal meat; an ingredient database containing data indicative of ingredients and data indicative of nutritional content of the ingredients;

a nutrition requirements database containing data indicative of types of livestock and data indicative of nutritional requirements of the types of livestock;

a production planner; a nutrition planner in communication with the production planner, the ingredient database and the nutrition requirements database for developing at least one ingredient list for at least one type of livestock selected by the

production planner; and an optimizer cooperating with the production planner and the nutrition

planner for developing a livestock production plan based at least in part upon the first and second substantially real time pricing information.

2. The apparatus as defined in claim 1 wherein at least some of

the first substantially real-time pricing information varies as a function of

time.

3. The apparatus as defined in claim 1 wherein at least some of the second substantially real-time pricing information varies as a function of time.

4. The apparatus as defined in claim 1 wherein the developed production plan is directed toward a predefined time period.

5. The apparatus as defined in claim 4 wherein at least some of

the data in the ingredient database and the nutrition requirements database is indicative of changes over time.

6. The apparatus as defined in claim 1 wherein at least some of the data in the ingredient database and the nutrition requirements database is

indicative of changes over time.

7. The apparatus as defined in claim 1 wherein the ingredient

database also contains data indicative of non-nutrient attributes of the

ingredients.

8. The apparatus as defined in claim 1 wherein the nutrition

requirements database also contains data indicative of feed and husbandry

requirements of the types of livestock.

9. The apparatus as defined in claim 1 wherein the ingredient database is periodically updated by communicating with a networked server via the communication device.

10. The apparatus as defined in claim 9 wherein the nutrition requirements database is periodically updated by communicating with the networked server via the communication device.

11. The apparatus as defined in claim 9 wherein the networked

server contains data for ingredients supplied by a plurality of third parties.

12. The apparatus as defined in claim 10 wherein the networked server contains data for types of livestock supplied by a plurality of third

parties.

13. The apparatus as defined in claim 11 wherein the networked

server downloads only data associated with ingredients that are practically available to the animal producer.

14. The apparatus as defined in claim 11 wherein the networked

server downloads only data that is at least one of new and modified since a

predefined earlier time.

15. The apparatus as defined in claim 14 wherein the predefined earlier time is a time of a previous download.

16. The apparatus as defined in claim 1 wherein the nutrition

requirements database is periodically updated by communicating with a networked server via the communication device.

17. The apparatus as defined in claim 16 wherein the networked server contains data for types of livestock supplied by a plurality of third

parties.

18. The apparatus as defined in claim 16 wherein the networked server downloads only data associated with animals that are practically

available to the animal producer.

19. The apparatus as defined in claim 17 wherein the networked

server downloads only data that is one of new and modified since a predefined

earlier time.

20. The apparatus as defined in claim 19 wherein the predefined

earlier time is a time of a previous download.

21. The apparatus as defined in claim 1 further comprising an electronic purchasing agent for electronically contracting to purchase an ingredient identified in the developed livestock production plan via the computer network.

22. The apparatus as defined in claim 21 further comprising an

electronic selling agent for electronically contracting to sell a product to be produced via the developed livestock production plan via the computer network.

23. The apparatus as defined in claim 22 further comprising a market monitor for electronically monitoring at least one ingredient market via the computer network, the market monitor cooperating with the electronic

selling agent, the electronic buying agent and at least one of: (a) the nutrition planner; (b) the production planner; and (c) the optimizer to perform at least

one of (i) selling out of a contract to purchase an ingredient, and (ii) entering

into a new contract to buy an ingredient if a change in the at least one

ingredient market merits a modification to the previously developed livestock production plan.

24. The apparatus as defined in claim 1 further comprising an

electronic selling agent for electronically contracting to sell a product to be produced via the developed livestock production plan via the computer

network.

25. The apparatus as defined in claim 1 further comprising at least one production constraint database containing data indicative of at least one of: physical production constraints associated with the animal producer; physical production constraints of at least one meat processing facility;

current sales commitments associated with the animal producer; and current purchase commitments associated with the animal producer.

26. The apparatus as defined in claim 25 wherein at least some of the physical production constraints of at least one of the animal producer and the meat processing facility are reflected as a function of time.

27. The apparatus as defined in claim 25 wherein at least one of the

physical production constraints of the at least one meat processing facility is

updated via the computer network.

28. A method for developing a livestock production plan

comprising the steps of: a) providing an ingredient database containing data indicative of

ingredients and data indicative of nutritional content of the ingredients; b) providing a nutrition requirements database containing data indicative of types of livestock and data indicative of nutritional requirements of the types of livestock;

c) identifying an objective to optimize; d) selecting at least one type of livestock to produce; e) developing at least one ingredient list for the at least one type of livestock; f) obtaining first substantially real-time pricing information for at

least the ingredients in the ingredient list and second substantially real-time pricing information for meat of the at least one type of livestock via a computer network; and

g) developing a livestock production plan which optimizes the objective.

29. The method as defined in claim 28 wherein the livestock

production plan is developed by repeating at least one of steps d, e and f.

30. The method as defined in claim 28 wherein the objective

comprises at least one of: maximizing profits, maximizing production,

maximizing use of a predefined ingredient, minimizing profits, minimizing

use of a predefined ingredient, minimizing physical space used in a predefined facility, minimizing time to produce a saleable product, maximizing cash flow, minimizing cash flow, maximizing usage of a predefined facility, minimizing

cost per unit of saleable product, and maximizing use of ingredients on hand.

31. The method as defined in claim 28 further comprising the step of automatically periodically updating the ingredient database by

communicating with a networked server via the computer network.

32. The method as defined in claim 31 further comprising the step of automatically periodically updating the nutrition requirements database by communicating with the networked server via the computer network.

33. The method as defined in claim 28 further comprising the step of automatically periodically updating the nutrition requirements database by

communicating with the networked server via the computer network.

34. The method as defined in claim 28 further comprising the step

of electronically contracting to purchase an ingredient identified in the

developed livestock production plan via the computer network.

35. The method as defined in claim 34 further comprising the step of electronically contracting to sell a product to be produced via the developed livestock production plan via the computer network.

36. The method as defined in claim 35 further comprising the steps of:

electronically monitoring at least one ingredient market via the computer network; and,

if a change in the at least one ingredient market merits a modification to the previously developed livestock production plan, performing at least one of (i) selling out of at least one contract to purchase an ingredient, and (ii)

entering into at least one new contract to buy an ingredient.

37. The method as defined in claim 28 further comprising the step

of electronically contracting to sell a product to be produced via the developed

livestock production plan via the computer network.

38. The method as defined in claim 28 further comprising the steps

of: providing at least one production constraint database containing data

indicative of at least one of: physical production constraints associated with the animal producer; physical production constraints of at least one meat processing facility; current sales commitments associated with the animal producer; current purchase commitments associated with the animal producer; and

employing at least some of the data in the at least one production constraint database in developing the production plan.

39. The method as defined in claim 38 wherein at least some of the physical production constraints of at least one of (i) the animal producer and (ii) the meat processing facility are reflected as a function of time.

40. The method as defined in claim 38 wherein at least one of the

physical production constraints of the at least one meat processing facility is

updated via the computer network.

41. The method as defined in claim 28 further comprising the steps

of: adjusting data in the ingredient database indicative of at least one

predefined ingredient; and executing at least some of steps c, d, e, f and g to determine an effect

adjusting the data indicative of the at least one predefined ingredient has on the production plan.

42. The method as defined in claim 41 wherein the step of

adjusting data comprises at least one of: making a new ingredient available in the ingredient database; making a modified ingredient available in the ingredient database; and

making an ingredient unavailable in the ingredient database.

43. The method as defined in claim 28 further comprising the steps of: adjusting data in the ingredient database indicative of the nutritional

content of at least one of the ingredients; and

executing at least some of steps c, d, e, f and g to determine an effect

adjusting the data indicative of the nutritional content of the at least one of the

ingredients has on the production plan.

44. The method as defined in claim 28 further comprising the steps

of: adjusting data in the nutrition requirements database indicative of at

least one type of livestock; and

executing at least some of steps c, d, e, f and g to determine an effect adjusting the data indicative of the at least one type of livestock has on the production plan.

45. The method as defined in claim 41 wherein the step of adjusting data comprises at least one of:

making a new type of livestock available in the nutrition requirements database; making a modified type of livestock available in the nutrition

requirements database; and making a type of livestock unavailable in the nutrition requirements database.

46. The method as defined in claim 28 further comprising the stepsό of:

adjusting data in the nutrition requirements database indicative of at

least one nutritional requirement of at least one of the types of livestock; and executing at least some of steps c, d, e, f and g to determine an effect

adjusting the data indicative of the at least one nutritional requirement of the at

least one of the types of livestock has on the production plan.

47. The method as defined in claim 38 further comprising the steps

of: adjusting data in the at least one production consfraint database; and

executing at least some of steps c, d, e, f and g to determine an effect adjusting the data in the at least one production constraint database has on the production plan.

48. The method as defined in claim 38 wherein the at least one production constraint database includes data for a plurality of different animal

producers, and further comprising the steps of: h) repeatedly executing steps c, d, e, f and g to develop a first set

of livestock production plans for at least a subset of the plurality of animal producers;

i) analyzing the developed production plans; j) adjusting data in the ingredient database indicative of at least

one predefined ingredient; k) repeatedly executing steps c, d, e, f and g to develop a second

set of livestock production plans for the at least a subset of the plurality of

animal producers; and

1) analyzing the second set of production plans to determine the effect across the subset of animal producers of adjusting the data.

49. The method as defined in claim 48 wherein the animal

producers in the subset are located in a predefined geographic area.

50. The method as defined in claim 48 wherein the animal

producers in the subset are representative of a global market.

51. The method as defined in claim 48 wherein the animal producers in the subset are representative of a local market.

52. The method as defined in claim 38 wherein the at least one production constraint database includes data for a plurality of different animal

producers, and further comprising the steps of:

h) repeatedly executing steps c, d, e, f and g to develop a first set

of livestock production plans for at least a subset of the plurality of animal

producers;

i) analyzing the developed production plans; j) adjusting data in the ingredient database indicative of the

nutritional content of at least one of the ingredients;

k) repeatedly executing steps c, d, e, f and g to develop a second

set of livestock production plans for the at least a subset of the plurality of

animal producers; and

1) analyzing a difference between the first and second sets of production plans to determine the effect across the subset of animal producers

of adjusting the data.

53. The method as defined in claim 52 wherein the animal

producers in the subset are representative of a global market.

54. The method as defined in claim 38 wherein the at least one production constraint database includes data for a plurality of different animal producers, and further comprising the steps of: h) repeatedly executing steps c, d, e, f and g to develop a first set of livestock production plans for at least a subset of the plurality of animal

producers;

i) analyzing the developed production plans;

j) adjusting data in the nutrition requirements database indicative

of at least one type of livestock; k) repeatedly executing steps c, d, e, f and g to develop a second

set of livestock production plans for the at least a subset of the plurality of

animal producers; and

1) analyzing a difference between the first and second sets of production plans to determine the effect across the subset of animal producers

of adjusting the data.

55. The method as defined in claim 38 wherein the at least one production constraint database includes data for a plurality of different animal

producers, and further comprising the steps of: h) repeatedly executing steps c, d, e, f and g to develop a first set of livestock production plans for at least a subset of the plurality of animal

producers; i) analyzing the developed production plans; j) adjusting data in the nutrition requirements database indicative

of at least one nutritional requirement of at least one of the types of livestock; k) repeatedly executing steps c, d, e, f and g to develop a second set of livestock production plans for the at least a subset of the plurality of

animal producers; and

1) analyzing a difference between the first and second sets of

production plans to determine the effect across the subset of animal producers

of adjusting the data.

56. A method of doing business comprising the steps of:

developing data indicative of the quality traits of a plurality of different

ingredients for animal production sold by third party ingredient suppliers;

storing the developed data;

making the stored data available for access by third party ingredient suppliers; and charging a fee for accessing the data.

57. A method for developing a livestock production plan for an animal producer comprising the steps of: selecting at least one type of livestock to produce; developing at least one list of ingredients for producing the at least one type of livestock;

obtaining first substantially real-time pricing information for the ingredients in the ingredient list and second substantially real-time pricing

information for meat of the at least one type of livestock via a computer network; and electronically developing a livestock production plan based at least in

part upon the first and second substantially real-time pricing information.

- I l l -

58. The method as defined in claim 43 further comprising the step

of using the effect on the production plan to calculate the value of the at least

one ingredient with the adjusted nutritional content.

59. The method as defined in claim 53 further comprising the steps

of: employing the effect across the subset of animal producers to

determine a substitution price for at least one product that can be substituted for the at least one of the ingredients.

60. The method as defined in claim 59 further comprising the step

of: selling the at least one product to reduce price risk associated with selling the at least one of the ingredients.

61. The method as defined in claim 53 further comprising the steps

of: employing the effect across the subset of animal producers to estimate

total use of the at least one of the ingredients to thereby estimate a demand

curve for the at least one of the ingredients; and

employing the effect across the subset of animal producers to

determine a substitution price for at least one product that can be substituted for the at least one of the ingredients to thereby estimate a supply curve for the

at least one of the ingredients.

62. The method as defined in claim 61 further comprising the step

of: employing the estimated supply curve and the estimated demand curve

to calculate market clearing prices.

63. The method as defined in claim 28 wherein the objective to optimize is profits and further comprising the step of: taking a market position based on the developed production plan that

hedges against risk in future sales of meat produced pursuant to the developed production plan.

64. The method as defined in claim 63 wherein the step of taking a market position comprises at least one of: (a) selling on a futures market; (b) selling on a cash market, and (c) selling on a derivative market.

65. A method for permitting an animal producer to develop an

ingredient mix to be input into an animal production system comprising the

steps of: providing an initial animal production plan identifying a first

combination of ingredients for providing a desired combination of nutritional

rations to animals to be produced by the animal producer; electronically monitoring at least one ingredient market exchange via a computer network; and

electronically determining if a change in the at least one ingredient market exchange has resulted in a lower cost combination of ingredients to provide the desired combination of nutritional rations than the first combination of ingredients.

66. A method comprising the steps of: accessing a ration exchange via a computer network to determine a

current price of a predetermined nutrition ration; accessing a commodity exchange via the computer network to determine a cuπent price of a predetermined commodity carrying the

predetermined nutrition ration; comparing the current prices of the predetermined commodity and the predetermined nutrition ration; and

taking market action based upon the comparison.

67. The method as defined in claim 48 further comprising the step of: analyzing the second set of production plans to identify an optimized

location for at least one of growing and selling the at least one predefined

ingredient.

68. A method of doing business comprising the steps of:

accessing at least one electronic market via a computer network to determine cuπent prices of a plurality of predetermined carriers of nutrition rations; and employing the current prices of the plurality of predetermined carriers

to automatically develop an optimized list of ingredients to supply the

nutrition requirements of an animal.

69. A method of operating a rations exchange comprising the steps of: receiving via a computer network a solicitation for bids to purchase a

first nutrition ration from a first party; making the solicitation for bids available to potential purchasers via the

computer network; receiving from a second party an electronic bid to purchase a quantity

of the first nutrition ration from the first party;

delivering the bid to the first party; and creating a contract between the first and second parties for the sale of the quantity of the first nutrition ration from the first party to the second party.