US20130311581A1

US20130311581A1 - Transmission of command execution messages for providing a shared experience to both internal, at-venue participants, and external, networked participants

Info

Publication number: US20130311581A1
Application number: US13/895,282
Authority: US
Inventors: Andrew Milburn; Thomas Hajdu
Original assignee: Individual
Current assignee: Individual
Priority date: 2012-05-18
Filing date: 2013-05-15
Publication date: 2013-11-21
Also published as: US20130308051A1; US20130311566A1; US20130310083A1; US20140019520A1; US20130325928A1; US9246999B2; US20130308621A1; US9357005B2; US9143564B2; US9071628B2

Abstract

Command execution messages are transmitted to both internal, at-venue participants and external, networked participants. An event server sends messages to local, at-venue users. In order to avoid overloading the event server, transmissions to remote users are directed to a staging server that is not required to be at the venue. Cloud capability may be utilized. The event server may send a message to the staging server. The staging server will subsequently send the message to all registered remote participants. Incoming messages from remote participants are processed by the staging server to determine if the messages need to be sent to the event server. If so, compression and other techniques to reduce the size of messages relayed to the event server are used.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This patent application claims priority of Provisional Patent Application 61/648,593 filed May 18, 2012, Provisional Patent Application 61/670,754 filed Jul. 12, 2012, Provisional Patent Application 61/705,051 filed Sep. 24, 2012, Provisional Patent Application 61/771,629 filed Mar. 1, 2013, Provisional Patent Application 61/771,646 filed Mar. 1, 2013, Provisional Patent Application 61/771,690 filed Mar. 1, 2013, and Provisional Patent Application 61/771,704 filed Mar. 1, 2013, the disclosures of which are each incorporated by reference herein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention
The present subject matter relates to transmission of command execution messages to provide a shared experience to groups of users of portable interactive devices participating in an event which groups may each be within a venue or a remote location.
2. Related Art
A recently developed enhancement of the concert experience includes providing a performance and interacting with client devices of individuals in an audience. Concerts may be provided in venues having a capacity of thousands or tens of thousands of audience members. Significant communications and data processing resources must be committed to communicating with all audience members. Communication with audience members in a venue requires a communication link and control by at least a server. While very large handling capacities could be provided, such capacity would be prohibitively expensive to a concert presenter.
An enhanced concert experience may be provided by utilizing transmission of command execution messages. The prior art has had a limited range of functions in interacting with audience devices in a venue. For example, a server could transmit position information to a portable device. This sort of transmission has few constraints on it in that the information can simply be transmitted to a user device and does not have to be coordinated with any other information that is being transmitted. The prior art has had a very limited range of experience in providing more complex interactions.
In the context of an interactive system performing transmission of command execution messages, the prior art has not addressed communicating with a significant number of client devices that are remote to the venue in order to construct remote audiences as well as local audiences.
The prior art has not addressed providing complex interactions with a local, in-venue audience as well as a remote audience. Concert venues normally have restricted networked communications capacity. In other words, Internet bandwidth provided into and out of the venue may be limited. Therefore, it would be difficult to use one communications link to communicate with the in-venue audience and couple the same communication to the remote audience.
U.S. Pat. No. 7,796,162 discloses a method and system for transmitting and displaying venue-based synchronized camera views for live venue activities to remote views. A synchronized camera can include a main camera and at least one slave camera, wherein slave camera movement depends on movement by the main camera. Remote viewers can include hand held devices and digital entertainment monitors (e.g., HDTV). Remote viewers receive signals. However, no shared experiences produced for remote viewers comprising a separate audience, and the remote viewers do not share an experience with the in-venue viewers.
U.S. Pat. No. 6,731,940 discloses methods of using wireless geolocation to customize content and delivery of information to wireless communication devices which send signals to a central control system. The method uses an RF receiving site including antenna array and a mobile device operated by a user. At least one p-dimensional array vector is derived from RF signals sampled from p antennas of an array, where p is an integer. At least one p-dimensional array vector is used to derive a location of the mobile device. The device addresses a data source in order to customize information in correspondence with the location. The customized information is transmitted to a user. This system does not address communicating with a remote audience.
United States Published Patent Application No. 20110075612 discloses a system in which content is sent to a plurality of receiving access terminals (portable devices) within a venue boundary, i.e. venue cast. Content generated at an access terminal, is transmitted to a venue-cast server. A venue-specific network could be a wide area network (WAN) or a Wi-Fi hotspot deployment. The system provides “unscheduled ad hoc deliveries” of content via the venue transmission system to provide venue visitors with venue related information. Content is specific to the venue and is not related to groups of users within the venue. The only function provided is venue cast. This is an example of an environment in which the capability to communicate within a venue does not suggest communicating outside of the venue as well.

