`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`SONY CORPORATION
`Petitioner
`
`v.
`
`STRAIGHT PATH IP GROUP, INC.
`(FORMERLY KNOWN AS INNOVATIVE COMMUNICATIONS
`TECHNOLOGIES, INC.)
`Patent Owner
`
`
`
`INTER PARTES REVIEW OF U.S. PATENT NO. 6,108,704
`Case IPR No.: To Be Assigned
`
`
`
`DECLARATION OF MARK E. CROVELLA, PH.D.
`
`
`
`
`
`
`
`
`SONY EXHIBIT 1004- Page 1
`
`

`

`
`
`TABLE OF CONTENTS
`
`I.
`
`PERSONAL AND PROFESSIONAL BACKGROUND ............................... 1
`
`II. MATERIALS REVIEWED AND CONSIDERED ........................................ 3
`
`III. PERSON OF ORDINARY SKILL IN THE ART .......................................... 4
`
`IV. THE BASICS OF NETWORK COMMUNICATION ................................... 5
`
`A. Assigning Addresses to Devices ................................................................... 7
`
`B. Mapping Addresses to Names ....................................................................... 9
`
`C. Locating Devices with Dynamically Assigned Network Addresses .......... 11
`
`D. Common Network Protocols ....................................................................... 15
`
`E. The Design of Network Communication Software Applications ............... 17
`
`F. Video Distribution Systems ........................................................................ 21
`
`V.
`
`SUMMARY OF THE ‘704 PATENT ........................................................... 23
`
`VI. CLAIMS 1, 11-12, 19, 22-23 AND 30 ARE INVALID IN LIGHT OF
`THE PRIOR ART IDENTIFIED IN SONY’S PETITION........................... 25
`
`A. Ground 1: The Microsoft Manual Discloses Each Limitation of Claim
`1. .................................................................................................................. 26
`
`B. Ground 2: The Microsoft Manual and Palmer Disclose Each Limitation
`of Claims 11-12, 19, 22-23, and 30. ........................................................... 37
`
`C. Ground 3: The Microsoft Manual, Palmer and Pinard Disclose Each
`Limitation of Claims 11-12, 19, 22-23, and 30. ......................................... 51
`
`D. Ground 4: The VocalChat References Disclose Each Limitation of
`Claims 1, 11-12, 19, 22-23, and 30. ............................................................ 56
`
`E. Ground 5: The VocalChat References in view of RFC 1541 Disclose
`Each Limitation of Claim 1. ........................................................................ 80
`
`F. Ground 6: The VocalChat References and Pinard Disclose Each
`Limitation of Claims 11-12, 19, 22-23, and 30. ......................................... 83
`
`G. Ground 7: Little-1994 and RFC 791 Disclose Each Limitation of Claim
`1. .................................................................................................................. 85
`
`H. Ground 8: Little-1994, RFC 791 and RFC 1541 Disclose Each
`Limitation of Claim 1. ................................................................................. 96
`
`I.
`
`Ground 9: Little-1994 and Little-1993 Disclose Each Limitation of
`Claims 11-12, 19, 22-23, and 30. ................................................................ 99
`
`
`
`- i -
`
`SONY EXHIBIT 1004- Page 2
`
`

`

`
`
`
`
`
`
`J. Ground 10: Little-1994 and Pinard Disclose Each Limitation of Claims
`11-12, 19, 22-23, and 30. .......................................................................... 111
`
`- ii -
`
`SONY EXHIBIT 1004- Page 3
`
`

`

`
`
`I, Mark E. Crovella, Ph.D., declare:
`
`1.
`
`I have been retained by Wolf, Greenfield & Sacks, P.C., counsel for
`
`Petitioner Sony Corporation (“Sony”), to submit this declaration in connection
`
`with Sony’s Petition for Inter Partes Review of Claims 1, 11-12, 19, 22-23, and 30
`
`of U.S. Patent No. 6,108,704 (“the ‘704 patent”). I am being compensated for my
`
`time at a rate of $450 per hour, plus actual expenses. My compensation is not
`
`dependent in any way upon the outcome of Sony’s Petition.
`
`I.
`
`PERSONAL AND PROFESSIONAL BACKGROUND
`
`2.
`
`I am Professor and Chair of the Department of Computer Science at
`
`Boston University. I received an undergraduate degree in Biology from Cornell
`
`University in 1982. I received a master’s degree in Computer Science from the
`
`University of Buffalo in 1989. I received a Ph.D. in Computer Science from the
`
`University of Rochester in 1994. The subject of my Ph.D. thesis was
`
`“Performance Prediction and Tuning of Parallel Programs.”
`
`3.
`
`From 1982 to 1984 I worked as a computer programmer for the State
`
`of Colorado. From 1984 to 1994 I was employed at Calspan Corporation, a
`
`research and development firm in Buffalo, NY, where I rose to the level of Senior
`
`Computer Scientist. My work at Calspan focused on development of experimental
`
`software and large-scale simulation software in support of contracts between
`
`Calspan and the U.S. Department of Defense.
`
`
`
`- 1 -
`
`SONY EXHIBIT 1004- Page 4
`
`

`

`
`
`4.
`
`In 1994, I joined the faculty of Boston University as an Assistant
`
`Professor of Computer Science. I was promoted to the rank of Associate Professor
`
`in 2000 and became a full Professor in 2006. Since 2013, I have served as Chair of
`
`the Department of Computer Science.
`
`5.
`
`I have been pursuing research in the area of computer networking
`
`since 1994. I have conducted research in a variety of areas related to the Internet
`
`and the World Wide Web. Among other areas, I have studied the efficient design
`
`of Web servers and content distribution systems; I have studied the statistical
`
`properties of Internet traffic; and I have made extensive measurements of Internet
`
`and corporate intranet infrastructure and the behavior of Internet and other network
`
`protocols. From 2007 to 2009 I was the Chair of ACM SIGCOMM (the Special
`
`Interest Group in Computer Communication), the main professional organization
`
`for scientists in the field of computer networking.
`
`6.
`
`I am co-author of Internet Measurement: Infrastructure, Traffic, and
`
`Applications (Wiley Press, 2006), and I am the author of over one hundred
`
`research papers on computer networks. I hold eight patents derived from my
`
`Internet-related research. I am an editor or past editor of the principal journals in
`
`the field of networking: Computer Communication Review, IEEE/ACM
`
`Transactions on Networking, Computer Networks, and IEEE Transactions on
`
`Computers.
`
`
`
`- 2 -
`
`SONY EXHIBIT 1004- Page 5
`
`

`

`
`
`7. My detailed employment background, professional experience, and
`
`list of technical papers and books are contained in my CV. (Ex. 1028.)
`
`8.
`
`I am familiar with the subject matter of this case. I consider myself an
`
`expert in networking, including network protocols, applications, and architecture.
`
`II. MATERIALS REVIEWED AND CONSIDERED
`
`9.
`
`In connection with my work on this matter, I have reviewed the ‘704
`
`patent (Ex. 1001) as well as the other documents listed on the following list:
`
`EXHIBIT
`
`DESCRIPTION
`
`1001
`
`U.S. Patent No. 6,108,704
`
`1014
`
`1015
`
`1016
`
`1017
`
`1018
`
`1019
`
`1020
`
`1021
`
`1022
`
`1023
`
`1024
`
`1025
`
`1028
`
`Microsoft Windows NT™ Version 3.5 TCPIP.HLP (“Microsoft
`Manual”)
`
`U.S. Patent No. 5,375,068 to Palmer et al.
`
`U.S. Patent No. 5,533,110 to Pinard et al.
`
`Little, T.D.C., et al., “Client-Server Metadata Management for the
`Delivery of Movies in a Video-On-Demand System,” First
`International Workshop on Services in Distributed and Networked
`Environments, June 27-28, 1994
`
`Little, T.D.C., et al., “A Digital On-Demand Video Service
`Supporting Content-Based Queries,” Proc. 1st ACM Intl. Conference
`on Multimedia, August 1993
`
`Droms, R., Dynamic Host Configuration Protocol, RFC 1541 (Oct.
`1993)
`
`Postel, J., Internet Protocol, RFC 791 (Sept. 1981)
`
`VocalChat Version 2.0 trouble.hlp (“Troubleshooting”)
`
`VocalChat Version 2.0 readme.txt (“Read Me”)
`
`VocalChat Version 2.0 User’s Guide (“User Guide”)
`
`VocalChat Version 2.0 info.hlp (“Info.”)
`
`VocalChat Version 2.0 voclchat.hlp (“Help File”)
`
`Curriculum Vitae of Prof. Mark E. Crovella
`
`
`
`- 3 -
`
`SONY EXHIBIT 1004- Page 6
`
`

`

`
`
`1029
`
`1030
`
`1031
`
`1032
`
`November 13, 2013 Screenshot of VocalChat software
`
`November 13, 2013 Screenshot of VocalChat software
`
`November 13, 2013 Screenshot of VocalChat software
`
`Straight Path’s Notice of Patent Priority Dates, In re Certain Point-to-
`Point Network Communication Devices and Products Containing
`Same, Inv. No. 337-TA-892 (filed Nov. 8, 2013)
`
`III. PERSON OF ORDINARY SKILL IN THE ART
`
`10.
`
`I am informed that prior art references should be understood from the
`
`perspective of a person of ordinary skill in the art to which the patent is related,
`
`based on the understanding of that person at the time of the patent’s priority date. I
`
`understand that a person of ordinary skill in the art is presumed to be aware of all
`
`pertinent prior art and the conventional wisdom in the art, and is a person of
`
`ordinary creativity. I have applied this standard throughout my declaration.
`
`11.
`
`I have been asked to provide my opinion as to the state of the art as of
`
`February 1995 because the Patent Owner alleges that the challenged claims of the
`
`‘704 patent are entitled to a conception date of February 22, 1995. (Ex. 1032.) In
`
`my opinion, a person of ordinary skill in the art related to the ‘704 patent at that
`
`time would have had at least a B.S. in Computer Science or the equivalent, along
`
`with several years of computer programming experience including experience with
`
`computer networking and networked applications, such as VoIP or other
`
`applications that present graphical user interfaces. This person would have been
`
`capable of understanding and applying the prior art references discussed herein.
`
`
`
`- 4 -
`
`SONY EXHIBIT 1004- Page 7
`
`

`

`
`
`12. My opinions set forth herein are from the perspective of a person of
`
`ordinary skill in the art, as set forth above.
`
`IV. THE BASICS OF NETWORK COMMUNICATION
`
`13. A computer network provides a mechanism for computers to
`
`communicate. Most networks operate in accordance with protocols that allow one
`
`device to send messages directly to another device. Supporting such point-to-point
`
`communication requires a mechanism by which a device sending a message can
`
`indicate which device or devices are to respond to the message. For this purpose,
`
`most widely used networks operate according to protocols that support network
`
`addresses. Each device may have a network address which, when included in a
`
`message, indicates either that the message is to preferentially go to that device or
`
`that other devices should ignore the message.
`
`14. An analogy can be drawn between a traditional telephone network and
`
`a modern computer network. In a traditional telephone network, the relevant
`
`“address” is the telephone number associated with a user. Just like telephone
`
`numbers within an area code, network addresses are typically unique, in that
`
`generally no two devices on the same network have the same network address.
`
`This ensures that when a message is sent by one device into a network, all of the
`
`devices on the network know which device is intended to receive and process the
`
`message.
`
`
`
`- 5 -
`
`SONY EXHIBIT 1004- Page 8
`
`

`

`
`
`15.
`
`In February 1995 (and still today), traffic on the Internet utilized the
`
`Internet Protocol (“IP”) to identify devices. This protocol was developed in the
`
`1970s and 1980s, leading to the “Internet Protocol Suite” standard in 1982, which
`
`formed the basis of the modern Internet and was also used in other computer
`
`networks. Historically, aspects of network communication have been standardized
`
`by the Internet Engineering Task Force (“IETF”), which codifies standards in
`
`documents called “Requests for Comments” or “RFCs” (the title of which is a
`
`historical artifact and is not to be taken literally, as these documents were widely
`
`distributed and used by engineers in designing networks and network products).
`
`16. The Internet Protocol was defined in RFC 791, which was published
`
`in September 1981.1 The protocol identified a device using a number, which is
`
`commonly represented as four values ranging from 0 to 255. For example, a
`
`network address using the Internet Protocol, also called an “IP address,” might be
`
`151.207.247.130. The Internet Protocol provided a way for a device having one IP
`
`address to direct data to another device with a different IP address.
`
`
`1 Ex. 1020 at 1 (“The internet protocol provides for transmitting blocks of data
`
`called datagrams from sources to destinations, where sources and destinations are
`
`hosts identified by fixed length addresses.”).
`
`
`
`- 6 -
`
`SONY EXHIBIT 1004- Page 9
`
`

`

`
`
`17. Most communications over a network involve some back and forth
`
`between devices. To acknowledge that a message was received, a device receiving
`
`a message is likely to need to communicate back to the sending device. To support
`
`such back and forth, many protocols, including the IP protocol, specify that a
`
`sending device must provide its network address to the receiving device.
`
`18.
`
`In sum, to communicate over a computer network in February 1995, a
`
`device needed two things: (1) its own network address and (2) the network address
`
`of other devices with which it wanted to communicate.
`
`A. Assigning Addresses to Devices
`
`19. As of February 1995, devices were assigned either static or dynamic
`
`network addresses. A device assigned a static network address retained that
`
`address each time it connected to the network. A device assigned a dynamic
`
`network address, on the other hand, received a potentially different network
`
`address each time it connected to the network.
`
`20. Prior to February 1995, most private users connected to the Internet
`
`via an Internet Service Provider (“ISP”). The ISP typically owned a collection of
`
`IP addresses, and would dynamically assign one of the addresses to a subscriber’s
`
`computer when the computer connected to the Internet.
`
`
`
`- 7 -
`
`SONY EXHIBIT 1004- Page 10
`
`

`

`
`
`21. Dynamic addressing was also well known for use on private computer
`
`networks (e.g., private intranets). Similar to the dynamic assignment of IP
`
`addresses on the Internet, addresses in a private network were dynamically
`
`assigned to be unique within the private network. Usually there was a range of
`
`valid private network addresses, and a device joining the network was assigned one
`
`of the addresses from the valid range.
`
`22. Starting around 1993, a framework for dynamically assigning network
`
`addresses was standardized, called Dynamic Host Configuration Protocol, or
`
`DHCP. (Ex. 1019.) Typically a device within a computer network (e.g., the
`
`Internet or a private intranet) acted as a DHCP server and assigned network
`
`addresses to devices joining the network. A device leaving the network released
`
`its assigned network address back to the DHCP server so that the server could re-
`
`assign that network address to another device that later joined the computer
`
`network. In some cases, a device periodically renewed (or reregistered) its address
`
`with the DHCP server to enable the DHCP server to distinguish between devices
`
`that were still using their assigned addresses and those that were not. This allowed
`
`the DHCP server to reassign the addresses not being used to other devices joining
`
`the network.
`
`
`
`- 8 -
`
`SONY EXHIBIT 1004- Page 11
`
`

`

