Abstract:
The present invention provides a seamless game world system in the field of massively multiplayer online games, comprising a plurality of game servers and at least a client, each of the game servers being assigned to a zone in the game world divided into zones. The seamless game world comprises: a game logic computing module for computing an avatar&#39;s new status; a map controller for detecting whether an area of interest of the avatar has crossed the border of a host server of the avatar and spanned neighbor game servers based on the avatar&#39;s new status computed by the avatar computing module, and determining to make/delete a clone on a neighbor game server or synchronize the clone&#39;s status based on the detected result; and an avatar status update module for performing a normal status update on the avatar based on the computed result of the game logic computing module after the map controller notices its neighbor game server to delete the clone from an avatar list.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention generally relates to a computer system for online gaming and the method thereof, in particularly to a seamless game world system for chaining a game world partition divided into several small-scale game worlds in massive multiplayer online games based on client/server architecture to form a whole game world, and method thereof.  
       BACKGROUND OF THE INVENTION  
       [0002]     With the advent of the Internet and wireless communication, massively multiplayer online games (MMOG) are becoming more popular in recent years. While P2P architecture has been discussed in academic fields for some time, and there are some games implemented in P2P manner, most commercially operated MMOG are provided in a typical client/server architecture for game security and management purposes.  
         [0003]     In the MMOG in the form of client/server architecture, players run a client program on their local game hardware (typically a PC or a game console) that acts only as an input/output device. The local machine accepts commands input from a remote game server and renders the player&#39;s view of the game world, sending keystrokes, mouse movements or controller commands across the network to signal the player&#39;s action within the game. Every player is represented in the game world by an entity called “avatar”, whose state is controlled by the user input. Most or all of the processing required to manage the game world&#39;s state is handled by the game logic executing on a remote server.  
         [0004]     The game logic server typically performs all computation needed to manage the game world state. In large-scale online games, because the whole game world is very large and no single server can support all the activities in game world alone, the game world is normally divided into several small ones and a cluster of game servers serve the participating game world together. Since the single server architecture (a single server serving the whole world) is very simple, it is the technology of multi-server architecture that will be addressed.  
         [0005]     In MMOG, the structured diagram is mapped onto distinct server clusters. Such a kind of map is introduced in Jarett A, Estanislao J, Dunin E, MacLean J, Robbins B, Rohrl D, Welch J and Valadares J, “(2003) IGDA Online Games White Paper”, pp63-64, 2003. In this document, the most common means for partitioning of the game world is to divide distinct geographical regions within a game world into zones, assigning one zone to a game server. Every zone is composed of many cells which are the basic map units. Neighbor cells are chained together to compose the zone, and then neighbor zones on different servers are chained together to form the whole game world.  
         [0006]     Referring to  FIG. 1 , an example of the game world is shown. In  FIG. 1 , the game world is composed of  4  zones, which are Zone  1 , Zone  2 , Zone  3  and Zone  4 , respectively. Zone  1  is composed of 16 basic map units, i.e. cells, Zone  2  is composed of 24 cells, Zone  3  is composed of 24 cells, and Zone  4  is composed of 36 cells. Zone  1 , Zone  2 , Zone  3  and Zone  4  are assigned to Computer  1 , Computer  2 , Computer  3  and Computer  4  as servers, respectively.  
         [0007]     To increase the number of simultaneous participants by reducing network bandwidth requirements, the entities usually disseminate update packets only to those nodes relevant to them, which are in the so-called AOI (area of interest). In multi-server MMOG, the avatar&#39;s AOI may cross the border. So, according to the zone interaction and AOI management method, the multi-server MMOG can be divided into two kinds. One of the two kinds of online game is a discrete game world. In this architecture, game worlds are zoned and each zoned has a boundary to prohibit players from being aware of events occurred outside. Switching between zones can be done only through switching a connection from a current game server to the one that serves the target zone.  
         [0008]     The discrete game world has three major shortcomings, the first of which is that there is an obvious interruption of game-playing felt when switching between two zones served by different servers. In fact, switching between two zones is implemented by the game logic discharging the avatar from the original server first and then performing logins it to another server. So the player will have the serious problem of abrupt visual effect on the client site. A second shortcoming is that the border of a zone prohibits the player from seeing another side of the game world, which in turn reduces the interaction and fun of the game. The third shortcoming is that the difficulty of dynamic load balancing among game server farms is increased (i.e. batch movement of avatar without influence on the business-as-usual (BAU) of game servers is a very challenging task.) Another kind of MMOG is a continuous or seamless game world. In contrast to the discrete game world, in zoned game worlds, MMOG can be designed to create seamless worlds in which a player can do whatever he does in the discrete game world without the boundary limitation. The player may interact with objects, computer-controlled characters or other players that are themselves executing on servers other than the player&#39;s. There are a number of benefits to the use of seamless game world design for MMOG.  
         [0009]     In the continuous or seamless game world, game designers can plan their game content on a larger and continual game world, which enables them to design more complicated/comprehensive contents. As the scale of the game world is becoming larger and more players are in the game world, the amounts of interaction will be increased and thus trigger some more advanced playing style—like more complicate organized communities and more transactions of virtual assets, which will increase the fun of gaming. In addition, the granularity of dynamic load balance could be adjusted according to real load rather than the static game world partition.  
         [0010]     For the advantages of the seamless game world, the way of forming a seamless game world system is important. To form a continuous game world: first, when the AOI (or visual range) of an avatar on a game server crosses other servers, he can be aware of entities on other servers which are still in his aura. Second, avatars can migrate from one server into another seamlessly and smoothly with a very small cost, and the continuity of the game experience of the avatars is guaranteed.  
         [0011]     Existing systems which provide this functionality use a buffer zone method. By overlapping the cells on the border of the region managed by a server with its adjacent server, the border cells are used as the buffer zone. Once an avatar enters the border zone, both servers will have a copy of an instance. This kind of method is disclosed by Jiung-yao Huang,Yi-chang Du and Chien-Min Wang in “Design of the Server Cluster to Support Avatar Migration” (Proceedings of IEEE Virtual Reality 2003(VR&#39;03), pp7-14, 2003). For the complexity of this method, it always requires the map to be regularly partitioned into a fixed size and shape beforehand, and then chained with an interleaved-squaring method.  
         [0012]     The main weaknesses of the buffered zone solution are: the game map needs to be reconstructed, the map cell&#39;s shape and size are also limited, and there is a paradox in dealing with the dynamically changing AOI. If the maximum AOI is adopted as the scope of overlapped area, it will increase the redundant computing and communication load of them and reduce the overall resource usage rate of the game server farm.  
       SUMMARY OF THE INVENTION  
       [0013]     Therefore, an object of the present invention is to provide a seamless game world system in which all players have a consistent seamless game world view, and the operation method thereof, so that when the AOI of an avatar on a game serve crosses other servers, he can be aware of entities on other servers which are still in his aura, and he can also migrate from one server into another seamlessly.  
         [0014]     In order to achieve the above and other objects of the present invention, according to one aspect of the present invention, a seamless game world system comprising a plurality of game servers and at least a client is provided, each said game logic server being assigned to a zone in the game world divided into zones for executing all the computations required to manage the status of the game world, said client being controlled by a player to accept commands input from a remote game server, render the player&#39;s view of the game world, and send keystroke, mouse or controller commands across the network to signal an avatar&#39;s move within the game, said avatar being an entity of the player in the game world whose status is controlled by the user input, characterized in that said seamless game world comprises: a game logic computing module for computing an avatar&#39;s new status; a map controller for detecting whether an area of interest of the avatar has crossed the border of a host server of the avatar and spanned neighbor game servers based on the avatar&#39;s new status computed by said game logic computing module, and determining to make/delete a clone on a neighbor game server or synchronize the clone&#39;s status based on the detected result, said clone representing the incarnation of a doer avatar on a neighbor server, said doer avatar being an avatar with a clone avatar; and an avatar status update module for performing a normal status update on the avatar based on the computed result of the game logic computing module after the map controller notices its neighbor game server to delete the clone from an avatar list.  
         [0015]     According to one aspect of the present invention, a method for realizing a seamless game world for every player of a game world, the game world being divided into zones, each zone being assigned to a game server for management, a player controlling a client to accept commands input from a remote game server, render the player&#39;s view of the game world, and send keystroke, mouse or controller commands across the network to signal an avatar&#39;s move within the game, said avatar being an entity of the player in the game world whose status is controlled by the user input, characterized in that said method comprises the steps of: computing an avatar&#39;s new status; detecting whether an area of interest of the avatar has crossed the zone border of a host server of the avatar and spanned neighbor game servers based on the computed avatar&#39;s new status; determining to make/delete a clone on a neighbor game server or synchronize the clone&#39;s status based on the detected result, said clone representing the incarnation of a doer avatar on a neighbor server, said doer avatar being an avatar with a clone avatar; and performing a normal status update on the avatar based on the computed result after deleting the clone from an avatar list.  
         [0016]     According to one aspect of the present invention, a computer readable media containing instructions for executing the above method is also provided.  
         [0017]     The map controller can be implemented as a module which has the responsibility to manage the clone and acts as the “hidden hand” between the game application and players, so there is no special requirement for the legacy game system, and different avatar&#39;s view scopes can be changed flexibly and there is no redundant clone avatar. In addition, the method according to the present invention has no limitation on the map structure. It can be easily adopted in the improvement of legacy games. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0018]     Those skilled in the art can understand the present invention better by referring to the drawings wherein like reference numbers indicate similar or the same element(s) throughout the drawings, in which:  
         [0019]      FIG. 1  shows an example of a game world;  
         [0020]      FIG. 2  shows a block diagram of the seamless game world system according to the present invention;  
         [0021]      FIG. 3  shows a block diagram of map controller  210  according to the present invention;  
         [0022]      FIG. 4  is a flowchart showing the complete status update of the map controller  210  according to the present invention;  
         [0023]      FIG. 5  is a schematic diagram showing, when an avatar&#39;s area of interest spans a game server, a different game server updates a corresponding area of interest to a client; and  
         [0024]      FIG. 6  is a flowchart illustrating the operation of the map controller  210 .  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0025]     The following description is used to provide a detailed depiction of an example of the present invention, and should not be used to limit the present invention. In contrast, any number of changes of the present invention may all fall into the invention scope defined by the claims appended to the specification.  
         [0026]      FIG. 2  shows a block diagram of a game server in the seamless game world system using a map controller according to the present invention. Referring to  FIG. 2 , the seamless game world system using a map controller according to the present invention comprises a plurality of game servers and at least one client (not shown). The seamless game world system further comprises a game logic computing module  200 , a map controller  210  and a avatar status update module  220 . The map controller  210  is positioned between a normal game logic computing module  200  and a player&#39;s avatar status update module  220 , and is integrated with the game application runtime.  
         [0027]     In the above seamless game world system using the map controller  210  according to the present invention, to facilitate the smooth avatar migration, when the AOI of an avatar moves out of its zone and enters into one or more zones served by adjacent game servers, clones of the avatar are created on the servers corresponding to these zones. By the term “clone”, the present invention means the incarnation of the doer avatar on another server. Actually, the doer avatar and its clone cannot be perceived by a player, and are considered as the same object. The incarnation is called “a clone” only for convenience of description.  
         [0028]     Hereinafter, an avatar (doer avatar) that has a clone avatar is called a doer. The main difference between a doer and a clone lies in the following two aspects. On one hand, a doer is a conventional avatar for which its host server computes its status change and updates it to the client by using the game logic computing module  200 . The map controller  210  then updates its clone avatar according to the computed new status. According to the map neighboring relation, a doer avatar can have several clone avatars.  
         [0029]     On the other hand, a clone is a representative of a doer and its host server does not compute its status by using the game logic computing module  200 . The host server for a clone only updates it according to its new status received from the doer&#39;s host server. The clone&#39;s host server also adds the clone to its player list, and uses a tag to identify that it is a clone. In the status update cycle, the clone avatar&#39;s host server updates the entities in the clone&#39;s AOI to the client by using the map controller  210 .  
         [0030]     It should be noted that any change of status on a doer will be synchronized to the clone(s) through the network protocol or under the support of communication middleware.  
         [0031]     To implement the function of the seamless game world system of the present invention, the game logic computing module  200  computes an avatar&#39;s new status. After the game logic module  200  computes out the avatar&#39;s new status, the map controller  210  will take the responsibility of handling the avatar&#39;s AOI change based on the computation result of the game logic computing module  200 . The map controller  210  further has the capability of keeping a unique status view for every avatar according to the policy of the game world. To achieve this, the map controller  210  will monitor the status change of an avatar, and detect whether or not the avatar&#39;s AOI crosses the border of the avatar&#39;s host server and spans to a neighbor server. Moreover, different from the way that prescribes an overlap zone as the buffer zone, the map controller  210  makes clone avatars at neighbor servers according to the individual avatar&#39;s AOI and other private policies. After making clone avatars at neighbor servers, the map controller  210  will be responsible for updating any change of the avatar to all clones. Specifically, the doer avatar&#39;s host server computes out the avatar&#39;s new status by using the game logic computing module  200 , and the map controller  210  will update it to all the clones. In the doer avatar&#39;s update cycle, the server will update the avatar&#39;s AOI on it to the client, and the neighbor server will also compute the clone&#39;s AOI on it to the client. The detail of this process will be explained later in conjunction with  FIG. 5 .  
         [0032]     Once the avatar&#39;s AOI is no longer spanning the map of neighboring servers, then the map controller  210  of the doer server will notify its neighbors to delete the clone from the avatar list. Then the avatar goes back to the normal computing and updating status.  
         [0033]     Once the avatar crosses the map border of its host server and goes into the map of an immigrated server, then the map controller  210  of the doer server will notice its peer on the immigrated server, and the migration process is completed by changing the avatar on the original into a clone avatar and changing the immigrated server&#39;s agent avatar into a doer avatar. When the avatar eventually migrates into the immigrated server, it is then taken over by the immigrated server immediately since its information already exists at the immigrated server.  
         [0034]      FIG. 3  shows the block diagram of the map controller  210  according to the present invention. Referring to  FIG. 3 , the map controller  210  consists of a clone detector  320 , a clone planner  340 , a clone plan sender  350 , a clone plan receiver and manager  360  and a map information pool (i.e. a map-server table memory)  330 .  
         [0035]     The clone detector  320  is responsible for detecting whether to make a clone, delete a clone or synchronize a clone&#39;s status. Specifically, the clone detector  320  receives the avatar&#39;s newest status from the game logic computing module  200  and makes a decision about whether to make a clone, delete a clone or synchronize a clone&#39;s status according to the information and avatar setting in the map-server table memory  330 .  
         [0036]     If the clone detector  320  decides to make a clone, delete a clone or update a clone&#39;s status, then the clone planner  340  generates a clone plan, which includes the participant neighbors (destination) and the action(s) of: (1) adding a clone, (2) deleting a clone, or (3) updating a clone status. To update a clone status, the clone plan also includes the avatar&#39;s newest status to be synchronized. Here every status has several different actions corresponding to different neighbor game servers.  
         [0037]     If the clone detector  320  decides not to make a clone, delete a clone or update a clone&#39;s status, then no action of clone adding, deleting or clone&#39;s status synchronizing is done, that is to say, the clone planner  340  will do nothing in this case.  
         [0038]     The clone plan sender  350  is responsible for sending action commands to its neighbors. Specifically, the clone plan sender  350  first reads the plan&#39;s destination item (the neighbor&#39;s address), then sends commands to different destinations through the network protocol or via communication middleware.  
         [0039]     The clone plan receiver and manager  360  is responsible for collecting all its neighbor game server&#39;s clone plans sent by its peers, and then doing the clone adding, deleting or status synchronizing process according to the clone plan information.  
         [0040]     The map-server table memory  330  is a persistent or temporary storage that describes the server-map relationship and the neighbor relationship between zone maps.  
         [0041]     In an embodiment of the present invention, the map controller  210  further comprises a game policy builder  310  and an avatar policy database memory  315 . The policy builder  310  collects an avatar&#39;s policy layer information negotiated by the game logic module  200  to build an avatar policy and store it in the avatar policy database memory  315 . The avatar policy includes the avatar&#39;s view scope and other special information (such as landscape etc.) which can be used to compute the avatar&#39;s AOI.  
         [0042]     The map controller  210  is running on the same game application runtime. The game application runtime supports the avatar game logic process being executed as designed by the game application. The map controller  210  begins its operation after the avatar status computing module  200  computes the result, and does not end the operation until the avatar status update module  220  begins to operate. The map controller  210  realizes the seamless game world for every player of the game world.  
         [0043]     The above functions of the map controller  210  can be implemented by making it execute the steps shown in  FIG. 4 .  FIG. 4  is a flowchart showing a complete status update. Referring to  FIG. 4 , at step S 410 , the map controller  210  monitors the status change of an avatar, and detects whether or not the avatar&#39;s AOI crosses the border of the avatar&#39;s host server and spans to neighbor game servers.  
         [0044]     If it is detected at step S 410  that the avatar&#39;s AOI is inside the border, i.e. the avatar&#39;s AOI does not cross the border and does not span to neighbor game servers, then the process proceeds to step S 420 , at which the map controller  210  notifies the doer server to update the avatar&#39;s status according to the new status of the avatar computed by the game logic computing module  200 .  
         [0045]     If it is detected at step S 410  that the avatar&#39;s AOI crosses the zone border of its host server and spans to neighbor game servers, then the process proceeds to step S 430 , at which the map controller  210  makes clones at neighbor servers according to the individual avatar&#39;s AOI and other privacy policies.  
         [0046]     Then the process proceeds to step S 440 , at which the doer server computes out the avatar&#39;s new status by using the game logic computing module  200 , and synchronizes the clone&#39;s status by using the map controller  210 .  
         [0047]     Next, the process proceeds to step S 450 , at which the doer server and the neighbor game servers perform status updates on the same avatar.  
         [0048]     Next, the process proceeds to step S 465 , at which the map controller  210  detects whether the avatar&#39;s AOI spans the map of the one server and enters into the zone of an immigrated server. If it is detected at step S 465  that the avatar&#39;s AOI is no longer spanning the map of the one server, then the process proceeds to step S 460 , at which the map controller  210  will notify the neighbor game servers to delete the clone from the avatar list. Then the process returns to step S 420 .  
         [0049]     If it is detected at step S 465  that the avatar crosses the zone border of its host server and goes into the zone of the immigrated server, then the process proceeds to step S 470 , at which the map controller  210  will notify its peer on the immigrated server, and the migration process is completed by changing the avatar that was the doer avatar into a clone avatar and changing the immigrated server&#39;s agent avatar into a doer avatar.  
         [0050]     Then the process proceeds to step S 480 , at which the avatar&#39;s status is computed in the immigrated server and the status update process is completed.  
         [0051]     The detail of forming a seamless game world view by a player will be described with respect to  FIG. 5 .  FIG. 5  is a schematic diagram showing, when an avatar&#39;s AOI spans a server, a different server updates a corresponding AOI to a client. Referring to  FIG. 5 , once the map controller  210  finds that one avatar&#39;s AOI is out of its zone, it then notifies the related neighbor peers to make a clone.  
         [0052]     The process that, in a doer avatar&#39;s update period, a server updates an avatar&#39;s AOI on it to a client and a neighbor game server computes a clone&#39;s AOI on it to the client will be described in detail in conjunction with  FIG. 5 .  
         [0053]     As shown in  FIG. 5 , the zone controlled by server A as a doer server is indicated by a blank block, and the zone controlled by sever B as a neighbor game server is indicated by a hatched block.  
         [0054]     Reference number  500  indicates a schematic diagram showing that an avatar&#39;s AOI spans a server. In this schematic diagram, zone  510  indicates the AOI of a player at position P 1 , and when the player moves from position P 1  to position P 2 , the AOI of the player at position P 2  is indicated by zone  520 . It can be seen from the diagram shown by reference number  500  that the AOI of the player at position P 2  spans the zone of the neighbor game server. In this case, the map controller  210  will make a clone avatar in the neighbor game server (server B), and synchronize the clone avatar&#39;s status with the doer avatar&#39;s status.  
         [0055]     In order to make a clone and synchronize a clone&#39;s status, when a player moves from position P 1  to position P 2  and the AOI of the player spans the zone of a neighbor game server, the commands of the player will still be sent to server A.  
         [0056]     Reference number  500 ′ indicates a schematic diagram illustrating the making of a clone and the synchronizing of a clone&#39;s status. In this schematic diagram, zone  530  indicates the part of an avatar&#39;s AOI in the zone controlled by server A, and zone  540  indicates the part of the avatar&#39;s AOI in the zone controlled by server B. Zone  530  is operated by a doer avatar, and zone  540  is operated by a clone avatar. The player sends his commands to server A. Server A processes the commands sent by the player based on game logic and sends its status update message to the doer avatar (a part of the view). In addition, during the update of server B, the status update message is also sent to the clone avatar (another part of the view), thereby to achieve the object of updating a new avatar&#39;s AOI to a client. By the above process, the client has a continuous view which is controlled by server A and server B, respectively.  
         [0057]     The method adopted by the map controller  210  is described in detail in conjunction with  FIG. 6  as follows.  FIG. 6  is a flowchart illustrating the operation of the map controller  210 . Referring to  FIG. 6 , at step S 610 , the map controller  210  calls the clone detector  320  after the game logic computing module  200  receives a player&#39;s command and computes the avatar&#39;s new status, so as to make a decision on whether to make a clone, delete a clone or synchronize a clone&#39;s status according to the computed avatar&#39;s current status, its policies and the map-server table.  
         [0058]     If it is decided at step S 610  to make a clone, delete a clone or update an existing clone&#39;s status, then the process proceeds to step S 620 , at which the clone planner  340  generates a clone plan, which includes the participant neighbors (destination) and the action(s) of: (1) adding a clone, (2) deleting a clone, or (3) updating a clone status. For the updating action, it also includes the avatar&#39;s newest status that needs to be synchronized. Every plan may have several different action items corresponding to different neighbor game servers. Then the process proceeds to step S 630 .  
         [0059]     If it is decided at step S 610  not to make a clone, delete a clone, or update an existing clone&#39;s status, then the process goes directly to step S 640 , at which the neighbor plan collecting and handling process is done so as to collect the neighbor&#39;s clone plans and perform corresponding processing according to the commands of the collected clone plans.  
         [0060]     At step S 630 , the clone plan sender  350  sends action commands of the clone plans to its neighbors according to the plans&#39; destination items (of the neighbors) through network protocol or via communication middleware. Then the process proceeds to step S 640 .  
         [0061]     Next at step S 640 , the plan receiver and manager  360  collects all its neighbor&#39;s plans sent by its peers, does the clone adding, deleting or status synchronizing process according to the clone plans. Then the process proceeds to step S 650 .  
         [0062]     Next at step S 650 , after all the clone plans are executed at step S 640 , in the doer&#39;s update cycle, its server updates the avatar&#39;s AOI on it to the client, the clone server will also compute the clone&#39;s AOI on it and update the information to the client.  
         [0063]     It can be seen from the description of the above embodiment according to the present invention that, by adding the map controller  210  between the game logic computing module  200  and the avatar status updating module  220  of the legacy MMOG system, the present invention enables all players to have a consistent seamless game world view. When the AOI of an avatar spans the doer&#39;s server of a non-player and arrives at other servers, the player can be aware of avatars on other servers which are still in his aura. The avatar can also migrate from one server into another seamlessly.  
         [0064]     The system and method according to the present invention can support changeable and different avatar view scopes very flexibly without a redundant clone avatar. Therefore it has less computing and communication load than the legacy overlap zone approach.  
         [0065]     The method according to the present invention also has no limitation on the map structure. It can be easily adopted in the improvement of legacy games.  
         [0066]     In addition, the map controller  210  can be implemented as a module which has the responsibility to manage the clone and acts as the “hidden hand” between the game application and players, so there are no special requirements for the legacy game system.  
         [0067]     While the preferred embodiment of the present invention has been described with respect to a hardware structure or method steps in the above, the operation method of the MMOG system according to the present invention can be implemented as computer program software. For example, the method according to an exemplary embodiment of the present invention can be embodied as a computer program product, which enables a computer to execute one or more exemplified methods. The computer program product may comprise a computer readable medium containing computer program logic or codes thereon for enabling the MMOG system to execute the MMOG according to one or more exemplified methods.  
         [0068]     The computer readable storage medium can be a built-in medium in the computer body or a movable medium that can be arranged so that it can be detached from the computer body. Examples of the built-in medium include but are not limited to a rewritable non-volatile memory, such as an RAM, an ROM, a flash memory and a hard disk. Examples of the movable medium can include but are not limited to an optical media such as CD-ROM and DVD; a magneto-optic storage media such as MO; a magnetic storage media such as a floppy disk (trademark), a cassette and a movable hard disk; and a media with a built-in ROM such as an ROM box.  
         [0069]     The program of the method according to the present invention can also be provided in the form of externally-provided broadcast signals and/or computer data signals included in a carrier wave. The computer data signals embodied as one or more instructions or functions of the exemplary method can be carried on the carrier wave sent and/or received by the entity for executing the instructions or functions of the exemplary method. Moreover, such a program can be stored and distributed easily when recorded on a computer readable storage media.  
         [0070]     The above description is illustrative. Therefore any changes without departing from the essence of the present invention are intended to be within the scope of the present invention. Such changes are not considered as departing from the spirit and scope of the present invention as set forth on the appended claims.