UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`DAIMLER NORTH AMERICA CORPORATION, MERCEDES-BENZ USA,
`
`LLC, AND MERCEDES-BENZ U.S. INTERNATIONAL, INC.,
`
`Petitioners
`
`
`
`
`v.
`
`
`
`Stragent, LLC,
`
`Patent Owner
`
`
`
`Case IPR2017-00457
`
`U.S. Patent 8,566,843
`
`
`
`
`DECLARATION OF JEFFREY A. MILLER
`
`
`Page 1 of 47
`
`BMW EXHIBIT 1028
`BMW v. STRAGENT
`IPR2017-01521
`
`

`

`1.
`
`I am an adult individual and make this Declaration based on personal
`
`knowledge.
`
`2.
`
`I have been retained by Stragent LLC (“Petitioner”) to provide
`
`analysis regarding U.S. Pat. No. 8,566,843 (the “’843 Patent”; Pet. Ex. 1001). I
`
`have personal knowledge of the facts set forth in this Declaration unless otherwise
`
`stated. If called as a witness, I could and would competently testify to the facts set
`
`forth in this Declaration.
`
`Qualifications
`
`3.
`
`I am an Associate Professor of Engineering Practices in the
`
`Department of Computer Science at the University of Southern California. I was
`
`awarded a Ph.D. in Computer Science from the University of Southern California in
`
`2007. I have authored numerous publications and a supplement to a book. I have
`
`given many presentations. I have assisted in developing curricula for the Computer
`
`Science and Computer Systems Engineering programs at UAA. I am a named
`
`inventor on one U.S. Patent Application. A copy of my curriculum vitae is attached
`
`hereto as Exhibit 2001.
`
`4.
`
`Currently, I am the Editor-in-Chief of the IEEE Intelligent
`
`Transportation Systems Magazine. I was previously an Associate Editor of the
`
`same magazine. I have also been an Associate Editor of IEEE Transactions on
`
`Intelligent Transportation Systems.
`
`
`
`2
`
`Page 2 of 47
`
`

`

`5.
`
`I have conducted research on the software and network architectures
`
`and algorithms used in mobile and wireless communication. Since 2008, I have
`
`secured over $930,000 for projects concerning Intelligent Transportation Systems
`
`networks and architectures.
`
`6.
`
`I was the General Chair for the IEEE 69th Vehicular Technology
`
`Conference in fall 2009, the IEEE 15th Intelligent Transportation Systems
`
`Conference in fall 2012, and the IEEE 77th Vehicular Technology Conference in
`
`fall 2013. I was also a Program Co-Chair and Technical Program Chair for the
`
`IEEE 73rd Vehicular Technology Conference in fall 2011. I was on the IEEE
`
`Intelligent Transportation Systems Society Board of Governors for the term from
`
`January 2009 - December 2011 and was elected as Vice President for
`
`Administrative Activities in the same society from January 2011 - December 2012.
`
`I was also on the IEEE Vehicular Technology Society Board of Governors for the
`
`term from September 2011- December 2013. From October 2011- December 2013,
`
`I was the Editor-in-Chief of the IEEE ITS Magazine. Within the ITSS, I was an
`
`Associate Editor for the IEEE Transactions on Intelligent Transportation Systems
`
`from 2010-2013. In 2010, I was the treasurer for the Alaska section of the IEEE
`
`and was the chair of the section from January 2011-December 2011. During my
`
`time as chair of the IEEE Alaska Section, the section won the 2011 Outstanding
`
`Section Award for the Region 6 Northwest Area. In addition to being a member of
`
`
`
`3
`
`Page 3 of 47
`
`

`

`the Intelligent Transportation Society of Alaska, I was also the president from
`
`January 2010-December 2011.
`
`7.
`
`I have reviewed the patent at issue as well as the prior art patents and
`
`printed publications discussed in this declaration and Petitioner’s Request for Inter
`
`Partes Review of that same patent. I am familiar with state of and nature of the art
`
`at the time of the invention by virtue of my review of contemporaneous materials,
`
`including but not limited to the prior art patents and printed publications addressed
`
`in this declaration. I am also familiar with the state of and nature of the art at the
`
`time of the invention based on my studies, research, publications and experience as
`
`explained in the attached CV. Ex. 2001. For example, my studies, research,
`
`publications and experience related to intelligent vehicles have included significant
`
`study of references of the time period of, before, and after the time of the invention.
`
`8.
`
`Patent Owner’s counsel has explained to me that a patent claim is
`
`invalid for obviousness under 35 U.S.C. § 103 if the differences between the subject
`
`matter sought to be patented and the prior art are such that the subject matter as a
`
`whole would have been obvious at the time the invention was made to a person
`
`having ordinary skill in the art to which said subject matter pertains.
`
`9.
`
`I have also been informed that various rationales may be used to find
`
`a patent claim obvious. For example, a combination of familiar elements according
`
`to known methods is likely to be obvious when it does no more than yield
`
`
`
`4
`
`Page 4 of 47
`
`

`

`predictable results. And when a work is available in one field, design incentives
`
`and other market forces can prompt variations of it, either in the same field or in
`
`another. Rearranging parts in a manner that does not change operation of the device
`
`is also not a patentable improvement. And still further, where a skilled artisan
`
`merely pursues known options from a finite number of identified, predictable
`
`solutions, the result was merely obvious to try. Obviousness also exists when a
`
`claimed improvement is but a predictable use of prior art elements according to
`
`their established functions.
`
`10.
`
`I have been further informed that to determine whether there was an
`
`apparent reason to combine the known elements in the way a patent claims, it is
`
`often necessary to look to interrelated teachings of multiple patents; to the effects of
`
`demands known to the design community or present in the marketplace; and to the
`
`background knowledge possessed by a person having ordinary skill in the art. In
`
`addition, I understand that a validity analysis need not seek out precise teachings
`
`directed to the specific subject matter of the challenged claim, as the inferences and
`
`creative steps that a person of ordinary skill in the art would employ can be
`
`recognized, and that the legal determination of obviousness may include recourse to
`
`logic, judgment, and common sense.
`
`11.
`
`Patent Owner’s counsel has also informed me that an obviousness
`
`analysis under 35 U.S.C. § l03(a) proceeds by setting a background against which
`
`
`
`5
`
`Page 5 of 47
`
`

`

`obviousness is measured. In this analysis, the inquiry is to: (1) determine the scope
`
`and content of the prior art, (2) ascertain the differences between the prior art and
`
`the claims at issue, and (3) resolve the level of ordinary skill in the art.
`
`12.
`
`Considering the types of problems encountered in the art, the prior art
`
`solutions to those problems and the high sophistication of the technology, a person
`
`of ordinary skill in the art of the ‘843 Patent at the time of the invention would have
`
`had at least the qualifications of or equivalent to either a master’s degree in
`
`electrical engineering, computer science, or computer engineering with course work
`
`or research in embedded networking technologies or an undergraduate degree in
`
`electrical engineering, computer science, or computer engineering with at least two
`
`years of relevant work experience in industry.
`
`The ‘843 Patent
`
`13.
`
`The ‘843 Patent is entitled “System, Method and Computer Program
`
`Product for Sharing Information in a Distributed Framework.” The ‘843 Patent was
`
`filed on June 22, 2012, issued on October 22, 2013, and has not yet expired. The
`
`‘843 Patent claims priority back to Dec. 17, 2002.
`
`14.
`
`The Petitioner argues that claims 1, 47, 48, 49, 50, and 51 of the ‘843
`
`Patent are invalid for obviousness on two grounds. At least for the reasons
`
`discussed below, claims 1, 47, 48, 49, 50, and 51 of the ‘843 Patent are not invalid
`
`
`
`6
`
`Page 6 of 47
`
`

