Event Monitor/Process Engine

Every time a location event is triggered, an entry in the Apisphere Event Log is created. The log entry contains all of the contextual information that will be needed by the process. That context includes the following:

• Timestamp of event.
• Zone that represents the location of the event.
• The device that triggered the event.
• The trigger type (on entry, or on exit).
• The person who owns the device that triggered the event.
• Historical list of events for that zone and device (these are useful for trigger guards).

Trigger Guards

GPS locations are not always accurate. Because of that, events could be triggered multiple times when they shouldn't. Because of the varying accuracy of location samples a user could be seen by the Apisphere Platform to have jumped out of and back into a zone, thus triggering the same event and process again.

Even when accuracy isn't a problem, certain events should only cause actions once in a certain frequency (or should only do so based on arbitrary logic that only the Apisphere Express developer can determine).

So, because events and processes are triggered automatically, the platform needs to have a mechanism for allowing developers to determine if processes should actually execute or not. We call those *trigger guards* in the Apisphere Platform.

Trigger guards are actually a set of API calls that allow connector developers to look at the history of events for the specific device and zone that has triggered the current event. In that way, connector developers can determine when, if ever, the exact device and zone have triggered an event. That historical information along with other API calls to stop processes, allow connector developers to short circuit process execution.

Connection Engine

Connectors are basically just Groovy scripts that perform broadly 3 functions:

• Retrieve information from external sources,
• Transform the information from one XML format to another, or
• Deliver information to the user.

There may be some specific examples that don't fit into one of those 3 categories, but the vast majority of connector scripts will.

Connector scripts execute within the same context as the overall

Track/Match/Trigger

One of the most basic and fundamental features of the Apisphere Platform is the tracking of devices into and out of zones. Zones are defined by arbitrary polygons.

Because of varying accuracies for location samples, this is not as simple as it would seem. Apisphere has worked hard to improve the accuracy of event triggering by refining the algorithms for determining if a device is located within a particular area or not. Improving the accuracy and efficiency will be an on going mission for Apisphere. As we improve upon those algorithms all Apisphere users will benefit.

Apisphere can utilize a variety of means for determining location, including the following:

• GPS
• Cell phone tower
• Wifi

Instead of treating the user's location as a point sample, the Apisphere tracking algorithms take into account the accuracy of the sample and effectively "spread" the user of space. That fuzzy view of the user's location is what is used to determine whether a user's mobile device is in a particular zone or not. Apisphere derives it's own view of accuracy that augments that which comes from the GPS or other means of location determination.

Messaging Engine

The Apisphere Platform is all about sending information to mobile devices, so it provides capabilities out of the box to communicate with mobile devices.

Email
The platform provides basic capabilities to construct email messages to one or more recipient and then send them. Our gateway will support large numbers of email messages supporting both HTML and plain text formats.

SMS
In addition to email, the Apisphere platform supports the construction and transmission of SMS messages to one or more mobile devices. The SMS messages can be chunked in order to support messages larger than 160 characters. MMS messages are also supported.

Voice
The Apisphere Platform has the ability to initiate voice calls. The voice calls can either be simple text to speech information only calls or highly interactive IVR based calls where the end user is prompted for various information. The information obtained in an IVR session can be used to update enterprise information systems using our process engine.

HTML Forms
Forms and other web based interactions can be initiated from the platform to the mobile device by sending a URL to the mobile device using either SMS or email. The interactions can be as simple or as complex as you like and can involve multiple HTML pages. All backend processing is done using our process engine and can include updating enterprise information systems.