METHOD AND SYSTEM FOR HIDING SENSITIVE DATA WITHIN MODELS IN AN ELECTRONIC SPREADSHEET ENVIRONMENT

Field of the invention the present invention is directed to the field of electronic spreadsheets and more particularly to a method, system and computer program for hiding sensitive data within models in an electronic spreadsheet environment.

Background of the invention

Before computers, numerical analyses, particularly financial ones, were usually prepared on an accountant's columnar pad or spreadsheet, with pencil and calculator in hand. By organizing data into columns and rows, spreadsheets afford the rapid assimilation of information by a reader. The task of preparing a spreadsheet on paper, however, is not quite so fast. Instead, the process tends to be very slow, as each entry must be tediously calculated and entered into the spreadsheet. Manually prepared spreadsheets are also prone to errors. Hence, preparation of spreadsheets by hand is slow, tedious, and unreliable.

With the advent of microcomputers, a solution was forthcoming in the form of "electronic spreadsheets." Better known simply as "spreadsheets," these software programs provide a computerized replacement for the traditional financial modelling tools: the accountant's columnar pad, pencil, and calculator. In some regards, spreadsheet programs are to those tools what word processors are to typewriters. Spreadsheets offer dramatic improvements in ease of creating, editing, and using financial models.

A typical spreadsheet program configures the memory of a computer to resemble the column/row or grid format of an accountant's columnar pad, thus providing a visible calculator for a user. Because this "pad" exists dynamically in the computer's memory, however, it differs from paper pads in several important ways. Locations in the electronic spreadsheet, for example, must be communicated to the computer in a format which it can understand. A common scheme for accomplishing this is to assign a number to each row in a spreadsheet, and a letter to each column. To reference a location at column A and row 1 (i.e., the upper-left-hand corner), for example, the user types in "Al".

In this manner, the spreadsheet defines an addressable storage location or "cell" at each intersection of a row with a column.

Data entry into an electronic spreadsheet occurs in much the same manner that information would be entered on an accountant's pad. After a screen cursor is positioned at a desired location, the user can enter alphanumeric information. Besides holding text and numeric information, however, spreadsheet cells can store special instructions or "formulas" specifying calculations to be performed on the numbers stored in spreadsheet cells. In this fashion, cell references can serve as variables in an equation, thereby allowing precise mathematical relationships to be defined between cells. The structure and operation of a spreadsheet program, including advanced functions such as functions and macros, are documented in the technical, trade, and patent literature. For an overview, see e.g., Cobb, S., Using Quatiro Pro 2, Borland-OsbomelMcGraw-MII, 1990; and LeBlond, G. and Cobb, D., Using 1-2-3, Que corp., 1985. The disclosures of each of the foregoing are hereby incorporated by reference.

Electronic spreadsheets offer many advantages over their paper counterparts. For one, electronic spreadsheets are much larger (i.e., hold more information) than their paper counterparts; electronic spreadsheets having thousands or even millions of cells are not uncommon. Spreadsheet programs also allow users to perform "what-if scenarios. After a set of computational relationships has been entered into a worksheet, thanks to imbedded formulas for instance, the spread of information can be recalculated using different sets of assumptions, with the results of each recalculation appearing almost instantaneously. Performing this operation manually, with paper and pencil, would require the recalculation of every relationship in the model with each change made. Electronic spreadsheet systems are well suited to solve "what-if problems, that is, changing an input and seeing what happens to an output.

Electronic spreadsheets are commonly used for implementing costing and pricing tools, typically for service oriented offerings. Such tools are simply an implementation of a model (either a costing model or a pricing model) featuring a set of output data, based on a set of input data. Among the input data, different types must be distinguished:

• Scope data, which is specific to a quotation and which quantifies the scope of service to be delivered. A typical scope data is for instance the number of objects to be managed, for a remote management offering.

• Model data, specifying parameters which are not scope dependent, but rather model dependent. A typical model data is for instance a labour rate, giving the hourly cost for a person with a given skill level.

