GB2434223A

GB2434223A - User interface for customising an electronic product

Info

Publication number: GB2434223A
Application number: GB0526493A
Authority: GB
Inventors: Peter Truman; Michael Roper
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2005-12-29
Filing date: 2005-12-29
Publication date: 2007-07-18
Anticipated expiration: 2025-12-29
Also published as: GB0526493D0; GB2434223B; GB2434223C

Abstract

A system for customising an electronic product such as a mobile telephone (200 fig 2) comprises a customer requirements capture tool (210 fig 2) arranged to receive a customer's requirements electronically and display a plurality of customisation options to a customer; and a back-end processing function, operably coupled to the customer requirements capture tool (210 fig 2). The back-end processing function is arranged to control the plurality of customisation options displayed to the customer and process inputs entered onto the customer requirements capture tool (210 fig 2). The back-end processing function captures one or more digital resources selected by the customer and, in response thereto, arranges the customer requirements capture tool (210 fig 2) to display said one or more digital resources to the customer in enabling the customer to customise the electronic product.

Description

User Interface for customising an electronic product

Field of the Invention

This invention relates to providing a customer of an electronic product with the ability to completely specify their requirements for the design, construction and delivery of the product. This invention is applicable to, but not limited to, providing a manufacturer's user interface to support such customisation.

Background of Inventions

In the field of this invention it is known for manufacturers and the like to attain a business advantage by being able to produce (in both mass and small volume down to single unit) products to the specific requirements of a customer. For example, for a mobile phone manufacturer it is desirable to produce a customised product for supply to a mobile phone operator, distributor or individual end user.

FIG. 1 illustrates a known a simplified manufacturer/supplier process 100 for producing a product build based on received customer requirements.

The process 100 starts with the customer, for example a mobile phone network operator, determining what their requirements are, in step 110. In a second step 120, the customer passes their requirements to the manufacturer/supplier, for example a mobile phone handset manufacturer.

The requirements may include, by way of example only, software and application requirements, colour and other hardware requirements, billing and delivery requirements, etc. The requirements received from the customer are collated and interpreted in step 130 by, for example, a sales representative from a local organisation of the manufacturer or supplier.

Once the sales representative has collated and interpreted the customer requirements, the interpreted requirements are typically passed to an order desk, as shown in step 140.

On receiving the interpreted requirements, the order desk formalises the requirements, in step 150. That is to say, the interpreted requirements are entered into, for example, a standard format of the manufacturer's/supplier's internal process flows such as a manufacturing line, billing and delivery system, etc. Having formalised the requirements in step 150, the order desk passes the formalised requirements to the relevant manufacturing/development departments, as shown in step 160.

Next, in step 170, the manufacturing/development departments implement the hardware and software requirements, and create a Bill of Materials (BOM) for the customised product and samples of the customised product.

In step 180, the samples are checked to ensure that they fulfil the formalised requirements.

Finally, once the samples have been checked that they fulfil the formalised requirements, the customised product is built and shipped to the customer 190.

However, this known prior art has the following disadvantages.

It is often the case that the customer requirements are not passed to the sales representative, in step 120, in a single, comprehensive fashion. Rather, the requirements may be provided over a period of time, for example via a product specification containing the basic requirements, followed by subsequent phone calls, emails, etc providing further requirements or refinements of the order/enquiry.

This provides the problem that it is necessary for the sales representative to collate all the information received and to try to make sense of the information which may conflict.

Furthermore, it will be necessary for the sales representative to interpret the requirements, thus adding certain subjectivity and human error to the capturing of customer requirements.

Furthermore, there is an inherent delay in the process, whilst waiting to receive all the requirements from the customer, in addition to the time it takes the sales representative to collate and interpret the requirements.

The above problems are further compounded at the order desk.

The interpreted requirements received by the order desk, which as mentioned above are prone to subjectivity and human error, must be formalised. This requires the requirements to be converted into a suitable format of the manufacturer's internal process flow.

The interpreted requirements received by the order desk are likely to be in a format that is a mixtures of formats in which the requirements were received from the customer and that used by the particular sales representative. Therefore, it is possible that this differs significantly to that of the internal process flow.

As a consequence of this, when entering the requirements into the format of the internal process flow, the individual entering the requirements will need to further interpret those requirements in order to best express them in the new format.

Consequently further subjectivity and human error is introduced.

Once again, the need to formalise the requirements adds delay to the process. This delay is further increased since it will be necessary to carry out financial checks, etc. to ensure that the customer has a sufficiently high credit rating and/or has not been "black listed" due to non-payment of invoices, etc. in the past.

It is also necessary to ensure that the requirements received are viable. For example, that all software and hardware components are available and supported by the manufacturer/supplier, and that the specific combination(s) of components is/are valid and without conflict. This viability check adds yet more delay to the process.

As will be appreciated by a skilled artisan, the subjectivity used in interpretation of the requirements at both stages mentioned above can lead to the formalised requirements varying from the original customer requirements. Furthermore, human error can lead to incorrect values, etc. occurring in the formalised requirements.

The outcome of this is that at the validation stage (step 180), the samples, etc. are checked against the formalised requirements. Consequently, even if samples meet the formalised requirements, there is a significant possibility that they would not meet the original customer requirements, due to the subjectivity and human error introduced in the process.

Yet more delay occurs during the process due to the implementation of the requirements. This is generally done on an individual basis manually by, in the case of software, manually creating a customised software build. This is then manually tested during validation, which again increases the delay.

A further problem that is encountered with this known process is that a customer may have digital resources, for example graphics, (e.g. bitmap files) or audio files, which they require to be included as a part of the customised product.

Such digital resources are not conducive to being captured on paper, and are, in general, required in an appropriate digital format. The known process described above does not allow for a reliable means for such digital resources to be managed.

In particular, a customer may specify that certain digital resources are desired early on, but the digital resources may not be provided in a suitable format until much later. This can lead to further delays etc., which are out of the control of the manufacturer. Furthermore, even when digital resources are provided in an appropriate format, the known process is not conducive for direct association of specific resources to specific orders. Thus, there is a risk of digital resource files being mislaid or associated to the wrong orders.

This known process also has the disadvantage that it is relatively inefficient in terms of both time and resources, as explained below.

From the point of view of the manufacturer's resources, i.e. actual people required to perform tasks, etc., Table 1 below illustrates the typically required resources for a mass produced product manufactured by a small to medium sized enterprise.

Area Task Resources Sales Collating and interpreting 1 Representative customer requirements Order desk Formalising interpreted 1-2 requirements Manufacturing! Implementing H!W, S!W 2-4 Development requirements, and creating BOM and samples Validation Checking samples fulfil 1-2 formalised requirements Production Building and shipping customised 1 products TOTAL 6-9

