throbber
41. If a process communicates using the TCP or UDP protocol (a higher level
`
`protocol running on top of the IP protocol), each process communication channel
`
`(usually called a ‘socket’) is assigned a ‘port’ (a 16-bit number) that uniquely
`
`identifies that channel, and thus, the ‘process’ within a given ‘processing unit’. For a
`
`process communicating using the TCP or UDP protocol, the network protocol
`
`address consists of its processing unit IP address and the port number assigned to the
`
`process communication socket. 12.34.56.78:1111 is an example of such an address,
`
`where 12.34.56.78 is the processing unit IP address, and 1111 is the process port
`
`number.
`
`42. Some TCP or UDP communication applications use fixed default port
`
`numbers. For example, Web (HTTP) servers use the TCP port 80 by default, and
`
`POP3 mail servers use the TCP port 110 by default. As a result, in order to instruct a
`
`Web browser to connect to a Web server running on a certain computer (‘processing
`
`unit’), one can specify just the IP address of that computer: if the port number is not
`
`specified, the Web browser will connect to the port number 80 by default. The Web
`
`URL http://12.34.5678 is the same as the http://12.34.56.78:8O URL.
`
`Page 24
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 26
`
`

`
`43. When an application has a default port number specified, a name server
`
`may contain a mapping of an application process name into the IP address of the
`
`processing unit (as opposed to a mapping into the full process address including the
`
`process port number). The name www.company.com can be mapped to the IP
`
`address 12.34.56.78, and when this name is used in the http://www.company.com
`
`URL, the Web browser will add the port 80 to the IP address 12.34.56.78.
`
`44. If all processes registered with a name server use the same default port
`
`number, the name servers may store just the IP address of the registered processes
`
`(i.e. the network address of the ‘processing unit’). The preferred embodiment of the
`
`‘704 Patent, the WebPhoneTM product (‘704 Patent Col. 3, lines 6-10) used the fixed
`
`TCP port 21845. The ‘connection server’ of the WebPhoneTM service could register
`
`either the full process network address (12.34.56.77:21845), or just the computer IP
`
`address (12.34.56.78), relying on the fact that the port number (21845) is fixed and it
`
`is known to the caller process (some other WebPhoneTM application instance). It is
`
`likely that this was the cause of the terminology confusion mentioned above.
`
`Page 25
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 27
`
`

`
`45. For NetBIOS—over-TCP, the process network address consists of the
`
`‘processing unit’ IP address and the ‘process’ registered name (this can be shown as
`
`somename AT 12.34.56. 78). When a datagram is sent to a NetBIOS ‘process’, it is
`
`delivered over the network to its ‘processing unit’ IP address, to the fixed UDP port
`
`number 138. The sent data packet contains the target ‘process’ name and the
`
`datagram itself. The NetBIOS—over-TCP software running on the target ‘processing
`
`unit’ receives all packets delivered to the port 138. It uses the supplied process name
`
`to deliver the datagram to the target ‘process’.
`
`46. There can be confusion about the contents of NetBIOS Name Server
`
`records: do they contain only IP addresses of ‘processing units’, or do they contain
`
`full network addresses of the registered ‘processes’? In reality, they contain both. A
`
`record mapping the process “Jim Files” to the IP address l.l.l.l contains a mapping
`
`from a process name to its processing unit address. But because the process full
`
`network address is “Jim Files” AT l.l.l.l, the same record also contains a mapping
`
`from a process name to the process network address: in NetBIOS—over-TCP, the
`
`process name itself is a part of the process network address.
`
`Page 26
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 28
`
`

`
`47. Conclusion. The Patent Owner’s Expert has made the following
`
`statements: “NetBIOS merely tracks the registration of a computer or node, and does not
`
`store any information relating to processes running on that computer or node” (Exhibit
`
`2018, p.26 and p.34), and “WINS only tracks registration of a computer, and does not
`
`store information in its database relating to processes running on that computer” (Exhibit
`
`2018, p.46), and “Lastly, the use of "PC1" and "PC2" further demonstrates that WINS
`
`merely coordinates queries regarding computers, not processes running on those computers”
`
`(Exhibit 2018, p.48), and “It [WINS] also does not store information regarding a process
`
`running on the computer” (Exhibit 2018, p.49), and “This "process," as discussed above,
`
`is a process or program running on a computer, not merely the associated computer itself.
`
`WINS only discloses the registration of a computer” (Exhibit 2018, p.55). All these
`
`statements are incorrect, as NetBIOS Name Servers (including WINS) contain
`
`registrations for process names. While many names may be mapped to the same IP
`
`address (many registered processes running on the same computer), each mapping in
`
`a NetBIOS Name Server includes the full process network address, as the registered
`
`name is a part of that address. I present an example of that mapping is Section 75.
`
`Page 27
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 29
`
`

`
`IX. Dynamic Process Addresses: Not a limitation.
`
`48. Claim. The Patent Owner and the Patent Owner’s Expert stated repeatedly
`
`that a requirement for a process to receive (get assigned) a network protocol address
`
`“following connection to the network” is an important limitation of the ‘704 Patent
`
`Claims. ‘‘In the current inter partes review, the Board stated that "the limitation ‘connection to
`
`the computer network’ was given the narrow construction to require a dynamic element" in the
`
`reexamination proceedings, and then determined that the claims did not require dynamic
`
`addressing (Decision at 9-10). I do not agree with this statement and decision, for the
`
`dynamic element is incorporated into the ‘704 claims via the language "following connection
`
`to the computer network." (See Ex. 2005, Notice of Intent to Issue Ex Parte Reexamination
`
`Certificate at 2-3 (emphasis added)). The fact that a network protocol address is assigned to
`
`a process upon its connection to the network is, by definition, dynamic address allocation.”
`
`(Mayer-Patel Declaration, Exhibit 2018, p.18).
`
`49. As noted in Section VIII of this Declaration, the ‘704 Patent uses only the
`
`term ‘process’ in its Claims. The Patent Owner’s Expert even tried to show that the
`
`‘704 Patent Description is also talking about the ‘process’ (though it does not use
`
`Page 28
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 30
`
`

`
`that term): “20. The specification also confirms that the claimed process is a computer
`
`program, rather than the computer itself: "The first processing unit 12 may operate the
`
`disclosed point-to-point Internet protocol by a computer program described hereinbelow in
`
`conjunction with FIG. 6, which may be implemented from compiled and/or interpreted source
`
`code in the C++ programming language and which may be downloaded to the first processing
`
`unit 12 from an external computer. The operating computer program may be stored in the
`
`memory 16, which may include about 8 MB RAM and/or a hard or fixed drive having about
`
`8MB." (’704 Patent at 3:39-47 (emphasis added)). This disclosure corresponds with the
`
`common understanding of the term "process." To one of ordinary skill in this art, the term
`
`"process" as used in the claims conveys a process or computer program running on a
`
`computer, rather than the computer itself.” (Mayer-Pate1Dec1aration, Exhibit 2018,
`
`p.10-l 1). I agree with the Patent Owner’s Expert that the ‘704 Patent Claims are
`
`using only the term ‘process’. The ’704 Patent Claims talk about the “process
`
`network protocol addresses,” and not about “process unit network protocol
`
`addresses” or “computer network protocol addresses.” The difference was explained
`
`in Section VIII of this Declaration.
`
`Page 29
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 31
`
`

`
`50. The ‘704 Patent Claim 1 uses the phrase “a network protocol address
`
`received by the first process following connection to the computer network,” while
`
`the Claims 2,4, and 32 specify a process address received “following connection” to
`
`the network, and the Claims 33 and 38 specify a process address received “upon
`
`connection to the computer network.”
`
`51. I agree with the Patent Owner’s Expert that a process is a running instance
`
`of an application, which is created anew every time when an application starts: “Q.|f
`
`a program is started again, is a new process created? A. Generally that is true, yes.”
`
`(Mayer-Patel Deposition, Exhibit 1022, p.l6:5-7). Such a dynamic entity gets its
`
`network address dynamically, too. Generically speaking, a process gets its network
`
`address when it “connects to the networ ”, i.e. when a process uses the Operating
`
`System controlling its ‘processing unit’ to prepare a network communication
`
`channel the process can use. The Patent Owner’ s Expert provided an even more
`
`restricted definition: “That process would receive a network protocol address when it uses
`
`the operating system in order to make a connection to some other process on some other
`
`computer.” (Mayer-Patel Deposition, Exhibit 1022, p.22:l5-19).
`
`Page 30
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 32
`
`

`
`52. As the Patent Owner’s Expert has confirmed, there is no way for a process
`
`to receive a “network protocol address” other than “upon/following connection to
`
`the computer network.” All process network protocol addresses are assigned
`
`dynamically, after the process (a running instance of an application) has started and
`
`when it uses the operating system to “connect to the network.” This is true for any
`
`process, whatever communication system or interface (NetBIOS, ‘sockets’, or any
`
`other) that process is using.
`
`53. Conclusion. I cannot agree with the Patent Owner that “process receiving
`
`a network protocol address following a connection to the computer networ ” is a
`
`limitation not disclosed in NetBIOS, or that it is a limitation at all. I similarly cannot
`
`agree with the Patent Owner that “processes having dynamically assigned network
`
`protocol addresses” (‘704 Patent, Claim 33) is a limitation not disclosed in NetBIOS,
`
`or that it is a limitation at all.
`
`X. Dynamic Addressing of Processing Units
`
`54. The Patent Owner and the Patent Owner’ s Expert pointed to the
`
`Description part of the ‘704 Patent which uses the term ‘processing unit’, as opposed
`
`Page 31
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 33
`
`

`
`to the term ‘process’ used in the ‘704 Patent Claims. They refer to the Description
`
`sections which talk about dynamic assignment of network addresses to processing
`
`units: “27. The specification also explicitly incorporates dynamic addressing into the claimed
`
`system. The Background of the patent explains a problem in the prior art as the following:
`
`Permanent IP addresses [i.e., ‘static’ addresses] of users and devices accessing the Internet
`
`readily support point-to—point communications of voice and video signals over the Internet...
`
`Due to the dynamic nature of temporary IP addresses of some devices accessing the
`
`Internet, point-to-point communications in realtime of voice and video have been generally
`
`difficult to attain. (’704 Patent at 1:48-56). 28. The descriptions of the patented invention also
`
`explicitly describe dynamic, rather than static, addressing: "When either of the processing
`
`units logs on to the Internet via a dial-up connection, the respective unit is provided a
`
`dynamically allocated IP address by a connection service provider." (’704 Patent at 5:21-23).
`
`The figures of the patent also specify that the system utilizes dynamic addressing: "As shown
`
`in FIG. 1, the disclosed point-to-point Internet protocol and system operate when a callee
`
`processing unit does not have a fixed or predetermined IP address." (’704 Patent at 5:15-17).
`
`The Patent lastly provides the following conclusion:
`
`Realtime point-to—point communication of audio signals over the Internet, as well as video and
`
`Page 32
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 34
`
`

`
`voicemail, may thus be established and supported without requiring permanent IP addresses
`
`to be assigned to either of the users or processing units. For the duration of the realtime
`
`point-to-point link, the relative permanence of the current IP addresses of the processing units
`
`is sufficient. (704 Patent at 7:32-38).” (Mayer-Patel Declaration, Exhibit 2018, pp. 19-
`
`20).
`
`55. As noted in Section VIII of this Declaration, the term ‘processing unit’ is
`
`not used in any of the ‘704 Patent Claims, and in my opinion, the ‘processing unit
`
`network addresses’ are not relevant to the ‘704 Patent Claims, which discuss only
`
`the ‘process network protocol addresses’. Nonetheless, I have decided to review the
`
`Patent Owner’s and the Patent Owner EXpert’s statements about dynamic address
`
`assignment to processing units being incompatible with the NetBIOS references.
`
`56. The ‘Dynamically Assigned IP address’ Terminology. The NetBIOS
`
`was designed in early 1980s, and the NetBIOS—over-TCP standards (RFC1001/ 1002)
`
`were published in March 1987 (Exhibit 1003). At that time automated mechanisms
`
`to assign IP addresses to ‘processing units’ (devices and computers) had already
`
`emerged. The BOOTP protocol standardized in RFC951 was published in September
`
`Page 33
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 35
`
`

`
`1985. At that time the term ‘dynamically assigned’ was not in use yet: while BOOTP
`
`implements what we now call ‘dynamically assigned IP addresses’ the word
`
`‘dynamically’ is not used anywhere in the RFC951 document. Only when the
`
`BOOTP protocol eventually had evolved into the DHCP protocol (standardized in
`
`RFC1531 in October 1993), did the term ‘dynamically configured hosts’ begin to be
`
`introduced. Abbreviated (and technically incorrectl) notion of ‘dynamically assigned
`
`IP address’ appeared even later than that. It is not surprising that the ‘dynamically
`
`assigned IP address’ notion does not appear in the RFC1001/RFC1002 documents
`
`published six years earlier, in March 1987.
`
`57. No limitation to static IP addresses. The NetBIOS—over-TCP was
`
`designed with a clear vision that in its target environment (office networks)
`
`computer network addresses were not assigned permanently. The
`
`RFC1001/RFC1002 standard does not contain anything that would limit its usage to
`
`1 It is incorrect because dynamic network configuration requires assignment not only of a host IP address, but, as a
`
`minimum, of the IP network ‘mask’, and of the ‘default gateway’ IP address.
`
`Page 34
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 36
`
`

`
`systems with permanently or ‘statically’ assigned IP addresses. This standard was
`
`designed to support ‘dynamically assigned addresses’, though these documents do
`
`not use this term because it was coined years later.
`
`58. Clear Reference to the Dynamic nature of IP addresses. The Domain
`
`Name System (DNS) was standardized in the RFC882/883 documents published in
`
`November 1983. By the time the RFCl0Ol/ 1002 documents were published in
`
`March 1987, DNS was already being used on the Internet. It was also used for large
`
`internal networks (universities, large corporations, etc). The Domain Name System
`
`was designed for environments where computers had permanently assigned IP
`
`addresses, and it was based on ‘static’ (manually modified) databases containing
`
`(among other things) mappings from names to IP addresses. The RFCl00l
`
`document described a NetBIOS Name Server (NBNS) that should contain similar
`
`mapping (from a process name to the processing unit IP address), and that document
`
`provided comparison between its NBNS and the already popular Domain Name
`
`System (DNS). When NetBIOS—over-TCP standards were developed, it was
`
`Page 35
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 37
`
`

`
`recognized that these name—to-address mappings should be dynamic (i.e. that the IP
`
`address can change) and this is why the traditional DNS could not be used2. The
`
`RFCl0Ol document reads: “This RFC, however, requires the NBNS to provide
`
`services beyond those provided by the current domain name system. An attempt has
`
`been made to coalesce all the additional services which are required into a set of
`
`transactions which follow domain name system styles of interaction and packet
`
`formats. Among the areas in which the domain name service must be extended
`
`before it may be used as an NBNS are:
`
`- Dynamic addition of entries
`
`- Dynamic update of entry data” (Exhibit 1003, p.386). As an entry data in
`
`NetBIOS Name server database contains a ‘process’ name and its ‘processing unit’
`
`IP address, a requirement to support “dynamic update of entry data” indicates that
`
`the RFCl00l document anticipated the ‘dynamic’ nature of IP address allocation:
`
`record data for a given name contains only an IP address, and record data needs to be
`
`updated only if that IP address can change.
`
`2 The Domain Name System was later extended to support dynamic addressing, too. The resulting
`Dynamic DNS (DDNS) standards appeared in July of 1994.
`
`Page 36
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 38
`
`

`
`59. The ‘704 Patent does not contain any mechanism specifically designed to
`
`support dynamic addressing, nor does it disclose any mechanism for dynamic
`
`allocation of IP addresses. The ‘704 ‘processes’ (or ‘processing units’) connect to
`
`the network, register their current network addresses with the server, and later
`
`disconnect from the network. When they connect again, they may be using the same
`
`network address, or they may have a different network address assigned — the
`
`‘connection server’ of the ‘704 patent simply registers the network address supplied.
`
`Similarly, a NetBIOS Name Server works equally well if a name was registered
`
`being mapped to one IP address, and later this name is re—registered being mapped to
`
`the same or to a different IP address.
`
`60. The Microsoft WINS is an implementation of NetBIOS Name Server
`
`(NBNS). It was designed specifically to work in DHCP environments (i.e. in
`
`networks were IP addresses are assigned dynamically, using a DHCP server). WINS
`
`strictly follows the RFC1001/RFC1002 standards: “As described in the following
`
`section, WINS is a NetBIOS over TCPfIP mode of operation defined in RFC
`
`1001/1002 as p—node.” (Exhibit 1004, p.65); “The WINS protocol is based on and is
`
`Page 37
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 39
`
`

`
`compatible with the protocols defined for NBNS in RFCs 1001/1002, so it is
`
`interoperable with any other implementations of these RFCs.” (Exhibit 1004, p.69).
`
`61. Conclusion. It is my opinion that not only the Microsoft WINS
`
`implementation, but the NetBIOS—oVer-TCP standards (RFC1001/ 1002) themselves
`
`fully anticipate configurations Where IP addresses of ‘processing units’ are assigned
`
`on a non-permanent basis (‘dynamically’).
`
`XI. Rebuttal to Additional Characterizations of NetB|OS
`
`62. While most of the NetBIOS-related statements in the Expert Declaration
`
`(Mayer-Patel Declaration, Exhibit 2018) are repetitions of the same two statements
`
`(“on-line status vs. registration” and “dynamic address assignment”), there are
`
`several other statements that, in my opinion, should be reviewed and discussed.
`
`63. The Patent OWner’s Expert claims ‘‘If a system is configured to utilize dynamic
`
`address allocation, each process is assigned a unique IP address from the sewer during
`
`network initialization.” (Mayer-Patel Declaration, Exhibit 2018, p.16). This statement is
`
`incorrect, as an IP address is assigned (permanently or dynamically) to an entire
`
`computer (‘processing unit’), and processes running on that computer unit share the
`
`Page 38
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 40
`
`

`
`same IP address as the ‘computer part’ of their process network addresses. This is
`
`why a process network address should include (explicitly or implicitly) a ‘local part’
`
`uniquely identifying that ‘process’ within the ‘processing unit’. It can be a ‘port
`
`number’ for processes using the TCP/UDP protocols, or it can be the registered
`
`name itself for a process using the NetBIOS—over-TCP protocol.
`
`64. The Patent Owner’s Expert makes the following statement about NetBIOS:
`
`‘‘35. In fact, once a node is registered, its status does not change in any way unless it is
`
`"challenged" by a new node requesting the same name registration as the original node.”
`
`(Mayer-Patel Declaration, Exhibit 2018, p.22). This is incorrect, as the NetBIOS
`
`Name Server may detect the change of the process on—line status when the process
`
`requests its ‘name release’, when the process or its ‘processing unit’ fail to refresh
`
`the registration before it times-out. See Sections 27 and 29 of this Declaration for the
`
`details.
`
`65. The Patent Owner’ s Expert makes the following statement about the
`
`record set (database) kept by NetBIOS Name Server (NBNS): “36. In the previous
`
`reexamination of the ’704 Patent, I noted that NetBlOS sets all names to "active," regardless
`
`Page 39
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 41
`
`

`
`of the name’s on—line status with the network. An active name simply refers to a name that
`
`has been registered and that has not yet been deregistered, independent of whether the
`
`associated computer is or is not on-line. The fields in the name flag merely denote whether
`
`the name is (1) active, or (2) in conflict, as pictured below: [...] (NetBIOS at 447).” (Mayer-
`
`Patel Declaration, Exhibit 2018, p. 23). The quoted NetBIOS record (“pictured
`
`below”) is taken from RFCl002, the document describing the formats of NetBIOS-
`
`over—TCP protocol messages, and the quoted part describes “4.2. 18. NODE
`
`STATUS RESPONSE”, sent by a ‘processing unit’ (not a particular ‘process’) in
`
`response to NetBIOS NODE STATUS REQUEST. Firstly, the NODE STATUS
`
`REQUEST does not correspond to any of the operations described in the ‘704 Patent
`
`(it asks a ‘processing unit’ to report all registered names of all ‘processes’ running
`
`on that unit), although it can be used to implement more effective ‘active polling’
`
`(the ‘704 Patent does not disclose ‘active polling’ at all, see Sections 31 and 35 of
`
`this Declaration). Secondly, the quoted NetBIOS record is part of the protocol, not a
`
`record of the NetBIOS Name Server internal database as the Patent Owner’s Expert
`
`implies, and the NODE STATUS RESPONSE record format does not define or
`
`restrict the content of that database.
`
`Page 40
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 42
`
`

`
`66. The Patent Owner’s Expert makes the following statement: ‘‘I note that the
`
`NetBIOS system does not actually deregister any names. Instead, NetBIOS will allow the user
`
`of the computer to delete its own name from the NetBIOS database. According to NetBIOS,
`
`"The only valid user function against a marked name is DELETE NAME." (NetBIOS at 380).”
`
`(Mayer-Patel Declaration, Exhibit 2018, p.24). This statement was taken completely
`
`out of context, which is RFC1001 section 15.1.3.5 NAME CONFLICT. That section
`
`explains what should happen to a ‘process’ trying to register a NetBIOS name that is
`
`already in use with some other ‘process’, and to the NetBIOS software running on
`
`the ‘processing unit’ where the first ‘process’ runs. The quoted section says: “Notice
`
`that only those nodes that receive the name conflict message place a conflict mark
`
`next to a name. Logically, a marked name does not exist on that node”, and then
`
`“The only valid user function against a marked name is DELETE NAME.” The ‘704
`
`Patent does not even try to discuss situations in which two different processes try to
`
`utilize the same name, so any discussion about duplicate names handling in
`
`NetBIOS is not relevant.
`
`67. The Patent Owner’s Expert later makes a similar statement: “39 Moreover, if
`
`the system does become aware that the node is not connected to the network (through a
`
`Page 41
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 43
`
`

`
`name challenge, for example), the node will still remain "registered" with the system, merely
`
`marked as "in conflict."” (Mayer-Patel Declaration, Exhibit 2018, p.24-25). Again,
`
`marking a NetBIOS record ‘in conflict’ takes place only when two processes try to
`
`use the same name — the condition completely ignored by the ‘704 Patent. Outside
`
`that condition, the NetBIOS Name Server does de—register records if their processes
`
`are no longer ‘on—line’, including the situations of active ‘name challenge’ polling:
`
`“A well—behaved NBNS, would, however, issue a challenge to-, or request a list of
`
`names from-, the non—reporting end—node before deleting its name(s). The absence
`
`of a response, or of the name in a response, will confirm the NBNS decision to
`
`delete a name.” (Exhibit 1003, pp.400-401).
`
`68. The Patent Owner’s Expert claims that not only is NetBIOS Name Server
`
`unable to detect that a process is no longer ‘on—line’ (this incorrect statement was
`
`examined in Section VII above), but that “NetBlOS clearly delineates its protocol for
`
`when a computer or node is thought to be disconnected from the network, and it does not
`
`include the generation or transmission of an off-line message to the first process” (Mayer-
`
`Patel Declaration, Exhibit 2018, p.36). This is an incorrect statement. When a
`
`process tries to connect to other process by name, and the NetBIOS—over-TCP
`
`Page 42
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 44
`
`

`
`software sends a NAME QUERY request to the NetBIOS Name Server, in a
`
`situation in which the Name Server does not have the requested record in its
`
`database, it generates and sends back a NEGATIVE RESPONSE message, in
`
`exactly the same way as the ‘704 Patent ‘connection server’ sends back its ‘off—line
`
`message’. The RFClOOl document reads: “The following diagram shows what
`
`happens if the NBNS has no information about the name:
`
`P—NODE DISCOVERY PROCESS
`
`(server has no information about the name)
`P—NODE
`NBNS
`
`NAME QUERY REQUEST
`
`_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __>
`
`NEGATIVE RESPONSE
`
`< ——————————————————————————————— ——
`
`(Exhibit 1003, p.389). The RFClO02 section 4.2.14. NEGATIVE NAME QUERY
`
`RESPONSE specifies this ‘off—line message’ format (Exhibit 1003, p.460).
`
`69. The Patent Owner’s Expert then makes one more attempt to show that the
`
`NetBIOS—over-TCP does not teach an equivalent to ‘off—line message’ reporting of
`
`the‘704 Patent (Sections 55-56 of the Expert Declaration). I agree with the Patent
`
`Owner’s Expert when he says ‘‘I note that the “END-NODE CHALLENGE
`
`Page 43
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 45
`
`

`
`REGISTRATION RESPONSE” transmitted by NBNS could not be interpreted as an "off-line
`
`message" generated and transmitted "to the first process".” (Mayer-Patel Declaration,
`
`Exhibit 2018, p.37), because he reviews a wrong RESPONSE. Here the Patent
`
`Owner’s Expert reviews the process of NetBIOS registration and various messages
`
`the Name Server (NBNS) generates when it discovers that the name to be registered
`
`is already claimed by a different process. Firstly, the ‘704 Patent does not even try
`
`to disclose what should be done if two processes claim the same name. Secondly, the
`
`‘off—line message’ as claimed in the ‘704 Patent Claim 7 is generated in response to
`
`“receiving a query from the first process to determine the on—line status of the
`
`second process” (parent Claim 4, B), i.e. in response to a NAME QUERY request
`
`(in NetBIOS—over-TCP terms), not in response to a NAME REGISTRATION
`
`request (in NetBIOS—over-TCP terms), claimed in the parent Claim 4, A. And, as
`
`shown in Section 68 of this Declaration, the NetBIOS—over-TCP Name Server does
`
`generate an ‘off—line message’ in response to a NAME QUERY request, in the form
`
`of NEGATIVE NAME QUERY RESPONSE.
`
`70. The Patent Owner’s Expert claims that “61. Further, NetBIOS does not delete
`
`an entry from its database. Claim 42 contains a step to "delete an entry from the
`
`Page 44
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 46
`
`

`
`compilation”.” The Expert then immediately contradicts himself, saying that NetBIOS
`
`does delete names, but does it “incorrectly”: “Second, for a name to be deleted, it must
`
`be deleted by the registrant, not by the NetBIOS system. Petitioner cites the NetBIOS
`
`excerpts that "NetBlOS names may be released explicitly or silently by an end-node," and "P
`
`nodes send a notification to their NBNS." (Petition at 55). I note that both of these excerpts
`
`establish that the registrant deletes itself, as names are released "by an end-node," and the
`
`"P nodes send a notification" requesting the deletion of its name.” (Mayer-Patel
`
`Declaration, Exhibit 2018, p.42). Firstly, it is not true that a NetBIOS Name Server
`
`deletes names only in response to a registrant process request (in response to its
`
`NAME RELEASE request). When a NetBIOS Name Server discovers that a process
`
`is not ‘on—line’ any more, it deletes its name: “The absence of a response, or of the
`
`name in a response, will confirm the NBNS decision to delete a name.” (Exhibit
`
`1003, pp.400-401). Secondly, the NAME RELEASE request sent by the registrant
`
`process perfectly matches the ‘704 Patent Claim 42. That process does not delete its
`
`registration completely by “itself”, as the Patent Owner’s Expert states: a ‘process’
`
`running on a different ‘processing unit’ does not have direct access to the Name
`
`Server ‘processing unit’ and its database. Instead, a ‘process’ that desires to remove
`
`Page 45
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 47
`
`

`
`its name (to “de—register”) uses the NetBIOS software to send the NAME RELEASE
`
`request to the NetBIOS Name Server. And the NetBIOS Name Server then deletes
`
`the process name from its database of active names (“releases the name”) and it
`
`sends back the POSITIVE NAME RELEASE RESPONSE. The RFClOO2 document
`
`shows how a NetBIOS Name Server should process NAME RELEASE requests:
`
`NAM% R%L%AS% R%QUfiST:
`/*
`
`* secure server may choose to disallow
`* a node from deleting a name
`*/
`
`update data base — remove entry;
`send POSITIVfi NAM% RfiLfiAS% R%SBONSj;
`return;
`
`(Exhibit 1003, p.502). Receiving a NAME RELEASE REQUEST is an example of
`
`“a predetermined event” specified in the ‘704 Patent Claim 42.
`
`XII.
`
`Rebuttal to Additional Characterizations of Microsoft WINS
`
`71. The Microsoft WINS product is an implementation of NetBIOS Name
`
`Server (NBNS). In this Section I address several statements the Patent Owner’s
`
`Expert has made about the Microsoft WINS product.
`
`Page 46
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 48
`
`

`
`72. Microsoft WINS fully follows the RFC1001/RFC1002 standards: “As
`
`described in the following section, WINS is a NetBIOS over TCP/IP mode of
`
`operation defined in RFC 1001/1002 as p—node.” (Exhibit 1004, p.65); “The WINS
`
`protocol is based on and is compatible with the protocols defined for NBNS in RFCs
`
`1001/1002, so it is interoperable with any other implementations of these RFCs.”
`
`(Exhibit 1004, p.69).
`
`73. The Microsoft TCP/IP manual (Exhibit 1004) is a document designed to
`
`help system administrators to understand concepts and ideas behind a NetBIOS
`
`Name Server (WINS), dynamic IP address allocation (DHCP), FTP, SNMP, and
`
`many other networking protocols and methods. This document can be used to
`
`illustrate some features of those protocols and methods. On the other hand, the
`
`Microsoft TCP/IP manual is not a formal programming guide, nor is it a detailed
`
`description of product internals. This document does not define everything a
`
`particular protocol or product can do: an absence of a technical detail in such a
`
`manual does not mean that this detail is not implemented in the product.
`
`Page 47
`
`Petitioner Sipnet EU S.R.O. - Exhibit 1023 - Page 49
`
`

`
`74. The Patent Owner’s Expert claims: “65. Registration (or the "cIaim[ing oi] the
`
`particular IP address") occurs during system startup. As the WINS reference states, "To
`
`ensure that both name and address are unique, the Windows NT computer using TCP/IP
`
`registers its name and IP address on the network during system startup." (WINS at 49). "A
`
`computer typically registers itself when it starts." (WINS at 50).” (Mayer-Patel Declaration,
`
`Exhibit 2018, p.44). Microsoft Windows NT allows a user to assign a ‘name’ to the
`
`computer. When Windows NT starts, several system processes are started
`
`automatically. Among them the Workstation Service and, optionally, the Messenger
`
`Service. These processes are registering themselves with a NetBIOS Name Server
`
`(such as WINS) using the computer na

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