throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`WORLDS INC.,
`Patent Owner.
`
`Case IPR2021-00277
`Patent 8,082,501
`
`SUPPLEMENTAL DECLARATION OF MICHAEL ZYDA, D.SC.
`
`1
`
`MS 1034
`
`

`

`
`I, Michael Zyda, declare as follows:
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`1.
`
`I have been retained on behalf of Microsoft Corporation to offer tech-
`
`nical opinions relating to U.S. Patent No. 8,082,501 (the ’501 Patent), and prior art
`
`references relating to its subject matter.
`
`2.
`
`I was previously retained by Bungie Inc. to provide opinions with re-
`
`spect to the ’501 Patent in relation to IPR2015-01319. I submitted two declarations
`
`in that proceeding: a first dated June 1, 2015 (Ex. 1002) (“First Declaration”), and a
`
`second dated March 4, 2015 (Ex. 1038) (“Second Declaration”). I was also deposed
`
`in that proceeding, a transcript of which was submitted as Ex. 2016. I stand by the
`
`testimony I gave in that proceeding, and incorporate it herein. I provide the follow-
`
`ing testimony to explain additional opinions I have with respect to the ’501 Patent
`
`and related prior art.
`
`I.
`
`ADDITIONAL GROUNDS BASED ON COMBINATIONS OF FUNK-
`HOUSER AND DURWARD
`3.
`In my First Declaration, I presented and explained three grounds based
`
`on combinations including Funkhouser (Ex. 1005) as the primary reference. See Ex.
`
`1002, ¶¶ 68-157. Since I submitted that first declaration, I am aware that a district
`
`court issued an order in which it construed various terms of the ’501 Patent. Ex.
`
`1032. One of the claim terms construed in that order was “participant condition,”
`
`which is recited in claim elements [1.2], [12.4], and [14.2]. Ex. 1032, 14-18. For
`
`
`
`2
`
`

`

`
`example, independent claim 1 recites “receiving, by the client device, position in-
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`formation associated with fewer than all of the other user avatars in an interaction
`
`room of the virtual space, from a server process, wherein the client device does not
`
`receive position information of at least some avatars that fail to satisfy a participant
`
`condition imposed on avatars displayable on a client device display of the client
`
`device.” Ex. 1001, 19:27-33 (emphasis added).
`
`4.
`
`The district court construed the term “participant condition” to mean “a
`
`condition set by the client.” Ex. 1032, 18. In construing the term, the court ex-
`
`plained:
`
`“conditions” constitute additional limits and that in the ‘501 and ‘998
`patents: “(1) the client receives position information for less than all
`of the other users’ avatars, and (2) at least some, but not necessarily
`all, of the avatars for which the client does not receive position infor-
`mation are ones that failed to satisfy a ‘participant condition’ or ‘con-
`dition.’” D. 63 at 25-26. The “conditions” contemplated in the ‘501
`and ‘998 patents then must be distinct from the server conditions de-
`scribed in the specification and are properly construed to be consistent
`with the user or client conditions contemplated by the specification,
`including user ID and “other variables in addition to proximity.” ‘690,
`D. 62-2 at 10. And while the specification explicitly considers that
`there may be a wide range of variables that a client might set, nothing
`in the patent record suggests that the server will set these additional
`conditions.
`
`
`
`3
`
`

`

