Patent Publication Number: US-2021162295-A1

Title: Method and apparatus for improving efficiency without increasing latency in graphics processing

Description:
CLAIM OF PRIORITY 
     This application is a continuation of U.S. patent application Ser. No. 16/445,092 filed Jun. 18, 2019, the entire disclosures of which are incorporated herein by reference. 
     U.S. patent application Ser. No. 16/445,092 is a continuation of U.S. patent application Ser. No. 15/838,065 filed Dec. 11, 2017, now U.S. Pat. No. 10,350,485, the entire disclosures of which are incorporated herein by reference. 
     U.S. patent application Ser. No. 15/838,065 is a continuation of U.S. patent application Ser. No. 13/631,812 filed Sep. 28, 2012, now U.S. Pat. No. 9,849,372, the entire disclosures of which are incorporated herein by reference. 
    
    
     CROSS-REFERENCE TO RELATED APPLICATION 
     This application is related to commonly-assigned, co-pending provisional application Ser. No. 61/666,628, (Attorney Docket Number SCEA12004US00) filed Jun. 29, 2012, and entitled “DETERMINING TRIGGERS FOR CLOUD-BASED EMULATED GAMES”, the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending provisional application Ser. No. 61/666,645, (Attorney Docket Number SCEA12005US00) filed Jun. 29, 2012, and entitled “HAPTIC ENHANCEMENTS FOR EMULATED VIDEO GAME NOT ORIGINALLY DESIGNED WITH HAPTIC CAPABILITIES”, the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending provisional application Ser. No. 61/666,665, (Attorney Docket Number SCEA12006US00) filed Jun. 29, 2012, and entitled “CONVERSION OF HAPTIC EVENTS INTO SCREEN EVENTS”, the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending provisional application Ser. No. 61/666,679, (Attorney Docket Number SCEA12007US00) filed Jun. 29, 2012, and entitled “SUSPENDING STATE OF CLOUD-BASED LEGACY APPLICATIONS”, the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending application Ser. No. 13/631,725, now U.S. Pat. No. 9,248,374 (Attorney Docket Number SCEA12008US00), filed Sep. 28, 2012, and entitled “REPLAY AND RESUMPTION OF SUSPENDED GAME” to Brian Michael Christopher Watson, Victor Octav Suba Miura, Jacob P. Stine and Nicholas J. Cardell, filed the same day as the present application, the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending application Ser. No. 13/631,740, now U.S. Pat. No. 9,707,476 (Attorney Docket Number SCEA12009US00), filed the same day as the present application, and entitled “METHOD FOR CREATING A MINI-GAME” to Brian Michael Christopher Watson, Victor Octav Suba Miura, and Jacob P. Stine, the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending application Ser. No. 13/631,785, now U.S. Pat. No. 9,694,276 (Attorney Docket Number SCEA12010US00), filed Sep. 28, 2012, and entitled “PRE-LOADING TRANSLATED CODE IN CLOUD BASED EMULATED APPLICATIONS”, to Jacob P. Stine, Victor Octav Suba Miura, Brian Michael Christopher Watson, and Nicholas J. Cardell the entire disclosures of which are incorporated herein by reference. 
     This application is related to commonly-assigned, co-pending application Ser. No. 13/631,803, Published as U.S. Patent Application Publication Number 2014-0092087 (Attorney Docket Number SCEA12011US00), filed Sep. 28, 2012, and entitled “ADAPTIVE LOAD BALANCING IN SOFTWARE EMULATION OF GPU HARDWARE”, to Takayuki Kazama and Victor Octav Suba Miura, the entire disclosures of which are incorporated herein by reference. 
     FIELD OF THE DISCLOSURE 
     The present disclosure is related to video game emulation. Among other things, this application describes a method and apparatus for reducing the latency in emulation of a computer game program. 
     BACKGROUND OF THE INVENTION 
     In a cloud-based gaming system the majority of the processing takes place on the cloud-based server. This allows the client device platform that is communicating with the cloud-based server to have minimal processing power. However, shifting the processing requirements to the cloud increases the possibilities of latencies disrupting the game playing experience. For example, in a first-person shooter game long latencies may reduce a user&#39;s reaction time, and therefore cause the user to be shot when he would otherwise have had time to avoid an incoming attack. 
     The latencies in a cloud-based gaming system may originate from several different sources such as, the network, the client side, the server side, or any combination thereof. By way of example, latencies may be caused by congestion on the network. If a network does not have sufficient bandwidth, the data transfers between the cloud-based gaming system and the client device platform may be delayed. Latencies on the client side may be a result of buffering the incoming data, or even due to variations in the refresh rate of the client&#39;s monitor. Additionally, latencies originating on the server side may include the time it takes to process input data in order to return output data to the client device platform. Therefore, increasing the speed that a cloud-based server processes data may result in substantial reductions in the latency of the system. 
     On a cloud-based system, the client device platform and the network speed may vary between many users. However, the processing capabilities of the server side are the same for each user of the system. Therefore, reductions in latency on the server side will decrease the latency for all users of the system. One solution for increasing the processing speed on the server is to have the cloud-based gaming system run as many operations in parallel as possible. However, running operations in parallel may not help reduce latencies when a game is first started, because at the initiation of the game there may not be any data buffered for the cloud-based gaming system to operate on. Therefore, running operations in parallel during the initiation of a game may not reduce latencies. 
     It is within this context that aspects of the present disclosure arise. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic diagram of a client device platform and an emulator communicating over a network. 
         FIG. 2  is a flow diagram describing a method for reducing the latency of an emulator operating on a network. 
         FIG. 3  is a schematic diagram of the client device platform generating a game input while displaying a game in a first state and thereafter receiving an encoded frame of the second state after the emulator has processed the game input. 
         FIG. 4  is block diagram describing the instructions for how the emulator reduces the latency while processing game inputs according to an aspect of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION OF THE DRAWINGS 
     Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the present disclosure. Accordingly, the aspects of the present disclosure described below are set forth without any loss of generality to, and without imposing limitations upon, the claims that follow this description. 
     Aspects of the present disclosure, describe a method and apparatus may be used to enhance efficiency in emulation of a computer program that involves emulation of both a central processing unit (CPU) and a graphics processing unit (GPU). Certain aspects are particularly advantageously for reducing the latency of the emulation of a computer game over a cloud-based network, particularly where the bottlenecks in processing that can lead to latency are due to the CPU as opposed to the GPU. As used herein, the term “latency” refers to the time delay between the generation of a game input by a client device platform when the game is in a first state and the display of the second state of the game by the client device platform. The game is advanced from the first state to the second state by the emulator processing the game inputs and delivering the resulting frame depicting the second state back to the client device platform. Aspects of the present disclosure describe an emulator that is configured to emulate a client device platform. The emulator may be comprised of an emulated central processing unit (CPU), an emulated graphics processing unit (GPU), and an emulated encoder, each of which may be operated in parallel. However, in order reduce the latency in the emulator, the emulated GPU is delayed until a first set of frames is generated by the emulated CPU. Delaying the start of the emulated GPU allows the emulated GPU to have multiple frames to operate on from the start instead of having to process a single frame at a time. Once the buffer has been built up, the emulated GPU may begin processing frames in parallel with the emulated CPU. 
     General-purpose cloud server architectures have aggressive power-saving features that create some latency between the time a thread begins processing data and the point when the CPU achieves maximum compute throughput. Therefore it is advantageous to queue as sizable a workload as possible before starting the GPU thread, so that the GPU thread has the minimum potential of draining its workload before the frame has been completed. If the GPU runs out of work ahead of time, the thread will fall asleep and will suffer compute throughput latency when new work is submitted. 2. Cloud server operating systems distribute threads across many cores in round-robin fashion to improve heat dissipation and extend CPU component lifespans (rate varies by OS configuration, 2 ms to 10 ms windows are common for servers configured to deliver interactive multimedia content). Each time a thread is switched to a different core the new core&#39;s L1 and L2 cache must be re-primed. When a task, such as the GPU, is able to execute its entire workload quickly without stalls, it increases the likeliness that most or all work is done within a single core instance, and lessens performance lost due to the thread being shifted to a new core. But if the thread stalls frequently during the course of generating a single frame, the operating system may decide to shift it across several different cores in an effort to load-balance against other busier threads. 3. The synchronization model does not benefit the CPU other than by way of simplifying the CPU-GPU communication model so that the CPU is able to spend less time determining if it must await GPU frames to complete. Since the CPU is commonly the latency issue, increasing GPU slightly in favor of reducing the CPU latency more substantially results in an overall latency reduction. However, this may change with the advent of APU processing (integrated CPU and GPU, whereby using the GPU resources can negatively impact available compute power along the CPU pipeline). 4. The model scales well to running multiple instances on a single cloud server which, in turn, can significantly reduce operational cost of the product. By having GPU jobs execute in short, efficient chunks, e.g., at 16 ms (60 hz) or 32 ms (30 hz) intervals, the efficiency and priority heuristics of the operating system multitasking kernel are improved, along with L1 and L2 cache usage and power-saving features of the underlying hardware. Therefore, overall latency/throughput of concurrent emulation systems hosted from a single server is improved. 
     By way of example, and not by way of limitation, at the start of gameplay, a client device platform may deliver one or more inputs to the emulator over the network. The emulated CPU receives the inputs and initiates the generation of a first set of frames. When a frame is generated by the emulated GPU, it is stored in a buffer on the emulator. Once all of the frames in the first set of frames have been produced by the emulated CPU, the contents of the buffer may be delivered to the emulated GPU. Each frame is then rendered by the emulated GPU in order to create rendered frames. The rendered frames may then be delivered to an encoder. Once received by the emulated encoder, the rendered frames are encoded and delivered to the client device platform over the network. 
       FIG. 1  is a schematic of an embodiment of the present invention. Emulator  107  may be accessed by a client device platform  104  over a network  160 . Client device platform  104  may access alternative emulators  107  over the network  160 . Emulators  107  may be identical to each other, or they may each be programed to emulate unique game program titles  106  or unique sets of game program titles  106 . 
     Client device platform  104  may include a central processor unit (CPU)  131 . By way of example, a CPU  131  may include one or more processors, which may be configured according to, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. Client device platform  104  may also include a memory  132  (e.g., RAM, DRAM, ROM, and the like). The CPU  131  may execute a process-control program  133 , portions of which may be stored in the memory  132 . The client device platform  104  may also include well-known support circuits  140 , such as input/output (I/O) circuits  141 , power supplies (P/S)  142 , a clock (CLK)  143  and cache  144 . The client device platform  104  may optionally include a mass storage device  134  such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The client device platform  104  may also optionally include a display unit  137  and a user interface unit  138  to facilitate interaction between the client device platform  104  and a user. The display unit  137  may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit  138  may include a keyboard, mouse, joystick, touch pad, game controller, light pen, or other device. A controller  145  may be connected to the client device platform  104  through the I/O circuit  141  or it may be directly integrated into the client device platform  104 . The controller  145  may facilitate interaction between the client device platform  104  and a user. The controller  145  may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The controller  145  may be capable of generating a haptic response  146 . By way of example and not by way of limitation, the haptic response  146  may be vibrations or any other feedback corresponding to the sense of touch. The client device platform  104  may include a network interface  139 , configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods. 
     The network interface  139  may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic communications network  160 . The network interface  139  may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The client device platform  104  may send and receive data and/or requests for files via one or more data packets over the network  160 . 
     The preceding components may exchange signals with each other via an internal system bus  150 . The client device platform  104  may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein. 
     The emulator  107  may include a central processor unit (CPU)  131 ′. By way of example, a CPU  131 ′ may include one or more processors, which may be configured according to, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The emulator  107  may also include a memory  132 ′ (e.g., RAM, DRAM, ROM, and the like). The CPU  131 ′ may execute a process-control program  133 ′, portions of which may be stored in the memory  132 ′. The process-control program  133 ′ may include programs that emulate a different systems designed to play one or more games  106 . The different system may be a so-called “legacy” system, e.g., an older system. Game programs originally configured to be run on the legacy are sometimes referred to herein as “legacy games”. 
     By way of example, the CPU of a legacy system may be emulated by the emulated CPU  101  and the GPU of the legacy system may be emulated by the emulated GPU  102 . The emulator may optionally be coupled to an encoder  103 , which may be implemented on the CPU  103  or on a separate processor. The emulated CPU  101  and the emulated GPU  102  and the (optional) encoder  103  may be configured to operate in parallel. The emulator  107  may also include well-known support circuits  140 ′, such as input/output (I/O) circuits  141 ′, power supplies (P/S)  142 ′, a clock (CLK)  143 ′ and cache  144 ′. The emulator  107  may optionally include a mass storage device  134 ′ such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The emulator  107  may also optionally include a display unit  137 ′ and user interface unit  138 ′ to facilitate interaction between the emulator  107  and a user who requires direct access to the emulator  107 . The display unit  137 ′ may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit  138 ′ may include a keyboard, mouse, joystick, light pen, or other device. The emulator  107  may include a network interface  139 ′, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods. 
     The network interface  139 ′ may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via the electronic communications network  160 . The network interface  139 ′ may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The emulator  107  may send and receive data and/or requests for files via one or more data packets over the network  160 . 
     The preceding components may exchange signals with each other via an internal system bus  150 ′. The emulator  107  may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein. 
     Emulator  107  may access a game program  106 , (e.g., a legacy game program) that has been selected by the client device platform  104  for emulation through the internal system bus  150 ′. There may be more than one game program  106  stored in the emulator. The game programs may also be stored in the memory  132 ′ or in the mass storage device  134 ′. Additionally, one or more game programs  106  may be stored at a remote location accessible to the emulator  107  over the network  160 . Each game program  106  contains executable game code  108  that is used by the emulated CPU  101  to generate the frames  212  in response to inputs  211  from the client device platform  104 . 
     By way of example, the game program  106  that is emulated may be any game program that is not compatible with a client device platform  104 . By way of example, and not by way of limitation, the game program  106  may be a legacy game designed to be played on Sony Computer Entertainment&#39;s PlayStation console, but the client device platform  104  is a home computer. By way of alternative example, the game program  106  may have been designed to be played on a PlayStation 2 console, but the client device platform  104  is a PlayStation 3 console. By way of further example and not by way of limitation, a game program  106  may have been designed to be played on a PlayStation console, but the client device platform  104  is a hand held console such as the PlayStation Vita from Sony Computer Entertainment. 
       FIG. 2  is a flow diagram of a method  200  for reducing the latency of the emulation of a legacy game  106  over a cloud-based network.  FIG. 2  depicts a client device platform  104  communicating with an emulator  107  over a network  160 . The dotted arrows represent data being delivered over the network  160 . Rectangular boxes represent processing steps, and the parallelograms represent the various forms of data being transferred. The emulator  107  may be comprised of an emulated CPU  101  and an emulated GPU  102 . Certain optional parts of the method may be implemented on an encoder  103 . The emulated CPU  101 , the Emulated GPU  102 , and (optionally) the encoder  103  may be operated in parallel with each other. 
     The emulation method  200  begins with the client device platform  104  generating one or more game inputs  211  at block  251 . By way of example, and not by way of limitation, the game inputs  211  may be commands that control the game play of a game program  106 . Game inputs  211  which control the game play may include commands that are generally used by a game player to advance the game program  106  from a first state  301  to a second state  302 . The game inputs  211  may be generated by a controller  145 , or they may be automatically generated by the client device platform  104 . Game inputs  211  may include, but are not limited to, inputs that cause a main character in a game program  106  to move to a new position, swing a sword, select an item from a menu, or any other action that can take place during the game play of a game program  106 . As shown in  FIG. 3 , the game input  211  is generated by the game player pressing the X-button  145   X . The pressing of the X-button  145   X  is designated by the button being shaded, whereas the other buttons remain white. 
       FIG. 3  is a simplified schematic diagram of the emulation process depicting the advancement from the first state  301  to the second state  302 . For purposes of clarity, the processing that takes place within the emulator  107  has been omitted from  FIG. 3 . The first state  301 , as shown on display screen  137   T=0 , is comprised of the main character  340  standing to the left of a large crevasse. The second state  302 , as shown on display screen  137   T=1 , is comprised of the main character  340  after it has been instructed, by a game input  211 , to jump in the upwards direction. The labels  137   T=0  and  137   T=1  are used in order to indicate that a period of time has elapsed between the time the game input  211  is generated (T=0) and the time that the result of the game input  211  is first displayed on the client device platform  104  (T=1). The period of time between T=0 and T=1 is considered the latency. The large gap between the main character  340  and the ground in the second state  302  was chosen to clearly indicate a jump has been made. However, it should be noted that the time T=1 is the time at which the first frame of the jump is displayed by the client device platform  104 . 
     Returning to  FIG. 2 , after the game inputs  211  have been generated, the client device platform  104  delivers them to the emulator  107  over the network  160 , as indicated by block  252 . The emulator  104  receives the inputs  211  with the emulated CPU  101  at block  253 . At this point, the emulated CPU  101  begins processing the game inputs  211  in order to generate a first set of frames  212  at block  254 . The emulated CPU may utilize the executable game code  108  of the game program  106  in order to process the game inputs  211 . By way of example, and not by way of limitation, the generation of the first set of frames may include the generation of display lists for the frames, the generation of graphics primitives, or any other high level graphics processing operations. Other steps that may be performed by the emulated CPU while it is generating the first set of frames before the frames are ready for rendering by the emulated GPU include, but are not limited to video decoding, audio mixing, and the like which in emulators is often unable to be generated asynchronously from the CPU. The first set of frames  212  may be comprised of one or more individual frames, e.g. approximately two frames, depending on the specifics of the hardware being implemented. By way of example, and not by way of limitation, the optimum quantity in emulation of certain titles is typically two (2) at 60 hz. This is because the great majority of titles for certain legacy platforms, such as the PlayStation (sometimes known as the PlayStation 1 or PS1) run their CPU-side update logic at 30 hz, not 60 hz. The second frame is a tween or interlace frame meant to improve visual animation fluidity, and does not vary based on user input. Interlocking the CPU in between these 30 hz frame-pairs does not reduce latency or improve gameplay experience. This behavior can usually be determined based on the video mode selection made by the legacy title. 
     After each individual frame in the first group of frames  212  is processed, it is stored in a buffer as indicated by block  255 . The buffer may be in the memory  132 ′ of the emulator  107 . By way of example, it may take approximately 10-12 milliseconds to finish processing the entire first set of frames  212  and store them all in the buffer. Once all of the frames in the first set of frames  212  have been stored in the buffer, the emulated CPU  101  may deliver the first set of frames  212  to the emulated GPU  102  as indicated by block  256 . Alternatively, the emulated CPU  101  may send the location of first set of frames  212  to the emulated GPU  102 , and the emulated GPU  102  may then retrieve the first set of frames  212  from the buffer. 
     At block  257  the emulated GPU  102  receives the first set of frames  212 . Until this time, the emulated GPU  102  has been idle. It would appear that keeping one of the processing units idle for a period of time would increase the latency of the emulator, but the inventors have determined that this is not the case. Delaying the start of the emulated GPU  102  allows a large buffer of work to be available for the emulated GPU  102  to process. Further, the processing by the emulated GPU  102  may then be done in parallel with the emulated CPU  101  while it begins processing of a second set of frames  212 ′. Further, by waiting for the emulated CPU  101  to finish processing the first set of frames  212  before the emulated GPU  102  is initiated, the emulated CPU  101  may run more efficiently. 
     The emulated GPU  102  begins rendering the first set of frames  212  at block  258 . Rendering the frames may comprise processing the frames according to a standard graphics pipeline. By way of example and not by way of limitation, a standard graphics pipeline may include vertex processing, clipping, primitive assembly, triangle setup, rasterization, occlusion culling, parameter interpolation, pixel shading, and frame buffering. Further by way of example, and not by way of limitation, the rasterization may be tile-based rasterization. Tile-based rasterization is described in detail in commonly-assigned, co-pending application Ser. No. 13/631,803, (Published as U.S. Patent Application Publication Number 20140092087), the entire disclosure of which has been incorporated by reference. Rendered frames  213  may then optionally be delivered to the encoder  103  at block  259 . The rendered frames  213  may be delivered once all frames in the first group of frames  212  have been rendered, or each rendered frame  213  may be delivered to the encoder  103  immediately after it has been rendered. Additionally, the rendered frames  213  may be stored in a frame buffer in a memory  132 ′ on the emulator  107  and the encoder  103  may be provided with the location of the rendered frames so that it may retrieve the rendered frames  213 . 
     At block  260  the encoder  103  may optionally receive the rendered frames  213 . Thereafter the encoder  103  may optionally initiate the encoding process. The rendered frames  213  may be encoded according to a proprietary or a standard codec. The encoder  103  may utilize I-frames, P-frames, and B-frames, or any combination thereof. By way of the example, and not by way of limitation, the emulated encoder  103  may use MPEG-4, H.264/MPEG-4 AVC, or WMV codecs. Once the frames have been encoded, the encoded frames  214  may be delivered to the client device platform  104  over the network  160 . The client device platform may receive the encoded frames  214  at block  263 . 
     As shown in  FIG. 4 , a set of emulator instructions  470  may be implemented, e.g., by the emulator  107 . The emulator instructions  470  may be formed on a non-transitory computer readable medium such as the memory  132 ′ or the mass storage device  134 ′. The emulator instructions  470  may also be part of the process control program  133 ′. The emulator instructions may also be implemented through separate emulation programs such as the emulated CPU  101 , the emulated GPU  102 , or the emulated encoder  103 , or it may be implemented by any combination thereof. 
     The instructions include instructions for receiving inputs  211 , e.g., over the network  160  from the client device platform  104 , as indicated at  473 . Thereafter the emulated CPU  101  may be instructed to begin processing the inputs  211  in order to generate a first set of frames  212 , e.g., by executing instructions as indicated at  474 . Next, the emulator  107  may be instructed to store each of the frames from the first set of frames  212  into a buffer on the emulator  107  by executing instructions as indicated at  475 . Once all of the frames from the first set of frames  212  have been generated, the emulator  107  may be instructed to deliver the first set of frames to the emulated GPU  102  by executing instructions as indicated at  476 . The emulated GPU  102  may be provided with instructions for receiving the first set of frames  212  as indicated at  477 . At this point the emulated GPU  102  may begin rendering the first set of frames  212  at  478 . Until this point, the emulated GPU  102  may have been instructed to be idle in order to allow for a sufficient buffer to be built. The emulator  107  may optionally be further instructed to deliver the rendered frames  213  to the emulated encoder  103  by executing instructions as indicated at  479 . The emulated encoder  103  may be provided with instructions for receiving the rendered frames  213  as indicated at  480 . When the emulated encoder  103  receives the rendered frames  213 , it may optionally be provided with instructions for encoding the first set of rendered frames  213  as indicated at  481 . Thereafter, the encoder  103  may optionally be provided with instructions for delivering the encoded first set of frames  214  to the client device platform  104 , e.g., over the network  160 , as indicated at  482 . 
     While the above is a complete description of the preferred embodiment of the present invention, it is possible to use various alternatives, modifications and equivalents. Therefore, the scope of the present invention should be determined not with reference to the above description but should, instead, be determined with reference to the appended claims, along with their full scope of equivalents. Any feature described herein, whether preferred or not, may be combined with any other feature described herein, whether preferred or not. In the claims that follow, the indefinite article “A”, or “An” refers to a quantity of one or more of the item following the article, except where expressly stated otherwise. The appended claims are not to be interpreted as including means-plus-function limitations, unless such a limitation is explicitly recited in a given claim using the phrase “means for.”