Event information tracking and communication tool

Abstract

A central server system is provided which communicates with a plurality of communication devices known as RTLS tags which are usually worn by participants of an event, the event being normally contained to a facility. The RTLS tags communicate with a network located in the vicinity of the facility to determine the position of the RTLS tags in real time. The network communicates with and transfers information to and from a RTIMS server. Information about identities of the participants, the location of the participants and geographical maps of display booths and exhibitor signage at the event are stored on the RTIMS server in a datastore connected thereto. The datastore may be queried to provide participants information relevant for navigation, lead capture, participant surveys and participant traffic flow. Participant locations may be correlated to entity locations or other participants by the RTIMS system to provide location oriented services.

Description

TECHNICAL FIELD OF THE INVENTION

This invention relates to a system and method for gathering information during an event, tracking and organizing event information including positional location of people and entities, creating a set of tools for allowing the people and entities to establish actionable relationships with other people and entities.

BACKGROUND OF THE INVENTION

Business and technical conferences and trade show events have become important means of developing meaningful and profitable business relationships. Such conferences and events may be classified under a larger umbrella of business activities including but not limited to meetings, incentives, conferences and exhibitions (MICE) events. MICE events can be quite large, drawing tens of thousands of attendees, exhibitors, sales people and organizers all of whom have an interest in maximizing their return on investment related to the event. The attendee, paying to attend, desires to find solutions to business or technical problems and is interested in meeting with as many vendors and other attendees or obtaining as much information as possible during the event that correlate to his or her desires. The exhibitor, paying for booth space and/or signage as well as investing in bringing a number of sales people to the event, desires to collect as many customers as possible through sales lead generation and through developing personal relationships. The exhibitor is interested in maximizing the time that his/her sales force spends in contact with sales leads and the development of new business relationships. The meeting organizer, investing in the MICE event infrastructure and marketing efforts, desires to attract as many attendees and exhibitors as possible on a year over year basis, and in so doing desires that new and meaningful event experiences are available to attract attendees and that the opportunities for relationship development are maximized so that the attendees and exhibitors have received value added services.

The creation of actionable experiences for the attendee and exhibitor are enhanced through efficient data collection and accurate measurement of activity at pre-event, during-event and post-event stages of the MICE event. It is essential, therefore, to have a reliable and efficient system for collecting event data at these different stages and particularly during the during-event stage to accurately record, measure and report event data. An example of a during-event data collection is to count the number of attendees per unit time showing interest in a particular product display at a particular exhibit booth.

The creation of actionable experiences for the attendee and exhibitor are enhanced through new means of communicating information to and from one another. In the case of the exhibitor to the attendee, there is a need to deliver product information which may be vast and complex and a need to present the best sales person matched to the attendee, both in a timely way to capture the opportunity; in the case of the attendee to the exhibitor, there is a need for a means for physically locating those exhibitors near attendees that have the best opportunity to solve those attendee's problems and there is a need for a means to communicate to those exhibitors the level of attendee interest in a range of products with expressed desire to gain more information and; in the case of attendee to attendee, there is a need for a means to exchange contact information and a means to physically locate each other efficiently in a large event hall where cell phone usage is often limited. It is optimal for MICE event situations, therefore, to have a reliable and effective means of communication between all entities.

The communication means and data collection means will optimally coordinate with physical location information to perform real-time event monitoring. The goal of the present invention is to combine traditional data collection and communication means with new physical location technology to create new types of experiences and new types of actionable data. It is one important goal of the present invention that the physical location technology is capable to pinpoint the position of an entity or person to an area consistent with that of a person's combined footprint or less, thereby enabling the data collection systems to place the entity or person in contact with one another. For example, a locating system should be capable of a person standing in front of a particular product display in a 50′×50′ booth area that contains a plurality of product displays. The locating system should also be able to resolve a difference between two or more persons standing in proximity to one another in real time.

There are means available in the art to measure positions of devices or entities as a function of time. Accepted standards, for example ISO/IEC 19762-5, now exist.

One class of available technologies for an RTLS system is active RFID (Radio frequency identification) and Active RFID-IR. Active RFID provides only presence information within a monitored area and requires an impractical amount of equipment to monitor the entire event space of a typical MICE event.

Another class of available technology for an RTLS system is optical or IR locating. While meeting the positional accuracy requirements of the present invention, line of site type positioning requires sophisticated tracking mechanisms for just one entity and would be overcome by the need to simultaneously monitor a moving set of several thousand entities.

Yet another class of available technologies for an RTLS system is ultrasound ranging and ultrasound identification (USID). However, the number of entities interacting would be limited in a given area due to bandwidth constraints related to reducing the noise between potentially interacting entities. Also the range distances and accuracy would be very limited.

Wireless LAN technologies, for example Wi-Fi with RSSI capability is a possible technology. But these technologies are limited in positional accuracy as is true of cell phone enabled GPS systems.

Di Floriano, International Patent Application WO 2006/013587, describes a system including a plurality of sensors in a targeted area accommodated by a plurality of people carrying RFID devices. Di Floriano lacks the means or necessary systems to precisely track location, having only the ability to ascertain if a person carrying an RFID device is inside the targeted area. The RFID device is not interactive, thereby limiting the carrier to use a cell phone to communicate desires to the system. Di Floriano does not describe a means of utilizing location information to project advertising or for determining actively controlled immersive media in the targeted area.

Werb in U.S. Patent Application 2003/0013146 discloses a real-time locating system (RTLS) using a hybrid tag device having a location position system (LPS) transmitter and a beacon transmitter comprising a baseline tag datagram.

Kovesdi, et al. in US Patent Application 2003/0155413 provides a description of a system and method for authoring and providing information relevant to a physical world. Kovesd, i et al., however, does not attempt to describe a system for dynamically binding a user to other relevant users with interest in communicating to the user prior to, during or after the playback event. Reacting to and creating a dynamic configuration of users and their profiles are not described.

Valentine, et al, US Patent Application 2008/0312946 propose location based services including real-time tracking and information management for trade show events. Valentine, et al. do not, however, indicate a system scope capable of enabling immersive media experiences such as lighting control or programmatic control of event media systems based on the presence of attendees and their profiles. Valentine, et al. do not describe a set of methods for determining the quality of location of a given attendee or of the system in general, for example, having the capability to map areas within the event facility that has poor ability to determine of location or having the capability to describe the probability of location based on motion vectors.

Valentine, et al. do not disclose a specific system or process for deploying location based services for trade show events, the deployment problem being significantly complicated by the need in the industry to set up an event with short notice between final configuration of exhibitors and show start—sometimes as short as one week. The system implementation aspects are a challenging problem because of the large amount of data being received by the RTLS system and the large amount of data generated by the event. The problem requires tools for rapid processing and manipulation.

Various embodiments will be described that address the need for real-time information management system for MICE events, alleviating the need for expensive database analysts and allowing for rapid turn around of post show data assets. Other embodiments describe methods for determining and utilizing a quality of location measure to greatly improve the reliability of real-time association of geospatial zones with RTLS tag devices. Immersive media experiences and location based control systems may also be integrated together to provide attendee and geospatial zone coordination.

SUMMARY OF INVENTION

The preferred embodiment utilizes an ultra wide band radio frequency (UWB RF) real-time location system (RTLS) system or other technology RTLS in combination with a real-time information management server (RTIMS), database servers, a web based portal application server and a web based dashboard application server together programmed to store, manipulate and control data at the direction of MICE event participants including attendees, exhibitors, sales staff and organizers.

The RTLS/RTIMS system continuously locates each participant through the use of an active RTLS tag which may be placed in the participants badge and verified during a registration process. The location system logs the participant locations in a database for real-time retrievable position and the creation of actions during and after the MICE event.

In one aspect the quality of location is assessed continuously and may be mapped to ascertain the positional accuracy of any participant. Additionally, the quality of location service may be utilized to ascertain the signal strength, coverage and overall health of the RTLS system.

Within the web based portal application, each attendee will be able to specify and control what contact information is provided to each exhibitor that is granted access to the attendee's contact information. Sales staff are provided access to the leads assigned to them by the exhibitor. The web portal access can include browsing, analyzing and exporting of the lead data.

In another aspect, exhibitors will be provided access to an exhibitor dashboard application in order to see live information concerning RTIMS activity related to them. This includes a map component that shows live positions and movements of attendees and sales staff in addition to reporting significant metrics.

The RTIMS of one embodiment can interact with CPUs connected to displays, lighting controls and other environmental devices in order to deliver immersive media experiences to Attendees.

Show organizers, session speakers and exhibitors can survey attendees in real time using the RTLS/RTIMS systems in order to collect more actionable data.

BRIEF DESCRIPTION OF DRAWINGS

The description will be aided by reference to the accompanying drawings, which are incorporated in the specification by reference, wherein:

FIG. 1 is a diagram depicting a typical MICE event situation including exhibitor booths and depicting movement and position location of the attendees and sales staff.

FIG. 2A shows an expanded view of a preferred embodiment cellular structure of the RTLS sensor system.

FIG. 2B shows an expanded view of the sensor configuration in a preferred embodiment cellular structure.

FIG. 3 is a block diagram of an attendee or sales staff wearing the RTLS tag and having a cell phone in a preferred embodiment.

FIG. 4 is a block diagram of the RTLS system of a preferred embodiment.

FIG. 5 is a block diagram of a preferred embodiment combination RTLS/RTIMS system functional arrangement.

FIG. 6 is a block diagram of a preferred embodiment RTIMS system network configuration showing the interactions between various entities involved in a MICE event.

FIG. 7 is a block diagram of the RTIMS portal application functions.

FIG. 8 is a block diagram of the relationships of MICE entities of the RTIMS database in relation to the portal application.

FIG. 9 is a block diagram of the relationships of attendee entities and event data entities of the RTIMS database in relation to the portal application of a preferred embodiment.

FIG. 10 shows a screen shot diagram view of the main screen of the dashboard application of a preferred embodiment.

FIG. 11 is a block diagram of the exemplary embodiment of a MICE event information system of a preferred embodiment.

FIG. 12 is a block diagram of a preferred embodiment software architecture of the RTIMS system.

FIG. 13 is a block diagram of a preferred embodiment software architecture of the reporting server.

FIG. 14 is a block diagram of a preferred internal structure including the entity relationships in the reporting server software.

FIG. 15 is a block diagram of the reporting system interactions in an exemplary embodiment.

FIG. 16A is a block diagram of the viewer application program of a preferred embodiment showing views and relational operations.

FIG. 16B is a use case diagram of the viewer application program of a preferred embodiment.

FIGS. 17A, 17B and 17C are screenshot diagrams showing the operations of the viewer application program of a preferred embodiment.

FIG. 18 is a flowchart diagram of a preferred process to determine and report quality of location in a preferred embodiment.

FIG. 19 is a flowchart diagram of a preferred method system setup process for the MICE event information system.