`
`Id. at 17-18.
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`5. My previous declarations did not explicitly address this construction.
`
`Having considered the district court’s construction, its relationship to claim elements
`
`[1.2], [12.4], and [14.2], and the three Funkhouser-based grounds I set forth in my
`
`First Declaration, it is my expert opinion that a POSITA would have found claim
`
`elements [1.2], [12.4], and [14.2]—and thus independent claims 1, 12, and 14 over-
`
`all—obvious in light of the teachings of Funkhouser, particularly when considered
`
`in light of the teachings of Durward (Ex. 1008).
`
`6.
`
`As I described in my First Declaration, Funkhouser describes “[s]erver-
`
`based message culling [that] is implemented using precomputed line-of-sight visi-
`
`bility information.” Ex. 1005 at 03. Funkhouser’s “RING servers can cull messages
`
`using high-level geometric algorithms and knowledge regarding a multiplicity of
`
`highly dynamic entity attributes (e.g., location, orientation, velocity, etc.) and inter-
`
`action types (e.g., visibility, sound, collision, etc.). Ex. 1005 at 03. In this regard,
`
`Funkhouser’s client devices clearly receive messages (e.g., messages including up-
`
`dated position information) associated with fewer than all of the other user avatars,
`
`and Funkhouser’s servers accomplish this by culling messages based (at least in part)
`
`on the proximity of the first user’s avatar to the other users’ avatars.
`
`7.
`
`However, the district court’s construction additionally requires that the
`
`claimed client device not receive position information of at least some avatars that
`4
`
`
`
`

`

`
`fail to satisfy “other variables in addition to proximity.” Ex. 1032, 18. Though not
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`a focus of my previous explanation of the Funkhouser grounds in my First Declara-
`
`tion, Funkhouser also describes culling messages based on variables in addition to
`
`proximity, as required by the district court’s construction. Specifically, Funkhouser
`
`describes that an “extension” to its system uses “multiresolution simulation to reduce
`
`network traffic and client behavioral simulation processing.” Ex. 1005 at 07. Under
`
`multiresolution simulation, “time critical computing algorithms can be used to de-
`
`termine an ‘optimal’ set of messages to send to each client based on network con-
`
`nection bandwidths, workstation processing capabilities, and many other real-time
`
`performance factors . . . .” Id. Thus, in addition to proximity, Funkhouser’s servers
`
`can use real-time performance factors such as network connection bandwidths and
`
`workstation processing capabilities to cull messages.
`
`8. While not explicitly described by Funkhouser, a POSITA would have
`
`found it obvious that the client device would have set at least some of these real-time
`
`performance factors. For example, the client device is in the best position to assess,
`
`set, and communicate to the server the “workstation processing capabilities” of the
`
`client. At the time of the ’501 patent, a POSITA would have known that relevant
`
`workstation processing capabilities would have included, for example, the client
`
`workstation’s clock rate, amount of available memory, network interface details,
`
`
`
`5
`
`

`

`
`and/or ping time1. Much of this information is specific to each individual client
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`workstation and would not be easily determinable without it being provided by the
`
`client workstation.
`
`9.
`
`In fact, there are only two entities in Funkhouser’s system that could
`
`have possibly provided the workstation processing capabilities and other real-time
`
`performance factors described by Funkhouser as being “used to determine an ‘opti-
`
`mal’ set of messages to send to each client”: the RING server or the client. See Ex.
`
`1005 at 07. There are no other relevant entities. See, e.g., Ex. 1005, FIG. 5 (showing
`
`a system diagram containing on client workstations and RING servers). Without
`
`receiving this information from the client, the RING servers would be forced to es-
`
`timate the “workstation processing capabilities,” which would have been inefficient
`
`
`1 Ping time is the amount of time is takes a request to travel from the client
`
`device to a server plus the time is takes the corresponding response to travel from
`
`the server to the client. While ping time can be calculated from either the client or
`
`the server, it was common at the time of the ’501 patent to have the client perform
`
`these calculations. This would avoid burdening the server and allow the client to
`
`couple the calculated ping time with other client-specific information (e.g., clock
`
`rate and available memory size) to determine a maximum packet size to communi-
`
`cate to the server.
`
`
`
`6
`
`

`