Table 1

Where only customised software components are required, the human resources required are likely to be in the range of 6' Where both customised hardware and software are required, the human resources required are likely to be in the range of 9' The resources indicated for production in Table 1 above only include human resources required for ensuring all the required information for the building and shipping of the customised product is provided to the factory line, etc. It does not include the actual resources required for the building and shipping of the product.

As will be appreciated by those skilled in the art, the need for such high resources adds significantly to the overheads of the manufacturer, which in turn must be passed on to the customer in terms of the price of the product. -d--

There is therefore a need for improving the method and process of managing and controlling a product build to alleviate the above mentioned problems and disadvantages.

Statement of Invention

In accordance with a first aspect of the present invention, there is provided a system for customising an electronic product, as claimed in Claim 1.

In accordance with a second aspect of the present invention, there is provided a method of manufacturing customised products, as claimed in Claim 11.

Further aspects and advantageous features of the present invention are as described in the appended Claims.

Brief Description of the Drawings

FIG. 1 is a simplified illustration of a known manufacturer/ supplier process for building a product based on received customer requirements Exemplary embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: FIG. 2 illustrates a requirements capture tool of a substantially automated control system for managing and controlling the production of a customisable product according to one embodiment of the present invention; FIG. 3 illustrates a process of generating a product using "building blocks" to represent the hardware and software domains, according to one embodiment of the present invention; FIG. 4 is a simplified illustration of a manufacturer! supplier process for producing a product build based on received customer requirements, according to one embodiment of the present invention; and FIG. 5 illustrates an exemplary embodiment of an implementation of the requirements capture tool of FIG. 2.

Description of Embodiments of the Invention

FIG. 2 illustrates a substantially automated control system for managing and controlling the production of a customisable product, and in particular a requirements capture tool, according to one embodiment of the present invention.

Such a control system 200 may be used by a manufacturer!supplier of customisable products, for example mobile phone handsets.

The control system 200 comprises a requirements capture tool 210, which may be linked to a product generator 220.

-10 -The requirements capture tool 210 captures customer requirements, for example the requirements that a mobile phone network operator may have for mobile phone handsets. Such customer requirements may include, by way of example only, software and application requirements, colour and other hardware requirements, billing and delivery requirements, etc. It is envisaged that the requirements capture tool 210 may comprise an Internet based front-end, whereby a customer is able to directly access the tool via the Internet. In this way, the customer is able to enter the requirements at their own convenience. This has the advantage that it is not necessary for a sales representative to be present whilst capturing the requirements of the customer.

In an alternative embodiment, the requirements capture tool 210 may comprise a proprietary software application located on, for example, the computer (e.g. a laptop style computer) of a sales representative of the manufacturer/ supplier organisation. In this way, the sales representative is able to visit the customer and enter the customer requirements with the customer present. This has the advantage of the sales representative being able to answer any questions that the customer might have, or clarify any options available to the customer, etc. in a real time manner.

In a still further alternative embodiment, the requirements capture tool 210 may comprise a proprietary software application provided by the manufacturer/supplier to the -11 -customer for inclusion on the customer's computer network.

Thus, the application can be made available to appropriate personnel of the customer for ordering products as and when required.

Notably, the customer requirements are entered directly into the requirements capture tool 210. In this way, the customer requirements may be entered directly in the format of the manufacturer's/supplier's internal process flow, for example in the form of a customisation checklist (CCL) . In effect, the customer requirements are therefore formalised at the point of capture.

As will be appreciated by a person skilled in the art, the use of the requirements capture tool 210 provides a number of advantages over the known processes.

Firstly, because the customer requirements are entered directly in the format of the manufacturer's/supplier's internal process format, and preferably by the customer himself/herself, problems are overcome: (i) a sales representative receiving the requirements over a period of time and having to collate the requirements; (ii) a sales representative having to interpret the requirements received from the customer; and (iii) the interpreted requirements having to be formalised by the order desk -12 -Consequently, there is no subjectivity or human error on the part of the manufacturer/supplier that could be detrimental to the accuracy of the formalised requirements.

Furthermore, since the customer requirements are directly entered into the format of the manufacturer's/supplier's internal process format, the time delay inherent in the old system for achieving this is removed.

Once all the customer requirements have been entered, they may be "submitted" to the product generator 220. This can be achieved in any suitable manner. For example, in the case of the requirements capture tool 210 comprising an Internet-based front-end, the requirements capture tool 210 further comprises a back-end residing on a server. The back-end receives the submitted requirements information, and stores the captured information in a database, for example a structured query language (SQL) database. The information in the database is then made available to the product generator 220.

In an alternative embodiment, the back-end receives the submitted requirements information and creates a definition file containing the captured information. The definition file may be in any suitable format, for example an extended mark-up language (XML) based format or other proprietary/non-proprietary format. This format can then be sent, or made available in a file storage area, to the product generator 220.

-13 -On receiving the captured customer requirements information, the product generator 220 generates the necessary components to build a product, in accordance with the customer requirements. Such components, in particular, include, but are not limited to, software binary "images" etc. For physical components, such as hardware, etc., the required components are identified so that they can be allocated from stock.

All parts and components of the product may have a unique part number. These part numbers are used to create a bill of material (BOM) . The BOM may be generated by the product generator 220, or alternatively by an Enterprise Resource Planning (ERP) System 230.

Having generated the necessary components, the product generator 220 makes the components available to a production system 240. For example, software components may be made available by storing them in a file storage area. The production system 240 is then able to use the generated components to build and ship the customised product.

In one embodiment of the present invention, prior to the necessary components being made available to the product generator 220, the software components may be tested to ensure that they function as intended/required.

The product generator 220 may generate these test scripts, which are based on the software components. Alternatively, a -14 -separate tool (not shown) may generate the test scripts based on the customer requirements.

The software components and the test scripts can then be provided to a device emulator (not shown), which emulates a device onto which the software components are to be loaded.

The test scripts are then run on the emulator to ensure that the software behaves as it should.

The control system 200 further comprises an enterprise resource planning (ERP) system 230. The ERP system 230 may be coupled to each of: the requirements capture tool 210, the product generator 220 and the production system 240.

An example of a suitable ERP system is SAPTh, details of which can be obtained from www.sap.com.