FIG. 20 is a flowchart diagram of a preferred method of RTIMS servicing of attendee requests for information in a preferred embodiment.

FIGS. 21A, 21B and 21C are flowchart diagrams of a preferred navigation program of the portal application of a preferred embodiment wherein the portal application is accessed prior to the MICE event, during the MICE event, and after the MICE event, respectively.

FIGS. 22A and 22B are flowchart diagrams of preferred attendee networking programs of the portal application of a preferred embodiment wherein the portal application is accessed prior to the MICE event

FIG. 23 is a flowchart diagram of a preferred attendee networking program to physically locate an attendee during the MICE event.

FIG. 24 is a block diagram showing the preferred functions of the exhibitor advertising portal application.

FIG. 25 is a flowchart diagram of a preferred lead capture program of a preferred embodiment.

FIG. 26 is a flowchart diagram depicting a preferred alerts messaging process implemented by the RTIMS for exhibitor use at a MICE event.

FIG. 27 is a flowchart diagram of a preferred embodiment organizer survey process implemented by the RTIMS of a preferred embodiment.

FIG. 28 is a perspective view of a badge, badge holder and RTLS tag suitable for use in a preferred embodiment.

FIG. 29 is a block diagram showing an example instantiation of the RTIMS system objects for a mood appliance application.

DETAILED DESCRIPTION

Various embodiments may be implemented in a variety of embodiments in differing event application environments incorporating hardware platforms suitable to the environment. Examples of event application environments are meetings, incentives, conferences and exhibitions hereafter referred to as MICE events. A purpose is to deliver and capture marketing information to and from attendees at a MICE event using a real-time locating system (RTLS) in combination with a hand-held tracking device and a set of communication tools.

The contextual MICE event is a conference exhibit event, of which a representative physical layout is shown in FIG. 1. The conference exhibit is enclosed in an exhibit hall 100 having at least one doorway 35 in the walls 36 leading to an exterior area 101. Various exhibits, marketing booths, common areas, and concession areas are established in the exhibit hall 100. For example, booth 1, booth 2, . . . , booth 16 form an array of marketing booth areas 18 in which products and marketing materials are presented to exhibit attendees (represented by black circles in the diagram). Each booth is typically occupied by at least one sales person (represented by white circles in the diagram). As an example, booth 2 has sales person 80 moving towards attendee 50. The movement of sales person 80 is indicated by velocity vector 81 and the movement of attendee 50 is indicated by velocity vector 51. In FIG. 1, sales persons and attendees are scattered about the exhibit hall each having their movements indicated by velocity vectors. If there is no velocity vector, then the sales person or attendee is stationary.

Booths may have internal structures. For example, booth 20 includes a first kiosk 21, a second kiosk 22, a first display area 23, a second display area 24, a third display area 25 and a fourth display area 26. The kiosks and display areas are marketing environments designed to attract attendee attention and may form known physical locations in which known product marketing materials are associated. Sales persons and attendees will naturally tend to interact at the known physical locations, especially where the attendee has specific interest in a product. A group of attendees and sales persons 52 are interacting at booth 11 indicating heightened interest in the product marketing materials in booth 11. The association of the location of attendees to the location of known product marketing materials and known sales persons is a key aspect of the present invention. The association process may be enhanced in various ways to create marketing value for the exhibitors; for example, in the preferred embodiment of the present invention, attendees may create a signal, such as signal 28 or signal 55 indicating specific interest in the product associated to the location of the attendee, these signals being processed by the system to allow for targeted follow up by exhibitors.

Exhibit hall 100 may have concession areas such as concession area 30 having associated sales persons 31, a line of attendees 70 and a set of tables 38 in which attendees and sales persons may congregate.

Authorized attendees and sales persons may move into and out of doorway 35 to access exterior area 101.

It is one objective to track the location and movement of the attendees and sales persons in real time, to associate the attendees and sales persons to a booth area or to a product marketing location within a booth area such as a kiosk or display area, to associate attendees and sales persons in proximity to one another, to collect information through a set of signaling mechanisms regarding interactions between attendees and sales persons in proximity and between attendees and exhibitor product marketing materials in proximity, and to create real time information for the event organizers.

An example is to contact the event organizer if the line of attendees 70 at concession area 30 becomes too long, thereby signaling that concession area needs additional sales persons 31 or other resources. Products and supplies in the concession area may be labeled with RFID tags detectable by RFID sensors networked into the RTLS system, so that the RTLS/RTIMS system may track concession inventory.

The embodiments are not limited to collecting real time location, movement and signaling from attendees, but also includes predictive elements. In one example an application is designed to alert a sales person that an attendee with known interest or with known affinity to the sales person's product is physically approaching his/her booth area. In another example, a real time map may be displayed on a hand held device (e.g. cell phone) carried by an attendee so as to guide them to the booths of a specific predefined list of exhibitors. An alternate application may guide the attendee in real-time to booths having products with predefined attributes.

A set of cell areas 90 are superimposed on the exhibit hall 100 and are further explained with the aid of FIGS. 2A and 2B. Cell areas 90 are defined by a set of sensor nodes 91. Each sensor node in the set of sensor nodes 91 contains a plurality of sensors capable of sensing information transmitted from pulsed signal sources and the directionality of pulsed signals generated from the pulsed signal sources. In the preferred embodiment, ultra wide band (UWB) radio frequency (RF) pulses are utilized for the pulsed signals. Other embodiments may use different types of signals such as ultrasound or RF signals such as those used by cellular networks. The sensors are capable of detecting the angle of arrival (AoA) of UWB RF pulses generated from a plurality of UWB pulsed sources.

In FIGS. 2A and 2B, a pulsed source 95 emits UWB RF pulses which are detected by sensor node 97 among other sensor nodes. Sensor node 97 contains an array of sensors: sensor 92A, sensor 92B and sensor 92C. Other sensor nodes are configured in a similar manner to sensor node 97, the other nodes positioned in varying proximity and direction from pulsed source 95. Sensor 92B is capable of measuring the angle of arrival, AoA 96, of the signal from pulsed source 95. Similarly, other sensor nodes may measure their corresponding angles of arrival of the signal from pulsed source 95.

In the preferred embodiment, the sensors contained in the set of sensor nodes 91 are connected together in a network having a central timing element 98 that synchronizes each sensor to one another. The sensors, being synchronized, are capable of detecting pulses and measuring time difference of arrival (TDoA) of pulses across the network of sensors. A central processor 99 may be connected to the network of sensors to collect data from each sensor for processing AoA and TDoA. Central processor 99 is programmed to tri-angulate (more generally poly-angulate) detected positions of pulsed sources, such as pulsed source 95, based on the collected AoA from each sensor in the network of sensors. Central processor 99 may also be programmed to utilize the TDoA data to compute velocity vectors and to compute quality of detected positions. The combination of central processor 99, central timing element 98, set of sensor nodes 91 and a plurality of pulsed sources similar to pulsed source 95 will be hereafter referred to as a real time location system (RTLS system). The pulsed sources will be hereafter referred to as RTLS tags which generate a continuous stream of UWB RF pulses for ranging. The RTLS tag devices in combination with a separate wireless network are capable of encoding information bits that may pass between the RTLS tags and the RTLS system. The information bits are useful to identify RTLS tags one from another and to transmit real time information generated, for example, by human interfaces to the RTLS tags.

A suitable RTLS system for the preferred embodiment is the Series 7000 RTLS platform from Ubisense Ltd which uses UWB RF pulsed sources and sensors capable of sustaining a continuous 160 Hz update rate, so that a RTLS tag location can be provided every 6.25 ms from each sensor and cell area. The Ubisense system utilizes a 2.4 GHz ISM band wireless network to accomplish communications between the RTLS tags and the system.

While the sensor nodes may be configured in an infinite number of geometrical configurations, the preferred embodiment is to place the sensor nodes such as to form hexagonal shaped cells as in FIG. 2A, with three sensors per node as in FIG. 2B. The typical physical size of sensor cells are approximately 90 feet in diameter and the typical positional resolution of the Ubisense based RTLS is 15 cm in three dimensions. RTLS systems are by their nature cellular. Cell shape and sensor layout is subject to numerous constraints and rules of thumb. In the RTIMS context, a preferred embodiment optimal layout technique is a hexagonal cell design. This design helps eliminate both the presence of deadspots and the efficiency of cell-to-cell hand-off for positional and velocity determination near cell borders.

An attendee at a MICE event typically carries a personal cell phone. An RTLS tag is assigned and distributed to this attendee either before the event begins or on-site. Referring to FIG. 3, the attendee 200 carries a RTLS tag 205 and may carry cellular phone 202 with them for the duration of the event.

The RTLS tag 205 is attached to a lanyard or more commonly is contained in a badge holder 204 as shown in FIG. 3 and in perspective in FIG. 28 as in use. In the preferred embodiment, the RTLS tag 205 has features for user interactivity with the RTLS system. A first button 211, a second button 212, a sound generator 213 and at least one LED 214 are integrated into the RTLS tag 205, the buttons allow the attendee to signal the RTLS system, the sound generator 213 and LEDS allowing the RTLS system to signal the attendee. The RTLS tag 205 may also include an integrated motion detector capable of measuring the acceleration of the tag and capable to report changes in motion to the RTLS system. The same functionality RTLS tags may be used for sales staff and other personnel on-site for positional tracking and communication.

RTLS tag 205 is automatically tracked during the MICE event by a network of sensors in the RTLS system as further described in FIG. 4 with reference to FIG. 2A. In FIG. 4, the network of sensors 222 sense RF pulse data from the set of RTLS tags 220 attached to attendees and sales persons registered for the MICE event. The sensors all communicate with an RTLS control system 225 which correlates the tag position and movement information into a continuously updated 3-D model 230 of all RTLS tag positions in the MICE event's physical space (e.g. exhibit hall of FIG. 1). The network of sensors 222 may be either temporarily installed into the MICE event facility for the duration of the event or permanently installed and used for multiple events as they occur in the event facility. The RTLS control system 225 is preferably physically located at the event facility and interconnected to the network of sensors 222 via routed local Ethernet connections between the RTLS control system 225 and individual sensors, the local Ethernet connections typically transporting TCP/IP protocol signals between the RTLS entities. The Ethernet connections may be wired or wireless connections to the network. In the preferred embodiment wired connections are preferred wherein the sensors are powered by power over Ethernet (PoE) cabled connections.

