GB2433798A

GB2433798A - System and method for paying royalties

Info

Publication number: GB2433798A
Application number: GB0526489A
Authority: GB
Inventors: Peter Truman; Paul Hoffman
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2005-12-29
Filing date: 2005-12-29
Publication date: 2007-07-04
Also published as: GB0526489D0

Abstract

A method of determining a third party Intellectual Property (IP) royalty payment charge for a customisable product comprises the steps of automating substantially a process relating to identifying those items that are to be incorporated into a customisable product; and identifying a third party IP royalty payment charge associated with a number of items in the customisable product. Advantageously, this substantially automates a system for identifying when third party IP royalty payments are due for selectable items, in particular in relation to customisable products where third party IP royalty payments can vary depending on customer requirements.

Description

SYSTEM AND METHOD FOR PAYING ROYALTIES

Field of the Invention

The present invention relates to a process to automatically manage, control and calculate Intellectual Property (IP) royalty payments accurately related to a product build. The invention is applicable to, but not limited to, automating a process in calculating and paying royalty payments to IP owners associated with IP used in a mobile phone product. Furthermore, the invention is applicable to, but not limited to, a mechanism for enabling an end-user or customer to select those embedded product items of, say, a mobile phone that may affect a purchase price of the phone as a consequence of incurring inherent royalty payments associated with those embedded product items.

Background of the Invention

In the field of this invention it is known that current electronic products are becoming ever more complex and utilise an ever-increasing amount of Intellectual Property (IP) owned by third parties. For example, as the complexity of products increases, manufacturers are reverting to a greater use of software houses to provide bespoke solutions/applications for the product. This is particularly the case for wireless devices, such as mobile phones. The use of 3rd parties to provide bespoke solutions/applications enables manufacturers to focus on designing and developing a core product, comprising housing and internal electronics to support 3rd party software applications.

Furthermore, in the field of mobile (wireless)

telecommunications, there is an increasing use of approved Standards and common open-architecture operating systems, to facilitate inter-operability between a wide range of manufacturers. There is a plethora of IP owners of, for example, patents that are deemed essential' to building a product compliant with one of a large number of telecommunication standards. A typical essential' patent would be, for example, one related to the speech codec or modulation coding scheme in a mobile phone.

Furthermore, there exists a larger number of IP owners of, say patents, that may not be deemed essential' to a telecommunication standard, but are very desirable for implementing in a product in order to offer a particular feature or function or less expensive circuit, thereby offering a competitive advantage.

However, this requirement to pay royalties to IP owners has the disadvantage that for customisable products or the like, it is very difficult to differentiate in which products specific royalty payments are due, i.e. which products employ which IF. To do so is highly labour intensive, and potentially liable to errors and mis-payments. Therefore, the standard practice is to pay fees to all declared IF owners for all products, even if some of those products do not actually utilise the protected IP and therefore do not require a royalty payment to be paid.

Another disadvantage of the standard practice in paying IF royalty payments is that, even if a manufacturer was able to differentiate those products where specific royalty payments are due or are not due, it is necessary to prove to the owners of the IP that certain products do not contain IP and therefore royalty payments are not due. It is rarely sufficient to audit a product to prove that product is shipped without certain IF. If some products are believed to contain third party IP, the third party IF owner is entitled to audit a company to ensure that all products shipped with their IF have been tracked and all payments made.

Furthermore, in order to simplify the payment of IF royalties, the inventors of the present invention have both recognised and appreciated that geographical coverage is generally not taken into consideration. For example, IF royalties may not be due for products shipped to countries where the relevant IF has not been protected. However, because tracking products geographically adds further complication in accurately determining those third party IF royalty payments that are due, royalty payments are made on all relevant products, irrespective of where the products are shipped or manufactured.

Consequently, third party IF royalty payments are invariably made even when not due.

There is therefore a need for improving the method and process of managing, controlling and accurately calculating third party IF royalty payments 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 method of determining a third party Intellectual Property (IP) royalty payment charge for a customisable product, as claimed in Claim 1.

