UNITED STATES PATENT AND TRADEMARK OFFICE
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SONOS, INC.
`Petitioner
`
`v.
`
`IMPLICIT, LLC
`Patent Owner
`
`IPR2018-00767 (Patent 8,942,252 B2)
`
`PATENT OWNER’S MOTION TO SUBMIT SUPPLEMENTAL
`INFORMATION UNDER 37 C.F.R. § 42.123(B)
`
`

`

`I.
`
`INTRODUCTION
`
`Implicit respectfully requests that the Board supplement the record with an
`
`October, 2001 email exchange between Dr. Larry Peterson, a Princeton Computer
`
`Science professor, and Marc Fiuczynski, a BeComm engineer. Attachment A.1
`
`A central issue in these proceedings is if Implicit can swear behind Janevski,
`
`Petitioner’s only primary invalidity reference. Janevski has a December 11, 2001
`
`filing date. The Peterson Email supports Implicit’s claim that it actually reduced the
`
`inventions to practice by October, 2001. The Patents relate to synchronizing content
`
`across multiple devices, and Mr. Fiuczynski explains in the Peterson Email that
`
`Implicit (then known as BeComm) reduced the invention to practice by October 4,
`
`2001 and was considering filing patent application on the new system at that time:
`
`We can synchronize video playing on one computer very accurately
`while the audio plays back on another. We can also synchronize audio
`across two computers to the point that you can plug a headphone into
`each separate computer, and listen to it in stereo. It sounds really good.
`. . .
`
`You had mentioned that this type of synchronization was rather difficult
`to achieve. Do you know of prior art that attempts to address this
`particular problem . . . ? We are thinking of writing up a provisional
`patent application on our system. . . .
`
`The Peterson Email is thus direct evidence of actual reduction to practice. It
`
`
`
`also corroborates the inventor testimony, documents, and source code evidence (and
`
`
`1 For completeness, Implicit has attached the Peterson Email and the attachment
`(“wp.pdf”) as a single document.
`
` 1
`
`

`

`expert analysis) in Implicit’s Patent Owner’s Response that shows that Implicit can
`
`swear behind Janevski. The Email also directly responds to Petitioner’s position that
`
`Implicit’s evidence is not adequately corroborated and that Implicit’s source code
`
`did not actually synchronize content playback. There is no question that the Email
`
`highly relevant to this case.
`
`Additionally, not only was Implicit unaware of the Email, the Email was not
`
`in Implicit’s possession, custody, or control. The Email only recently came to light
`
`through a third-party subpoena in an unrelated litigation. Because Implicit could not
`
`have reasonable obtained the Email earlier and the interests of justice favor
`
`considering the Email, Implicit respectfully requests to supplement the record.
`
`II. BACKGROUND
`
`The Board instituted proceedings on two Implicit Patents, U.S. Patent Nos.
`
`7,391,791 and 8,942,252, based on the Janevski reference (U.S. Patent No.
`
`7,269,338), either alone or in combination with other secondary references. The
`
`Patents claim priority to a December 17, 2001 application, and Janevski has a
`
`priority date of December 11, 2001—six days earlier.
`
`Implicit asserts that it can swear behind Janevksi. Implicit (then known as
`
`BeComm) developed the patented technology in connection with its networking
`
`operating system product, known as Strings. Implicit submitted inventor testimony,
`
`expert testimony, source code, and documentary evidence from the 2001 time period
`
` 2
`
`

`

`to support its position. Petitioner asserts that the evidence does not adequately
`
`corroborate testimony from the lead inventor (Mr. Balassanian) that the invention
`
`was reduced to practice prior to Javenski’s December 11, 2001 filing date.
`
`On February 27, 2019, Dr. Larry Peterson (a Professor in Computer Science
`
`at Princeton) produced an email in response to a subpoena in an unrelated case (the
`
`Implicit v. NetScout case). Exhibit 2090. The email is dated October 4, 2001.
`
`In the email, Marc. Fiuczynski (a BeComm engineer at the time) explained to
`
`Dr. Peterson that BeComm was able to “leverage Strings in a novel way” to
`
`“synchronize media across networked machines,” and that the company was
`
`considering filing a patent application on this new system:2
`
`We can synchronize video playing on one computer very accurately
`while the audio plays back on another. We can also synchronize audio
`across two computers to the point that you can plug a headphone into
`each separate computer, and listen to it in stereo. It sounds really good,
`and we believe that it would even work across a WAN connection as
`the synchronization protocol doesn’t require a lot of bandwidth.
`
`You had mentioned that this type of synchronization was rather difficult
`to achieve. Do you know of prior art that attempts to address this
`particular problem in either LAN or WAN settings? We are thinking
`of writing up a provisional patent application on our system, and it
`would help to understand its relationship to other systems.
`
`
`
`
`2 Guy Carpenter implemented the inventions. He is no longer with Implicit.
`
` 3
`
`

