GB2374166A - Customisation of a generic project plan - Google Patents

Abstract

At least one generic project plan or template recipe is stored in a computer. Specific parameter values are entered into this template to generate a customised plan, which may take the form of a set of instructions for performing a task. Calculations may be performed on the input parameters to determine further parameters for inclusion in the customised plan, which may be subdivided. Applications for this technique include DIY project planning and the scaling of cookery recipes. Ingredients may be scaled linearly, in a stepped fashion or in a non-linear fashion. The database of plans may be linked to a retail outlet so that the most economical way of purchasing ingredients can be determined and a shopping list produced. A map may show the customer the most efficient route around the shop. The database may be accessible through interactive television and advertised on a television program.

Description

ACTIVE RECIPE SYSTEM Background to the Invention This invention relates to a system and method for producing recipes, customised to the requirements of users.

The word"recipe"is used herein to mean a list of materials and/or a set of instructions for performing some task. It includes, but is not limited to, cookery recipes. The invention is particularly, although not exclusively, concerned with recipes for do-it-yourself (DIY) construction projects.

Many DIY stores produce leaflets containing instructions on how to perform DIY tasks, including some details of the materials required. However, these are static generic documents, which do not necessarily match the user's requirements. In particular, recipes may need to be scaled according to the user's requirements. Whilst in some cases it is sufficient simply to scale the ingredients linearly to produce a new size, in many instances this will not be the case. For example, there may be a requirement for additional items if a construction is over a particular size, such as additional support posts (e. g. for a fence). In addition, the method of execution may change if the quantities change, for example there may be a longer setting time for a larger quantity (e. g. of concrete). Furthermore, the timescales for executing each stage of a construction project will change dependent on the size of the project, and this may impact scheduling of the work and the delivery of the ingredients.

Similar considerations also apply outside the DIY market. For example, in cookery it may not be sufficient just to alter the quantities of ingredients ; it may also be necessary to change the cooking time, the tin sizes, the number of batches into which to split the cooking and so on.

The object of the invention is to provide a system for producing a recipe customised to the individual requirements of a user.

Summary of the Invention According to the invention a computer-implemented method for generating a recipe, comprises the steps: (a) storing at least one generic definition of a recipe; (b) enabling a user to input a set of parameters specifying the user's requirements in relation to the recipe ; and (c) combining the generic definition with the user's requirements, to generate a customised recipe for the user.

Brief Description of the Drawings Figure 1 is a schematic block diagram of an active recipe system.

Figure 2 is a flow chart outlining the steps for producing a customised recipe.

Description of an Embodiment of the Invention One active recipe system in accordance with the invention will now be described by way of example with reference to the accompanying drawings.

Figure 1 shows a web server computer 10 which runs conventional web server software 11. The web server can be accessed over the Internet 12 by a number of user personal computers (PCs) 13 running conventional web browser software 14.

The web server stores a number of active recipe pages 15, as well as a number of conventional web pages (not shown). Each of the active recipe pages comprises an XML (Extensible Markup Language) document, which defines a generic recipe, as will be described in more detail below. The web server also stores a stock file 16 and a number of customer project files 17. The web server also includes a XML processor program 18, for parsing the active recipe pages, and generating customised recipes, as will be described.

In this example, it is assumed that the web server is operated by or on behalf of a DIY store, and that the recipes relate to DIY projects. Each active recipe page 15 relates to a particular DIY project.

Active recipe page Each active recipe page 15 comprises a number of sections defining various factors for the project. These include: user parameters, derived parameters, stage breakdown, ingredients, method of execution, and post-execution tasks. (Not all of these sections are necessarily present in any particular active recipe page). Each of these sections will now be discussed in turn.

The user parameters section contains definitions of one or more parameters to be input by the user. For example: < USER PARAMETER < NAME > Length < /NAME > < UNITS > metres < /UNITS > < TEXT > Total length of fence < /TEXT > < /USER PARAMETER This defines a parameter"Length", which is to be input by the user in response to the prompt"Total length of fence".

The derived parameters section contains definitions of one or more parameters that can be derived from the user parameters.