In accordance with a second aspect of the present invention, there is provided a system for determining a third party Intellectual Property (IP) royalty payment charge for a customisable product, as claimed in Claim 8.

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

Brief Description of the Drawings

Exemplary embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: FIG. 1 illustrates an example of software architecture for an electronic product such as a mobile phone handset, adapted in accordance with the preferred embodiment of the present invention; FIG. 2 illustrates a substantially automated control system for managing and controlling the production of a customisable product according to a preferred embodiment of the present invention; and FIG. 3 is a simplified illustration of a manufacturer! supplier process encompassing selectable IP royalty bearing components incorporated in response to customer requirements, according to a preferred embodiment of the present invention.

Description of Preferred Embodiments

FIG. 1 illustrates an example of software architecture for an electronic product such as a mobile phone handset. The software architecture 100 comprises an application layer 110, a protocol layer 120, drivers 130 and various resources 140.

These software components are well known in the art and shall therefore not be described in detail herein.

However, for clarity, the application layer may comprise one or more modules, such as a Tegic T9 core 112 (a well known predictive text input mechanism), SIM application toolkit 116, etc., that is/are provided to the manufacturer of the product by 3r parties. The resources may include, by way of example only, graphics, fonts, sounds, language variants (including Tegic T9 language databases), etc. The software architecture 100 further comprises a plurality of software applications 150. The software applications 150 include applications provided to the manufacturer of the handset by 3rd parties. For example, the software applications may include a flash player 152 such as RealP1ayer from RealNetworks TM, Inc, and an HTML browser 154 such as the Opera Mobile Browser from Opera Software ASA.

As will be appreciated by a skilled artisan, products making use of such software architecture often comprise a large number of software components/applications provided by 3rd parties. The use of such 3rd party software requires royalties to be paid to those 3 parties for the use of their software.

Furthermore, it has become common for products, such as mobile phone handsets, to make use of approved standards, such as MP3, MPEG, GIF, JPEG, etc. Such standards are often not mandated for use by the corresponding telecommunication standard that the mobile phone is manufactured to be compliant with, such as the Global System for Mobile communication (GSM), and as such are generally referred to as non-essential' patents.

Consequently, it is necessary for IP royalties to be paid for the use of such standards, even if the applications, functions etc. that make use of those standards are provided by 3rd parties.

In a preferred embodiment of the present invention a customer, for example a mobile phone network operator or a consumer, is provided with the ability to customise a product, and in particular to choose whether or not a product comprises features/functionality that requires IP royalties to be paid to third parties. This embodiment is described in more detail with reference to FIG. 2 and FIG. 3 below.

In accordance with a preferred embodiment of the present invention, FIG. 2 illustrates a substantially automated control system 200 for managing and controlling the production/manufacture of a customisable product. Such a control system 200 may be used by a manufacturer/supplier of customisable products, for example mobile phone handsets. The control system has been adapted to support the provision of cost reduction by making features! functions that incur IP royalty payments to be made as selectable features/ functions.

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

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 envisioned 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 manner, 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 computer) of a sales representative of the manufacturer! supplier organisation. In this manner, the sales representative can 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 the customer might have, for example the nature or cost associated with certain third party IP, or clarify any options available to the customer, etc. In a still further alternative embodiment, the requirements capture tool 210 may comprise a proprietary software application provided by the manufacturer! supplier to the customer for inclusion on the customer's computer network, and capable of connecting to the manufacturer's/ supplier's computer system as required.

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

Once all the customer requirements have been entered, they are "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 preferably on a server. The back-end receives the submitted requirements information, and creates a file containing the captured information. The 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.

For the purposes of the present invention, the terms front-end' encompasses -Internet based graphical user interface presented over the (world-wide-web), and back-end' encompasses a manufacturer! supplier system comprising business logic relating to the products in question, and one or more associated databases.

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 preferably identified so that they can be retrieved from stock and incorporated into the customised product.

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

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 access and use the generated components to build and ship the customised product.

In a preferred embodiment of the present invention, prior to the necessary components being made available to the production system 240, the software components are tested to ensure that they function as intended/required.