`
`and prone to error. Therefore, designing Funkhouser’s system to have the client
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`send data representing the workstation processing capabilities to the RING servers
`
`would have been an obvious and predictable design choice. Furthermore, there are
`
`numerous prior art references (including Durward, which I separately discussed in
`
`my First Declaration) that provide relevant teachings confirming that a client device
`
`would have communicated at least some variables in addition to proximity to the
`
`server that would have been used to cull update messages sent from the server to the
`
`client.
`
`10. Durward (Ex. 1008) describes a three-dimensional virtual world similar
`
`to Funkhouser’s. Specifically, Durward’s system includes “a central database for
`
`defining one or more three-dimensional virtual spaces,” with the server communi-
`
`cating data to users “so that the user’s computer may display a portion of a selected
`
`virtual space on the user’s head mounted display.” Ex. 1008, 1:52-59. To “reduce[]
`
`bandwidth requirements,” Durward’s system culls messages in a similar manner as
`
`Funkhouser’s system. Id. at 4:12-29. “After initial position, motion, control and
`
`sound data is communicated to the users, only changes in the position, motion, con-
`
`trol and sound data is communicated thereafter.” Id. at 4:23-26. Like in Funkhouser,
`
`“visual relevant spaces determine which state changes are communicated to (or per-
`
`ceivable by) the users.” Id. at 4:54-56. The “user’s visual relevant space may be
`
`defined by the field of view of the virtual being and areas in close proximity to it (as
`7
`
`
`
`

`

`
`with virtual being 184), in which case the visual relevant space may move about the
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`virtual space as the perspective or position of the virtual being changes.” Id. at 5:13-
`
`18.
`
`11. Durward further teaches that “[e]ach visual relevant space may be fur-
`
`ther subdivided into one or more visual priority spaces.” Id. at 5:23-24. These visual
`
`priority spaces within each visual relevant space are akin to the multiresolution sim-
`
`ulation taught by Funkhouser. Specifically, Durward’s “visual priority spaces may
`
`be used to determine the update frequency of elements located within them.” Id. at
`
`5:27-29. In other words, different objects in a visual relevant space can be rendered
`
`at a different resolution (e.g., different update frequency) depending on whether they
`
`are located in a visual priority space. For example, “data for updating objects or
`
`sounds in one priority space may be communicated thirty times per second, whereas
`
`data for updating objects or sounds in another priority space may be communicated
`
`once per second. Id. at 6:65-7:2. “This reduces the amount of data that must be
`
`communicated to each user while maintaining realism of important elements.” Id.
`
`at 5:35-37, 6:62-65.
`
`12. Durward describes that “[c]ontrol data received from the users may be
`
`used . . . to specify visual and sound relevant spaces and their corresponding priority
`
`spaces, etc.” Id. at 6:27-34. In other words, in implementing its multiresolution
`
`
`
`8
`
`

`

`
`message culling architecture, Durward describes that its system relies upon control
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`data set by the client device (i.e., “from the user”) to the server.
`
`13. Based on the teachings of Durward, a POSITA would have found it
`
`obvious and predictable to implement Funkhouser’s multiresolution simulation ex-
`
`tension so that at least some of the “real-time performance factors” used by Funk-
`
`houser’s server to cull messages are set by the user and his/her client device. For
`
`example, as noted above, it would have been obvious to a POSITA to implement
`
`Funkhouser’s system such that the client device would set the “workstation pro-
`
`cessing capabilities.” A POSITA would have been motivated to implement Funk-
`
`houser’s system in this way, because, e.g., it would have permitted the user the abil-
`
`ity to control the amount of update messages it receives from the server according
`
`to the capabilities of the user’s system. As the user upgrades his/her client work-
`
`station, these changes could have be communicated to Funkhouser’s server by the
`
`client workstation in order to provide increased update frequency—and thus per-
`
`ceived resolution. And, as I described above, only the client and the RING servers
`
`could have provided the workstation processing capabilities and other real-time per-
`
`formance factors, so implementing Funkhouser’s system such that the clients pro-
`
`vide their workstation processing capabilities to the RING servers would have been
`
`an obvious design choice.
`
`
`
`9
`
`

