`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`REALTIME DATA LLC,
`Patent Owner.
`____________
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`____________
`
`Record of Oral Hearing
`Held: January 8, 2018
`____________
`
`
`
`
`Before GEORGIANNA W. BRADEN, JASON J. CHUNG, and JEFFREY
`A. STEPHENS, Administrative Patent Judges.
`
`
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`W. KARL RENNER, ESQUIRE
`JEREMY J. MONALDO, ESQUIRE
`ANDREW PATRICK, ESQUIRE
`Fish & Richardson, P.C.
`1425 K Street, N.W., Eleventh Floor
`Washington, D.C. 20005
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`JOSEPH EDELL, ESQUIRE
`Fisch Sigler, LLP
`5301 Wisconsin Avenue, N.W., Fourth Floor
`Washington, D.C. 20015
`
`and
`
`KAYVAN B. NOROOZI, ESQUIRE
`Noroozi, P.C.
`1299 Ocean Avenue, Suite 450
`Santa Monica, California 90401
`
`
`
`
`The above-entitled matter came on for hearing on Monday, January 8,
`
`2018, commencing at 1:00 p.m., at the U.S. Patent and Trademark Office,
`600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`
`
`2
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE BRADEN: Good afternoon. We are convened for oral
`arguments in IPR2016-01737, IPR2016-01738 and IPR2016-01739, all of
`which challenge U.S. patent number 8,880,862. I am Judge Braden. Also
`appearing remotely is Judge Stephens, and our colleague in the room with
`you in Alexandria is Judge Chung. As Judge Stephens and I are appearing
`via video, we require counselors to speak directly into the microphone when
`talking and to identify specific slide numbers when referring to
`demonstratives.
`Now, each party has 90 minutes total time to argue all three cases.
`Petitioner, Apple, Inc., has the ultimate burden of establishing
`unpatentability. Therefore, petitioner will open the hearing by presenting its
`cases as presented in its petitions regarding the alleged unpatentability of the
`challenged claims. Petitioner may reserve rebuttal time. Thereafter, patent
`owner, Realtime Data, LLC, will respond petitioner's arguments and may
`present its cases regarding the motions to amend and motions to exclude.
`Patent owner may reserve rebuttal time only with regards to its motions.
`Petitioner may then proceed to use any reserved rebuttal time to address
`arguments in either the grounds in the petitions, its replies and/or those in
`the motions to amend and motions to exclude. Finally, patent owner may go
`last and may use any reserved rebuttal time to address only petitioner's
`arguments regarding the motions to amend and the motions to exclude.
`Otherwise, the parties may use its allotted time to discuss the three cases in
`any order they choose. We ask, however, that you make it clear which case
`
`
`3
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`and which claims you are addressing. To ensure clarity of the record
`following the hearing, please provide the court reporter with a list of names
`and word spellings.
`Now, we have received objections from the petitioner regarding
`patent owner's demonstratives. As the demonstratives are not evidence and
`not part of the official record, we will take the objections under advisement
`and will not rule on them at this time. I will note, however, that if patent
`owner cannot show where its slide graphics were discussed or presented in
`its briefing, then such graphics will not be relied upon during our decision
`making.
`Lastly, we ask that the parties hold any objections regarding a
`party's arguments until it is their time at the podium. To be clear, I will not
`take objections during a party's arguments. You must wait until it is your
`time at the podium to note any objections.
`I will maintain a clock and inform the parties when they have five
`minutes left. So let's go ahead and get started with appearances for both
`sides. We will start with petitioner.
`MR. RENNER: Good afternoon, Your Honors. Karl Renner from
`Fish & Richardson here on behalf of Apple. And I'm joined by co-counsel,
`Jeremy Monaldo and Andrew Patrick.
`JUDGE BRADEN: Thank you, counselor. Counsel for patent
`
`owner.
`
`MR. EDELL: Thank you, Your Honors. Joe Edell on behalf of
`the patent owner from Fisch Sigler. I am joined by co-counsel, Kayvan
`Noroozi of Noroozi PC.
`
`
`4
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`JUDGE BRADEN: Very good. Thank you. Petitioner, you are
`up. Do you wish to reserve any rebuttal time?
`MR. MONALDO: Thank you, Your Honor. Yes, we do. We are
`hoping to receive approximately 60 minutes in rebuttal time.
`JUDGE BRADEN: Very good. You may begin your arguments
`when ready.
`MR. MONALDO: May it please the Board, my name is Jeremy
`Monaldo from Fish & Richardson, representing Apple as petitioner. I'm
`joined today by my colleagues Karl Renner and Andrew Patrick. First of all,
`I want to thank Your Honors for taking the time to hear our case in this
`matter, particularly Judge Chung, the court reporter and the staff here, given
`the weather conditions in Alexandria.
`So today we are scheduled to discuss just one patent, Realtime's
`'862 patent. But this is not a typical patent. It is a patent with 117 claims
`that required three IPR petitions and a variety of grounds to address. As a
`consequence, we are facing a substantial record.
`The good news is that the '862 patent is a continuation of
`Realtime's '608 and '936 patents that we previously discussed last fall. With
`that similarity, I think we are all very aware of the subject matter of
`Realtime's patent. As a consequence, I'll not plan to use my direct time to
`provide an overview of that patent unless Your Honors would like.
`Now, despite the similarity of the '862 patent and the '608 and '936
`patents, there are significant differences between those proceedings and the
`present ones. You'll see that Realtime has moved away and abandoned
`many of the arguments made in the earlier proceedings. Instead, what
`
`
`5
`
`
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`Realtime has done is they have pursued claim amendments and changed to
`new arguments that are different from those made in the original
`proceedings. For my direct presentation, I'll plan to focus on those new
`arguments raised with respect to the original claims.
`Moving to slide 2, you'll see that we provided a table of contents
`for convenient reference to the various sections in our demonstratives.
`You'll see that the table of contents lists a set of issues, these new arguments
`that Realtime has brought forward and brought to bear against the claims of
`the '862 patent. Now, this is not intended to be a comprehensive list of
`issues, but rather a list of issues that we thought warranted further
`discussion. Some of these issues apply to all three proceedings and some
`apply to just one or two of the proceedings. Our slides signal which
`proceeding is relevant to the issue through citation to one or more of the
`1737, 1738 and 1739 IPR proceeding numbers.
`With that background, I actually plan to spend most of my time on
`the first issue here, the combination of the prior art applied in these
`proceedings and how these combinations work. With the substantial record
`before us, I really want to leave this discussion giving Your Honors clarity
`of our position and a clear understanding of how these references come
`together. With a clear understanding of our application of the prior art, the
`remainder of the issues really become non-issues, features that are clearly
`present in the combinations that we have set forward. Now, that said, our
`primary objective is to make sure we answer any questions Your Honors
`might have. So feel free to please interrupt me or steer the discussion in any
`way you choose.
`
`
`6
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`So now I would like to move to slide 9 to discuss the combination
`of the Sukegawa and Dye reference which is relevant to the 1737 and 1738
`proceedings. So on the left-hand side of our slide 9, you can see that
`Sukegawa's Figure 1 annotated on the slide has many of the same
`components as Realtime's patent. We have a host system highlighted in
`purple, a controller highlighted in red, a hard disk highlighted in green and a
`cache highlighted in blue. Now, the host system uses the hard disk
`highlighted in green as a large storage repository of all of the data used by
`the host system. This includes the host system's operating system data and
`data related to frequently used applications that is needed shortly after the
`system powers on or resets.
`So if that hard disk has all the data the host system needs, why do
`we have the cache? We have the cache because of speed. Given the large
`volume and its technology for data storage, a hard disk is a relatively slow
`device. Sukegawa recognized this problem particularly for the operating
`system in frequently used application data that is needed soon after you
`power on. If the controller needs to go back to the hard drive to provide that
`data, the boot process is slow and can cause user frustration.
`So what did Sukegawa propose? He proposed adding the cache,
`the flash memory unit 1, which is faster memory device and allows the
`controller to access that data more quickly. However, the cache is also a
`smaller device. You can't store everything in a hard disk in the cache. If
`you could, you wouldn't need the hard disk. So with these realities,
`Sukegawa had to make choices to what data gets loaded into the cache and
`what data is stored only in the hard disk. One choice was clear. It was the
`
`
`7
`
`
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`operating system data in the frequently used application data that gets loaded
`in the cache and made available to speed the boot process.
`Sukegawa also recognized the need for flexibility in what data
`goes into that cache. Every user is different. They might want different data
`in the cache. Required data may change over time. So we need to manage
`this cache in a fluid manner so that the system can continue to provide a
`good user experience and boot the computer up as quickly as possible in the
`way the user chooses.
`So specifically, Sukegawa proposed two types of managements for
`the cache, user management and automated management. You can see in
`flash memory unit 1 you have an area 10A that is directed to this
`user-managed data. So Sukegawa uses a data storage utility program that
`allows a user to go and pick what data gets loaded into area 10A. Now,
`although 10A is labeled there as permanent storage area, it's not really
`permanent. It's only permanent in that the controller will only remove data
`from this area with user permission. Accordingly, the user is free to use
`Sukegawa's data storage utility program to add data into area 10A, remove
`data into area 10A based on that user's current or changed preferences.
`So as to automated management, Sukegawa uses area 10C which
`the controller manages automatically based on the data request it's receiving
`from the host system. Specifically the controller keeps the most recent data
`in area 10C, removing older data that hasn't been requested in some time. In
`this way, the data in 10C is managed fluidly and is kept current keeping the
`recent data in area 10C and removing the older data.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
`8
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`So now, how does Sukegawa keep track of all of this data? It uses
`management information table 3A. You can see that on the right-hand side
`of Figure 1. So this table 3A is a list of data included in Sukegawa's cache.
`This includes the user-managed area 10A. So when a user adds data in the
`cache, table 3A is updated to reflect that data. When a user deletes data
`from the cache, the cache, that table 3A is updated to remove that data from
`the cache. The list is to maintain a current version of what is stored in area
`10A.
`
`Similarly --
`JUDGE BRADEN: Can you point me to where in Sukegawa that
`is about the updating of 3A. Do you have a citation handy?
`MR. MONALDO: I don't have a citation handy. There's a variety
`of places in Sukegawa that describe how table 3A is updated. I'm sorry, let
`me consult one of our slides. But you can certainly see in table 3A that
`Sukegawa describes that as managing the information in all of the cache. It
`says managing the storage areas 10A to 10C. So as a consequence, you
`have, and as Dr. Neuhauser explained to you, a table that lists all of the data
`in 10A, and then you certainly have description throughout Sukegawa about
`user deletion of operating system data or user deletion of application data.
`And as a consequence, that table requires updates. It has to know what data
`is in the cache. And we'll look, my colleague, Andrew Patrick is looking for
`a citation now.
`JUDGE BRADEN: I don't want to mischaracterize patent owner's
`arguments in any way, but I understood that they made an argument saying
`that if it was user done, that that was a different situation than it being
`
`
`9
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`automatically done to be able to associate boot data with the boot data list.
`Is there something in Sukegawa that you rely on to be able to show that if
`there is any kind of automatic updates or changes to the boot data, that there
`is therefore, an updating or changing of a boot data list that would be in
`table 3A?
`MR. MONALDO: Sure, Your Honor. So as I was mentioning,
`we've got these user updates. We still think that would apply, a user going
`in, deleting data, removing data from the boot data list, that certainly would
`apply and meet the updates that are required and the different claim elements
`where you remove data from the boot data list.
`We also have area 10C which includes boot data itself. It can
`include the operating system data and it can include application data. Let
`me give you an example of that. So permanent storage area 10A is used for
`a user who wants to pick what data goes into that area. Now, Sukegawa
`explicitly describes an example where that data might not include the
`operating system. The user might not want the operating system to be stored
`in area 10A. In that case, that operating system data is just treated as any
`other data in Sukegawa and would be loaded into area 10C automatically.
`That's how Sukegawa works in its automatic management process of area
`10C.
`
`So in that case, the boot data would be loaded into area 10C, the
`operating system data, frequently used application data, all of that boot data,
`and that would be managed automatically. As things are requested, they get
`loaded to 10C and they are in -- and table 3A is updated. As things -- as you
`add new data, you of course have to remove data, and Sukegawa tells you
`
`
`
`
`10
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`that. And when you remove data, you need to update that list, the boot data
`list, the table 3A to reflect what data has been removed from the storage
`area. Does that answer your question?
`JUDGE BRADEN: I understand your position. Thank you.
`MR. MONALDO: Great. Thank you, Your Honor. So with this
`operation, what Sukegawa does is it loads boot data whether it's going to
`10A or 10C and includes the boot data list at table 3A that gets updated by
`adding and removing data. So what Sukegawa is missing, however, is
`compression. We've spoken at length about that before and I don't know that
`I want to go too far into it. But we certainly have Dye here that clearly
`shows compression with a compression unit being provided in a controller,
`highlighted in red, similar to the controller in Sukegawa. You can see what
`Dye is controlling and what it's performing compression on is a flash
`memory array, highlighted in blue, similar to the flash memory unit in
`Sukegawa.
`So if we move to slide 10, you can see how Dye quite naturally
`combines into Sukegawa adding its compression/decompression engine into
`Sukegawa's controller. Dye's compression engine then can compress data
`and decompress data stored in both of Sukegawa's storage devices, the flash
`memory unit as well as the hard drive. So as data is written to either of these
`units, the controller is able to confirm that the data is compressed. Whether
`it has to compress it or not or if it's already in compressed form, it can load it
`in compressed form. Also as the host system requests data, Sukegawa's
`controller modified by Dye and depresses it and provides it to the host
`system.
`
`
`11
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`So why would a person of ordinary skill in the art make this
`change? I think we've discussed this at length, but for two good reasons.
`One, to increase your storage density. If your data is smaller, you can fit
`more data into your flash or in your hard drive; and two, faster access speed.
`Dye allows you to get data out of these storage devices more quickly using
`compression. Because data is accessed more quickly, booting is faster. So
`in this context with increased fast capacity and faster speed, the combination
`makes a lot of sense and really helps speed Sukegawa's boot process.
`So I just want to pause here to see if there are any further questions
`on our application of Sukegawa and Dye and how these references are
`coming together.
`So hearing no questions, I would like to move to slide 12 to discuss
`the Settsu reference and its relevance in the 1739 proceeding. So on slide
`12, you can see a version of Settsu's Figure 12 which provides a graphic of
`Settsu's operating system. As shown, the operating system is stored on a
`hard disk boot device 3. The operating system is divided into two parts, a
`mini OS module shown at the upper portion of the figure, and an OS main
`body module shown at the lower portion of the figure. The OS main body is
`further broken into several operating system modules.
`So how does Settsu perform a boot process? First Settsu loads the
`mini OS module, the upper portion. As shown in Figure 13 of Settsu, the
`mini OS module includes a kernel that forms a basic part of the operating
`system and executes first. After that kernel is running, the mini OS module
`starts an OS loading and decompression module. What does this module
`do? It does exactly that. It loads an operating system module into memory
`
`
`12
`
`
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`and decompresses it. That OS and loading decompression module continues
`loading these OS main body modules one by one and in parallel.
`Now, Settsu confirms that the border with which the OS modules
`is loaded is flexible. Any one of them can be loaded first. Now, that's the
`explicit disclosure in Settsu found, for example, at column 11, lines 31 to 33.
`So to keep track of that loading order and to determine when all modules
`have been loaded, Dr. Neuhauser tells us that Settsu's mini OS module uses
`a list, a list of those modules stored in the OS main body.
`So with that background, I thought I would jump to slide 25
`actually to discuss a more specific example of Settsu's booting process. So
`if we move over to slide 25, you can see Settsu's Figure 20 which is directed
`to a specific example that uses Settsu's function definition file. So this
`example shows how a user is able to customize Settsu's boot process and
`control which OS main body modules are loaded and initialized first. The
`goal of the function definition file is to list the OS modules required for an
`important application to operate. Because that application only needs a part
`of the operating system to function, the application can start more quickly if
`those modules are loaded and initialized first.
`So let's look at Figure 20. So how does this process start? The
`first thing you do is you load your application and then you analyze this
`function definition file that identifies the list of OS modules that are needed
`for that application to run and should be loaded first.
`The flow then moves to load these modules. You can see at
`step 213 that you load each of the modules defined in the function definition
`file and then at step 216 to check whether all of those listed modules have
`
`
`13
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`been loaded. Once all of the listed modules have been loaded, the flow
`moves to step 217 to start the application. At this point we have a subset,
`just a portion of the modules of Settsu's operating system loaded and
`initialized and you have an application that's running and operational while
`the boot process completes.
`So then you move to the latter part of the figure where you
`complete the boot process. And this aligns with the description I just gave
`you related to Figure 12. You can see this at step 218 where each of the
`remaining modules is loaded. Then at step 221 you have a determination
`made as to whether all of the modules have been loaded. So to achieve this
`operation, the operation shown specifically in Figure 20, Settsu has two lists
`of boot data. First it has that function definition file which loads those
`modules that need to go first to support the application. Second, you have a
`list of the entirety of modules in the OS main body. This list is used to load
`the remaining modules that are not included in the function definition file
`and ensure you make the right decision that all modules have been loaded.
`So that's really Settsu alone and that's our --
`JUDGE BRADEN: Where does Settsu update the boot data list?
`MR. MONALDO: So that's a great question. So as you know,
`Your Honor, we have applied Settsu under an obviousness context. So it's
`one thing that we recognize Settsu doesn't explicitly have disclosure of
`updating a boot data list. So let's recall what we've just talked about as being
`the boot data list in Settsu. It's the function definition file list of those
`modules that are needed in the application and it's the list of the entirety of
`modules within the OS main body. We've also mapped a variety of lists to
`
`
`14
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`the actual lists of -- the actual files themselves in the modules. So there's a
`lot of lists that are going and operating a computer system, but let's focus on
`the list of modules for this discussion.
`And so as we presented in the petition, we offered evidence from
`Dr. Neuhauser that said, look, we know operating systems get updated all
`the time. You are always getting new updates, a new version of an operating
`system, and we specifically provided evidence of updates that happen to a
`Windows operating system. This is something that just naturally occurs as
`part of the process. When you are using an operating system, you are going
`to need to update it. Things change --
`JUDGE BRADEN: Does every file that gets updated have a new
`version number? Does that always happen? My confusion stems from say
`that you have a list of files and each file is a file and there's substance in the
`file. If you update a file, you change it, you fix a bug or put a patch in there,
`why does that necessarily mean that your table of contents, your list of files
`must necessarily be updated or changed?
`MR. MONALDO: So that's a great question, Your Honor. It's not
`necessarily that your list gets changed when you just update a single file. If
`you are just putting new data in that file, the list in that file, the information
`in that file must change as a consequence. It might not change the list of
`modules that we talked about, but there are certainly cases when you are
`updating your operating system where you are going to get rid of some
`functionality, you're going to change your modules. Maybe new things have
`come out. You are going to add a module in, you are going to move a
`module. It's just how this works and how operating systems function in this
`
`
`15
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`opportunity. You can't just have a static list of modules and say, hey, these
`are the modules I'm going to have and that's going to run in perpetuity. A
`person of ordinary skill in the art would not understand that to happen.
`Rather, there's going to be updates, there's going to be additions, there's
`going to be removals, and that's where your list of modules needs to get
`updated. Does that answer your question?
`JUDGE BRADEN: Is there something particularly that
`Dr. Neuhauser points to that would help us show that this would be
`something that a person of skill in the art would find obvious that any time
`you are updating your modules or you have got to update the boot data list in
`and of itself necessarily -- this is obviously not a 102 argument, we are
`talking about 103, but point to me where in the record there's sufficient
`evidence to show that this would happen in order to meet the claim
`limitations.
`MR. MONALDO: Yeah, Your Honor. Maybe I'll move us to
`slide 26. Actually, let me move to slide 28. This is just a specific example
`of what I have been talking about here where we are talking about Settsu's
`list of modules. So this aligns exactly with our discussion. We had some
`earlier presentation on slide 27 that shows you how files get updated and
`how there's headers in Settsu's files. For clarity, let me just point to slide 28
`which shows how Dr. Neuhauser opined that Settsu's list of modules gets
`updated.
`JUDGE BRADEN: Actually, I guess what I'm looking for is, is
`there some evidence of showing that this has actually happened? Because
`other than you showing that there's a change in your boot data list where you
`
`
`16
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`have got a new version, I mean, is there an example, is there some evidence
`in the record besides testimony of showing that this happens with Settsu's
`program or with Settsu's system?
`MR. MONALDO: Yeah, Your Honor. I mean, I think there is.
`You can see Dr. Neuhauser's declaration here at paragraph 117.
`JUDGE BRADEN: Is this O'Reilly?
`MR. MONALDO: This is O'Reilly, yes. There's a citation and
`talks about the updates that are regularly occurring to the Windows
`operating system. And you'll see here in that section how when you have
`these updates to an operating system, there are certainly changes that would
`impact, and as Dr. Neuhauser explained, impact the modules that would be
`used so that you'd have to change your list.
`And you'll see this is really not a point of debate between the two
`experts. In Dr. Back's declaration, we can talk about that at some time, he
`recognizes that updates occur. That's not something that's new or something
`that would be considered inventive in terms of what's going on, and that's
`well known by those of skill in the art. And you can see the language that
`Dr. Back uses. He says most of the time operating system modules might
`not be updated, but the list of modules could in some time be operating. So
`by using the word "most," he's himself recognizing there are at least some
`instances where the list of modules would be operated. So in an obviousness
`context where we don't necessarily need to show an inherency argument
`where the list of modules is necessarily operated, it certainly is something
`that would be obvious in light of Dr. Neuhauser's opinion supported by the
`evidence of record, the updates to the operating system as well as Dr. Back's
`
`
`17
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`opinion that at least sometimes those modules need updating, that list of
`modules. So does that answer the question?
`JUDGE BRADEN: I believe I understand your position. Thank
`
`you.
`
`MR. MONALDO: Thank you, Your Honor. So I think I would
`like to turn back now to slide 12. So we have an additional combination in
`the 1739 proceeding which is the Settsu and Zwiegincew combination. So
`what is Zwiegincew? Zwiegincew is a patent that's directed to pre-fetching
`data from a hard disk to memory to avoid hard page faults. So hard page
`faults are a situation that occurs where a computer asks for data and it's not
`in memory. You have to go all the way back to the hard disk to get that
`data. Zwiegincew recognized that that's a problem that's undesirable
`because it takes a relatively long time to go back to the hard drive and get
`this data. To address this issue --
`JUDGE BRADEN: Counsel, you have five minutes before you
`start eating into your rebuttal time.
`MR. MONALDO: Yes, Your Honor. Thank you. So to address
`this issue, Zwiegincew uses these scenario files. What they do is they have a
`list of page sequences that are related to scenarios that occur in
`Zwiegincew's system. So when a scenario is detected, Zwiegincew loads the
`pages that are likely to be retrieved during the next -- during that scenario.
`So Zwiegincew tells us that you have these scenario files. It's constantly
`looking and taking patterns of data accesses and refining the scenario files
`based on usage. So Zwiegincew itself is updating its list of boot data or list
`of data to scenario files.
`
`
`18
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`
`
`Case IPR2016-01737 (Patent 8,880,862)
`Case IPR2016-01738 (Patent 8,880,862)
`Case IPR2016-01739 (Patent 8,880,862)
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`So how does this combination come together? So as I previously
`mentioned, Settsu has these lists of the OS modules. These are higher level
`lists than the lists in Zwiegincew. Zwiegincew is looking at a lower level.
`Not the modul