`

`for obviousness under 35 U.S.C. § 103(a) on either ground. A copy of the ‘843
`
`Patent is attached as Exhibit 2002.
`
`15.
`
`Petitioner relies on Claim 51 of the ‘843 Patent as the template for its
`
`analysis of the ‘843 Patent and had presented the elements of Claim 51 in a table
`
`below. I will follow Petitioner’s listing of the elements. The elements of the
`
`challenged independent claim 51 of the ‘843 Patent are as follows:
`
`51a
`51b
`51c
`
`51d
`
`51e
`
`51f
`
`51g
`
`51h
`
`51i
`
`51j
`51k
`
`51l
`
`51m
`
`
`
`An apparatus, comprising:
`a control unit configured for:
`identifying information associated with a message received utilizing a
`first network protocol associated with a first network;
`issuing a storage resource request in connection with a storage resource
`and determining whether the storage resource is available;
`determining whether a threshold has been reached in association with the
`storage resource request;
`in the event the storage resource is not available and the threshold
`associated with the storage resource request has not been reached, issuing
`another storage resource request in connection with the storage resource;
`in the event the storage resource is not available and the threshold
`associated with the storage resource request has been reached, sending a
`notification; and
`in the event the storage resource is available, storing the information
`utilizing the storage resource;
`wherein the apparatus is operable such that the information is capable of
`being shared in real-time utilizing a second network protocol associated
`with a second network, and the control unit includes:
`a first interface for interfacing with the first network,
`the first interface including a first interface-related first component for
`receiving first data units and a first interface-related second component,
`the control unit being operable such that the first data units are processed
`after which processed first data units are provided,
`where the first network is at least one of a Controller Area Network type,
`a Flexray network type, or a Local Interconnect Network type;
`and a second interface for interfacing with the second network,
`
`7
`
`Page 7 of 47
`
`

`

`51n
`
`51o
`
`
`
`the second interface including a second interface-related first component
`for receiving second data units and a second interface-related second
`component, the control unit being operable such that the second data
`units are processed after which processed second data units are provided,
`where the second network is at least one of the Controller Area Network
`type, the Flexray network type, or the Local Interconnect Network type.
`
`16.
`
`Patent Owner’s counsel has asked me to construe the term “sharing
`
`the information”, which appears in claim 47 to mean “completing delivery of
`
`information to a destination.” This construction is consistent with the claim
`
`language itself. For example, claim 1 recites “ … in real-time, sharing the
`
`information utilizing at least one message format corresponding to a second
`
`network protocol associated with a second network ….” Pet. Ex. 1001, col. 12, ll.
`
`33-35. The utilization of a message format implies that a message is being sent and
`
`received. Similarly, this is consistent with the specification. For example, the
`
`specification notes that “By placing local information in a shared memory (local
`
`bulletin board), it can be used by multiple processes on this processor node. A
`
`group bulletin board allows devices on a sub-network to share information with a
`
`minimum of network traffic.” Pet. Ex. 1001, col. 6, ll. 27-31. The “sharing”
`
`clearly involves the actual delivery of information to the local bulletin board.
`
`Having reviewed the claims, the specification and prosecution history of the Patent,
`
`I concur that the construction is correct. My analysis and conclusions use this
`
`construction.
`
`
`
`8
`
`Page 8 of 47
`
`