Costing / pricing models can be quite complex and the resulting spreadsheet tool can also be complex, involving a large number of formulas spreading across different sheets. Such formulas involve intermediary results, themselves involving either input data (scope data or model data), or other intermediary data. Such intermediary result data may constitute a tree with a rather complex structure. The output data can be seen as a trunk and the input data as leaves on branches of the tree.

If a costing / pricing tool spreadsheet is disclosed to a person, this person can easily "reverse engineer" this tool to determine all the different intermediary results which are part of the model. Such intermediary results can contain confidential information

(typically the model data) that the costing/pricing tool spreadsheet author does not want to share with third parties. Nevertheless he/she may want to share a tool which produces the output data when fed with the scope data.

A typical example corresponding to this case is the following. Let's assume that a company X is currently delivering an offering through direct sales channel, and wants to rely on indirect channels, like business partners, to reach a wider opportunity base. If an internal cost / price model is disclosed to a business partner, then this business partner will easily access information that this company X refuses to disclose. On the contrary, every effort must be done by the company X to give to this business partner all the relevant tools streamlining the sales cycle, such as a costing/pricing tool.

This dilemma cannot be solved with conventional spreadsheet tools, knowing even more that spreadsheet protection can easily be broken by cracks available on the Internet.

The problem is to build (within an electronic spreadsheet) a tool implementing a costing/pricing model:

• giving to the tool user a limited visibility on the model internals,

• while maintaining full control of all the parameters, including the model data, for the tool author.

Objects of the invention

• It is an object of the present invention to specify within an electronic spreadsheet, the cells containing either an output data, or a scope data or a model data.

• It is a further object of the present invention to build an internal table representing a sequence of intermediary results establishing a set of hierarchical relationships between the output data and both the scope and model data.

• It is a further object of the present invention to establish a relationship tying directly the output data from the scope and model data.

• It is a further object of the present invention to specify which model data must be hidden.

• It is a further object of the present invention to establish a relationship tying directly the output data from the scope data and from the not hidden model data.

• It is a further object of the present invention to remove cells referencing either intermediary results or hidden model data, so that the resulting electronic spreadsheet file only comprises the output data, the scope data and the not hidden model data.

Summary of the invention

The present invention is directed to a system and method, as defined in independent claims.

More particularly, the present invention is directed to a method for hiding sensitive data of a model in an electronic spreadsheet. The method comprises the steps of :

• identifying a model in a spreadsheet, this model comprising :

• one or plurality of cells comprising input data; • one or a plurality of cells comprising intermediary results, each intermediary result being defined as the result of an equation comprising as arguments, one or a plurality of input data and/or one or a plurality of intermediary results;

• a cell comprising output data defined as the result of an equation comprising as arguments, one or a plurality of input data and/or one or a plurality of intermediary results;

• establishing equations for intermediary results comprising only input data as arguments;

• establishing an equation for output data comprising only input data as arguments;

• removing the content of cells comprising intermediary results, so that the resulting model only comprises :

• one or plurality of cells comprising input data;

• a cell comprising output data defined as the result of an equation comprising only input data as arguments.

Further embodiments of the invention are provided in the appended dependent claims.

The foregoing, together with other objects, features, and advantages of this invention can be better appreciated with reference to the following specification, claims and drawings.

Brief description of the drawings

The novel and inventive features believed characteristics of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative detailed embodiment when read in conjunction with the accompanying drawings, wherein:

• Figure 1 A is a block diagram of a computer system in which the present invention can be embodied.

• Figure 1B is a block diagram of a software system including an operating system, an application software, and a user interface for carrying out the present invention.

• Figure 1C illustrates the basic architecture and functionality of a graphical user interface in which the present invention may be embodied.

• Figure 2A shows a spreadsheet notebook interface used in the preferred embodiment of the present invention.

• Figure 2B shows the toolbar component of the notebook interface shown in Figure 2 A.

• Figures 2C and 2D show page identifiers for rapidly accessing and manipulating individual pages of the notebook interface shown in Figure 2A.

• Figure 3 is a block diagram illustrating the hierarchical relationships between input data and output data.

• Tables 4A, 4B, 4C, 4D, and 4E respectively show examples of scope data, model data, output data and two sets of intermediary result data.

• Table 5 specifies with the help of an example, the various relationships established between different data.