For example: < DERIVED PARAMETER < NAME > Area < /NAME > < DEFINITION > Length * Width < /DEFINITION > < /DERIVED PARAMETER < DERIVED PARAMETER < NAME > SectionlLength < /NAME > < DEFINITION > Length * 0. 7 < /DEFINITION > < /DERIVED PARAMETER The first of these defines a parameter"Area", calculated by multiplying together the parameters"Length"and"Width". The second defines a parameter"SectionlLength", calculated by multiplying the parameter"Length"by 0.7.

The stage breakdown section (if present) defines the stages (or phases) into which the project can be broken down, and the circumstances under which the project should be sub-divided.

Each stage is implemented as a specified sub-recipe.

For example, when laying a concrete base, if the area is more than 10 square metres it may be appropriate to divide the task into sub-projects, such as preparing the ground and then laying the base. However, if the area to be laid is just 2 square metres, it may not be worth such a sub-division. This would be defined as follows: < BREAKDOWN > < CONDITION > Area > 10 < /CONDITION > < STAGE > < STAGE ID > 1 < /STAGE ID > < RECIPE > Prepare Ground < /RECIPE > < /STAGE > < STAGE > < STAGE ID > 2 < /STAGE ID > < RECIPE > Lay Base < /RECIPE > < /STAGE > < /BREAKDOWN > The ingredients section defines how to calculate the required quantity for each ingredient in the recipe, depending on the size of the project as specified by the user parameters and derived parameters. This will be described in more detail later.

The method of execution section is used to generate a text description of how to perform the tasks required in the project. This method is defined in a structured markup language to enable customisation.

Two basic tags are used to permit the customisation. The first is a < CUSTOM VALUE > tag, which enables one or more custom values to be defined in terms of the user parameters or derived parameters. For example: < DEFINITION > < CUSTOM VALUE NAME > Drying Time < /CUSTOM VALUE NAME > < CUSTOM VALUE DEFINITION > Volume * 60 < /CUSTOM VALUE DEFINITION > < /DEFINITION > This defines the custom value"Drying Time"to be the"Volume" (a user or derived parameter) multiplied by 60.

This custom value can then be used in the active recipe page as follows: "The concrete must then be allowed to set for < CUSTOM VALUE > Drying Time < /CUSTOM VALUE > minutes." When the customised recipe is generated, the appropriate Drying Time value will be inserted into the text.

User parameters and derived parameters can also be inserted into the text, for example: "Start by digging a trench < PARAMETER > Length < /PARAMETER > metres long." The other form of customisation of the method of execution is to determine which text is used based on the user or derived parameters. For example, in a recipe describing how to construct a fence, the following generic recipe description may appear: < CONDITIONAL INSTRUCTION > < CONDITION > Length > 2 < /CONDITION > < CONDITIONAL TEXT > Put additional fence posts at two metre intervals < /CONDITIONAL TEXT > < /CONDITIONAL INSTRUCTION > This indicates that the extra line of text concerning addition fence posts every two metres is to appear only if the condition is true, i. e. if the length is greater the two metres.

The post-execution tasks section defines any tasks that may be performed some time after completion of the project. These may comprise, for example, maintenance tasks that have to be performed periodically after the project is complete.

The definition of these post-execution tasks includes the time when they should be performed first and, where appropriate, how often they should be repeated. These post-execution tasks may simply be added to a scheduling system as text entries, or may be added as future projects. Post-execution tasks may include user or derived parameters.

An example of a post-execution task would be to creosote a fence six months after construction, and then to repeat this task every two years. The amount of creosote required could be calculated based on the size of the fence, using a custom value defined as described above. This post-execution task could be defined as follows: < POST-EXECUTION TASK > < FIRST OCCURRENCE > 6 months < /FIRST OCCURRENCE > < REPEAT OCCURRENCE > 24 months < /REPEAT OCCURRENCE > < TASK TYPE > Project < /TASK TYPE > < TASK DESCRIPTION > Creosote Fence < /TASK DESCRIPTION > < TASK PARAMETER > Fence Area = < CUSTOM VALUE > Fence Area < /CUSTOM VALUE > < /TASK PARAMETER > < /POST-EXECUTION TASK > In this case, the Task Type is "Project", which means that the post-execution task should be scheduled as a new project for the customer. Alternatively, if Task Type were"Text", the post execution task would simply be entered as a text item in the customer's schedule.

Ingredients calculation As mentioned above, the ingredients section of the active recipe page defines how to calculate the required quantity for each ingredient in the recipe, depending on the size of the project.

