U.S. patent application number 12/638652 was filed with the patent office on 2010-04-15 for method, system for controlling service access and server.
This patent application is currently assigned to Tencent Technology (Shenzhen) Company Ltd.. Invention is credited to Liang Hu, Min Yan, Caishi Yang.
Application Number | 20100093443 12/638652 |
Document ID | / |
Family ID | 38880637 |
Filed Date | 2010-04-15 |
United States Patent
Application |
20100093443 |
Kind Code |
A1 |
Yan; Min ; et al. |
April 15, 2010 |
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.
Inventors: |
Yan; Min; (Shenzhen city,
CN) ; Yang; Caishi; (Shenzhen city, CN) ; Hu;
Liang; (Shenzhen city, CN) |
Correspondence
Address: |
MARSHALL, GERSTEIN & BORUN LLP
233 SOUTH WACKER DRIVE, 6300 SEARS TOWER
CHICAGO
IL
60606-6357
US
|
Assignee: |
Tencent Technology (Shenzhen)
Company Ltd.
Shenzhen
CN
|
Family ID: |
38880637 |
Appl. No.: |
12/638652 |
Filed: |
December 15, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
PCT/CN2008/070545 |
Mar 20, 2008 |
|
|
|
12638652 |
|
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
H04L 12/1818 20130101;
A63F 2300/5546 20130101; A63F 2300/572 20130101; H04L 67/38
20130101; A63F 13/795 20140902; A63F 13/35 20140902; A63F 2300/513
20130101; H04L 67/1002 20130101 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Foreign Application Data
Date |
Code |
Application Number |
Jun 15, 2007 |
CN |
200710111340.1 |
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.
Description
FIELD OF THE INVENTION
[0001] 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
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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
[0012] FIG. 1 is a flowchart illustrating a procedure of
implementing an invitation according to the prior art.
[0013] FIG. 2 is a block diagram illustrating a structure of an
online game invitation system according to an embodiment of the
present invention.
[0014] 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
[0015] An existing invitation procedure is as shown in FIG. 1,
which includes the following steps.
[0016] 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.
[0017] 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.
[0018] Step 103: the invitee messenger client accepts the
invitation and sends a response message to the inviter messenger
client through the messenger Server.
[0019] Step 104: after receiving the response message, the inviter
messenger client automatically starts an inviter game client.
[0020] Step 105: the inviter game client logs on a Game Server to
authenticate user information.
[0021] 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.
[0022] 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.
[0023] Step 108: after receiving the game information, the inviter
messenger client sends the game information to the invitee
messenger client through the messenger Server.
[0024] Step 109: the invitee messenger client receives the game
information.
[0025] Step 110: the invitee messenger client automatically starts
an invitee game client according to the game information
received.
[0026] Step 111: the invitee game client logs on the Game Server to
authenticate user information
[0027] Step 112: after the authentication is passed, the invitee
game client joins in the game position selected by the inviter game
client.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.about.307d and steps
308a.about.308b.
[0047] Steps 307a.about.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.
[0048] Steps 308a.about.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.
[0049] In the above steps 307a.about.307d and 308a.about.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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] Step 311: the inviter sub-game end 13 and the invitee
sub-game end 23 are respectively started to play the game.
[0055] 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.
[0056] 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.
[0057] The present invention has the following advantages and
characteristics: [0058] 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;
[0059] 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. [0060]
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.
[0061] 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.
[0062] 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.
[0063] The foregoing are only preferred embodiments of the present
invention and are not for use for limiting the protection scope of
the present invention.
* * * * *