• Figure 6 is a block diagram showing an example of tree structure along which are organized the data.

• Figure 7 is a flow chart illustrating the method according to the present invention.

Preferred embodiment of the invention

The following description is presented to enable one or ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.

HARDWARE As shown in FIG. 1 A, the present invention may be embodied on a computer system 100 comprising a central processor 101, a main memory 102, an input/output controller 103, a keyboard 104, a pointing device 105 (e.g., mouse, track ball, pen device, or the like), a display device 106, and a mass storage 107 (e.g., hard disk). Additional input/output devices, such as a printing device 108, may be included in the system 100 as desired. As illustrated, the various components of the system 100 communicate through a system bus 110 or similar architecture.

Illustrated in FIG. 1B, a computer software system 150 is provided for directing the operation of the computer system 100. Software system 150, which is stored in system memory 102 and on disk memory 107, includes a kernel or operating system 151 and a shell or interface 153. One or more application programs, such as application software 152, may be "loaded ¹ (i.e., transferred from storage 107 into memory 102) for execution by the system 100. The system 100 receives user commands and data through user interface 153; these inputs may then be acted upon by the system 100 in accordance with instructions from operating module 151 and/or application module 152. The interface 153, which is preferably a graphical user interface (GUI), also serves to display results, whereupon the user may supply additional inputs or terminate the session. In a preferred embodiment, operating system 151 and interface 153 are Microsoft Win95, available from Microsoft Corporation of Redmond, Wash. Application module 152, on the other hand, includes a spreadsheet notebook of the present invention as described in further detail herein below.

INTERFACE Introduction

The following description will focus on the presently preferred embodiments of the present invention, which are embodied in spreadsheet applications operative in the Microsoft Windows environment. The present invention, however, is not limited to any particular application or any particular environment. Instead, those skilled in the art will find that the system and methods of the present invention may be advantageously applied to a variety of system and application software, including database management systems, word processors, and the like. Moreover, the present invention may be embodied on a variety of different platforms, including Macintosh, UNIX, NextStep, and the like. Therefore, the description of the exemplary embodiments which follows is for purposes of illustration and not limitation.

Referring now to FIG. 1C, the system 100 includes a windowing interface or workspace 160. Window 160 is a rectangular, graphical user interface (GUI) for display on screen 106; additional windowing elements may be displayed in various sizes and formats (e.g., tiled or cascaded), as desired. At the top of window 160 is a menu bar 170 with a plurality of user-command choices, each of which may invoke additional submenus and software tools for use with application objects. Window 160 includes a client area 180 for displaying and manipulating screen objects, such as graphic object 181 and text object 182. In essence, the client area is a workspace or view port for the user to interact with data objects which reside within the computer system 100.

Windowing interface 160 includes a screen cursor or pointer 185 for selecting and otherwise invoking screen objects of interest. In response to user movement signals from the pointing device 105, the cursor 185 floats (i.e., freely moves) across the screen 106 to a desired screen location. During or after cursor movement, the user may generate user-event signals (e.g., mouse button "clicks" and "drags") for selecting and manipulating objects, as is known in the art. For example, Window 160 may be closed, resized, or scrolled by "clicking" (selecting) screen components 172, 174/5, and 177/8, respectively.

In a preferred embodiment, screen cursor 185 is controlled with a mouse device. Single-button, double-button, or triple-button mouse devices are available from a variety of vendors, including Apple Computer of Cupertino, California., Microsoft Corporation of Redmond, Wash., and Logitech Corporation of Fremont, California., respectively. More preferably, screen cursor control device 105 is a two-button mouse device, including both right and left "mouse buttons."

Programming techniques and operations for mouse devices are well documented in the programming and hardware literature; see e.g., Microsoft Mouse Programmer's Reference, Microsoft Press, 1989. The general construction and operation of a GUI event-driven system, such as Windows, is also known in the art: see, e.g., Petzold, C, Programming Windows, Second Edition, Microsoft Press, 1990. The disclosures of each are hereby incorporated by reference.

Preferred interface