SUMMARY

Briefly stated, in accordance with the present subject matter, command execution messages are transmitted to both internal, at-venue participants and external, networked participants.
In order to avoid overloading an event server which sends messages to local, at-venue users, transmissions to remote users are directed to a staging server that is not required to be at the venue. Cloud capability may be utilized. The event server may send a message to the staging server. The staging server will subsequently send the message to all registered remote participants.
Incoming messages from remote participants are processed by the staging server to determine if the messages need to be sent to the event server. If so, compression and other techniques to reduce the size of messages relayed to the event server are used.

BRIEF DESCRIPTION OF THE DRAWINGS

The present subject matter may be further understood by reference to the following description taken in connection with the following drawings:

FIG. 1, consisting of FIGS. 1A and 1B, is an illustration of the method and apparatus of the present subject matter operating in a venue;

FIG. 2 is a block diagram of the system illustrated in FIG. 1;

FIG. 3 is a block diagram of a concert network controller with a communications module;

FIG. 4 is a partial detailed view of the block diagram of FIG. 2 in one preferred embodiment; and

FIG. 5 is chart illustrating signal transmission to enable to and from the staging server.

DETAILED DESCRIPTION

FIG. 1, consisting of FIGS. 1A and 1B, is an illustration of a venue 10 comprising a system 2 in accordance with the present subject matter. FIG. 2 is a high-level block diagram of communication paths in the system illustrated in FIG. 1. In accordance with the present subject matter, communications are efficiently directed among an in-venue audience, a remote audience, and the central concert control as seen, for example, in FIG. 1B.
FIGS. 1 and 2 are discussed at the same time. The system 2 may be used in conjunction with a live event, for example a concert. Two-way interactivity is provided between a central server 8 and individual audience members 4 who may each have a portable device 6. The portable device 6 may be a smartphone, tablet, or other device. The present subject matter addresses providing reliable, high-capacity interaction in a highly efficient manner. The present subject matter provides for both reaching substantially an entire audience physically and for efficiently managing communications by off-loading connections from a higher demand location to a lower demand location.
The venue 10 may include a stage 12, audience area 14, a control room 16, and a media system 18 which may be located in the control room 16. The media system 18 receives audio, video, and intelligence from other sources and may be operated to perform control room functions such as mixing, selecting, and processing. A video program 20 is shown on a display 22.
The media system 18 is used to couple outputs from a video source 26, a sound source 28, and other intelligence source 30. The video source 26 may comprise one or more television cameras 24. In the present illustration, an audio-video unit 34 includes the video source 26, sound source 28, and other intelligence source 30. The sound source 28 comprises audio output from a live performance provided by a performer or performers 40 coupled by transducers 42, such as microphones. Alternatively, one or more of the video source 26, the sound source 28, and other intelligence source 30 may comprise sources of streaming content, prerecorded content, stored data, or currently processed content from any source. These sources may be local, remote, or both.
In one preferred form the display 22 is a screen 50 that comprises a backdrop for the stage 12. The display 22 could comprise an array 52 of screens over which the video program 20 is distributed. In another form, often used in arenas, the display 22 could comprise a display unit 56 which includes a plurality of monitors 58 on one support 60, with each monitor 58 facing in a different direction. Examples of the display unit 56 are available under the trademark Jumbotron®.
The media system 18 is operated by a VJ 70. The VJ 70 may comprise one or more personnel or a programmed computer. It is not essential that the control room 18 be located at the venue 10. The media system 18 provides content to a concert network controller 100. The concert network controller 100 may both receive and transmit information. The concert network controller 100 provides an input to a display link 102, which is coupled by a patch panel 104 to the display unit 56.
The concert network controller 100 may also comprise a Wi-Fi hotspot 120 providing and receiving signals to and from the audience area 14. As further described below, content may be provided both to and from audience members 4. The concert network controller 100 may also interact with remote participants 140. In another form, a Wi-Fi system 124, discussed below with respect to FIG. 2, couples audience members 4 to interact with the system 2.
The concert network controller 100 is preferably wirelessly connected to an event server 130, which can provide communications between remote participants 140 and the concert network controller 100. The event server is coupled to a content editor 134, which interacts with a staging server 136. The content editor 134 may be placed in the The content editor 134 is a separate machine that may be chosen by a VJ 70 or other concert staff authorized to have creative control. The data provided from the content editor 134 is used to create content during the show and may use a mixture of participant provided content, pre-existing content and other content drawn from external. This processing is done in the main server 138 to reduce load on the event server 130. However, this function can be provided in the main server eight. The staging server 136 may be coupled to the remote participants 140 by a network, for example, the Internet 144.
Communications will be provided between a target system and a source system. In the present description, “source system” is a device that wishes to send a message to a “target system.” The target system is a device that is configured to receive sent messages via its operating-system provided from a network connection sub-system. The business logic running on the device can select as-needed to operate as the target or the source system at any moment. Operating as a source system or target system for a particular messaging transaction does not preclude operating as the other system for a different messaging transaction simultaneously.
The system is interactive between the concert network controller 100 and one or both of the remote participants 140 and local participants 4. The concert network controller 100 and one or both of the remote participants 140 and local participants 4 may be a source when another is a target. The target and source system roles can be assumed by each device within the present subject at different times and without requiring reconfiguration.
In a nominal application, thousands of portable user devices 6 may communicate with the concert network controller 100. The communication will provide interaction for intended uses of the system 2. This alone could strain resources and require expensive T1 access lines far beyond the capacity normally utilized within a concert venue. Providing such capacity would be both expensive and impractical.
Since users 4 have the option to operate their portable user devices 6 in order to access the Internet and to access cell phone services, bandwidth demands in prior art systems are potentially unlimited. This can overload capacities of communications links at venues. It is important to limit bandwidth requirements to enable accommodating a large number of portable user devices 6. In accordance with the present subject matter, limiting bandwidth requirements is accomplished by disabling access to applications that are not part of the entertainment functions of the system 2. For purposes of the present description, the applications, contributing to functioning of the system 2 are referred to as business logic.
Business logic comprises software for a number of functions. The system 2 may send video displays to the screens of portable user devices 6. In various forms of the present subject matter, the business logic may operate to individualize communications. Therefore, certain functions, such as retrieving user-specific data such as a Facebook profile are considered to be business logic.
The system has illustrated in FIG. 2 supports transmission of command execution messages to both external participants 140 and internal, in-venue participants 104. The at-venue participants utilize mono-cast IP and multi-cast UDP protocols to transmit messages over the captive Wi-Fi network which requires the deployment of a stand-alone Wi-Fi network suitably architected for the venue. Handling the potentially hundreds-of-thousands of remote users would not scale given the very limited bandwidth into the venue location. Often, a venue may be equipped with a consumer-grade DSL Internet connection. The large load due to such a large number of users would overpower capabilities of the event server 130. Instead, all messages destined for external participants are handled by the staging server 136. It is not required that the staging server 136 be resident at the venue 10 itself but is instead resident at an external service provider, for example, Rackspace or Amazon AWS. These services provide resources which are dynamically scaled to match a current level of external participant user-load.
FIG. 3 is a block diagram of a concert network controller 100 with a communications module 200 which is utilized to filter and regulate communications. The communications module 200 may be located in components other than the concert network controller 100. The illustration of the communications module in the concert network controller 100 is simply illustrative of possibilities, and is not limiting.
Optimization of bandwidth use, i.e., available bandwidth versus number of users that can be accommodated, is achieved by using a combination of a URL Internet filter, compression algorithms, a staging server, and rules created to limit message propagation not needed for producing the enhanced composite experience.
The communications module 200 includes a URL web filter 210. The URL web filter 210 is generally an integrated content filtering software application. One example of a URL web filter is the Barracuda Web Filter made by Barracuda Networks, Inc. in Campbell, Calif. The URL web filter 210 may be operated to block or permit access to URLs or selected applications at different times and for different reasons.
The URL web filter 210 may have its settings commanded by a data register 220. Programs, URLs, and other data that can be used in operating the URL web filter 210 are stored in a data register memory 230. The data register memory 230 contains data indicative of URLs which can be blocked or allowed. For purposes of the present description, URL may also include a particular page within a domain. A page is indicated by the form www.URL.com/page. The domain register memory 230 is addressed by a program register 240. The program register 240 selects a currently desired set of URLs to be allowed. The selections are mapped into memory locations within the data register memory 230. Outputs from the data register memory 230 are loaded into locations of the data register 220. The data register 220 provides settings to the URL web filter 210.
The selections made by the program register 240 in a preferred form, may be correlated with a mode of operation of the system 2. A program table 250 is loaded with sets of information corresponding to different concert functions. Each concert function defines a set of permissions for respective groups of URLs. A program interface 260 receives inputs, such as from the control system 16 or the program control system 8 (FIG. 1).
FIG. 4 is a partial detailed view of the block diagram of FIG. 2 in one preferred embodiment. Messages that are linked from the local audience 32 are load balanced between multiple instances of the event server 130. The multiple instances include database replication. The event server 130 is the transmission point for messaging coming from the concert controller 100. The concert controller 100 accepts commands from the main server 8 and client devices of the main server 8. The event server 130 forwards messages to the staging server 136. The event server 130 also receives commands from the remote participants 140 that are sent via the staging server 136. In one embodiment, a 5000 user load is accommodated. Since all requests are stateless, it is not necessary to provide sticky sessions.
The staging server 136 acts as an intermediary for messages to and from remote participants 140. It enables the concert controller 100 to send a single message destined for the many thousands of external participants without consuming the limited bandwidth capacity generally provided by venues. User generated content is stored on the staging server 136 before being requested by the content editor 134 or by the event server 130.
Messages for transmission to the remote participants 140 are coupled through the staging server 136. In this particular illustration, the staging server 136 comprises multiple instances with database replication in the Cloud. One example of a service providing the Cloud resource is Amazon AWS service.
Messages are also received from the remote audience 140. Messages can include personal data collected by an app and sent for processing by the main server 8. Messages to be directed to the event server 130 can be further processed, as by the content editor 134, via compression and/or consolidation into a single larger message or via a specially defined message that allows for partial or chunked transmission of this information.
FIG. 5 is chart illustrating a routine 300 for determining processing of signal transmission to enable communication between the event server 130 and the staging server 136. At block 302 a message is received from the remote audience 140 to the content editor 134. At block 304, the content editor 134 reads a current message, and selects message components indicative of message source, message destination, message serial number, message type, and message data. At block 306, the message is categorized as to whether it is the type of message to be sent to the event server 130. If so, at block 308 the message is marked for transmission to the event server 130. If not, at block 320 the message is directed locally. The message may be directed in any of a number of routes depending on its contents. For convenience in the current description, two routes are illustrated. If the message is a local registration message from a portable user device in the remote audience 140 of a participant who has arrived at the concert and is signing into the system, operation proceeds to block 322, and the user is registered for a session in the staging server 136. If the message is a content message such as an image or information about a user, operation proceeds to block 324 where the data is made available for review by a human or automated processor who may review the contents at block 326 and forward information to a selected location such as the main server 8 by the event server 130.
Offloading message handling capacity requirements from the event server 130 to the staging server 136 further reduces bandwidth requirements. Messages from external participants 140 can be pre-processed by the staging server 136 and evaluated according to a rule to determine if these messages are of the type to be sent to the event server 130. If so, then they can be further processed via compression and/or consolidation into a single larger message or via a specially defined message that allows for partial or chunked transmission of this information. Typically, however, externally delivered messages can be processed fully on the staging server 136 without need to contact the event server 130 at all.
Messages which typically do need to be forwarded to the event server 130 are the initial registration messages and video/stills created by external users. However, in this latter case, artifacts can be pulled down selectively by a human user based on thumbnails rather than an entire file in every instance.
This operation may be further facilitated by the use of chunked transmission of information.
If messages need to be forwarded to the event server 130, then they can be further processed via compression and/or consolidation into a single larger message or via a specially defined message that allows for partial or chunked transmission of this information. Permitted data is throttled to a low data rate so that it is acquired over time. It is unnecessary to gather the data in real time. When receipt of the requested data is completed, status is reported to the controller 100.
When sending messages to internal users, the event server 130 will send one additional message 400 to the staging server 136 specially structured so the staging server will subsequently send that message to all registered external participants. In this way a single message from the concert controller 100 can be broadcast to an arbitrary number of external users without placing any additional burden on the at-venue infrastructure.
Similarly, incoming messages from external participants 140 can be pre-processed by the staging server 136 to determine if indeed these messages must in fact be sent all the way to the event server. If so then they can be further processed via compression and/or consolidation into a single larger message or via a specially defined message that allows for partial or chunked transmission of this information. Chunked transfer encoding is a mechanism that allows HTTP messages to be split in several parts. This can be applied to both HTTP requests from client to server and HTTP responses from server to client. If a server is to send a response while lacking data as to a message's total length, simple chunked transfer-encoding will enable transmission. This encoding breaks the complete response into smaller chunks and sends them in series. Consequently, a download may be transmitted between the server and client one chunk at a time rather than in a single transmission. Since the operation of transmitting the information may be interrupted, real-time access to an entire message from the selected URL is not required. Therefore, bandwidth requirements are reduced. Once the end of the message is received, the destination target can communicate a completed status to the concert controller 100, for example.
While the foregoing written description of the subject matter enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The subject matter should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the subject matter as claimed.