`
`
`23. DHCP techniques were in use both on private networks and on the
`
`Internet before February 1995. In each case, the DHCP server assigned an address
`
`to the user dynamically upon connection to the network.
`
`B. Mapping Addresses to Names
`
`24. As I mentioned above, IP addresses were numbers. For example, the
`
`IP address for CNN’s website could be: 157.166.226.25. Because these complex
`
`network addresses were difficult to remember, there existed a need to link the
`
`addresses with more easily remembered names.
`
`25. This “name resolution” problem was not unique to computer
`
`networks. Long before the development of computer networks, the telephone
`
`industry recognized that it was unreasonable to expect users to remember or keep
`
`track of more than a handful of telephone numbers. The telephone industry
`
`therefore mapped telephone numbers to names, and provided solutions for
`
`translating names to telephone numbers. One solution was the directory assistance
`
`operator. A directory assistance operator had access to a database that mapped
`
`network addresses (e.g., telephone numbers) to devices (e.g., a particular user’s
`
`telephone). Callers did not need to keep track of every telephone number they
`
`might want to call; they simply called the directory assistance operator and asked
`
`for the callee’s number.
`
`
`
`- 9 -
`
`SONY EXHIBIT 1004- Page 12
`
`

`

`
`
`26. Similar solutions to the “name resolution” problem were developed in
`
`the context of computer networks. One example is the Domain Name System
`
`(DNS) developed in the 1980s to translate IP addresses into domain names.2 The
`
`DNS mapped domain names (e.g., www.cnn.com) to IP addresses (e.g.,
`
`157.166.226.25). As part of a computer’s browser making a connection to a web
`
`site, it would access a “DNS server” that, like a telephone book, mapped domain
`
`names to IP addresses. Transparent to the user, the DNS server provided the
`
`computer’s browser with the IP address of the requested domain name, thereby
`
`allowing the browser to access the server hosting the website.
`
`27. Microsoft implemented a similar name resolution solution in the
`
`context of a local computer network. The manual for Microsoft TCP/IP for
`
`Windows NT 3.5 (“the Microsoft Manual”) described the “Windows Internet
`
`Name Service” (“WINS”) (Ex. 1014), which I discuss below in Grounds 1-3.
`
`28. The WINS technology allowed a user running Windows NT 3.5 to use
`
`easily-remembered names to access other computers or devices on a computer
`
`network. For example, it was desirable to assign easily remembered names to
`
`different printers available on a network (e.g., “3rd Floor Printer,” “4th Floor Color
`
`Printer”), rather than requiring a user to remember an IP address to select a
`
`particular printer connected to the network.
`
`
`2 RFC 1034, November 1987 (http://tools.ietf.org/html/rfc1034).
`
`
`
`- 10 -
`
`SONY EXHIBIT 1004- Page 13
`
`

`

`
`
`29. According to Microsoft, WINS “solve[d] the problems that occur with
`
`name resolution in complex internetworks,” and provided a distributed database for
`
`querying “computer name-to-IP address mappings in a routed network
`
`environment.” (Ex. 1014 at 66.)3 Like DNS, WINS was essentially a directory
`
`assistance operator that provided a first device with the network address of a
`
`second device, based on a name associated with the second device, analogous to
`
`providing a first user the telephone number for a second user based on the second
`
`user’s name.
`
`C. Locating Devices with Dynamically Assigned Network Addresses
`
`30. As discussed above, dynamically assigning network addresses was
`
`common prior to February 1995. There were (and are) several benefits to
`
`dynamically assigning network addresses. Use of dynamic addresses was (and is)
`
`administratively simpler, since client devices could usually be provided with
`
`dynamically assigned addresses without any action being taken on the part of the
`
`client device user. Static addresses, on the other hand, required a user or network
`
`administrator to configure the device with the appropriate static address and to
`
`keep track of the static addresses that were already assigned to other devices on the
`
`network.
`
`
`3 Citations are to the page numbers that Sony added to the manual.
`
`
`
`- 11 -
`
`SONY EXHIBIT 1004- Page 14
`
`

`

`
`
`31.
`
`In addition, dynamic addresses were provided to devices on the basis
`
`of need, rather than by assignment of a static address whose usage must be
`
`allocated and tracked long-term. This was (and is) particularly useful in mobile
`
`environments, since a single device (e.g., a laptop computer) could have connected
`
`to different networks over time and could be given a dynamic address each time it
`
`connects to a network. The address assigned by a particular network to the mobile
`
`device at one time would be assigned to other devices that connect to that
`
`particular network at other times. Use of such a mobile device with static
`
`addresses, on the other hand, would be administratively burdensome for both users
`
`and network administrators because a network may have an addressing scheme that
`
`is inconsistent with the static address assigned to the device, or because the
`
`network may already be using that address for another device connected to the
`
`network. Therefore, a mobile device with a static address cannot be expected to
`
`smoothly connect to a new network.
`
`32. Dynamically assigning network addresses, however, also introduced a
`
`further complication to the “name resolution” problem: how to accurately map
`
`device names to network address that are constantly changing. This was akin to a
`
`telephone system in which users received new telephone numbers each time they
`
`hung-up the phone.
`
`
`
`- 12 -
`
`SONY EXHIBIT 1004- Page 15
`
`

`

`
`
`33. Solving this added complication required developing mechanisms that
`
`enabled devices, such as computers, to update a name resolution database as new
`
`network addresses were assigned to devices on a computer network. The computer
`
`network industry developed these mechanisms prior to February 1995.
`
`34. For example, WINS mapped dynamic network addresses to device
`
`names. As each device connected to the network, a DHCP server assigned it a
`
`dynamic network address. (Ex. 1014 at 60-61.) The device then registered its
`
`name and its dynamically assigned network address with the WINS directory
`
`server. (Ex. 1014 at 68-70.) WINS thus maintained a mapping of dynamically
`
`assigned network addresses to device names that was updated each time a device
`
`connected to the network (i.e., each time a device was assigned a new dynamic
`
`network address).
`
`35. Given its use in a dynamic addressing environment, WINS needed to
`
`update its database regularly and included a technique for doing so. Each device
`
`registered its name with the WINS server. Upon the device disconnecting from the
`
`computer network, it would send a “release” message informing the server that the
`
`name was no longer being used and the computer associated with the name was no
`
`longer connected to the computer network. (Ex. 1014 at 69-70.) The WINS server
`
`would then update its database to reflect the fact that the name was released. (Id.)
`
`
`
`- 13 -
`
`SONY EXHIBIT 1004- Page 16
`
`

`

`
`
`36. Because computers occasionally disconnected from the computer
`
`network without properly shutting down, the release process was not perfect.
`
`WINS therefore also required computers to periodically “renew” or reregister their
`
`names with the server. (Id.) If a device did not renew or reregister its name within
`
`an allotted period of time, WINS marked the name as released and available for
`
`use. (Id.) This technique ensured that WINS’s mapping of computer names and
`
`network addresses was relatively (although not necessarily completely) current and
`
`accurate.
`
`37. WINS’s technique for ensuring database accuracy was not unique to
`
`Microsoft. As I described above, the DHCP protocol described a process by which
`
`client devices that were assigned dynamic network addresses would “release” the
`
`addresses back to the DHCP server when the client “no longer need[ed] the
`
`address,” i.e., when the client logged-off the computer network. (Ex. 1019 at 11,
`
`16, 35.) The DHCP protocol also used a similar “lease” technique in which client
`
`devices were assigned their dynamic network address for only a limited period of
`
`time, but could subsequently request an extension or renewal of their leases. (Id. at
`
`11.)
`
`
`
`- 14 -
`
`SONY EXHIBIT 1004- Page 17
`
`

`

`
`
`D. Common Network Protocols
`
`38. As described above, the IP protocol facilitates the transmission of
`
`messages from a source computer to a destination computer identified by an IP
`
`address. In the majority of networks, messages are sent in “packets,” which are
`
`blocks of data combined with routing and transport information in addition to the
`
`data being communicated (i.e., the “payload”). In the case of the IP protocol, each
`
`packet includes a header, which provides information about the packet. As per
`
`RFC 791, the IP header comprises at least 160 bits and looks like this:
`
`
`
`(Ex. 1020 at 11.)
`
`39. The numbers across the top provide a scale to make it easy to
`
`understand how many bits are in each field. For example, the Source Address and
`
`Destination Address fields utilize 32 bits of data (8 bits for each of the four values
`
`in the IP address). As the figure demonstrates, each IP packet contained the IP
`
`address of the device that sent the message as well as the IP address of the device
`
`that was the intended recipient of the message.
`
`
`
`- 15 -
`
`SONY EXHIBIT 1004- Page 18
`
`

`

`
`
`40. Although the IP protocol could be used alone to transmit data across a
`
`network such as the Internet, there are multiple reasons why this is undesirable.
`
`Network congestion or other unpredictable network behavior can result in IP
`
`packets being undelivered, duplicated, or delivered out of order. To this end, a
`
`number of “transport protocols” have been developed which include various
`
`degrees of error detection and congestion control functionality. The transport
`
`protocol most commonly used for reliable communication over IP is the
`
`Transmission Control Protocol (TCP). This pairing is usually written as “TCP/IP.”
`
`For example, all web browsers use TCP/IP when connecting to the World Wide
`
`Web, and e-mail servers utilize TCP/IP to deliver e-mail across the Internet.
`
`41. Other transport protocols include the User Datagram Protocol (UDP),
`
`which is similar to TCP but is simpler and has reduced error checking capabilities.
`
`In particular, whereas TCP will resend a packet that has failed to reach its
`
`destination, UDP will simply ignore the dropped packet. This makes UDP
`
`particularly suitable for real-time applications such as online gaming or Voice over
`
`IP (described below) in which time sensitivity means that losing a packet of data at
`
`the destination is preferable to the system having to wait for the packet to be re-
`
`delivered.
`
`
`
`- 16 -
`
`SONY EXHIBIT 1004- Page 19
`
`

`

`
`
`E.
`
`The Design of Network Communication Software Applications
`
`42. The above-described technical developments in computer network
`
`communication provided the foundation upon which computer programmers
`
`developed software applications that allowed for communication between network
`
`devices. These developments were well underway prior to February 1995.
`
`43. The Microsoft Manual, for example, described software (Microsoft
`
`TCP/IP) that leveraged the use of DHCP servers and name-resolution techniques to
`
`enable “communication across interconnected networks made up of computers
`
`with diverse hardware architectures and various operating systems.” (Ex. 1014 at
`
`9.) Once this software was installed on a server running the Windows NT 3.5
`
`operating system, “additional applications and connectivity utilities provided by
`
`Microsoft and other developers” could be used to leverage the communication
`
`capabilities of Microsoft TCP/IP. (Ex. 1014 at 11.)
`
`44. The additional applications and connectivity utilities referenced in the
`
`Microsoft Manual would have interfaced with Microsoft TCP/IP and the Windows
`
`NT 3.5 operating system through the use of an application programming interface
`
`(“API”). (Ex. 1014 at 20.) An application that conformed with the API would
`
`have functioned properly with Microsoft’s software (e.g., Microsoft TCP/IP for
`
`Windows NT 3.5) and would have leveraged that software’s underlying network
`
`communication capabilities (e.g., WINS and DHCP). The availability of such
`
`
`
`- 17 -
`
`SONY EXHIBIT 1004- Page 20
`
`

`

`
`
`networking software, accessible through an API, as part of a computer’s operating
`
`system, was intended to expand the availability of networked computer
`
`applications because it allowed programmers to more simply write applications
`
`while still taking advantage of all that networking communication functionality.
`
`45. As of February 1995, many applications existed that interfaced with
`
`Microsoft TCP/IP for Windows NT. (Ex. 1014 at 20 (describing Windows
`
`Sockets), 284-89 (identifying Windows Sockets Applications).) These
`
`applications allowed users to access the underlying network communication
`
`capabilities, often through a user interface.
`
`46. As the name implies, a user interface was an interface to a computer
`
`with which a user would interact to control software running on the computer.
`
`User interfaces were physical (e.g., the standard computer keyboard and mouse) as
`
`well as visual. Visual user interfaces, often called “graphical user interfaces,” were
`
`provided to a user through a display (e.g., a computer monitor) and allowed a user
`
`to select different actions for the software to perform.
`
`47. User interfaces for network communication software applications
`
`were particularly useful. These interfaces allowed a user to identify devices on a
`
`network that were available for communication and also allowed the user to select
`
`the type of data that was being sent to those devices.
`
`
`
`- 18 -
`
`SONY EXHIBIT 1004- Page 21
`
`

`

`
`
`48. Though user-facing functionality was intended to be added via
`
`network communication software applications, even the underlying networking
`
`software provided some functionality that might be accessed by a user. The
`
`Microsoft Manual, for example, described a user interface for Microsoft TCP/IP
`
`printing. This interface, below, allowed a user to print a document at different
`
`printers connected to different computers on a network. (Ex. 1014 at 219-20.)
`
`Ex. 1014 at 224.
`
`
`
`49. The TCP/IP printing user interface was basic. As of February 1995,
`
`many other user interfaces existed that provided users with increased control and
`
`utilized more user-friendly graphical icons. For example, U.S. Patent No.
`
`5,375,068 (“Palmer”) describes a videoconferencing application, called
`
`“DECspin,” that was designed for computer workstations including those using the
`
`Windows NT operating system. (Ex. 1015 at 7:9-11.) The software described in
`
`Palmer generated a user interface that allowed a user to select up to seven different
`
`workstations with which to establish a videoconference call. (Id. at 8:32-47;
`
`10:18-32; 10:66-11:16; 13:5-8.) Palmer’s user interface is shown below:
`
`
`
`- 19 -
`
`SONY EXHIBIT 1004- Page 22
`
`

`

`
`
`
`50. Similarly, U.S. Patent No. 5,533,110 to Pinard et al. (“Pinard”)
`
`disclosed a software application for voice communication across a network. (Ex.
`
`1016.) It too generated a user interface from which a user could select different
`
`individuals to call:
`
`
`
`- 20 -
`
`
`
`SONY EXHIBIT 1004- Page 23
`
`

`

`
`
`51. As the above two user interface examples demonstrate, software
`
`programmers prior to February 1995 had already recognized the value of software
`
`that transmitted voice data over a network. Both Pinard and Palmer describe user
`
`interfaces that could be used to control such software, but the underlying
`
`communication software was developed prior to February 1995 as well. Such
`
`software implemented what was sometimes called Voice over IP or “VoIP.”
`
`52. For example, prior to February 1995, an Israeli company, VocalTec
`
`Ltd., had published manuals describing a VoIP software product called VocalChat
`
`that utilized the name resolution techniques developed in the computer networking
`
`field to establish voice communication between users connected to a network. I
`
`discuss VocalChat in more detail in Grounds 4-6 below.
`
`F. Video Distribution Systems
`
`53.
`
`In addition to developing software applications that allowed for
`
`communication between network devices in the context of general network
`
`computing (e.g., the Microsoft Manual) and VoIP (e.g., VocalChat), technical
`
`developments in computer network communication provided the foundation upon
`
`which distributed video systems were created. These systems existed prior to
`
`February 1995 and allowed a user to access content that was distributed on