Shown in FIG. 2A, a spreadsheet notebook interface of the present invention will now be described The spreadsheet notebook or workbook of the present invention includes a notebook workspace 200 for receiving, processing, and presenting information, including alphanumeric as well as graphic information. Notebook workspace 200 includes a menu bar 210, a toolbar 220, a current cell indicator 230, an input line 231 , a status line 240, and a notebook window 250. The menu bar 210 displays and invokes, in response to user inputs, a main level of user commands. Menu 210 also invokes additional pull down menus, as is known in windowing applications. Input line 231 accepts user commands and information for the entry and editing of cell contents, which may include data, formulas, macros, and the like. Indicator 230 displays an address for the current cursor (i.e., active cell) position. At the status line 240, system 100 displays information about the current state of the workbook; for example, a "READY" indicator means that the system is ready for the user to select another task to be performed.

The toolbar 220, shown in further detail in FIG. 2B, comprises a row or palette of tools which provide a quick way for the user to choose commonly-used menu commands or properties. In an exemplary embodiment, toolbar 220 includes file manipulation buttons 221, printing buttons 222, an undo button 223, cut, copy, and paste buttons 224,

information pop-up window buttons tool 225, a range selection button 226, a style copy button 227, a column resizing button 228, and a sum button 229. The functions of these buttons are suggested by their names. For instance, buttons 224 cut, copy and paste data and objects to and from Windows' clipboard. The same actions are also available as corresponding commands in the Edit menu (available from menu bar 210).

The notebook, which provides an interface for entering and displaying information of interest, includes a plurality of spreadsheet pages. Each page may include conventional windowing features and operations, such as moving, resizing, and deleting. In a preferred embodiment, the notebook includes 256 spreadsheet pages, all of which are saved as a single disk file on the mass storage 107. Workspace 200 may display one or more notebooks, each sized and positioned (e.g., tiled, overlapping, and the like) according to user-specified constraints.

Each spreadsheet page of a notebook includes a 2-D spread. Page A from the notebook 200, for example, includes a grid in row and column format, such as row 3 and column F. At each row/column intersection, a box or cell (e.g., cell C4) is provided for entering, processing, and displaying information in a conventional manner. Each cell is addressable, with a selector being provided for indicating a currently active one (i.e., the cell that is currently selected).

As shown in FIGS. 2C-D, individual notebook pages are identified by page identifiers 260, preferably located along one edge of a notebook. In a preferred embodiment, each page identifier is in the form of a tab member (e.g., members 261a, 262a, 263a) situated along a top edge of the notebook. Each tab member may include representative indicia, such as textual or graphic labels, including user selected titles representing the contents of a corresponding page. In FIG. 2C, the tab members 260 are set to their respective default names. For example, the first three tab members (members 261a, 262a, 263a) are respectively set to A, B, and C. Tab members are typically given descriptive names provided by the user, however. As shown in FIG. 2D, for example, the first three tab members have now been set to "Contents" (tab member 261b), "Summary" (tab member 262b), and "Jan" (tab member 263b). In a similar manner, the remaining tabs are set to subsequent months of the year. In this manner, the user associates the page

identifiers with familiar tabs from an ordinary paper notebook. Thus, the user already knows how to select a page or spread of interest: simply select the tab corresponding to the page (as one would do when selecting a page from a paper notebook).

In addition to aiding in the selection of an appropriate page of information, the user-customizable page identifiers serve aid in the entry of spreadsheet formulas. For example, when entering a formula referring to cells on another page, the user may simply use the descriptive page name in the formula itself (as described herein below), thus making it easier for the user to understand the relationship of the cell(s) or information being referenced.

