KR100879564B1 - System, apparatus and method for managing virtual entity on a network - Google Patents

Abstract

The present invention relates to an apparatus for managing a virtual entity on a network having a computer function, a display function, and an interconnect function for transmitting data over a network, and in particular, stored in common to each client on the network. A database that stores static data that can be combined to represent a character and dynamic data that includes different information for each virtual entity; And a character sharing unit capable of sharing the virtual entity character with other devices via a network using an interconnect function.

Virtual Self-Developing Pets, Electronic Devices, Networks, Characters, Avatars, Data, Sharing, Communities

Description

SYSTEM, APPARATUS AND METHOD FOR MANAGING VIRTUAL ENTITY ON A NETWORK}

1 is a simplified illustration of a self-developed pet exchanged between two mobile devices according to a first embodiment of the present invention.

FIG. 2 is a simplified illustration of the arrangement of data for the self-developed pet of FIG. 1 into static data and dynamic data. FIG.

Figure 3 is a simplified diagram illustrating the exchange of data via a text message in accordance with a preferred embodiment of the present invention.

4 is another simplified illustration of blocks of an engine supporting a self-developed pet, in accordance with a preferred embodiment of the present invention.

5 is a simplified diagram illustrating a process for generating a text encoded binary text message, in accordance with a preferred embodiment of the present invention.

6 is a simplified diagram illustrating the structure of the SMS message of FIG.

Figure 7 is a simplified view of the procedure for receiving a self-developed pet according to a preferred embodiment of the present invention.

8 is a simplified illustration of transmitting a decoration according to a preferred embodiment of the present invention.

9 is a flow chart briefly illustrating transmitting a snack according to a preferred embodiment of the present invention.

FIG. 10 is a block diagram illustrating a transmission procedure for a self-developed pet, in particular showing the time points at which loss of synchronization may result in loss of the pet, in accordance with a preferred embodiment of the present invention.

11 is a flow chart illustrating a procedure for automatically searching for pets in case of timeout, in accordance with a preferred embodiment of the present invention.

12 is a flowchart of synchronization using a time stamp in accordance with a preferred embodiment of the present invention.

13 is a block diagram of a characteristic and emotion engine in accordance with a preferred embodiment of the present invention.

14 is a diagram illustrating how a change function can be used to change from a first set of properties to a second set of properties, in accordance with a preferred embodiment of the present invention.

FIG. 15 is a flow diagram illustrating a principle in which two characters may be changed differently by the same external behavior, in accordance with a preferred embodiment of the present invention. FIG.

16 and 17 show screen snapshots illustrating the principle of FIG. 15.

18A-18C show three different ranges of characteristics, respectively, with Fig. 18B briefly illustrating how a particular range defines the overall emotion.

19A-19C show briefly how the change function directly changes characteristics, and indirectly through emotions, according to the three ranges of FIGS. 18A-18C.

FIG. 20 is a flow diagram illustrating the principles by which an external action causes the pet to take an action to accept or reject according to the current state, also causes a change in state depending on the choice of action, and a new state induces a new set of actions. .

FIG. 21 illustrates a series of interaction tables for pets, traits, emotions, and behaviors, in accordance with a preferred embodiment of the present invention. FIG.

22-24 are a series of screen snapshots showing a racing application that attracts two pets, according to a preferred embodiment of the present invention.

25 is a simplified flow diagram illustrating the operational flow during the race application of FIGS. 22-24.

<Explanation of symbols for the main parts of the drawings>

10: first telephone 12: avatar

14: Friend Phone 20: 3D Model

22: Texture 24: Animation

26: sound 42: shared unit

44: static data 46: dynamic data

48: Presence Control Model 50: Emotion Engine

FIELD OF THE INVENTION The present invention relates to virtual entities on a network, and more particularly to the presence or exchange of animated characters over a network, the virtual on a network managing the presence or exchange of characters over a cellular telephone network. A system, apparatus, and method for managing an entity.

A moving character can be a user's spokesperson, avatar, or any other kind of moving character, including characters associated with computer games or assimilated self-developing pets. Self-developed electronic pets are games that involve a character that needs consistent attention from its owner to grow well. Self-developed electronic pets grow and develop if they receive attention, but otherwise degenerate. The idea is that pets are always present and require constant attention from their owners.

Self-developed pets are generally based on physical dolls. The physical doll has a processor and a memory, and has a physical entity. You can give it to people or get it back. Self-developed pets need attention as described above. In principle, it is also possible to have a virtual self-developed pet which is a moving character supported by a computer. Virtual self-developed pets have changed their ideas from the original physical self-developed pets because they are not always present with the user and therefore cannot require constant attention.

Virtual self-developed pets are limited because they can't or won't always be with you. For example, even if the computer is a mobile computer, it is very inconvenient to interact with the computer as a user walks, for example.

You can also share some of your own pet's experience with your friends. Physical self-developed pets can be shared with friends, but virtual self-developed pets can only be shared when dealing with issues of existence. Therefore, it should be ensured that the virtual self-developed pets do not exist in two places at the same time or that the virtual self-developed pets are not lost from all places. In addition, virtual self-developed pets are required to be able to develop both physically and emotionally over time, as real pets grow and learn.

SUMMARY OF THE INVENTION An object of the present invention is to provide a system, apparatus and method for managing virtual entities on a network that allows a virtual self-developed pet to continue to be available to its owner.

It is also an object of the present invention to provide a system, apparatus, and method for managing a virtual entity on a network that allows a virtual self-developed pet to share with others.

It is also an object of the present invention to provide a system, apparatus and method for managing a virtual entity on a network for building a virtual community for a virtual self-developed pet.

In order to achieve the above object, the present invention provides a device for managing a virtual entity on a network having a computing function, a display function, and an interconnection function for transmitting data over a network, which is commonly stored in all clients on the network. A database for storing dynamic data including static data representing a virtual object character and specific information of said virtual object character that is different from another virtual object character, and a virtual entity composed of said static data and said dynamic data using said interconnection function; A character sharing unit capable of sharing a character with other devices via the network, and a presence control model for controlling the character sharing unit such that the virtual entity character has a unified presence on the network. .

In order to achieve the above object, the present invention provides a system for managing a virtual entity on a network including mobile communication devices each having a computing function, a display function, and a communication function, each of which is included in each of the mobile communication devices. And an engine for operating characters having an avatar, an emotion engine for providing emotion-based behavior to the characters according to a set of avatars and emotion parameters corresponding to the characters stored in each of the mobile communication devices; In the set of avatars, pointer information indicating a first avatar according to a first character of a first mobile communication device among the mobile communication devices is transmitted to a second mobile communication device of the mobile communication devices, and the second mobile communication is performed. The device receives the pointer information and receives the received information from the set of avatars. Identify a first avatar corresponding to the inter information, share the first avatar with the second mobile communication device such that the identified first avatar operates in the same individual behavior and appearance as in the first mobile communication device, And a switching unit for providing a second avatar according to the second character of the second mobile communication device and a community environment for operating the first avatar.

In order to achieve the above object, the present invention provides a method for managing a virtual entity on a network for exchanging virtual object characters through a mobile telephone network between a plurality of mobile devices, the corresponding virtual object character according to specific behavioral parameters. Providing each of the plurality of mobile devices with an action engine that provides a specific behavior of an object character; providing static data for displaying the corresponding virtual object character to each of the plurality of mobile devices; A first mobile device of the device transmitting specific behavioral parameters of the first virtual object character and a reference value of the static data to a second mobile device of the plurality of mobile devices, and wherein the second mobile device is the first virtual object; Receive specific behavioral parameters and reference values of a character, such that the received specific behavior By identifying the meter la and each of the first virtual object static data with a particular action of a character from a reference value characterized in that it comprises the step of sharing the virtual object, the first character.