Each calculation is based on one of a number of scaling algorithms: linear, stepped, ranged, custom and fixed. Each of these scaling algorithms has a corresponding definition format as will now be described.

Linear scaling-the quantity of the ingredient varies in direct proportion to a user parameter or derived parameter. For example, the amount of ready-mix concrete required varies in direct proportion to the volume of hole to be filled: < INGREDIENT > < NAME > Ready mix concrete < /NAME > < SCALE TYPE > Linear < /SCALE TYPE > < SCALE PARAMETER > Volume < /SCALE PARAMETER > < SCALE FACTOR > 2 < /SCALE FACTOR > < /INGREDIENT > This means that for the ingredient"Ready mix concrete", the system will take the calculated or user parameter called "Volume"and multiply it by the scale factor (2) to calculate the customised quantity.

Stepped scaling-the quantity of the ingredient varies in steps according to the value of a parameter. For example, the number of fence posts required may be one for each end of the fence plus one more for each two metres of fence: < INGREDIENT > < NAME > Fence post < /NAME > < SCALE TYPE > Stepped < /SCALE TYPE > < SCALE PARAMETER > Fence Length < /SCALE PARAMETER < MINIMUM > 2 < /MINIMUM > < STEP > 2 < /STEP > < STEP AMOUNT > l < /STEP AMOUNT > < /INGREDIENT > This means that for the ingredient "Fence Post", a minimum of 2 will always be required. In addition, the STEP AMOUNT, 1, is to be added for each additional 2 metres of"Fence Length".

Ranged scaling-the quantity of the ingredient varies irregularly depending on the range of a parameter. For example: < INGREDIENT > < NAME > Nails < /NAME > < SCALE TYPE > Ranged < /SCALE TYPE > < SCALE PARAMETER > NoOfPanels < /SCALE PARAMETER < RANGE > < LOWER LIMIT > 1 < /LOWERLIMIT > < UPPER LIMIT > 4 < /LOWERLIMIT > < VALUE > 1 < /VALUE > < /RANGE > < RANGE > < LOWER LIMIT > 5 < /LOWERLIMIT > < UPPER LIMIT > 10 < /LOWERLIMIT > < VALUE > 2 < /VALUE > < /RANGE > < /INGREDIENT > This means that for the ingredient"Nails", the system checks the user or derived parameter"NoOfPanels"against each of the ranges listed. If NoOfPanels is between 1 and 4, the quantity is 1 (pack of 100), if it is between 5 and 10, the quantity is 2 (packs of 100).

Custom scaling-the quantity of the ingredient is specified by a custom algorithm, based on one or more factors.

The implementation of custom scaling is of a more bespoke nature depending on the type of ingredient. For example, it may involve performing a calculation on two parameters and then using a linear scaling on the calculated result. In other cases, custom scaling may require changes in the definition of the ingredient rather than simply the quantity. For example, in planning the insulation of a loft, two parameters (e. g. the width and length of the area) may determine the area to be covered, whereas a third parameter (e. g. the thickness of existing insulation) may determine the overall volume required, so that a named function can be called to determine the number of rolls required.

< INGREDIENT > < NAME > Insulation < /NAME > < SCALE TYPE > Custom < /SCALE TYPE > < SCALE FUNCTION > InsulationCalc < /SCALE FUNCTION < FACTOR > < NAME > Length < /NAME > < VALUE > 20 < /VALUE > < /FACTOR > < FACTOR > < NAME > Width < /NAME > < VALUE > 12 < /VALUE > < /FACTOR > < FACTOR > < NAME > ExistingThickness < /NAME > < VALUE > 50 < /VALUE > < /FACTOR > < /SCALE FUNCTION > < /INGREDIENT >

Fixed - the quantity of the ingredient does not vary. For example, if the quantity of the ingredient"Water"is not affected by the size of the project (e. g. because it is specified in terms of a required consistency, rather than by volume), this would be defined as follows: < INGREDIENT > < NAME > Water < /NAME > < SCALE TYPE > Fixed < /SCALE TYPE > < QUANTITY > 1 < /QUANTITY > < /INGREDIENT > Stock file The stock file 16 defines a number of items, stocked for sale by the DIY store, which can be used as ingredients for the projects. This file contains a series of stock item definitions, such as, for example: < STOCK ITEM > < STOCK NAME > Nails < /STOCK NAME > < PACK > < SIZE > 24 < /SIZE > < PRICE > 0.25 < /PRICE > < /PACK > < PACK > < SIZE > 100 < /SIZE > < PRICE > 0.70 < /PRICE > < /PACK > < PACK > < SIZE > 500 < /SIZE > < PRICE > 3.20 < /PRICE > < /PACK > < /STOCK ITEM >