A general description of the features and operation of the spreadsheet notebook interface may be found in Quattro Pro for Windows (Getting Started, User's Guide and Building Spreadsheet Applications), available from Borland International.

HIDING SENSITIVE DATA WITHIN MODEL Assumption It will be assumed that a single output data is provided by the model under study. For real cases where several output data are featured, the model can be considered as a collection of different models, where each of them specifies a single output data.

Notation

Let first introduce some notations and naming conventions which will ease the understanding of the present invention.

• OD corresponds to the output data.

• [SD ₁ ] corresponds to the set of scope data. Here it is assumed that several of these

scope data are part of the model under study. Scope data is identified by an index i.

• [MD _J }corresponds to the set of model data. Here it is assumed that several of these

model data are part of the model under study. Model data is identified by an index j.

• {/iζjcorresponds to the set of intermediary results. Here it is assumed that several

of these intermediary results are part of the model under study. Intermediary results are identified by an index k.

The different relationships defined between the above data correspond to the different formulas found within the electronic spreadsheet cells hosting these data. These relationships are also formally represented by mathematical functions, as follows:

It must be noted that all the available input data ([SD ₁ ] and \MD _} \) are not necessarily

present in the above formula. The same remark also applies for the formula translating the relationship defining the intermediary data (see below).

As it is assumed that there is no circular reference (that is a data which is a function of itself) in the electronic spreadsheet, some intermediary results are such that:

This means that these intermediary results only rely on the input data.

This way, the set of relationships can be formalized through a tree structure, as shown in Figure 3. This kind of tree structure defines a hierarchy between a lowest level, corresponding to the output data OD 301, and arbitrarily set to 1 , and a highest level corresponding to an intermediary result which is the deeper in the sequence of antecedents. Within the case illustrated by the Figure 3, a first intermediary result IRkI 302 is at level 2, while the level 3 corresponds to a second intermediary result IRk2 304, to a scope data SDi 303 and to a model data MDj 305. Conventional techniques, not described here, are available to assign such levels.

Principle of the invention

The principle of the invention is to rely on computer algebra along the following sequence of steps.

A. The first step consists in building a relationship (equation) where the output data only depends on the input data, as follows:

OD = F (SD _i ,MD _J ) (4)

This can be done by recursively replacing in each equation of type (2)

IR _kχ = F _k (SD _l ,MD _J ,IR _k ) each argument IR _k by the corresponding equation of

either type (2) m _k = F _k \SD _l ,MD _J ,IR _k ) or type (3) I\ = F^SD ₁ MD ₃ ).

For instance, • if each argument IR _k is replaced by an equation of type (2)

IR _k1 = F _k1 (SD _i ,MD _j ,IR _k ), the step will consist in building the following relationships IRki = FM(SD ₁ ,MD ₁ ,Fk(SD ₁₁ MD ₁ ,IRk)). In the present case, all the resulting equations are of type (2). The next step will consist again in replacing each argument IR _k of each equation of type (2) by an equation either of type (2) or (3). This iterative process ends when each argument can be defined by an equation of type (3) and when the output data can be represented in an equation of type (4).

• if each argument IR _k is replaced by an equation of type (3)

IR _k2 - F _k XsD^MD _j ) _^ the step will consist in building the following relationships IRki = F _k i(SD, ,MD ₁ ,Fk(SD ₁₁ MD ₁ )) which are equations of type (3). The next step consists in replacing in equation of type (1 ) all the arguments IR _k by the corresponding equations of type (3) to obtain an equation of type (4).

• if at least one argument IR _k is replaced by an equation of type (2)

IRk ₁ = ^F k _x \ ^SD ι-> ^MD j>I ^R k), at least one of the resulting equations will be of type (2). The next step will consist in replacing each argument IR _k of each

equation of type (2) by an equation either of type (2) or (3). This iterative process ends when each argument can be defined by an equation of type (3) and when the output data can be represented in an equation of type (4).

B. The second step consists in simplifying the equation (4) OD = F ySD ₁₇ MD _j ) through conventional techniques available in computer algebra, such as factorisation.

Note: these two first steps A and B can be advantageously nested, so that the formula can be simplified as soon as possible.

C. The third step consists in substituting within the equation (4) OD = F[SD ₁₇ MD _j ) ₁ the model data to be hidden by their values, in order to hide this model data from the user,

D. The fourth step consists in simplifying (again thanks to computer algebra) the resulting formula. For instance, if all the model data are replaced by their values, then the resulting model will be reduced to what is targeted : a formula where only scope data are used as parameters, as follows:

OD = F (SD ₁ ) (5)

The resulting new formula (5) OD = F (SD ₁ ) supersedes the set of formulas corresponding to the equations (1 ), (2) and (3). These equations (1 ), (2) and (3) can be simply removed from the electronic spreadsheet file by deleting the content of the corresponding cells. Obviously the resulting data needs to be recorded in a new file, to avoid the loss of the root information made by the equations (1), (2) and (3).