`

`Dr. Peterson served as a BeComm technical advisor until around 2002. Mr.
`
`Fuicynski left BeComm in late 2001. Neither are affiliated with Implicit or were
`
`directly involved in the development that led to the inventions. Exhibit 2091, at ¶ 5.
`
`On February 28, 2019, the day after receiving the Peterson Email, Implicit’s
`
`counsel produced the Email to Petitioner. On March 7, 2019, Implicit notified
`
`Petitioner that it sought to supplement the record with the Peterson Email and
`
`informed Petitioner of the upcoming depositions of Dr. Peterson and Mr. Fiuczynski
`
`in the Implicit v. NetScout case (set to complete by April 5, 2019).
`
`III. ARGUMENT
`
`The Board may accept supplemental information if the evidence “reasonably
`
`could not have been obtained earlier” and “consideration of the supplemental
`
`information would be in the interests-of-justice.” 37 C.F.R. § 42.123(b). Both
`
`prongs are met in this case.
`
`
`
`A.
`
`Implicit Reasonably Could Not Have Obtained The Email Earlier
`
`Implicit could not have reasonably obtained the Peterson Email earlier.
`
`Implicit (including Mr. Balassanian) did not have possession, custody, or control of
`
`the Peterson Email prior to its production on February 27, 2019.
`
`Mr. Balassanian is the records custodian for Implicit. Exhibit 2091, at ¶ 4.
`
`He searched for potentially relevant records, including email, in connection with
`
`these proceedings prior to the submission of the Patent Owner Response in
`
` 4
`
`

`

`December, 2018. Id. at ¶ 7. He also provided Implicit’s records to counsel, id., who
`
`also searched for potentially relevant records. Implicit did not find the Peterson
`
`Email. Id. at ¶ 7. After Dr. Peterson produced the Email, Implicit again searched
`
`its records again. It did not find the Peterson Email. Id. at ¶ 8.
`
`Mr. Balassanian is listed as a “CC” on the Email, sent in 2001, though he does
`
`not recall receiving it. Exhibit 2091, at ¶¶ 5, 9. Around that time, BeComm migrated
`
`email systems that likely resulted in deletion of the Peterson Email. Id. at ¶ 9.
`
`As Mr. Balassanian testified in 2012 in a different case, BeComm often
`
`migrated its email server during the early days of the company, which caused emails
`
`to become lost. Exhibit 2092, at 196:4–203:2. At each upgrade, emails could be
`
`lost unless an employee saved them. Id. at 200:7–200:20. During those migrations,
`
`which required individuals to personally archive or save their emails, Mr.
`
`Balassanian did not backup or save his emails before the migration. Id. at 201:3–
`
`202:2. Mr. Balassanian also had a practice of deleting emails throughout the day,
`
`with the goal of having an empty inbox at the end of the day. Id. at 201:3–202:2.
`
`Sometime after 2001, BeComm again switched email servers. Exhibit 2091,
`
`at ¶ 9. Like the prior migrations, emails did not automatically transition to the new
`
`server and were lost unless an employee saved or archived them prior to the switch.
`
`Id. Mr. Balassanian does not recall saving his emails, archiving his emails, or
`
`otherwise transitioning his emails to the new server. Id. While Implicit did locate
`
` 5
`
`