`

`References Relied Upon by Petitioner
`
`a. Posadas
`
`17.
`
`For its Ground 1, Petitioner’s primary reference is Posadas et al.,
`
`“Communication Structure for Sensor Fusion in Distributed Real Time Systems,”
`
`published in the Proceedings volume from the 6th IFAC Workshop, Palma de
`
`Mallorca, Spain. Pet. Ex. 1007. Posadas describes a communication system for use
`
`in the YAIR (Yet Another Intelligent Robot). The system employs a CAN bus to
`
`transmit data, and the CAN bus interfaces with a “distributed blackboard” using the
`
`IP protocol on an Ethernet bus. The communication software “SC” is based on a
`
`Windows NT platform. “The data structure that forms the blackboard is continually
`
`updated with the changing values of the objects through the SC established
`
`channels.” “The SC system requires a program instance to be executed in each
`
`computer belonging to the configuration. The programs instance will communicate
`
`with each other to control and update the distributed data. As a result, each
`
`computer has a partial copy of the blackboard.” Pet. Ex. 1007 at 10. In other
`
`words, the memory used by an individual process is not shared by any other
`
`process.
`
`18.
`
`Petitioner asserts that Posadas “expressly requires a ‘guaranteed’
`
`response time, one of the defining characteristics of a real-time system.” See Pet. at
`
`28 n.6. In fact, Posadas describes a system that is not guaranteed to be real-time:
`
`
`
`9
`
`Page 9 of 47
`
`

`

`“These systems have a reactive level based computing and communication under
`
`real-time constraints. A deliberative level without real-time constraints also exists,
`
`but a good mean response time must still be guaranteed.” Pet. Ex. 1007 at 8. Thus,
`
`Posadas does not “require” guaranteed response times, and does not disclose how
`
`such response times might be guaranteed. Instead, Posadas merely states that “a
`
`good mean response time” must be guaranteed. A mean response time is quite
`
`different from a guaranteed response time. In addition, Posadas does not disclose
`
`how the “soft real time” system might guarantee response times. A typical non-
`
`deterministic Ethernet system running UDP might never deliver a packet, while the
`
`same system running TCP might have packet latency of more than one second.
`
`19. Although Posadas refers to the YAIR communication system as “real-
`
`time,” it is not clear from the reference that the two networks in the system actually
`
`shared information in real time. Posadas provides an analysis of the response time
`
`of the system, specifically defining the equation: Tacc = Tcomp + Rpet + Tproc + Rresp
`
`20.
`
`Each of the variables is defined in Posadas, but no bounds are placed
`
`on any of them. Pet. Ex. 1007 at 11-13. Although the terms “soft real-time” and
`
`“hard real-time” are used to describe the performance of the Ethernet and CAN
`
`networks, respectively, they are never defined to be within a specific bound (i.e.,
`
`less than one second). Without any bounds on any of the variables, it is not
`
`possible or appropriate to make any assumption as to the overall response time. In
`
`
`
`10
`
`Page 10 of 47
`
`

