Henkel: IP Modularity

Technische Universität München
IP Modularity • Henkel, Baldwin, Shih 1
IP Modularity:
Profiting from Innovation by Aligning
Product Architecture with Intellectual Property
Joachim Henkel1, Carliss Y. Baldwin2, Willy Shih2
1Technische Universität München
2Harvard Business School
PDW "Intellectual Property Management and Innovation Appropriability:
Towards a New Research Agenda"
AoM, 10 August, 2013

“Every action we take will be done with
an eye toward striking this more subtle
balance between proprietary and open.“

Selective openness – Modular architecture
• Balance between proprietary and open:
selective openness
• Selectivity is facilitated by a
modular architecture
• Modularity to accommodate selective
IP treatment: “IP Modularity”
vs.

Example: M-Systems
• Seller of embedded flash memory
• With open source driver, could have tapped a larger market (Linux)
• But: flash management software needed to remain proprietary
Sources: http://www.sandisk.com/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=3494;
http://linuxdevices.com/news/NS9657944693.html; Kaplan (2006), http://www.linuxdevices.com/articles/AT2185129745.html (figures modified)
HOST FLASH MEMORY
Driver, incl.
Flash Mgmt. SW
had to be kept proprietary

M-Systems’ Solution
• In 2006, re-modularized the flash management software:
• Now: “thin” driver open, flash management software protected:
Sources: http://www.sandisk.com/Corporate/PressRoom/PressReleases/PressRelease.aspx?ID=3494;
http://linuxdevices.com/news/NS9657944693.html; Kaplan (2006), http://www.linuxdevices.com/articles/AT2185129745.html (figures modified)
HOST FLASH MEMORY
Thin
driver
Flash
Mgmt. SW
could be made open source
Driver, incl.
Flash Mgmt. SW
Thin
driver
Flash
Mgmt. SW

Existing theory can not explain M-System’s move
It was not the aim to…
• improve internal functioning
• distribute/simplify R&D or production
• enable re-use of components
• simplify maintenance
• satisfy heterogeneous needs
• keep flexibility for need changes
engineering
use
HOST FLASH
Driver, incl.
Flash Mgmt. SW
HOST FLASH MEMORY
Thin
driver
Flash
Mgmt. SW
FLASH MEMORY

Rationale: IP modularity
Kaplan (M-Systems):
• “The second generation EFD introduced a new architecture […]
• With sensitive IP now embedded in the storage device, flash
vendors no longer need to worry about exposing competitive
secrets.”
Source: Kaplan (2006), http://www.linuxdevices.com/articles/AT2185129745.html

“IP modularity” is about managing…
intellectual property rights
and
a system’s modular structure
in conjunction,
such as to reconcile
distributed value creation
and
value appropriation

Two Types of IP Modularity
IP Modularity can relate to…
• … the focal innovator’s own IP. Example: M-Systems
• … external IP. Example: braking system

IP Modularity with External IP: Braking System
• Car stability system, developed by major car maker
• Builds upon a supplier’s braking system
• OEM supplies its stability system to the supplier,
who then supplies the combined system back to the OEM
• To keep the OEM’s technology proprietary from other customers of the
supplier, the system was redesigned
• Interviewee: “So, as the vehicle develops,
as the technology develops, sometimes
we need to re-segment both hardware
and software modules, or the modularity
of the system, based more on the commercial
needs of, say, protecting an in-house algorithm,
than on just the most efficient design.”
OEM A:
stability
system
supplier:
braking
system

Braking System and Stability System
OEM A:
stability
system
supplier:
braking
system
supplier
integrates
delivered
to other
OEMs
delivered
to OEM A

• An artifact is “IP modular” when the modular structure
imposed by intellectual property rights (IP rights)
coincides with its design structure
– Comprises formal IP (patents, copyright, contracts) and informal IP
(secrecy, lead time, …)
• IP-wise, which elements…
– shall (own IP) or must (external IP) be treated identically /
differently?
– will make differential treatment desirable or necessary
in the future?
What is IP Modularity?