In an enhanced embodiment of the present invention it is envisaged that the requirements capture tool 210 provides for different types of user, such as customers, consumers and internal users (e.g. employees of the manufacturer/supplier organisation) For example, customers, such as Network Operators, might have an on going relationship with the manufacturer/supplier. In this manner, the customer and the manufacturer/supplier would have typically previously negotiated certain terms, such as pricing, certain settings, graphics and logos, minimum quantities and other standard requirements that the customer might have. This information may be held within the ERP -15 -system 230. When the customer logs onto the system (for example by way of entering a unique username and/or password), the previously agreed details can automatically be retrieved from the ERP system 230, thus saving the need for the customer to re-enter such details each time they use the system.

Consumers, on the other hand, will in general only make one off purchases. Therefore, they will not have negotiated requirements, etc. with the manufacturer/supplier. Therefore, it will be necessary for a consumer to enter all requirements.

However, a consumer may be provided with fewer customisation options, since certain options may require either a particular level of technical understanding, or a minimum quantity purchased to make those options financially viable.

Furthermore, consumers may be limited to maximum quantities, as a consumer is likely to have a lower credit rating' than, say, a network operator.

Internal users may be provided with discounted prices, for example as part of an employee benefit package.

Alternatively, internal users may be able to make use of the system for ordering samples which may be required for trade shows, to show to prospective new customers, or simply to test new products.

The ERP system 230 may also hold information regarding stock levels, lead times for ordering new stock etc., for example as provided by the production system 240. Furthermore, the ERP system 230 may also monitor production orders already scheduled on the production system 240. In this way, it is -16 -possible to determine the earliest possible delivery dates for products depending on the requirements entered by a user of the system, based on availability of stock and when the product can be scheduled to be built. Consequently, a user can be provided with an estimated delivery date, or be able to select a favourable delivery date from a range of possible delivery dates.

As previously mentioned, the product generator 220, on receiving the customer requirements, generates (or identifies) the necessary components for the customised product to be built.

From the point of view of software components, the product generator 220 generates, for example, software binary "images" containing the required features! functionality! applications, etc. From the point of view of hardware, it is envisaged that a user's requirements may include the selection of possible hardware options. For example, where the product is a mobile phone handset, the user of the system may be able to select the base model, the colour of the handset, the type of camera (e.g. the resolution/number of pixels), etc. Where this is the case, it is not necessary for the product generator 220 to generate any components. Instead, the relevant part numbers for the selected hardware components are simply included in the BON, as mentioned above.

-17 -However, it is also envisaged that a user's requirements may include hardware options that are not necessarily considered as standard' For example, a mobile phone network operator may specify that their logo or some other graphic be present on, for example, the bezel of the handset. Where this is the case, the product generator 220 generates a print template, or other appropriate guide/specification, which may automatically be sent to the supplier of, in this example, the handset bezels, along with the required quantity of bezels.

Alternatively, the print template, or other appropriate guide/specification, may already exist, for example from a previously placed order or from prior negotiation, and stored in the ERP system 230. In this case, the product generator simply retrieves the print template or other appropriate guide/specification from the ERP system 230, and the required bezel(s), comprising the Network Operator logo, is/are automatically ordered from the relevant supplier.

It is envisaged that this approach may also apply to packaging, manuals, marketing/advertising material, etc. As also mentioned above, every component of a product is allocated a unique part number. All part numbers are held and controlled in the ERP system 230. The product generator 220 creates a complete list of all components that can be used in a product.

In one embodiment of the present invention, the product generator will then pass the list to the ERP system 230, which for the known or previously used/generated components -18 -retrieves the relevant part numbers. For new (i.e. specifically generated) components, the ERE system 230 may create new part numbers.

The ERP system 230 then uses the part numbers to create the BOM for that product, which it stores and also passes back to the product generator 220. The product generator 220 is then able to make the components and their part numbers available to the production system 240.

In an alternative embodiment of the present invention, the product generator 220 retrieves the part numbers for the known or previously used/generated components from the ERP system 230. For the new (i.e. specifically generated) components, the product generator 220 creates the new part numbers. The product generator 220 is then able to create the BOM itself, which it passes to the ERP system 230 for storing, along with the newly created part numbers. The product generator 220 is then able to make the components and their part numbers available to the production system.

The production system 240 is provided with the BOM, identifying all required components, along with the quantity of units to be built and the delivery information. From the BOM, the production system 240 is able to generate a "pick list" or the like, which lists all the physical components (e.g. hardware, accessories, user manuals, packaging, etc.) required to build the product, and the quantities required to fulfil the order. This pick list can then be used to retrieve all necessary physical parts from stock.

-19 -Furthermore, the production system 240 is able to identify from the BOM all necessary software files (e.g. binary images, resource files etc.), which will have previously been made available by the product generator 220. The production system 240 is then able to retrieve the required software files, and configure the assembly line for downloading the files into the units as they are built.

A user of the system is, in effect, placing an order each time they submit their requirements. In one embodiment, the ERP system 230 tracks the progress of each order. Furthermore, it is envisaged that the ERP system 230 effectively controls the process, allowing each order to progress through each stage, or restricting orders from progressing if required.

For example, when an order is placed (i.e. a user submits their requirements), the requirements capture tool 210 sends the customer requirements to the product generator 220, as well as informing the ERP system 230 of the placing of an order. The product generator 220 waits until it receives confirmation from the ERP system 230 before generating the required components.

Alternatively, on receiving the customer requirements from the requirements capture tool 210, the product generator 220 notifies the ERP system 230 of the receipt of an order, and awaits confirmation to proceed from the ERP system 230 before generating the required components.

-20 -On receiving the notification from the requirements capture tool 210, the ERP system 230 performs a check to ensure that it is acceptable to process an order from that particular user. For example, where the user is a customer such as a Network Operator, each customer may be awarded a credit limit.

The ERP system 230 checks the current credit level for that customer, and if the customer is within their limit, the ERP system 230 will inform the product generator 220 to proceed with generating the required components.

Alternatively, the ERP system may contain, or have access to, a list of customers who have outstanding unpaid invoices, or the like. If the user is on this list, the ERP system 230 may then automatically send a notice (for example by email) to the user informing them that until the outstanding invoices have been paid no more orders will be accepted. The order may then be "held" until the outstanding invoices are paid, or the order is cancelled.

Alternatively, it may be that payment for an order is due prior to an order being fulfilled. In this case, the ERP system 230 may await confirmation that a payment has been received before instructing the product generator 220 to proceed with generating the required components.

In this manner, the product generator 220 only generates required components for valid orders, with the ERP system 230 performing certain checks prior to committing to the product build. This offers the advantage that computing resources and -21 -the like are not wasted on generating components for orders that are not fulfilled.

The ERP system 230 may also control the scheduling of product builds. For example, the ERP system 230 may monitor stock levels, and allocate stock to specific orders. When all components for a particular product order are available, the ERP system 230 schedules, or causes to be scheduled, the building of the product order with the production system 240.

In this manner, it is possible to cancel any order, for example if parts become unavailable or a customer wishes to cancel the order, withminimum interference to the production system 240. This allows the production system 240 to operate as efficiently as possible, and thereby aids in achieving maximum productivity on the assembly lines, etc. This is important since any confusion or delays that might occur on an assembly line or the like can result in significant drops in productivity and lost revenue.

Once a product has been built and shipped, the production system 240 may confirm shipment to the ERP system 230.

The ERP system 230 may also contain pricing information for each product/order, which may be provided by the requirements capture tool 210 or product generator upon submission of the customer requirements (since the user may have been informed of the price prior to submitting the order) -22 -Alternatively, the ERP system 230 may calculate the price from the BOM. This can be achieved simply by associating each part number with a price. In this manner, the ERP system 230 may simply add up all the individual part prices to obtain the overall price for the product.

Where new components are generated, at the time of assigning new part numbers, the price for each new component may be determined based on the contents of each component, or may be based on the price of alternative similar components.

In either event, the ERP system 230 is configured to possess both the price (per unit) and the quantity of units shipped.

Consequently, the ERP system 230 is able, upon confirmation of shipment, to automatically generate, or cause to be generated, invoices etc., as appropriate.

Referring now to FIG. 3, the process of generating a product uses "building blocks" to represent the hardware and software domains. In particular, in the context of the present invention, embedded software elements of the product are represented as software building blocks. Embedded software elements, in the context of the present invention, comprise software modules where software-based functions of an electronic product, such as a mobile phone, are separated into code and data (i.e. software that is not executed' by a processor) . Thus, a tool is provided that allows configuration to be performed in a well-defined, automated manner. Notably, the configuration is performed safely (i.e. inconsistencies between software modules are avoided) . This -23 - is advantageous when configuring complex embedded software-based products, due to the huge number of product variations that can be ultimately manufactured. Thus, a standardised process of driving down customisation throughout the embedded software contained within a product is supported.

In this manner, the requirements capture tool 210 is able to provide a user (e.g. a customer, sales representative, etc.) with the opportunity to effectively "click" together a working device from, say, a mixture of embedded software and additional hardware components. The embedded software is such that a user "clicks" together a working software domain (hereinafter referred to as "image") comprising, for example, an OS and/or one or more applications and/or one or more settings and/or one or more resources to fit that phone.

Notably, it is within the contemplation of the present invention that the customisation of a software-based electronic product may encompass every aspect of the product, in addition to the embedded software elements.

Thus, in the context of the present invention, it is envisaged that the embedded software may be configured to represent further elements in addition to the software elements, for example representing: (i) One or more hardware elements; and/or (ii) One or more packaging elements; and/or (iii) One or more accessories.

-24 -As such, it is envisaged that the customisation of the software-based electronic product may encompass the box that the product is shipped in, for example, its size, shape, colour, logo affixed to the box or the product, any manuals that accompany the product, options for accessories, such as cables, battery chargers, replacement batteries, etc. for a phone product.

Referring to FIG. 3, one implementation of the system architecture 300, arranged to control the complete configuration process for, say, the build of a Smartphone, Featurephone or similar complex wireless communication unit, is illustrated in more detail. The system architecture 300 comprises a version-controlled file storage function 305, which for one embodiment of the present invention forms a part of the ERP system 230 of FIG 2.

The version-controlled file storage function 305 comprises the necessary software and hardware building block definition files 310, core building blocks 315, variant builds 320, localisation files 325 and binary definition files 330, 335.

In one embodiment of the present invention, the version-controlled file storage function 305 comprises, say, hundreds or thousands of software and/or hardware building blocks.

Each block may also be provided with its own unique part number.

The version-controlled file storage function 305 is operably coupled to the requirements capture tool 210 and the product/image generator 220. A customer may access a user -25 -interface, such as a graphical UI (GUI) (not shown), of the requirements capture tool 210. When building' a graphical representation of the electronic product, the requirements capture tool 210 accesses representations of the embedded software, and preferably hardware building blocks, stored in the version-controlled file storage function 205.

The output of the requirements capture tool 210 may comprise a "definition" file 345 containing all of the customer requirements. The definition file 345 of the device (that includes both hardware and software components, packaging and accessory components, billing and delivery information, etc.) may comprise all information regarding the device, at all levels. This file could, in theory, be regarded as the "recipe" for the construction of the device. The definition file 345 may take any suitable form, for example the definition file 345 may be in the form of a mark up language file, such as an adaptation of XML.

Since the user (e.g. the customer) has defined the device's requirements, including in one embodiment its look and feel, it is possible to generate a set of scripts for use by a test (harness) engine (not shown); to ensure that the end product produced matches the customer requirements as provided directly by the customer.

In combination with the assembly database (validation), this dramatically reduces the requirements for test and delivery of a product to a customer. Furthermore, because the subjectivity and human error factors inherent in the known -26 -process have been substantially removed, the testing is performed directly against the customer requirements. This significantly improves the quality (from the customer's point of view) of the delivered product.

The definition file 345 is passed from the requirements capture tool 210 to the product generator 220. The product generator 220 uses the information contained within the definition file to generate a set of software image components to be loaded onto a device. These components are to be issued unique part numbers, and are included, along with the part numbers of all other components of the device, into a bill of material (BOM) 360.

The BOM 360 is then passed to a production system, for example the production system 240 of FIG. 2, for actual construction of the product on the assembly line.

The production system 240 may comprise a configuration administrative system automatic software loader 375, for configuring the product with selected software elements, such as mobile phone applications. The selected software code/ applications are extracted from a configuration system database 380.

For the purpose of configuring a build of a wireless communication unit such as a Smartphone or Featurephone, it is envisaged that the product/image generator 220 may generate a production order with an adapted BOM 360. In an enhanced embodiment of the present invention, the adapted BOM may be -27 -used to emulate in software the operation of the wireless communication unit, for example, to be run on a real-life phone or on a PC 365. Again, the aforementioned test scripts can again be used to provide a test environment for the product at a virtual stage, before committing build resource.

Advantageously, with the provision of an emulator according to the enhanced embodiment of the present invention, the solution may be iterative, i.e. a customer or consumer is able to assess the various selectable hardware and/or software options from the version-controlled file storage 305. Furthermore, the customer or consumer may be able to assess the impact in a real-life scenario, in a real-time manner, as more software elements are incorporated into the emulated phone. Thus, an iterative solution may be used to ensure consistency across various software/hardware versions.

Advantageously, this virtual device may also be presented during creation and configuration, so that a user can visualise and interact with a virtual representation of their product.

It is envisaged that the BOM 360 may also comprise a list of parts, with new additional information relating to a particular product build. In one embodiment, the BOM 360 may also comprise a favourite list of selectable hardware and/or software elements contained, say, in a browser.

A further advantage of the inventive concept hereinbefore described is that it is far easier for manufacturers and -28 -customers to collaborate on joint development work. In particular, the implementation may be web-based, to allow, for example, a wireless communication unit manufacturer to work with customers! vendors in an on-line manner.

In addition, it is envisaged that the aforementioned arrangement may be used as part of various project management exercises, in the development of products. That is, in this manner, a development or project engineer or manager is able to validate the inter-working of particular software and (in one embodiment) hardware components more easily during a development phase of the product.

The variant builds 320 may contain order/customer specific information and comprise the configurable software items for the wireless communication unit. Thus, the product generator 220 is used by the customer to combine software and/or hardware building block representations, based on the core building blocks 315, and one or more variant builds 320, localisation files 325 and binary definition files 330, 335.

In one embodiment, the product generator 220 also specifies the version of the build environment that is to be used/being used.

The requirements capture tool 210 may also provide an object representation of configurable elements in the build environment. As such, in one embodiment of the present invention, the requirements capture tool 210 comprises software and hardware representations of product elements, such as mobile phone elements. In an enhanced embodiment of -29 -the present invention, the software representation comprises embedded software elements, so that a mobile phone can be designed! built from these embedded software elements. In one embodiment of the present invention, the embedded software elements are stand-alone items that may be configured within a phone in a plug-in' type manner.

As previously mentioned, it is envisaged that the software build can be performed over the Internet, through a client application or by another system or via a customer's system.

Furthermore, it is envisaged that a new application can be added as an option on the requirements capture tool 210, as a new isolated module (for example in the form of a Java bean) that describes both the application and its configuration relevant behaviour. In this form, the customer or consumer is able to manipulate the requirements capture tool 210 elements, in effect by performing a drag and drop and verify operations.

The build environment/product generator 220 is modified to deal with the application object, which may not require extensions and/or modifications to many, if any, different parts of the build environment.

A hardware or software component object in the requirements capture tool 210 may be an object in the build environment.

If the software component object is not the same as the object in the build environment, then the match should be as close as possible.

An example software candidate for representing these embedded software elements is C++ or JAVA. The classes of configurable -30 -elements may be equipped with a subset of the behaviour methods of matching Java beans in the requirements capture tool 210, as will be appreciated by a skilled artisan. It is envisaged that a JAVA based arrangement provides the simplest and most efficient mechanism to implement a drag and drop' function within the requirements capture tool 210.

In addition, it is envisaged that other advantageous methods may be supported using C++ classes, which are particularly applicable in a build environment. It is also envisaged that the classes in the build environment may comprise additional levels that are built into the software to handle more detail-specific builds.

A listing of various software configurable (selectable) elements, as used in the one embodiment of the present invention, comprises: (1) Customer variant -Contains customer specific Bitmaps, splash screens, ring tones, etc.; (ii) Customer Applications variant -Contains customer specific applications; (iii) Language variant - Contains a set of languages with a specified default language; and (iv) Specific applications, logos, bitmaps, splash screens, ring tones, etc. Furthermore, it is envisaged that a listing of various hardware configurable elements, as used in one embodiment of the present invention, comprises: -31 - (i) Battery type; (ii) Bezel; (iii) Labels; and (iv) Accessories.

A skilled artisan will appreciate that many other variant /selectable elements may be offered in alternative applications.

Downloading of binary files to a wireless communication unit build may be performed using a universal serial bus (USB) connection, or by use of a removal memory module (such as a memory card), which is used for conventional programming of mobile phones or direct programming at the point of assembly or configuration.

Although embodiments of the present invention have so far been described as allowing either a customer or a sales representative being able to utilise the features and functionality of the present invention, it is contemplated that the requirements capture tool may also be made available to consumers. In this way, a consumer is able to order a customised single unit to their requirements. Alternatively, it is envisaged that a consumer may be able to select/ configure software upgrades, additional software applications, accessories, etc. for a previously purchased product.

In accordance with one embodiment of the present invention, an input for the requirements capture tool 210 may be a -32 -Customisation Checklist, as completed by the customer or consumer. Customisation of a wireless communication unit, as specified by the customer or consumer, may require changes to a device configuration, depending upon, say, a rules database (not shown) for the requirements capture tool 210. For instance, the consumer or customer may be provided with the opportunity to specify a combination of two applications where the rules database specifies that these applications typically cannot be used together, for example due to incompatibilities between the two applications. This means that the customer will have to change his/her requirements.

One embodiment of the present invention envisages that the customer is provided with the ability to specify several application' items of the user interface of the wireless communication unit, which may be configured! arranged to be customisable, by the end user. Examples of these items comprise:

(i) Background bitmaps;

(ii) Colour schemes; (iii) Sounds; (iv) Animations; (v) Fonts; and (vi) Indicators such as Key-lock, GPRS signal, etc. The customer may also be provided with an opportunity to specify his/her own splash screen, i.e. the initial screen that appears for a few seconds following start-up and shut-down, as well as specify how long the splash screen is to be -33 -displayed. In addition, the customer may also be provided with an opportunity to specify one or more customer-specific ring tones to be loaded into the phone.

It is envisaged that the customer may also be provided with an opportunity to specify items that are specific for use in a particular country or region, in relation to the manufacture/build of a particular order. For example, the customer may specify: (i) One or more languages, where the number of specified languages is limited by the amount of memory used by the total build; (ii) A default language, if more than one language is specified. Advantageously, this allows the Customer to order a single phone capable of operating in two different countries, where the phone starts up with the default language for the correct country in which the phone was sold; and (iii) Default regional settings to control, for example, a display of date and/or time in the correct format for the specified region, and/or a display of currency/numbers, etc. in a correct format for the specified region and/or a default time zone, etc. It is also envisaged that the customer is provided with the opportunity to define the connection settings for each phone from, say, a list of connection types that are supported by the phone, to match the customer's setup. Such connection settings may include one or more of the following: -34 - (i) Wireless Access Protocol (WAP) parameters, where all WAP connection settings are specified in the

WAP provisioning Content Specification, available

from the WAP Forum (http://www.wapforum.org); (ii) General Packet Radio System (GPRS) parameters; (iii) Dial-up settings and parameters; (iv) Browser settings, including browser favourites.

Here, the Customer may be provided with the opportunity to define a list of browser favourites to be pre-configured in the phone for a particular order. The definition of a browser favourite may include at least a descriptive tag and the URL. Additionally, the Customer may be able to specify a sequence in which the Browser favourites appear; (v) Proxy settings and parameters; and (vi) Over-the-air programming (OTAP) mechanisms.

Advantageously, the aforementioned build mechanism enables the phone binaries to be built by someone who is not technically proficient, thereby enabling orders for the phone to be fulfilled in a customisable manner.

Thus, a binary image may be generated in a post manufacturing process step in a distribution/retail context using a plurality of selectable software representation blocks In addition, it is possible for customer specific components to be incorporated, without the need for the customer to -35 -manually specify them. For example, in the above example, the resource files of the product may include customer specific graphics and logos. Such logos may have been previously arranged and agreed with the customer, for example from previous orders and/or negotiations.

In this manner, the order information may comprise a customer identifier for a particular software-package option. Thus, the part number for the software-package option may be specific to, say, Customer X' Alternatively, the customer may upload desired graphics and/or audio files at the point of capturing the customer requirements.

As previously mentioned, the order for an electronic product, particularly when placed by a customer such as a Network Operator, may encompass a large number of products. Sets of these products may be configured in substantially the same manner, or some may be configured with individual requirements.

It is within the contemplation of the present invention that the inventive concepts hereinbefore described are not limited to the described wireless communication unit software build or associated manufacturing system of embodiments of the present invention. Indeed, it is envisaged that the inventive concepts are applicable to any suitable mass-produced software-based electronic product (or product that offers -36 -software variants) comprising embedded software and hardware elements.

Referring now to FIG. 5, there is illustrated an exemplary embodiment 500 of an implementation of the requirements capture tool 210 of FIG. 2. The requirements capture tool 210 may comprise a front-end component and a back-end component.

The front-end component is provided in the form of a website, which may be accessible to a customer 310 via the Internet 520. The front-end component is hosted on a front-end server 530, which may be located within a de-militarised zone (DMZ) of the manufacturer's corporate computer network.

For reference, a DMZ is middle ground between an organisation's trusted internal network, such as an intranet, and an un-trusted, external network such as the Internet.

Another term for a DMZ is a "perimeter network". A DMZ is a sub-network that may sit between firewalls, or off one leg of a firewall. In the illustrated embodiment, the DMZ sits off one leg of a firewall 540 of the manufacturer's corporate computer network.

The front-end component may be developed using ASP.NET.

For reference, ASP (or an Active Server Page) is a Web server technology that allows for the creation of dynamic, interactive sessions with a user. An ASP is a web page that contains hyper text mark-up language (HTML) and embedded programming code written in VBScript or Jscript. When an -37 -internet information server (e.g. web server) encounters an ASP page requested by a browser, it executes the embedded program. ASP.NET is an enhanced version of ASP for the.NET platform.

The back-end component may be provided as a series of Java Servlet, provided via a Java web server/listener, and is hosted on a back-end server 550. The back-end server 550 may be located within a trusted part of the manufacturer's corporate computer network, such as a LAN.

The requirements capture tool 210 may also comprise a database component, which may also be located on the back-end server 550.

The database component holds the building block definition files etc. In an alternative embodiment to that illustrated in FIG. 3 where customised product definitions for the embodiment illustrated in FIG. 5 are provided to the product generator 220 in a "definition file", the customised product definitions are stored in the database component and the product generator 220 is able to access the product definitions when required.

The database component may be in the form of an SQL database, since this provides manageability, quick access to stored data, flexibility and the ability to store not just information, but binary data (for example graphics/audio files) as well.

-38 -By locating the back-end and database server 550 within the relatively secure environment of the LAN, the back-end component and database are afforded security.

The location of the front-end component in the DMZ provides the advantage that it is accessible to customers, without allowing access to the more sensitive back-end component and database.

As will be appreciated by a skilled artisan, when a customer accesses the requirements capture tool 210, the front-end component is loaded, in the form of a web page, from the front-end server 530. The front-end component then communicates with the back-end component. In order to achieve this, the method of communication is required to traverse the firewall restrictions.

An advantage of implementing a web-based front-end is that firewalls in general allow hypertext transport protocol (HTTP) connections to transverse them. Consequently, by utilising a simple XML over HTTP based message system for communication between the front-end component and the back-end component, minimal (if any) changes are required to the firewall restrictions to implement the requirements capture tool 210.

These HTTP based communications can be secured by simple conversion to HTTPS (secure HTTP), allowing for all transactions between client and server to be encrypted.

-39 -An alternative communication protocol is SOAP (simple object access protocol), which is a message-based protocol based on XML for accessing services on the Internet.

Barring an initial handshake connection from the front-end component to the back-end component, the front-end system may be driven by the back-end component.

The back-end component provides, for example via XML, the front-end component with a series of questions and potential answers, which the front-end component presents to the user.

The back-end component may also provide certain validation criteria. In this way, answers provided by a user (i.e. the customer) will be subjected to an initial validation by the front-end component, and then returned to the back-end component.

Each returning message is stamped with authentication credentials to identify the user etc. Such credentials may include, by way of example only, one or more of the following: (i) A timestamp; (ii) A username; (iii) An access level; (iv) An ASP session ID; and (v) A Java session ID.

This implementation of the requirements capture tool 210 enables the front-end to remain stateless and able to display a variety of options and questions without the need for -40 -processing by the front-end component, or updating of the front-end component.

On loading the front-end component, the customer may be required to log-in', or register.

To log-in, the customer may enter a username and password. The front-end component then returns the entered username and password to the back-end component, which uses the username to determine whether an account exists by accessing data within the database component. If an account does exist for that username, the password is then compared with a password stored within the database component.

If both the username and password are correct, the back-end component then may check to see if a customer record exists within the database to determine whether the account has been suspended. If the customer account has not been suspended, a user session is started, and main menu questions, valid answers and validation criteria are sent to the front-end component.

To register, the customer enters required details, such as a username, password contact details, etc. Alternatively, a username and/or password may be automatically generated for the customer for security reasons.

This information is then returned to the back-end component, which creates the new customer account within the database component.

-41 -In one embodiment of the present invention, the account is initially suspended in order for financial checks and the like to be carried out. The account can then be activated at a later time/date once the required checks have been carried out. The customer may, for example, be sent an email informing them when the account is activated, and also where appropriate with the automatically generated username and/or password.

Having successfully logged in, the customer may be provided with a menu of options, which in the case of a mobile telephone handset manufacturer may comprise one or more of the following: (i) Configure new handset; (ii)Load saved configuration; (iii) Re-order previous handset configuration; and (iv) Logout.

On the customer selecting one of the options, the front-end component returns the selected option to the back-end component, which retrieves the next question(s), permitted answers, validation criteria, etc from the database component, depending upon the returned information.

For example, where the customer chooses to configure a new handset, the subsequent message from the back-end component instructs the front-end component to ask the customer to select the country in which the handset is intended to be -42 -sold. The message from the back-end component may also include a list of countries from which the customer may choose.

On receiving the selected country information from the front-end component, the back-end component retrieves a list of valid handset models for that particular country from the database, and returns this list to the front-end component along with the instruction for the customer to choose a handset model.

It is within the contemplation of the present invention that the information provided to the front-end component also includes information relating to each handset model, and may also include graphical representations of each handset model.

In this way the front-end component is able to display this information to the customer, aiding them in choosing the handset model they require.

When the back-end component subsequently receives chosen handset information, it creates a handset session, including the default features, functionality, settings etc. for the selected handset model.

The back-end component then continues to provide questions, etc. to the front-end component, and receive responses back from the front-end component, thereby allowing the customer to configure the handset. Each time the customer alters the configuration of the handset, the back-end component updates the handset session.

-43 -It is also contemplated that a customer is able to upload digital resources, such as graphics files and audio files, which are optional or required by the user to be included as part of the customised product. Furthermore, the back-end component provides the front-end component with validation criteria such as valid file formats, size of files, etc. In this way, the digital resources can be validated at the point of capture.

By capturing, and verifying, digital resources at the outset, delays, etc. that occur in known customisation mechanisms are substantially alleviated. Furthermore, by storing the digital resources in the database component or including them in the definition file, the digital resources are directly associated with orders/product definitions, thus substantially removing the problems of misplacing the digital resources or using the wrong digital resources.

The customer may be able to save the handset session at any point. When the back-end component receives a request to save the session, it instructs the front-end component to request a reference from the customer.

On receiving the reference from the front-end component, the back-end component checks to see if that reference already exists within the database for that customer. If not, the back-end component stores the handset session, including any digital resources provided by the customer, in the database -44 -under the customer reference, and returns the front-end component to the main menu.

In this way, a customer is able, for example from the main menu, to return to a previous handset session to continue configuring the handset, or to modify previous changes.

When a customer wants to order (or re-order) a handset, if the appropriate handset session is not already open, the back-end component retrieves the appropriate handset session from the database, and instructs the front-end component to request delivery information and number of units required.

On receiving the delivery information from the front-end component, the back-end component makes the handset configuration information in the database available to the product generator 220, and passes information on the delivery and number of units to the ERP system 230. The customised handset can then be produced to the desired specification.

FIG. 4 is a simplified illustration of a manufacturer/supplier process 400 for producing a product build based on received customer requirements according to one embodiment of the present invention.

As with the prior art process 100 illustrated in FIG. 1, the process 400, according to one embodiment of the present invention, begins with a customer (or other user of the system such as a consumer or employee of the manufacturer/supply organisation) determining their requirements, in step 410.

-45 -Next, the customer enters the requirements into the requirements capture tool 210, as illustrated in step 420. In one embodiment of the present invention, the requirements capture tool 210 is configured such that the requirements are entered directly into the format of the internal process flow of the manufacturer/supplier.

As will be appreciated by a skilled artisan, by the customer requirements being entered directly into the requirements capture tool 210 by the customer, in the format of the internal process flow of the manufacturer/supplier, the subjectivity and human error on the part of the manufacturer/supplier that afflicts the prior art process illustrated in FIG. 1 is substantially alleviated.

Furthermore, it is not necessary for a sales representative to manually collate the customer requirements, nor for the interpreted requirements receive from a sales representative to be manually formalised. Consequently the inherent delays relating to these steps in the prior art process illustrated in FIG. 1 are substantially removed.

In step 430, the requirements capture tool 210 captures the requirements provided by the customer, in step 430. In step 440, the requirements capture tool 210 then makes the requirements available to the product generator 220.

In step 450, the product generator 220 generates required software components and creates a Bill of Materials (BOM) . In an alternative embodiment, the BOM is created by an enterprise -46 -resource planning system, such as the ERP system 230 of FIG. 2, based on a list of components provided by the product generator 220.

In step 460, the software components generated by the product generator 220 are tested using automated test scripts on a product emulator (not shown) . The test scripts may be automatically generated based on the captured requirements, and may be generated by the product generator 220 or by a separate test script generator. The criteria for the tests more accurately represent the requirements of the customer compared to the prior art process of FIG. 1, since the test scripts are based directly on the requirements provided by the customer.

The software components and test scripts may be automatically loaded into the emulator, and tested, to ensure that the software fulfils the customer requirements.

Where the customer requirements only require customised software' components, once the software components have been tested using the test scripts, no further testing or validation is required. Thus, the software components and the BOM, etc. can be made available to the production system 240.

Thus, the next step 490 is simply for the product to be produced and shipped to the customer.

From the point of view of the manufacturer's resources, i.e. actual people required to perform tasks etc. when only -47 -customised software components are required; Table 2 below illustrates the required resources.

Area Task Resources Capture tool Capturing customer requirements 0 Product Generator Generating required software 0 components and BOM Auto-test scripts Production Building and shipping customised 0 products TOTAL 0

Table 2

The resources indicated for production in Table 2 above only include resources required for ensuring all the required information for the building and shipping of the customised product is provided to the factory line etc. It does not include the actual resources required for the building and shipping of the product.

As can be seen, the present invention provides a system whereby it is possible for an order to be received (i.e. when a customer enters their requirements) and fully processed through to production without any human resources. In comparison, the prior art process of FIG. 1 requires around six human resources.

As will be appreciated by those skilled in the art, this reduction in resources significantly reduces the overheads of -48 -the manufacturer, which in turn can be passed on as a saving to the customer in the price of the product. Alternatively, the reduction in overheads can free up finances that can be put into other areas of the business, such as research and development, etc. It is further envisioned that throughout the entire customisation and production process, customisation information, etc. is maintained in a substantially human readable form in order to facilitate tracking, maintenance and auditing.

Referring back to FIG. 4, where customised hardware components are required, there are the additional steps of creating the required hardware components and samples in step 470 and checking the samples fulfil the customer requirements in step 480.

From the point of view of the manufacturer's resources, i.e. actual people required to perform tasks etc. when customised software' and hardware' components are required; Table 3 below illustrates the required resources.

Area Task Resources Capture tool Capturing customer requirements 0 Product Generator Generating required software 0 components and BOM Auto-test scripts Manufacturing! Implementing H!W requirements, 2 -49 -Development and creating samples Validation Checking samples fulfil customer 1 requirements Production Building and shipping customised 0 products TOTAL 3

Table 3

The resources indicated for production in Table 3 above only include resources required for ensuring that all of the required information for the building and shipping of the customised product is provided to the factory line, etc. It does not include the actual resources required for the building and shipping of the product.

As can be seen, the present invention provides a system whereby it is possible for an order to be received (i.e. when a customer enters their requirements) and fully processed through to production with only 3' human resources required.

In comparison, the known process of FIG. 1 requires around 9' human resources.

Once again, this reduction in resources significantly reduces the overheads of the manufacturer, which in turn can be passed on as a saving to the customer in the price of the product.

Alternatively, the reduction in overheads can free up finances that can be put into other areas of the business, such as research and development, etc. -50 -In practice, it is likely that the manufacturer/supplier organisation will require an additional resource to maintain a system according to the present invention, for example the control system 200 for managing and controlling the production of a customisable product. However, even with this additional resource, the overall resources required are significantly less than that required by known processes.

It will be understood that the control system, as described above, tends to provide one or more of the following advantages: (i) Removes delay in the processing of orders for customised products; (ii) Reduces subjectivity and human error in capturing and fulfilling customer requirements; (iii) Reduces the amount of resources required in processing orders for customised products, resulting in: a) Economic savings; and/or b) Freeing up resources for other tasks (iv) Facilitates the ordering of new products from a customer's/consumer's point of view, thereby improving saleability of products; (v) Allows a simple and effective way of employees of the manufacturer/supplier organisation to obtain products for: a) Personal use (for example as part of an employee benefit scheme) b) Samples to show to prospective customers or at a trade show, etc. -51 -(vi) Provides a repeatable, and therefore controllable process, which allows for improved quality control, which in turn allows for: a) Manufacture of higher quality products; and b) Customer confidence; (vii) Provides a means for uploading, and validating at the point of capture, digital resources such as graphics and audio files; and (viii) Provides a means for validating requirements, or at least only allowing valid requirements, at the point of capture.

Overall, the present invention provides a system that facilitates a more efficient and effective method of implementing a manufacturing-based business, and can form an integral part of the running of a business.

Whilst embodiments of the present invention are described above, it is clear that one skilled in the art could readily apply variations and modifications of such inventive concepts.

Thus, an improved control system for managing and controlling the production of a customisable product and method therefor has been described where at least one of the aforementioned disadvantages with prior art arrangements has been alleviated.

Claims

-52 -Claims 1. A system (200, 500) for customising an electronic

product (200) comprising: a customer requirements capture tool (210) arranged to receive a customer's requirements electronically and display a plurality of customisation options to a customer; a back-end processing function (550), operably coupled to the customer requirements capture tool (210) and arranged to control the plurality of customisation options displayed to the customer and process inputs entered onto the customer requirements capture tool (210), wherein the back-end processing function captures one or more digital resources selected by the customer and, in response thereto, arranges the customer requirements capture tool (210) to display said one or more digital resources to the customer in enabling the customer to customise the electronic product.

2. A system (200, 500) for customising an electronic product (200) according to Claim 1, wherein the system further comprises a database operably coupled to the back-end processing function for storing the one or more digital resources, such that the selected one or more digital resources are directly associated with a customised electronic product.

3. A system (200, 500) for customising an electronic product (200) according to Claim 1 or Claim 2, wherein the system further comprises a verifying function for verifying -53 -one or more digital resources upon selection by the customer's requirements electronically.

4. A system (200, 500) for customising an electronic product (200) according to Claim 3 further characterised in that the verifying function generates one or more test scripts for testing an electronic version of the electronic product in response to the selected customer's requirements.

5. A system (200, 500) for customising an electronic product (200) according to any preceding Claim further characterised in that the back-end processing function performs a customer authentication check to validate the customer electronically entering the customer requirements.

6. A system (200, 500) for customising an electronic product (200) according to Claim 5 further characterised in that following each option selection by a customer, the back-end processing function returns a message comprising an authentication validation to identify the selection made by the customer.

7. A system (200, 500) for customising an electronic product (200) according to Claim 6 further characterised in that the authentication check includes providing one or more of the following within the message: (i) A timestamp; (ii) A username; (iii) Access level; (iv) ASP session ID; and/or -54 - (v) Java session ID.

8. A system (200, 500) for customising an electronic product (200) according to Claim 8 further characterised in that the back-end processing function provides a sub-selection of options to the customer requirements capture tool (210) in response to validating an access right of the customer.

9. A system (200, 500) for customising an electronic product (200) according to any preceding Claim further characterised in that the customer requirements capture tool (210) is a web-based user interface.

10. A system (200, 500) for customising an electronic product (200) according to any preceding Claim further characterised in that the back-end processing function updates an image displayed to the customer via the customer requirements capture tool (210) in response to a number of electronic entries of the customer requirements.

11. A method (400) for customising an electronic product (200) comprising the steps of: receiving, by a customer requirements capture tool (210), a customer's requirements electronically; displaying a plurality of customisation options to a customer; processing customer requirements by a back-end processing function, operably coupled to the customer requirements capture tool (210); -55 -capturing (430) one or more digital resources by the back-end processing function as selected by the customer and, displaying said one or more digital resources to the customer, in response thereto, to enable the customer to customise the electronic product.

12. The method for customising an electronic product (200) according to Claim 11, wherein the method further comprises the step of: storing the one or more digital resources, such that the selected one or more digital resources are directly associated with a customised electronic product.

13. The method for customising an electronic product (200) according to Claim 11 or Claim 12, wherein the method further comprises the step of verifying one or more digital resources upon selection by the customer's requirements electronically.

14. A method for customising an electronic product (200) according to Claim 13 further characterised in that the step of verifying comprises the step of: generating one or more test scripts for testing an electronic version of the electronic product in response to the selected customer's requirements.

15. A method for customising an electronic product (200) according to any of preceding Claims 11 to 14 further comprising the step of authenticating a customer entering the customer's requirements electronically.

--

16. A method for customising an electronic product (200) according to Claim 15 further characterised in that the authentication validation includes one or more of the following: (vi) A timestamp; (vii) A username; (viii) Access level; (ix) ASP session ID; and/or (x) Java session ID.

17. A method for customising an electronic product (200) according to Claim 15 or Claim 16 further characterised by the step of: providing a sub-selection of options to the customer requirements capture tool (210) in response to validating an access right of the customer.

18. A method for customising an electronic product (200) according to any of preceding Claims 11 to 17 further characteriSed by the step of: updating an image displayed to the customer via the customer requirements capture tool (210) in response to a number of electronic entries of the customer requirements.