-10 -The control system 200 further comprises an enterprise resource planning (ERP) system 230. The ERP system 230 is preferably 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.

The ERP system 230 preferably holds, and controls, information regarding available customisation options 232 for customising a product. By way of example, for electronic products containing embedded software, such as a mobile phone handset, the ERP system 230 contains details of available software features and/or functionality, including details regarding compatibility between, and requirements for, different features and functionality. In this way, the requirements capture tool 210 is able to obtain such information from the ERP system 220, and only allow a user to customise a product in a valid/allowable manner. This may be achieved by the requirements capture tool 210 interrogating the ERP system 230, either periodically or as and when required.

Alternatively, this may be achieved by the ERP system 230 "pushing" the information to the requirements capture tool 210, for example whenever new information is available.

The requirements capture tool 210 further obtains from the ERP system 230 pricing information, such that the requirements capture tool 210 is able to dynamically present to the user the price of the customised product, and update the price as the user continues to customise -11 -the product, for example by incorporating any third party IP royalty payment that is associated with a particular selected feature of an application, and therefore owed to the respective third party IP owner.

The ERP system 230 preferably also holds, and controls, information 234 regarding users of the system. For example, the system may be restricted to previously approved users, such as network operators. In order for a customer to use the system, it is necessary for the customer's details to have been entered on the system.

This would allow only users who have a sufficient credit rating or the like to make use of the system, as well as aiding in preventing random, incorrect and/or inappropriate use of the system, which could tie up computing resources, etc. In an advanced embodiment of the present invention it is envisaged that the requirements capture tool 210 provides different functions for different types of user, such as customers, consumers and internal users (i.e. 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 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 can be held within the ERP system 230, and when the customer logs onto the system (for example by -12 -way of a unique username and 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 typically be necessary for a consumer to enter all their requirements. However, it is envisaged that a consumer might be provided with fewer customisation options since certain options may require either a certain 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 also 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 preferably also holds information regarding stock levels, lead times for ordering new stock etc., for example, which is preferably provided by the production system 240. Furthermore, the ERP system 230 preferably also monitors production orders already scheduled on the production system 240. In this manner, it is possible to determine the earliest possible delivery dates for products depending on the requirements -13 -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.

It is also envisaged that the ERP system 230 also stores details regarding usage of the system. For example, the ERF system 230 preferably stores the time and/or dates that a user logs onto the system etc. Furthermore, it is envisaged that the requirements capture tool 210 allows a user to "save" a session, for example whilst entering their requirements. This feature is advantageous when a user may need to leave and return at a later date/time to finish entering the requirements.

When this is the case, the user is able to save the session, and thereby save the requirements entered up to that point. Thus, a user is able to identify the IP royalty cost related to a particular feature, and if this cost is undesirable the user is able to go off-line' and investigate whether the feature/function that incurs the royalty payment is desired/worthwhile at that cost. In this case, the requirements capture tool 210 preferably sends the entered requirements to the ERP system 230, which stores the information. The next time that the particular user logs on to the system, the requirements capture tool 210 is able to retrieve the information from the ERP system 230, thus saving the user from having to re-enter the information.

As previously mentioned, on receiving the customer requirements the product generator 220, and therefore -14 -software components associated with third party IP royalty payments, 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 preferably generates, for example, software binary "images" containing the required features/ functionality/ applications, etc. This is described in more detail later in the description, with reference to FIG. 3.

From the point of view of hardware, it is envisaged that a user's requirements includes 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 BOM, as mentioned above. Again, if a particular hardware component incurred a corresponding third party IP royalty payment, for example a battery type or type of display to be used, this cost would be displayed to the user.

As also mentioned above, every component of a product is allocated a unique part number. All part numbers are preferably held and controlled in the ERP system 230.

The product generator 220 preferably creates a complete list of all components to be used in a product.

-15 -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 retrieves the relevant part numbers. For new (i.e. specifically generated) components, the ERP system 230 creates new part numbers.

The ERP system 230 then uses the part numbers to create the BOM for that product, which it stores and also preferably 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, 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 240.

The ERP system 230 stores the BOM details 236 for every product ordered/built. Since the BOM for a product contains a list of every component of that product (settings, languages, etc.), the ERP system 230 holds a record of every software component used in any product, all standards (e.g. MP3, MPEG, GIF, JPEG, etc.) used in any product, etc. -16 -Furthermore, in accordance with the present invention, the ERP system 230 also holds all third party IP royalty and pricing information 237 for every component. This information preferably includes at least: i) An indication as to which products, applications, features, etc. require one or more third party IP royalty payments to be made; ii) For those products applications, features, etc. that require one or more third party IP royalty payments to be made, the entity to whom royalty payments are to made; iii) The amount of third party IP royalty (or where appropriate a means of determining the amount, for example where it is a percentage of the selling price of the product) that is to be paid; and iv) Any jurisdiction/country limitation associated with their party IP royalty.