The continuously updated 3-D model 230 of FIG. 4 and of FIG. 5 can be queried by the RTLS control system 225. In FIG. 5, a real-time interactive marketing system (RTIMS) 250 is connected to the RTLS control system 225 allowing for communications and data transfer between them. The RTIMS 250 queries the RTLS control system 225 for positional data in 3D model 230, storing the returned positional data in an internal RTIMS database 240 along with other relevant data stored previously (such as the serial number of the RTLS tag assigned to the attendee, the attendee's cellular phone number and historical positional information previously supplied by the RTLS control system) to generate attendee experiences and to record experience outcomes. Examples of attendee experiences will be given below. RTIMS 250 may be operated as an application in an on-site or off-site server, however, the preferred embodiment has the RTIMS 250 physically located on-site at the event facility and interconnected to the RTLS control system via the local Ethernet network.

In order to generate experiences for attendees, RTIMS 250 is also interconnected to several networks and serves applications connected thereto. FIG. 6 is a schematic diagram of applications that may be driven by the RTIMS 250. In addition to the local area network 265, the RTIMS 250 may be connected to the internet 270 and to a cellular network 260. The cellular network 260 is used by RTIMS 250 to communicate with attendee 200 via their cellular phone 202, for example, with SMS/MMS messages or through smart phone web browsing functions. RTIMS 250 and attendee 200 are enabled to send unsolicited messages to each other in real-time.

During the MICE event, RTIMS 250 communicates over internet 270 connections to a portal application 272. RTIMS 250 is capable to transfer information collected at and prior to the event, to and from portal application 272 to aid in establishing interactions between and experiences for attendees 200, exhibitors (not shown), sales staff 210 and show organizers 215 of the MICE event.

Before, during and after a MICE event, a set of authenticated users 201 are able to access portal application 272 from a web browser 274 connected to internet 270 for the purposes of configuring and viewing information concerning their experiences and interactions at the event. The set of authenticated users 201 can also all communicate via internet 270 connections or local area network 265 connections to a web-browser based dashboard application 275 that is served from RTIMS 250. Authenticated users 201 are typically the registered attendees, sales staff, exhibitors and organizers but may include other persons or entities having interest in the event.

Portal application 272 is a web application containing programs with at least the functionality to setup, access and manage information related to the MICE event as shown in FIG. 7. Functionality that would be provided to attendees via portal application 272 includes at least a first program 301 providing for the attendee to make and receive exhibitor information requests, a second program 302 providing for the attendee to connect with another attendee, a third program 303 providing for the attendee to plan his/her trip to the event to help the attendee gain maximal information and meet conference objectives, and a fourth program 304 providing for reporting of vital event information back to the attendee.

Per each MICE event, the RTIMS database 240 contains information relationally organized as shown in FIG. 8. The show organizer 314 has multiple exhibitors 310 attending their event. Each exhibitor has multiple sales staff 312 attending the event, and all of the show organizers 314, exhibitors 310 and sales staff 312 interact with all of attendees 300.

Between events, RTIMS database 240 contains information relationally organized as shown in FIG. 9. Each attendee 315A has relationships to data in multiple events 320 and each attendee 315A can create or accept relational connections between other attendees 315B attending the MICE event.

During the event, attendees, exhibitors, sales staff and show organizers have access to dashboard application 275 which is shown in FIG. 10. Dashboard application 275 provides access to a map component 285, a display area 280 for graphical and textual data and has controls 281 for accessing and controlling RTIMS database information through search functions 282 and list functions 283. Information gathered via controls 281 is displayed using map component 285 or display area 280 or both. The amount and type of data that is available will vary based on the type of person accessing dashboard application 275 and the type of data requested. As an example, an exhibitor may access the dashboard and use its controls to search for attendees from an organization. The search may reveal a graphical display of the attendee locations at the event facility. The search may also reveal a list of attendees meeting the search criteria.

FIG. 11 is a block diagram showing the architecture of an exemplary embodiment MICE event information system 350 comprising the real-time interactive marketing system, RTIMS 250, a reporting system 251, the real-time location system, RTLS system 225, a dashboard system 351 which operates dashboard application 275, a portal application system 352 which operates portal application 272, a viewer application system 354, a real-time recorder system 355, a first set of database files 358 and a second set of database files 359.

RTIMS 250 is a real-time, multi-processing, asynchronous control system for managing information going to and from the RTLS system 225, storing and retrieving data about all persons interacting with the system, and coordinating actions between the RTIMS server and client systems including dashboard application system 351, portal application system 352 and a set of controllable devices 345. MICE event information system 350 may comprise multiple server hardware platforms operating in tandem to address multiple processes, applications and user components. MICE event information system 350 has external interfaces to at least the set of external systems 361, a local area network 367 at the event facility and a wide area network 368 which may be the internet. Dashboard system 351 is connected to RTIMS 250 via local area network 367. Portal application system 352 is connected to RTIMS 250 via wide area network 368 and may exist off-site of the event facility. Both the dashboard and portal systems may be accessed by a set of web browsers 366 connected via the internet.

RTIMS 250 is internally architected as multiple processes in a multitasking operating system such as Unix, operating on a modern server hardware platform including at least one processor, having random access memory and having a set of local storage drives.

Referring briefly to FIG. 12, RTIMS 250 operates RTIMS main process 372 as an asynchronous, event-driven application. It uses off-the-shelf event application libraries to manage all system activities as events and responses to them. In the exemplary embodiment, RTIMS main process 372 implements a software design that enables the representation of complex system behavior with a simple set of objects. RTIMS main process interacts with an object oriented RTIMS database 240 which utilizes internal database components with an API 373 for storing and retrieving arbitrary data structures. The RTIMS main process 372 is responsible for coordinating all RTIMS related behavior in real-time. It is capable of decomposing its behavior into multiple processes in order to take advantage of multiprocessing hardware. This decomposition is enabled by using an inter-process communication protocol IPC 375 between the main process and a set of sub-processes 374. RTIMS 250 interacts with RTLS system 225 which has a documented RTLS API 371 for receiving real-time notices of RTLS events such as RTLS tag sighting and containment events when an RTLS tag is identified within a specific region of the three dimensional space.

In one aspect of the RTIMS system, all operations between processes and subprocesses are asynchronous and non-blocking. The non-blocking aspect alleviates the need to use threads to achieve multiprocessing behaviors within a process which simplifies the software development.

Objects are containers for methods and attributes inherited from object classes and programmed according to standard object oriented programming rules known by those skilled in the art. The invention meets real-time performance and ease of operational set-up by utilizing object oriented internal data structures which are dynamic in nature and are treated like database objects. Object-oriented database management systems (OODBM) suitable for use in the present invention is a known class of databases available as off-the-shelf software components

In an alternate embodiment, RTIMS database 240 may be constructed with an off-the shelf SQL database server with a documented API, although performance and ease of deployment are likely to be deficient compared to the exemplary embodiment.

Referring again to FIG. 11, the processes and fundamental object classes of RTIMS 250 are indicated. RTIMS has controller 380 for creating and managing objects during real-time operation. The relevant object classes for the managed objects are appliances 383, persons 385 and drivers 386. RTLS driver 389 and zone drivers 388 are subclasses of the drivers 386 which are fundamental to the operation of the RTIMS system.

The data structures associated to the objects may be imported from a first set of database files 358 and exported to a second set of database files 359. The second set of database files 359 are considered to be data models capturing the behaviors of attendees, exhibitors, sales staff and organizers prior to and during an event. In the exemplary embodiment both sets of database files are realized as tables written to standard CSV files which are stored on the RTIMS system's local storage drives and which may be written to computer readable media for transmission to other systems. Exporter process 382 is a sub-process for exporting data structures into second set of database files 359. Examples of exported data structures are guests in guests.csv which are instantiations of persons 385 and zone activity encapsulated therein.

In an alternate embodiment, CSV files may be imported from remote sources over the internet to establish an RTIMS appliance such as an exhibitor display system. The exhibitor display system may be associated to a proximate attendee, the attendee having attributes that allow information to be gathered in real-time from a remote internet resource. The information is gathered and presented to the display system via the RTIMS system in the form of targeted information such as an advertisement, or a targeted survey.

Continuing with FIG. 11, persons 385 are object representations of a real-world person (e.g. an attendee) that is known by the RTIMS, for example, through a registration process wherein the subset of the real-world person's information is stored prior to the event in first set of database files 358. Appliances 383 are objects that represent high-level system behaviors of physical world devices and systems embodied in the RTIMS server. Examples of these appliance behaviors are: digital signage content personalization, lighting control/behavior, attendee registration and dashboard content management. Drivers 386 are objects that represent lower-level system behaviors that may be embodied within the RTIMS server or within the set of controllable devices 345. If the behavior is external, then a subset of drivers 386 implements an interface between an appliance and that external behavior. General examples of controllable devices having drivers are: client hardware stations such as a registration station executing an attendee registration, digital signage displaying real-time changes in messaging, DMX lighting systems executing changes in exhibit hall lighting, sound systems producing announcements and music, and web cameras streaming video and audio marketing productions. RTLS driver 389 is a specific driver object for interfacing to the RTLS system to collect attendee and sales staff positional data.

Zone drivers 388 is a specific set of zone driver objects, for holding geospatial coordinates and containment information related to geospatial areas called zones. Zones may be static or dynamic. Each person (holding an RTLS tag device) has a dynamic zone associated to them. An exhibitor booth is an example of a static zone. Zone drivers 388 act upon changes to static zone containment data, and report dynamic zone crossings.

Positional tracking of a set of persons is accomplished as follows. A zone driver object is associated 1:1 to a static zone predefined in the RTLS system for the facility. A person object is associated 1:1 to a dynamic zone assigned to a RTLS tag device worn by one person in the set of persons. A given zone driver object captures and records in its data structure a list of person objects that are currently contained within the given zone driver object's geospatial area. A person object captures and records in its data structure a perpetual list over time of static zones that the associated person has entered including the current static zone where the person is located. The person object also captures and records in its data structure a perpetual list over time of other dynamic zones that have enters the associated person's dynamic zone over time. Predefined parameters may be used by the person objects for defining when a zone entrance occurs including the physical dimension of the dynamic zones and the minimum zone overlap time.

Reporting system 251 of FIG. 11 is a back office system programmed to provide reporting services based on data gathered during a MICE event by RTIMS 250. Reporting system 251 draws data from second set of database files 359 into reporting datastore 396 for internal processing. Portal application system 352, viewer application system 354, and external systems 361 may exchange data with reporting system 251. External systems 361 may connect customer relationship management systems (CRM) 362 to reporting system 251 for organizing sales, marketing and other data pertinent to exhibitors, show organizers and customers of data generated during a MICE event.

Reporting system 251 is further explained with the help of FIGS. 13, 14 and 15. In FIG. 13, reporting system 251 comprises a reporting main process 390, a reporting data store 396 and a set of reporting sub-processes 391. Reporting system 251 is internally architected as multiple processes in a multitasking operating system such as Unix operating on a modern server hardware platform including at least one processor, having random access memory and having a set of local storage drives.

Reporting system 251 may comprise multiple server hardware platforms operating in tandem to address multiple processes, applications or users. The reporting data store 396 has functionality similar to the database functionality of the RTIMS system utilizing internal object oriented methods and procedures, defined in API 394, to manipulate tables of data imported from second set of database files 359.

In an alternate embodiment, reporting data store 396 may be an off-the-shelf database server with a documented API for storing and retrieving arbitrary data.

The reporting main process 390 is responsible for coordinating all reporting related behavior. It can decompose its behavior into multiple processes in order to take advantage of multiprocessing hardware, for example, to service multiple simultaneous queries from external systems. This decomposition is enabled by using an inter-process communication protocol, IPC 393, between the reporting main process 390 and the reporting sub-processes 391.

In FIG. 14, the processes and fundamental object classes of reporting system 251 are indicated. Reporting system 251 has controller process 408 for creating and managing objects during operation. The relevant object classes for the managed objects are shows 401, organizations 404, persons 405 and components 402. Shows 401 are constructed from the imported sets of database files (CSV files) via reporting data store 396 and contain information related to multiple MICE events. Components 402 are aspects of given MICE events, for example, the RTLS system configurations for the given MICE events. Organizations 404 may be show organizers, exhibitors and advertisers involved in the plurality of shows 401. The reporting system allows for a plurality of organizations per show and a plurality of shows per organization. Persons 405 are objects representative of people associated to organizations 404.

In FIG. 15, reporting system 251 has functional capability to perform tasks prior to and after the MICE event including obtaining data 410 from the event RTIMS system; generating reports 411, which may be electronic reports or hardcopy reports; collecting feedback 412 from participants; establishing event datasets 413 prior to the event; establishing asset definitions 414 prior to the event which are sets of relational operations for organizing data from the event; utilizing report templates 415 which are document templates, slide presentation templates and similar file templates previously created to generate desired forms for reports; communicating with CRM software 416 in external systems; and interacting with a deployed portal 417 for a given MICE event. The controller process of reporting system 251 processes a report by importing and operating on required event datasets using the set of relational operations in an asset definition then merging the resulting dataset from the relational operations with one or more report templates.

In relation to reporting system 251, portal applications are represented by two concrete and separate functions: a reporting function and user facing function. The reporting function of the portal application interfaces to reporting system 251 for the back office automation of the following tasks:

• a. collection and storage of data generated by user facing function,
• b. processing and report generation on the data in reporting data store 396,
• c. distribution of data to and from external systems and people, and
• d. collection of feedback from recipients of distributed data.

The user facing function is a standard web application, such as a user home page, that can communicate with the RTIMS and with the reporting system to provide authenticated user facing functions such as the attendee functions of FIG. 7.

Referring back to FIG. 11 once again, real-time recorder system 355 is a process in a multitasking operating system such as Unix, operating on a modern server hardware platform including at least one processor, having random access memory and having at least one local storage drive in which recorder data store 356 is organized to contain the collected RTLS tag locations.

RTLS system 225 streams RTLS tag device location coordinates to the RTIMS 250 and to the real-time recorder system 355 as the sensor network senses RTLS tag devices. In the exemplary embodiment, the RTIMS 250, via RTLS driver 389, filters the streamed location coordinates to identify zone crossings only. Real-time recorder system 355 interfaces to RTLS system 225 and is programmed to collect all streamed RTLS tag locations continuously as they are sensed and identified by RTLS system 225. For example, an RTLS tag may be configured to send out a UWB RF pulse for position location in predefined time slot at a frequency of 1.0 seconds. In the preferred embodiment RTLS system, predefined time slots are organized by a master sensor in the set of sensors making up each cell sensor area and are spaced apart by 6.25 ms in a 160 Hz sampling system.

In one aspect, real-time recorder system 355 may operate a post-show motion picture application wherein the location coordinates of the set of RTLS tag devices, as contained in recorder data store 356, are plotted on a map of the event facility as a function time. A snapshot of recorder data store 356 may be copied to a snapshot file, allowing the motion picture application to operate during the show using the snapshot data. The motion picture application may plot positions and attributes of persons carrying the RTLS tags using symbols and colors to plot unique locations of attendees, sales persons, or sets of persons with similar attributes, the colors and symbols identifying person's attributes. The motion picture application is useful to determine, for example, the movement of sales people of a particular exhibitor during a time period or in a security application, the movement of a person suspected of wrongful behavior at a particular location and time.

In another aspect of the present embodiment, Real-time recorder system 355 is capable of maintaining a location cache 357 for holding the last reported location for each RTLS tag device. Location cache 357 may then be accessed at any time by the RTIMS system to render event maps avoiding the need to poll the RTLS system for current locations. The location cache access method is much more efficient than polling and reloading the data over a network.

Viewer application system 354 of FIG. 11 contains a viewer application program that'is used to manipulate CSV files, most importantly the set of database files 359 but not limited thereto. The viewer application program is (1) a quick and efficient tool for the mining of data from several sources to create actionable information assets; and (2) a means to rapidly create reporting templates for reporting system 251. The viewer application system treats data as self-describing tables rather than requiring a process of pre-defining SQL table schema and then importing data into the SQL table schema.

The viewer application program is explained with the help of FIGS. 16A, 16B, 17A, 7B and 17C. Beginning with the example of FIG. 16A, viewer application program 800 is a desktop computer application programmed to include functionality to allow a user to open one or more CSV files into one or more corresponding table views. Viewer application program 800 is also programmed with a predefined set of relational operations which may operate on the one or more corresponding table views to create new set of table views. The created table views may be saved in local storage devices as new CSV files. The set of relational operations used to create the new set of table views may be recorded as an executable macro and saved.

In operation, the example of FIG. 16A shows that a first table view 801 is opened and a first relational operation 805 is performed to generate a second table view 802. A second relational operation 806 operates on second table view 802 to create a third table view 803. A third relational operation 807 operates on the second table view 802 to create a fourth table view 804. Relational operations are similar to SQL relational operations such as SELECT, JOIN, and PROJECT. The example of FIG. 16A, while a very simple example, illustrates a programming environment wherein a user may interact with any set of CSV files regardless of their content, source or original purpose, i.e. the CSV files may have been built by scanning a website, creating tabular data from a user generated program or similar process and may not necessarily have been created as a part of the RTIMS system or exported from a pre-existing database system. Viewer application program 800 allows for data manipulation in a way that is similar to standard database functionality without requiring the overhead of a database analyst to work under database system constraints and without requiring that the data was properly loaded into a database system.

FIG. 16B shows a use case of viewer application program 800 wherein a report analyst 810 interacts with the viewer application program 800 to create informational assets from distinct MICE events, event A and event B. Event A relational model 814 is built by an RTIMS system and saved in CSV files as Event A dataset 812. At a later time and for a different event, Event B relational model 815 is built by an RTIMS system and saved in CSV files as Event B dataset 813. Event B, for example, may occur a year after Event A. Viewer application program 800 is utilized to manipulate data from Event A dataset 812 by interactively performing a set of relational operations on the Event A table view and table views generated by one or more of the relational operations. The set of relational operations are recorded in asset definition 816 which as may be stored as a recorded macro that is executable and capable of begin replayed to recreate the set of relational operations. The output table views after applying the relational operations are stored in Event A informational asset 811 as one or more CSV files. Asset definition 816 is then used to operate on Event B dataset 813 to create a new Event B informational asset 817 without requiring report analyst intervention.

Macros such as asset definition 816 may be merged with report templates in the reporting system to organize data into reports including data from a plurality of events having a plurality of CSV files. Thus, the viewing application program may be used to create client report templates specifically customized for the client that may be run automatically, rapidly and repeatedly by the reporting system as required by the client's CRM or similar systems.

FIGS. 17A, 17B and 17C show screenshot type graphical views of viewer application program 800. Beginning with FIG. 17A, viewer application program 800 has the capability to present a view workspace window 820 and a view navigator window 821. In FIG. 17B, a requested view, “view a” is opened by interaction with view navigator window 821. Viewer application program 800 is programmed to respond to the requested “view a”, by opening a CSV file associated to “view a” and displaying a table view 822 of “view a” organized into columns 823 and rows 824.

FIG. 17C shows three screenshot views of the viewer application program while responding to requests for relational operations. Viewer application program 800 is programmed to present a pull-down list 833 of possible relational operations from which one relational operation may be selected to operate on “view a” 832 which was previously selected in the view navigator window. Viewer application program 800 is programmed to respond to the relational operation selection, first by opening a confirmation dialog 834 and then, based on approval in the confirmation dialog, performing the relational operation on “view a” 832 selection to create a new view, “view b” 835. Viewer application program is programmed to make “view b” 835 available for further operation through the viewer navigation window.

FIG. 29 shows a block diagram of an example event situation showing the set of objects and their interactions in the RTIMS system for the example situation. An RTIMS system 420 is shown with specific instances of objects at the time of the example event. An instance of a person 422 and a particular appliance, mood appliance 421, are defined prior to a locating event in the RTIMS system. The locating event is derived in zone driver 423 having received a zone report from RTLS driver 424 that the person associated to person 422 has just entered the zone associated to zone driver 423 zone and is contained within the associated zone, the RTLS driver 424 having obtained the locating event from the RTLS system 429. In the example of FIG. 29, the zone associated to mood appliance 421 has similar coordinates as the zone associated to person 422, so zone driver 423 captures the fact that mood appliance zone contains person 422 zone and sends a message to mood appliance 421 that person 422 has entered its zone. Mood appliance 421 then queries person 422 for an attribute such as the color preference attribute. Mood appliance 421 then sends a message to DMX driver 425, which controls the settings for lighting in the facility, to adjust the color of lights associated to the location mood appliance 421 to the preferred color of person 422. DMX driver 425 receives the command, processes it, then communicates with a DMX network 426 existing in the facility and connected to a light controller 427. DMX network 426 then passes to light controller 427 the command to change the color at the location of mood appliance 421. Light controller 427 changes the color of the lights 428 in the vicinity of the location. This simple example demonstrates a method that the MICE event system may use to create immersive experiences for attendees of a MICE event.

The successful operation of the MICE event system includes the generation and usage of performance management metrics, the most important of which is Average Quality of Location (AQoL), AQoL is a metric that is defined on a per RTLS tag basis as the average age of each tag's location which is reported to the RTIMS by the RTLS system. This is a running average meaning it is updated regularly as time passes and each time the RTLS system reports a new sighting for the tag. The running average can have a smaller window or a larger window depending on how the AQoL value will be used.

The usage of AQoL includes:

• • a. As an indicator of the confidence level that the RTIMS system has an accurate real-world concept of where a person is currently located (vs. where the RTLS system last reported them)
  • b. As an indicator of system performance, the AQoL can be used to produce quality contour maps of the RTLS coverage area. These maps can be used to detect problems with system performance/coverage in particular areas. Prior to the event the quality contour maps may be also be examined to set sensor cell physical dimensions. For example, a 160 Hz system with a global AQoL target of less than 1 second will limit the cell density to 160 RTLS tag devices. If through historical data, an average density of persons within a sensor cell area is projected to be greater than 160 than the physical sensor cell dimensions may be reduced.
  • c. A tag based AQoL may be used instead of a global AQoL to support events where the average density of persons within many sensor cell areas is projected to be greater than cell density limit of the system. In this type of situation, the RTIMS system dynamically determines AQoL priorities for RTLS tags located within crowded areas. The AQoL priority is determined from metrics that may be based on the persons attributes and the proximate exhibitor attributes. Those RTLS tags with lower priorities may report their positions less frequently, thus allowing a larger number of lower priority tags into the sensor cell area. An added benefit of tag based AQoL is that sensor cell areas may be made larger if the event organizer is willing to allow a set of lower priority tags in the facility which have more uncertainty in their location. Larger cell areas in a given event translate into lower hardware and network costs for the given event.
  • d. As an indication of system data generation quality, AQoL values aggregated by event can be calculated to indicate the overall quality of data collected during the event in order to provide confidence levels in the context of reporting.

FIG. 18 is a flowchart of a quality monitoring process 450 to generate and utilize AQoL and positional error for the RTLS system. Quality monitoring process 450 is repetitive and begins with the step 451 wherein the RTLS system determines the positional age T_age of a given RTLS tag in a given time interval. The positional age T_age is defined as the time since the last positional update from the RTLS system, wherein RTLS tag position was most recently triangulated and reported. In step 453 the AQoL is computed as a time sliding average of T_age for the given RTLS tag, the width of the sliding time window 454 being pre-defined. Step 455 follows wherein if the position and velocity for the given RTLS tag have been updated since the last time interval, the average speed v_ave is computed as a time sliding average of the updated speed (magnitude of updated velocity) for the given RTLS tag over the width of the sliding time window 454. Once the v_ave and AQoL is determined, a positional error estimate Δx is made in step 457 by multiplying v_ave by AQoL, the positional error effectively estimating the sphere of distance the RTLS tag has potentially moved since the position was last updated.

Steps 451, 453, 455 and 457 are repeated via step 452 for each RTLS tag in a given system time interval and for all tags at regular system time intervals. At certain predetermined system time intervals, reports are created in step 460, step 462, step 463 and step 465. Step 460 reports a topological map of AQoL. Step 462 reports a topological map of positional errors Δx. In step 463, the AQoLs are averaged across all RTLS tags to provide a first aggregate measure of the system quality. In step 465, the positional errors Δx are averaged across all RTLS tags to provide a second aggregate measure of system quality.

The apparatus described herein is flexible to create value for MICE event participants including attendees, exhibitors, sales staff and event organizers. Methods and processes to use the real time marketing system are now described in the context of creating useful tools for the MICE event participants.

The successful deployment of an RTLS system in an RUMS context involves techniques that reduce the complexity of setup and increase performance. Setup of an RTLS system involves an in-depth surveying and tuning process in order to ensure acceptable operation. The complexity of this process is aided by software tools which assist with the gathering of and organization of surveying information such as: survey points, frame of references, organizing distance measurements, automatically determining sensor locations based on individual related measurements and cross-checking to determine likely causes of error.

A process to set up operation of the MICE event information system is shown in the flowchart of FIG. 19. The process 900 as described uses the exemplary embodiment MICE event information system of FIG. 11, but may be appropriate for a variety of apparatus embodiments conceivable according to the present invention. The process as shown in FIG. 19 works for multiple facilities and multiple events per facility.

Beginning with the steps related to facility preparation, step 902 begins the process wherein the RTLS system is designed, a design representing the number and configuration of sensors, grouping the sensors into cells and defining the number and configuration of cells, the physical cell size, the wired and wireless RTLS network components and similar features. The RTLS system is then installed in step 904, calibrated in step 906 and then undergoes performance testing in step 908, wherein quality of location, AQoL, is verified to meet predefined levels throughout the facility. Steps 902 through 908 are only necessarily repeated once per facility although step 908 may be selectively completed again for selected events. Performance testing is done prior to placement of show structures.

Following the facility preparations, MICE event (show) specific operations begin. In step 910, show specific customizations are identified and in step 912 the identified customizations are developed including necessary software development and configuration. An example of show specific customizations is the integration of registration processes with the MICE event information system. Once the show specific customizations are developed they are ready for site configuration and deployment. In step 914, the server resources are configured and deployed. Examples of server resources are the RTIMS system, a DMZ system, and the RTLS recorder system. In step 916, immersive media resources and systems are configured and deployed. Examples of immersive media are large display video systems, 3D video systems, interactive lighting systems and music systems.

After the show specific resources are configured and deployed, the facility is mapped and static geospatial zones are defined in step 918. The facility may be mapped using CAD designs which may be imported into the RTIMS system, for example, by using CSV files holding tabular information with columns of coordinates and rows associated to distinct zones. The zones may be imported into the RTLS system in step 920 after which the zones are physically validated in step 922 by walking through the facility with one or more RTLS tag devices. AQoL is then checked again in step 924 after the show structures are fully in place and performance issues identified for remediation in step 926. If required, remediation of the RTLS system is performed in step 928, remediation including, for example, movement of RTLS sensors and recalibration of the system. If remediation is complete or not required the RTLS and RTIMS systems are integrated and tested in step 930. The event operation occurs in step 932.

Steps 910 through 932 are repeated per event wherein the facility has been set up previously according to steps 902 through 908.

During event operation, the RTIMS functions to automatically record and fulfill attendee requests for product information from a targeted exhibitor. Referring to FIG. 20, information request process 500 is shown. When an attendee is located in an exhibitor's booth, having been tracked to that location by the RTLS/RTIMS system in step 502, the attendee can indicate in step 504 via a button press on the RTLS tag that they desire more product information from the targeted exhibitor. Optionally, the attendee may send a SMS/MMS message from their cell phone. In step 506, the RTIMS server correlates this request with the attendee's current position in order to determine the targeted exhibitor for the request. If the location is does not correlate to a freestanding signage location, step 508, the desire for information is routed to the determined exhibitor in step 516 and access is granted to the targeted exhibitor for the attendees contact information 515. In step 519 the request may be fulfilled by any combination of SMS/MMS messaging back to the cell phone, email or other electronic means including posting information to the portal application associated with the RTIMS server. The requests may be automatically fulfilled; optionally, the exhibitor may act as a manual gatekeeper for such product information requests in step 518, receiving product information requests, for example, via the dashboard application.

In addition to booth oriented exhibitor information requests, attendees can approach arbitrary areas with freestanding signage indicating a topic of interest (for example a wall poster, a digital sign having programmable messaging, or simply a marking on the carpet). The attendee can indicate via the RTLS Tag, or alternatively a SMS/MMS message interaction, a generic request for “more information”. After determining that such a freestanding request has been made in step 508, the process continues with step 510, wherein the RTIMS associates the freestanding request with the topic assigned to the location the attendee is standing. The association may include attendee attributes to determine the topic of interest. If the freestanding signage is digital signage with programmable messaging, the digital sign is caused by the RTIMS system to display the topic of interest in step 512. In addition to or in lieu of step 512, the RTIMS may also fulfill the request for “more information” as described in step 519.

The RTIMS/RTLS system provides for a means to aid the attendee in pre-show, at-show navigation and post-show annotation of the MICE event through the navigation tools shown in the block flow diagrams in FIGS. 21A, 21B and 21C. Beginning with FIG. 21A, an attendee visits the portal application prior to the show (MICE event) in event 532. Subsequently, the attendee is presented with a map in step 534 from which the attendee selects various booths and events that they wish to visit based on information sent to the attendee about each exhibitor. For example, the attendee selects a booth for possible visit in step 536. Information about the selected booth exhibitor is shown in the attendee's web browser (in communication with the portal application) in step 538. Then, the attendee either confirms visit location in step 540 or moves to select another visit location via step 536. Once a visit is confirmed, it is added to the “visit” list 550 via step 542. Optionally, information about the attendee's registration at the show can also be used to automatically add to “visit” list 550 list any sessions that the attendee is scheduled to attend. The attendee has the option in step 544 to delete items from “visit” list 550. At any time during the portal session the attendee may print a list of and optionally map items on “visit” list 550 via step 545. The portal may be exited in step 546. Alternatively, in step 545 the attendee may request that “visit” list 550 in either text or map form be sent via SMS/MMS text message to the attendee's cell phone. The portal may be exited in step 546.

During the MICE event, the RTIMS server will keep track of the booths actually visited by the attendee. Either by SMS/MMS interactions or via the Dashboard, an attendee can compare what they have visited against what they planned to visit. They can request a map that indicates where they currently are located and how to get to any other location at the event.

The at-show process is described with the help of steps 552 through 569 of FIG. 21B. In step 552 the attendee visits a booth location of interest. The attendee signals a visit of this booth location in step 554 to the RTIMS via the attendee's RTLS tag or optionally by sending an SMS/MMS text message. In step 556, the RTIMS correlates the attendee's location to the closest booth location of an exhibitor, a booth location being the geospatial zone containing the booth area. In step 558, the correlated exhibitor location is compared with exhibitors on “visit” list 550 which is updated according to whether the exhibitor is currently included in the list or not. If the exhibitor is included in “visit” list 550, step 560 updates the status of the correlated exhibitor in “visit” list 550 to “visited”. If the exhibitor is not included in “visit” list 550, the correlated exhibitor is added to “visit” list 550 with status “visited” in step 561.

At any time while attending the show, the attendee may request an updated report in step 563 of “visit” list 550 via SMS/MSS interaction step 567, on their cell phone for example, or via dashboard interaction step 565 on a web-enabled application on a cell phone or local computer terminal, for example. The updated report is delivered to the attendee in step 568 as a list or in step 569 as a map.

After the MICE event, the attendee can visit the portal in order to experience reporting about their navigation of the event, for instance, the attendee may see exhibitors that were visited and pre-selected exhibitors that were missed. They can also annotate information about their visit experience and export it as a report for the consumption of supervisors or other interested parties. The post-show process as indicated by steps 572 through 585 of FIG. 21C, may occur at the end of one day of a multiday MICE event or may occur at some time later, say two weeks after the event concludes.

An attendee begins the post show process by visiting the portal application in step 572 and requesting the portal to report visit activity in step 574 which retrieves “visit” list 550. A display of “visit” list 550 is created in step 576 wherein exhibitors listed therein have status indicated as “visited” or “not visited”. The portal application then provides a means for the attendee to annotate informational notes about each “visited” exhibitor in step 578 and then, in step 580, stores the annotated notes with “visit” list 550. At a later time, or upon completion of annotating “visit” list 550, the attendee, in step 582, may create an “exhibit visit” report 584. The post show process completes when the attendee exits the portal application in step 585. Exhibit visit report 584 may be emailed in step 586 to a given set of email addresses and may alternatively be printed locally via the attendee's web browser in step 587.

During the MICE event, each attendee has the ability to create connections to other attendees at the event. FIG. 22A shows a flow diagram of method 600 wherein two attendees make such a connection. If two attendees request of the RTIMS server to make a connection, attendee1 via request 605 and attendee2 via request 606, the connection will be recorded by RTIMS server in step 607. These connections are private to each attendee and are independent of the event. The connection gives one attendee access to the contact information of the other attendee; attendee1's contact list in the portal is updated to include attendee2 contact information in step 608 and attendee2′s contact list in the portal is updated to include attendee1 contact information step 609. The connections and contact information can be viewed and managed post-show within the portal application. Confirmation of an established connection can be optionally delivered to each attendee's cell phone. Requests to connect may be made by RTLS tag or by SMS/MMS messaging.

Restraints may exist on connection requests via method 600, for example, requests may not being honored unless they fall within a pre-defined time window between requests. Typically, the attendees requesting connection are in communication with each other or in close physical proximity to one another.

An alternate embodiment of establishing connections between attendees is method 620 of FIG. 22B wherein attendee1 issues request 623 to establish a connection to attendee2 who is presently unaware of attendee1. RTIMS server receives the request as an SMS/MMS text message containing, for example, attendee2's last name and company. RTIMS server then correlates the received information to attendee2 and passes the request on to attendee2 as a SMS/MMS text message 626. Note that attendee2's cell phone number or RTLS tag identifier must be looked up in the RTIMS database to accomplish request 623.

Attendee2 may respond 624 to attendee1's connection request with an affirmative or negative confirmation 628 which is assessed in step 630. The response is forwarded to attendee1. If the response is not received in a pre-defined time limit, or the response is negative nothing happens. If the response is confirmed positive, then attendee1's contact list in the portal is updated to include attendee2 contact information in step 634 and attendee2's contact list in the portal is updated to include attendee1 contact information in step 636. The connect request 626 from the RTIMS server may alternatively be an audio sound or message generated by the RTLS tag.

During the MICE event, an attendee can request, via SMS/MMS communication or a dashboard application, the physical location of a second attendee to which they have previously established a connection. The RTIMS server will produce for the attendee a map indicating their current physical location and the location of the physical location of the second attendee.

A locator process 650 for locating attendees is shown in FIG. 23 which indicates a physical location request and the RTIMS actions that result. Attendee 1 begins locator process 650 by submitting a request 654 for the location (coordinates) of attendee2. RTIMS receives the request in step 656, querying the RTIMS database 660 in step 658 to confirm that attendee2 and attendee1 have previously established connection to one another. If

RTIMS database 660 does not confirm that a connection has been established, an appropriate message is sent back to attendee1 to that effect in step 659 and locator process 650 is terminated. If RTIMS database 660 confirms that a connection has been established the then locator process 650 continues with step 662 to query RTIMS database 660 for the coordinates of attendee2. Meanwhile, in tracking process 663, the RTLS system is tracking attendee2, and RTIMS system is logging attendee2's coordinates into the RTIMS database 660.

The most recent coordinates of attendee2 are returned from RTIMS in step 662, if attendee2 has been tracked at the MICE event, otherwise a null or equivalent is returned to step 662. Locator process 650 continues in step 664 by generating a map indicating the coordinates of attendee1 and the coordinates of attendee2. The map so generated in step 664 is made available for display to attendee in the portal in step 666.

A confirmation of a “successful” or “unsuccessful” location may be sent back to attendee1. As a part of the confirmation message or, alternatively, as a part of the map display, the time of the last successful RTLS location of attendee2 may be displayed. In an alternate embodiment, the map may be sent to attendee1's cell phone or the attendee may be instructed to view the map on the dashboard application. In another alternate embodiment, locator process 650 may run continuously so that the displayed map may be updated continuously with the coordinates of both attendee1 and attendee2.

In another aspect, the RTIMS system may have an appliance to track RTLS tag affinities. Affinity is a figure of merit proportional to the amount of time that the geospatial zone surrounding one RTLS tag is overlapped with a second RTLS tag. Affinities are for each RTLS tag and thus each person are stored in the database files. One useful tool delivered by the portal during and after the event is to provide a list of affinities for an attendee or for a sales person. The list of affinities effectively becomes a prioritized networking contact list and provides the attendee or sales person with direct information about what persons or exhibitors they spent the most time with during the event. A networking graph may also be constructed from the list of affinities. It readily understood that the affinity appliance is a useful tool for social networking events.

Other applications that benefit the exhibitor are provided. In a first example of such an application, exhibitor services setup process 680 is shown in FIG. 24, each exhibitor is able to visit, in step 681, the portal application prior to the show (MICE event) in order to load multi-media elements 682 that can be used in advertising. Exhibitors are offered the opportunity to purchase services 683, such as SMS/MMS messages to attendees passing by the booth in order to entice them to visit the booth. In step 684, sales staff may be set up in the RTIMS system, given specific authorizations and attributes for utilizing the RTLS and RTIMS system and for handling sales lead capture events as will be explained in relation to FIG. 25.

Another exhibitor application is indicated in the lead capture process 700 of FIG. 25. An attendee's request 702 for more information from the exhibitor and a simple event 701 wherein the RTLS system reports that an attendee entered the physical space of the exhibitor's booth is detected by the RTIMS system in step 704. As a result of the detection, access may be granted the exhibitor to the attendee's contact information in step 706.

The contact information and visit information will be collected as lead information for the exhibitor to analyze, annotate and distribute to Sales Staff. When the contact information is released to the exhibitor, the contact information is included in the list of leads 710. The exhibitor accesses the contact information in step 713, with the ability to annotate the list of leads 710 and the ability to request a report 715 of the list of leads 710. The exhibitor may be charged a fee to receive the contact information and to gain access this information as in step 708.

In yet another application conceived for the exhibitors benefit, the exhibitor can set up alerts for events such as a particular attendee or an attendee meeting certain criteria arriving in the booth as detected by the RTLS. The RTIMS will then send an SMS/MMS message to the Exhibitor and Sales Staff of their choosing to be notified of this event.

A representative exhibitor alerting process is shown in FIG. 26. Alerting process 720 is initiated with event 722 wherein an attendee visits the exhibitor location such as a booth. RTIMS system detects the attendee in step 724 and begins a process to determine if the attendee is of sufficient interest to cause an alert to be sent to a sales staff person. Step 726 checks attendee attributes for comparison against pre-defined attributes to establish an alert, for example: company, title, and key words in the attendee's description. If there is no match, alerting process 720 terminates. If some attributes do match, then a sales staff person, preferably on-site, is selected in step 730 and alerted in step 732. The alert may occur, for example, by sending SMS/MMS message 735 to the selected sales staff or as an alert message 737 on the exhibitor dashboard application. The alerting process terminates by at least capturing the attendee information and time of arrival in lead capture event 728. If no sales staff is available, the lead is still captured for later follow up in lead capture event 728. A fee may be charged in step 733 for the lead capture service.

Post-show, information is processed by the reporting system and reported to exhibitors via the portal application concerning:

• • a. attendee visits to or near the Exhibitor's booth (in aggregate and categorized) (fee may be charged for this service),
  • b. staff interactions with attendees,
  • c. detailed reporting on demographics and movements of individual attendees,
  • d. Scatter-map analysis (including movies depicting movement) of attendee traffic at the show.

The portal and dashboard applications recognize, through the authentication process at log-in, what type of user (attendee, exhibitor, sales staff, show organizer) is accessing information and responds with appropriate levels and types of information.

Several examples of applications that benefit the attendee and the exhibitor have presented. The present invention also enables many conceivable applications that benefit the show organizer.

Show Organizers are provided access to a “show organizer” dashboard application in order to experience live information concerning RTIMS activity within the entire event. This includes a map component that shows live positions and movements of every attendee at the event in addition to reporting significant metrics.

Post-show, information is processed by the RTIMS system and reported to show organizers concerning:

• • a. attendee visits to or near every exhibitor's booth (in aggregate and categorized),
  • b. attendee traffic at arbitrarily defined areas of the event,
  • c. detailed reporting on demographics and movements of specified individual attendees,
  • d. scatter-map analysis (including movies depicting movement) of attendee traffic at the MICE event.

Prior to and during the MICE event, the RTIMS server populates the RTIMS database with information concerning the event and its environment. Attendees and exhibitors may query the database via SMS/MMS messaging or the dashboard application. For instance, the attendee can request local weather and radar images, information about training or other event related sessions starting in the next 30 minutes, maps of the facilities, and information about local restaurants, event hours, emergency contact numbers and procedures.

Within the portal application, each attendee will be able to specify and control what contact information is provided to each exhibitor that is granted access to the attendee's contact information. Sales staff are provided access to the leads assigned to them by the exhibitor. The portal access can include browsing, analyzing and exporting of the lead data.

Show Organizers and Exhibitors can survey attendees in an interactive audience response system application using the RTLS/RTIMS systems in order to collect actionable data from the survey. FIG. 27 depicts a flowchart of an exemplary embodiment of a survey process 750 enabled by the present invention. In the exemplary embodiment, the surveyor may be, for example, a session speaker, an exhibitor or a member of the press. The surveyor makes a survey request 751 through purchase agreement or similar means utilizing the portal application. In step 753, the surveyor defines criteria about the survey such as the survey question(s), response constraints, attendee constraints such as registration type and location, time window for response once the survey is initiated, where to send the results and statistical data required. The RTIMS system collects the survey criteria through the portal application so that when the surveyor initiates the survey in step 757, the RTIMS system in step 755 begins collecting the survey response according to the collected criteria.

The audience of the survey may respond in step 759 by one of the method of submitting a response through the portal application, the method of SMS/MMS messaging the response and the method of pressing one or more RTLS tag buttons. Other means for response are possible.

In step 760, survey responses collected by the RTIMS system are aggregated into a report according to the collected criteria. An SMS/MMS message of the aggregated result may be sent to the surveyor in step 764 for immediate feedback which may be used to influence the activity in which the surveyor is engaged. For example, a session speaker may orient the remainder of his presentation based on the survey results. A more comprehensive report may be emailed in step 766 and may be posted to the portal application in step 768 for later review by the surveyor. A fee may be charged for the survey service in step 762, wherein the fee may comprise a set up fee, a per instantiation fee and a per response fee. Surveys may be repeated for use on an individual basis, for example, a surveyor may target a specific attendee at a specific time for a response to a survey question.

The invention also supports the use of RTIMS enabled hand-held computers carried by sales staff. The RTIMS system associates the hand-held computer with the appropriate sales staff member and can interact with them via wireless Ethernet for the purposes of providing information about an attendee standing nearby and for collection of survey responses from them.

An additional alternate embodiment incorporates the use of a handheld computer device such as a smart phone device with an integrated RTLS tag in place of a cellular phone and separate RTLS tag. The attendee would wear the device on a lanyard and the delivery of services to the attendee would be done using a Graphical User Interface (GUI) rather than relying on SMS/MMS messaging. The handheld computer device would include an exterior speaker, a vibrating alert system, and a headphone port.

In alternate embodiments, active RFID technology can be used in place of RTLS in order to deliver a subset of the value represented by the invention. Active RFID provides only presence information within a monitored area and requires an impractical amount of equipment to monitor the entire event space.

An additional alternate embodiment includes the use of a web browser on the cellular phone to provide attendee access to their personal dashboard application and/or their personal portal application. This functionality would replace some SMS/MMS interactions where appropriate.

Another alternate embodiment includes connecting kiosks placed around the event space to the RTIMS network in order to deliver access to the dashboard and/or portal.

Much of the value of this invention can also be delivered in a permanent installation setting such as a museum. In that case, the content is less marketing and advertising oriented and more centered on interactively delivering specific content about individual museum exhibitions.

It will be appreciated by those skilled in the art that changes could be made to the exemplary embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope as defined by the appended claims.

Claims

1. A system for managing event information during an event occurring in a facility, the facility including a set of geospatial zones, wherein a set of persons move throughout the set of geospatial zones, the system comprising: a) A set of computer servers having one or more processors, local memory, at least one storage device attached to each computer server;b) A set of locatable tag devices associated with the set of persons, to transmit locating signals on a first channel and to transmit and receive device data on a second channel;c) A network of real-time location sensors, located in a predetermined pattern in the facility, to detect the locating signals;d) A set of controllable devices located in the facility connected to the set of computer servers;e) A real-time location system, connected to the network of real-time location sensors and to the set of computer servers, and programmed to interact with the set of locatable tag devices and with the network of location sensors to determine, to store in memory and to report geospatial coordinates of each locatable tag device in the set of locatable tag devices;f) A recording system, connected to the real-time location system, to record a set of locations associated with the set of locatable tag devices as reported by the real-time location system;g) A real-time information marketing system (RTIMS) in communication with the real-time location system, the RTIMS connected to a local area network and further connected to a wide area network, the RTIMS programmed to operate on the set of computer servers to create a first set of associations between each person in the set of persons to one locator tag device of the set of locator tag devices, to create a second set of associations between each person in the set of persons to one geospatial zone of the set of geospatial zones and further programmed to generate a set of tabular data files; the set of tabular data files including the first set of associations and the second set of associations;h) The RTIMS further comprising a means for assessing a quality of location parameter and a means for reporting the quality of location parameter;i) The RTIMS further comprising a means for controlling the set of controllable devices based on the first set of associations and the second set of associations;j) A dashboard application system operating a dashboard application program and connected through the local area network to the RTIMS;k) A portal application system operating a web portal application program and connected through the wide area network to the RTIMS;l) A viewer application system, operating a viewer application program, for viewing the tabular data files; andm) A reporting system, connected to the portal application system, the viewer application system, and a set of external systems, the reporting system having access to the set of tabular data files and programmed to provide reporting services based on the set of tabular data files.

