U.S. patent application number 14/633015 was filed with the patent office on 2017-01-12 for venue notifications.
The applicant listed for this patent is Blazer and Flip Flops, Inc. dba The Experience Engine. Invention is credited to Joshua David Bass, Scott Sebastian Sahadi, Benjamin Harry Ziskind.
Application Number | 20170011348 14/633015 |
Document ID | / |
Family ID | 53883391 |
Filed Date | 2017-01-12 |
United States Patent
Application |
20170011348 |
Kind Code |
A1 |
Ziskind; Benjamin Harry ; et
al. |
January 12, 2017 |
VENUE NOTIFICATIONS
Abstract
A web service platform to improve end-user engagement in a
captive audience environment. Mobile and web-based clients allow
application users to authorize and communicate their locations with
other individuals within the closed environment. Communication may
include methods for forming rally points and notifying each other
of entry to and exit from the environment.
Inventors: |
Ziskind; Benjamin Harry;
(San Diego, CA) ; Bass; Joshua David; (Carlsbad,
CA) ; Sahadi; Scott Sebastian; (Solana Beach,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Blazer and Flip Flops, Inc. dba The Experience Engine |
San Diego |
CA |
US |
|
|
Family ID: |
53883391 |
Appl. No.: |
14/633015 |
Filed: |
February 26, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61945053 |
Feb 26, 2014 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 63/102 20130101;
H04L 51/046 20130101; H04L 63/101 20130101; G06F 2221/2149
20130101; H04W 4/021 20130101; H04L 63/18 20130101; G06F 21/6218
20130101; G06Q 10/1095 20130101 |
International
Class: |
G06Q 10/10 20060101
G06Q010/10; H04L 12/58 20060101 H04L012/58; H04W 4/02 20060101
H04W004/02 |
Claims
1. A method for connecting with a contact, comprising: determining
a user has entered a venue by a computing device; identifying user
contacts within the venue; and transmitting a message to devices
associated with each user contact within the venue regarding the
user within the venue.
2. The method of claim 1, further including determining the user
contact and the user have a mutual connection.
3. The method of claim 1, wherein the user and the user contact
have a connection through a third party network service.
4. A method for organizing a gathering, comprising: creating a
rally at geographical point by a computing device; receiving a
selection of contacts from a remote device associated with a user;
and transmitting rally geographic information to a device
associated with each selected contact to allow for a later meet-up
of the contacts.
5. The method of claim 4, determining the time for each contact of
the selected contacts to travel to the geographical point.
6. The method of claim 5, further comprising: changing the
geographical location or a time associated with the rally; and
updating the time for each contact of the selected contacts to
travel to the geographical point.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims the priority benefit of U.S.
provisional application No. 61/945,053 filed Feb. 26, 2014 and
entitled "System and Method for Increasing Customer Engagement,"
the disclosure of which is incorporated herein by reference.
BACKGROUND
[0002] Field of the Invention
[0003] The present invention is generally related to web services.
More specifically, the present invention concerns a web service
platform to improve customer communications within a venue.
[0004] Description of the Related Art
[0005] Venues such as theme parks, cruise ships, universities,
arenas, resorts, and stadiums are popular attractions that host
thousands of people on a daily basis. Most of these venues provide
static paper maps or signs that are meant to allow guests to
explore the venue, encourage engagement in one or more activities
at the venue, and otherwise attempt to maximize enjoyment while on
the premises. These venues will often have other special events
such as concerts, merchandise, culinary, or souvenir sales, and
other limited time or new events that are of potential interest to
their visitors.
[0006] It is difficult if not impossible, however, for guests to
communicate their location and plan to one another with respect to
when and where to meet for special events. Guests are similarly
challenged with respect to simply meeting up throughout the day
when they are only provided with a paper map upon entrance into the
venue. While signage, flyers, or commercials outside the venue
might help communicate information or identify potential meeting
points, there is no means to communicate this information in
real-time, especially for last minute events, offers, and changes
in plans.
[0007] There is a need in the art for improved customer
communications. An improved guest communication methodology within
such venues would improve the guest experience and ultimately
improve monetization from the user presence at the venue.
SUMMARY OF THE PRESENTLY CLAIMED INVENTION
[0008] A first claimed embodiment of the present invention includes
a method for connecting with a contact. Through the method, a
determination is made as to whether a user has entered a venue,
identifies user contacts within the venue, and then transmits a
message to devices associated with each user contact within the
venue regarding the user within the venue.
[0009] A second claimed embodiment concerns a method for organizing
a gathering. Through this method, a rally point at a geographical
point in a venue is generating. Selected contacts from a remote
device associated with a user receive a transmission of the rally
geographic information to allow for subsequent meet ups.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] FIG. 1 illustrates a system for increasing customer
engagement, including venue notifications.
[0011] FIG. 2 is a method for sharing user information.
[0012] FIG. 3 is a method for providing notification to users.
[0013] FIG. 4 is a method for coordinating a meeting point at a
venue.
[0014] FIGS. 5A-D illustrate exemplary user interfaces for
implementing the methods described in the contexts of FIG. 2 and
FIG. 3.
[0015] FIG. 5A illustrates an exemplary user interface for
implementing privacy settings corresponding to particular
contacts.
[0016] FIG. 5B illustrates an exemplary user interface that
displays a notification message identifying that "James Moore" is
in a venue.
[0017] FIG. 5C illustrates an exemplary user interface that
displays a notification message identifying that multiple friends
of a user are in a venue.
[0018] FIG. 5D illustrates an exemplary user interface that
displays a notification message identifying that "Amy White" is in
a venue.
[0019] FIG. 6 illustrates an exemplary computing system that may be
utilized to implement one or more embodiments of the present
invention.
[0020] FIGS. 7A-F illustrate exemplary user interfaces for
implementing the described in the context of FIG. 4.
[0021] FIG. 7A illustrates an exemplary user interface with a map
view that identifies an optimal rally point, a user location, and
locations of several contacts.
[0022] FIG. 7B illustrates an exemplary user interface with a map
view that identifies a moved rally point.
[0023] FIG. 7C illustrates an exemplary user interface with a map
view that identifies options for scheduling a rally time.
[0024] FIG. 7D illustrates an exemplary user interface that
displays a rally point invitation.
[0025] FIG. 7E illustrates an exemplary user interface with a map
view that identifies options for accepting an identified rally time
or proposing an alternative rally time.
[0026] FIG. 7F illustrates an exemplary user interface allowing a
user to set a reminder to trigger when the user needs to begin
travelling to the rally point.
DETAILED DESCRIPTION
[0027] The present invention includes a web service platform to
improve end-user engagement in a captive audience environment.
Mobile and web-based clients enable application users to authorize
and communicate their locations with other individuals within the
closed environment. Communication may include methods for forming
rally points and generating notifications concerning friend arrival
and departure.
[0028] FIG. 1 illustrates a system 100 for increasing customer
engagement, including customer monetization. The system 100 of FIG.
1 includes an ecosystem of data sources 105 such as mobile devices
110, point-of-sale (POS) terminals 115B or point-of-entry/-exit
(POE) terminals 115A, and databases 120. Communicatively coupled to
data sources 105 are back-end application servers 125. In system
100, application servers 125 can ingest, normalize and process data
collected from mobile devices 110 and various POS terminals 115B or
POE terminals 115A. Types of information gathered from data sources
105 and processed by back-end application servers 125 are generally
inclusive of identity (e.g., user profiles, CRM data, entitlements,
demographics, reservation systems and social media sources like
Pinterest and Facebook), proximity (e.g., GPS and beacons), and
time (e.g., schedules, weather, and queue length).
[0029] Mobile devices 110 can execute an application on a user
mobile device that shares customer engagement data such as current
and prior physical locale within a venue as well as wait times and
travel times (e.g., how long was a customer at a particular point
in a venue and how long did it take the customer to travel to a
further point in a venue). Mobile devices 110 are inclusive of
wearable devices. Wearable devices (or `wearables`) are any type of
mobile electronic device that can be worn on the body or attached
to or embedded in clothes and accessories of an individual.
Processors and sensors associated with a wearable can gather,
process, display, and transmit and receive information.
[0030] POS data may be gathered at a sales terminal 115B that may
interact with a mobile or wearable device 110 to track customer
purchase history at a venue or preference for engagement at a
particular locale within the venue. POE terminals 115A may provide
data related to venue traffic flow, including entry and exit data
that can be inclusive of time and volume. POE terminals 115A may
likewise interact with mobile and wearable devices 110.
[0031] Historical data may also be accessed at databases 120 as a
part of the application server 125 processing operation. The
results of a processing or normalization operation may likewise be
stored for later access and use. Processing and normalization
results may also be delivered to front-end applications (and
corresponding application servers) that allow for the deployment of
contextual experiences and provide a network of services to remote
devices as is further described herein.
[0032] The present system 100 may be used with and communicate with
any number of external front-end devices 135 by way of
communications network 130. Communication network 130 may be a
local, proprietary network (e.g., an intranet) and/or may be a part
of a larger wide-area network. Communication network 130 may
include a variety of connected computing device that provide one or
more elements of a network-based service. The communications
network 130 may include actual server hardware or virtual hardware
simulated by software running on one or more actual machines
thereby allowing for software controlled scaling in a cloud
environment.
[0033] Communication network 130 allows for communication between
data sources 105 and front-end devices 135 via any number of
various communication paths or channels that collectively make up
network 130. Such paths and channels may operate utilizing any
number of standards or protocols including TCP/IP, 802.11,
Bluetooth, GSM, GPRS, 4G, and LTE. Communications network 130 may
be a local area network (LAN) that can be communicatively coupled
to a wide area network (WAN) such as the Internet operating through
one or more network service provider.
[0034] Information received and provided over communications
network 130 may come from other information systems such as the
global positioning system (GPS), cellular service providers, or
third-party service providers such as social networks. The system
100 can measure location and proximity using hardware on a user
device (e.g., GPS) or collect the data from fixed hardware and
infrastructure such as Wi-Fi positioning systems and Radio
Frequency ID (RFID) readers. An exemplary location and proximity
implementation may include a Bluetooth low-energy beacon with real
time proximity detection that can be correlated to
latitude/longitude measurements for fixed beacon locations.
[0035] Additional use cases may include phone-based, GPS, real-time
location (latitude/longitude) measurements, phone geo-fence-real
time notifications when a device is moving into or out of location
regions, Wi-Fi positioning involving user location detection based
on Wi-Fi signal strength (both active or passive), RFID/Near Field
Communication (NFC), and cellular tower positioning involving wide
range detection of user device location, which may occur at the
metro-level.
[0036] Front-end devices 135 are inclusive of kiosks, mobile
devices, wearable devices, venue devices, captive portals, digital
signs, and POS and POE devices. It should be noted that each of
these external devices may be used to gather information about one
or more consumers at a particular location during a particular
time. Thus, a device that is providing information to a customer on
the front-end (i.e., a front-end device 135) such as a mobile
device executing an application or a specially designed wearable
can also function as a data source 105 as described above.
[0037] The system 100 of FIG. 1 provides services to connect venue
management with visitors and entertainment consumers while
simultaneously providing a messaging platform for consumers. For
example, the social network of a consumer may be extended into a
map and the physical world associated with the map. Services to
extend the social network of a user include finding friends,
coordinating rally points, management of proximity based parental
controls, friend arrival and departure, and customization and
sharing of photos. Venue management may provision consumers with
badges, points and rewards, coordinate scavenger hunts and
competitions, and provide leaderboard and trivia services.
Consumers may also be engaged by collecting feedback and reviews of
their experiences, managing favorites and wish lists, conducting
surveys and interactive voting, and through the display of
messages.
[0038] FIG. 2 is a method for sharing user information. The method
200 of FIG. 2 may be executed in a system 100 like that described
in the context of FIG. 1. FIG. 1 illustrates a number of mobile
devices such as handsets and wearables (110), application service
platforms (125), and third-party systems (like those used in
communications network 130). The foregoing devices, platforms, and
systems are exemplary. The concepts of sharing information as set
forth herein may be implemented in any number of devices, machines,
and platforms. In some instances, the application service platform
125 may operate in conjunction with a mobile application or mobile
interface on a user mobile device or wearable (110).
[0039] Returning to the method (200) of FIG. 2, an account may be
created at step 210. In some instances, an end user may create an
account that is hosted by a web service platform as might be
running at application service platform 125 or operating in
conjunction with a mobile device or wearable 110. A user account
may be configured during account creation to opt-in for various
system notifications at step 220. A user may opt-in to allow the
service to notify them when certain events occur. For example, a
user may opt-in for notifications related to events associated with
other users. Such an event might be when other end-users of the
service (e.g., friends) enter a geo-fence of the venue.
[0040] The identity of friends that would trigger such a
notification may be manually created or derived from a "friends
list" as might exist in various forms of social media accounts such
as Facebook, Instagram, or Twitter. The specifics of a geo-fence
can also be defined at this stage. The geo-fence may be related to
the entire venue, general geographic areas or "lands" within a
venue, or specific geographical points or points-of-interest such
as specific rides, vendors, or even specific GPS coordinates. The
opt-in step 220 may also allow the user to provide for
notifications to be sent to other users of the system 100
concerning passage in or from certain geo-fences. More
specifically, User A can configure the system 100 by way of method
200 to receive notifications when Users B and C enter a particular
venue. User A can also allow the system 100 to provide for
notifications to Users B and C (or perhaps just User B) when User A
arrives at the venue or portions thereof. In this regard, the user
can set up certain privacy controls to permit certain users to have
notifications and deny such notifications to other users, even if
those other users are desirous of receiving the same.
[0041] During the method 200 of FIG. 2, an end user may also
authorize the system 100 (or at least application server 125) to
access an address book or other contacts list (such as a social
network) at step 230. The address book may be stored on a mobile
device or accessible on a cloud network or through a third-party
service provider. In some instances, the user may be required to
provide credentials to the third-party service provider to allow
for access by system 100 and server 125. Allowing for address book
access may allow for further notifications to be generated or
provided. Address book access may, therefore, occur prior to or in
conjunction with the generation or allowance for various
notifications in step 210.
[0042] Granting access to an address book at step 230 is optional.
Generating and/or allowing for certain notifications at step 220 is
likewise optional. While generating notifications or allowing for
address book access is optional, denying such access may affect the
overall functionality of generating and/or receiving certain venue
notifications.
[0043] Should a user grant access at step 230, the application
running on the mobile device 110 or application server 125
downloads or otherwise accesses certain address book information at
step 240. The application server 125--alone or in conjunction with
mobile device 110 and any corresponding web or mobile
application--may attempt to match contacts with other users who
have granted similar access to system 100. Matching may occur
through the use of phone numbers, email addresses, social network
IDs, or instant messaging IDs.
[0044] A user may--in a manner similar to granting address book
access at step 230--grant social network access at step 250. When a
social network service is linked to the system 100, the end-user
may authorize the application server 125--alone or in combination
with a mobile or web application at mobile device 110--to import
social network contact information at step 260. As noted above,
granting access to various accounts and importing of data from
those accounts may occur in various orders or concurrently with
other operations of the method 200 of FIG. 2 (e.g., concurrent with
notification set up at step 220). When the platform operating at
application server 125 imports social network contacts, certain
relationships may be verified relationships such as parent and
child, husband and wife, and then associated with information
derived from an address book contact list.
[0045] Further contact or social network matching may occur at step
270. After importing all contacts and social network information
(should such access be granted) or otherwise manually entered, the
web service executing at application server 125 will compare the
imported information to identify end users who know each other.
Step 280 may allow for a user to set, reconfigure, or otherwise
eliminate certain privacy settings that may be necessary following
the matching operation at step 270.
[0046] FIG. 3 is a method 300 for providing notification to users.
The method 300 of FIG. 3 may occur in the context of a system (100)
like that of FIG. 1. A user may enter a venue at step 305 in FIG.
3. The venue may be stadium, theme park, or other area defined by a
geographic region. Said venue may have implemented a system (100)
like that illustrated in FIG. 1. The end user location may be sent
to a web service platform as may be running at application server
125 at step 310. The location may be received and stored by the
application server 125 and corresponding web service platform.
[0047] For each contact that an end user imported into the web
service platform, the end user can set privacy settings to specify
whether they want the contact to receive notifications when they
enter and leave the venue (e.g., steps 220 and 280 of FIG. 2) and
whether that contact can see the end user's location while they are
both inside the venue. An exemplary user interface for implementing
such privacy settings is illustrated in FIG. 5A. An end user may
update their particular privacy settings for any contact at any
time and not just during the contact import process as might
otherwise occur in the methodology described in FIG. 2.
[0048] A determination is made as to whether any user contacts on
the list are within the venue at step 315. The location of end user
can be determined by the mobile handset or a wearable device
calculating its location through on-device technology like
GPS/Wi-Fi, by sensors within the venue detecting the user entering
the venue and reporting location to web service platform operating
at application server 125, or through beacon technology such as
iBeacons interfacing between the mobile handset 110 and the web
service platform.
[0049] The web service platform may compare a contact list of the
end user to other users currently within the venue. If no user
contacts are inside the venue, the method of FIG. 3 may temporarily
end or suspend. The method of FIG. 3 may be subject to regular
polling to determine whether such a situation has changed. If
contacts of the user are in the venue as determined at step 315, a
determination may be made as to whether the contact is a mutual
connection at step 320. For each end user on the contact list (the
contact) of the end user entering the venue, web service platform
will perform a different workflow depending on whether the
connection is mutual (i.e., the end user and the contact are on
each on one another's contact lists and that end user authorized
the contact to be notified when end user enters the venue. If the
contacts are mutual connections as determined at step 320, the
method continues to step 325. If the contacts are not mutual
contacts, the method continues to step 350.
[0050] For mutual contacts, the web service platform sends a
message to the contact notifying them at end user has entered the
venue at step 325. The contact is added to a list of contacts
within the venue at step 330 so that a single message can be sent
to the mobile handset, tablet device, or wearable device of the end
user. If more contacts exist to be identified as mutual or not
mutual at step 335, the method returns to step 320. Hence, steps
320-330 are repeated for each of the user's contacts in the venue.
A single message is sent to end user listing all the mutual
contacts that are currently within the venue at step 340, and end
user can view the location of all contacts on a map at step 345
that authorized their location to be shared on the map. An example
user interface for this step on a mobile handset is shown in FIG.
5C. FIG. 5C illustrates how an end user would access a map view to
see where their mutual contacts are located on the map.
[0051] For contacts on an end user's contact list that do not have
a mutual connection and have been authorized by user to receive
notifications, a message is sent to the contact at step 350
informing them that the end user is within the venue and asking
them if they want to allow that user to be notified that they are
within the venue and/or view their location. An exemplary user
interface for this operation is shown in FIG. 5B.
[0052] If the contact authorizes the user at step 355, the message
is sent at step 340 to end user informing them that their contact
is within the venue. Additionally, the contact will now visible on
end user's map at step 345. An exemplary user interface for this
step is shown in FIG. 5D.
[0053] Embodiments of the present invention may check for end user
contacts on a user contact list at step 315. These checks may be
periodic. For example, they may occur while the user remains within
the venue in order to identify end user to additional contacts who
enter the venue after end user entered.
[0054] FIG. 4 is a method 400 for coordinating a meeting point at a
venue. The method 400 of FIG. 4 may be implemented by an end user
with a mobile handset, tablet device, or wearable device that
connect to a web service platform as might be executing at
application server 125 in conjunction with an application installed
on the mobile handset, tablet device, or wearable.
[0055] A shared map is displayed on a user handset or other mobile
device at step 405. End user may open the application on mobile
handset, tablet device, or wearable device and display a shared map
showing both end user's location and the location of all mutual
contacts within the venue. A rally point may be created at step
410. End user may, through an interface provided by a mobile device
application, provide input to create a rally point at any location
within the venue, at a selected point of interest, or an optimal
rally point based on the location of the end user and a selected
contact or contacts. The user may select the contacts at step 415
that the end user wants to meet at the rally point.
[0056] If the end user chooses the optimal rally point location,
travel time is calculated at step 420 by the web services platform,
the application running on the mobile device, or a combination of
the two. The rally point is the location that has equidistant
travel times for all users invited to the rally. Travel time takes
into account all transportation methods available to each contact
including walking times, movable walkways, elevators, and public
transit. An example user interface after an optimal rally point has
been created on a mobile device is shown in FIG. 7A.
[0057] If an end user creating the rally point provides input to
move the rally point location at step 425, new calculations are
performed to determine the arrival times of each invitee and
adjusting time of the rally at step 430. An example user interface
after the rally point has been moved is shown in FIG. 7B.
[0058] The end user creating the rally point can choose to schedule
the rally point for as soon as possible at step 435 or schedule for
a future time at step 440. An example user interface for selecting
the rally time as soon as possible or scheduled for a future time
is shown in FIG. 7C. After configuring the rally point location and
time, the end user may send the rally point to all invitees at step
445. Each invitee will receive a rally point message at step 450 on
their mobile device. An exemplary user interface rally point
invitation is shown in FIG. 7D.
[0059] Each recipient 720/750/755/760 can view the rally point time
725 and location on the map 730, directions to the rally point 780,
the current location of all other users invited to the rally, the
estimated travel time of each invitees 710 (including themselves
720), and whether each invitee has seen and accepted the rally
request. The invitee can choose to accept the rally at step 455,
reject the rally at step 455 and propose an alternate rally point
or time at step 465, or send a message to the rally creator at step
470. An example of this user interface is shown in FIG. 7E. In FIG.
7E, element 750 shows a user ("Jack") who has accepted the rally,
element 755 shows a user ("Alison") who has rejected the rally, and
element 760 shows a user ("Caren") who has not yet responded to the
rally.
[0060] If the invitee chooses to accept the rally at step 455, they
can set a reminder to rally at step 460. The reminder may be for
the number of minutes before they need to begin travelling to the
rally point that they should be reminded on their mobile device. An
exemplary user interface illustrating the same is shown in FIG.
7F.
[0061] If an invitee chooses to propose an alternate rally at step
465 the same workflow as the original rally point creation takes
place starting with calculating the optimal rally point location
and time at step 420. If the invitee accepts the rally at step 455,
their mobile device will display a reminder for them to attend the
rally at step 475 (head towards the rally point) at the specified
number of minutes before their current travel time to the rally
point. For instance, if an invitee is 10 minutes from the rally
point and has their reminder to rally set to 5 minutes, they would
receive the reminder 15 minutes before the scheduled rally time.
The timing of this reminder will take into account the end user's
current location and not the location where they accepted the
rally. This reminder message may be generated by either the
application running on the mobile device.
[0062] The method 400 discussed with respect to FIG. 4 allows large
groups of users to coordinate planning a meeting point taking into
account the location and travel time of each member of the group
without needing to ask each user explicitly. Further, this solution
allows all members of the group to easily know whether the other
members of the group have seen the meeting point request and
monitor their progress towards the meeting point without needing to
contact them directly to ask.
[0063] FIGS. 5A-D illustrate exemplary user interfaces for
implementing the methods described in the contexts of FIG. 2 and
FIG. 3.
[0064] FIG. 5A illustrates an exemplary user interface for
implementing privacy settings corresponding to particular
contacts.
[0065] FIG. 5B illustrates an exemplary user interface that
displays a notification message identifying that "James Moore" is
in a venue.
[0066] FIG. 5C illustrates an exemplary user interface that
displays a notification message identifying that multiple friends
of a user are in a venue.
[0067] FIG. 5D illustrates an exemplary user interface that
displays a notification message identifying that "Amy White" is in
a venue.
[0068] FIG. 6 illustrates an exemplary computing system that may be
utilized to implement one or more embodiments of the present
invention. System 600 of FIG. 6, or portions thereof, may be
implemented in the likes of client computers, application servers,
web servers, mobile devices, wearable devices, and other computing
devices. The computing system 600 of FIG. 6 includes one or more
processors 610 and main memory 620. Main memory 620 stores, in
part, instructions and data for execution by processor 610. Main
memory 620 can store the executable code when in operation. The
system 600 of FIG. 6 further includes a mass storage device 630,
portable storage medium drive(s) 640, output devices 650, user
input devices 660, a graphics display 670, and peripheral device
ports 680.
[0069] While the components shown in FIG. 6 are depicted as being
connected via a single bus 690, they may be connected through one
or more internal data transport means. For example, processor 610
and main memory 620 may be connected via a local microprocessor bus
while mass storage device 630, peripheral device port(s) 680,
portable storage device 640, and display system 670 may be
connected via one or more input/output (I/O) buses.
[0070] Mass storage device 630, which could be implemented with a
magnetic disk drive or an optical disk drive, is a non-volatile
storage device for storing data and instructions for use by
processor 610. Mass storage device 630 can store software for
implementing embodiments of the present invention, including the
method 200 described in the context of FIG. 2.
[0071] Portable storage medium drive(s) 640 operates in conjunction
with a portable non-volatile storage medium such as a flash drive
or portable hard drive to input and output data and corresponding
executable code to system 600 of FIG. 6. Like mass storage device
630, software for implementing embodiments of the present invention
(e.g., method 200 of FIG. 2) may be stored on a portable medium and
input to the system 600 via said portable storage.
[0072] Input devices 660 provide a portion of a user interface.
Input devices 660 may include an alpha-numeric keypad, such as a
keyboard, for inputting alpha-numeric and other information, or a
pointing device, such as a mouse. Input device 660 may likewise
encompass a touchscreen display, microphone, and other input
devices including virtual reality (VR) components. System 600
likewise includes output devices 650, which may include speakers or
ports for displays, or other monitor devices. Input devices 660 and
output devices 650 may also include network interfaces that allow
for access to cellular, Wi-Fi, Bluetooth, or other hard-wired
networks.
[0073] Display system 670 may include a liquid crystal display
(LCD), LED display, touch screen display, or other suitable display
device. Display system 670 receives textual and graphical
information, and processes the information for output to the
display device. In some instances, display system 670 may be
integrated with or a part of input device 660 and output device 650
(e.g., a touchscreen). Peripheral ports 680 may include any type of
computer support device to add additional functionality to the
computer system. For example, peripheral device(s) 680 may include
a modem or a router or other network communications implementation
(e.g., a MiFi hotspot device).
[0074] The components illustrated in FIG. 6 are those typically
found in computer systems that may be suitable for use with
embodiments of the present invention. In this regard, system 600
represents a broad category of such computer components that are
well known in the art. System 600 of FIG. 6 can be a personal
computer, hand held computing device, smart phone, tablet computer,
mobile computing device, wearable, workstation, server,
minicomputer, mainframe computer, or any other computing
device.
[0075] System 600 can include different bus configurations, network
platforms, processor configurations, and operating systems,
including but not limited to Unix, Linux, Windows, iOS, Palm OS,
and Android OS. System 600 may also include components such as
antennas, microphones, cameras, position and location detecting
devices, and other components typically found on mobile devices. An
antenna may include one or more antennas for communicating
wirelessly with another device. An antenna may be used, for
example, to communicate wirelessly via Wi-Fi, Bluetooth, with a
cellular network, or with other wireless protocols and systems. The
one or more antennas may be controlled by a processor, which may
include a controller, to transmit and receive wireless signals. For
example, processor execute programs stored in memory to control
antenna transmit a wireless signal to a cellular network and
receive a wireless signal from a cellular network. A microphone may
include one or more microphone devices which transmit captured
acoustic signals to processor and memory. The acoustic signals may
be processed to transmit over a network via antenna.
[0076] FIGS. 7A-F illustrate exemplary user interfaces for
implementing the described in the context of FIG. 4.
[0077] FIG. 7A illustrates an exemplary user interface with a map
view that identifies an optimal rally point, a user location, and
locations of several contacts.
[0078] FIG. 7B illustrates an exemplary user interface with a map
view that identifies a moved rally point.
[0079] FIG. 7C illustrates an exemplary user interface with a map
view that identifies options for scheduling a rally time.
[0080] FIG. 7D illustrates an exemplary user interface that
displays a rally point invitation.
[0081] FIG. 7E illustrates an exemplary user interface with a map
view that identifies options for accepting an identified rally time
or proposing an alternative rally time.
[0082] FIG. 7F illustrates an exemplary user interface allowing a
user to set a reminder to trigger when the user needs to begin
travelling to the rally point.
[0083] The foregoing detailed description of the technology herein
has been presented for purposes of illustration and description. It
is not intended to be exhaustive or to limit the technology to the
precise form disclosed. Many modifications and variations are
possible in light of the above teaching. The described embodiments
were chosen in order to best explain the principles of the
technology and its practical application to thereby enable others
skilled in the art to best utilize the technology in various
embodiments and with various modifications as are suited to the
particular use contemplated. It is intended that the scope of the
technology be defined by the claims appended hereto.
* * * * *