Consequently, for any given product it is possible to ascertain from the BOM of that product that is customised and/or manufactured, those components that were included.

Then, from the royalty and pricing information 237, it can be determined: i) To whom (i.e. a third party IF owner) royalty payments are due; ii) How much royalty is to be paid per product, application and/or feature to each IF owner It is noteworthy that this information may also include jurisdiction/country factors, for example where sales to a particular country do not incur any royalty payments; and -17 -iii) The total amount of royalties per unit to be paid for that product; etc. 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.) that are 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.

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 can then 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. Preferably 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 (e.g. a user submits their requirements), the requirements capture tool 210 -18 -sends the customer requirements to the product generator 220, as well as informs 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.

The ERP system 230 preferably also controls 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 way, it is possible to cancel any order, for example if parts become unavailable or a customer wishes to cancel the order, with minimum 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 preferably confirms shipment to the ERP system -19 - 230, along with the quantity of units shipped. These shipping details 238 are then stored by the ERP system 230.

As a result, the ERP system 230 holds information regarding the quantity of units shipped for every product built. Therefore, combining this information with the BOM details 236 and the third party IP royalty and pricing information 238, the ERP system 238 holds all necessary information required for accurately determining the exact amount of third party IP royalties that are required to be paid, and to whom they are required to be paid. Furthermore, since the whole process described above is substantially automated, no human interaction has been necessary. Thus, no additional resources are required to determine such third party IP royalty information.

For the embodiment illustrated in FIG. 2, a third party IP royalty payment function 250 is provided. The third party IP royalty paymentfunction 250 may be a discrete component to the ERP system 230, as illustrated in FIG. 2. However, in an alternative embodiment, the third party IP royalty payment function 250 forms an integral part of the ERP system 230.

The third party IF royalty payment function 250 is coupled to the ERP system 230, and is able to retrieve information required for identifying those royalty payments that are due, and the amount of royalties that are due. This information may simply be the raw BOM details 236, third party IP royalty and pricing information 237 and shipment details 238. In this -20 -manner, the third party IF royalty payment function 250 is able to manipulate the raw information to determine the required third party IP royalty payments details.

Alternatively, the ERP system 230 may comprise a further function (not shown), which receives queries from the third party IF royalty payment function 250. The further function then obtains the required information from the BOM details 236, third party IF royalty and pricing information 237 and shipping details 238 and from these formulates the response to the query. The response is then sent back to the third party IF royalty payment function 250.

In this manner, third party IF royalty payments can be substantially automated, considerably reducing required human resources, as well as reducing the likelihood of errors due to, for example, human error.

Preferably, the ERP system 230 also holds details of all paid third party IF royalties, for example as a part of the shipment details 238. This information would be provided by the third party IP royalty payment function.

As will be appreciated by a skilled artisan, the preferred embodiment of the present invention, as described above, provides an automated method of managing third party IF royalty payments, even for customisable products. Thus, third party IF royalty payments can be identified and tracked individually and accurately, in an efficient and low resourced manner.

-21 -Consequently, only those third party IP royalty payments that are due are paid, thus allowing a manufacturer to pass those savings on to the customer, and/or increasing the profit margin for the manufacturer.