Claims

1. A system for providing a shared experience to both internal at-venue participants and to external networked participants comprising:

an event server coupled to receive command execution messages are transmitted from a central server;

said event server creating messages for a local in-venue audience and being coupled to send messages to the local, at-venue users;

a staging server coupled for providing messages to external networked participants;

said event server creating and transmitting a message intended for the remote users; and

said staging server being coupled for receiving messages from the remote users and selectively transmitting messages to said event server.

2. A system according to claim 1 wherein said staging server further comprises a local processor program through read messages from remote users and apply a rule to select messages to forward to the event server.

3. A system according to claim 2 comprising wherein said staging server comprises a Cloud resource.

4. A system according to claim 3 further wherein the event server structures a message to provide a command for portable interactive devices of the local at-venue participants.

5. A system according to claim 4 comprising wherein the event server constructs a message including a command for portable interactive devices of the local at-venue participants to execute the command at substantially the same time.

6. A method for providing a shared experience to both internal at-venue participants and to external networked participants comprising:

receiving a command execution message at an event server from a central server;

creating messages for the internal at-venue participants and creating a message for external networked participants;

coupling messages to a communications link for transmission to portable interactive devices of internal act-venue participants;

coupling the a message for external networked participants to a staging server; and

creating messages for the external networked participants and communicating the messages via a separate communication.

7. A method according to claim 6 further comprising receiving messages at the staging server from the external network participants, analyzing messages, and selecting messages for forwarding to be event server in accordance with a rule.

8. A method according to claim 7 further comprising utilizing a cloud resource as the staging server.

9. The method according to claim 8 wherein the step of creating messages comprises constructing packets to selectively identify messages to be forwarded to internal and a venue participants and a message to be forwarded to the staging server.

10. A non-transitory machine-readable medium for execution on a digital processor, which when executed causes the processor to perform the steps of:

receiving a command execution message at an event server from a central server;

11. A non-transitory machine-readable medium according to claim 10 wherein the step of coupling the message to the staging server comprises sending the message via a network to a Cloud resource.

12. A non-transitory machine-readable medium according to claim 11 further comprising instructions to command the staging server to analyze messages from the external networked participants said to the staging server to select messages to be forwarded to the event server in accordance with a rule.