Using Strings to Compose Applications from Reusable Components
`BeComm Corporation
`info@becomm.com
`October 4, 2001
`
`The past decade in technology has evidenced an explosive growth in the proliferation of new web and
`network services, digital data and content, new and increasingly diverse computing devices and new
`wired and wireless networks for data communication. With the billions investments in hardware
`infrastructure, software infrastructure and network infrastructure, not only do end users want to see new
`applications, but ISVs and OEMs must deliver these applications in a way that assuages managements
`demands for an ever-increasing return on investment. As a result, this changing landscape has imposed a
`critical challenge on software developers and IT managers to improve time to market and reduce
`development costs. To leverage this existing investment in hardware, network and software infrastructure,
`applications must be developed to capitalize on new revenue opportunities while also reducing existing
`operating expenses. The key observation made by many is that reuse of technology assets to compose
`new applications is critical to addressing these challenges.
`
`There are, however, several issues that make reuse difficult to achieve. First, reuse is an easily
`misunderstood concept, as it is not simply using previously engineered or acquired technology asset more
`than once. It requires reuse engineering that prepares technology assets to be reusable. Second,
`identifying what software components can be reused is a confusing process, as traditional design
`approaches tend to prevent reuse outside the narrow scope or domain in which they were initially
`developed. Finally, software engineering techniques and methodologies alone are insufficient tools for
`developers to achieve true reuse. Even with the best development methodologies and architectural
`techniques, taking a traditional approach to development can reduce the potential for reusing technology
`assets or limit the type of potential reuse, without later additional re-engineering.
`
`To address these issues requires an application framework that promotes reuse at every level: from fine-
`grained application components to large-scale back-end systems. The lack of a solid application
`framework for reuse has prevented it from being widely accepted and implemented. Such a framework
`needs to yield solutions that are dynamic enough to adapt reusable components to changing networks,
`media types, and device types at runtime in unanticipated ways; distributed so as to leverage services
`within the WAN and LAN; and efficient enough to run on network servers and resource-constrained
`embedded devices alike. While traditional techniques (e.g., object-oriented design and component
`systems with the appropriate extensions to support client/server systems) and methodologies (e.g., UML
`that aids in the specification and design of systems) have various strengths they have two inherent
`limitations that prevent the developer from creating solutions that are truly reusable. These limitations are
`as follows:
`Limitation 1: Imperatively Defined Configuration Intelligence
`In traditional application development, the software developer explicitly identifies a set of required
`services and specifies how and when to interface with them. This necessitates that developers have a
`priori knowledge of all services that are to be used directly by their component. This entanglement of
`configuration intelligence with application logic transcends from the so-called “main loop” of the
`application down
`to granular components composing
`the application. While conventional
`OO/component techniques enable the developer to be oblivious of an algorithm’s implementation
`details, they are still required to know the interfaces, and to write code that depends on those
`interfaces to meet the goals of the application. Consequently, it is difficult to chain together services
`to achieve a desired goal without explicitly specifying all possible configurations in advance.
`Therefore, in practice, imperatively defining the configuration intelligence limits the application to a
`static set of predefined interactions.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 1 of 10
`
`Page 1 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`Limitation 2: Process-centric Computing
`The traditional notion of an “application” implies a process-centric viewpoint, in which each
`application is embodied by a computational process on a node in the network. From the end-user’s
`perspective, the application is usually perceived to be the process with which they are directly
`interacting (e.g. a spreadsheet or a web browser), possibly extended to include the back-end services
`supporting that process, such as a web server and CGI program. In the case of distributed systems,
`the “application” might be interpreted as living on both the client and server node.
`
`The framework for enabling communication is considered external to the application itself, existing
`as a separate layer on which the application resides. Application development focuses on defining
`the computational process, encoding the relationships between objects, and invoking methods from a
`known set of interfaces, but the flow of data between processes is considered subordinate to the
`processes themselves. This “process-centric” notion of an application is inherently limiting to the
`developer, because it does not easily accommodate the potential for an application to participate as a
`service operating on a stream of data flowing through a dynamic configuration of other services.
`
`Today’s emphasis on return on investment requires the reuse of legacy technology assets as well as newly
`designed algorithms, and therefore evidences the need to overcome traditional application design
`limitations such that application logic can be reused in a more flexible, efficient, and cost sensitive
`manner.
`
`Strings™ defines an application framework that supports build-time and more importantly runtime
`adaptability of reusable software components. The methodology used to develop Strings-based
`applications facilitates the creation of software components as services with an unprecedented degree of
`reusability, thereby enabling software developers to quickly create smarter and less expensive solutions.
`
`2 Strings Methodology
`
`To achieve an unprecedented degree of reuse, the Strings methodology is to (i) turn application logic into
`services (ii) to augment the process-centric paradigm with a dataflow-centric paradigm, in which the
`defining principle of the application are goal rules that control the flow of data itself over these services.
`The data can then pass through an ad hoc defined sequence of reusable application services. The fact that
`these services may be embodied in processes is secondary to the primary notion of a stream of data.
`
`By separating configuration intelligence from application logic into rules and primitive services,
`respectively, it is possible to declaratively define how and when the service can be used. This separation
`results in a form of communication indirection, in which no service refers to the interface of any other
`service, and no two objects talk directly to each other. Instead, an “intelligent engine” facilitates the
`creation of communication paths between objects automatically by reasoning about the goals of the
`application.
`
`In this way it is possible to hook services together at run-time as they are discovered. As a result, the
`traditional tight coupling of objects and the so-called “main loop” of the application ceases to exist, being
`replaced by a set of rules and a “higher-order control” that coordinates the flow of communication
`between services. With such an approach, applications no longer exist as static “programs”, but rather as
`dynamic invocations of services that can be automatically configured in unanticipated ways, adapting to
`meet the goals of the system on the fly.
`
`The resulting inversion of control greatly improves the task of building applications, as the programmer is
`freed from the task of specifying configuration information imperatively. Routing decisions and state
`management are removed from the application, and handled by the system. In this model, objects can talk
`to each other without a priori knowledge of each other’s existence.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 2 of 10
`
`
`Page 2 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`3 Strings Framework
`
`The Strings framework consists of the following components:
`1. A dynamic set of discrete services, called Beads™, which encapsulate application logic.
`2. A set of declarative rules specifying when beads are used to achieve some application-specific
`goal, which can either be specified by the user, system’s integrator, or catalyzed by system events
`at runtime.
`3. An “engine” that matches the application-specific goals with the declarative rules of the beads,
`and thereby decides what services to employ to meet the goals.
`The rest of this section discusses this components in further detail.
`
`3.1 Beads
`Beads encapsulate resources as discrete services that adhere to a highly structured interface. The bead
`itself is a software component that exports a granular unit of functionality. Examples of resources that a
`bead can encapsulate include:
`• hardware such as a video display, speaker, microphone, mouse, Ethernet, etc.
`• protocols such as TCP/IP, HTTP, SOAP, email (POP3, SMTP), etc.
`•
`transformational algorithms such as audio/video decoders, etc.
`• SDK technologies such as speech-recognition engines (e.g., IBM’s ViaVoice), text-to-speech
`generators, etc.
`• Backend services such as Database, CRM, and Content Management Systems.
`In other words, any resource that can be defined as a service can be encapsulated within a bead. There is
`no direct reliance on a particular programming language (such a Java) required to use the framework.
`The purpose of the bead is to completely hide both the interface and the implementation of the resources
`they encapsulate, and thereby cleanly separate the internal algorithm from its external relationship to
`other such algorithms. The methodology of encapsulating functionality into discrete elements encourages
`a software partitioning that exhibits no redundancy or dependencies on other beads. This results in code
`that is highly reusable, and enables services to be assembled into dynamic applications by an automated
`engine.
`
`Beads are the building block for the pipeline of processing elements applied to a data flow. Beads
`conform to a strongly-typed interface pattern, in which operations are represented as Edges, which are the
`touch points of how beads are strung together into a pipeline. Configurations of pipelines range from
`linear, unidirectional to complex, bi-directional flows of data. Bi-directional flows are automatically
`managed by the Strings engine, such that a bead may send data in the opposite direction of the flow
`without needing to know from where the flow originated.
`
`A bead is described to the Strings engine in an XML-based Bead Schema that declares the number and
`direction of its edges and the conditions indicating when its input edges can be used and what type of data
`comes out of its output edges. A Bead Schema can be authored directly in XML or with the Bead Schema
`Editor, which is a development tool included with the Strings toolkit.
`
`Figure 1 shows an example bead schema that defines the operation of an MPEG audio decoder. The
`schema identifies the bead’s name, description, and one or more edges. Each edge is a separately
`nameable entity, and in this example the MPEG decoder bead has a single “filter” edge, which logically is
`both an input and output edge. The precondition of the edge predicates that it should only be used if the
`content-type variable of the data is set to the MIME-like string of ‘audio/mp3’. Similarly, the post
`condition overrides the content-type variable to the MIME-like string of ‘audio/pcm’ to indicate the
`edge’s output type.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 3 of 10
`
`
`Page 3 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`<BEAD_SCHEMA name="mp3decoder">
`<DESCRIPTION>
` The Mp3Decoder bead decodes mp3 data to PCM audio.
`</DESCRIPTION>
` <EDGE name="Decode" shape="filter">
` <PRECONDITION value="query:Content-Type==’audio/mp3’"/>
` <POSTCONDITION value="namespace:Content-Type=’audio/pcm’"/>
` </EDGE>
`</BEAD_SCHEMA>
`
`
`
`Figure 1. Bead Schema for an MPEG Layer-3 decoder.
`Each edge is implemented as a set of handlers: the message handler, which is called on to process each
`message passing through the edge, and several auxiliary handlers to support the creation and destruction
`of data flows. The partitioning of logic into these handlers, combined with the strongly-typed pipe-like
`structure of the edge interface, is precisely what enables Strings to hook beads together on the fly to
`create higher-level services based on the needs of the network, the system, the media types being handled,
`and user preferences.
`
`3.2 Declarative Rules
`Rules are the primary mechanism for configuring Strings, as they define when beads are used to perform
`some task to achieve some application-specific goal. A rule is defined as a sequence of one or more steps
`to execute when a specific set of constraints are met.
`
`Constraints are defined using an evaluation grammar that supports an arbitrary set of evaluation object
`types. The type of an evaluation object can be an integer, an IP address, a date, or the content-type of the
`data, etc., which allows for a rich set of declarative rules to be used. For example, if developing an
`application for the consumer space, it would be possible to declare the constraints of a rule that specify to
`play music on the home theatre system after 6:00PM. The result of a constraint evaluation determines
`both whether Strings will execute the steps specified by the rule, as well as which steps to take if multiple
`rules match the constraints.
`
`If all of a rule’s constraints are met, then Strings will execute the specified steps. The collection of steps
`associated with a rule is referred to as a route along which data will flow. There are three types of steps
`that the Strings engine can take: 1) a bead step which passes data to a particular bead; 2) a seed step
`which populates the “namespace of an application context”* with a value that may satisfy some condition
`of another rule; and, 3) a loopback step which specifies what should be sent in the opposite direction of
`the original data flow.
`
`A rule is described to the Strings engine in an XML-based format that declares a predicate and an
`associated route of steps. The rules can be authored directly in XML or with a graphical Rule Editor.
`
`Figure 2 shows an example rule that plays audio content of type MPEG to a speaker device, as defined by
`its predicate and only a single seed step. The rule declares that for data labeled with a content-type of
`‘audio/mp3’ the system should seed the application context’s namespace* with the value “Target-
`Device=’speaker’”. It would then be up to the system to determine how to satisfy the application-specific
`goal of rendering MPEG audio to a speaker. This style of rule is referred to as a goal rule, because it does
`not specify an “edge step” to pass data to a particular bead.
`
`
`* The application context’s namespace will be further discussed in section 3.3.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 4 of 10
`
`
`Page 4 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`<RULE>
` <PREDICATE value="query:Content-Type==’audio/mp3’" />
` <ROUTE>
` <STEP>
` <SEED value="namespace:Target-Device=’speaker’" />
` </STEP>
` </ROUTE>
`</RULE>
`
`
`
`Figure 2. Example rule that plays MP3 audio to a speaker device.
`Achieving the rule’s goal specified in Figure 2 assumes that the Strings engine is configured with
`additional rules and bead schemas. Let’s assume this configuration information comes from the
`previously described MPEG decoder bead schema shown in Figure 1 (section 3.1) as well as the rule and
`bead schemas shown in Figure 3, which defines how to render audio data to a speaker device. The rule in
`Figure 3 declares that the speaker bead’s “Encode” edge should be used when the target device is set to
`speaker, while the bead schema defines that the speaker bead can only accept input of content-type
`‘audio/pcm’.
`
`<RULE>
` <PREDICATE value="query:Target-Device==’speaker’" />
` <ROUTE>
` <STEP>
` <BEAD name="Speaker" />
` <EDGE name="Encode" />
` </STEP>
` </ROUTE>
`</RULE>
`
`<BEAD_SCHEMA name="Speaker">
` <DESCRIPTION>
` The Speaker bead delivers PCM audio to an audio output device.
` </DESCRIPTION>
` <EDGE name="Encode" shape="input">
` <PRECONDITION value="query:Content-Type==’audio/pcm’"/>
` </EDGE>
`</BEAD_SCHEMA>
`
`
`
`Figure 3. Example rule and bead schemas to render audio data to a speaker device.
`When a message is injected into the system containing MPEG audio data and the content-type is set to
`audio/mp3 in the application context’s namespace, then the Strings engine would evaluate the above
`mentioned rules, create a pipeline consisting of the MPEG decoder and the speaker bead, and route the
`message along the appropriate edges of these beads. The outcome is the desired effect of rendering
`MPEG audio to the speaker device.
`
`The flexibility of using a declarative style configuration system was only partially shown in the above
`example. A similar “program” could have been constructed straightforwardly using a traditional
`application design approach that imperatively defines how to decode MPEG audio into a format that can
`be rendered to a speaker. However, such an application and its components can only be used in the
`parochial scope for which it was developed. It would be difficult to reconfigure this “program” in
`unanticipated ways without a fair amount of re-engineering. For example, consider the amount of re-
`engineering required if the audio data should be processed by a speech-recognition component, and that
`its output is then sent to either a word processor or an email client. With Strings this is a straightforward
`process of modifying or replacing the declarative rules, which can be done either at build-time or more
`importantly at runtime in response to a changing user preference or catalyzed by system events. The
`flexibility of Strings will be further explored later in section 4.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 5 of 10
`
`
`Page 5 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`3.3 Strings Engine
`The Strings Engine consists of two components: a constraint solver and a resource manager. These
`components work hand in hand. The constraint solver is used to determine where a message should be
`routed to for processing given the declarative rules and beads described in the previous two sections. The
`resource manager defines an application context encoded as a namespace of variables using a data
`structure called a Path.
`
`This path state enables the constraint solver to evaluate the declarative rules to determine what steps to
`take, and in turn as it identifies the steps it further registers seed values, beads, or loop back information
`with the resource manager. It is in this manner how the engine “strings” together beads without having to
`encode those decisions in the beads themselves.
`
`Once a completed path exists then subsequent messages meeting the same conditions can be routed onto
`the same path without rebuilding it from scratch. This separation of path building from message
`processing is a key characteristic of the Strings Engine, which enables it to provide global resource
`management policies which would otherwise be unenforceable. Finally, since beads separate interfaces
`and implementation, the resource manager can reuse beads in multiple contexts without requiring
`additional application code. The result is a flexible framework with an unprecedented degree of software
`reuse that yields efficient solutions at runtime.
`
`4 Examples
`
`To gain a better understanding of Strings we are going to look at one example: a media player. The
`media player allows a user to view either motion video or still images, and listen to audio. Figure 4
`illustrates the basic components that one expects such a player to contain, which includes modules that
`interact with the user, retrieve the media from some source, process the various media types, and render
`the media to a screen and speaker device.
`
`UI
`
`Media
`Source
`
`Graphics
`System
`
`Sound
`
`Media
`Parser
`
`Video
`Decoder
`
`Audio
`Decoder
`
`
`
`Figure 4. Media Player Components
`Note that the components shown only define application logic and not how they are configured into a
`fully functioning media player application. The fundamental services that each module provides are as
`follows:
`• User Interface (UI): react to user events
`• Media Source: reading media from a media source (e.g., a disk)
`• Media Parser: demultiplex a merged media stream, such as MPEG2, into its constituent audio and
`video streams
`• Video Decoder: transform an encoded video stream into a format suitable for rendering by the
`graphics system.
`• Audio Decoder: transform an encoded audio stream into a format suitable for rendering by the
`sound system.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 6 of 10
`
`
`Page 6 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`• Graphics System: render screen data to the underlying screen device.
`• Sound: render audio data to the underlying speaker device.
`The rest of this section contrasts conventional application design with one that benefits from using the
`Strings framework for three variants of the media player.
`
`4.1 Single Application
`Figure 5 illustrates the conventional versus the Strings approach of constructing such an application. The
`conventional application development approach (shown on the left in the figure) might be to develop a
`central program that invokes each service matching the flow of data (illustrated as the green, purple and
`yellow arrows) across the various modules. This organization is often referred to as the “main loop” used
`by imperative application designs within which the configuration intelligence of how the components are
`used is statically pre-defined. To change the behavior of the application requires that this configuration
`intelligence be modified, which essentially requires a rewrite of the program defining the application.
`This is a time consuming and difficult task that does not scale, and more importantly is not possible at
`runtime in response to user preferences or system events.
`
`UI
`
`Media
`Source
`
`Graphics
`System
`
`App
`
`Sound
`
`UI
`
`Media
`Source
`
`Graphics
`System
`
`Sound
`
`Media
`Parser
`
`Video
`Decoder
`
`Audio
`Decoder
`
`Media
`Parser
`
`Video
`Decoder
`
`Audio
`Decoder
`
`
`Figure 5. Conventional application structure (left) contrasted with Strings structure (right).
`The corresponding application in Strings consists of beads that define “service rules” for each underlying
`module, and a set of “goal rules” that collectively define the media player task. The beads are depicted as
`grey circles containing directional triangles. Note that there is no concept of a central program that is
`responsible for both control flow and dataflow of the application. Rather, the configuration intelligence
`manifests itself in these rules and the so-called “main loop” is built into the Strings engine that evaluates
`these rules. The engine dynamically “strings” together the modules via the beads at runtime into a graph.
`In other words, the control flow and dataflow graph of the application is defined by the rules at runtime.
`
`
`
`Strings’ dataflow centric framework combined with declarative rules enables a high degree of flexibility
`to the media player application. For example, it is straightforward to dynamically add a new media
`decoder/parser into the Strings-based media player application, as this simply requires the loading of a
`new bead representing this functionality with the appropriate rules. Further, the ability to do this at
`runtime is built into the Strings framework, freeing the application developer from explicitly having to
`support this feature themselves.
`
`4.2 Client/Server Media Player
`To illustrate Strings’ flexibility and generality we shall consider breaking the media player application
`into its constituent client and server components, and then distribute it across two networked machines.
`Remember that in Strings each piece of application logic is exposed by a bead as a service, and as such
`can be communicated with from the same network node or from across the network. As a result, to build
`a client/server version of the media player simply requires placing the appropriate beads and rules on the
`client and server nodes, and adding communication beads that allow them to communicate with each
`other.
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 7 of 10
`
`
`Page 7 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`This is depicted in Figure 6 where the media source component is placed on a server node while the other
`components remain in the client node. There also is the addition of networking components that provide
`the services of messaging over a communications network (i.e., a LAN or a WAN); however, these are
`integrated seamlessly without needing to modify any of the other bead logic. The overall system
`configuration of how the beads are composed for this client/server media player is governed by the rules
`on each respective system.
`
`Media
`Source
`
`UDP
`
`IP
`
`UI
`
`Media
`Parser
`
`UDP
`
`IP
`
`Graphics
`System
`
`Sound
`
`Video
`Decoder
`
`Audio
`Decoder
`
`
`
`Figure 6. Strings-based client/server media application.
`This example illustrates the limitations of the traditional approach. Constructing the same client/server
`media player will likely require a separate server application in addition to interface modules that allow
`the client application to communicate with the server application. The imperatively defined configuration
`information that is embodied in the application requires code changes in order to become a distributed
`application. Further, a new application embodied in a process needs to be designed and implemented
`only to provide a “service” on the server side. And finally, because the stream of data is subordinate to the
`process-centric notion of the application, it needs to be explicitly encoded by the client/server interface
`modules. This is illustrated in Figure 7 with App2 being the server application.
`
`Media
`Source
`
`App2
`
`Graphics
`System
`
`App1
`
`Sound
`
`UI
`
`Client
`Interface
`
`Media
`Source
`
`Server
`Interface
`
`Media
`Parser
`
`Video
`Decoder
`
`Audio
`Decoder
`
`
`
`Figure 7. Conventional client/server application requiring explicit control applications.
`
`4.3 Distributed Media Player
`The distributed media player is an extension of the client/server media player, with the minor difference
`that the client portion of the application spans multiple machines. Specifically, let’s assume the video is
`rendered on one machine (e.g., set-top box) and the audio is rendered on another machine (e.g., a digital
`audio receiver attached to the home theatre). The traditional vs. Strings-based applications are shown in
`Figure 8 and Figure 9 (on the next page), respectively.
`For the traditional application design approach the transition from client/server to a distributed media
`player requires a modification to the server application (App2), as the audio and video streams are split on
`the server side before sending them back to the client machines. Further, the new client machine requires
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 8 of 10
`
`
`Page 8 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`its own application program (depicted as App3 in Figure 8). Finally, to ensure a pleasant multimedia
`experience requires that the audio and video playback on the two client machines be synchronized. To
`support this requires a new synchronization module that is present on both of the client machines, as well
`as support for these modules to communicate with each other. This type of synchronization across
`network devices is very difficult when using a traditional application design approach.
`
`This seemingly simple extension to the client/server media player is made difficult due to the limitations
`of traditional application design approaches. In contrast, the Strings framework only requires the addition
`of the clock synchronization modules encapsulated within a bead, which is then placed as late as possible
`in the data flow of video and audio on each client in order to achieve the best possible synchronization.
`The remaining redefinition of the client/server media player is purely done in the context of the rules,
`which requires no additional application programming.
`
`Media
`Source
`
`App2
`
`Graphics
`System
`
`App1
`
`Sound
`
`UI
`
`Client
`Interface
`
`Media
`Source
`
`Media
`Parser
`
`Server
`Interface
`
`Media
`Parser
`
`Clock
`Sync.
`
`Video
`Decoder
`
`Audio
`Decoder
`
`App3
`
`Clock
`Sync.
`
`Sound
`
`
`Figure 8. Conventional distributed media player application, requiring a control program for each
`distributed system.
`
`Server 2
`Interface
`
`Audio
`Decoder
`
`Graphics
`System
`
`Media
`Source
`
`Media
`Parser
`
`RTP
`
`UDP
`
`IP
`
`UI
`
`Clock
`Sync.
`
`Video
`Decoder
`
`RTP
`
`UDP
`
`IP
`
`Sound
`
`Clock
`Sync.
`
`Audio
`Decoder
`
`RTP
`
`UDP
`
`IP
`
`Figure 9. Strings-based distributed media player application.
`
`4.4 Summary
`The degree of re-engineering described in the previous sections is inherent to traditional application
`design approaches, which is a major contributor to limiting the return on investment. In particular,
`adapting existing applications to new feature sets tends to require investments in application components
`
`
`
`Copyright © 2001 BeComm Corporation. All Rights Reserved.
`
`Page 9 of 10
`
`
`Page 9 of 10
`
`Implicit Exhibit 2021
`Sonos v. Implicit, IPR2018-0766, -0767
`
`

`

`
`
`that cannot easily be reused. Using Strings to dynamically compose applications from reusable
`components avoids the application logic re-engineering.
`
`5 Conclusion
`
`The Strings methodology enables an unprecedented degree of reuse that can be applied to fine-grain
`software components and coarse-grain legacy applications, and thereby improving both time to market
`and ROI. The Strings framework is intended for a wide range of uses, running a variety of software
`applications at all levels of sophistication. Strings is available as part of a toolkit with the following
`attributes that make it a compelling development framework for a variety of solutions:
`• Open hardware and software interfaces between major subsystems, for easy integration and expansion
`by third parties.
`• Extensibility for future uses not originally defined through the interchange and addition of its building
`blocks (Beads), creating a range of possible functionalities.
`• High degree of reusability, allowing each component to be independently unit tested and reused
`across many different systems.
`• Support for downloaded components that are installed via wireless or wireline by the user or system
`operator, allowing for incremental updates and enhancements.
`• Support for the integration of third-party vendor legacy software.
`• Operating system independence proven to run consistently across all major desktop and embedded
`operating systems (Windows 95/98/2000/XP/PocketPC/CE, Linux, *BSD, and VxWorks).
`• Architectural relevancy that spans market segments from small gadgets, Internet attached appliances,
`to back-end systems connected by all major networking technologies.
`The Strings framework is available as part of a toolkit that effectively enables complex communications
`applications across a broad range of device types, networks and computing systems. Strings enables
`OEMs and ISVs to build applications from reusable components, with the resulting sol