In particular, and advantageously, it is possible to accurately reflect in the price of a product the effect of adding or removing royalty-bearing components, since the requirements capture tool 210 is able to retrieve the third party IP royalty information from the ERP system 230. Thus, on the one hand a customer who is content with a simpler product is able to remove unwanted features and functionality and receive a reduction in the cost due to the removal of the royalty payments that are applicable for those unwanted features and functionality.

On the other hand, a customer who requires a more feature/ function rich product is able to make a more informed decision on which features/ functions to include, based on the cost incurred for incorporating such features.

As previously mentioned the ERP system 230 contains royalty and pricing information 237 for each component.

Where new components are generated, at the time of assigning new part numbers, the royalties and price for each new component can be determined and entered into the ERP system 230 based on the contents of each component.

Table 1 below illustrates an example of the royalty and pricing information 237 stored for a component by the ERP system 230.

-22 -

Table 1

Component Category Applicable Cost IP Owner ID# Territories (US$) ID 101 Manufacturer European $0.35 I.P.

Union Owner Ltd. ID 104 Manufacturer Other $0.00 I.P. Owner Ltd.

ID 1001 Customer All $0.50 N/A ID 198 Consumer All $2.00 N/A ID 489 Sample All $0.00 N/A ID 498 Staff All $0.35 N/A The first column of Table 1 has the heading "Component ID#". The entries in this column are preferably limited to a set of predefined values, and comprise the plethora of components that can be used in building the product, including all those components (hardware/software or firmware) that incur third party IP royalty payments.

The second column of Table 1 has the heading "Category".

The entries in this column are preferably limited to a set of predefined values. Each predefined value has a set of rules relating to it, which determine when those entries, and the corresponding information in the other columns, are relevant and how that information is to be treated.

For example, for the first two rows the category value is "Manufacturer". A "Manufacturer" category means that the -23 -information contained in that row relates to a cost for that component to the manufacturer. In other words, where a royalty payment is due for a component, the royalty that is payable per unit for that component is indicated in the "Cost" column.

The "IP Owner" category indicates to whom that cost is payable. This is required since for some components, royalties may be payable to more than one IP owner.

Finally, in the column with the heading "Applicable Territories", geographical variations in royalties/costs can be taken into consideration. It is envisaged that this category may be divided into two or more areas, depending upon the nature of the IP rights, such as country of manufacture, country/territory of sale, country of importation, etc. These rights relate to potential infringing acts, such as sale, manufacture, keeping, importation, etc. of an infringing product.

For example, it is envisaged that IP rights may be owed for a particular component or feature based on where that component or feature was manufactured, as compared to sold. That is, a component, such as a battery, may be manufactured by a third party vendor in Taiwan, and only sold in the European Union. If IP rights were only obtained by the third party IP owner in Taiwan, they may still be owed, dependent upon where the product was manufactured (or sold) . Thus, in alternative or enhanced embodiments, it is envisaged that an alternative or additional column related primarily to the country of sale and/or manufacture of a component or customised product can be included. Such a feature further increases -24 -the accuracy of third party IP royalty payments that are due.

Thus for the example illustrated in Table 1, a royalty of $0.35 is payable to IP Owner Ltd., whenever this particular component is included in a product within the European Union, but no royalties are payable outside of the European Union. Thus, the row in Table 1 shows the cost to the manufacturer within the European Union, which is $0.35. The second row in Table 1 shows the cost to the manufacturer outside of the European Union, which is $0.00.

Royalty payments are not always a fixed amount. For example, a royalty payment may be based on a percentage of the selling price of each unit in which the component is present. Alternatively, the royalty payment may be dependent on the number of units sold that comprise the component. Consequently, it is within the contemplation of the present invention that the "Cost" column may contain a formula for determining the true' royalty payment.

The next row in Table 1 has a category of "Customer".

This means that the information contained in that row relates to a cost for that component to a customer, such as a mobile phone network operator. Therefore, for the example illustrated in Table 1, where a customer orders a product comprising this component, the cost to that customer for choosing this component is $0.50.

The fourth row in Table 1 has a category of "Consumer".

This means that the information contained in that row -25 -relates to a cost for that component to a consumer, i.e. an end user. Therefore, for the example illustrated in Table 1, where a consumer orders a product comprising this component, the cost to that consumer for choosing this component is $2.00.

The fifth row in Table 1 has a category of "Sample".

This means that the information contained in that row relates to a cost for that component when the product is a sample that has been ordered, for example by an employee of the manufacturer for validation purposes, etc. For the example illustrated in Table 1, where the product is a sample comprising this component, the cost for including this component in the sample is $0.00.

The final row in Table 1 has a category of "Staff". This means that the information contained in that row relates to a cost for that component to a member of staff of the manufacturer. Therefore, for the example illustrated in Table 1, where a member of staff orders a product comprising this component, the cost to that member of staff for selecting this component is $0.35.

As an example, let us consider that a customer configures a product comprising the components relating to Table 1, and places an order for 50,000 units to be shipped within the European Union and 20,000 substantially identical units to be shipped outside of the European Union.

Since all 70,000 units are substantially identical, a single BOM will be used for both European Union destined, and non European Union destined, units. However, the shipment details 238 will contain two separate entries, -26 - one for the European Union units and one for the non-European Union units.

When determining the royalty payments due to I.P. Owner Ltd, the first step is to identify all relevant BOMs, e.g. all BOM5 in which the component relating to Table 1 is present. For simplicity, let us assume that there is only a single BOM.

Next, the shipment details 238 are searched for all occurrences of this BOM. As mentioned above, two shipments will be identified, one for the European Union destined units and one for the non-European Union destined units.

Finally, for each shipment, the third party IP royalties due can be determined using the third party IF royalty and pricing information 237. Looking at Table 1, it can be seen that for every unit shipped to the European Union, a royalty of $0.35 is due, whilst for units shipped anywhere else there is no third party IF royalty due.

Thus, in this example 50,000 units are shipped to the European Union. Therefore, at a rate of $0.35 per unit a total royalty of $17,500 is due. However, since no royalty is due for the units shipped outside of the European Union, no royalty is due for 20,000 units, thereby providing a cost saving of $7,000.

As can be seen, the present invention allows an efficient method of identifying when royalty payments are due. In this manner, and advantageously, it is no longer -27 -necessary to pay third party IP royalties on units that do not incur such costs, due to them being shipped in circumstances or to territories that do not require a third party IP royalty charge.

Referring now to FIG. 3, the process of generating a product preferably 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) . In particular, the process configures how the code modules execute in a product being manufactured by changing the data. 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 is advantageous when configuring complex embedded software-based products due to the plethora 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 way, the requirements capture tool 210 can provide a user (e.g. a customer, sales representative etc.) with the opportunity to effectively "click" together a working device from preferably a mixture of embedded software and additional hardware components.

-28 -The embedded software is such that a user "clicks" together a working software domain (hereinafter referred to as "image") comprising, for example, an operating system (OS) and/or one or more applications and/or one or more settings and/or one or more resources to fit that phone. In the context of the present invention, one or more of operating system (OS), application(s), setting(s), resource(s) may be recorded as being associated with a third party IP royalty charge.

Notably, it is within the contemplation of the present invention that the customisation of a product, such as an electronic software-based product like a mobile phone, may encompass every aspect of the product, in addition to the embedded software elements. 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. It is noteworthy that one or more of the above may also be recorded as being associated with a third party IP royalty charge.

Referring now to FIG. 3, a preferred implementation of the system architecture 200 to control the complete configuration process for, say the build of a Smartphone, is illustrated in more detail. The preferred system architecture 300 comprises a version-controlled file storage function 305, which for the preferred embodiment of the present invention forms a part of the ERP system 230.

-29 -The version-controlled file storage function 305 comprises the necessary software and hardware building blocks 310, comprising core building blocks 315, variant builds 320, localisation files 325 and binary definition files 330, 335. In the preferred 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 is also preferably 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 generator 220. A customer preferably accesses a user interface, (or 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 305.

The output of the requirements capture tool 210 is preferably 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.) will preferably 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 -30 -definition file 345 may be in the form of a mark up language file, such as an adaptation of XML.

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 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 can then be passed to a production system 380, for example the production system 240 of FIG. 2, for actual construction on the assembly line.