2. The system of claim 1 wherein the real-time location sensors in the network of real-time location sensors further comprises a means to measure an angle of arrival of the locating signals from the set of geospatial zones.

3. The system of claim 2 wherein the network of real-time location sensors further comprises a means for measuring a time difference of arrival between a predetermined pair of locating signals from the set of locating signals.

4. The system of claim 1 wherein the predetermined pattern comprises a plurality of networks of hexagonal shaped cells.

5. The system of claim 1 wherein the set of locatable tag devices includes a physical control to enable a user-generated signal on the second channel.

6. The system of claim 1 wherein the real-time location system is capable of identifying each locatable tag device of the set of locatable tag devices by communicating over the second channel.

7. The system of claim 1 wherein the RTIMS further comprises a means to communicate to the set of persons through a public cellular network.

8. The system of claim 1 wherein the RTIMS further comprises a main process, a set of sub-processes and a database in asynchronous and non-blocking operation.

9. The system of claim 1 wherein the real-time location system comprises a spatial model processor connected to the set of computer servers programmed to generate a three-dimensional model of the geospatial zones.

10. The system of claim 1 wherein the set of tabular data files are of the comma separated value (CSV) format.

11. The system of claim 1 wherein the set of tabular data files is exported into a SQL database system.

12. The system of claim 1 wherein the RTIMS further comprises: a) A set of person objects, resident on the computer servers, for containing and operating on a set of data related to the set of persons;b) A first set of driver objects, resident on the computer servers, for containing information and methods to operate on the set of controllable devices;c) A second set of driver objects including an object for the real-time location system and for modeling and manipulating a set of data related to the set of geospatial zones;d) A set of appliance objects, resident on the computer servers, for containing data and modeling a set of data related to a set of devices and systems in the facility;e) An exporter function for exporting object data into the set of tabular data files; andf) A controller function for creating and managing the set of person objects, the set of appliance objects and the set of driver objects, and for importing data from a set of import data files and for exporting a set of export data to the exporter function.