According to an aspect of the present invention, there is provided an electronic game method in a mobile communication device, the method for managing a virtual entity on a network, wherein the first electronic character and one or more other electronic characters are provided through a first electronic character in a virtual environment. Setting a match task for the character to earn, acquiring a level of attributes corresponding to each of the first electronic character and the one or more other electronic characters, and obtaining the obtained first electronic character and the one or more other electronic characters Comparing the levels of the attributes corresponding to the respective ones, and selecting a winner of the competition task from the first electronic character and the one or more other electronic characters according to the comparison result.

delete

delete

delete

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The materials, methods, and examples provided herein are merely illustrative and are not intended to limit the invention.

Implementation of the methods and systems of the present invention require performing or completing certain selected tasks or steps manually, automatically, or a combination thereof. Further, according to the actual means and equipment of the preferred embodiments of the method and system of the present invention, some selected steps may be built by hardware, by software on an operating system of any firmware, or by a combination thereof. have. For example, as hardware, selected steps of the present invention can be built into a chip or circuit. As software, selected steps of the present invention may be constructed of a number of software instructions to be executed by a computer using any suitable operating system. That is, the selected steps of the method of the present invention and the system of the present invention can be said to be performed by a data processor such as a computing platform that executes a plurality of instructions.

In the following description, the invention has been described by way of example only with reference to the accompanying drawings. In particular with reference to the accompanying drawings in detail, the illustrated details are shown by way of example only and are merely illustrative of the preferred embodiments of the invention and are the most useful and easy understanding of the principles and conceptual aspects of the invention. I would like to emphasize that it is presented to provide what is considered to be an explanation. In that respect, no attempt will be made to show structural details of the invention in more detail than is necessary to a basic understanding of the invention, and those skilled in the art may, from the description made in conjunction with the accompanying drawings, practice how to practice some aspects of the invention. Will be clearly identified.

The present invention consists of a system, apparatus and method for supporting a self-developed pet on a mobile device and creating a networked community of self-developed pet owners. The self-developed pet community is based on a single model that includes basic pet characteristics and behaviors, including emotions, and a set of avatars. The set of models and avatars is present on all mobile devices in the community. Each pet is then formed from an avatar selected from among the avatars and a developed set of parameters for the model. Each pet will have a host device and can transmit to and receive from other devices only by specifying the current set of parameters and the selected avatar. Such transmission is preferably performed using binary data in the text message.

When transmitting a pet, preferred embodiments of the present invention ensure that a pet always has only one entity, which parameter set of the pet can be updated independently on only one device at a given time. It means that there is. In addition, embodiments of the present invention ensure that a pet is not lost if a particular device fails to receive the pet or fails to return the pet to the road owner.

More specific embodiments of the present invention provide communication between finite resource devices using binary coded text, communication between finite resource devices using text messaging, between applications on different finite resource devices using text messaging. Communication, and communication between such applications using binary coded text.

The embodiments also teach creating a community for the use of such animations, including a game environment in which users test their pets against other pets.

The principles and operation of the system, apparatus and method according to the present invention will be better understood with reference to the accompanying drawings and the accompanying description.

Prior to describing in detail one or more embodiments in accordance with the invention, the invention is limited in its application to the details of construction and arrangement of components that are set forth in the following description or shown in the accompanying drawings. You should know not. The invention is capable of other embodiments or of being practiced or carried out in various ways. Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.

Reference will now be made to FIG. 1, which is a simplified diagram of two electronic devices, such as mobile phones or other wireless or cellular communication devices, used in accordance with a first embodiment of the present invention. The devices preferably include computing functions, display functions, and interconnect functions for transmitting data over a network. As shown, a self-developed pet is present on first telephone 10, the presence of which is indicated by screen avatar 12. Parameters for the behavior model that personalizes the pet, as well as the identifier of the pet, including a pointer to the avatar, are encoded into a text message (typically a Short Message Service (SMS) message) in binary format, thereby allowing the pet to be cellular Can be sent to a friend's phone 14 via a network. The avatar 12 then appears on the friend's phone 14 to indicate the pet's presence there.

In particular, SMS is desirable for transmission over a telephone network. However, it is also possible for embodiments of the present invention to employ other networks. Two phones located close to each other can transmit data using an IR link between their respective InfraRed (IR) ports. At this time, since the binary SMS file is a small file, it is suitable to form the basis of IR communication. On the other hand, local Hotpoint connection or Bluetooth ^TM connection can likewise be used. In order to use such a connection, certain additional functions must typically be included in the user client.

Hereinafter, with reference to FIG. 2, how the data of the pet will be described. The data varies between pets or varies over time with static data (type A), such as 3D model data 20, texture 22, animation 24, and sound 26, common to all clients in the community. It is organized as data that varies (type B).

In other words, user clients contain type A or static information, which is all the information needed to support the pet community. The static information includes pet behavior model, animation, texture, and the like. Some of the above information, such as the model, applies to all different pets. On the other hand, other information may apply to some pets, and may not apply to other pets. Thus, all dogs of the same breed can share a particular avatar.

Type B data is dynamic data that varies between pets. The dynamic data includes name, age, specific kind of pet, and current status of the characteristics. The characteristic values of the pet, which will be described later in more detail, are actually parameters for the pet behavior model. Such dynamic behavior includes information that changes over a pet's life, such as the current state or age of a particular behavior, and information that remains the same for that pet over the life of a given pet, such as a name. In addition, the dynamic information includes data common to all pets of the same kind, and thus includes a pointer to the correct avatar.

Dynamic data, including character specific data, provides a representation of that pet along with an avatar common to a number of characters, such as all dogs of a given breed. The character specific data includes behavioral parameters, which will be described later in more detail, which behavioral parameters are allowed to develop according to certain rules contained within the model. On the other hand, the model can further use individualized parameters for different varieties. In this case, deploying behavioral parameters means making the pet a self-developed pet.

3, the static data described above may be configured such that the character sharing unit shares individual pets over the network only by sending dynamic data (type B), namely name, age and parameters or characteristics. Present on all devices. The character sharing unit preferably transmits type B data using text messaging, such as SMS.

On the other hand, even if not all pets use the same avatar, it is desirable that the avatar be present on all user clients to form part of the static data.

Referring now to FIG. 4, a block diagram illustrating the internal operation of mobile phone 40 supporting self-developed pets will be described. Hereinafter, the sharing unit 42 described above will be described in more detail. Static data 44 includes models and avatars, and the models include a behavioral model as described above. Specific data 46 includes pet specific information as dynamic data.

The presence control model 48 controls the character sharing unit 42 to ensure that the character has a unified presence on the network. Such presence control preferably ensures that the same pet exists only on one device on the network at any given time. As used herein, the term "exists" means that avatars for the same pet appear on one device, although some exceptions to such rules may be allowed. Such presence control more importantly ensures that specific data 46 for the pet can only be updated on one device at a given time.

On the other hand, pets can be transmitted to other devices and shared with other users for specific purposes. Uses for sharing pets will be described in more detail later. The presence control model 48 described above sets the time at which the pet is expected to return. Until the set time is reached, the pet does not appear on the originating device unless it is actually returned from other devices. If a pet is returned from another device, any changes made to the pet on other devices are recognized as parameters for the pet. If the pet is not returned by the end of the scheduled time, the pet only reappears at the originating device and its original parameters are restored. If the pet is returned from another device after the scheduled time expires, any parameters changed from the other device are ignored. The features of such an existence will be described later in more detail.