`

`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`14. This obvious implementation of Funkhouser’s system would not alter
`
`
`
`the combinations of Funkhouser with Sitrick, Wexelblat, or Funkhouser ’93 that I
`
`described in my First Declaration. As I explained in my First Declaration, a POSITA
`
`would have relied upon Sitrick for its teachings related to “tools to allow a user to
`
`update the appearance of her avatar, and further discloses updating the geometry of
`
`avatars.” Ex. 1002, ¶¶ 75-77. A client providing one or more of the real-time per-
`
`formance factors to the RING servers, as I describe above, would not have impacted
`
`the combination of Funkhouser and Sitrick, as these real-time performance factors
`
`are unrelated to avatar customization.
`
`15. As I explained in my First Declaration, a POSITA would have relied
`
`upon Wexelblat for its teachings related to “an avatar be[ing] allowed to teleport
`
`between virtual rooms in the virtual world.” Ex. 1002, ¶¶ 134-141. A client provid-
`
`ing one or more of the real-time performance factors to the RING servers, as I de-
`
`scribe above, would not have impacted the combination of Funkhouser, Sitrick, and
`
`Wexelblat, as these real-time performance factors are unrelated to avatar teleporta-
`
`tion.
`
`16. As I explained in my First Declaration, a POSITA would have relied
`
`upon Funkhouser ’93 for its teachings related to “the client determining which ob-
`
`jects, including other user avatars, to display based not only on the orientation of the
`
`client avatar but also on a maximum number of avatars to be displayed based on the
`10
`
`
`
`

`

`
`performance capabilities of the client computer and desired frame rate of the dis-
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`played environment.” Ex. 1002, ¶¶ 142-157. A client providing one or more of the
`
`real-time performance factors to the RING servers, as I describe above, is related to
`
`the combination based on Funkhouser ’93 but is complimentary. Whereas the com-
`
`bination I described in my First Declaration with respect to Funkhouser ’93 relates
`
`to the client determining a maximum number of avatars to be displayed, the combi-
`
`nation I describe here with respect to Durward related to the server using workstation
`
`processing capabilities to limit the messages sent to the client. As I described in my
`
`First Declaration, it would have been obvious for both Funkhouser’s RING servers
`
`to use the workstation processing capabilities to limit the number of messages sent
`
`to the client and Funkhouser’s clients to further limit which objects, including other
`
`user avatars, to display. Ex. 1002, ¶¶ 147-152.
`
`17. Thus, in combinations with Durward, the Funkhouser grounds I set
`
`forth in my First Declaration with respect to the claims of the ’501 patent would
`
`remain the same except with respect to claim elements [1.2], [12.4], and [14.2]. With
`
`respect to claim element [1.2], [12.4], and [14.2], in addition to culling messages
`
`based on the position of the first user’s avatar, Funkhouser’s server would also cull
`
`messages based on workstation processing capabilities set by the user, as described
`
`above. In this updated combination that includes Durward, the first user’s client
`
`device would “not receive position information of at least some avatars that fail to
`11
`
`
`
`

`

`
`satisfy a participant condition [i.e., a condition based on client-set workstation pro-
`
`Supplemental Declaration of Michael Zyda
`re U.S. Patent No. 8,082,501
`
`cessing capabilities] imposed on avatars displayable on a client device display of the
`
`client device,” as recited in claims claim elements [1.2], [12.4], and [14.2].
`
`II. CONCLUSION
`I hereby declare that all statements made herein of my own knowledge
`
`18.
`
`are true and that all statements made on information and belief are believed to be
`
`true; and further that these statements were made with the knowledge that willful
`
`false statements and the like so made are punishable by fine or imprisonment, or
`
`both, under Section 1001 of Title 18 of the United States Code and that such willful
`
`false statements may jeopardize the validity of the application or any patents issued
`
`thereon.
`
`
`
`
`
`Date:
`
`
`
`
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`
`
`
`Michael Zyda
`
`
`
`
`
`12
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket