UNITED STATES DEPARTMENT OF COMMERCE
`United States Patent and Trademark Office
`
`June 29, 2015
`
`THIS IS TO CERTIFY THAT ANNEXED IS A TRUE COPY FROM THE
`RECORDS OF TillS OFFICE OF THE FILE WRAPPER AND CONTENTS
`OF:
`
`APPLICATION NUMBER: 091629,577
`FILING DATE: July 31, 2000
`PATENT NUMBER: 6,732,147
`ISSUE DATE: May 04, 2004
`
`By Authority of the
`Under Secretary of Commerce for Intellectual Property
`and Director of the United States Patent and Trademark Office
`
`M. TARVER
`Certifying Officer
`PART (I{) OF (j,) PART(S)
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 960 of 1657
`
`

`
`s
`
`to
`
`The underlying peer-to-peer communications protocol
`messages in a single message stream. The traditional technique for retrie · g messages from
`a stream has been to repeatedly invoke an operating system routine to etrieve the next
`message in the stream. The retrieval of each message may require two call to the operating
`system: one to retrieve the size of the next message and the other to retrie e the number of
`bytes indicated by the retrieved· size. Such calls to the operating system an, however, be
`very slow in comparison to the invocations of local routines. To overcome the inefficiencies
`
`send multiple
`
`R to identify the
`of such repeated calls, the broadcast technique in one embodiment, uses
`message boundaries in a stream of messages. The broadcast technique may request the
`operating system to provide the next, for example, 1,024 bytes from
`e stream. The
`broadcast technique can then repeatedly invoke the XDR routines to· retri ve the messages
`and use the success or failure of each invocation to determine whether ano er block of 1,024
`bytes needs to be retrieved from the operating system. The invocation of R routines do
`not involve system calls and are thus more efficient than repeated system c
`
`15 M-Resular
`
`20
`
`In the. embodiment described above, each fully connected c mputer has four
`internal connections. The broadcast technique can be used with other n
`bers of internal
`connections. For example, each computer could have 6, 8, or any even n ber of internal
`connections. As the number of internal connections increase, the diamete of the broadcast
`channel tends to decrease, and thus propagation time for a message tends o decrease. The
`time that it takes to connect a seeking computer to the broadcast chann 1 may, however,
`increase as the number of internal connections increases. When the n ber of internal
`connectors is even, then the broadcast channel can be maintained
`m-regular and
`m-connected (in the steady state). If the number of internal connections i odd, then when
`the broadcast channel has an odd number of ~omputers connected, one of e computers will
`have less than that odd number of internal connections. In such a situati n, the broadcast
`network is neither m-regular nor m-connected. When the next comput
`broadcast channel, it can again become m-regular and m-connected.
`us, with an odd
`number of internal connections, the broadcast channel toggles between be· g and not being
`30 m-regular and m-connected.
`
`25
`
`[03004-8001lSL003733.107]
`
`-21-
`
`7/lllOO
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 961 of 1657
`
`

`
`Components
`Figure 6 is a block diagram illustrating components of a omputer that is
`connected to a broadcast channel. The above description generally assum d that there. was
`only one broadcast channel and that each computer had only one connectio to that broadcast
`
`channeL More generally, a network of computers may have multiple br adcast channels,
`d· each computer
`each computer may be .connected to more than one broadcast channel,
`can have multiple connections to the same broadcast channel. The broadca t channel is well
`suited for computer processes (e.g., application programs) that execute col boratively, such
`as network meeting programs. Each computer process can connect to one r more broadcast
`channels. The broadcast channels can be identified by channel type e.g., application
`program name) and channel instance that represents separate broadcast hannels for that
`channel type. When a process attempts to connect to a broadcast channel, t seeks a process
`currently connected to that broadcast channel that is executing on a po
`computer. The
`seeking process identifies the broadcast. channel by channel type and chann
`1 executing as
`Computer 600 includes multiple application programs
`separate· processes. · Each application program interfaces with a broadcaste component 602
`for each broadcast channel to ·which it is connected The broadcaster co ponent may be
`the application
`implement as an object that is instantiated within · the process space o
`program. Alternatively, the broadcaster component· may execute as a se arate process or
`thread from the application program.
`In one embodiment. the broad ster component
`provides functions (e.g., methods of class) that can be invoked by the app cation programs.
`The primary functions provided may include a connect fWiction that an ap Iicari on program
`invokes passing an indication of the broadcast channel to which the ap lication program
`wants to connect. The application program may provide a callback routine that the
`broadcaster component invokes to notify the application program that th connection has
`been completed, that is the process enters the fully connected state. The broadcaster
`component may also provide an acquire message function that the applica ·on program can
`invoke to retrieve the next message that is broadcast on the broadcast chann l. Alternatively,
`the application program may provide a callback routine (which may be virtual function
`provided by the application program) that the broadcaster component inv kes to notify the
`application program that a broadcast message has been received.
`ach broadcaster
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`component allocates a call-in port using the hashing algorithm. When call are answered at
`-22-
`
`[03004-IIOOJISL003733.101]
`
`7131100
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 962 of 1657
`
`

`
`the call-in port, they are transferred to other ports that serve as the exte 1 and internal
`
`ports.
`
`The computers connecting to the broadcast channel may ·
`, output devices
`processing unit, memory, input devices (e.g., keyboard and pointing devic
`(e.g., display devices), and storage devices (e;g., disk drives). The m ory and storage
`
`5
`
`10
`
`15
`
`20
`
`25
`
`tructions that
`devices are computer-readable medium that may contain computer
`In addition, the data struc
`s and message
`implement the broadcaster component.
`structures may be stored or transmitted via a signal transmitted on a c mputer-readable
`media, such as a communications link.
`Figure 7 is a block diagram illustrating the sub-components
`component in one embodiment. The broadcaster component includes a co ect component
`701, an external dispatcher 702, an internal dispatcher 703 for each intern connection, an
`acquire message component 704 and a broadcast component 712. The ap lication program
`may provide a connect callback component 710 and a receive response co ponent 711 that
`are invoked by the broadcaster component. The application program inv kes the connect
`~ The connect
`component to establish a connection to a designated broadcast chann
`component identifies the external port and installs the external dispatc er for handling
`
`messages that are received on the external port. The connect component · vokes the seek
`
`portal computer component 705 to identify a portal computer that is onnected to the
`
`broadcast channel and invokes the connect request component 706 to ask th portal computer
`(if fully connected) to select neighbor processes for the newly connec · g process. The
`external dispatcher receives external messages, identifies the type of mess ge, and invokes
`the appropriate handling routine 707. The internal dispatcher receives the · ternal messages,
`tine 708. The
`identifies the type of message, and invokes the appropriate handling r
`received broadcast messages are stored in the broadcast message queue 7 9. The acquire
`message component is invoked to retrieve messages from the broadc st queue. The
`broadcast component is invoked by the application program to broadcast messages in the
`broadcast channel.
`
`A Distributed Game Environment
`
`30
`
`In one embodiment, a game environment is implemented usmg broadcast
`channels. The game environment is provided by a game application pro
`executing on
`
`[03004-800 l/SL003733.1 07)
`
`-23-
`
`7/31100
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 963 of 1657
`
`

`
`each player's computer that interacts with a broadcaster component. Ea h player joins a
`
`game (e.g., a first person shooter game) by connecting to the broadcast c
`
`el on which the
`
`game is played. Each time a player takes an action in the game a message representing that
`In addition, a
`s messages (e.g., strategy information) to one or mo~ other players b broadcasting a
`
`action is broadcast on the game's broadcast channel.
`
`layer may send
`
`message. When the game application program receives an indication of an action, either
`
`received on the broadcast channel or generated by the player at this comp ter, it updates its
`
`current state of the game. The game may terminate when one of the players reaches a certain
`
`score, defeats all other players, all players leave the game, and so on.
`
`10
`
`To facilitate the creation of games· for the game environme t, an application
`
`programming interface ("API") is prqvided to assist game developers. The
`
`I may provide
`
`high-level· game functions that would be used by most types of first perso
`
`For example, the. API may include functions for indicating that a player ha
`
`position, for shooting in a certain direction, for reporting a score, for anno
`
`15
`
`and departure of players, for sending a message to another player, and so o
`
`The game environment may provide a game web site throu which players
`
`can view the state of current games and register new games. The game eb server would
`include a mapping between each game and the broadcast channel on which e game is to be
`played. When joining a game, the user would download the broadcaster c mponent and the
`game application program from the web server. The user would al
`
`download the
`
`20
`
`description of the game, which may include the graphics for the game~
`
`would also provide the channel type and channel instance associated with e game and the
`identification of the portal computers for the game. The game environmen
`
`game monitor computer that connects to each game, monitors the activity of the game, and
`
`25
`
`reports the activity to the web server. With this activity information, th web server can
`
`provide information on the current state (e.g., number of players) of each g
`The game environment may also be used for games other than first person
`shooter games. For example, a variation of a society simulation game can be played where
`
`30
`
`players sign up for different roles. If a role is unfulfilled or a player ·
`playing, then an automated player can take over the role.
`The following tables list messages sent by the broadcaster co
`
`(03004-800 11Sl.003733 .1 07]
`
`-24-
`
`7/31/00
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 964 of 1657
`
`

`
`Message Type
`seeking_ colUlection _call
`
`connection _request_ call
`
`edge _proposal_ call
`
`port_connection~call
`
`connected_ stmt
`
`condition_ repair_ stmt
`
`EXTERNAL MESSAGES
`
`Description
`Indicates that a seekingprocess would like.to kn ow whether the
`receiving process is fully colUlectedto the broauJ ~ast channel
`Indicates that the sending process would like the recetvmg
`process to initiate a connection of the sending p ocess to the
`broadcast·channel
`Indicates that the sending process is proposing.a ~ edge tlrrough
`which the receiving process can connect to the t oadcast
`channel (i.e., edge pinning)
`Indicates.thatthe sending process is proposing a port through
`which the receiving process can connect to the t lroadcast
`channel
`Indicates that the sending process is connected t the broadcast
`channel
`Indicates that the receiving process should disco ~ect from one
`of its neighbors and connect to one of the procel ses involved in
`the neighbors with empty port condition
`
`Message Type
`broadcast_ stmt
`
`connection _port _search_ stmt
`
`connection_ edge_ search_ call
`
`connection_edge_search_resp
`
`diameter_ estimate_ stmt
`diameter _reset_stmt
`
`disconnect_ stmt
`
`condition_ check_ stmt
`
`INTERNAL MESSAGES
`
`Description
`Indicates a message that is being broadcast jthrough the
`broadcast channel for the application progr !Jms
`Indicates that the designated process is lool Ptig for a port
`through which it can connect to the broadc. ~tchannel
`Indicates that the requesting process is lool ing for an edge
`through which it can connect to the broadc ~tchannel
`Indicates whether the edge between this pn ~Cess and the
`sending neighbor has been accepted by the equesting
`party
`Indicates an estimated diameter of the broa icast channel
`Indicates to reset the estimated diameter to indicated
`diameter
`Indicates that the sending neighbor is disco nnecting from
`the broadcast channel
`Indicates that neighbors with empty port c<: ndition have
`
`(03004-800 l/SL003733.1 01)
`
`-25-
`
`7131/00
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 965 of 1657
`
`

`
`been detected
`
`condition_ double_ check _stmt
`
`Indicates that the neighbors with empty po have the
`same set of neighbors
`
`shutdown_stmt
`
`Indicates that the broadcast channel is bein shutdown
`
`Flow Diagrams
`
`Figures 8-34 are flow diagrams illustrating the processing o the broadcaster
`
`lishing external
`
`5
`
`15
`
`component in one embodiment. Figure 8 is a flow diagram illustrating the ocessing of the
`connect routine in one embodiment. This routine is passed a channel type e.g., application
`name) and channel instance (e.g., session identifier), that identifies the bro dcast channel to
`which this process wants to connect. The routine is also passed auxiliary information that
`the connection
`includes the list of portal computers and a connection callback routine. Wh
`is established, the connection callback routine is invoked to notify the app ication program.
`10 When this process invokes this routine, it is in the seeking connection stat When a portal
`computer is located that is connected and this routine connects to at least o e neighbor, this
`process enters the partially connected state, and when the process eventually connects to four
`neighbors, it enters the fully connected state~ When in the small regime,
`process may have less than four neighbors. In block 801, the routine open the call-in port
`through which the process is to communicate with other processes when es
`and internal connections. The port is selected as the first available port
`In block 802, the ·routine sets the connect · e to the current
`algorithm described above.
`time. The connect time is used to identify the instance of the process
`t is connected
`through this external port. One ·process may connect to a broadcast ch
`el of a certain
`
`20
`
`channel type and channel instance using one call-in port and then disconn cts, and another
`
`process may then connect to that same broadcast channel using the same
`
`•in port. Before
`
`unicate with it
`the other process becomes fully connected, another process may try to co
`thinking it is the fully connected old process. In such a case, the connect · e can be used to
`identify this situation. In block 803, the routine invokes the seek portal omputer routine
`passing the channel type and channel instance. The seek portal computer ro tine attempts to
`locate a portal computer through which this process can connect to the broa cast channel for
`the passed type and instance. In decision block 804, if the seek portal co puter routine is
`
`25
`
`[03004-80Dl/SL003733.107)
`
`-26-
`
`7/ll/00
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 966 of 1657
`
`

`
`successful in locating a fully connected process on that portal computer, then the routine
`continues at block 805, else the routine returns an unsuccessful indication.
`decision block
`805, if no portal computer other than the portal computer on which the pro ess is executing
`
`was located, then this is the first process to fully connect to broadcast channel and the
`
`5
`
`block 806, the
`routine continues at block 806, else the routine continues at block 808.
`routine invokes the achieve connection routine to change the state of this process to fully
`connected. In block 807, the routine installs the external dispatcher for pro essing messages
`
`received through this process' external· port for the passed channel type· and hannel instance.
`
`When a message is received through that external port, the external dispa cher is invoked.
`
`10
`
`The routine then returns. In block 808, the routine installs an external dis atcher. In block
`
`. 809, the routine. invokes. the connect request routine to initiate the . proce s of identifying
`
`neighbors for the seeking computer. The routine then returns.
`Figure 9 is a flow diagram illustrating the processing of the seek portal
`
`computer routine in one embodiment. This routine is passed the channel
`
`e and channel
`
`instance of the broadcast channel to which this. process wishes to connect. This. routine, for
`each search depth (e.g., port number), checks the portal computers at that s arch depth. If a
`portal computer is located at that search depth with a process that is fully connected to the
`broadcast channel, then the routine returns an indication of success. In bl ks 902-911, the
`routine loops selecting each search depth until a process is located. In bloc 902, the routine
`selects the next search depth using a port number ordering algorithm. In de ision block 903,
`
`if al1 the search depths have already been selected during this execution o the loop, that is
`
`for the currently selected depth, then the routine returns a failure indicatio else the routine
`continues at block 904. In blocks 904-911, the routine loops selecting eac
`
`and determining whether a process of that portal computer is connected to or attempting to
`In
`el instance.
`905, if all the
`
`connect to) the broadcast· channel with the passed channel type and ch
`In decision blo
`
`block 904, the routine selects the next portal computer.
`
`15
`
`20
`
`25
`
`portal computers have already been selected, then the routine loops to block 902 to select the
`
`next search depth, else the routine continues at block 906. In block 906, th routine dials the
`
`selected portal computer through the port represented by the search depth.
`
`decision block
`
`30
`
`907, if the dialing was successful, then the routine continues at block 908 else the routine
`loops to block 904 to select the next portal computer. The dialing will be successful if the
`
`dialed port is the call-in port of the broadcast channel of the passed channel
`-27-
`
`[03004-8001/Sl.D03733.107]
`
`e and channel
`
`713 1100
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 967 of 1657
`
`

`
`instance of a process executing on that portal computer. In block 908, the outine invokes a
`contact process routine, which contacts the answering process of the portal omputer through
`the dialed port and determines whether that process is fully connected to the broadcast
`channel. In block 909, the routine hangs up on the selected portal comp ter. In decision
`s block 910, if the answering process is fully connected to the broadcast hannel, then the
`routine returns a success indicator, else the routine continues at block 911. In block 911, the
`routine invokes the check for external call routine to determine whether an external call has
`e routine then
`been made to this process as a portal computer and processes that call.
`
`loops to block 904 to select the next portal computer.
`Figure 10 is a flow diagram illustrating the processing of th contact process·
`
`10
`
`routine in one embodiment This routine detennines whether the proce of the selected
`
`15
`
`20
`
`25
`
`30
`
`broadcast channel.
`
`portal computer that answered the call-in to the selected port is fully
`In block 1001, the routine sends an exte
`seeking_ connection_ call) to the answering process indicating that a seeking process wants to
`eL In block
`In
`· g process.
`received (i.e.,
`
`know whether the answering process is fully connected to the broadcast c
`1002, the routine receives the external response message from the answ
`decision block 1003, if the external response message is successful}
`
`seeking_connection_resp), then the routine. continues at block 1004, else
`
`Wherever the broadcast component requests to receive an external message, it sets a time out
`period. If the external message is not received within that time out perio
`the broadcaster
`component checks its own call-in port to see if another process is calling it. In particular, the
`dialed process may be calling the dialing process, which may result in a d adlock situation.
`The broadcaster component may repeat the receive request several times. If the expected
`message is not received, then the broadcaster component handles the error s appropriate. In
`decision block 1004, if the answering process indicates in its response mes ge that it is fully
`connected to the broadcast channel, then the routine continues at block 100 , else the routine
`continues at block 1006. In block I 005, the routine adds the selected p
`al computer to a
`In block 1006, the routine adds the
`list of connected portal computers and then returns.
`answering process to a list of fellow seeking processes and then returns.
`
`Figure 11 is a flow diagram illustrating the processing of th connect request
`
`routine in one embodiment. This routine requests a process of a portal c mputer that was
`
`identified as being fully connected to the broadcast channel to initiate the
`-28-
`
`[030[)4.8001/SL003733.107J
`
`nnection of this
`
`7131100
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 968 of 1657
`
`

`
`process to the broadcast channel In decision block 1101, if at least one p ocess of a portal
`computer was located that is fully connected to the broadcast channel, then the routine
`
`continues at block 1103, else the routine continues at block 1102. A pro ess of the portal
`
`5
`
`computer may no longer be in the list if it recently disconnected from the b oadcast channel.
`In one embodiment, a seeking computer may always search its entire se h depth and find
`multiple portal computers through which it can connect to the broadcast
`1102, the routine restarts the process of connecting to the broadcast chann I and returns. In
`block 1103, the routine dials the process of one of the found portal com
`ters through the
`call-in port. In decision block 1104, if the dialing is successful, then the ro tine continues at
`
`10
`
`block 1105, else the routine continues at block 1113. The dialing may be
`
`response message (i.e., connection.;_request_resp}.
`
`successfulif, for
`In block
`example, the dialed process recently disconnected from the broadcast c annel.
`1105, the routine· sends an external message to the. dialed process requestin a connection to
`the broadcast channel (i.e., connection_request_call). In block 1106, thero tine receives the
`In decision block 110 , if the response·
`15 message is successfully received,· then the routine continues at block 110 , else the routine.
`continues at block. 1113. In block 1108, the routine sets the expected n
`
`er of holes (i.e.,
`empty internal connections) for this process based on the received respo e. When in the
`large regime, the expected number of holes is zero. When in the small re
`e, the expected
`In block 1109, the routine s ts the estimated
`nuinber of holes varies from one to three.
`diameter of the broadcast channel based on the received response. In decis on block 1111, if
`
`the dialed process is ready to connect to this process· as indicated by the r sponse message,
`then the routine continues at block 1112, else the routine continues at bloc 1113. In block
`1112, the routine invokes the add neighbor routine to add the answe g process as a
`
`neighbor to this process. This adding of the answering process typically occurs when the
`broadcast channel is in the small regime. When in the large regime, the r dom walk search
`for a neighbor is performed.
`In block 1113, the routine hangs up the ex emal connection
`
`with the answering process computer and then returns.
`
`Figure 12 is a flow diagram of the processing of the check for external call
`routine in one embodiment. This routine is invoked to identify whether a fellow seeking
`process is attempting to establish a connection to the broadcast channel thr ugh this process.
`In block 1201. the routine attempts to answer a call on the call-in port.
`1202, if the answer is successful then the routine continues at block 120 , else the routine
`-29-
`
`decision block
`
`7131/00
`
`j03004-8001/SL003733.107)
`
`20
`
`25
`
`30
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 969 of 1657
`
`

`
`returns. In block 1203, the routine receives the external message from the xternal port. In
`decision block 1204, if the type of the message indicates that a seeking rocess is calling
`(i.e., seeking_connection_call), then the routine continues at block 1205, else the routine
`returns. In block 1205, the routine sends an external message (i.e., seeking onnection_resp)
`connection. In
`to the other seeking process indicating that this process is also is seeking
`decision block 1206, if the sending of the external message is successful, then the routine
`continues at block 1207, else the routine returns. In block 1207, the rou · e adds the other
`seeking process to a list of fellow seeking processes and then returns. This list may be used
`if this process can find no process that is fully connected to the broadcast c annel. In which
`case, this process may check to see if any fellow seeking process w re successful in
`connecting to the broadcast channel For example; a fellow seeking proces may become the
`
`first process fully connected to the broadcast channel.
`
`Figure 13 is a flow diagram of the processing of the achieve c nnection routine
`in one embodiment This routine sets the state of this process to fully onnected to the
`broadcast channel and invokes a callback routine to notify the application program that the
`In block 130 I, the
`In block 1302, the
`
`routine sets the connection state of this process to fully connected.
`
`process is now fully connected to the requested broadcast channel.
`
`5
`
`10
`
`IS
`
`routine notifies fellow seeking processes that it is fully connected by sen · g a connected
`In block 1303, the ro tine invokes the
`external message to them (i.e., connected_stmt).
`
`20
`
`connect callback routine to notify the application program and then returns.
`
`Figure 14 is a flow diagram illustrating the processing of the external
`
`dispatcher routine in one embodiment. This routine is invoked when
`
`e external port
`
`receives a message. This routine retrieves the message, identifies the exte al message type,
`
`25
`
`and invokes the appropriate routine to handle that message. This routine loops processing
`each message until all the received messages have been handled. In block 1401, the routine
`In decision
`answers (e.g., picks up) the external port and retrieves an external mess ge.
`block 1402, if a message was retrieved, then the routine continues at bl k 1403, else the
`routine hangs up on the external port in block 1415 and returns. In decisi n block 1403, if
`the message type is for a process seeking a connection (i.e., seeking_ conn ction _call), then
`
`30
`
`the routine invokes the handle seeking connection call routine in block 140 , else the routine
`In decision block 1405, if the message type is for a connection
`
`continues at block 1405.
`
`request call (i.e., connection_request_call), then the routine invokes the
`-3 0-
`
`{03004-8001/SLOOJ733.107}
`
`dle connection
`
`7131100
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 970 of 1657
`
`

`
`In decision
`request call routine in block 1406, else the routine continues at block 14 7.
`block 1407, if the message type is edge proposal call (i.e., edge _propos _call), then the
`lse the routine
`routine invokes the handle edge proposal call routine in block 1408,
`continues at block 1409. In decision block 1409, if the message type is art connect call
`(i.e., port_connect_call), then the routine invokes the handle port connecti n call routine in
`block 1410, else the routine continues at block 1411. In decision block 141 , if the message
`
`s
`
`type is a connected statement (i.e., connected_stmt), the routine inv kes the handle
`
`In· decision
`connected statement in block 1112, else the . routine continues at block 1 12.
`block 1412, ifthe message type is a condition repair statement (i.e., condi on_repair_stmt),
`
`10
`
`then the routine invokes the handle condition repair routine in block 1413 else the routine
`
`loops to block 1414 to process the next message. After each handling rou · e is invoked, the
`
`routine loops to block 1414. In block 1414, the routine hangs up on the xternal port and
`
`continues at block 1401 to receive the next message.
`Figure 15 is a flow diagram illustrating the processing of th handle seeking
`connection call.routine in one embodiment. This routine is invoked when
`seeking process
`is calling to identify a portal computer through which it can connect to the oadcast channel.
`In decision block 1501, if this process is currently fully connected to the oadcast channel
`identified in the message, then the routine continues at block 1502, else the outine continues
`at block 1503. In block 1502, the routine sets a message to indicate that thi process is fully
`
`connected to the broadcast channel and continues at block 1505. In block 503, the routine
`sets a message to indicate that this process is not fully connected. In block 504, the routine
`adds the identification of the seeking process to a list of fellow seeking p ocesses. If this
`process is not fully connected, then it is attempting to connect to the broa cast channel. In
`block 1505, the routine sends the external message response (i.e., seeking onnection_resp)
`to the seeking process and then returns.
`
`Figure 16 is a flow diagram illustrating processing of the h
`
`request call routine in one embodiment. This routine is invoked when th calling process
`wants this process to initiate the connection of the process to the broad
`t channel. This
`·th this process
`routine either allows the calling process to establish an intemal connection
`(e.g., if in the small regime) or starts the process of identifying a process to hich the calling
`process can connect. In decision block 1601, if this process is currently
`the broadcast channel, then the routine continues at block 1603, else the ro tine hangs up on
`-31-
`
`[03004-80011SL003733.107J
`
`7131100
`
`15
`
`20
`
`25
`
`30
`
`IPR2016-00726 - ACTIVISION, EA, TAKE-TWO, 2K, ROCKSTAR, Ex. 1002, Vol. 4, p. 971 of 1657
`
`

`
`the external port in block 1602 and returns, In block 1603, the routines
`the number of
`holes that the calling process should expect in the response message.
`block 1604, the
`In block 605, the routine
`routine sets the estimated diameter in the response message.
`indicates whether this process is ready to connect to the calling process. This process is
`ready to connect when the number of its holes is greater than zero and the alling process is
`not a neighbor of this process. In block 1606, the routine sends to the· c ling process an
`external message
`that
`is
`responsive
`to
`the
`connection
`req est
`call
`(i.e.,
`connection_request_resp). In block 1607, the routine notes the nwnber f holes that the
`calling process needs to fill as indicated in the request message. In decisi n block 1608, if
`this process is ready to connect to the calling process, then the routine c ntinues at block
`1609, else the routine continues at block 1611. In block 1609, the routin invokes the add
`In block 610, the routine
`neighbor routine to add the calling process as a neighbor.
`decrements the number of holes that the calling process needs to fill and c ntinues at block
`1611. In block 1611, the routine hangs up on the external port. In decisi n block 1612, if
`this process has no holes or the estimated diameter is