`

`some emails relating to this case from the 2001 time period, e.g., Exhibits 2012,
`
`2038, those emails were likely specifically saved at the relevant time. Id.
`
`Implict thus did not have the Peterson Email in its possession during these
`
`proceedings prior to February 27, 2019. Exhibit 2091, at ¶ 6. Nor was Implicit
`
`aware that Dr. Peterson or Mr. Fiucynski might have potentially relevant information
`
`from over 17 years ago. They were not directly involved in relevant projects
`
`developing the audio-video synchronization functionality. Id. at ¶ 5; Exhibit 2009,
`
`at 5 (listing Balassanian, Bradley, Carpenter, and Greene as team members).
`
`Implicit could not reasonably have obtained the Peterson Email earlier than it did.
`
`Implicit also acted diligently after learning of the Peterson Email. Two
`
`networking companies, NetScout and Sandvine, subpoenaed Dr. Peterson in
`
`litigation that involves another family of Implicit patents. They issued the subpoena
`
`as part of their prior art defenses, and sought any communications Dr. Peterson may
`
`have had with BeComm from 1996 to 2003. Exhibit 2090 Dr. Peterson produced
`
`the Email in response to that subpoena on February 27, 2019. Within a day of
`
`receiving the email from Dr. Peterson, Implicit produced the Email to Petitioner.
`
`B.
`The Interests of Justice Weigh in Favor of Considering the Email
`The interests of justice also weigh in favor of considering the Peterson Email.
`
`As recounted above, the Email provides direct evidence of actual reduction to
`
`practice in October, 2001—ahead of Janevski: “We can synchronize video playing
`
` 6
`
`

`

`on one computer very accurately while the audio plays back on another. . . . We can
`
`also synchronize audio across two computers to the point that you can plug a
`
`headphone into each separate computer, and listen to it in stereo. . . .” The Email
`
`also corroborates the evidence in Implicit’s Patent Owner Response that shows
`
`actual reduction to practice by October, 2001. E.g., Exhibit 2001, at ¶¶ 35–61
`
`(testimony relating to October, 2001 source code and demonstrations); Exhibit 2021
`
`(October, 2001-dated whitepaper substantially similar to the Peterson Email
`whitepaper attachment); Exhibit 2056, 1–2 (October 11, 2001 audio.rule source
`
`code file that plays “master audio” on one output and “synchronized PCM” on
`another output); Exhibit 2023, at 1 (October 29, 2001 source.pl source code file
`
`that lists “fightclubrgb.avi” as an audio-video source file); Exhibit 2077, at 21–22
`
`(“fightclubrgb.avi” file created on September 7, 2001). A fact-finder assessing
`
`priority would certainly want to consider the Peterson Email alone and in the context
`
`of assessing whether to credit Implicit’s other evidence, which is consistent with the
`
`Peterson Email. See Ultratec, Inc. v. CaptionCall, LLC, 872 F.3d 1267, 1273 (Fed.
`
`Cir. 2017) (discussing importance of inconsistent testimony).
`
`The relevance of the Peterson Email is beyond dispute. Petitioner instead
`
`focuses on two procedural arguments: (1) that the Email will entail further discovery
`
`at a time too late in these proceedings and (2) that the Email is not admissible. Paper
`
`No. 25. Neither argument is a reason to deny this Motion.
`
` 7
`
`

`

`Considering the Peterson Email will not impermissibly open up discovery.
`
`Petitioner is free to depose Mr. Balassanian and address any testimony in its response
`
`to this Motion. Implicit also notified Petitioner in advance of Dr. Peterson’s March
`
`11, 2019 deposition, but Petitioner did not attend the deposition. Petitioner will have
`
`the opportunity to ask Mr. Fuiczynski questions at his deposition on April 5, 2019 if
`
`it so chooses. Petitioner has not, to date, indicated whether it will attend Mr.
`
`Fuiczynski’s deposition. No other discovery is necessary regarding the Email.
`
`The Peterson Email is also admissible. Dr. Peterson authenticated the Email
`
`as a business record from his Princeton email archive (both stipulated on the record
`
`and in his testimony). Exhibit 2093, at 9:3–17, 196:3–197:3. Mr. Fuiczynski will
`
`also be asked to lay foundation to admit the Peterson Email. Regardless, evidentiary
`
`objections are not a basis to preclude submitting supplemental information.
`
`Petitioner is free to lodge an objection to the Peterson Email and then preserve that
`
`objection through a motion to exclude as in the normal course.
`
`IV. CONCLUSION
`
`For these reasons, Implicit respectfully requests that the Board grant this
`
`Motion to Submit Supplemental Information.
`
`
`
`
`
` 8
`
`

`

`Dated: April 4, 2019
`
`
`
`
`
`
`
`Respectfully submitted,
`
`THE DAVIS FIRM, P.C.
`
`By: /Christian Hurt Reg. No. 63,659/
`Christian Hurt
`
`THE DAVIS FIRM, PC
`213 N. Fredonia Street, Suite 230
`Longview, Texas 75601
`903-230-9090
`churt@bdavisfirm.com
`
`
`
`
`
`
`
`
`
`
` 9
`
`

`

`ATTACHMENT A
`
`ATTACHMENT A
`
`

`

`PETERSON000048
`
`Marc Fiuczynski <marcf@becomm.com>
`From :
`"'Larry Peterson"' <llp@CS.Princeton.ED U>
`To :
`Edward Balassanian <EdwardB@becomm.com>
`Cc :
`RE: strings whitepaper
`Subje ct:
`Thu , 4 Oct 2001 13:57:23 -0700
`Sent:
`~
`
`Larry ,
`
`I am looking forward to your comments. The first paragraph of the paper
`changed to something new. I've attached the latest draft of the whitepaper
`to this document.
`
`Your student Rob has gotten in touch with me about a month ago and this past
`Tuesday.
`It seems that he started to go through the examples we have put
`together , and was running into some setup problems on Windows. Rob
`mentioned that he did not have an application in mind at this point in time.
`
`On another note , Guy Carpenter came up with a scheme to synchronize media
`across networked machines. The design leverages Strings in a novel way. We
`can synchronize video playing on one computer very accurately while the
`audio plays back on another. We can also synchronize audio across two
`compu ters to the point that you can plug a headphone into each separate
`computer , and listen to it in stereo.
`It sounds really good , and we believe
`that it would even work across a WAN connection as the synchronization
`protocol doesn't require a lot of bandwidth.
`
`You had mentioned that this type of synchronization was rather difficul t to
`achieve. Do you know of prior art that attemp ts to address this particular
`problem in either LAN or WAN settings? We are thinking of writing up a
`provisional patent application on our system , and it would help to
`understand its relationship to other systems.
`
`Marc
`
`----Original Message----
`From: LarryPeterson[mailto:llp@CS.Princeton.EDU)
`Sent: Thursday , October 04 , 2001 1 :39 PM
`To: Marc Fiuczynski
`Subject: Re: strings whitepaper
`
`I'll take a look and get back to you with comments. BTW , has the
`student , Rob Katcher , gotten ahold of you. (I'm sorry to say I
`haven't seen/heard from him in a while. )
`
`Larry
`
`PETERS ON 000048
`
`