The production system 380 preferably comprises a configuration administrative system automatic software loader 375, for configuring the product with selected software elements, such as applications. The selected software code! applications are extracted from a configuration system database 380.

For the purpose of configuring a Smartphone product build, it is envisaged that the product generator 220 may generate a production order with an adapted BOM 360.

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

-31 -The Variant builds 320 preferably contain order/customer specific information and comprise the configurable software items for the Smartphone. 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. Preferably, the product generator 220 also specifies what version of the build environment is to be used/being used.

The requirements capture tool 210 preferably also provides an object representation of configurable elements in the build environment. As such, the requirements capture tool 210 comprises software and preferably hardware representations of product elements, such as mobile phone elements. The software representation comprises embedded software elements, so that a mobile phone can be designed/ built from these embedded software elements. Preferably, the embedded software elements are stand-alone items that may be configured within a phone in a plug-in' type manner.

Such an arrangement for embedded software modules lend themselves to easier third party IP royalty payments, as they are considered individual entities.

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 -32 -both the application and its configuration relevant behaviour. In this form, the customer or consumer is able to manipulate the elements of the requirements capture tool 210, in effect by performing drag' and drop' and verify' operations. The build environment/product generator 220 is modified to deal with the application object, which preferably does 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 should preferably be an object in the build environment. If the software component object cannot be 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 elements are preferably 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. -33

Although the present invention has 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 manner, a consumer is able to order a customised single unit to their requirements.

Alternatively, a consumer may be able to select/configure software upgrades, additional software applications, accessories, etc. for a previously purchased product.

Again, according to the preferred embodiment of the present invention, such software upgrades, additional software applications, accessories, etc. may be associated with a third party IP royalty charge.

It is also envisaged that a customer/consumer order may comprise a customer identifier for a particular software- package option. Thus, the part number for the software-package option may be specific to Customer X' . 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.

Referring back to FIG. 2, the product generator 220, ERP system 230 and production system 240 preferably exist within a secure environment 260. In this manner, with the exception of a controlled number of high-level administrators, access to the operation of these three systems is prohibited. This prevents any interference of the operations performed within the system and more -34 -importantly prevents any corruption or manipulation of the BOM details 236, third party IP royalty and/or pricing information 237 and/or shipment details 238.

Furthermore, it is envisaged that even where high-level administrators have access to the secure environment 260, any actions performed by such administrators is logged.

The secure environment 260 provides the advantage that the BOM details 236, third party IP royalty and pricing information 237 and the shipment details 238, collectively and the third party IP royalty data, are reliable and trustworthy. In this manner, the manufacturer is able to demonstrate to an IP owner the integrity of the system once, and thereafter the IP owner can easily retrieve the third party IP royalty data to perform an audit, without the need to audit the entire system.

Alternatively, the manufacturer can have an audit carried out by an independent auditor, who can certify the integrity of the system. Thereafter, any IP Owners desiring to perform an audit can be provided with the details of the independent audit to satisfy themselves of the integrity of the system. This will save the manufacturer from having to suffer numerous separate audits from numerous IP owners.

It is within the contemplation of the invention that the inventive concepts hereinbefore described are not limited to the described phone build or associated manufacturing system of the preferred embodiment. Indeed, it is envisaged that the inventive concepts are applicable to -35 -any suitable mass-produced product that is capable of supporting selectable items, some of which may incur third party IP royalty charges.

It will be understood that the process of managing, controlling and accurately calculating third party IP royalty payments, as described above, tends to provide one or more of the following advantages: (i) A substantially automated system for identifying when third party IP royalty payments are due, in particular in relation to customisable products where third party IP royalty payments can vary depending on customer requirements; (ii) An accurate management of third party IF royalty payments; (iii) Substantially removes the need to pay unnecessary third party IP royalties, thus saving money; (iv) Allows savings to customers or consumers by providing transparency to third party IP royalty payments, and allowing the customers or consumers to decide whether to include features/functionality; (v) Provides a secure, efficient, traceable and trustworthy system that reduces auditing requirements, and provides confidence to third party IP owners; (vi) Provides a reduction in required human resources; and (vii) Provides a reduction in mistakes and the like due to, for example, human error.

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

