Methods and devices for exchanging messages in an always-on network

BRIEF DESCRIPTION OF THE DRAWINGS

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

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.

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.

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.

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.

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.

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.

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.

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:

- MsgLen|Ver|#SubMsgs|SrcID|DstID|SeqNo|Authentication|(SubMsgs)*
  
  where the asterisk indicates one or more submessages.

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.

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.

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.

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.

In accordance with one embodiment of the invention, the general structure of a sub-message may take the form of:

- SubMsgLen|SubMsgType|SubMsgPayload

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:

- “SubMsgLen”: (2 bytes): This sub-field indicates a length of the sub-message.
- “SubMsgType”: (1 byte): This sub-field indicates a sub-message type.
- “SubMsgPayload”: This sub-field is for message specific data.

We now turn to a more detailed discussion of the state sync, presence update, game playing, and common sub-messages mentioned above.

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.

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.

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.

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.

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:

- SYNC REQUEST: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: SYNC
  - Sync request payload (Each entry is optional)
    - Type of Sync (1 byte): GameList
      - Checksum (2 bytes)
    - Type of Sync (1 byte): BuddyList
      - Checksum
    - Type of Sync (1 byte): HomeScreen
      - Checksum
    - Type of Sync (1 byte): GameScreen
      - Checksum
    - Type of Sync (1 byte): BuddyScreen
      - Checksum

In accordance with an embodiment of the invention, all of the checksums may have a length of 2 bytes by default, unless otherwise indicated.

The next type of sync state sub-message is a Sync Response sub-message:

- SYNC RESPONSE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: SYNC-RESPONSE
  - Sequence number of corresponding request
  - sync update payload
    - Type of update (1 byte): GameList
      - 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)
      - Number of games
      - List of games:
      - (gameIndex, name (string: length, bytes), . . . )
    - Type of update (1 byte): BuddyList
      - 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)
      - Number of buddies (for gaming only)
      - List of buddies:
      - (buddyIndex, NAI, ScreenName, . . . )
    - Type of update (1 byte): HomeScreen
      - 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) . . . ,}
    - Type of update (1 byte): GameScreen
      - 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)
      - Number of icons on screen (1 byte)
      - List of icons:
      - {iconIndex, gameIndex, #buddies, (buddyIndex1, buddyIndex2 . . . )}
    - Type of update (1 byte): BuddyScreen
      - 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)
      - Number of icons on screen (1 byte)
      - List of buddy icons or names (each buddy may be shown as a row, along with associated games):
      - {rowIndex, buddyIndex, #games, (gameIndex1, gameIndex2, . . . ) }

The next type of sync state sub-message is a Sync Update sub-message:

- SYNC UPDATE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
- Message length
- Message type: SYNC-UPDATE
- Sync update payload (same as a Sync Response message)

The fourth type of sync state sub-message is a Sync Update Response sub-message:

- SYNC UPDATE RESPONSE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
- Message length
- Message type: SYNC-UPDATE-ACK
- Sequence number of corresponding update
- Sync Update Confirm Payload: may be the same as the payload of a Sync Request sub-message.

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.

- OFFLINE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
- Message length
- Message type: OFFLINE

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.

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.

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.

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.

- SUBSCRIBE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: SUBSCRIBE
  - AlertType (1 byte): Presence
    - Number of buddies (2bytes)
    - BuddyIndex1, BuddyIndex2,
- UNSUBSCRIBE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: UNSUBSCRIBE
  - AlertType: Presence
    - Number of buddies
    - BuddyIndex1, BuddyIndex2,
- NOTIFY: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: NOTIFY
  - AlertType: Presence
    - UserID
    - PresenceInfo ( using one or more types of encoding)
- AVAILABILITY UPDATE: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message Type: AVAILABILITY
  - ProfileID (1 byte): may include, for example, the values: OME, WORK, INTRANSIT, INGAME, NA

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.

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.

- 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):
  - Message length
  - Message type: PLAY-WITH-BUDDY
  - GameIndex (2 bytes)
  - List of buddies to invite
    - Number of buddies (2 bytes)
    - BuddyIndex1, BuddyIndex2,
- 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):
  - Message length
  - Message type: PLAY-WITH-ANY
  - GameIndex
- 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):
  - Message length
  - Message type: GAME-INVITE-ALERT
  - UserID of the inviting player
  - GameIndex
- 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):
  - Message length
  - Message type: GAME-INVITE-RESPONSE
  - Sequence number of the corresponding Game Invite Alert
  - Response (1byte): 0: accept; 1: reject
- 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):
  - Message length
  - Message type: MATCHING-STATUS
  - Number of currently matched players (1 byte)
- 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):
  - Message length
  - Message type: GAME-START
  - Lobby ID (4 bytes)
  - Game server address (4 bytes)
  - Game session ID

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.

- ACK: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: ACK
  - Sequence number of corresponding message being acknowledged
- Keepalive: may comprise the following sub-fields (with exemplary, recommended lengths noted in parentheses):
  - Message length
  - Message type: KEEPALIVE

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.

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.

Methods and devices for exchanging messages in an always-on network

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims

Parent Case Info