13. The system of claim 12 wherein the RTIMS further comprises an object-oriented database system, resident on the set of computer servers, for storing and manipulating the set of data related to the set of persons, the set of data related to the set of geospatial zones and the data related to the set of devices and systems in the facility.

14. System of claim 1 wherein the set of external systems includes CRM systems.

15. A reporting system, resident on at least one computer server, for reporting event information after a set of events, wherein a set of persons have attended at least one event of the set of events and a set of organizations have taken part in at least one event of the set of events, and wherein a real-time information management system and a real-time location system have been utilized to gather a set of event data sets for each event of the set of events, and wherein the reporting system is programmed to process and store a set of reports in a local memory for exporting to a set of external systems, the reporting system comprising: a) A set of reporting templates defining a set of report forms;b) A set of asset definitions defining a set of relational operations to be performed on the set of event datasets;c) An operation means for performing relational operations on the set of event datasets to create a set of report datasets; andd) A merging means for merging at least one reporting template for the set of reporting templates with at least one report dataset of the set of event datasets to create a report.

16. The system of claim 15 further comprising: a) A set of organization objects containing and operating on data related to the set of organizations;b) A set of person objects containing and operating on data related to the set of persons;c) A set of show objects containing and operating on at least one event dataset from the set of event datasets;d) A set of component objects containing and operating on data describing configurations of the real-time location system and the real-time information management system for the set of events;e) A datastore for holding the set of event datasets; andf) A controller function for creating and managing the set of person objects, the set of organization objects, the set of show objects and the set of component objects, and for importing at least one of the event datasets into the datastore and for controlling the operation means and the merging means.