`

`addition, the results provided are based on local testing under specific hardware and
`
`software constraints, neither of which is directly provided in Posadas. In my
`
`opinion, a POSA at the time of the invention of the ‘843 Patent would not be able to
`
`employ the disclosures in Posadas to create a system of two networks sharing
`
`information in real time without an undue degree of experimentation. Petitioner
`
`argues that Posadas describes a real-time communications systems implemented in
`
`an autonomous industrial robot (“YAIR”) that “included a number of sensors that
`
`were interconnected using two different, real-time networks,” the first being a CAN
`
`bus and the second being, what Petitioner describes as, the “’deliberative system,’
`
`… described as ‘Soft Real-Time,’ and used the IP protocol on an Ethernet Bus,”
`
`with the two networks “shar[ing] information using a ‘blackboard’ shared
`
`memory.” Pet. at 13.
`
`21.
`
`Posadas also does not include anything that could correspond to a “a
`
`control unit” that comprises “a second interface for interfacing with the second
`
`network, the second interface including a second interface-related first component
`
`for receiving second data units.”
`
`22.
`
`Posadas describes a YAIR robot where all communications with any
`
`sensors and other nodes is by way of a CAN bus. In addition, Posadas discloses a
`
`distributed blackboard in accordance with a particular paper (Penny, H. (1989)
`
`“Blackboard Architectures and Applications.” Edited by V. Jagannathan, Rajendra
`
`
`
`11
`
`Page 11 of 47
`
`

`

`Dodhiawala, Lawrence S. Baum). The blackboard is part of the main control unit
`
`whose function is to receive data from the CAN bus and then externally
`
`communicate via “CAN, Ethernet, DOE, RS232, and so on.”
`
`23.
`
`The invention claimed by the ‘843 Patent requires that the control unit
`
`receive data units from both the first and second network, there is no second
`
`network providing data units in Posadas. There is no indication in Posadas that the
`
`“ISCCAN” or “SC” are interfaces for data units arriving from two separate
`
`networks.
`
`24.
`
`Thus, Posadas is not relevant to the claimed invention at its most basic
`
`level. In addition, as detailed below, any combination of Posadas and other prior art
`
`references does not provide a system meeting multiple specific elements of the ‘843
`
`Patent claims.
`
`b. Miesterfeld
`
`25.
`
`The primary reference offered by Petitioner for Ground 2 is U.S.
`
`Patent No. 6,141,710 to Miesterfeld. (Pet. Ex. 1010; hereinafter “Meisterfield”).
`
`Miesterfeld describes a system for interfacing a Vehicle Data Bus (VDB) to an
`
`Intelligent Transportation System (ITS) Data Bus (IDB). The system provides for
`
`memory accessed two busses and a gateway to manage the access. Petitioners
`
`assert that Miesterfield’s reference to “IDB” inherently refers to interaction via
`
`CAN. Pet. at 68; Pet. Ex. 1005, ¶¶85-88, 253. That is incorrect. Miesterfield
`
`
`
`12
`
`Page 12 of 47
`
`

`

`refers solely to “IDB.” A skilled artisan would understand that reference to mean
`
`Standard J2355_199710, which was published October 1, 1997, and was the only
`
`IDB standard when Miesterfield was published. Ex. 2002. Contrary to Petitioner’s
`
`assertion, a skilled artisan would not understand that Miesterfield was referring to
`
`“IDB-C,” which is a very different specification than “IDB,” and which was not
`
`even published until November 27, 2001 – long after Miesterfield was published.
`
`See Pet. Ex. 1032 (SAE J2366 Fact Sheet, USDOT July 12, 2006). Miesterfeld
`
`never refers to CAN directly or indirectly, and a skilled artisan would not consider
`
`that Miesterfield discloses combining the invention with the “IDB-C” standard
`
`merely because the standard includes the “IDB” in its title. Therefore, Miesterfeld
`
`does not disclose to a skilled artisan at the time of the invention of the ‘843 Patent a
`
`system which includes a CAN bus.
`
`c. Stewart
`
`26.
`
`Petitioner cites Stewart as a secondary reference in support of
`
`Grounds 1 and 2. The Stewart reference is “Integration of Real-Time Software
`
`Modules for Reconfigurable Sensor-Based Control Systems”, published in the
`
`Proceedings of the 1992 IEEE/RSJ International Conference on Intelligent Robots
`
`and Systems in Raleigh, North Carolina in July 1992. Pet. Ex. 1008 (hereinafter,
`
`“Stewart”). Stewart describes a system with a global state variable table (database)
`
`that can share data across multiple processes confined to a single bus in real-time.
`
`
`
`13
`
`Page 13 of 47
`
`