`

`PETERSON000049
`
`Using Strings to Compose Applications from Reusable Components
`BeComm Corporation
`info@becomm.com
`Octobe r 4, 200 I
`
`The past decade in technology has evidence d an exp losive growth in the proliferation of new web and
`network serv ices, di gita l data and content, new and increas in gly diverse comput ing devices and new
`w ired and w ireless networks
`for data comm uni cat ion. With the billions
`investments
`in hardware
`infra structure, software infra structu re and network infra structure, not only do end users wa nt to see new
`applications, but ISVs and OEM s must deliver these applications
`in a way that assuages managements
`deman ds for an eve r-in creas ing retur n on investment. As a result, this changin g land scape has impose d a
`cr itica l chall enge on software deve lope rs and IT managers
`to improve
`time to market and reduce
`deve lo pment costs . To leve rag e this existing investme nt in hardware, network and softwa re infrastructure,
`applications mu st be deve loped to cap italize on new revenue opportunities while also reducing existin g
`operating expenses. Th e key observation made by many is that reuse of techno lo gy assets to compose
`new applications
`is cr itica l to addressing these chall enges .
`
`that make reuse difficult to ach ieve. Fir st, reuse is an eas ily
`There are, however, severa l issues
`misunderstood concept, as it is not simpl y using previously engin eered or acquired techno lo gy asset mor e
`It requir es reuse enginee ring that prepares
`than once.
`techno lo gy assets
`to be reusable. Second,
`ident ifying what software components can be reused
`is a confus in g process, as tradi tional design
`approaches
`tend to prevent reuse outside
`the narrow scope or domain in wh ich they were initiall y
`deve lop ed. Finally softwa re eng ineer ing techniques and methodologies alone are insuffic ient too ls for
`deve lopers to achieve true reuse. Even with the best deve lopment methodologies and architectural
`techn iqu es, tak ing a tradition al approach to deve lopm ent ca n reduce the potential for reusing tec hnolo gy
`assets or limit the type of potential reuse, withou t later additional re -engin eer ing.
`
`To address these issues requires an application framework that promotes reuse at every leve l: from fine(cid:173)
`gra ined application compo nents to large-sca le back-end systems . The lack of a solid application
`framework for reuse has prevente d it from being widely accepted and impl emente d. Such a framework
`needs to yield so lution s that are dynamic enough to adapt reusa ble compon ents to chang ing networks,
`media types, and device types at runtim e in unan ticipate d ways; distributed so as to leverage se rvices
`w ithin the WAN and LAN; and efficient enough to run on network servers and resource -constra in ed
`embe dded devices alike. While
`traditional
`techniqu es (e.g., object-o riented des ign and co mponent
`systems w ith the appropriate exte nsions to support client/serve r syste ms) and methodologies (e.g., UM L
`that aids in the spec ification and design of systems) have various strengths they have two inherent
`limitation s that pr event the deve loper from creat ing solution s that are truly reusa ble. These limi tation s are
`as follows:
`
`Limitation l: Imperatively Defined Configuration Intelligence
`In traditional application deve lopm ent, the softwa re deve lop er exp licitly ident ifies a set of requir ed
`services and spec ifies how and when to in terface with them. This necess itates that deve lop ers have a
`pr iori knowledge of all se rvices that are to be used directly by the ir component. This entang lement of
`config uration intellig ence with application
`logi c transcends from the so-ca lled "main loop" of the
`application
`down
`to gran ular components
`compos ing
`the application. While
`conve ntional
`00/component
`techn iqu es ena bl e the deve loper to be oblivious of an algorithm's
`impl ementation
`details, they are still requir ed to know the interfaces, and to write code that depe nds on those
`interfaces to meet the goa ls of the application. Consequently,
`it is difficu lt to cha in together services
`to achieve a desired goa l without expli citly spec ifying all possible config uration s in advance.
`Th erefore, in pra ctice, imp erat ively defin ing the config ura tion intelli gence limi ts the application to a
`static set of pre defined interactions.
`
`Copyrig ht © 2001 BeComm Corp ora tion. All Rights Reserved.
`
`Page I of 10
`
`PETERSON000049
`
`

`

`Limitation 2: Process-centric Computing
`The traditional notion of an "app licat ion" impli es a process-centric viewpo int, in wh ich each
`application is embod ied by a computat ional process on a node in the network. From the end-user's
`perspective,
`the application
`is usually perceived
`to be the process with wh ich they are directly
`interacting (e.g. a spreads heet or a web browser), po ssibly extended to includ e the back-end services
`suppor ting that process, such as a web server and CGI program.
`In the case of distributed systems,
`the "app licat ion" might be interpr eted as living on both the client and serve r nod e.
`
`The framework for enab ling commun icat ion is cons idered externa l to the application itself, existin g
`as a separate lay er on which the application resides. Application development foc uses on defining
`the computat ional process, encod ing the re lation ships between objects, and invoking methods from a
`known set of interfaces, but the flow of data between processes
`is cons ider ed subordinate
`to the
`processes
`themselves. This "process-centr ic" notion of an application is inherent ly limi ting to the
`developer, because it does not easily accommodate
`the potent ial for an application to participate as a
`service operating on a stream of data flowing through a dynam ic configuration of other services.
`
`Today's emphasis on return on investme nt requires the reuse of legacy tec hnology assets as we ll as newly
`designed algorithms, and therefore evidences
`the need
`to overcome
`traditiona l application design
`limitations such that application
`logic can be reused in a more flexible, efficient, and cost sens itive
`manner.
`
`Strings™ defines an application
`framewo rk that supports build-time and more impor tantly runtime
`adaptability of reusable software components.
`The methodology used to develop Strings-based
`applications facilitates the creation of software components as services w ith an unpr ecedente d degree of
`reusability, thereby enablin g software developers to quickly create smarter and less expens ive solution s.
`
`2
`
`Strings Methodology
`
`To achieve an unpr ecedent ed degree of reuse, the String s methodology is to (i) turn application logi c into
`services (ii) to augment the process-centric paradigm with a dataflow- centr ic paradigm,
`in which the
`defin ing principle of the application are goal rules that contro l the flow of data itself over these serv ices.
`The data can then pass through an ad hoc defined sequence of reusable application serv ices. The fact that
`these serv ice s may be embod ied in processes is seco ndary to the primary notion of a stream of data.
`
`into rules and primitive serv ices,
`logic
`intelligence from application
`By separating config uration
`respect ively, it is possible to declarati vely define how and w hen the service can be used . Thi s separation
`results in a form of commun ication indir ectio n, in which no serv ice refers to the interface of any other
`service, and no two objects talk directly to each other.
`Instead, an "intelligent engin e" facilitates the
`creatio n of communication paths between objects automatically by reaso ning about the goa ls of the
`application.
`
`ln th is way it is possible to hook services to gether at run-time as they are discovered. As a r esult, the
`traditional tight coupling of objects and the so-call ed "main loop" of the application ceases to exist , being
`replaced by a set of rules and a "higher-order control"
`that coordina tes the flow of comm unicat ion
`betwee n services. With such an approach, applications no longer ex ist as static "programs", but rather as
`dynamic invocat ions of services that can be automatically config ur ed in unanticipated ways, adapting to
`meet the goals of the system on the fly.
`
`The resu lting invers ion of control greatly improv es the task of building applications, as the programmer is
`freed from the task of spec ifying configuration
`infomrnt ion imp erative ly. Routing decisions and state
`management are remove d from the application, and handled by the system.
`ln this model, objects can talk
`to each other w ithout a priori know ledge of each other's existence.
`
`Copyright © 200 I BeComm Corporation. A II Rights Reserved.
`
`Page 2 of 10
`
`PETERSON000050
`
`

`

`3
`
`Strings Framework
`
`The Strings framework cons ists of the following compo nents:
`
`1. A dynamic set of discrete services, called Beads TM, which encapsu late application logi c.
`2. A set of dec larative rules spec ifyin g when beads are used to achieve some application-specific
`goal, which can either be specified by the user, system's integrator, or cata lyzed by system eve nts
`at runtime.
`3. An "engine" that matches the application-specific goals w ith the declara tive rules of the beads,
`and thereby dec ides what services to emp loy to meet the goals.
`
`3.1 Beads
`Beads encap sulat e reso urces as discrete serv ices that adhere to a highly structured in terface. Th e bead
`itself is a softwa re component that exports a granular unit of functionality. Examples of resources that a
`bead can encapsu late includ e:
`
`•
`•
`•
`•
`
`hard wa re such as a video disp lay, speake r, microphone, mouse, Ethernet, etc.
`protocols such as TCP /IP, HTTP, SOAP, ema il (POP3, SMTP), etc.
`transformational algor ithms such as audio /video decod ers, etc.
`SOK technologies such as speech-recognition engines (e .g., IBM's Via Voice), text-to-speech
`generators, etc.
`• Backend services such as Databa se, CRM, and Content Management Sys tems .
`In other words, any resource that can be define d as a serv ice can be encaps ulated within a bead. Th ere is
`no dir ect reliance on a particular programming
`languag e (su ch a Java) required to use the framewo rk.
`The purpose of the bead is to comp lete ly hide both the interface and the impl eme ntation of the r esources
`they encapsulat e, and thereby cleanly separat e the interna l algorithm from its externa l relations hip to
`other such algorithms. The me thodology of encapsu lating functionality into discr ete element s encourag es
`a software parti tioning that exhibits no redundan cy or depe nden cies on other beads. This result s in code
`that is highly reusab le, and enables serv ices to be assembled into dynami c applications by an automated
`eng ine.
`
`Beads are the buildin g block for the pipeline of proc ess ing elements applied to a data flow. Bead s
`confo rm to a strongly-typed inter face 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, unid irect ional to complex, bi-directional
`flo ws of data. Bi-directional
`flows are automatically
`managed by the Strings engine, such that a b ead may send data in the opposite dir ection of the flow
`without needing to know from where the flow originated.
`
`A bead is descr ibed to the Strings eng ine in an XML-ba sed Be ad Schema that declar es the number and
`directio n of its edges and the conditions indicating w hen its input edges can be used and what type of data
`comes out of its output edges. A Bead Schema can be authored direct ly in XML or with the Bead Schema
`Editor, which is a developm ent tool included with the Strings toolkit.
`
`Figure 1 shows an example bead schema that defines the operation of an MPEG audio deco der. The
`schema
`identi fies the bead's nam e, description, and one or more edges. Each edge is a sep arat ely
`nameable entity, and in this exa mpl e the MPEG decoder bead has a single "filter" edge, which logically is
`both an input and output edge. The precond ition of the edge predicates that it shou ld only be used if the
`content -type variabl e of the data is set to the MlME -like str ing of 'audio / mp3'. Similarly, the post
`condition overrides
`the content-type variable to the MIME-like str ing of 'audio /pcm'
`to indicat e the
`edge's output type.
`
`Copyright © 200 I BeCo mm Corporation. A II Right s Rese rved.
`
`Page 3 of 10
`
`PETERSON000051
`
`

`

`" >
`
`bead
`
`decodes mp3 data
`
`<BEAD_SCHEMA name= "mp3decoder
`<DESCRI PTION>
`The Mp3Decoder
`</D ESCRIPT I ON>
`" >
`<EDGE name = " Decode " shape= " f i lter
`'" />
`-T ype= = ' audio/mp3
`<PRECONDI TI ON value= " que r y : Content
`<POSTCONDITI ON value = " nam espace
`: Content
`- Typ e = ' aud i o/pcm '" />
`</ EDGE>
`</B EAD_SCHEMA>
`
`to PCM audio
`
`.
`
`Figure l. Bead Schema for an MPEG Layer-3 decoder.
`
`Each edge is implemented as a set of handlers: the messa ge 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 Ru les
`Rule s 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
`type s. 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 constraint s.
`
`If all of a rule's constraints are met , then Strings wil I execute the specified steps. The collection of steps
`associated with a rule is referred to as a rout e along which data wi II flow. There are three types of steps
`that the Strings engine can take: l) a bead step which passes data to a particular bead ; 2) a se ed step
`which populates the "namespace of an application context "• with a value that may satisfy some condition
`of another rule ; and, 3) a loopba ck step which specifies that should be sent in the opposit e direction of the
`original data flow .
`
`format that declares a predicate and an
`to the String s engine in an XML-based
`A rule is described
`associated route of steps . The rules can be authored directly in XML or with a graphical Rule Editor.
`
`<RULE>
`< PREDI CATE value= " query
`<ROUTE>
`<S TEP>
`<S EED value = " namespace
`</S TEP >
`</ROU TE>
`</RUL E>
`
`: Conte nt - Ty p e== ' audio/mp3
`
`'"
`
`/>
`
`: Targe t - Dev i ce = ' speaker
`
`'"
`
`/>
`
`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'
`system
`should seed
`the application
`cont ext's namespace • with
`the value
`'Target -
`
`' The application conte xt ' s namespace will be further discussed in section 3.3.
`
`Copyright
`
`2001 BeComm Corpo ration . All Right s Res erved .
`
`Page 4 of 10
`
`PETERSON000052
`
`

`

`It wou ld then be up to the system to determine how to sat isfy the application-specific
`Device='speaker"'.
`goa l of rend ering MPEG audio to a speaker. Thi s sty le ofrule
`is refer red to as a goa l rule, because it does
`not spec i fy an "edge step" to pass data to a particular bead.
`
`<RULE>
`< PREDI CATE v a l ue = " que r y : Con t e n t -T ype == 'au d i o/ mp3 '"
`<ROUTE>
`<STEP >
`<S EED v a lue = " n ame sp a ce : Tar ge t - Devi ce = ' s p ea ke r'"
`</S TEP >
`</ROU TE>
`</ RULE>
`
`/>
`
`/>
`
`Figure 2. Example rul e that pla ys MP3 audio to a speaker device.
`
`that the Strings engine is configure d with
`To ach ieve the rule's goal spec ified in Figure 2 assumes
`additional
`rules and bead schemas. Let's assume
`this configurat ion in format ion comes
`from the
`previously descr ibed MPEG decoder bead schema shown in Figure I (section 3. I) as we ll as the rul e and
`bea d schemas shown in Figure 3, which defines how to render audio data to a speake r device. The rul e in
`Figure 3 dec lares that the speake r bea d's "E ncode" edge should be used when the target device is set to
`speaker, wh ile the bead schema defines that the speake r bead can on ly accept inpu t of content-type
`'audio /pcm'.
`
`<RULE>
`< PREDI CATE v a lu e = " que r y : Targ e t - Devi ce == ' s p ea ke r'"
`<ROUTE>
`<STEP >
`<BEAD name = " Sp e ak e r"
`<ED