17. A viewer application system, resident on at least one computer, for viewing and organizing event information after a set of events, in communication with a computer network, wherein a set of persons have attended at least one event and a set of organizations have taken part in at least one event, and wherein a real-time information management system and a real-time location system have been utilized to gather a set of event data sets related to each event of the set of events, the viewer application system comprising: a) A computer having at least a processor, a display and persistent memory in communication with the computer network;b) A viewer application program operating on the computer;c) A view navigator component in the viewer application program for selecting and importing at least one event dataset from the set of event datasets;d) A view workspace component in the viewer application program for displaying at least one event dataset from the set of event datasets in a tabular form;e) A graphical analysis component in the viewer application program for analyzing graphically displayed data from the set of event datasets;f) A relational operations component, in the viewer application program, to interactively select and perform at least one pre-defined relational operation on at least one event dataset from the set of event datasets to produce and store a first event data asset in persistent memory, the relation operations component further programmed to interactively select and perform at least one predefined relational operation on the first event data asset to produce a second event data asset and to store the second event data asset in a persistent memory; and,g) An asset definition component, in the viewer application program, to record and store the at least one pre-defined relational operation as an executable relational operation producing the second event data asset from the at least one event data asset.

18. A method to assemble an event information management system for a set of events held in a first chosen event facility a set of event facilities wherein the event information management system comprises at least a real-time location system (RTLS) and a real-time information marketing system (RTIMS), the method comprising the steps of: a) Performing a facility set up process in the first chosen event facility, including the steps of: i) Designing a configuration for the RTLS including at least a network of RTLS sensors and a set of RTLS tag devices;ii) Installing the network of RTLS sensors;iii) Calibrating the network of RTLS sensors; andiv) Testing the performance of the network of RTLS sensors;b) Performing an event specific set up process for a chosen event from the set of events, the event specific process including the steps of: i) Identifying a set of event specific customizations;ii) Developing the set of event specific customizations including software development and software configuration;iii) Deploying and configuring a set of server resources for the chosen event, the server resources including at least a server resource for the RTIMS and at least one server resource for a RTLS recorder system;iv) Deploying and configuring a set of immersive media systems;v) Defining a set of geospatial zones related to the event facility;vi) Importing the set of geospatial zones into the RTLS;vii) Validating the set of geospatial zones by testing event facility with at least one RTLS tag device;viii) Measuring a quality of location parameter for the set of geospatial zones to identify a geospatial zone that requires system performance remediation;ix) Remediating the geospatial zone that requires system performance remediation;x) Testing the event information management system;xi) Operating the event information management system;xii) Repeating the step of performing a facility set up process for each facility in the set of events; andxiii) Repeating the step of performing a facility set up process for a second chosen event facility of the set of event facilities.