IP Modularity: Categories
TYPE OF
IP MODULA-
RITY
own IP:
IP status of modules
can be specified
external IP:
externally given
FUTURE NEEDS AND
OBLIGATIONS W.R.T. IP
certain uncertain

Own IP / Certain
TYPE OF
IP MODULA-
RITY
own IP:
can be specified
external IP:
externally given
specification
of IP status of
own artifact
FUTURE NEEDS AND
OBLIGATIONS W.R.T. IP
certain uncertain
Cases in the paper:
M-Systems, IBM 360, IBM PC, SMaL, F101 engine, APIs, inkjet printers, Intel vs. AMD

When IP Modularity implies an integral design
Inkjet printers
• Two main modules: cartridge, printer itself
• Question: where to put the printhead?
• Integration with printer: lower cost
• But: HP, Canon integrated printhead with cartridge
• Rationale: cartridge linked to revenues,
but weak IP; Integration extended the
printhead’s stronger IP to cartridge
 Modular architecture determined by IP
Source of figure: HP

Conclusions
• IP must be taken into account when devising product architecture
– applies to products, but also to processes and organizations
– also informs the established theory of modularity
• IP modularity allows…
– to resolve conflicts between value co-creation and value capture
– to avoid hold-up arising from incoming IP
• IP modularity is increasingly important
– open and semi-open innovation processes matter more
– IP increasingly important
• IP modularity is an issue for strategy
– affecting value appropriation and business models
– being of a long-term nature
Thank you

Comments welcome
Prof. Dr. Joachim Henkel
Arcisstr. 21
D – 80333 Munich
henkel@wi.tum.de
http://www.wi.tum.de/tim
+49 - 89 - 289 25741

BACKUP

But: Modularity can also pose risks for value capture
Examples:
• IBM System/360
• IBM PC

Unhappy outcomes (1)
IBM System/360
• Modularize the
technical system
• Identify the possibility
for external value creation
• Assert exclusive control
of knowledge elements
for an essential module
• Prevent exclusive control
by others of knowledge
elements for comple-
mentary modules

Unhappy outcomes (2)
IBM PC
• Modularize the
technical system
• Identify the possibility
for external value creation
• Assert exclusive control
of knowledge elements
for an essential module
• Prevent exclusive control
by others of knowledge
elements for comple-
mentary modules

Illustration (1)
B
B B
B
A
A A
(a)
B
B B
B
A
A A
(b)
B
B B
B
A
A A
(a)
B
B B
B
A
A A
(b)
Note:
Elements A, B
have distinct
IP status
Systems with integral (a) and IP-modular (b) structure

Illustration (2)
Note:
Elements A, B
have distinct
IP status
Systems with modular (a) and IP-modular (b) structure
B
B B
B
A
A
(a)
A
B
B
B B
B
A
A
(b)
A
B
A A
B
B B
B
A
A
(a)
A
B
B
B B
B
A
A
(b)
A
B
A A

“IP incompatibility”
• A: OSS code under the GPL
• B: from commercial supplier; license forbids disclosing the source code
• C: developed in-house; right to read, but not to modify, shall be granted
• Elements in the same component can not be separated and treated differently!
A
B
B
A
C
CC
B
AB
C
B
not IP modular
Strong IP
incompatibility
in all
components,
in particular
those
containing
A and B
IP modular
A
B
B
A
C
CC
B
AB
C
B
Components
can be
treated in
distinct ways;
they are
“IP Modules”