The character sharing unit 42 preferably places a signature on the message so that the text message transmitting the character specific data is recognized as belonging to the pet community and routed to the appropriate client. If the client is not installed on the receiving phone, the message is sent directly to the SMS client and displayed as a text message. Of course, the message contains binary data and therefore cannot be read. Thus, in one preferred embodiment, the text message comprises a human readable message. Such a message tells, for example, how a user can join a self-developed pet community. Character specific data is preferably binary data, and the character sharing unit is configured to put such binary data in a text message.

The character sharing unit 42 is also configured to scan incoming text messages for signatures that are indices of character data content. Incoming messages may be local pet return messages or visitor pet arrival messages.

Scanning is preferably performed before each text message is sent to the client applications, such that the text message is not sent to the SMS client before being sent to the pet client.

Character-specific information, on the other hand, typically consists of emotion parameter data that operates the emotion engine 50. The emotion engine 50 with specific parameter data is different between pet characters and provides different emotion-based behaviors as a given pet character evolves.

As mentioned above, the emotion engine 50 is configured to slowly develop the emotion parameter data over time. The evolving behavior provides the pet with the development of emotion-based behavior and makes the pet a self-developing pet.

A feature of the preferred embodiments is that no server side general purpose running application is needed because the clients are on user devices. Thus, there is no need to change the network at all. Even if a server is needed, it is only needed for initial download and subsequent update of clients. One embodiment has a client initially provided in a ROM at the time of manufacture. In this case, the server is not needed even for the initial download.

In the foregoing description, it has been described that binary information is transmitted via a text message. Hereinafter, the selection of a text message and a method of binary encoding the text message will be discussed in more detail.

The method of transferring binary information between telephone users has three possible solutions:

a. Peer-to-Peer (P2P) Communication: Current cellular networks support P2P communication between phones and service providers (operators). This method of communication allows the transfer of binary content from dedicated servers / from dedicated servers to user's mobile phones / mobile phones.

b. SMS: A standard protocol supported on all mobile phones and all networks that allows users to transfer non-voice data between them. SMS generally does not require server support at the application level.

c. Infrared / Bluetooth Link: A method of transmitting binary information between phones that are in close proximity or are physically linked to one another.

In the current technology, such solutions have the following disadvantages:

a: P2P communication: not directly between users, but rather between users and servers If you want to transfer binary information between users, you need to come up with a server-side solution.

b: SMS: Current SMS applications only support textual content. In addition, the SMS protocol transfers SMS between phones, not between applications. SMS can only transmit very small amounts of data.

c: Infrared / Bluetooth Link: Requires users to be physically close to each other.

As mentioned above, a preferred solution is to send a virtual pet over the network while using binary SMS while maintaining a full user client on each phone. At this time, the only data that needs to be transmitted in order to obtain a result that the pet is completely transmitted is parameter information specific to each pet. Such parameter information can be tailored to SMS of limited size.

<Expression of pet>

A single virtual pet is represented by a large amount of data. Most of such data is used to physically represent the animal: for example, the data can be 3d-models, textures, animations, sounds, and the like.

As mentioned above, the system informs the two types of information described above in connection with FIG.

Static data (data shared between all pets or between homogeneous pets): The static data is part of the user client mentioned above and resides on the respective phones. The user client may additionally reside on the central server, or certain portions of the user client, such as certain rarely used portions of the user client, may reside on the central server. Thus, there may be a general range of pets available to anyone and special particular pets that users can download specifically. That is, in general, all users may already have a user client or connect to the server to download the user client.

On the other hand, after the application is published, new data may be added to the user client. For example, such data may be new sounds, animations, and the like. Such new data can be accessed by all the phones that can download the data as updates from the central server.

The physical representation included in the user client is static data, i.e., invariant data of the pet, including three-dimensional models, textures, animations, and sounds. Since such data is the same for all homogeneous pets, it is held in common within the user client.

Non-Static Data: Non-static data is the information needed to represent a particular pet. Such data is generated and stored on the user's telephone. The non-static data will change over time and according to the user's behavior, as is assumed to represent living organisms.

The non-static data is the only data needed to reconstruct a particular pet on another phone because the other phone contains a user client as described above. Each particular pet only needs to store true actions on the static data used, and does not need to store the data itself. This is possible because static data may already be on the user's phone or downloaded from a predetermined server. Thus, multiple different pets can share the same static data.

Here is an example of three pets taking their model and texture from the user client and having their specific parameters for name and age:

Pet 1: Name: "Johnny", Age: 12 days, Breed: "Cocker-spaniel", Texture: "Brown".

Pet 2: Name: "Mookey", Age: 93 days, Breed: "Jindog", Texture: "Brown".

Pet 3: Name: "Poko", Age: 2 days, Breed: "Jindog", Texture: "Yellow".

The data for each such specific pet is as follows:

Name, age, characteristics (power, intelligence, etc.), breed (corresponding to 3d-model).

Thus, the amount of data needed to be transmitted to reconstruct a particular pet on the other side is very small. Only non-static data is sent. In this case, the characteristic information may be configured as information that is not visible to the user. That is, the characteristic information affects the behavior of the pet, but does not necessarily bring the user's attention directly. In addition, parametric data for behavioral or emotional models may be provided. Such data may be provided separately or as part of the characteristic information, which will be described in more detail later.

Next, the overall flow of transmitting a pet via SMS will be described with reference to FIG. 5.

First, in step 501 pet specific data, that is, all specific data including parameters are collected and compressed into an SMS message. The compressed data is then streamed to a binary stream in step 503. On the other hand, the SMS format has two limitations that complicate the task.

A. The SMS format is a text format, as intended for text text messages, and not a binary format.

On the other hand, the representation of pets is binary information.

B. SMS messages are limited to a few characters that are currently 80 characters long. Since we want to send the complete representation of the pet in one SMS message, enough data must fit within 80 characters.

One preferred embodiment overcomes the threshold A by converting the information from binary information to text information in step 505. The preferred transformation is to use a 7-bit method known to those skilled in the art. In such a seven-bit method, every seven bits of binary information are converted into one text character. However, such a 7-bit method unfortunately has the side effect of adding 15% of the total size of the data due to the loss of 1 bit for every byte. As for point B, since it assumes the presence of static shared data as described above in the system, only very little binary information is actually required to represent a particular pet.

<SMS Message Configuration>

The above description is not sufficient to generate an SMS message that can be sent to other mobile phones. Therefore, it may be desirable for the SMS message itself to include extra information in addition to the pet example information.

That is, certain header information is required to identify the above-mentioned messages according to the present invention as a special SMS message. The SMS messages were originally conceived for textual messages as described above, and are generally sent automatically to the user's SMS client, which then automatically displays the received message on the user's screen. In such a case, displaying the content of the message sent according to the invention is meaningless. Rather, it is necessary for the SMS client to recognize the message before it finds it and sends it back to a self-developed pet application for analysis. Thus, the header information set in accordance with the present invention functions to allow the receiving telephone to identify and lead the SMS to the application before the SMS is displayed on the screen.

On the other hand, an SMS message containing a pet may be sent to a phone without a self-developed pet application installed. In such a case, it is desirable to have the contents of the message automatically displayed, since there is nothing to recognize the headers and no place to turn the message anywhere. In other words, the SMS message appears as a random character set. Thus, it is necessary to add some coherent text at the beginning of the message to let the recipient know what happened. That is, the message may include a plain text tag such as "This is a phone pet not supported by your phone" or "U sent a pet. Call * 111 to unlock". .