Computer algebra is today a well known technique, available either within commercial product such as "Maple", "Mathematica", "MatLab", and "MuPad", or as sharewares like "Yacas" (see http://yacas.sourceforge.net/yacas.html) or many other ones as pointed on the following page (http://www.toria.fr/"-'zimmerma/CalculFormel/). Such techniques are available in tools that can be easily interfaced by office applications, like electronic

spreadsheets, thanks to industry standard Application Programming Interfaces which can be invoked by macros. In the rest of this document, it will not assumed one particular tool, as most of them share a wide range of similar functions which fit our needs, related to formula simplification (for instance through factorisation techniques) or formula evaluation.

Example

The present invention will be described through an example derived from a real costing / pricing model in the field of remote network management.

• The scope data are described in Table 4A. They correspond : • to the duration of the service contract (scope data "year"),

• to the number of managed network devices (scope data "dev"), and

• to the number of customer locations (scope data "loc").

• The model data are described in Table 4B. They correspond to multiple variables specifying different cost drivers, such as : • hourly labor rates (model data "hrmon", "hrpb" and "hrrep"),

• hardware charges (model data "srvcost"),

• software license charges (model data "sfwfee").

• The output data is represented in Table 4C. It corresponds to a single output data giving the total contract value (output data "tcv"). • The intermediary results are represented by the two following tables 4D and 4E.

• The first table 4D comprises intermediary results corresponding to either monthly charges or one time charges.

• The second table 4E comprises intermediary results corresponding to yearly dependent cost drivers.

The relationships established between the output data, the intermediary results and the input data are specified according to the content of multiple cells within the cost model spreadsheet and correspond to the equations specified in Table 5. Each equation is identified through : a type, • a level,

a rank.

For instance the first equation tcv=mlc*year*12+otc (rank equal to 1) within this Table 5 translates the relationship used to determine the output data "tcv" from the scope data "year", and from the intermediary results "mlc" and "otc". This first equation receives the level 1 as it is at the top of the tree hierarchy, and is of type (1 ).

The previous relationships are summarized in the tree represented in Figure 6. This tree also specifies the levels defining the hierarchy between the different intermediary results. For instance the highest hierarchical level 1 corresponds to the output data "tcv" 601, the second level corresponds to the intermediary results "mlc" 602 and "otc" 603, and so on up to reach the lowest hierarchical level 12 corresponding to the intermediary result "coefl" 604.

Steps A and B

In the present example, the first two steps A and B, as previously described, are performed as follows, starting with the equation of highest level 12, that is "coef(1 )=1", followed down to level 7: coef(1) = 1 coef(2) = coef(\) x eff = lxeff = eff coef(3) = coef(2) χ _e ff = eff xeff = eff ² coef(4) = coef(3) x eff = eff ² x eff = eff ³ coef(5) = coefiA) χ eff = eff ³ χeff = eff ⁴ coef(6) = coef(5) x eff = eff ⁴ χ eff = eff ⁵

Note that in the previous equalities, steps A and B have been nested to allow the computer algebra algorithm to perform the simplification of the form a" ^'1 χa = a ⁿ .

Then, going on with the equations of level 6, starting with rank 31 to 36, and using the variable "i" as an integer between values 1 and 6:

Similarly we get for the equations of rank 25 to 30:

and for the equations of rank 19 to 24:

yielding for the equations of level 5 (rank 13 to 18):

Then the equations of level 4 can be written as:

Then the equations of level 3 can be written as:

Then the equations of level 2 write as:

For finally getting the formula of level 1 , giving the output data "tcv":

which shows that the output data "tcv" is derived from the input data ("year", "dev", "loc") by a function of the form:

where the capital letters represent constants.

Step C

Let assume now that the objective is to hide all the model data, except the "trv" one which specifies the average cost for travelling to the customer premises. The step C substitutes every model data (but "trv") in the former formula, by its corresponding value,

as follows:

Step D

The last step consists in feeding the computer algebra engine with the above formula, in order to perform the simplification of the expressions between brackets. This results into the following formula:

It is clear that nobody can "reverse engineer" this kind of formula to sketch the underlying model and cost drivers. So if a spreadsheet cell is filled with this formula, and if all the cells hosting intermediary results are removed, then the present problem is solved. Spreadsheet file according to the present invention comprises a faithful and working version of the original model, without disclosing any of its internal, sensitive information.

Method

As illustrated in the previous example, the present invention follows the method according to flow chart shown in Figure 7.

• At step 701 , the spreadsheet user is prompted to specify the cell which comprises the Output Data OD ■ We have assumed earlier that a single output data is produced by the model, so that a single cell must be specified within the electronic spreadsheet file. For model producing a plurality of output data, the present method can simply be repeated for each individual output data.

• At step 702, the spreadsheet user is prompted to specify the cells corresponding to the Scope Data [SD ₁ ]

• At step 703, the spreadsheet user is prompted to specify the cells corresponding to the Model Data [MD ₁ }

• At step 704, a so-called Intermediary Result Table (IRT for short) is created to record the set of intermediary results IR comprised in the spreadsheet and to link the output data with both the Scope Data and the Model Data. This IRT is made of a collection of records, each record comprising the following fields:

• a Cell Address field (CA for short). If the cell is named, then the cell name can replaces the cell address.

• a Cell Type field (CT for short).

• a Cell Level field (CL for short). • a Cell Content field (CC for short).

This table is build by starting with the first record corresponding to the output data, where the CL (Cell Level) defaults to 1. The creation of the following records comprises the steps of :

• parsing the formulas of the CC (Cell Content) field of already existing records; • identifying in the parsed formulas, variables which are neither a SD (Scope Data) nor a MD (Model Data). Such variables correspond to Intermediary Results (IR).

• for each created record corresponding to a given IR, the value given to the CL (Cell Level) field is equal to the highest value of the CL field of the parent IR, incremented by 1.

This process completes when for all the created records, the formula points to variables which are either SD or MD or recorded IR.

• At step 705, the computer algebra engine is fed with the formulas comprised in the CC fields of the IRT in order to build a formula of type (4) OD = F(SD ₁ , MD J. This is also done iteratively by starting feeding the computer algebra engine with the formulas CC of highest CL, and simplifying the last fed CC. This sequence of steps is illustrated in the previous example.

• At step 706, the resulting formula built by the computer algebra engine is recorded in a cell of the spreadsheet file, for instance within a cell previously void, or as a new version of the cell previously containing OD (Output Data).

• At step 707, the electronic spreadsheet user is prompted to specify which are the MD (Model Data) which need to be hidden. This can be done through conventional user interface techniques, such as pop-up windows and dialog box, or this can even be reduced to a void step, assuming by default that all the MD must be hidden (if it is not the case, then an input data is specified as Scope data in step 802.

• At step 708, the hidden MD are replaced by their values, within the formula recorded at step 706.

• At step 709, the computer algebra engine is fed with this formula (where hidden MD are replaced by their values) for simplification.

• At step 710, the simplified formula returned by the computer algebra engine is recorded in a cell of the spreadsheet file, with the same approach as for step 706.

• At step 711 , all the IR (intermediary result) cells (including obviously the original OD cell) and all the hidden MD cells are removed from the electronic spreadsheet file.

• At step 712, the user is prompted for renaming and saving the resulting updated file.

Particular embodiment

In a conventional costing / pricing tool, end users can easily determine all the different intermediary results which are part of the model. Such intermediary results can contain confidential information (typically the model data) that the costing/pricing tool spreadsheet author does not want to share with third parties. Nevertheless the author may want to share a tool which produces the output data when fed with the scope data.

The present invention can be advantageously used to share a a costing / pricing model with third parties without disclosing intermediary results can contain confidential information (typically the model data).

For instance a company X is currently delivering an offering through direct sales channel, and wants to rely on indirect channels, like business partners, to reach a wider opportunity base. Thanks to the present invention, it is possible to share with one or a plurality of business partners, an internal cost / price model while preserving the confidentiality of sensible information.

While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood that various changes in form and detail may be made therein without departing from the spirit, and scope of the invention.