Thus, the present invention provides a system that allows for a more efficient and effective method of managing and controlling third party IP royalty payments and the like, and can form an integral part of the running of a business thereby alleviating at least one of the aforementioned disadvantages with prior art arrangements has been alleviated.

Claims

-37 -Claims 1. A method of determining a third party Intellectual

Property (IP) royalty payment charge for a customisable product characterised by the steps of: automating substantially a process relating to identifying those items that are to be incorporated into a customisable product; and identifying a third party IP royalty payment charge associated with a number of items the customisable product.

2. A method according to Claim 1 further characterised by the steps of: providing a consumer or customer with an ability to select items relating to a customisable product and identifying a third party IP royalty payment charge associated with each of said items such that the consumer or customer can select an item and be informed of the consequent IP charge.

3. A method according to Claim 1 or Claim 2 further characterised in that the third party IP royalty payment charge relates to hardware items and/or software items and/or firmware items relating to a customisable electronic product.

4. A method according to any preceding Claim further characterised by the step of: storing bill of material details for third party IP royalty charges and pricing information for a plurality of items to be incorporated into the customisable product.

-38 - 5. A method according to any preceding Claim further characterised third party IP royalty payment charge comprises one or more of the following: i) An indication as to which products, applications, features, etc. require one or more third party IP royalty payments to be made; ii) For those products applications, features, etc. that require one or more third party IP royalty payments to be made, the entity to whom royalty payments are to made; and iii) An amount of third party IP royalty that is to be paid.

6. A method according to any preceding Claim further characterised by the step of: combining information regarding a quantity of products shipped with a bill of materials information (236) and/or third party IF royalty and/or pricing information (238) to determine an amount of third party IF royalties that are to be paid.

7. A method according to Claim 6 further characterised in that the step of combining information also comprises information on entities holding the third party IF royalties that are to be paid.

8. A system (200) for determining a third party Intellectual Property (IF) royalty payment charge for a customisable product comprising: -39 -a customer requirements capture tool (310) arranged to receive a customer's requirements and automatically create in response thereto a computerised component list format employed by a manufacturer relating to a customisable product; and a product generator (320) operably coupled to the customer requirements capture tool (210) and arranged to automatically generate a list of components in response to the customer's requirements; wherein the system is characterised by: an IF royalty function (250) operably coupled to the product generator and arranged to identify a third party IF royalty payment charge associated with a plurality of individual items from the generated list of components to be used in a manufacture of the customisable product.

9. A system according to Claim 8 further characterised by a resource planning system (330) operably coupled to the customer requirements capture tool (310) and arranged to offer as selectable items of the customisable product, one or more items that incur third party IF royalty charges.

10. A system according to Claim 9 further characterised in that the resource planning system (330) stores or is operably coupled to a file storage device that stores bill of material details (236) for third party IF royalty charges and pricing information (237) for a plurality of items to be incorporated into the custornisable product.

-40 - 11. A system according to any of preceding Claims 8 to 10 further characterised in that the third party IP royalty payment function (250) comprises one or more of the following: i) An indication as to which of one or more product, application, feature, requires one or more third party IP royalty payments to be made; ii) One or more entities to whom royalty payments are to made; and iii) An amount of third party IP royalty payment.

12. A system according to any of preceding Claims 9 to 11 further characterised in that the resource planning system (330) is configured to combine information regarding a quantity of products shipped with bill of materials information (236) and third party IP royalty and pricing information (238) to determine an amount of third party IP royalties that are required to be paid.

13. A system according to any of preceding Claims 8 to 12 further characterised in that the system comprises a secure environment 260 to maintain integrity of pricing and third party IP royalty information.

14. A method substantially as hereinbefore described with reference to, and/or as illustrated by, FIG. 3 of the accompanying drawings.

15. A system substantially as hereinbefore described with reference to, and/or as illustrated by, FIG. 2 or FIG. 3 of the accompanying drawings.