However, when the same message arrives at the phone with the application installed, the message itself does not appear at all, but is provided directly to the self-developed pet application as described above. Such mechanisms will be described in more detail later.

Reference is now made to FIG. 6 with the resulting SMS message added above in FIG. 5.

An SMS message contains three areas:

a. Header 601: The header preferably consists of two letters, and identifies the transmitted SMS message as a pet SMS message.

b. Unsupported message 603: As described above, this message appears on phones that do not support the application.

c. Pet Encoding Information 605: This message portion contains the actual binary information needed to reconstruct a pet. The information is the non-static data mentioned above.

Hereinafter, a method of transmitting an SMS and receiving it from another mobile phone, a receiving phone, or a receiver will be described with reference to FIG. 7.

First, when the SMS arrives at the receiver supporting the self-developed pet in step 701, the received SMS message is identified as a special message in step 703. In other words, a sniffer application is provided that checks all incoming messages. If the first two characters correspond to a predetermined header signature, the message is not displayed on the screen but is provided to a self-developed pet application.

Once the content of the message is delivered to the self-developed pet application, the application can begin the message analysis process. The analysis only requires a message portion 605 containing text encoded binary data. At this time, the header 601 and the unsupportable message 603 are only involved in the role of reaching the application with the received message.

The pet information contained in the SMS message is then decoded in the reverse process of the encoding process.

In this case, since an error may occur in the SMS messages while passing through the network, it is necessary to perform a validity test in step 705. The received pet's parameters are first tested for appropriate conditions, such as the requirement that the age parameter cannot be negative. If only one parameter fails the test, it is preferable to discard the entire SMS. Otherwise, binary data can be used to reconstruct pet 707, which is then displayed on the recipient's screen 709.

On the other hand, when a message is received by a recipient who is not configured with a self-developed pet application, the message itself is displayed directly on the screen. At this point, there is an unsupported message 603 immediately following the header indicating that the feature is not supported and the receiver cannot know what happened.

Within the scope of self-developed pet applications, besides sending pets, there may be other interactions that enhance the community experience of self-developed pets among self-developed pet clients where SMS messaging may be used. 8 and 9 are flow charts showing two examples of such interactions. FIG. 8 illustrates sending a decoration or accessory to a particular pet, and FIG. 9 illustrates sending a cake.

Referring to FIG. 8, a decoration or an accessory is an article (a medal, sunglasses, a hat, etc.) that can be worn by a pet. Expressing a decoration is similar to the way of representing a pet: there is a wide range of storage space in the static information (eg, 3d-models and textures of the decorations). Thus, the amount of data needed to reconstruct the decoration on the other side is very small: the necessary data is a reference to the name, color, etc. of the 3d-model to be used. In FIG. 8, the decoration is shown on the sender's pet at step 801. Such a decoration is sent using binary SMS encoded in text at step 803, and at 805 an accessory is presented on the recipient's pet.

9, the same principle as described above in FIG. 8 is illustrated for a snack. A snack is a gift (ie cake, dried meat, etc.) that a user (owner) can give to his or her pet. Giving a pet a snack somehow raises the pet's emotional state. Again, there will be a finite database of messageable snacks and message transfers, and in steps 901, 903, and 905, only the ID of the particular snack to be served is transmitted.

10, the time delay procedures involved in transmitting a pet from one phone to another will be described. That is, SMS delivery is asynchronous and typically does not involve acknowledgments. Thus, the asynchronous nature of this delivery can result in the pet being present in two places at the same time or lost from all places.

More specifically, when a message is sent, the user does not know for sure when the message will arrive, or even not sure if it will arrive. The message may take several seconds or minutes to transmit. For example, because the recipient's phone may be turned off, the message is only received when the recipient's phone is turned on, which may be a few days later. Also, since SMS does not require a direct link with the recipient, the pet may be sent to the wrong number. Such a problem cannot be determined when sending a text message.

On the other hand, the problem of this wrong number can be overcome at the receiver side using the above unsupported message.

Summarizing the above-mentioned problems as follows: The user does not know when or not the message containing information about the pet will arrive at its destination. Thus, returning to the example of the ornament in FIG. 8, it is assumed that the user sends the ornament to a friend. After the decoration is sent, it is deleted from the user's phone. If the SMS does not arrive at the recipient's phone, the decoration is lost from both places.

In other cases, you can send your pet to a friend's phone for play and then return home. Since such features enrich the community aspect of self-developed pets, it is desirable to ensure that the features can be reliably supported. One such feature is that pets should be removed from their source phone if they are released from their source phone.

The usual way to implement it is to use two back-to-back SMS messages: the first message is sent from the sender to the receiver, after a few minutes another message is returned from the receiver to the sender and the pet returns home. Such a solution is a dangerous solution because the receiver may not actually receive the SMS at all or an error may occur in the SMS. In such a case, the recipient may not be able to send a response SMS at all and the pet may be lost forever, which means that the status of the pet on the source phone remains "absent".

Another problem that can be considered is that a pet sending SMS can only be received after a long time. It can happen, for example, if the receiver's phone has been off for two days. The result is a long delay in return SMS.

10 is a flowchart illustrating the movement of a pet over time between a user's telephone 1001 and a receiver's telephone 1003. If the pet is sent to the receiver in step 1005, it disappears from the sender's phone from that point on. At this time, if the receiver's telephone is turned on, the pet is received at the receiver's telephone. On the other hand, even if a message is received by the recipient, the message may fail or the recipient may be busy with something else. However, assuming that the message is received safely and the recipient is not busy, the pet will play well and return home via a return SMS in step 1007.

However, if the return message is not received by the sender for any reason, the pet is lost on the simple principle described above.

Hereinafter, the above-described automatic return mechanism procedure will be described with reference to FIG. 11. The automatic return mechanism ensures that the pet will automatically reappear on the calling phone if the pet does not return to the calling phone within a predetermined time frame, typically within a few minutes, such as within 10 minutes. In this case, the late returned message is ignored along with the corresponding data. At this time, such a return message is virtually unnecessary, because a complete message about the pet is always present on the calling telephone. The mechanism described above may have been caused by an SMS not arriving at its destination at all (because of a wrong number, etc.), a arrival at the destination but ignored (due to a busy user or a phone off), or an error in the message. It works when there is a delay in the messaging path, or some other reason.

Hereinafter, an embodiment in which a time signature is used for synchronization between a sender and a receiver will be described with reference to FIG. 12. Assuming two phones have synchronized clocks, it is possible for the receiver to identify and process old messages. The sender only needs to create an SMS 1201 and then attach a time signature to the sending SMS message 1202. Such a signature is attached by the sender to indicate the time at which the SMS was sent. Within a single time zone, there is little risk of clocks becoming out of sync because the cellular network can provide time. The SMS is received at the recipient 1204 and the time signature is checked 1205 for the current time. If the signature is new (1206), the pet goes back to play (1208). However, if the recipient receives an SMS with an old signature, such as an hour old signature (1206), the SMS may be processed differently. For example, the application may display 1207 a message such as "A friend came to visit you, but you returned home because you did not have time."

Hereinafter, a model for providing traits and emotional behaviors to a character will be described with reference to FIG. 13. Living pets have different characters that are reflected in their behavior. In the virtual world, what distinguishes self-developed pets from other classes of dolls is that they can change over time in a way that looks natural. Thus, in the present embodiments, a mathematical behavior model is proposed that simulates a natural pet character.

