METHOD, SYSTEM FOR CONTROLLING SERVICE ACCESS AND SERVER

Abstract

A method for controlling service access is provided. the method includes: creating a service group comprising more than one client; searching, by a server, for a service component, wherein the number of users allowed to access the service component is larger than or equal to the number of the clients in the service group; configuring the service component as being accessible to only the clients in the service group; and informing the clients in the service group that the service component is accessible; and accessing, by the clients in the service group, the service component. A server and a system corresponding to the method are provided at the same time. By applying the method and system of the present invention, success ratio of the invitation is improved and the implementation procedure is simplified.

Description

FIELD OF THE INVENTION

The present invention relates to Instant Messaging (IM) technologies, and more particularly to a method, system for controlling service access and server.

BACKGROUND OF THE INVENTION

In current Internet applications, along with rapid development of Instant Messaging (IM), various applications and services based on the IM, such as multi-player online game, etc., are widely used. The multi-player online game refers that a user sends an invitation through his/her IM client to invite two or more users to participant in the same game to implement the multi-player online game.

In the prior art, there are relatively mature solutions to implement the multi-player online game. Take a scenario where two users participant in the same game as an example, an existing system for implementing the online game includes: an inviter messenger client, a Game Server, a messenger Server, an invitee messenger client, an inviter game client and an invitee game client, etc. Usually, a game client is also referred to as a game hall. On the Game Server, there are multiple threads or components to implement a game. The threads and components can be accessed by multiple users (clients) to implement the function of multi-player online game. This kind of thread is usually referred to as a game table. The accessing to the game thread or component of the clients is referred to as the user joining in the game table or occupying a game position. Further, for facilitating management, similar game threads or components in the same Game Server are divided into multiple groups, each group is called as a game room, and each game room may have multiple game tables. In some cases, a game thread or component may also be called as a game room.

In the prior art, the game position is selected by the inviter game client and is informed to the invitee game client by the system automatically. It is unnecessary for the invitee game client to acknowledge. As such, a problem arises: if a game position, such as seats to a game table, has been seized by other players before the invitee joins, the invitee cannot join in the same table but only joins the same room. In other words, in the existing game invitation procedure, after selecting the game table, the inviter game client cannot ensure that there is an available seat when the invitee game client joins. It is quite possible that all available seats of the game table corresponding to the inviter game client have been occupied by other players before the invitee game client joins, thus the invitation cannot be implemented.

Moreover, in the existing procedure, the game position is selected by the inviter game client. Then the messenger Server forwards information of all the game tables such as room and seat information. Finally, subsequent operations of the inviter game client and the invitee game client are invoked and initiated. In this way, the invitation procedure is relatively complicated.

In the prior art, the invitation request is generated through the inviter messenger client and the inviter game client will be started directly after the invitation information is acknowledged. In this way, the game invitation and response functions must be integrated in the messenger Client during development, which increases workload for developing the messenger Client and results in a bad extensibility.

SUMMARY OF THE INVENTION

Embodiments of the present invention provides a method, system for controlling service access and a server, so as to solve the problem that the service invitation cannot be really implemented in the prior art.

According to an embodiment of the present invention, a method for controlling service access is provided. The method includes: creating a service group comprising more than one client; searching, by a server, for a service component, wherein the number of users allowed to access the service component is larger than or equal to the number of the clients in the service group; configuring the service component as being accessible to only the clients in the service group; and informing the clients in the service group that the service component is accessible; and accessing, by the clients in the service group, the service component.

According to another embodiment of the present invention, a control server for controlling service access is provided. The control server includes: A server for controlling service access, including: a first unit, adapted to manage at least one service component; a second unit, adapted to search the first unit for a service component when a service group comprising more than one client has a service access requirement, wherein the number of users allowed to access the service component being searched for is larger than or equal to the number of clients in the service group; and a third unit, adapted to configure the service component searched out by the second unit as accessible to only the clients in the service group.

According to another embodiment of the present invention, a system for controlling service access is provided. The system includes: a server, adapted to manage service components, search for a service component wherein the number users allowed to access the service component is larger than or equal to the number of clients in a service group, configure the service component as accessible to only the clients in the service group, and inform the clients in the service group that the service component is accessible; and at least two clients in the service group, adapted to access the service component searched out by the server.

In the present invention, the server selects a service component which is able to hold all members in a service group. Through restricting the service component as being accessible to only the clients in the service group, all the clients in the service group can access the service component and perform service operations, which increases the success ration of the invitation during creation of the service group and implementation of the service invitation.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flowchart illustrating a procedure of implementing an invitation according to the prior art.

