throbber
13
`
`EP 0 680 185 A2
`
`14
`
`input terminals of the transport multiplexer 110, and
`may have input terminals coupled to central pro-
`cessing facilities through data transceivers.
`In operation, data representing the distributed
`computing application program, and data related to
`the transmission of the program over the transport
`mechanism 30 are supplied to the flow builder 102
`from the application source 101. This data may be
`supplied either in the form of files containing data
`representing the code and data modules, or by
`scripts providing information on how to construct
`the code and data modules, or other such informa-
`tion. The code and data modules may be constant
`or may change dynamically, based on inputs re-
`ceived from the client computers 20 via the central
`computing facility 60 and/or other sources. The
`executable code and data module files may be
`generated by a compiler, interpreter or assembler
`in a known manner in response to source language
`programming by an application programmer. The
`data file related to the transmission of the modules
`
`includes such information as: the desired repetition
`rates for
`the directory and the code and data
`modules to be included in the data stream; the size
`of main memory in the client computers 20 re-
`quired to store each module, and to completely
`execute the application program; a priority level for
`the module, if it is a code module, etc.
`Flow builder 102 processes the data from the
`application source 101.
`In response,
`flow builder
`102 constructs a directory module, giving an over-
`all picture of the application program. The informa-
`tion in the directory module includes e.g. the iden-
`tification of all the code and data modules being
`repetitively transmitted in the data stream,
`their
`size and possibly other information related to those
`modules. Then the application program representa-
`tive data is processed to generate the code and
`data modules. The directory, code and data mod-
`ules thus constructed are formatted by adding
`module headers and error detection and/or correc-
`tion codes to each module. A transmission sched-
`
`ule is also generated. After this processing is com-
`plete,
`the data representing the directory module
`and the code and data modules are repetitively
`presented to the transport packetizer 104 according
`to the schedule previously generated.
`a
`The
`transport packetizer
`104 generates
`stream of packets representing the directory mod-
`ule and the code and data modules as they are
`emitted from the flow builder 102. Each packet has
`a constant predetermined length, and is generated
`by dividing the data stream from the flow builder
`into groups of bits, and adding a packet header
`with information identifying the information con-
`tained in the packet, and an error detection and/or
`correction code, etc., to each group, such that each
`packet is the same predetermined length.
`(If there
`
`is
`
`insufficient data from the flow builder 102 to
`
`completely fill a packet, the packet is padded with
`null data.) These packets are time multiplexed with
`the auxiliary data packets,
`in a known manner,
`to
`form a single packet stream in the packet mul-
`tiplexer 106.
`It
`is also possible for the generated
`packets to have varying lengths.
`In this case, the
`packet header for each packet will contain the
`length of that packet.
`In addition,
`time code data
`packets are placed in the data stream packets
`and/or the auxiliary data packets based on data
`received from the clock 109.
`Packet streams from ail of the channel sources
`
`(108,108a) are multiplexed into a single transport
`channel, which is
`transmitted through transport
`mechanism 30. As described above,
`the packet
`streams may be frequency multiplexed by having
`each packet stream modulate a carrier signal at a
`different frequency, with all of the carriers being
`carried by a satellite link to the client computers
`20,
`in a known manner.
`In addition,
`if
`there is
`sufficient capacity within one carrier channel, sev-
`eral packet streams may bestatistically time mul-
`tiplexed, and used to modulate a single carrier,
`also in a known manner. For example,
`it has been
`proposed to time multiples up to eight interactive
`television data streams through a single satellite
`link.
`
`Data from the client computers 20 via the cen-
`tral processing facility 60 (of FIGURE 1) is received
`at the server computer 10 by the data transceiver
`103, which may include its own processor (not
`shown).
`If an immediate response is generated, the
`transceiver 103 processor returns that response via
`the central processing facility 60 to a specific client
`computer (22-26), a specific set of the client com-
`puters 20 or to all client computers 20 in their turn.
`lf, however, a common responseto all client com-
`puters 20 is desired,
`the application programmer
`may amend the code and data files in the applica-
`tion code and data source 101 using the applica-
`tion compiler. These amended files are then pro-
`cessed by the flow builder again to generate an-
`other flow.
`It
`is further possible that the code and
`data files in the application source 101 may be
`amended automatically and dynamically (i.e.
`in real
`time) in response to data received from the tran-
`sceiver 103, and the flow updated as the data is
`being received from the client computers 20.
`FIGURE 3 is a timing diagram illustrating the
`data streams produced by the server computer 10
`in a distributed computing system as illustrated in
`FIGURE 1.
`In FIGURE 3 server computer 10 is
`shown as simultaneously producing a plurality of
`packet streams 32-38. Each packet stream (32-38)
`is shown as a horizontal band divided into packets
`having the same duration and number of bits. As
`described above,
`it is possible that the size of the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0451
`EXHIBIT 1003 - PAGE 0451
`
`

`

`15
`
`EP 0 680 185 A2
`
`16
`
`packets within any packet stream vary with the
`amount of data to be carried.
`In FIGURE 3 it can
`
`be seen that the starting times of the packets are
`not synchronized.
`It is possible to synchronize the
`packets, but
`it
`in not necessary.
`In FIGURE 3,
`packets carrying data representing directories are
`designated DIR, packets carrying data representing
`code modules are designated CM, packets carrying
`data representing data modules are designated
`DM, and packets carrying auxiliary data are des-
`ignated AUX.
`the leftmost
`In the top series of packets 32,
`packet contains data representing a code module,
`CM. This is followed by three packets containing
`auxiliary data, AUX,
`followed by another packet
`containing data representing the code module, CM.
`From the series of packets 32 it can be seen that
`the code module is
`repetitively produced. There
`may be more or fewer packets in between succes-
`sive repetitions of the code module packets CM.
`The rate of
`repetition may be specified by the
`programmer when the application is programmed,
`and may be varied during the execution of
`the
`application.
`In the next series of packets 34, the leftmost
`packet contains auxiliary data, AUX. The next two
`packets contain respective portions of a code mod-
`ule (CM1,CM2). The last packet contains auxiliary
`data, AUX. From the series of packets 34 it can be
`seen that
`if a code module is too large to be
`contained in a single packet,
`it may be carried by
`more than one, with each packet containing a por-
`tion of the code module. Although two packets are
`illustrated in the series of packets 34 as containing
`the code module (CM1,CM2), any number of pack-
`ets may be used to carry the code module, de-
`pending upon its size. The two packets carrying
`the code module, (CM1,CM2) are repetitively trans-
`mitted (not shown) in the series of packets 34, as
`described above.
`
`In the series of packets 36, the leftmost packet
`contains data representing a code module (CM).
`The next packet (DM1) is a first packet containing
`data representing a data module. The next packet
`contains
`auxiliary data, AUX. The next packet
`(DM2) is a second packet containing the remaining
`data representing the data module. From the series
`of packets 36 it may be seen that a data module
`(DM1,DM2),
`associated with
`the code module
`(CM), may also be included in the packet stream.
`Both the code module (CM) and the data module
`(DM1,DM2)are repetitively transmitted (not shown)
`in the series of packets 36. The rate of repetition of
`the code module (CM) may be different from that
`of the data module (DM1,DM2), and both rates may
`be specified by the application programmer and
`varied during the execution of the application.
`
`It may further be seen that if the data module
`is too large to be contained in a single packet,
`it
`may be carried by more than one packet, with
`each packet containing a portion of the data mod-
`ule. Although two packets are illustrated in the
`series of packets 36 as containing the data module
`(DM1,DM2), any number of packets may be used
`to carry the data module, depending upon its size.
`It may be further seen that the packets carrying the
`data module need not be transmitted sequentially,
`but may have intervening packets in the packet
`stream. The same is true for multiple packets car-
`rying a code module or directory module (not
`shown).
`the
`In the bottommost series of packets 38,
`leftmost packet contains data representing the di-
`rectory (DIR). The next packet contains data repre-
`senting a code module (CM), followed by a packet
`containing auxiliary data (AUX) and a packet con-
`taining data representing a data module (DM).
`In
`the series of packet 38 all of a directory module
`(DIR), a code module (CM) and a data module
`(DM) in a single packet stream may be seen. The
`respective repetition rates of these three modules
`may be different, as specified by the programmer
`of the application, and may be varied during the
`execution of the application.
`FIGURE 4 is a block diagram of a client com-
`puter 22 asillustrated in FIGURE 1.
`In FIGURE4,
`transport mechanism 30 (of FIGURE 1) is coupled
`to an input terminal of a stream selector 202. An
`output terminal of stream selector 202 is coupled to
`respective input terminals of an auxiliary data ex-
`tractor 204 and a packet data extractor 206. An
`output
`terminal of auxiliary data extractor 204 is
`coupled to the auxiliary data processor 50 (of FIG-
`URE 1). A bidirectional
`terminal of packet data
`extractor 206 is coupled to a corresponding termi-
`nal of a stream I/O adapter 208. A control output
`terminal of stream |/O adapter 208 is coupled to a
`corresponding control
`input terminal of stream se-
`lector 202. The combination of stream selector 202,
`auxiliary data extractor 204 and packet data extrac-
`tor 206 form a data stream receiver 207 for client
`
`computer 22,
`URE 4.
`
`illustrated by a dashed line in FIG-
`
`Stream I/O adapter 208 forms a part of a
`processing unit 224 in client computer 22,
`illus-
`trated by a dashed line in FIGURE 4. In addition to
`the stream I/O adapter 208, processing unit 224
`includes
`a processor 210,
`read/write memory
`(RAM) 212 and read-only memory (ROM) 214
`coupled together in a known manner via a system
`bus 216. Further
`input and output
`facilities are
`provided by an I/O port 218, coupled to the local
`processor 40 (of FIGURE 1); user I/O adapter 220,
`for communicating with user 80; and modem 222,
`coupled to the central processing facility 60 (of
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0452
`EXHIBIT 1003 - PAGE 0452
`
`

`

`17
`
`EP 0 680 185 A2
`
`18
`
`FIGURE 1); all also coupled to the system bus 216
`in a known manner. Other adapters (not shown)
`may be coupled to system bus 216 to provide
`other capabilities to the processing unit 224.
`As described above, auxiliary data extractor
`204, I/O port 218 and modem 222 are not required
`in a client computer 20 according to the present
`invention. They are illustrated in FIGURE 1 and
`FIGURE4 to show optional additional functionality.
`In operation, processor 210 of processing unit
`224 retrieves program instructions permanently
`stored in ROM 214, or temporarily stored in RAM
`212, and executes the retrieved instructions to read
`data from ROM 212 and/or RAM 214, write data to
`RAM 212 and/or receive data from or supply data
`to outside sources via the I/O port 218, user I/O
`adapter 220 and/or modem 222,
`in a known man-
`ner. Under program control, processor 210 may
`also request a code and/or data module from the
`data stream supplied to the client computer 22 via
`the transport mechanism 30 (of FIGURE 1). To
`retrieve this data, processor 210 first
`instructs
`stream V/O adapter 208 to send a selection control
`signal
`to the stream selector 202, possibly in re-
`sponse to user input from user I/O adapter 220.
`Then processor 210 issues a request for a specific
`code or data module to the stream I/O adapter 208.
`Stream I/O adapter 208 relays this request to the
`packet data extractor 204.
`Transport mechanism 30 (of FIGURE 1) sup-
`plies all of the plurality of packet streams (32-38 of
`Figure 3)
`it carries to the stream selector 202,
`which passes only the selected packet stream.
`Auxiliary data extractor 204 monitors the selected
`packet stream, extracts the auxiliary data packets
`from it and supplies them directly to the auxiliary
`data processor 50 (of FIGURE 1). Packet data
`extractor 206 similarly monitors the selected packet
`stream, extracts the directory, code and/or data
`module packets requested by the stream I/O adapt-
`er 208 and supplies them to the stream I/O adapter
`208. The data in the packets returned to the stream
`V/O adapter 208 is supplied to the RAM 212. When
`the entire module has been retrieved from the
`
`packet stream (which may require several packets,
`as described above), processor 210 is notified of
`its receipt by the stream I/O adapter 208. Proces-
`sor 210 may then continue execution of
`its pro-
`gram.
`The data stream in a distributed computing
`system illustrated in FIGURE 1
`is similar to a mass
`storage system in prior art systems. An application
`program executing on the processor 210 makes a
`request for a module listed in the directory in the
`same manner that such a program would make a
`requestfor a file containing a code or data module
`previously stored on a mass storage device in a
`prior art system. The data stream receiver 207 is
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`10
`
`similar to a mass storage device, and stream I/O
`208 acts in a similar manner to a mass storage
`adapter on a prior art system by locating the de-
`sired data, transferring it to a predetermined loca-
`tion (I/O buffer) in the system memory and inform-
`ing the processor of the completion of the retrieval.
`However,
`the stream I/O adapter 208 can only
`retrieve code and data from the data stream; data
`cannotbe written to the data stream.
`
`As described above, the distributed computing
`application may be divided into more than one
`code module, each containing executable code for
`a different portion of the distributed computing ap-
`plication. When a particular code module is de-
`sired, processor 210 requests that code module
`from stream I/O adapter 208. When execution of
`that module has completed, processor 210 re-
`quests the next module from stream I/O 208. Be-
`cause code and data modules are repetitively car-
`ried on the data stream, a module may be deleted
`from RAM 212 when it
`is not currently needed
`without the necessity of temporarily being stored,
`because if
`it
`is
`required later,
`it may again be
`retrieved from the data stream when needed. How-
`
`if RAM 212 has sufficient capacity, processor
`ever,
`210 may request stream I/O adapter to simulta-
`neously load several code modules into RAM 212.
`lf this can be done, then processor 210 may switch
`between code modules without waiting for stream
`VO adapter 208 to extract
`them from the data
`stream.
`
`As described above, other I/O adapters may be
`coupled to the system bus 216 in a known manner.
`For example, in an interactive TV system, a graph-
`ics adapter may be coupled to system bus 216.
`The graphics adapter generates signals represent-
`ing graphical
`images,
`in a known manner,
`in re-
`sponseto instructions from the processor 210. Fur-
`ther, these signals may be combined with the stan-
`dard video signal produced by the video decoder
`(described above) in the auxiliary data processor
`50 of an interactive TV system. When the graphical
`image representative signal and the standard video
`signal are combined, the resulting signal represents
`an image in which the image generated by the
`graphics adapter is superimposed on the image
`represented by the broadcast video signal.
`It
`is
`also possible to selectively combine these two im-
`age representative signals under the control of the
`processor 210.
`An interactive TV system, may also include a
`sound adapter coupled to the system bus 216. The
`sound adapter generates a signal representing a
`computer generated sound (such as music, syn-
`thesized voice or other sound), in a known manner,
`in response to instructions from the processor 210.
`Further, these signals may be combined with the
`standard audio signal produced by the audio de-
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0453
`EXHIBIT 1003 - PAGE 0453
`
`

`

`19
`
`EP 0 680 185 A2
`
`20
`
`coder (described above) in the auxiliary data pro-
`cessor 50 of an interactive TV system. When the
`sound representative signal and the standard audio
`signal are combined, the resulting signal represents
`the combination of
`the sound generated by the
`sound adapter and the broadcast audio signal.
`It is
`also possible to selectively combine these two
`sound representative signals under the control of
`the processor 210.
`The timing of the generation and display of the
`graphical
`image and sound representative signals,
`may be controlled by receipt of the time code data
`from the data stream. This enables an executable
`
`code module to synchronize the display of proces-
`sor generated image and presentation of processor
`generated sound to the broadcast video and aucio.
`It is further possible to synchronize the operation of
`the interactive TV application by the insertion of
`specialized packets into the data stream which
`cause an interrupt of the code currently executing
`in processor 210. Stream I/O 208 monitors the data
`stream for such specialized packets, and generates
`an interrupt,
`in a known manner, for the processor
`210. Processor 210 responds to that interrupt, also
`in known manner, by executing an interrupt service
`routine (ISR). This ISR may be used for synchro-
`nization of the interactive TV application, or other
`purposes.
`A client computer 22 in a distributed computing
`system asillustrated in FIGURE 1 does not need a
`mass storage device, nor a large amount of RAM
`212. Such a system decreases the cost of a client
`computer, and increases the functionality of
`the
`lower cost client computers.
`In addition, such a
`client computer has the option of participating in a
`distributed computing function, may join in the dis-
`tributed computing function at any time (or may
`drop out and return later), and may participate at
`its own pace.
`
`Claims
`
`1. A distributed computer system characterized
`by:
`
`a source (10) of a continuous data stream
`repetitively including data representing a dis-
`tributed computing application; and
`a client computer (20), receiving (207) the
`data stream, extracting (206)
`the distributed
`computing application representative data from
`the data stream, and executing (224) the ex-
`tracted distributed computing application.
`
`2. The computer system of claim 1, further char-
`acterized by
`an
`auxiliary data processor;
`wherein:
`
`the data stream source produces the data
`stream further including auxiliary data; and
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`11
`
`the client computer extracts the auxiliary
`data from the data stream and supplies it to
`the auxiliary data processor.
`
`The computer system of claim 2, characterized
`in that:
`
`the data stream source produces the data
`stream in the form of a series of packets;
`a first one of the series of packets contains
`data representing the distributed computing
`application and includes identification informa-
`tion indicating that the first one of the series of
`packets contains data representing the distrib-
`uted computing application; and
`a second one of
`the series of packets
`contains auxiliary data and includes identifica-
`tion information indicating that the second one
`of the series of packets contains auxiliary data.
`
`The computer system of claim 1, characterized
`in that:
`
`the data stream source simultaneously
`produces
`a_
`plurality
`of
`continuous
`data
`streams, each repetitively including data repre-
`senting a respective distributed computing ap-
`plication; and
`the client computer further includes a data
`receiver for selectively receiving one of
`the
`plurality of data streams, and extracting the
`distributed computing application representa-
`tive data included in the selected one of the
`data streams.
`
`The computer system of claim 4, further char-
`acterized
`by
`an
`auxiliary data processor;
`wherein:
`
`the data stream source produces the data
`stream further including auxiliary data; and
`the client computer extracts the auxiliary
`data from the data stream and supplies it to
`the auxiliary data processor.
`
`The computer system of claim 4, characterized
`in that:
`
`the data stream source produces the data
`stream in the form of a series of packets;
`a first one of the series of packets contains
`data representing the executable code module
`and includes identification information indicat-
`
`ing that the first one of the series of packets
`contains data representing the executable code
`module;
`the series of packets
`a second one of
`contains data representing the data module
`and includes identification information indicat-
`
`ing that the second one of the series of pack-
`ets contains data representing the data mod-
`ule; and
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0454
`EXHIBIT 1003 - PAGE 0454
`
`

`

`a1
`
`EP 0 680 185 A2
`
`22
`
`a third one of the series of packets con-
`tains auxiliary data and includes identification
`information indicating that the third one of the
`series of packets contains auxiliary data.
`
`The computer system of claim 6, characterized
`in that:
`
`the data stream source produces the data
`stream further
`including a directory module
`containing information related to the code
`module; and
`the client computer first extracts the direc-
`tory module from the data stream,
`then ex-
`tracts the code module in response fo the
`information related to the code module in the
`
`extracted directory module, and executes the
`extracted code module.
`
`10.
`
`10
`
`15
`
`11.
`
`The computer system of claim 1, characterized
`in that:
`
`20
`
`the data stream source produces the data
`stream in the form of a series of packets;
`a first one of the series of packets contains
`data representing the executable code module
`and includes identification information indicat-
`
`25
`
`In a distributed computer system, a client com-
`puter (22), characterized by:
`an input terminal (30), for receiving a con-
`tinuous data stream repetitively including data
`representing a distributed computing applica-
`tion
`
`a data stream receiver (207), coupled to
`input
`terminal,
`for
`receiving the data
`the
`stream and extracting (206)
`the distributed
`computing application representative data; and
`a processing unit
`(224), coupled to the
`data stream receiver, for receiving and execut-
`ing (210) the distributed computing application.
`
`The client computer of claim 10, characterized
`in that the processing unit comprises:
`a system bus;
`read/write memory, coupled to the system
`
`bus;
`
`a data stream input/output adapter, coup-
`led between the data stream receiver and the
`
`system bus, for receiving the extracted distrib-
`uted computing application representative data
`from the data stream receiver, and storing it in
`the read/write memory; and
`a processor, coupled to the system bus for
`executing the distributed computing application
`stored in the read/write memory.
`
`The client computer of claim 10, characterized
`in that:
`
`the input terminal receives the data stream
`as a series of packets containing packets car-
`rying the distributed computing application re-
`presentative data; and
`a
`the data stream receiver comprises
`packet data extractor, coupled to the input
`terminal, for extracting the packets carrying the
`distributed computing application representa-
`tive data.
`
`ing that the first one of the series of packets
`contains data representing the executable code
`module;
`the series of packets
`a second one of
`contains data representing the data module
`and includes identification information indicat-
`
`ing that the second one of the series of pack-
`ets contains data representing the data mod-
`ule;
`
`a third one of the series of packets con-
`tains data representing the directory module
`and includes identification information indicat-
`
`ing that the second one of the series of pack-
`ets contains data representing the directory
`module; and
`a fourth one of the series of packets con-
`tains auxiliary data and includes identification
`information indicating that the third one of the
`series of packets contains auxiliary data.
`
`The computer system of claim 8, characterized
`in that:
`
`the data stream source produces the data
`stream further including a data module and a
`directory module further contains information
`related to the data module; and
`the client computer
`further extracts the
`data module from the data stream in response
`to the information related to the data module in
`
`the extracted directory module and executes
`the extracted code module to process the ex-
`tracted data module.
`
`30
`
`12.
`
`35
`
`40
`
`45
`
`50
`
`55
`
`14.
`
`12
`
`13.
`
`The client computer of claim 12, characterized
`in that:
`
`the series of packets in the data stream
`further include packets carrying auxiliary data;
`the client computer
`further
`includes an
`auxiliary data processor; and
`the data stream receiver comprises an
`auxiliary data packet extractor, coupled to the
`auxiliary data processor,
`for extracting the
`packets carrying the auxiliary data from the
`data stream and supplying them to the auxil-
`iary data processor.
`
`The client computer of claim 13, characterized
`in that the distributed computing system is an
`interactive television system, and the auxiliary
`data is television video and audio.
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0455
`EXHIBIT 1003 - PAGE 0455
`
`

`

`23
`
`EP 0 680 185 A2
`
`24
`
`15.
`
`The client computer of claim 10, characterized
`in that:
`
`terminal receives a plurality of
`the input
`data streams, each including data representing
`a respective distributed computing application;
`and
`
`the data stream receiver comprises:
`a data stream selector, coupled to the in-
`put terminal, for producing a selected one of
`the plurality of data streams in response to
`control signals from the processing unit; and
`a_
`distributed
`computing
`representative
`data extractor,
`coupled between the data
`stream selector and the processing unit,
`for
`extracting the distributed computing application
`representative data from the selected one of
`the plurality of data streams.
`
`16.
`
`The client computer of claim 15, characterized
`in that:
`
`the data stream selector comprises a se-
`lection control input terminal, and produces the
`selected one of the plurality of data streams in
`response to a control signal at the selection
`control input terminal;
`the processing unit comprises:
`a system bus;
`read/write memory, coupled to the system
`
`bus;
`
`a data stream input/output adapter, coup-
`led between the data stream receiver and the
`
`system bus, for receiving the extracted distrib-
`uted computing application representative data
`from the data stream receiver, and storing it in
`the read/write memory, and having a control
`output terminal coupled to the selection control
`input terminal of the data stream selector, for
`producing the selection contro! signal; and
`a processor, coupled to the system bus,
`for controlling the data stream input/output de-
`vice to generate a selection control signal se-
`lecting a specified one of the plurality of data
`streams,
`and for executing the distributed
`computing application stored in the read/write
`memory.
`
`17.
`
`The client computer of claim 10, characterized
`in that:
`
`the input terminal receives the distributed
`computing application representative data in-
`cluding an executable code module;
`the data stream receiver extracts the ex-
`ecutable code module; and
`the processing unit executes the extracted
`code module.
`
`18.
`
`The client computer of claim 17, characterized
`in that:
`
`the input terminal receives the distributed
`computing application representative data fur-
`ther
`includes a directory module containing
`information related to the executable code
`module; and
`the data stream receiver first extracts the
`
`directory module from the data stream;
`the processing unit then processes the in-
`formation related to the executable code mod-
`
`ule in the directory module;
`the data stream receiver then extracts the
`executable code module from the data stream
`based on the information related to the execut-
`
`able code module in the extracted directory
`module; and
`the processing unit then executes the ex-
`tracted executable code module.
`
`19.
`
`The client computer of claim 18, characterized
`in that:
`
`the distributed computing application re-
`presentative data further includes a data mod-
`ule and the directory module further contains
`information related to the data module;
`the processing unit further processes the
`information related to the data module in the
`
`directory module;
`the data stream receiver further extracts
`the data module from the data stream based
`on the information related to the data module
`
`in the extracted directory module; and
`the processing unit executes the extracted
`code module to process the extracted data.
`
`The client computer of claim 10 characterized
`in that the distributed computing application is
`divided into a plurality of modules, represent-
`ing portions of the application, and the pro-
`cessing unit stores only modules of said plural-
`ity of modules, necessary to execute the cur-
`rent portion of the application.
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0456
`EXHIBIT 1003 - PAGE 0456
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`20.
`
`40
`
`45
`
`50
`
`55
`
`13
`
`

`

`EP 0 680 185 A2
`
`FIG. 1
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0457
`EXHIBIT 1003 - PAGE 0457
`
`

`

`EP 0 680 185 A2
`
`DATA
`TRANSCEIVER
`
`
` 7103
`
`
`|
`
`FIG. 2
`
`18
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0458
`EXHIBIT 1003 - PAGE 0458
`
`

`

`EP 0 680 185 A2
`
`AUX
`207~
`DATA
`TRANSPORT [sop TOTO oe
`|
`PROCESSOR
`MECHANISM
`AUX
`|-——_____.°
`30
`STREAM
`5
`DATA_
`EXTRACT
`SELECTOR
`2
`|
`LOCAL
`PACKET
`PROCESSOR
`|
`| EXTRACT
`40
`24N —_- ZT :
`—
`ve
`7
`al:
`STREAM
`ie
`|
`|
`
`|
`|
`
`216
`
`0
`
`M2
`
`vO
`
`d
`
`0
`
`USER
`
`oe ~
`
`zz
`
`FIG. 4
`
`PROCESSOR
`60
`
`| USER80
`
`16
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0459
`EXHIBIT 1003 - PAGE 0459
`
`

`

`
`
`(19) —d)
`
`(12)
`
`Europaisches Patentamt
`
`European Patent Office
`
`Office européen des brevets
`
`(11)
`
`EP 0 680 185 A3
`
`EUROPEAN PATENT APPLICATION
`
`(88) Date of publication A3:
`02.05.2002 Bulletin 2002/18
`
`(43) Date of publication A2:
`02.11.1995 Bulletin 1995/44
`
`(21) Application number: 95105803.1
`
`(51) Int ci.7: HO4L 29/06, HOAN 7/24,
`GO6F 9/445
`
`(22) Date of filing: 19.04.1995
`
`
`(84) Designated Contracting States:
`DE ES FR GBIT
`
`(80) Priority: 28.04.1994 US 233908
`
`(71) Applicant: OpenTV,Inc.
`Mountain View, CA 94043 (US)
`
`- Dureau, Vincent
`Venice, California 90291 (US)
`- Jessup, Ansley Wayne, Jr.
`Willingboro, New Jersey 08046 (US)
`« Delpuch, Alain
`Los Angeles, California 90064 (US)
`
`(72) Inventors:
`¢« Joseph, Kuriacose
`Plainsboro, New Jersey 08543 (US)
`289-293 High Holborn
`London WC1V 7HU (GB)
`
`(74) Representative: Freeman, Jacqueline Carol et al
`W.P. THOMPSON & CO.
`Celcon House
`
`(54)
`
`A distributed computer system
`
`A distributed computer system is disclosed
`(57)
`which comprises a source (30) of a continuous data
`stream repetitively including data representing a distrib-
`uted computing application and a client computer (22),
`
`receiving the data stream, for extracting (207) the dis-
`tributed computing application representative data from
`the data stream, and executing (224) the extracted dis-
`tributed computing application.
`
`OATA
`TRANSPORT = @- —- — ar
`|
`PROCES
`MECHANISM [ 22
`AUX
`o| STREAM
`DATA
`|
`—-
`SXTRACTY
`LOCAL
`°F
`PROCESSOR
`DATA
`J
`40
`s
`|
`
`—_— oora ma224 —_— —_— —
`- 7
`STREAM |
`|
`vO
`|
`
`
`
`
`
`vO
`PORT
`
`EP0680185A3
`
`FIG. 4
`
`Printed by Jouve, 75001 PARIS (FR)
`
`IPR2022-01228
`IPR2022-01228
`EXHIBIT 1003 - PAGE 0460
`EXHIBIT 1003 - PAGE 0460
`
`

`

`EP 0 680 185 A3
`
`
`
`European Patent
`Office
`
`EUROPEAN SEARCH REPORT
`
`Application Number
`EP 95 10 5803
`
`DOCUMENTS CONSIDEREDTO BE RELEVANT
`Citation of documentwith indication, where appropriate,
`of relevant
`passa
`US 5 251 301A (COOK GARY M)
`5 October 1993 (1993-10-05)
`* abstract *
`* calumn 1,
`* column 3,
`* colum 4,
`figure 3 *
`* claims 1,6-10 *
`
`line 62 — column 2,
`line 5 ~ line 48 *
`line 57 -—

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