U.S. Pat. No. 9,162,141

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following descriptions are exemplary embodiments only, and are not intended to limit the scope, applicability or configuration of the invention in any way. Rather, the following description provides a convenient illustration for implementing exemplary embodiments of the invention. Various changes to the described embodiments may be made in the function and arrangement of the elements described without departing from the scope of the invention as set forth in the appended claims.

As shown inFIGS. 1 and 2, a localization system according to an embodiment of the present invention contains a portable storage device1and a game console2.

The portable storage device1can be a Multimedia Card (MMC), a Secure Digital (SD) card, a MINI card, a MD card, a FLASH memory, a hard disk, or a similar memory device capable of storing game files. The portable storage device1contains a target word unit (i.e., target)11data-linked to a small database (i.e., header)12having an identification code. The small database12is data-linked to a configuration unit having a cover data, configuration data, etc. (not shown, and the cover data or configuration data can be directly encoded into the small database12). The small database12can access a logic allocation unit14which contains at least a game file141. The game file141has a game identification code corresponding to the identification code so that the small database12can precisely locate the game file141. The game file141also has a game title, a game program, or game sound data, or game graphic data, etc.

The game console2can be a computer, a tablet computer, a smart phone, a XBOX, a XBOX 360, a Playstation2 (PS2), a Playstation3 (PS3), a Nintendo Wii, a Nintendo64 (N64), or a similar electronic appliance capable of user interaction. The game console2contains at least an interface21for data transmission through WIFI, Bluetooth, USB, RS-454, IEEE1394, SATA, and Thunderbolt, Lighting, SD card socket (e.g., in a cellular phone), or any wired or wireless data transmission means. The interface21provides transmission functions such data downloading or overwriting existing files. The interface21is data-linked to a storage unit22which stores at least an application program. The application program is to access the small database12and display the relevant information about the game file141whose game identification code is corresponding to the identification code of the small database12. When a user is to select a game to play, the user makes the selection through a controller23. A central process unit (CPU)24loads the game file141into a free space in a main memory25of the game console2, and executes the game file141. The interface21is able to data-link to at least a preset server3, and the application program is able to compare the small database12's game information with a game database in the server3. Based on the comparison result, a new game file is downloaded or overwrites the existing game file141.

Additionally, the game console2can contains at least an optional optical disk apparatus to access an optical-disk storage medium4and to download a game file from the optical-disk storage medium4into the logic allocation unit14when a user selects and executes the installation of a game through the application program's menu. The cover data or configuration data in the optical-disk storage medium4is also downloaded into the configuration unit's respective blocks for the cover data or the configuration data. Relevant gaming information is also recorded in the small database12for speedily running a game.

As shown inFIGS. 1 to 3B, a process of accessing the portable storage device1by the game console2contains the following steps.

In step (a), an application program installed in the storage unit22of the game console2is activated.

In step (b), the application program searches the at least one interface21to see if the portable storage device1is connected. If yes, the process enters the step (c). Otherwise, the process enters the step (g).

In step (c), the target word unit11stored in the portable storage device1is searched. If the target word unit11is found, the process enters the step (d). Otherwise, the process enters the step (g).

In step (d), game information in the small database12is searched. If found, the process enters the step (e). Otherwise, the process enters the step (g).

In step (e), the presence of a cover data or a configuration data corresponding to the identification code of the small database12is checked. If yes, the process enters the step (f). Otherwise, the process enters the step (g).

In step (f), a configuration unit is accessed for the cover data or the configuration data.

In step (g), the cover data or the configuration data, if present, is displayed by the application program on a screen of the game console2.

As shown inFIG. 4, after the game console2obtains the cover data or the configuration data in the portable storage device1, a user can picks and runs a game from the screen. The process is as follows.

In step (10), the application program displays relevant game information in a menu on the screen.

In step (11), if the user picks a game to run, the process enters the step (12). Otherwise, the process returns to the step (10).

In step (12), the selected game's game file141in the portable storage device1is accessed.

In step (13), the game file is executed.

As shown inFIG. 5, a process of accessing the portable storage device1by the game console2which is a computer contains the following steps.

In step (a), the application program is activated and the application program searches the at least one interface21to see if the portable storage device1is connected. If yes, the process enter the step (b). Otherwise, the process enter the step (e).

In step (b), the target word unit11stored in the portable storage device1is searched. If the target word unit11is found, the process enters the step (c). Otherwise, the process enters the step (c1).

In step (c1), whether the portable storage device1is formatted is checked. If yes, the process enters the step (c2). Otherwise, the process enters the step (e).

In step (c2), the target word unit11, the small database12, the logic allocation unit14, the cover block, or configuration block are established. The process enters the step (e).

In step (c), game information in the small database12is searched. If found, the process enter the step (d). Otherwise, the process enters the step (e).

In step (d), whether the game identification code of the game file141in the logic allocation unit14is corresponding to the identification code of the small database12is checked. If yes, this means that the game file141is present.

In step (e), the application program displays relevant game information on a screen of the computer.

In step (f), a game in the computer is selected.

In step (g), whether the game identification code of the game's game file in the computer is corresponding to the identification code of the small database12is checked. If yes, the process returns to the step (f). Otherwise, the step enters the step (h).

In step (h), the game file is transmitted to the logic allocation unit14or the configuration unit. The identification code is established in the small database12.

As shown inFIG. 6, after the portable storage device1is mounted onto (i.e., is connected to) the game console2and a selection from a menu displayed by the application program is made, the process of linking and downloading from the server contains the following steps:

In step (a), the application program has accessed the game information specified by the selection from the menu.

In step (b), a connection of the game console2to the server3is tried. If the connection is established, the process enters the step (c). Otherwise, the process enters the step (h).

In step (c), the game information in the portable storage device1is compared against a game database in the server3. If they are identical, the process enters the step (d). Otherwise, the process enters the step (f).

In step (d), a game file is downloaded into the game console2.

In step (e), the game file is downloaded into the logic allocation unit14of the portable storage device1. The game information is established in the small database12.

In step (f), whether the game file has been updated is checked. If yes, the process enters the step (g). Otherwise, the process enters the step (h).

In step (g), the game file is written into the logic allocation unit14or the configuration unit.

In step (h), the application program returns to show the menu.

As shown inFIG. 7, after the portable storage device1is mounted onto the game console2and a selection from a menu displayed by the application program is made, the process of updating the game file contains the following steps.

In step (a), the application program has accessed the game information specified by the selection from the menu, and a menu is displayed.

In step (b), a menu item for checking or updating game file is selected.

In step (c), a connection of the game console2to the server3is tried. If the connection is established, the process enters the step (d). Otherwise, the process enters the step (g).

In step (d), the game information in the portable storage device1is compared against a game database in the server3. If the game program is not present, the process enters the step (e). If different, the game file is not present and the process enters the step (e). If identical, the game file is present or the game file is present but damaged, the process enters the step (f).

In step (e), the game file is downloaded into the game console2from the server3. The process enters the step (g).

In step (f), the game file is downloaded or is forcefully downloaded into the game console2. The process enters the step (f1).

In step (f1), the existing game file is overwritten by the newly downloaded game file.

In step (g), the application program returns to show the menu.

As shown inFIG. 8, in the main memory25of the game console2, there is at least a game information121which contains an identification code1211, and may further contain a game title1212, a file start section1213indicating a corresponding game file's start location in the logic allocation unit14, and a cover data1214for the game. When a user picks a game to play from the menu provided by the application program, a game file141in the logic allocation unit14having a game identification code corresponding to the identification code1211of the game information121therefore can be quickly located, loaded into a free space in the main memory25, and then executed. The game file141also contains the game title, the game program, or the game sound data, or the game graphic data. For the other game information121that is not picked, they are ignored, thereby achieving the asynchronous localization.

As shown inFIG. 9, if viewed from the perspective of the storage medium, there are multiple game files141in the logic allocation unit14. Each game file141is packaged as a game block. When a game file141is selected and unpacked, the game block contains a game identification code, a game title, a game program, or game sound data, or game graphic data. As shown inFIG. 10, if viewed from the perspective of the game console2, there are multiple game blocks. Each game block contains a game identification code, a game title, a game program, or game sound data, or game graphic data. Please note that the game file can be a compressed file or any package file. Additionally, a game file ofFIG. 9is basically identical to a game block of FIG.10as the difference only lies in the perspective. Therefore, accessing a game file can be deemed as accessing game block.

As shown inFIG. 11, the localization method contains the following steps.

In step (a), an application program installed in an internal storage unit22of a game console2is activated.

In step (b), the application program searches through at least an interface21to see if a portable storage device1is connected. If yes, the process enters the step (c). Otherwise, the process enters the step (e).

In step (c), a target word unit11in the portable storage device1is searched. If not found, the process enters the step (e). Otherwise, the process enters the step (d).

In step (d), game information in a small database12of the portable storage device1is searched.

In step (e), the game information is returned to the application program and is displayed in a menu of the application program.

As shown inFIGS. 12 to 14, another embodiment of the localization method contains the following steps.

In step (a), an application program installed in an internal storage unit of a game console is activated.

In step (b), the application program searches through at least an interface to see if a portable storage device is connected. If yes, the process enters the step (c). Otherwise, the process enters the step (f).

In step (c), a target word unit in the portable storage device is searched. If not found, the process enters the step (f). Otherwise, the process enters the step (d).

In step (d), game information in a small database (i.e., header) of the portable storage device is searched. If the game information is found, the process enters the step (e). Otherwise, the process enters the step (f).

In step (e), whether the small database has user partitions is checked. If there is no user partition, a number of auxiliary small databases are produced. If a user partition is found, whether the user partition is in use is further checked. If the user partition is idle, the user partition is assigned to a new user.

In step (f), the game information is returned to the application program and is displayed in a menu of the application program.

The present embodiment is different from the previous embodiment in that the present embodiment provides many-to-one or one-to-many scenarios. When a first user logs in, the small database5automatically updates the data in the auxiliary small databases6, and uses the first auxiliary small database6. Subsequently, when a second user logs in, a second auxiliary small database6can be used. As such, the first and second users do not have data conflict when they conduct their game playing. In other words, each user has his/her own small databases. If a third user logs in, then a third auxiliary small database6can be used, and so on. In this way, when multiple users log in to play games, each user has proprietary small database5or auxiliary small database6for game-related operations, thereby avoiding data conflict from using a same small database. Subsequently, when the small database5is updated, the auxiliary small databases6can be updated synchronously so that each user is able to access the latest game menu.

While certain novel features of this invention have been shown and described and are pointed out in the annexed claim, it is not intended to be limited to the details above, since it will be understood that various omissions, modifications, substitutions and changes in the forms and details of the device illustrated and in its operation can be made by those skilled in the art without departing in any way from the spirit of the present invention.