FIG. 2 is a block diagram illustrating a structure of an online game invitation system according to an embodiment of the present invention.

FIG. 3 is a flowchart illustrating a procedure of implementing an online game invitation according to a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

An existing invitation procedure is as shown in FIG. 1, which includes the following steps.

Step 101: an inviter messenger client triggers a game button on an IM interface to send a game invitation request to an invitee messenger client through a messenger Server.

Step 102: after receiving the invitation sent from the inviter messenger client, the invitee messenger client prompts that an invitation is received and determines whether to accept the invitation. If the invitation is not accepted, the invitation procedure is finished. If the invitation is accepted, step 103 is performed.

Step 103: the invitee messenger client accepts the invitation and sends a response message to the inviter messenger client through the messenger Server.

Step 104: after receiving the response message, the inviter messenger client automatically starts an inviter game client.

Step 105: the inviter game client logs on a Game Server to authenticate user information.

Step 106: after the authentication is passed, the inviter game client selects and joins in a game position, wherein the game position, such as game room, game table, etc. is selected by the inviter game client itself.

Step 107: after selecting the game position, the inviter game client sends game information to the inviter messenger client. The game information includes but is not limited to: Game Server ID, Game room ID and relevant game data, etc.

Step 108: after receiving the game information, the inviter messenger client sends the game information to the invitee messenger client through the messenger Server.

Step 109: the invitee messenger client receives the game information.

Step 110: the invitee messenger client automatically starts an invitee game client according to the game information received.

Step 111: the invitee game client logs on the Game Server to authenticate user information

Step 112: after the authentication is passed, the invitee game client joins in the game position selected by the inviter game client.

In the above procedure, the game position is selected by the inviter game client and is informed to the invitee game client by the system automatically. It is unnecessary for the invitee game client to acknowledge. As such, a problem arises: if a game position, such as a seat to a game table, has been seized by another player before the invitee joins, the invitee cannot join in the same table but only joins the same room. In other words, in the existing game invitation procedure, after selecting the game table, the inviter game client cannot ensure that there is an available seat when the invitee game client joins. It is quite possible that all available seats of the game table corresponding to the inviter game client have been occupied by other players before the invitee game client joins, thus the invitation cannot be implemented.

Moreover, in the existing procedure, the game position is selected by the inviter game client. Then the messenger Server forwards information of all game tables such as room and seat information. Finally, subsequent operations of the inviter game client and the invitee game client are invoked and initiated. In this way, the invitation procedure is relatively complicated.

In addition, in the procedure shown in FIG. 1, the invitation request is generated through the inviter messenger client and the inviter game client will be started directly after the invitation information is acknowledged. In this way, the game invitation and response functions must be integrated in the messenger Client during development, which increases workload for developing the messenger Client and results in a bad extensibility.

The core idea of the present invention relies in that, the Game Server implements the selection of a final game position for the game position of the inviter game client and the invitee game client; after the game position is determined, the inviter and the invitee are informed to join in the same game position and proceed with subsequent procedure, so as to guarantee the success rate of the invitation.

For facilitating the communications between the messenger clients and the game clients respectively, and between the messenger clients and the Game Server, and for extension of the messenger clients, a game client Plug-in may be respectively configured in the inviter and the invitee in the present invention. The game client Plug-in is adapted to generate messages, such as the invitation message and the response message. As such, a uniform management can be performed. Further, in the present invention, when the inviter messenger client initiates the invitation, online friend information and Game Server related information are obtained through an invitation interface of the game client Plug-in to generate relevant invitation information. Thus it is unnecessary to start the inviter game client, which is more convenient and efficient.

In the embodiments of the present invention, the inviter game client may be started immediately after the invitee messenger client receives the invitation message and determines to accept the invitation. In this way, better experience is obtained, and WYTIWYG (What You Think Is What You Get) is implemented.

As shown in FIG. 2, the system for implementing online game invitation according to an embodiment of the present invention includes: an inviter 10, an invitee 20, a messenger server 30 and a game server 40. The inviter 10 and the invitee 20 are both connected with the messenger server 30 and the game server 40. The inviter 10 is a collection of hardware and software used by a user initiating the invitation; it may also be called as inviter client 10. The invitee 20 is a collection of hardware and software used by a user being invited and may also be called as invitee client 20. The messenger server 30 is adapted to connect messenger clients of all users and implement functions such as user status query, friend list management, message forwarding, etc. The game server 40 is adapted to connect game management clients of all users and implement functions such as game distribution, game rule configuration and implementation, user status query, game information forwarding, game account authentication and management, bill recording, advertisement pushing, etc. More importantly, the game server 40 is further adapted to implement selection of a game position, i.e. pair game players.