In order to model a pet characteristic, the present embodiments are directed to creating a mathematical construct 1301 that allows each pet to have a set of characteristics 1303 that vary according to external actions or events acting on the pet. Include. For example, an external event may be a change in time (a pet becomes increasingly hungry) or an external action may be a user's command (a user sitting, standing, teasing, rolling, shaking, turning, etc. to a pet). have. Any combination of these characteristic states will produce a single emotion. The pet acts on the emotion by doing the actions associated with the emotion. For example, pets display happy animations when they are happy.

The general solution consists of three elements:

a. Properties 1303-A set of parameters that reflects a pet's condition. Properties vary with external events and behaviors according to a specific alteration function.

b. Emotions 1305-a set of emotions determined by a combination of characteristic states by a transform (translation) function.

c. Pet Behavior 1307-A set of behaviors that reflect each state.

<Special Character Creation>

characteristic:

Characteristics are a set of parameters that reflect the pet's condition. Such parameters contain the physical state of the pet. The characteristics change according to external behaviors by different alteration functions associated with the characteristics of the pet. Each pet has its own characteristics, causing variations in possible features.

emotion:

Emotions behave similarly to characteristics in that they are parameters, but, unlike the features described above, reflect the emotional state of the pet.

<Foreign behavior or event>

External events are input events that can be external or internal to the application. External events typically trigger a chain reaction that will eventually change the pet's characteristic state. For example, a time event occurs every hour. Such a time event results in a change function that changes one or more of the pet's current characteristics. Thus, pets may become more tired and hungry.

There are also external practices that are not entirely enforced on pets. In such events, the pet has the ability to make a choice if he or she wants to accept or refuse the action. After such an external event, the pet may make a decision based on its current characteristic state and feelings when it makes the choice to accept or reject the external action. When a pet chooses to accept the behavior, its characteristics change as it "accepts a change function." If a pet makes the choice to reject external events, its characteristics can change as it "rejects a change function." Such functions define the characteristics as they will be behind the action. For example, accepting food results in decreased hunger properties.

<Change function>

The change function is a conversion function between two characteristic states. Each pet type has a change function specific to each action or event. As such, external actions and events change the pet characteristics slightly differently for each character, creating many possible characters. Thus, the result of the same user behavior for two different pet characters would produce two different states, one for each pet. That is, a slightly different change function can create a number of different pet characters. For example, one pet becomes happier after eating, while the other pet becomes sleepier.

Hereinafter, with reference to FIG. 14, a change function causing a change of eight different characteristics represented by a bar graph will be described. The graph on the left shows the feature state before the event that triggers the change function, and the graph on the right shows the feature state after the event. As described above, the value of each of the eight characteristics is converted by a unique change function for a particular pet character.

Referring to FIG. 15, it can be seen that even if the same change function is applied to two different characters, Character 1 and Character 2, they are substantially unique to each character and bring different final states.

16 and 17 are screen snapshots respectively illustrating the current state of the pet, the behavior following it, a graph of the characteristics to be changed following it, and the new state following it. In Figures 16 and 17, although the current state, which is a hungry state, and the behavior, which is an eating behavior, are the same, the changes of the corresponding characteristics are different (because the characters are different), and as a result, the new state is also different.

Hereinafter, different possible ranges of characteristics will be described with reference to FIGS. 18A to 18C. Each figure is a bar graph showing a combination of characteristics, in particular FIG. 18B results in an overall feeling of "happy emotion" as will be described in more detail later. 19A-19C show the modifying functions for each of the ranges of FIGS. 18A-18C, for example, showing how the happy emotions of FIG. 18B can be turned into sad emotions by external actions.

On the other hand, pet emotions are determined by the state of the traits. Each character has a transform function specific to itself, which transforms a set of characteristic states into one or more emotions. Since such transformation functions are specific to each pet trait, even the same set of traits states can produce different overall feelings. For example, a dog pet with "satiety"> 80% may be set to have a "tired" feeling, while a cat pet may be set to have a "pleasant" emotion. Such deviation of the transform function allows different pet characters to be generated. In a state where the two transform functions yield two different emotions, the system can do one of the following.

Accepting only one of the emotions makes a choice between two possible states, each defined. For example, this may be implemented using an emotion priority table, or the system may choose to combine the accepted emotions into a set of emotions in which two emotions (or more) are active at the same time. For example, pets can be "hungry" and "tired" at the same time.

For example, f (characteristic state) may be as follows:

If f (Talent Status) = {(Saving <20%)} ⇒ Emotion = Hunger

If f (Talent Status) = {(Strength <40%)} and {(Fatigue> 80%)} ⇒ Emotion = Instructions

If f (Talent Status) = {(Health <40%) and (Strength <25%)} ⇒ Emotion = Pain

behavior:

Each emotion has a set of actions that reflect that emotion. The actions in that set correspond to the animations. Each screen, scenario, or character in the application results in a different set of behaviors for each emotion. By doing so, various ways in which the pet reflects his feelings are created. There are many types of behaviors that pets can do and a non-limiting list of behaviors that can change depending on their emotional state is as follows:

a. Visual effects-different animations set for each emotion.

b. Voice-The sound set for each emotion.

c. Text-Different text hints or text bubbles that a pet sees depending on its feelings.

d. Rejection-Depending on the pet's emotional state (characteristics and emotions), the pet may choose to reject the behavior requested by the user.

e. Etc

Next, referring to FIG. 20, an event or action may be changed according to a current emotional state, and how the result may be a change function that induces a change in the current state. Thus, future actions depend on future conditions. That is, when an event or action occurs, the action is selected according to the type, current characteristics, and emotion of the event.

When the action is rejected according to the selection, the property state is changed according to a predetermined rejection change function, and a transformation function is applied according to the changed property state. On the other hand, if the action is allowed according to the selection, the characteristic state is changed according to the preset allowable change function, and the transformation function is applied according to the changed characteristic state.

In addition, as described above, the current characteristic state is calculated by the application of the transform function, and the emotion corresponding to the current characteristic state is expressed. At this time, the change of behavior is set continuously according to the current emotion.

<General flow>

Data structure

Hereinafter, a table known as a ground table of the system will be described with reference to FIG. 21. The ground table of the system is as follows:

2101 Pets-This table contains all the pets currently on the phone.

2102 Talent-The set of all possible Talents a pet may have.

2103 emotions-a set of all emotions a pet can have.

2104 Behavior-The set of all behaviors a pet can do.

On the other hand, there is a link table between the tables:

1. Pet_Characters (2105)-This table contains indices that append all possible characteristics for a particular pet.

2. Pet_Emotions (2106)-This table contains all the current emotions that pets have at the present time.

3. Emotions_Behavior 2107-This table contains all possible actions that can be taken for each emotion.

<Development model>

1. The above-described embodiment can be improved in function by dividing two specific emotions into developing emotions. Developing feelings change more slowly than other feelings. The development model provides pets that are easier for the user to understand and can be given more differentiation between different breeds. As a result, the user has a greater feeling of handling a live pet. In addition, power generation will appear over time.

In the development model the feature offsets are set to be the same for all varieties and ages. Different varieties and ages, however, differ in that the traits have different maximums. Exemplary offsets are shown in Table 2 below.

Maximums of various characteristics are set according to the characteristics of the varieties.

Characteristics to be considered include the following.

-Health, fatigue, satiety, cleanliness, stress, obedience, and intimacy.

The first five traits can change quickly without much effort. Intimacy and obedience are special development models, which means they are much more stubborn and longer term. The user must gain the trust of the pet as it develops. Although the pet does not die, the system can punish the user by lowering the level of intimacy for the user not taking care of his pet.

Pets can also learn to perform tricks. The user must specifically train the pet for each stunt. It is desirable that the learning curves differ between varieties and ages. The user may scold or praise the pet after each instruction to facilitate the learning process or otherwise affect the learning process.

The emotions typically used are pain, hunger, guidance, anger, serenity, and pleasure. The emotions are determined according to the characteristics except development characteristics.

Pets can accept or reject behavior based on their emotional state and characteristics.

If the pet does not respond to the behavior, it is desirable to tell the user exactly why. Thus, pets may not eat because they are sick or have eaten quickly, in which case it is desirable to inform the user that "feeling bad" or "full." The pet may refuse to walk with the user if the intimacy property is very low, in which case the user will be notified that "I do not want to go with you."

In one preferred embodiment, intimacy and obedience change rapidly for puppies. Scolding and praising affects different dogs differently, and it is desirable to affect different dogs differently, even depending on the last action or depending on the time elapsed since the last action.

Now, a series of emotions will be described with reference to Table 1, which is shown in a predetermined order. Each emotion is associated with one or more characteristics. Each characteristic is represented by predetermined maximums that can vary from 0% to 100%. In addition, some values may be represented as absolute values. Above or below a threshold is set at which the emotion is affected. Thus, if the health is less than 25%, the animal is ill. Since the pain is the highest emotion in the priority list, the animal is ill regardless of the lower item of the emotion table. On the other hand, if there is no emotion above the threshold, the animal is calm as it corresponds to the lowest item on the table.

<Emotion>

The following priorities (pain is highest):

Order of emotions and their priorities for the characteristic level  pain  Health <25%  Hunger  Satiety <25%  Guideline  Fatigue> 75%  aggro  Stress> 75%  joy  Health> 70% and satiety> 50% and fatigue <50% and stress <30%  Calm  None of the above

Reference is now made to Table 2, which shows the values that change emotions over time. The feelings of intimacy and obedience change more slowly than others.

That is, the time changes by the following values.

Change over time (per hour) for a characteristic  emotion  health  fatigue  Satin  Cleanliness  stress  Intimacy  Obedience Pleasure / Calmness / Guidance / Anger  0  +7  -7  -One   -3   0   0  Hunger  -4  +9  -5  -One   0  -One  -One  pain  -One  +15  -2  -One   0  -3   0

Reference is now made to Table 3, which shows the conditions under which a pet will accept a particular action given it.

Acceptance conditions are as follows.

Act acceptance condition  walk  Calm or joyful emotions. Intimacy> = 70 Last walk before 10 minutes  play  Calm or joyful emotions. Intimacy> = 70  meal  A painful emotion  Sleep  Angry feelings. Fatigue> 50%  cure  Health <50%  Washing  Angry feelings. Cleanliness <50%. Intimacy> 50  feat  Calm or joyful emotions. Intimacy> = 70 Knows the feat. Depending on the obedience level, the pet may refuse to make a mark (optionally), and then scolding may help to raise the obedience level.

Hereinafter, reference will be made to Table 4, which shows the effect of accepting the actions of Table 3 on various characteristics.

Effect of act acceptance  health  fatigue  Satin  Cleanliness  stress  Obedience  Intimacy  walk   X  +8   -5  -2   -4   X  +2  Ding dong games   X  +6   -4  -One   -One   X  +2  Starga Game   X  +10   -6  -3   -2   X  +2  Learn english words   X  +3   -One   X   X   X  +2  Speaking of the day   X   X   X   X   -One   X   X  meal  Cotton satiety, -10  +1  +30  -3   -2   X  +1  Sleep  +3  With zero  -10   X  -10   X   X  cure  To the maximum  +20   -5   X  +30   X  -One  Washing  +3  +10   -4  To the maximum  +15   X  -One  Command   X  +1   -One   X   -One   X  +1  Racing win  +1  +15  -10  -2   -8   X  +2

Table 5 below is a corresponding table showing the effect of rejecting an action.

Effect of refusal  health  fatigue  Satin  Cleanliness  stress  Obedience  Intimacy  walk   X   X   X   X   +1   X   X  meal   X   X   X   X   X   X   X  Sleep   X   X   X   X   +1   X   X  cure   X   X   X   X  +15   X  -2  Washing   X   X   X   X   +5   X  -2  Command   X   X   X   X   X   X   X  Race defeat   X  +15  -10  -2   +5   X   X

The effect of praise or scolding is set so that actions within one minute after compliment or scolding do not affect it.

At this time, if a compliment or scolding is performed about 1 minute after the stunt command, the effect is as shown in Tables 6 and 7. As shown, the effect may vary depending on the pet's response to the command, ie whether the pet performed a trick or refused grumpy.

The effect of scolding  health  fatigue  Satin  Cleanliness  stress  Obedience  Intimacy  punishment  X  +2   X   X   +10   X  -One  caution  X  +1   X   X   +6   X  -One  Punishment (after grumpy)  X  +4   X   X   X  +2   X  Attention (after grumpy)  X  +2   X   X   X  +1   X

The effect of praise  health  fatigue  Satin  Cleanliness  stress  Obedience  Intimacy  Pets  X  X   X   X   -4   X  +1  compliment  X  X   X   X   -5   X  +1  Pets (after performing stunts)  X  X   X   X   -4  +1  +1  Praise (after performing stunts)  X  X   X   X   -5  +1  +2  Pets (after grumpy)  X  X   X   X    X  -2   X  Praise (after grumpy)  X  X   X   X    X  -2   X

<Characteristic maximum>

As mentioned above, the characteristics are set to maximums that reflect the differences between the varieties.

Take the following varieties with the following characteristics:

코커 스파니엘: 타고난 사냥개로서, 덤불 속으로 뛰어들도록 훈련되어 있다. 아이들과 다른 애완동물에 관대하다.

Cocker Spaniel: A natural hunting dog, trained to jump into bushes. Tolerant to children and other pets

파피용: 사교성이 좋고 친절하다. 안기기 및 놀기를 좋아한다. 집에 길들이기가 매우 어려울 수 있다. 파피용은 정기적인 솔질을 필요로 한다.

Papillon: Sociable and kind. I like to hug and play. Taming home can be very difficult. Papillon needs regular brushing.

비글: 고집이 세고 길들이기 어려울 수 있다. 부단한 운동을 필요로 하고, 쉽게 지겨워한다. 아이들과 다른 개들을 좋아하는 온순한 동물이다. 필요에 따라 솔질해주고, 절대적으로 필요한 경우에만 목욕시킨다.

Beagle: Can be stubborn and hard to tame It requires constant exercise and is easily bored. It is a gentle animal who likes children and other dogs. Brush as needed and bath only when absolutely necessary.

진돗개: 진돗개는 날씬하면서도 근육이 잘 발달한 개이고, 당당하게 행동한다. 스스로 몸을 깨끗이 하는 품종이고, 집에 길들이기 매우 쉽다.

Jindo dog: Jindo dogs are slender and well-developed dogs, and they act proudly. It is a breed that cleans itself and is very easy to tame at home.

The aforementioned characteristics are represented by the sets of maximums shown in Table 8.

Maximum value of various characteristics for different varieties  health  fatigue  Satin  Cleanliness  stress  Obedience  Intimacy  Cocker Spaniel Dog  100  90  120  100   110  200  200  Papillon dog  80  100   80  120   100  200  200  Beagle dog  80  110  100  100   80  200  200  Jindog dog  120  130  110   80   110  200  200

Now, puppies and dogs can be defined as follows:

For puppies: Take 50% of the maximum adult dog (except obedience and intimacy that remains at the maximum 200).

For medium-grown dogs: Take 80% of the dog's maximum (except obedience and intimacy, which remains at the maximum of 200).

Table 9 shows the suggested initial values for newborn puppies for the breeds illustrated above.

Breed Characteristics of Newborn Puppies  health  fatigue  Satin  Cleanliness  stress  Obedience  Intimacy  Cocker Spaniel  100%  0  50%  100%   0  100  100  Papillon  100%  0  50%  100%   0   80  120  beagle  100%  0  50%  100%   0   70  100  Jindo dog  100%  0  50%  100%   0  120   80

Puppies can grow and become in peak physical condition (100% health, 0 fatigue, 100% satiety, 100% cleanliness, 0 stress). Obedience and intimacy need not change.

Learning stunts also depends on the breed. Table 10 shows the suggested values of the learning table for different varieties. This table indicates how many times a dog must be trained on a stunt before the dog can master it.

Training required to learn stunts by breed   Sitting   roll   spin   Barking   Scratching  Cocker Spaniel   5   15    6    10   7  Papillon   9   22    9    14   12  beagle   7   20    7    12   10  Jindo dog   2    7    4    6   5

Reference is now made to Table 11, which illustrates a number of snacks that dictate the conditions under which a pet accepts to eat the snack. The table also illustrates the effect on the existing characteristics of pets who accept snacks.

Acceptance conditions and change functions for snacks  item        Acceptance condition     Change function  biscuit  Not pain. Not instructions.  Stress -2  Chewing gum  Not pain. Not instructions. Stress <80%  Cleanliness + 15% (clean teeth)  Dry meat  Not pain. Not instructions. Stress <80%  Intimacy +2  sausage  Not pain. Not instructions. Stress <80%  Obedience +2  Cheese  Not pain. Not instructions.  Stress -5  helminthic  Intimacy> 100 and stress <50%  Health + 15%  tonic  Stress <30%  Intimacy +5  Recovery agent  Intimacy> 150  -20% stress

Although the present preferred embodiments refer to the transmission of text encoded binary information about a pet, the principle of using an SMS message to communicate parameter data for a commonly held user client is to other applications and other types of information. It should be noted that they may be applied and are within the scope of the present invention. In addition, the principle of using text encoded binary data for direct connection between mobile devices is also within the scope of the present invention, and the concept of using text encoded binary data for communication between user clients over the air is also within the scope of the present invention. . The use of text messaging to transfer binary data between mobile devices is also included in the present invention.

The principles described above may be extended to other types of information for transmission between mobile devices and other finite resource devices. It is anticipated that numerous related devices and systems will be developed during the life of this patent, and the scope of the terms herein, especially mobile devices, cellular communications, text messages, etc., includes all such new technologies a priori. I want to.

Additional objects, advantages, and novel features of the present invention will become apparent to those skilled in the art upon reviewing the following examples, which are not intended to be limiting. In addition, various embodiments and aspects of the present invention as outlined herein and claimed in the claims are supported experimentally by the following examples.

<Example: Gyeongju>

A distinctive feature of self-developed pets in mobile devices is that experiences with self-developed pets can be shared and a community of users can be created. One way to share self-developed pets and related experiences is to engage in joint activities where pets move together to compete with each other. It may or may not be implemented by sending a pet to a friend's phone.

One possible activity is racing. Two self-developed pets exist on the same phone and compete with each other in a race. The attributes, characteristics, and feelings of self-developed pets determine who is the winner, and the user who pays more time and attention to his pet wins.

The sequence of possible screen snapshots involved in initiating a race will now be described with reference to FIG. 22.

Any user can initiate a race by sending an SMS to another user installed on his phone (screen snapshot 2201). The user who receives the SMS can accept or decline the race offer (screen snapshot 2202).

When the receiver accepts the race offer, the receiver's phone enters a state where the receiver sees two pets (their own pet and the sender's pet) who are preparing to stretch and race. Countdowns from 3 to 1 begin (screen snapshot 2203).

23 and 24, a flag is given at the end of the countdown to indicate the start of the race (screen snapshot 2301).

The two pets start the race at the stadium and preferably run in separate running lanes. Pets escape the curves of running lanes through three different backgrounds 2301, 2303, 2305. Once the pets reach a point in the third background, one of the pets speeds up to the finish line in screen snapshot 2401.

The winner of the race is based on pet characteristics. An exemplary formula for calculating the score for each pet is shown in Equation 2 or Equation 3 below.

On the other hand, other similar relationships may be used with similar or alternative features and emotions.

The pet with the highest score wins the race through the above formula. If the scores are the same, the race offer user wins the race.

The sequence at the end of the race depends on which pet has won. If the visitor pet wins, a sequence of screen snapshots 2401, 2403, 2405 appears. If the home pet wins, a sequence of screen snapshots 2410, 2412, 2414 appears.

In one preferred embodiment, the race may appear simultaneously on the sender's phone and the receiver's phone. Since the two phones calculate the winner in the same way, the phones do not actually need to be synchronized with each other for the winner. Thus, the end of the race will be different on each phone because the publication of the results should show what the home pet did.

Gyeongju allows users to apply medicine to their pets, for example, by increasing their pet's power, feeding their pets, improving their pet's health, treating their pets, and It serves as an incentive to develop their own pets by giving them, and also to induce users to sleep their pets from time to time to minimize their fatigue. In addition, racing serves as a focal point for users to compare their efforts because the best handled pet wins.

If the home pet wins, the visitor (loser) receives an SMS with a silver medal, if the home pet loses, the home pet receives a silver medal, and the visitor (winner) receives an SMS with a gold medal.

Medals are preferably added to the pet's decorative list so that they can be worn at any time. After the race is over, the sender who sends his pet to the receiver gets his pet back.

After the race, the characteristics of the two pets are changed. An exemplary change is made as follows.

For 2 players:

Strength: -5, Health: -5, Fatigue: +3, Satisfaction: -5, Cleanliness: -5, Intelligence: +2, Intimacy: No change.

About the winners:

Satisfaction: +20, Stress: -5

About the loser:

Satisfaction: -5, Stress: +20.

Hereinafter, the overall flow of the race will be described with reference to FIG. 25. As mentioned above, the originating user sends the pet to the receiver for racing. The recipient receives an invitation to the race and responds. If the receiver does not accept the race, the pet is returned to the sender. Otherwise, the race begins. Then, the scores of the pets are calculated and one of the pets wins the race. The pet owner is notified of the victory, the other pet owner is notified of the defeat, and the caller's pet is returned to its source.

In somewhat more conceptual terms, a race may be replaced by a race task, meaning any other task, preferably any task that can first identify, win, or better character. Such a task develops attributes through its own electronic character within the virtual environment of a mobile phone, and then a game in which the electronic character performs with one or more other electronic characters, more precisely, in comparison to one or more other electronic characters. An electronic game method comprising setting up a task is provided.

Then, in the electronic environment, the winner of the race task is selected among the characters through evaluation of the development of the attributes. Thus, a user who puts more effort into his pet wins the race. The race gives users the opportunity to share their pets and benefit from the level of development that they have put on their pets.

Certain features of the invention, which are, for clarity, described in the context of separate embodiments, may be combined with each other and provided in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may be provided separately or in any suitable subcombination.

While the invention has been described in connection with specific embodiments thereof, it will be apparent that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, it is intended that the present invention cover all such alternatives, modifications, and variations that fall within the spirit and scope of the appended claims. All publications, patents, and patent applications mentioned in this specification are incorporated herein in their entirety to the same extent as if each individual publication, patent, or patent application was specifically stated to be incorporated herein by reference. Become part of that member. In addition, citation or identification of any reference in this application should not be construed as an admission that such reference can be used as prior art to the present invention.