19. The method of claim 18 wherein the step of designing the configuration of the RTLS includes the steps of: a) Representing the number and configuration of sensors in the network of RTLS sensors;b) Grouping the network of sensors into a set of sensor cells;c) Defining the number and configuration of the set of sensor cells including the physical cell size of each sensor cell; andd) Defining a set of wired and wireless RTLS network components resident in each sensor cell.

20. A method of gathering and managing event information from an event, the event information describing behaviors of a set of organizers, a set of participants and a set of exhibitors in an event facility during the event, the method including the steps of: a) Providing a real-time information marketing system (RTIMS) at the event facility which produces an event data set modeling the behaviors of the set of organizers, set of participants and set of exhibitors in the event facility during the event;b) Storing the event data set in a persistent memory of a computer server;c) Deploying a network of real-time location sensors at the event facility;d) Deploying a set of real-time location system (RTLS) tag devices to the participants;e) Providing a RTLS for determining RTLS tag device locations in the facility;f) Programming the RTLS with a set of geospatial zones within the event facility;g) Enabling RTLS communication with the RTIMS with the network of RTLS sensors and with the set of RTLS tag devices;h) Tracking the locations of the set of participants using the RTLS and RTIMS with a participant locator service;i) Providing a dashboard application program for the set of exhibitors;j) Providing a portal application program for the set of participants and the set of exhibitors;k) Providing a recorder system for recording the locations of the set of participants;l) Providing a viewer application program to organize and manage the event dataset; andm) Providing a reporting system for the set of exhibitors and the set of organizers to organize and generate a set of reports based on the event dataset.

21. The method of claim 20 wherein the dashboard application program is provided during the event time period.

22. The method of claim 20 including the steps of: a) Deploying a set of controllable devices in the event facility;b) Enabling communications between the set of controllable devices and the RTIMS; andc) Enabling the RTIMS to control the controllable devices based on the locations of the set of participants.

23. The method of claim 20 wherein the step of providing a portal application program for the participants includes the steps of: a) Monitoring a set of information requests from the set of exhibitors;b) Enabling the set of participants to access the participant locating service; andc) Enabling a set of navigation planning tools for the set of participants.