The inviter 10 further includes an inviter messenger client 11, an inviter game client 12, an inviter sub-game end 13 and an inviter game client Plug-in 14. The inviter messenger client 11 is adapted to receive and send information of the inviter 10. The inviter game client 12 is adapted to implement function management of various games of the inviter 10, such as download, installation, configuration, friend/blacklist, group organization, communication, property purchase, advertisement. The inviter sub-game end 13 is adapted to implement multi-player game of the inviter 10. The inviter game client Plug-in 14 is a program Plug-in compiled as required by an IM software interface and is adapted to generate messages, implement communications between the inviter messenger client 11, the inviter game client 12 and the game server 40, and is further adapted to implement interaction operations and content display of a user invitation interface of the inviter 10. Information contents generated and forwarded by the inviter game client Plug-in includes but is not limited to: user account, user password, game server information, friend information, game position information of the user, game content information of the user, game position information of a friend, and game content information of the friend.

The invitee 20 further includes an invitee messenger client 21, an invitee game client 22, an invitee sub-game end 23 and an invitee game client Plug-in 24. The invitee messenger client 21 is adapted to receive and send information of the invitee 20. The invitee game client 22 is adapted to implement function management of various games of the invitee 20, such as download, installation, configuration, friend/blacklist, group organization, communication, property purchase, advertisement, etc. The invitee sub-game end 23 is adapted to implement multi-player game of the invitee 20. The invitee game client Plug-in 24 is a program Plug-in compiled as required by the IM software interface, and is adapted to generate messages, implement communications between the invitee messenger client 21, the invitee game client 22 and the game server 40, and is further adapted to implement interaction operations and content display of a user invitation interface of the invitee 20. Information contents generated and forwarded by the invitee game client Plug-in includes but is not limited to: user account, user password, game server information, friend information, game position information of the user, game content information of the user, game position information of a friend and game content information of the friend.

In the system as shown in FIG. 2, the inviter game client Plug-in 14 and the invitee game client Plug-in 24 are optional. If the inviter game client Plug-in and the invitee game client Plug-in are not configured in the inviter or the invitee, the generation and the reception of the invitation message and the response message, the interaction operations and the contents display of the user invitation interface can be implemented by the inviter messenger client and the invitee messenger client respectively.

Based on the system shown in FIG. 2, a method for implementing an online game invitation in accordance with a preferred embodiment of the present invention is shown in FIG. 3, which includes the following steps.

Step 301: when desiring to send a game invitation to the invitee 20, the inviter 10 firstly starts the inviter messenger client 11 and starts the inviter game client Plug-in 14 embedded in the inviter messenger client 11 to generate an invitation interface.

Step 302: the inviter game client Plug-in 14 obtains a game list directly from the game server 40 and presents the game list to the inviter 10.

Step 303: the inviter messenger client 11 obtains an online status of the invitee 20 through the messenger server 30. If the invitee 20 is online, the inviter 10 generates an invitation message through the inviter game client Plug-in 14 to initiate a game invitation and create a service group.

The step of generating the invitation message includes: the inviter game client Plug-in 14 selects and determines game information such as game type and game room etc. according to a game list obtained, and generates the invitation message in a fixed format according to the game information.

Step 304: the inviter messenger client 11 sends the generated invitation message to the invitee game client Plug-in 24 through the messenger server 30. The invitation message includes but is not limited to: inviter identity (UID), game information, game area information, game room information and network environment information, etc.

Step 305: after receiving the invitation message of the inviter messenger client 11, the invitee game client Plug-in 24 prompts that an invitation is received and determines whether to accept the invitation. If the invitation is not accepted, the invitation procedure will be finished directly; if the invitation is accepted, step 306 is performed, and the invitee game client Plug-in 24 joins in the service group.

Before step 305, the invitee 20 may firstly start the invitee messenger client 21 and the invitee game client Plug-in 24 embedded in the invitee messenger client 21, so that the invitee game client Plug-in 24 is in a working state.