`

`Each process maintains its own local state variable table so there is no contention of
`
`data among the processes. “At the beginning of every cycle of a task, the variables
`
`which are input ports are transferred into the local table from the global table. At
`
`the end of the task's cycle, variables which are output ports are copied from the
`
`local table into the global table.” Pet. Ex. 1008 at 7. To keep the data in sync with
`
`the global database, Stewart recommends a spin-lock. The spin-lock tests to see if
`
`any other process has currently acquired the lock on the database, and if so, the
`
`process must wait for a small delay (called the polling time) before trying again.
`
`Stewart directs that if a process is unable to access the database after a certain
`
`number of retries, “error handlers should be installed to detect tasks that suffer
`
`successive time-out errors,” but then states that “[d]iscussion on handling these
`
`errors is beyond the scope of this paper.” Pet. Ex. 1008, IV.A., at 11. Thus,
`
`whereas Stewart acknowledges that his proposed system includes situations where a
`
`process will not be able to write to the global database, Stewart does not disclose
`
`how to handle such situations, and, in fact, disclaims any discussion on handling
`
`these circumstances.
`
`d. Wense
`
`27.
`
`Petitioner cites Wense as a secondary reference in support of Grounds
`
`1 and 2. The reference is H-C. von der Wense et al., “Building Automotive LIN
`
`Applications,” Advanced Microsystems for Automotive Applications, published on
`
`
`
`14
`
`Page 14 of 47
`
`

`

`July 16, 2001. (Pet. Ex. 1009; hereinafter “Wense”). Wense describes the Local
`
`Interconnect Network (LIN) communication standard, and, particularly, the
`
`properties of LIN in comparison with other networking standards, LIN’s position in
`
`the relative hierarchy of networking applications, and its potential operation as a
`
`subnetwork of a CAN network system.
`
`28. As detailed below, in my opinion, neither Posadas nor Miesterfeld,
`
`even as supported by Stewart and Wense, disclose or render obvious the inventions
`
`claimed in the ‘843 Patent.
`
`29.
`
`The discussion below presents the exact language of each challenged
`
`claim element, where applicable, in italics as headings, which are followed by a
`
`discussion to show the absence of disclosure of the claimed element.
`
`Ground 1
`
`Claim 51
`
`30.
`
`Element 51g: in the event the storage resource is not available and
`
`the threshold associated with the storage resource request has been reached,
`
`sending a notification;
`
`Petitioner fails to demonstrate obviousness of Claim 51, at least because no
`
`combination of Posadas, Stewart and Wense discloses element 51g. Petitioner
`
`argues that “Stewart discloses that a time-out error will occur if a time-out (the
`
`claimed ‘threshold’) has been reached for a task that has been continually trying to
`
`
`
`15
`
`Page 15 of 47
`
`

`

`access the table but has been unsuccessful. Id.,11 (‘a time-out mechanism is used,
`
`so that if the lock is not gained within a pre-specified time or number of retries,
`
`then the transfer is not performed. . . . When using the time-out mechanism, error
`
`handlers should be installed to detect tasks that suffer successive time-out
`
`errors.’).” See Pet. at 24-25. Petitioner is incorrect. Petitioner relies entirely on
`
`the following discussion in Stewart that discusses a “time-out mechanism” and an
`
`associate “error handler”:
`
`Without a bounded waiting time locking mechanism, it is not possible
`to guarantee that tasks will get the data they require on time, every
`time. As an alternative, a time-out mechanism is used, so that if the
`lock is not gained within a pre-specified time or number of retries,
`then the transfer is not performed. The maximum waiting time for the
`lock is then the time-out period, which is also equal to polling_time *
`max_number_of_retries. For most tasks in a control system, missing
`an occasional-cycle is not be critical. In such a case, the value from
`the previous cycle still remains in the local table, and will be used
`during the next cycle. When using the time-out mechanism, error
`handlers should be installed to detect tasks that suffer successive time-
`out errors. Discussion on handling these errors is beyond the scope
`of this paper.
`
`Pet. Ex. 1008 at 11 (emphasis added).
`
`As is plainly apparent from the above excerpt, Stewart does not disclose
`
`“sending a notification.” Petitioner’s apparent suggestion that Stewart’s reference
`
`to “error handler” constitutes “sending a notification” is unfounded and is merely
`
`erroneous speculation. The typical meaning of an “error handler” is a mechanism
`
`that forestalls errors if possible, and then recovers from errors when they occur
`
`
`
`16
`
`Page 16 of 47
`
`