24. The method of claim 20 wherein the step of providing a dashboard application program includes the additional steps of: a) Providing a graphical display of a real-time map of the event facility;b) Providing a set of dashboard controls to enable the set of exhibitors in finding the participants; andc) Providing a textual display for showing a list of information related to the set of participants.

25. The method of claim 20 including the step of providing a set of active buttons on the RTLS tag device usable by the set of participants to communicate with the RTLS.

26. The method of claim 25 wherein the step of providing a portal application program includes the steps of: a) Displaying a map of a set of booths in the event facility assigned to the set of exhibitors;b) Providing a set of information about the exhibitors for a first selected booth in the set of booths to the set of participants;c) Confirming a visit by the set of participants to the first selected booth;d) Adding the selected booth and a second selected booth to a visit list;e) Allowing for the participant to modify the visit list;f) Allowing set of the participants to display the visit list; andg) Allowing set of the participants to store the visit list for use during the event.

27. The method of claim 26 further comprising the steps of: a) Monitoring the set of active buttons;b) Correlating the location of a chosen participant of the set of participants to a closest booth in the set of booths;c) Comparing the closest booth to the visit list;d) If the closest booth is not in the visit list, then adding the closest booth to the visit list;e) Annotating the visit list to indicate that the closest booth was visited; andf) Reporting the updated visit list to the chosen participant.

28. The method of claim 27 wherein the step of reporting the updated visit list to the chosen participant includes sending an SMS//MMS text including the updated visit list to the chosen participant.

29. The method of claim 27 wherein the step of reporting the updated visit list to the chosen participant includes the steps of: a) Enabling the chosen participant to utilize the dashboard application; andb) Sending a message to the dashboard application program that results in a map display indicating that a booth of the set of booths was visited.

30. The method of claim 27 including the following steps which may be performed after the event: a) Retrieving the visit list for the chosen participant;b) Displaying the visit list;c) Ascertaining a set of visited booths from the set of booths;d) Allowing the chosen participant create an annotated visit list;e) Storing the annotated visit list; andf) Creating a visit report from the annotated visit list.

31. The method of claim 30 including the additional step of: Emailing the visit report to the chosen participant.

32. The method of claim 30 including the additional step of: Printing the visit report for the chosen participant.

33. The method of claim 25 wherein the step of providing a RTIMS at the event facility includes the additional steps of: a) Receiving a first request with the RTLS that a first participant of a set of participants desires a first set of information associated with a second participant;b) Receiving a second request with the RTLS that the second participant of the set of participants desires a second set of information associated with the first participant;c) Correlating the first request and the second request;d) Sending the first set of information to the second participant; ande) Sending the second set of information to the first participant.

34. The method of claim 25 wherein the step of providing a RTIMS at the event facility includes the additional steps of: a) Recognizing that a first participant requests capture of information associated with a second participant;b) Sending a connection request to the second participant;c) Receiving a confirmation message from the second participant;d) Sending a denial message to the first participant if the confirmation message denies the connection request; ande) Performing the following steps if the confirmation message allows the connection request: i) Allowing a first set of contact information associated with the first participant to be viewable by the second participant; andii) Allowing a second set of contact information associated with the second participant to be viewable by the first participant.

35. The method of claim 25 wherein the step of providing a RTIMS at the event facility includes the additional steps of: a) Allowing for a first participant and a second participant to establish a persistent connection wherein contact information and physical location information may be shared;b) Recognizing that the first participant requests capture of the current physical location of the second participant;c) Determining if the first participant has established a persistent connection with the second participant;d) Sending a denial notice to the first participant if a persistent connection has not been established between the first participant and second participant; ande) Obtaining a set of positional data from the RTLS for the second participant if the persistent connection has been established.

36. The method of claim 35 including the further steps of: a) if the persistent connection is established then generating a map of the event facility;b) Plotting the coordinates of the first participant and the second participant on the map; andc) Making the map available to the first participant through the portal application program.

37. The method of claim 20 wherein the step of providing a portal application program includes the steps of: a) Allowing for a chosen exhibitor of the set of exhibitors to load a multimedia advertising element into the RTIMS;b) Providing the chosen exhibitor of the set of exhibitors an event information management service; andc) Providing the chosen exhibitor a set of sales staff authorizations for accessing the event information management service.

38. The method of claim 25 wherein the step of providing a RTIMS at the event facility includes the additional steps of: a) Detecting when a requesting participant of the set of participants requests information from a chosen exhibitor of the set of exhibitors;b) Detecting when the requesting participant visits a selected booth associated with the chosen exhibitor; andc) Providing the chosen exhibitor a set of contact information for the requesting participant.

39. The method of claim 38 including the additional steps of: a) Adding the set of contact information to a list of customer leads;b) Providing the chosen exhibitor access to the set of contact information;c) Providing the chosen exhibitor access to a report containing the list of customer leads; andd) Logging a fee related to the report containing the list of customer leads.

40. The method of claim 25 wherein the step of providing a RTIMS at the event facility includes the additional steps of: a) Detecting when a requesting participant visits a chosen booth associated with a specific exhibitor;b) Retrieving a set of requesting participant attributes associated with the requesting participant;c) Comparing the set of requesting participant attributes to a pre-defined set of exhibitor attributes in order to match a sales agent with the requesting participant;d) Selecting the sales agent based on the result of the step of comparing;e) Alerting the sales agent of the requesting participant;f) Passing the set of requesting participant attributes to a lead capture list if the sales person does not respond to the alerting step; andg) Charging a fee to the exhibitor if a sales agent is matched with the requesting participant.

41. The method of claim 40 wherein the step of alerting the sales agent about the requesting participant includes the step of sending a SMS/MMS message to the sales agent.

42. The method of claim 40 wherein the step of alerting the sales agent about the requesting participant includes the step of sending an alert message to the dashboard application program.

43. The method of claim 25 wherein the step of providing a RTIMS at the event facility includes the additional steps of: a) Collecting criteria for a requested survey from the portal application program;b) Detecting the initiation of the requested survey;c) Collecting survey data from a selected set of participants;d) Aggregating the collected survey data into a survey report;e) Publishing the survey report; andf) Charging a fee for the publication of the survey report.

44. The method of claim 43 wherein the step of collecting survey data from a set of participants includes the step of receiving a survey submission through the portal application program.

45. The method of claim 43 wherein the step of collecting survey data from a selected set of participants includes the step of receiving a survey submission through a SMS/MMS message.

46. The method of claim 43 wherein the step of collecting survey data from the selected set of participants includes the step of receiving a survey submission from the active buttons.

47. The method of claim 43 including the additional step of sending an SMS/MMS message of the survey report.

48. The method of claim 43 including the additional step of sending an email message containing the survey report.

49. The method of claim 43 including the additional step of posting the survey report to the portal application program.

50. The method of claim 20 wherein the step of tracking the locations of the set of participants using the RTLS and RTIMS systems includes the step of: Periodically determining average quality of location parameter (AQoL) for each RTLS tag device as the average age of each RTLS tag device during the event.

51. The method of claim 50 including the additional steps of: a) Generating a contour map of the event facility indicating the AQoL of each RTLS tag device; andb) Reporting the average of AQoL over all RTLS tag devices in the event facility.

52. The method of claim 50 including the additional steps of: a) Computing an average velocity for each RTLS tag device during the event, the velocity being computed as the time averaged rate of change of RTLS tag device location during a pre-defined time interval as reported to the RTIMS by the RTLS; andb) Computing an estimated positional error for each RTLS tag device by multiplying the average speed of a given RTLS tag device by the AQoL of the given RTLS tag device.

53. The method of claim 52 including the additional steps of a) Generating a contour map of the event facility indicating the estimated positional errors for each RTLS tag device; andb) Reporting the average of AQoL over all RTLS tag devices in the event facility.

54. The method of claim 20 wherein the step of tracking the participant locations of the set of participants using the RTLS and RTIMS systems includes the steps of: a) Defining a set of person objects wherein each person object contains a first zone list and a second zone list;b) Associating each person object to a dynamic zone of a set of dynamic zones;c) Defining a set of zone objects wherein each zone object contains a third zone list;d) Associating each zone object to one geospatial zone in the set of geospatial zones;e) Populating each first zone list with a subset of geospatial zones from the set of geospatial zones;f) Populating each second zone list with a first subset of dynamic zones; andg) Populating each third zone list with a second subset of dynamic zones.

55. The method of claim 20 wherein the step of providing a viewer application program to organize and manage the event data set comprises the steps of: a) Defining a set of relational operations in the viewer application program;b) Providing for an asset definition recorder in the viewer application program for recording a list of relational operations in a computer readable device;c) Importing the event data set into the viewer application program;d) Operating on the imported event data set with a first relational operations from the set of relational operations to create a first derived event data set; ande) Storing the first derived event data set in the computer readable device.

56. The method of claim 55 including the additional steps of: a) Operating on the first derived event data with a second relational operation from the set of relational operations to create a second derived event data set;b) Recording the first and second relational operations as an executable macro in the asset definition recorder; andc) Storing the second derived event data set in the computer readable device.

57. The method of claim 56 including the additional steps of: a) Importing a new event data set from a new event into the viewer application program; andb) Executing the executable macro to cause the first relational operation and the second relational operation to operate on the new event dataset to create a new derived event dataset.

58. A method of reporting event information for a set of events in a set of event facilities, the event information for each event included in an event data model representing the behaviors of a set of organizers, a set of participants and a set of exhibitors during each event in each event facility, the set of event data models for the set of events being stored in a local memory datastore of a reporting system server, the method including the steps of: a) Creating a set of executable asset definitions to organize a set of report data from the set of event data models;b) Creating a set of report templates;c) Operating a reporting program on the reporting system server;d) Importing the set of report templates into the local memory datastore;e) Importing the set of executable asset definitions into the local memory datastore;f) Executing at least one of the asset definitions of the set of asset definitions to organize a set of report data from the set of event data models;g) Placing the set of report data into at least one report template to create a report; andh) Communicating the report to an external computer system.

59. The method of claim 58 wherein the step of creating a set of executable asset definitions includes the steps of: a) Applying a set of relational operations to a first set of tabular data to extract a second set of tabular data; andb) Storing the set of relational operations on a computer readable media suitable for importing into the reporting program as an executable asset definition which when executed on a third set of tabular data reapplies the set of relational operations to the third set of tabular data.

60. The method of claim 58 wherein the step of creating a set of report templates includes the step of defining a set of report templates suitable for creating reports that transfer into a CRM system of an external system.

61. The method of claim 58 including the additional steps of: a) Providing a set of objects including a person object class, an organization object class, a show object class and a component object class in communication with the reporting program;b) Instantiating at least one show object of the show object class with data from the set of data models;c) Instantiating a set of organization objects of the organization object class with data from the set of data models;d) Instantiating a set of component objects of the component object class with data from the set of data models; ande) Instantiating a set of person objects of the person object class with data from the set of data models.