Step 306: the invitee messenger client 21 accepts the invitation, sends a response message to the inviter game client Plug-in 14 through the messenger server 30 to indicate that the invitation is accepted, and starts the invitee game client 22. In this way, the inviter 10 and the invitee 20 generates a service group for performing game services. The service group includes more than one client. Afterwards, the inviter 10 and the invitee 20 respectively perform steps 307a˜307d and steps 308a˜308b.

Steps 307a˜307b: the inviter game client Plug-in 14 receives the response message and starts the inviter game client 12. The inviter game client 12 logs on the game server 40 to authenticate user information. The information used in the authentication includes invitation-related information, such as an ID assigned for the invitation and a UID which accepts the invitation. After the authentication is passed, join in a determined game area or room according to the game room selected in step 303, and wait the game server to determine a final game position.

Steps 308a˜308b: the invitee game client 22 logs on the game server 40 to authenticate user information. The information used in the authentication includes invitation-related information, such as an ID assigned for the invitation and a UID which initiating the invitation. After the authentication is passed, the invitee game client 22 joins in the game area or room designed by the inviter 10 according to the invitation message, and waits the game server to determine the final game position.

In the above steps 307a˜307d and 308a˜308b, lithe inviter game client 12 has already logged on the game server before sending the invitation message, the invitation-related information such as the ID assigned for the invitation and the UID which accepts the invitation may be sent to the game server by the inviter game client Plug-in 14. If the inviter 10 is not equipped with the inviter game client Plug-in 14, the invitation-related information may be sent to the game server by the inviter messenger client 11.

Step 309: the game server 40 stores the invitation-related information such as the ID assigned for the invitation, the UID which initiates the invitation and the UID which accepts the invitation, etc., and determines the final game position according to an available seat preferable principle. The game server 40 automatically sends pair information, i.e. the selected final game position, to the inviter game client 12 and the invitee game client 22.

The available seat preferable principle means that: when selecting seats, the game server 40 most preferably selects a game table with all seats currently available for the inviter game client and the invitee game client to join in; less preferably, select the game table with one seat occupied. And then, select the game table with two seats occupied. In the same way, until select the game table with only two seats available. As such, the success of the invitation may be ensured. Certainly, if multiple users are invited, the game table with multiple available seats may be selected according to the available seat preferable principle to guarantee the success of the invitation. In the embodiments of the present invention, the final game position is obtained by a following manner: according to the available seat preferable principle, the game server searches for a game thread or component which allows a number of users to access, wherein the number is larger than or equal to the number of users in the invitation. If such game thread or the component is found, the game thread or component is taken as a target game table, i.e. the final game position.

Step 310: the game server 40 sends the determined final game position to the inviter game client 12 and the invitee game client 22. After receiving the final game position, the inviter game client 12 and the invitee game client 22 respectively join in the determined game position.

After determining the final game position, the game server 40 may temporarily lock the game position to prevent the position from being occupied by other users before the inviter and the invitee join. Specifically, it is possible to configure an access control parameter of the game position, i.e. the game thread or the component, as access according to an Access Control List, i.e. according to the UIDs in a white list. When determining that all the clients corresponding to the UIDs in the white list have accessed the game thread or the component, the game server 10 configures the access control parameter as accessible to all clients. The white list is a table in an access attribute of the game thread or component. Only the client whose UID is in the white list is allowed to access the game thread or component.

Step 311: the inviter sub-game end 13 and the invitee sub-game end 23 are respectively started to play the game.

In the procedure shown in FIG. 3, if the inviter game client Plug-in and the invitee game client Plug-in are not configured in the inviter and the invitee, the generation and reception of the invitation message and response message, the interaction operations and content display of the user invitation interface may be implemented by the inviter messenger client and the invitee messenger client respectively.

In practical applications, the inviter game client Plug-in may start the inviter game client before sending the invitation message or before generating the invitation message. The inviter game client logs on the game server to authenticate the user information. After the authentication, the inviter game Plug-in sends the invitation message to the invitee through the messenger server, or generates the invitation message and sends the generated invitation message to the invitee through the messenger server. In this case, after receiving the response message returned by the invitee, the inviter game client Plug-in informs the inviter game client to join in the game room selected in advance and to join in the final game position after the game server determines the final game position.

The present invention has the following advantages and characteristics:

• • 1) in the present invention, the game server implements the final game pair and determines the final game position, which increases the success ratio of the invitation;
  • 2) in the present invention, the inviter game client Plug-in and the invitee game client Plug-in are configured in the inviter and the invitee to integrate the information forwarding between the messenger clients and their respective game clients and between the messenger clients and the game server, generate the invitation message and response message, etc., so as to facilitate management of communication information. Further, the usage of the Plug-ins meets the extension requirements of the messenger clients.
  • 3) in the present invention, related information in the game server, such as the game list, may be directly obtained by the inviter game client Plug-in without opening the inviter game client, which improves response sensitivity for user operates; further, the inviter may implement further selection according to the related information obtained, which is flexible and convenient.
  • 4) in the present invention, after the invitee accepts the invitation the invitee game client rather than that of the inviter may be started first, which provides the user with better experience and is simple and more efficient.

In view of the above, the present invention optimizes the whole invitation procedure and automatically generates complete invitation data according to the inviter's will by the client program or background server. Meanwhile, the present invention ensures that the invitation procedure is not affected by actions of other external users, which not only increases the success ratio of the invitation but also brings better experience for the user.

The foregoing are only preferred embodiments of the present invention and are not for use for limiting the protection scope of the present invention.

Claims

1. A method for controlling service access, comprising:

creating a service group comprising more than one client;

searching, by a server, for a service component, wherein the number of users allowed to access the service component is larger than or equal to the number of the clients in the service group; configuring the service component as being accessible to only the clients in the service group; and informing the clients in the service group that the service component is accessible; and

accessing, by the clients in the service group, the service component.

2. The method of claim 1, wherein the creating the service group comprising more than one client comprises:

sending, by a first client, a service invitation to at least one second client to create the service group; and

responding, by the at least one second client, the service invitation and joining in the service group.

3. The method of claim 2, wherein the searching for the service component comprises:

obtaining, by the server, the number of the clients in the service group; and

searching, by the server, for the service component according to an available seat preferable principle.

4. The method of claim 3, wherein the obtaining the number of the clients in the service group comprises:

obtaining, by the server, the number of the clients in the service group when the clients log on the server.

5. The method of claim 3, wherein the clients are messenger clients, and the obtaining the number of the clients in the service group comprises:

if the clients have logged on the server before the service group is created, sending, by an inviter messenger client, User Identifiers (UIDs) of the clients in the service group to the server; and

obtaining, by the server, the number of the clients in the service group according to the UIDs.

6. The method of claim 3, wherein the clients are messenger clients and each messenger client comprises a service function Plug-in, the obtaining the number of the clients in the service group comprises:

if the clients have logged on the server before the service group is created, sending, by the service function Plug-in of an inviter, UIDs of the clients in the service group to the server; and

obtaining, by the server, the number of the clients in the service group according to the UIDs.

7. The method of claim 1, wherein configuring the service component as being accessible to only the clients in the service group comprises:

storing UIDs of all the clients in the service group;

writing the UIDs of all the clients in the service group into an access control list; and

configuring an access control parameter of the service component as access according to the UIDs in the access control list.

8. The method of claim 7, further comprising:

after determining that UIDs of clients currently access the service component comprises the UIDs of all the clients in the service group, configuring, by the server, the access control parameter of the service component as accessible to all clients.

9. A server for controlling service access, comprising:

a first unit, adapted to manage at least one service component;

a second unit, adapted to search the first unit for a service component when a service group comprising more than one client has a service access requirement, wherein the number of users allowed to access the service component being searched for is larger than or equal to the number of clients in the service group; and

a third unit, adapted to configure the service component searched out by the second unit as accessible to only the clients in the service group.

10. The server of claim 9, further comprising:

a fourth unit, adapted to inform the clients in the service group that the service component searched out by the second unit is accessible.

11. The server of claim 9, wherein the third unit is further adapted to allow all the clients to access the service component after determining that User Identifiers (UIDs) of clients currently access the service component comprises UIDs of all the clients in the service group.

12. A system for controlling service access, comprising:

a server, adapted to manage service components, search for a service component wherein the number users allowed to access the service component is larger than or equal to the number of clients in a service group, configure the service component as accessible to only the clients in the service group, and inform the clients in the service group that the service component is accessible; and

at least two clients in the service group, adapted to access the service component searched out by the server.

13. The system of claim 12, wherein the server is further adapted to allow all clients to access the service component after determining that User Identifiers (UIDs) of clients currently access the service component comprises UIDs of all the clients in the service group.

14. The system of claim 12, wherein each of the clients is further adapted to send a service invitation to create the service group or adapted to respond to a service invitation sent by another client to join in the service group.