This means that for the ingredient"Nails", the store stocks a pack of 24 costing LO. 25, a pack of 100 costing LO. 70 and a pack of 500 costing E3. 20.

Operation The operation of the system will now be described with reference to Figure 2.

(Step 20) The customer accesses the DIY website and selects a construction project to perform. This can be done using a web browser, or by way of an Interactive Television link, from a DIY television programme. Details of the selected project are stored in the customer's project file 17. Alternatively, the customer may select a project previously stored in the customer's project file.

(Step 21) When a project is selected, the corresponding active recipe page 15 for that project is accessed. This in turn calls the XML processor 18, which will process the active recipe page as follows.

(Step 22) The XML processor generates a form which enables the customer to enter any user parameters defined in the user parameters section of the active recipe page. These parameters may for example be entered using a text box, or selected from a drop-down list. The parameters are stored in the customer's project file.

(Step 23) The XML processor then calculates any derived parameters defined in the derived parameters section of the active recipe page.

(Step 24) The XML processor then accesses the stage breakdown section of the active recipe page, if any, and uses this to determine whether the project needs to be split into phases. If so, each of these phases is progressed as a sub-recipe.

(Step 25) The XML processor then accesses the ingredients section of the active recipe page, and uses this (along with the user and derived parameters obtained in the previous steps) to calculate the required quantity of each of the ingredients.

(Step 26) The XML processor then accesses the stock file 16, and uses this (along with the ingredient quantities calculated in the preceding step) to generate a customised, costed bill of materials for the customer, as well as the overall cost of the project.

It is unlikely that the DIY store will produce packs of exactly the right size for all ingredients. The system may calculate the smallest pack size that contains the required quantity.

Alternatively, the system may calculate the cheapest way to purchase the required quantity, for example by working through different combinations of the pack sizes to identify the best price. In the above example, if the number of nails required was 60, the system would calculate the cheapest option to be a purchase of a pack of 100 at EO. 70 rather than three packs of 24 at a total cost of LO. 75.

(Step 27) The XML processor then accesses the method of execution section of the active recipe page, and uses this to generate a customised text description of how to perform the tasks required in the project. The description is stored in the customer's project file.

(Step 28) The XML processor then accesses the post-execution tasks section of the active recipe page, and uses this to generate and schedule any required post-execution tasks. These tasks are stored in the customer's project file.

(Step 29) The XML processor then makes the customised recipe (i. e. the customised bill of materials and text description) available to the customer. There are various methods for this, including: 'Making it available via the Internet.

'Downloading it to a customer's Personal Computer

'Printing it out at home or in a DIY store 'Downloading it to a customer's Personal Digital Assistant (PDA) The customised bill of materials may also be sent electronically to one or more DIY stores to permit easier purchasing of the items. This may include: 'Online ordering and home delivery 'Staff in the store picking the items for collection by the customer

Production of a routing map around the store to enable quick picking of the items by the customer Some possible modifications It will be appreciated that many modifications may be made to the system described above without departing from the scope of the present invention.

One extension is to types of recipe other than DIY, for example cooking, where a user may need to scale a generic recipe to a specific number of servings. Whilst applications already exist which include simple linear scaling of quantities of ingredients, this invention would also permit the method of execution to be customised, for example including a longer cooking time for larger quantities, together with the far wider range of scaling possibilities (stepped, ranged, custom, fixed).

The equivalent of breaking down a construction project into stages could include breaking down the cooking of a large number of servings into a number of batches.

Instead of accessing the system over the Internet from their home PCs, the customers may access the system by other means, such as through a terminal in the DIY store, connected by a local area network (LAN) to the server. Alternatively, the active recipe system may be implemented as a stand-alone program, running on the customer's PC.

The active recipes may also contain information about skills, techniques and tools associated with each DIY project. These may be specified by corresponding sections of the active recipe (similar to the ingredients section described above), which in turn reference other files defining these skills, techniques and tools. The system may also allow the user to purchase any required tools on-line, in addition to the ingredients for the project.

