U.S. patent application number 11/393901 was filed with the patent office on 2007-10-11 for methods and devices for exchanging messages in an always-on network.
Invention is credited to Girish P. Chandranmenon, Fang Hao, Scott C. Miller, Sarit Mukherjee, Tejas Naik.
Application Number | 20070238526 11/393901 |
Document ID | / |
Family ID | 38576013 |
Filed Date | 2007-10-11 |
United States Patent
Application |
20070238526 |
Kind Code |
A1 |
Chandranmenon; Girish P. ;
et al. |
October 11, 2007 |
Methods and devices for exchanging messages in an always-on
network
Abstract
Components of an "always-on" network exchange messages to, among
other things, allow an agent to monitor the "presence status" of an
associated user. By monitoring the presence status of the user, the
agent may act as a proxy for the user when the user becomes
inactive.
Inventors: |
Chandranmenon; Girish P.;
(Edison, NJ) ; Hao; Fang; (Morganville, NJ)
; Miller; Scott C.; (Freehold, NJ) ; Mukherjee;
Sarit; (Morganville, NJ) ; Naik; Tejas;
(Edison, NJ) |
Correspondence
Address: |
CAPITOL PATENT & TRADEMARK LAW FIRM, PLLC;ATTN: JOHN CURTIN
P.O. BOX 1995
VIENNA
VA
22183
US
|
Family ID: |
38576013 |
Appl. No.: |
11/393901 |
Filed: |
March 31, 2006 |
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
A63F 2300/5566 20130101;
H04L 67/24 20130101; A63F 2300/402 20130101; A63F 13/358
20140902 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method for exchanging messages between a client device and an
always on agent comprising: generating one or more messages, each
message comprising at least one submessage, wherein the at least
one submessage comprises a presence status that indicates whether a
device is active or inactive.
1. The method as in claim 1 wherein the at least one submessage
comprises either a subscribe or unsubscribe submessage.
2. The method as in claim 1 wherein the at least one submessage
comprises an alert notification submessage.
3. The method as in claim 1 further comprising forwarding the one
or more messages to the always on agent.
4. The method as in claim 1 wherein the at least one submessage
comprises a synchronization submessage.
5. The method as in claim 1 wherein the at least one submessage
comprises a game playing submessage.
6. The method as in claim 1 wherein the at least one submessage
comprises a common submessage.
7. A device for exchanging messages with an always on agent
operable to: generate one or more messages, each message comprising
at least one submessage, wherein the at least one submessage
comprises a presence status that indicates whether a device is
active or inactive.
8. The device as in claim 8 wherein the at least one submessage
comprises either a subscribe or unsubscribe submessage.
9. The device as in claim 8 wherein the at least one submessage
comprises an alert notification submessage.
10. The device as in claim 8 further operable to forward the one or
more messages to the always on agent.
11. The device as in claim 8 wherein the at least one submessage
comprises a synchronization submessage.
12. The device as in claim 8 wherein the at least one submessage
comprises a game playing submessage.
13. The device as in claim 8 wherein the at least one submessage
comprises a common submessage.
Description
[0001] Co-pending U.S. patent application Ser. Nos. ______, ______,
and ______, incorporated by reference in full herein as if set
forth in full herein, disclose methods and devices which, among
other things, enables users to conduct communication sessions
(e.g., on-line games) quickly and with greatly reduced airlink
time/bandwidth than previously thought possible. In general, the
co-pending Applications just mentioned disclose "always-on" methods
and devices because even when a user of a device is inactive (e.g.,
her device is powered-off) an "always-on agent" may act as a proxy
and continue to act on behalf of the user/user's device during a
given communication session.
BACKGROUND OF THE INVENTION
[0002] To carry out the features and functions described in the
co-pending Applications mentioned above novel messages may be
exchanged. The present invention is directed at the generation and
subsequent exchange of such messages. The following discussion
provides some examples of the format and content of such
messages.
SUMMARY OF THE INVENTION
[0003] The present invention provides methods and devices that
generate messages that may be exchanged between components of an
"always-on" network and the like. For example, the present
invention provides for methods that allow user devices and their
agents exchange messages. In one exemplary method, a device may
generate one or more messages, where each message contains at least
one sub-message. The sub-message may: (a) contain information
concerning the presence status of the device and its associated
user; (b) indicate a subscribe/unsubscribe status to one or more
services; (c) comprise an alert notification; (d) comprise a
synchronization signal ("sync"); (e) contain game playing
information; or (f) represent common messages, to name just some of
the many types of sub-messages provided by the present
invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] FIG. 1 depicts a block diagram illustrating an "always-on"
architecture according to one embodiment of the present
invention.
DETAILED DESCRIPTION OF THE INVENTION. WITH EXAMPLES
[0005] Referring now to FIG. 1 there is shown an always-on
architecture 1 in accordance with one embodiment of the present
invention. This architecture 1 may be used by a service provider to
deliver one or more services in a manner that is faster than
previously thought possible while requiring a minimal amount of
changes or upgrades to the provider's network.
[0006] While the discussion which follows will focus on on-line
gaming, it should be understood that the architectures provided by
the present invention may be used for any number of services; that
is, they are not limited to just gaming services, applications or
activities.
[0007] In addition, it should be understood that a service provider
may chose to implement an always-on architecture provided by the
present invention in any number of ways. For example, one
architecture (such as architecture 1) may be implemented such that
it is underneath another application (e.g., gaming application).
That is to say any third party communication applications the
service provider has available may lay on top of the always-on
architecture.
[0008] To provide the always-on features and functions described in
the co-pending Applications mentioned above, such as presence
management/proxying, real-time launching of services, and game
playing the components shown in FIG. 1 need to exchange messages
with one another.
[0009] The architecture 1 in FIG. 1 comprises an always-on client 2
("client"), applications client 2a (e.g., "game client"), always-on
proxy agent 3 ("agent"), always-on lobby 4 ("lobby"), an
applications/game server/engine 5 (e.g., "game server") and one or
more other third party agents 300. Besides hardware
implementations, the client 2 and applications client 2a may also
comprise one or more software or firmware programs/applications
that may be co-located and stored on a computer readable medium 20
of some sort (e.g., hard-drive, compact disc, memory, memory and
processor) which may be, in turn, embedded within a larger device
200, such as a wired or wireless telephone, personal digital
assistant (PDA), computer, gaming device, or a device which
combines one or more functions (e.g., email and voice messaging),
etc., . Alternatively, the client 2 and applications client 2a may
be stored on more than one medium or stored on separate mediums.
Likewise, the agent 3 and lobby 4 may also comprise one or more
applications and may also be stored on some kind of computer
readable medium 30, 40, respectively, that are also part of one or
more wired or wireless devices, such as a server 34 or the like.
Though shown as one component 34, it should be understood that the
agent 3 and lobby 4 may be separate units and need not be
co-located. When stored on one or more mediums, a
program/application may comprise code that controls the features
and functions of a component shown in FIG. 1. More details
concerning the architecture 1 are set forth in the co-pending
Applications mentioned above.
[0010] More specifically, in one embodiment of the present
invention, the device 200 may interact with the agent 3 through an
interface 2b. Many times the device 200 will be a hand-held device
(or handset for short). To simplify the explanation which follows
we may refer to the device 200 as simply a handset, it being
understood that this is just one example of the type of device that
may make use of the messages provided by the present invention. In
addition, though in our discussion we may state that the device or
handset 200 generates, exchanges or forwards messages, many times
it is the interface 2b and/or client 2/applications client 2a that
is actually involved in generating, forwarding and/or receiving
messages.
[0011] Like the client 2 and applications client 2a, the interface
2b may comprise hardware, software, firmware or some combination of
the three. When embodied in software/firmware, interface 2b may
comprise one or more programs/applications that may be co-located
and stored on a computer readable medium 20 of some sort which may
be, in turn, embedded within handset 200. When stored on one or
more mediums, a program/application may comprise code that controls
the features and functions of interface 2b. In yet an additional
embodiment of the invention, the interface 2b comprises software
that works in conjunction with an air interface of handset 200.
[0012] Continuing, within handset 200 the client 2 and interface 2b
may typically handle all communications, including the exchange of
messages with agent 3. In one alternative embodiment of the
invention, the interface 2b may be part of the client 2. For the
sake of simplicity, we shall assume this is the case for the
remainder of this discussion. However, it should be realized that
this is an optional feature of the present invention. In accordance
with an embodiment of the present invention, the client 2 may
generate messages formatted as binary User Datagram Protocol (UDP)
packets (i.e., "short binary messages") in order to minimize
airlink delays and to make the implementation of the network 1 and
its many agents 3,300 scalable. In general, the messages generated
by both the client 2 and agent 3 may be structured as follows:
[0013]
MsgLen|Ver|#SubMsgs|SrcID|DstID|SeqNo|Authentication|(SubMsgs)*
where the asterisk indicates one or more submessages.
[0014] The message header of such a message may include the
following fields from the structure above. First, the "SrcID" field
(e.g., 4 bytes in length). This field identifies the component that
is sending or forwarding a message. In messages sent from the
handset 200 to the agent 3, this field contains the identification
(ID) of the handset. The ID is typically assigned by a provisioning
server (not shown in FIG. 1). It may be assigned, for example, when
the user subscribes to an always on service. In messages sent from
the agent 3 to the handset 200, this field may contain the ID of
the agent 3 which also may be assigned by a provisioning
server.
[0015] The next field that may be part of the header is the "DstID"
field. It too may be 4 bytes in length. This field may be used to
identify the recipient of a message. The third field that may be
part of the header is a "SeqNo" field. Again, it may be 4 bytes in
length. This field may be used to indicate the sequence number of a
given message. The next field that may be part of the header is the
"Authentication" field. As with the other fields it may be 4 bytes
in length. This field may be used to hold content/information to
authenticate a sender of a message. It may also be used to assure
that a message has not been corrupted or altered by an unauthorized
third party (e.g., by sniffing). The last field that will be
discussed herein which may be part of the header is a "SubMsgs"
field. In accordance with an exemplary embodiment of the present
invention, this field may in fact comprise a sequence of one or
more sub-messages.
[0016] The following discussion will highlight some examples of
sub-messages so that the reader may gain an understanding of the
present invention. In general, sub-messages may be classified into
four categories: state sync, presence update, game playing, and
common sub-messages. It should be noted that the present invention
places no restriction on the number or type of sub-messages that
may be contained in a single message. Instead, a particular
combination may be purely based on timing, performance or other
considerations.
[0017] Further, it should be noted that if a particular message
contains at least one sub-message that requires an acknowledgement
("ACK") message, then one ACK message should be generated by the
recipient of the message. Depending on the type and requirement of
each sub-message, an ACK message itself may contain one or more
sub-messages.
[0018] In accordance with one embodiment of the invention, the
general structure of a sub-message may take the form of: [0019]
SubMsgLen|SubMsgType|SubMsgPayload
[0020] The three sub-fields of the sub-message above may be further
described as follows below. It should be noted that where a number
of bytes is indicated as a length of a given sub-field this is
merely an exemplary length. Other lengths may be substituted
without changing the principles of the present invention. The
sub-fields are: [0021] "SubMsgLen": (2 bytes): This sub-field
indicates a length of the sub-message. [0022] "SubMsgType": (1
byte): This sub-field indicates a sub-message type. [0023]
"SubMsgPayload": This sub-field is for message specific data.
[0024] We now turn to a more detailed discussion of the state sync,
presence update, game playing, and common sub-messages mentioned
above.
[0025] In accordance with one embodiment of the present invention,
a state sync sub-message is used to synchronize the handset 200 and
agent 3, for example. This type of sub-message is usually sent
during a "power on" or initialization time period during which the
device 200, and in particular, the client 2/interface 2b, may be
enabled. Various information that is stored by the device 200
(and/or agent 3 if it is the agent that is being powered up) may be
updated or synchronized during this time period. One examples of
such information are: game list(s), buddy list(s), home screen
features, game screen features, and buddy screen features, to name
just a few examples.
[0026] As is known by those skilled in the art, the handset 200 and
agent 3 may lose synchronization with one another when, for
example, changes occur to either one of them. For example, when a
user changes the features of the device 200 the agent 3 may not
automatically detect these changes. Such changes may involve
adding/deleting a buddy to/from a buddy list or may be triggered
when a new game is downloaded. To insure the device 200 and agent 3
are once again synchronized, the device 200 may generate and
forward a message containing a sync state sub-message related to a
given type of information or change. On the agent 3 side, a sync
state sub-message may be generated and sent in order to refresh
icons or keys on a display, keypad or the like (not shown in FIG.
1) that is part of the device 200 with new information collected,
generated, analyzed or otherwise formatted by the agent 3.
[0027] The present invention provides for the generation of a
plurality of state sync sub-messages. In accordance with one
embodiment of the invention, at the beginning of a synchronization
process, the handset 200 may generate and send a "Sync Request"
sub-message to the agent 3, along with five checksums, each
checksum associated with a different type of state information.
[0028] In accordance with the present invention, the agent 3 may
associate a different checksum with: (a) a most recent version of a
particular type of information, and (b) a previous version of the
information. For example, upon receiving a "Sync Request"
sub-message from the handset 200, the agent 3 may be operable to
compare the received checksum in the sub-message with, for example,
two versions of a checksum previously stored. Thereafter, the agent
3 may be further operable to determine which, if any, information
is out of sync and which side (handset or agent) has the most
recent version of the information.
[0029] Once it has received a Sync Request, the agent 3 maybe
operable to generate and send a "Sync Response" sub-message back to
handset 200. If it happens that the agent 3 has the latest version
of a particular type of information, the latest state/version of
this information may be piggybacked (i.e., included in) as a part
of the "Sync Response" sub-message. If, however, the handset 200
has the latest version, then the handset 200 may be operable to
generate and send a "Sync Update" sub-message to the agent 3 after
receiving the "Sync Response" sub-message from the agent 3. Coming
full circle, the agent 3 may yet be further operable to generate
and send a "Sync Update Response" sub-message to the device 200 as
an acknowledgement of sorts. The following are examples of the
structure of some of the sync state sub-messages just discussed:
[0030] SYNC REQUEST: may comprise the following sub-fields (with
exemplary, recommended lengths noted in parentheses): [0031]
Message length [0032] Message type: SYNC [0033] Sync request
payload (Each entry is optional) [0034] Type of Sync (1 byte):
GameList [0035] Checksum (2 bytes) [0036] Type of Sync (1 byte):
BuddyList [0037] Checksum [0038] Type of Sync (1 byte): HomeScreen
[0039] Checksum [0040] Type of Sync (1 byte): GameScreen [0041]
Checksum [0042] Type of Sync (1 byte): BuddyScreen [0043]
Checksum
[0044] In accordance with an embodiment of the invention, all of
the checksums may have a length of 2 bytes by default, unless
otherwise indicated.
[0045] The next type of sync state sub-message is a Sync Response
sub-message: [0046] SYNC RESPONSE: may comprise the following
sub-fields (with exemplary, recommended lengths noted in
parentheses): [0047] Message length [0048] Message type:
SYNC-RESPONSE [0049] Sequence number of corresponding request
[0050] sync update payload [0051] Type of update (1 byte): GameList
[0052] Result (1 byte): 0: Ok (no sub-message, etc., follows) 1:
out of sync, handset version is more recent (no other sub-message,
etc., follows) 2: out of sync, agent version is more recent (hence
an update may follow) [0053] Number of games [0054] List of games:
(gameIndex, name (string: length, bytes), . . . ) [0055] Type of
update (1 byte): BuddyList [0056] Result (1 byte): 0: Ok (no
sub-message, etc., follows) 1: out of sync, handset version is more
recent (no other sub-message, etc.,follows) 2: out of sync, agent
version is more recent (an update may follow) [0057] Number of
buddies (for gaming only) [0058] List of buddies: (buddyIndex, NAI,
ScreenName, . . . ) [0059] Type of update (1 byte): HomeScreen
[0060] Result: (1 byte) 0: Ok (no sub-message, etc., follows) 1:
out of sync, handset version is more recent (no sub-message, etc.,
follow) 2: out of sync, UA version is more recent (hence an update
may follow) Number of icons on screen (1byte) List of icons:
{iconIndex, gameIndex, #buddies, (buddyIndex1, buddyIndex 2) . . .
,} [0061] Type of update (1 byte): GameScreen [0062] Result (1
byte): 0: Ok (no sub-message, etc., follows) 1: out of sync,
handset version is more recent (no sub-message, etc., follows) 2:
out of sync, agent version is more recent (hence an update may
follow) [0063] Number of icons on screen (1 byte) [0064] List of
icons: {iconIndex, gameIndex, #buddies, (buddyIndex1, buddyIndex2 .
. . )} [0065] Type of update (1 byte): BuddyScreen [0066] Result
(1byte): 0: Ok (no sub-message, etc., follows) 1: out of sync,
handset version is more recent (no sub-message, etc., follows) 2:
out of sync, agent version is more recent (hence an update may
follow) [0067] Number of icons on screen (1 byte) [0068] List of
buddy icons or names (each buddy may be shown as a row, along with
associated games): {rowIndex, buddyIndex, #games, (gameIndex1,
gameIndex2, . . . ) }
[0069] The next type of sync state sub-message is a Sync Update
sub-message: [0070] SYNC UPDATE: may comprise the following
sub-fields (with exemplary, recommended lengths noted in
parentheses): [0071] Message length [0072] Message type:
SYNC-UPDATE [0073] Sync update payload (same as a Sync Response
message)
[0074] The fourth type of sync state sub-message is a Sync Update
Response sub-message: [0075] SYNC UPDATE RESPONSE: may comprise the
following sub-fields (with exemplary, recommended lengths noted in
parentheses): [0076] Message length [0077] Message type:
SYNC-UPDATE-ACK [0078] Sequence number of corresponding update
[0079] Sync Update Confirm Payload: may be the same as the payload
of a Sync Request sub-message.
[0080] The final, exemplary type of sync state sub-message is an
Offline sub-message. This type of sub-message may be generated and
sent by a handset to an agent to indicate that the handset is going
offline. [0081] OFFLINE: may comprise the following sub-fields
(with exemplary, recommended lengths noted in parentheses): [0082]
Message length [0083] Message type: OFFLINE
[0084] The next type of sub-message is a "presence update"
sub-message. This type of sub-message may, for example, enable the
handset 200 to subscribe and/or unsubscribe to receive the presence
status (e.g. active/inactive) of other devices. A more detailed
explanation of the presence status of a device is given in
co-pending U.S. patent application No. ______, mentioned above.
[0085] In accordance with an embodiment of the present invention,
the handset 200 may receive updated presence status information
after first subscribing to receive this information by generating
and sending a "Subscribe" presence update sub-message to the agent
3. Alternatively, if the handset 200 generates an "Unsubscribe"
sub-message it will not receive presence update information.
Conversely, the agent 3 may forward the presence status of a buddy
to the handset 200 by generating and sending a "Notify", presence
status sub-message.
[0086] In a further embodiment of the invention, the handset 200
may also provide its own presence status (e.g., active/inactive) to
the agent 3 by generating and sending an "Availability Update",
presence update sub-message to the agent 3. This may be useful
when, for example, a user wishes to enter, or exit, an on-line game
or a group/lobby associated with such a game.
[0087] The following are examples of the structure, format and
content of the presence update sub-messages just mentioned. It
should be noted for the sake of completeness, that some of these
sub-messages may require an acknowledgement message. [0088]
SUBSCRIBE: may comprise the following sub-fields (with exemplary,
recommended lengths noted in parentheses): [0089] Message length
[0090] Message type: SUBSCRIBE [0091] AlertType (1 byte): Presence
[0092] Number of buddies (2bytes) [0093] BuddyIndex1, BuddyIndex2,
[0094] UNSUBSCRIBE: may comprise the following sub-fields (with
exemplary, recommended lengths noted in parentheses): [0095]
Message length [0096] Message type: UNSUBSCRIBE [0097] AlertType:
Presence [0098] Number of buddies [0099] BuddyIndex1, BuddyIndex2,
[0100] NOTIFY: may comprise the following sub-fields (with
exemplary, recommended lengths noted in parentheses): [0101]
Message length [0102] Message type: NOTIFY [0103] AlertType:
Presence [0104] UserID [0105] PresenceInfo ( using one or more
types of encoding) [0106] AVAILABILITY UPDATE: may comprise the
following sub-fields (with exemplary, recommended lengths noted in
parentheses): [0107] Message length [0108] Message Type:
AVAILABILITY [0109] ProfileID (1 byte): may include, for example,
the values: OME, WORK, INTRANSIT, INGAME, NA
[0110] The third type of sub-message is a game playing sub-message.
This type of sub-message may be generated and sent by the device
200 to the agent 3 to: (a) play a game with an anonymous player;
(b) invite a buddy(s) to play a game with the user of device 200;
or (c) accept an invitation to play a game with a buddy, to give
just a few examples.
[0111] The following are examples of the structure, format and
content of some specific game playing sub-messages provided by the
present invention. Again, it should be noted for the sake of
completeness that some of these sub-messages may require an
acknowledgement message. [0112] PlayWithBuddy: This sub-message may
be generated and sent by a handset to an agent to play a specified
game with a specified buddy. It may comprise the following
sub-fields (with exemplary, recommended lengths noted in
parentheses): [0113] Message length [0114] Message type:
PLAY-WITH-BUDDY [0115] GameIndex (2 bytes) [0116] List of buddies
to invite [0117] Number of buddies (2 bytes) [0118] BuddyIndex1,
BuddyIndex2, [0119] PlayGameWithAnyone: This sub-message may be
generated and sent by a handset to an agent to play a specified
game with any available player. It may comprise the following
sub-fields (with exemplary, recommended lengths noted in
parentheses): [0120] Message length [0121] Message type:
PLAY-WITH-ANY [0122] GameIndex [0123] Game Invite Alert: This
sub-message may be generated and sent by an agent to a handset/user
may comprise the following sub-fields (with exemplary, recommended
lengths noted in parentheses): [0124] Message length [0125] Message
type: GAME-INVITE-ALERT [0126] UserID of the inviting player [0127]
GameIndex [0128] Game Invite Reply: This sub-message may be
generated and sent by a handset to an agent. It may comprise the
following sub-fields (with exemplary, recommended lengths noted in
parentheses): [0129] Message length [0130] Message type:
GAME-INVITE-RESPONSE [0131] Sequence number of the corresponding
Game Invite Alert [0132] Response (1byte): 0: accept; 1: reject
[0133] Matching Status Report: This sub-message may be generated
and sent by an agent to a handset/user. It may comprise the
following sub-fields (with exemplary, recommended lengths noted in
parentheses): [0134] Message length [0135] Message type:
MATCHING-STATUS [0136] Number of currently matched players (1 byte)
[0137] Game Start: This sub-message may be generated and sent by an
agent to a handset/user. It may comprise the following sub-fields
(with exemplary, recommended lengths noted in parentheses): [0138]
Message length [0139] Message type: GAME-START [0140] Lobby ID (4
bytes) [0141] Game server address (4 bytes) [0142] Game session
ID
[0143] The last type of exemplary sub-message discussed herein is
so-called a common sub-message. One common sub-message is an
acknowledgement (ACK) sub-message. This type of sub-message may be
generated and sent by either a handset or agent. It is a generic
sub-message that may be used to confirm the receipt of a message or
sub-message. The second type of common sub-message is a "Keepalive"
sub-message. This is an optional sub-message that may be generated
and sent by a handset to an agent on a periodic basis, typically
during an "idle" time period (e.g., once every 5 minutes). This
type of sub-message enables an agent to receive and maintain the
presence status of a handset. It may not be necessary for the
handset to generate this type of sub-message if the handset's
presence status information is available from another source. The
following are examples of the structure, format and content of
acknowledgement and Keepalive sub-messages provided by the present
invention. [0144] ACK: may comprise the following sub-fields (with
exemplary, recommended lengths noted in parentheses): [0145]
Message length [0146] Message type: ACK [0147] Sequence number of
corresponding message being acknowledged [0148] Keepalive: may
comprise the following sub-fields (with exemplary, recommended
lengths noted in parentheses): [0149] Message length [0150] Message
type: KEEPALIVE
[0151] Up until now, the discussion has focused on those messages
that may be exchanged between a handset and an agent. However,
interfaces between the client 2 and game client 2a, between the
agent 3 and lobby 4, and between the lobby 4 and game server 5 are
also provided by the present invention.
[0152] The above discussion sets forth some examples of methods and
devices provided by the present invention for enabling the exchange
of messages between components of an always-on network. The true
scope of the present invention, however, is provided by the claims
that follow where it should be noted that the term "device" is
meant to include devices, like device 200 for example, and/or their
associated users.
* * * * *