`

`without terminating the application. “Error handler” does not necessarily or
`
`inherently include sending a notification, as required by Claim 51 of the ‘843
`
`Patent. In fact, Stewart states that the “discussion on handling these errors is
`
`beyond the scope of this paper,” which expressly disclaims the disclosure of any
`
`particular error-handling method, and, thus, expressly excludes disclosing the
`
`sending of any notification. Petitioner does not point to any function or structure
`
`in Stewart which sends “a notification.” Stewart does not disclose claim element
`
`51g.
`
`31.
`
`Element 51i: wherein the apparatus is operable such that the
`
`information is capable of being shared in real-time…
`
`The combination of Posadas, Stewart and Wense also fails to disclose
`
`element 51i. Petitioner argues that Posadas discloses real-time sharing of
`
`information between two networks, because Posadas claims to perform a “response
`
`time analysis” of “read/write temporary costs on sensorial distributed variables.”
`
`Pet. Ex. 1007 at 12. Posadas states, “[d]istributed variable access time is split into
`
`the following factors:
`
`
`
`Tacc = Tcomp + Rpet + Tproc + Rresp.”
`
`Posadas then defines each of those four variables. Pet. Ex. 1007 at 13.
`
`To appreciate Posadas’ disclosure, it is necessary to appreciate that none of
`
`the variables Tcomp, Rpet, Tproc, or Rresp are bounded or restricted in time – either
`
`
`
`17
`
`Page 17 of 47
`
`

`

`directly or inherently. Thus, Tcomp means “computation time”; Rpet means “CAN
`
`latency for request”; Tproc means “processing time or local access time”; and Rresp
`
`means “CAN latency for response.” Id . Thus, even if one assumes that Tacc is the
`
`time that it takes for one process to provide data so that another process can access
`
`it, none of the incorporated variables is restricted or bounded in time. We cannot
`
`assume that the sum of those values, which is defined to be Tacc, is less than one
`
`second.
`
`32.
`
`Further, the use of the term “real-time” in Posadas sections 7 and 10
`
`are not defined to be within a specific bound. See Pet. Ex. 1007 at 12, 13. The term
`
`“real-time” is not defined as a certain number of milliseconds, microseconds, or
`
`seconds generally in the technology field, but is more generally defined as not
`
`having a significant delay. These terms are relative based on the application
`
`though. For example:
`
`real-time stock tickers may need to operate within 3 seconds of a stock price
`
`changing
`
`real-time streaming of video may be 10 seconds behind the actual data being
`
`downloaded
`
`real-time stopping of a vehicle may need to begin stopping within 10ms of
`
`detecting an obstacle
`
`18
`
`-
`
`-
`
`-
`
`
`
`Page 18 of 47
`
`

`

`Without values bounding the variables used to determine Tacc, we are not able to
`
`state whether Tacc is bounded by a maximum value of 1 second.
`
`33.
`
`51d: issuing a storage resource request in connection with a storage
`
`resource and determining whether the storage resource is available;
`
`51e: determining whether a threshold has been reached in association
`
`with the storage resource request;
`
`51f:
`
`in the event the storage resource is not available and the threshold
`
`associated with the storage resource request has not been reached, issuing
`
`another storage resource request in connection with the storage resource; and
`
`51h: in the event the storage resource is available, storing the
`
`information utilizing the storage resource;
`
`Petitioner alleges that elements 51d through 51h are met by Stewart, Pet. Ex.
`
`1008.
`
`It has been previously demonstrated that element 51g is not found in either
`
`Posadas or Stewart, and, thus, no combination of Stewart and Posadas will produce
`
`the invention claimed in the ‘843 Patent. Further, even if it were assumed,
`
`arguendo, that Stewart discloses a system that provides for storing of information
`
`similarly to that set forth in elements 51d through 51h, there is still no basis for
`
`combining Posadas with Stewart to arrive at the invention claimed by the ‘843
`
`Patent.
`
`
`
`19
`
`Page 19 of 47
`
`