The active recipes may also provide notices associated with the DIY projects. These define statements that the user needs to be aware of, such as safety, environmental, and legal notices.

Notices may be handled as a form of post-execution task.

Claims (28)

1. CLAIMS 1. A computer-implemented method for generating a recipe, comprising the steps: (a) storing at least one generic definition of a recipe ; (b) enabling a user to input a set of parameters specifying the user's requirements in relation to the recipe; and (c) combining the generic definition with the user's requirements, to generate a customised recipe for the user.
2. 2. A method according to Claim 1, including the step of deriving one or more further parameters from the parameters entered by the user.
3. 3. A method according to either preceding claim, including subdividing the recipe into a number of smaller recipes depending on the values of one or more of said parameters.
4. 4. A method according to any preceding claim, including generating a list of ingredients, and customising the quantities of each of the ingredients dependent on the values of one or more of the said parameters.
5. 5. A method according to Claim 4 wherein the types of customisation of the quantities of ingredients include one or more of the following: (a) linear scaling, where the quantity of the ingredient varies in direct proportion to a parameter; (b) stepped scaling, where the quantity of the ingredient varies in steps according to the value of a parameter ; (c) ranged scaling, where the quantity of the ingredient is varies dependent on range in which a parameter falls; (d) custom scaling, where the quantity of the ingredient is specified by a custom algorithm based on the value of one or more parameters; and (e) fixed, where the quantity of the ingredient does not vary.
6. 6. A method according to Claim 4 or 5, including calculating the smallest pack size required for an ingredient, based on the available pack sizes.
7. 7. A method according to any of Claims 4 to 6, including calculating the cost of each of the ingredients.
8. 8. A method according to any preceding claim, including generating a description of a method of execution of the recipe, said description being customised dependent on the value of one or more of the said parameters.
9. 9. A method according to Claim 8 wherein the customisation of the method of execution includes one or more calculated custom values based on one or more of the said parameters.
10. 10. A method according to Claim 8 or 9 wherein the customisation of the method of execution includes conditional steps which are included or excluded based on the conditions including one or more of the said parameters.
11. 11. A method according to any preceding claim, including generating one or more post-execution tasks.
12. 12. A method according to Claim 11 wherein the post-execution tasks are separate projects.
13. 13. A method according to Claim 11 or 12 wherein the postexecution tasks are customised according to one or more of said parameters.
14. 14. A method according to any of Claims 11 to 13 wherein the post-execution tasks are scheduled to repeat at defined intervals.
15. 15. A method according to any preceding claim, wherein the customised recipe is made available on an Internet site for the customer.
16. 16. A method according to any preceding claim, including printing out the customised recipe for the customer.
17. 17. A method according to any preceding claim, wherein the customised recipe is delivered to the customer's personal computer or Personal Digital Assistant.
18. 18. A method according to any preceding claim, including delivering the customised recipe to a retail store to facilitate the purchase of the ingredients.
19. 19. A method according to Claim 18 including enabling the ingredients to be purchased online for delivery to the customer.
20. 20. A method according to Claim 18 including preparing the customised set of ingredients in the retail store for collection by the customer.
21. 21. A method according to Claim 18 including preparing a customised route plan of the store showing the quickest route to purchase the required ingredients.
22. 22. A method according to any preceding claim, wherein the recipe is selected after being viewed on a broadcast TV show.
23. 23. A method according to Claim 22 wherein the recipe is selected using an interactive television service.
24. 24. A method according to any preceding claim, wherein the generic definition comprises a document in a structured markup language, defining one or more of the following: (a) one or more parameters to be entered by the user; (b) one or more further parameters, to be derived from the parameters entered by the user; (c) the circumstances in which the recipe is to be subdivided into a number of smaller recipes, and the way it is to be subdivided; (d) the manner in which a customised list of ingredients is to be generated; (e) the manner in which a customised description of the method of execution of the recipe is to be generated; and (f) one or more post-execution tasks to be performed after completion of the recipe.
25. 25. A method according to Claim 23 wherein the structured markup language is XML (Extensible Markup Language).
26. 26. A method according to any preceding claim, including providing information on skills, techniques, tools and notices associated with the recipe.
27. 27. A computer system comprising means for performing a method according to any preceding claim.
28. 28. A method or system substantially as hereinbefore described with reference to the accompanying drawings.