How modularity enhances value creation (1/2)
Cognitive
• Facilitates understanding of complex artifacts
• E.g., Simon (1969), Parnas (1972), Aoki (2001)
Organizational
• Enables division of labor (intra/inter firm, for R&D/production)
• Intra firm: e.g., Brooks (von Hippel (1990), Sanchez and Mahoney (1996),
Baldwin and Clark (2000), Chesbrough and Kusunoki (2001), Takeishi
(2002), Puranam and Jacobides (2005), Brusoni and Prencipe (2006),
Hoetker (2006), Colfer (2007)
• Inter firm: e.g., Langlois and Robertson (1992), Baldwin and Clark (1997),
Sturgeon (2002), Langlois (2003), and Staudenmayer et al. (2005), Baldwin
(2007), Ethiraj (2007), Ethiraj et al. (2007)

How modularity enhances value creation (2/2)
Functional
• Improves internal functioning, enables re-use of components,
simplifies maintenance
• E.g., Parnas (1972), Henderson and Clark (1990), Garud and
Kumaraswamy (1995), Ulrich (1995), Baldwin and Clark (2000), Langlois
(2002), MacCormack and Iansiti (2004)
Use
• Satisfies heterogeneous demand, increases flexibility, allows
selective upgrades
• E.g., von Hippel and Finkelstein (1979), Baldwin and Clark (2000),
Schilling (2000)

Consequences of Modularity
• Modularity allows for distributed value creation – open innovation,
outsourced production etc.
• BUT: modularity may have undesired consequences (IBM 360, PC);
the focal firm may lose control and hence fail to appropriate value
• Strategic challenge: To appropriate value in a modular system
• IP Modularity helps to avoid such loss of control, reconciling
distributed value creation and value capture
• It is obtained by managing architecture – module boundaries – and
IP status of modules jointly

Scope conditions for argument
• Complex products and processes
– Many components
• Components are complementary
– Functional system needs several components
– Some components are essential, some are not
• Designers have some degree of choice in dividing up components
and defining module boundaries
– Architectural freedom

Summaries of Findings: Own IP / Certain
• Potential for value co-creation in the ecosystem. Whenever the potential
for value co-creation exists in the surrounding ecosystem, distributing own IP
into relatively unprotected “open” modules and highly protected “closed”
modules will be advantageous.
• Distributed co-creators. The more distributed, numerous, and anonymous
the co-creators of value, the more advantageous it is to establish an IP
modular system made up of unprotected open modules and protected closed
modules.
• Customization. The greater and more varied the need for customer
adaptations, the more advantageous the more advantageous it is to establish
an IP modular system made up of unprotected open modules and protected
closed modules.
• Avoiding IP leakage. When the focal firm must rely on opportunistic suppliers
and/or employees and its IP is not strongly appropriable, distributing own IP
into discrete, non-overlapping modules with little or no stand-alone value and
allocating responsibility for each module to a different supplier or business unit
will be advantageous.

Summaries of Findings: External IP / Certain
• Avoid compromising own IP through integration with external IP. When
distributed value creation requires linking the components under the focal firm’s
own IP with components under external IP such that the bundle is beyond the firm’s
control, an IP-modular architecture helps avoid compromising the firm’s own IP.
• Holdup risk. IP modularity with external IP is advantageous when the focal firm
faces the risk of holdup from IP suppliers. The module boundaries should go
between the firm’s own IP and the external IP.
• Distributed ownership of external IP. IP modularity with external IP is
advantageous when the focal firm obtains IP on different terms from diverse
sources. Module boundaries should be placed to ensure IP-compatibility within
modules and to minimize the costs of renegotiation. In particular, it should be
possible to change the IP status of a module without renegotiating numerous IP
licenses.
• Establishing control of external open IP through integration with own IP.
Integrating an “open” component under external IP with an own component under
strong appropriability into one module may allow to establish control of the open
component.

Summaries of Findings: Uncertain
• Uncertainty and Own IP. An “overly modular” product or process architecture
creates options to capture value in the future by selectively adapting the IP
status of individual modules. Such options for IP modularity of own IP are more
valuable in the presence of high market or technological uncertainty.
• Inadvertent infringement. A product or process architecture characterized by
IP modularity is a partial defense against unanticipated external IP claims,
because it gives the firm options to “design around” the claims without
redesigning the whole system.

Henkel: IP Modularity

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (14)

Semelhante a Henkel: IP Modularity

Semelhante a Henkel: IP Modularity (20)

Mais de Alberto Minin

Mais de Alberto Minin (15)

Último

Último (20)

Henkel: IP Modularity