`

`34.
`
`Petitioner argues that “Both Posadas and Stewart are in the same field
`
`of endeavor.” Pet. 21. That is true only to the extent that both Posadas and Stewart
`
`disclose only a single data unit network system. Neither Posadas nor Stewart
`
`envision a system that includes “second data units” as contemplated by the ‘843
`
`Patent. Certainly, there is nothing in the specific disclosures of Posadas or anything
`
`that is necessarily inherent in Posadas that would suggest that any control unit
`
`receives data units from any source other than the CAN bus.
`
`35. Moreover, Petitioner ignores that Posadas stored information in a
`
`specific blackboard architecture and system. Stewart, on the other hand, does not
`
`deal with a blackboard architecture. There is no explanation why a skilled artisan
`
`would think of meshing Posadas’ blackboard-specific architecture with Stewart’s
`
`non-blackboard system.
`
`36.
`
`Petitioner next asserts that “Both Posadas and Stewart are aimed at
`
`solving the same perceived problem in the prior art.” Pet at 21. That is not correct,
`
`again, because Posadas utilizes a blackboard system that is not like the storage
`
`system referenced in Stewart.
`
`37.
`
`Petitioner next asserts that “Both Posadas and Stewart use similar
`
`techniques to solve the same problem,” because both “use a shared memory
`
`architecture to exchange information.” Pet at 21-22. I agree that both Posadas and
`
`
`
`20
`
`Page 20 of 47
`
`

`

`Stewart include a memory where information may be stored, but blackboard
`
`systems differ from the Stewart’s storage system.
`
`38.
`
`Petitioner next asserts that “The use of the memory access arbitration
`
`techniques expressly disclosed in Stewart were well-known, simple design choices
`
`to one of ordinary skill in the art,” and that “[d]etermining whether memory is
`
`available before writing to it is a basic, fundamental operation that was well-known
`
`to those of skill in the art since the availability of multitasking computers.” Pet. at
`
`22. I agree that determining memory availability is well known in the art, but
`
`Petitioner’s assertions fail to analyze Posadas’ blackboard system in contrast with
`
`Stewart’s system.
`
`39.
`
`Petitioner next asserts that both “Combining Posadas with Stewart
`
`would have been a predictable combination.” Pet at 22. Yet, Petitioner does not
`
`even attempt to explain whether the result of the combination would (or even could)
`
`retain Posadas’ blackboard architecture, much less explain how Posadas’
`
`blackboard structure could be changed to accept Stewart’s system. It is stressed
`
`that Posadas’ data structure is accessed via the blackboard architecture, and not by
`
`way of a CAN bus interface.
`
`In view of the particular Stewart environment and structure, a skilled artisan
`
`would not be motivated to rework and then combine Stewart’s memory access
`
`arbitration techniques with Posadas.
`
`
`
`21
`
`Page 21 of 47
`
`

`

`40.
`
`51h: in the event the storage resource is available, storing the
`
`information utilizing the storage resource;
`
`Petitioner alleges that element 51h is met by Stewart, because “Stewart
`
`discloses a global variable table which is stored in shared memory for the exchange
`
`of data between modules.” Pet. at 25. However, as noted above, the “modules”
`
`that are sharing information in Stewart are software modules, which may be
`
`resident on the same processor, or which may be resident on separate processors
`
`connected by a common data bus, not modules connected to separate and distinct
`
`data networks connected by a shared memory system. In my opinion, although
`
`Petitioner has attempted to make Stewart sound like a system similar to both
`
`Posadas and the claimed invention, it is, in fact, entirely different, and a POSA at
`
`the time of the invention of the ‘843 Patent would not have been motivated to
`
`combine them.
`
`41.
`
`51m and 51n: a second interface for interfacing with the second
`
`network,
`
`the second interface including a second interface-related first component
`
`for receiving second data units and a second interface-related second component,