The present invention has the advantage that the owner of the virtual self-development pets continuously and share the virtual self-developed pets with others, thereby establishing a virtual community for the self-developed pets.

Claims (37)

A device for managing virtual objects on a network having computing capabilities, display capabilities, and interconnect capabilities for transmitting data over a network, A database which is stored in common to all clients on the network and stores dynamic data including static data representing virtual object characters and specific information of the virtual object characters different from other virtual object characters; A character sharing unit capable of sharing the virtual object character composed of the static data and the dynamic data with other devices via the network using the interconnect function; And a presence control model for controlling the character sharing unit such that the virtual entity character has a unified presence on the network. The apparatus of claim 1, wherein the character sharing unit transmits the dynamic data to any one of the other devices when the static data exists on the other devices, thereby receiving the dynamic data. A device for managing virtual objects on a network, characterized by sharing with the device. 3. The apparatus of claim 2, wherein the transmitted dynamic data includes a pointer for identifying an avatar associated with the virtual object character from a group of avatars. The apparatus of claim 1, wherein the character sharing unit shares the virtual entity character with any one of the other devices using text messaging. The method of claim 4, wherein avatars are located on the other devices, and dynamic data including a pointer to an avatar associated with the virtual object character is transmitted to any of the other devices via the text messaging. Device that manages virtual objects on the network. delete The virtual entity on a network according to claim 1, wherein the existence control model prevents the virtual entity character from being present in a device that has transmitted the virtual entity character when the virtual entity character is transmitted to another device. Device to manage. 8. The method of claim 7, wherein the existence control model restores the existence of the virtual object character at the device that transmitted the virtual object character if the virtual object character is not returned from the other device within a predetermined time. Characterized by a device for managing virtual objects on a network. The apparatus of claim 8, wherein the existence control model is configured to transmit the virtual object character by accepting specific data of the virtual object character as changed by the other device when the virtual object character is returned from the other device. And recover the existence of the virtual entity character of the virtual entity on the network. 10. The apparatus of claim 9, wherein specific data of the virtual entity character is changed on the other device. 10. The apparatus of claim 9, wherein the specific data of the virtual entity character is changed on the device that transmitted the virtual entity character. 5. The apparatus of claim 4, wherein the character sharing unit includes specific data of the virtual entity character so that the text message can be recognized as consisting of specific data of the virtual entity character for operating the virtual entity character on the other device. A device for managing virtual objects on a network, characterized in that a signature is attached to a text message. 13. The apparatus of claim 12, wherein the character sharing unit includes the specific data of the virtual entity character in the binary data format in the text message. 13. The apparatus of claim 12, wherein the character sharing unit is configured to scan incoming text messages for signatures that are indicators of character data content. 15. The apparatus of claim 14, wherein the character sharing unit is configured to perform the scanning before each text message is sent to client applications. 10. The apparatus of claim 9, wherein the specific data of the virtual entity character includes emotion parameter data for an emotion engine configured to provide emotion-based behavior to the virtual entity character. 17. The apparatus of claim 16 wherein the emotion engine develops the emotion parameter data over time to provide evolution of emotion-based behavior for the virtual entity character. A system for managing a virtual entity on a network comprising mobile communication devices each having a computing function, a display function and a communication function An engine included in each of the mobile communication devices to operate characters having individual actions and avatars; An emotion engine for providing emotion-based behavior to the characters according to a set of avatars and emotion parameters corresponding to the characters stored in each of the mobile communication devices; In the set of avatars, pointer information indicating a first avatar according to a first character of a first mobile communication device among the mobile communication devices is transmitted to a second mobile communication device among the mobile communication devices, and the second movement is performed. Receiving the pointer information at a communication device to identify a first avatar corresponding to the received pointer information from the set of avatars, wherein the identified first avatar has the same individual behavior and appearance as at the first mobile communication device. A switching unit that shares the first avatar with the second mobile communication device so as to operate, and provides a second avatar according to a second character of the second mobile communication device and a community environment for operating the first avatar. System for managing virtual objects on the network, characterized in that. 19. The apparatus of claim 18, wherein the exchange unit is further configured to display behavioral parameters for a particular behavior of the first character such that the first avatar exhibits the same behavior on the second mobile communications device as on the first mobile communications device. A system for managing virtual objects on a network, characterized by transmitting to a mobile communication device. 20. The apparatus of claim 19, wherein the exchange unit indicates the first avatar to be used in the first mobile communication device and includes the behavior parameters in a text message to include behavior parameters for a specific behavior of the first character. 2 A system for managing virtual objects on a network, characterized by transmitting to a mobile communication device. 21. The system of claim 20, wherein the exchange unit attaches a signature to the text message so that the text message can be recognized as consisting of specific data of the virtual entity character. A method of managing virtual objects on a network that exchanges virtual object characters across a mobile telephone network between a plurality of mobile devices, the method comprising: Providing each of the plurality of mobile devices with a behavior engine that provides a specific behavior of the virtual entity character according to specific behavioral parameters of the virtual entity character; Providing static data for displaying the corresponding virtual object character to each of the plurality of mobile devices; Transmitting, by a first mobile device of the plurality of mobile devices, reference values of specific behavioral parameters and static data of a first virtual entity character to a second mobile device of the plurality of mobile devices;  The second mobile device receives the specific behavioral parameters and reference values of the first virtual entity character, and identifies the static data and the specific behavior of the first virtual entity character through the received specific behavioral parameters and reference values, respectively; And sharing the first virtual object character. The method of claim 22, And wherein some of the specific behavioral parameters included in each of the plurality of mobile devices are slower to develop than other specific behavioral parameters. The method of claim 22, Specific behavior parameters included in the plurality of mobile devices each define a type of virtual entity character according to a set maximum value, and define a type of a new virtual entity character when there are sets of newly defined maximum values. How to manage virtual objects. 23. The method of claim 22, wherein reference values of specific behavioral parameters and static data of the first virtual character are included in one or more text messages and transmitted to the second mobile device. delete 26. The method of claim 25, wherein the reference value of the specific behavioral parameter and the static data of the first virtual character is included in the one or more text messages in text encoded binary data format. delete delete The method of claim 25, And wherein the one or more text messages includes a header to identify the text message for the first virtual object character. An electronic game method in a mobile communication device, the method for managing a virtual entity on a network, Setting up a match task for the first electronic character and one or more other electronic characters through a first electronic character in a virtual environment; Obtaining a level of attributes corresponding to each of the first electronic character and the one or more other electronic characters; Comparing levels of attributes corresponding to each of the obtained first electronic character and the one or more other electronic characters;  And selecting a winner of the competition task from the first electronic character and the one or more other electronic characters according to the comparison result. Claim 32 was abandoned upon payment of a registration fee. 32. The method of claim 31, wherein the first electronic character and the one or more other electronic characters are each included in different mobile communication devices, and the one or more other electronic characters are transmitted to the mobile communication device including the virtual environment. Playing way made with. Claim 33 was abandoned upon payment of a registration fee. 32. The method of claim 31 wherein the attributes corresponding to each of the first electronic character and the one or more other electronic characters are one or more of a group consisting of characteristics and emotions. The method of claim 31, wherein And after selecting a winner of the competition task, changing attributes of each of the first electronic character and the one or more other electronic characters according to the selection result. 33. The method of claim 32 wherein the transmission comprises transmission by text messaging. Claim 36 was abandoned upon payment of a registration fee. 36. The method of claim 35 wherein the text messaging is a short messaging service (SMS). delete

Images