Patent Application
20180150920
Today, airline and other travel passengers are inundated with announcements in terminals and boarding areas, especially during the boarding process. Between those needing special assistance, different classes, upgrades and late seat assignments, loyalty levels affinity credit card memberships, premium options, and many general boarding groups or zones, the number of announcements can be overwhelming, confusing, inefficient, and certainly not very personal.
Various embodiments herein each include at least one of systems, methods, and software for silent announcements. One embodiment is in the form of a method that includes receiving an update on a mobile device of a mobile document data item for a mobile document present on the mobile device and generating a notification via the mobile device.
Another method embodiment includes receiving, via a network from a data source, a dynamic mobile document generation request including data identifying a transmission mode for transmitting a dynamic mobile document to be generated, a network identifier of where to send the generated dynamic mobile document, and at least one data item to be included in the dynamic mobile document when generated and to uniquely identify the dynamic mobile document. This method further includes storing data of the dynamic mobile document generation request in a database and generating the dynamic mobile document including the at least one data item and metadata defining the at least one item as a dynamic data item within the generated dynamic mobile document from which a notification is to be generated on a mobile device. The method may then transmit, via the network, the generated dynamic mobile document according to the identified transmission mode to a network destination of the network identifier.
A further embodiment is in the form of a device that includes a processor, a memory, a network interface, and instructions stored in the memory that are executable by the processor to perform data processing activities. The data processing activities in some embodiments include receiving an update on a mobile device of a mobile document data item for a mobile document present on the mobile device and generating a notification via the mobile device.
Various embodiments herein each include at least one of systems, methods, and software for silent announcements. Some such silent announcement embodiments leverage the enterprise ticketing solutions of travel providers, such as airlines, to deliver boarding invitations to passengers via their mobile devices (e.g., smart phones, smartwatches, tablets).
An example embodiment includes a passenger checking in for a flight and opting to have a mobile boarding pass delivered to their mobile device, such as within a mobile device app, by email or text message, or a link in an email or text message from which to download the boarding pass. The passenger may also opt in or be automatically designated for “silent boarding” or other silent announcements. An opt-in may be included in some embodiments to alleviate any privacy concerns related to silent notifications, but may also register the mobile boarding pass for silent boarding and other silent announcements, if not already set.
In this embodiment, the airline may control, through configuration settings, how silent boarding is administered. In some embodiments, only certain flights or even certain passenger types may be enabled, allowing the airline to restrict the number of participants, thereby reducing confusion and congestion as well as adding a premium aspect to the passenger experience.
The mobile boarding pass data may be delivered to the passenger via a central server. The method for delivery may be SMS, email, or through mobile application code embedded in a smartphone or other mobile device app.
The central server may expose an Application Programming Interface (API) for an airline to call one or more boarding passes to board.
In some embodiments, at the boarding gate, prior to departure, the airline system (either automatically or manually) may send a request to the central server API requesting that a silent boarding notification be sent. This notification can be scheduled by either the airline system or the boarding pass central server. However, due to the practical implications of flight delays it may be more common and prudent that the actual request time, or scheduling, be handled by the requesting party (e.g., the airline) or be triggered by application logic upon a change in flight status to a certain status or other data event.
In some embodiments, the airline can associate one or more boarding passes with a silent boarding or silent announcement call via a number of methods, such as by a boarding pass identification number, a frequent flyer number, other unique passenger data contained on the boarding pass, or a unique flag, code, or other value tagged to the pass.
In some embodiments, when the central server receives a silent boarding or other announcement request, the corresponding mobile boarding passes are updated to display a YOU ARE WELCOME TO BOARD indicator, such as by leveraging a dynamic mobile document functionality as described elsewhere herein. The boarding pass may also display a different image to distinguish it from the “normal” idle boarding pass state, where the image may indicate the passenger is authorized to board.
In such embodiments, the mobile boarding pass is updated at the central server and the passenger is notified via the same method as they previously received their pass. For example, if the passenger originally checked in for a flight and received a link to view the boarding pass via SMS message, the silent announcement notification will appear as a new SMS message. When the passenger clicks the link, the new boarding pass is retrieved and displayed. The SMS may also say include additional details with regard to the announcement, such as “YOU ARE WELCOME TO BOARD.” In a similar way, a boarding pass may be synced between a mobile app and the central server to be dynamically updated. In such embodiments, the mobile app may be responsible for notifying the passenger.
In some embodiments, an airline agent at a gate door can visibly distinguish between invitees and non-invitees by the look of their respective passes, such as by a changed color or an icon presented on the boarding pass. The rest of the boarding pass may functions as usual. For instance, the passenger or agent can still scan a barcode on the boarding pass prior to gaining admittance to the aircraft.
In typical embodiments, the silent announcement API is flexible enough to allow the airline or other travel service provider to offer boarding to select groups of passengers en masse. For instance, all First Class passengers or all elite passengers may receive an invitation triggered by a single API request. The key in such embodiments is that only passengers holding mobile boarding passes linked to the central server will be capable of receiving the updates and invitations.
These and other embodiments are described herein with reference to the figures.
In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific embodiments in which the inventive subject matter may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice them, and it is to be understood that other embodiments may be utilized and that structural, logical, and electrical changes may be made without departing from the scope of the inventive subject matter. Such embodiments of the inventive subject matter may be referred to, individually and/or collectively, herein by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed.
The following description is, therefore, not to be taken in a limited sense, and the scope of the inventive subject matter is defined by the appended claims.
The functions or algorithms described herein are implemented in hardware, software or a combination of software and hardware in one embodiment. The software comprises computer executable instructions stored on computer readable media such as memory or other type of storage devices. Further, described functions may correspond to modules, which may be software, hardware, firmware, or any combination thereof. Multiple functions are performed in one or more modules as desired, and the embodiments described are merely examples. The software is executed on a digital signal processor, ASIC, microprocessor, or other type of processor operating on a system, such as a personal computer, server, a router, or other device capable of processing data including network interconnection devices.
Some embodiments implement the functions in two or more specific interconnected hardware modules or devices with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the exemplary process flow is applicable to software, firmware, and hardware implementations.
The mobile wallet item 102 includes several elements, some of which may be dynamic. One element is the “GoFast Airlines” header or logo. There are also three other dynamic elements 104, 106, 108 of the mobile wallet item 102, although other mobile wallet items and other mobile documents may include only one dynamic element or many dynamic elements. The dynamic elements of the mobile wallet item include a barcode 104, flight information 106, and an indicator 108 of when the mobile wallet item 102, or one or more of the dynamic elements therein, was last updated. In some embodiments, the indicator 108 may not be visible, but instead utilized by an update process of a mobile wallet app to determine when to check for updates to the mobile wallet item 102, such as every fifteen minutes, every two hours, daily, or another period. The refresh period for the mobile wallet item 102 may be specified within a mobile wallet or other app used to view the mobile wallet item 102, within metadata 102M of the mobile wallet item, within metadata 104M, 106M of one or more dynamic elements 104, 106, or multiple such locations. Regardless, the dynamic elements 104, 106 are data items that can change over time while the mobile wallet item 102 resides on a mobile device.
The mobile wallet item 102 may also include a status indicator portion that may indicate the mobile wallet item 102 is now authorized for boarding a plane, entering a theater, other action. The status indicator may be one or both of text and a graphical element, such as an icon, a background or foreground color, an image, and the like. The status indicator, depending on the status and the mobile app, may trigger a silent notification on the mobile device, such as a sound, a mobile device notification, and the like.
Mobile wallet items 102, such as travel boarding passes as illustrated or movie tickets, sporting event tickets, and the like, often involve underlying data that may change. Airport gate assignments, flight status, boarding times, sporting event start times and weather delays, seat assignments, theater complex theater assignments, and the like may change and static mobile wallet items are unable to accommodate such changes, thereby requiring new static mobile wallet items be issued and obtained or replace paper items be generated and provided. The various embodiments herein allow for the dynamic elements 104, 106, as well as a status indicator as discussed above, to be updated or for the entire mobile wallet item 102 to be updated. The updates may occur in different embodiments in different ways. For example, a mobile wallet app may include code that operates to refresh data of dynamic elements 104, 106 by retrieving updated data from one or more data sources as identified within metadata 102M, 104M, 106M of a mobile wallet item or as may be transmitted thereto. In other embodiments, one or more other apps may feed updated data to the mobile wallet app.
In some embodiments, metadata 102M, 104M, 106M underlies one or more of the mobile wallet item 102 and dynamic elements 104, 106. The metadata may define how the data is to be presented, notification to provide, link the data of the respective dynamic element to a callable application programming interface (API), web service, or other network location from which an update to the respective data may be requested, set the refresh period, and other purposes.
The operator system 212 is an example of a system implemented by an operator of a service or facility for which a dynamic mobile document, such as the mobile wallet item 102 of
The consumer devices 220, 222 may include one or both of an operator app 220 and a wallet app 222. The operator app 220 is a mobile device app that communicates over the network 208 with one or both of the operator system 212 and the cloud service provider system to request and receive dynamic mobile documents and updates to to dynamic elements thereof. The operator app 220 may store and present dynamic mobile documents and also provide them to the wallet app 222. The wallet app 222 may receive dynamic mobile documents and store and present them. Dynamic mobile documents may also be received via email, text message, and other electronic means in some embodiments which may then be imported to one or both of the operator app 220 and the wallet app 222. The operator app 220 and the wallet app 222 may also request and receive dynamic mobile document updates from one or both of the operator system 212 and cloud service provider system 214. Silent notifications may also be provided based on mobile document updates received from one or both of the operator system 212 and cloud service provider system 214. Note that some mobile documents may also include dynamic elements with data sourced from other network 208 locations, such as weather data which may be requested and received from a weather service provider (not illustrated), destination guide data sources (not illustrated), advertising content providers (not illustrated), and other data sources. Silent notifications may also be provided on consumer devices 220, 222 based on data received from data sourced from the other network 208 locations.
Although the operator system 212 and the cloud service provider system 214 are illustrated as separate and distinct systems, these systems may be combined into a single system in some embodiments. Further, in some embodiments, the cloud service provider system 214 is operated by a third-party and is a multi-tenant system providing services for a plurality of operator system 212. In other embodiments, the cloud service provider system 214 is operated by the same entity as the operator system 212.
The first process flow diagram 1, as mentioned above, 1 illustrates an example embodiment of a process whereby a mobile device app requests a dynamic mobile document from a service provider. The mobile device app sends a request for a mobile document to the service provider. The service provider then retrieves and generates data for the requested mobile document and sends the data to the dynamic server. The dynamic server then stores the mobile document data, generates the mobile document including a barcode (e.g., a Quick Response code, standard one-dimensional barcode) when needed for the document-type requested, and sends the generated mobile document to the requesting mobile device app. Based on the data in the particular mobile document, the mobile device app may generate a silent notification via the mobile device. Note that the silent notification is silent in the sense that the notification is provided without an announcement made from a PA system in an airport terminal or in a gate area. The silent notification is instead provided on the mobile device, which may include an audible notification based on the particular mobile device, mobile device app, notification to be provided, and configurations thereof. Further note, however that sending the mobile document to the mobile device app may include sending a link in an email, text message, in-app message, and the like or an image of the mobile document. In some embodiments, the dynamic servicer may return the generated mobile document to the service provider for relay back to the mobile device app.
The second process flow diagram 2, as mentioned above, illustrates an example embodiment of a process through which the mobile device app receives an update to a dynamic mobile document pushed by the service provider. Over time, data from which the mobile document was generated may change. For example, when the mobile document is an airline service boarding pass, the gate assignment for boarding of the flight may change on the service provider system. The service provider system will send the updated data to the dynamic servicer. The data sent to the dynamic servicer may not identify individual boarding passes to receive the update, but instead include sufficient data to identify the flight, such as a flight date, flight number, departure airport, and arrival airport plus a data representation of the newly assigned gate. The data sent to the dynamic servicer may be further refined by identifying a loyalty status of passengers to receive a notification, seat row numbers, or even specific seat numbers and boarding pass identification numbers. As the dynamic servicer stores the data from which it generates the mobile documents are generated, the dynamic servicer is then able to identify to which mobile device app instances the mobile document has been sent within that data and then provide the update appropriately. Thus, when the dynamic servicer receives a data update from the service provider, the dynamic servicer stores the updated data, identifies to whom the update is to be provided when not specified in the received data, and generates and sends the update to one or more mobile devices apps, which as mentioned above may instead be text messages, emails, in-app messages, and the like. Silent notifications may be generated on the mobile devices based on data included in the updates.
The third process flow diagram 3 illustrates an example embodiment of a process through which a mobile device app requests, or pulls, an update to a dynamic mobile document from the service provider. This process flow begins with the mobile device app requesting an update to a mobile document, either as a whole or with regard to one or more specific dynamic elements included in the mobile document. The update request is sent to the service provider. The service provider then retrieves the requested data when the data has been updated since the mobile document was generated and sends the data to the dynamic servicer. The dynamic servicer then generates the mobile document update, stores the updated data, and sends the mobile document update to the mobile device app. Silent notifications may then be generated on the mobile devices based on data included in the updates.
In some embodiments, the method 400 includes receiving 400, via a network, a dynamic mobile document request associated with a registered user and including a token associated with data to be included in the dynamic mobile document. The method 400 further includes retrieving 404 data for the dynamic mobile document from a database based at least in part on the token and an identifier of the registered user. Retrieving 404 the data for the dynamic mobile document may also include generating and deriving data in some embodiments. The method 400 then continues by transmitting, via the network, the retrieved dynamic mobile document data and data indicating how the dynamic mobile document is to be provided to the registered user to a dynamic mobile document generation service. The dynamic mobile document generation service is a network accessible service in some embodiments, that generates and provides the dynamic mobile document to the registered user, including updates from which silent notifications may be generated on a mobile device. Examples of the dynamic mobile document generation service include the cloud service provider system 214 of
In some embodiments of the method 400, at least one data item retrieved 404 from the database for the dynamic mobile document is subject to change. In some such embodiments, the method 400 further includes receiving, via the network from the dynamic mobile document generation service, a dynamic mobile document data update request including at least the token and retrieving at least a portion of the data for the dynamic mobile document from the database. The method 400 in such embodiments then transmits, via the network, at least the portion of the retrieved data for the dynamic mobile document to the dynamic mobile document generation service.
In some other embodiments of the method 400, at least one data item retrieved from the database for the dynamic mobile document is subject to change. The method 400 in such embodiments further includes identifying a change in the database to a data item included in at least one dynamic mobile document and retrieving the changed data and additional data to enable the dynamic mobile document generation service to identify all dynamic mobile documents impacted by the changed data. The method 400 in these embodiments then transmits the retrieved change data and the additional data via the network to the dynamic mobile document generation service to provide an update to a dynamic mobile document of at least one registered user. Depending on the one or more data items that have changed, the update to the mobile document may further include an indication for a mobile device app to generate a silent notification based on one or more of the updated data items.
In some embodiments of the method 400, the dynamic mobile document request is received 402 from a mobile device app of the registered user. Some such embodiments further include receiving, via the network from the mobile device app or a mobile wallet app of the registered user, a dynamic mobile document data update request including at least the token. These embodiments may then retrieve at least a portion of the data for the dynamic mobile document from the database and transmit, via the network, at least the portion of the retrieved data for the dynamic mobile document to the dynamic mobile document generation service to provide to the mobile device app or the mobile wallet app from which the request was received.
In some of these and other embodiments of the method 400, the dynamic mobile document is an airline boarding pass and the token is one or a combination of airline boarding pass data items that uniquely identify at least one of the airline boarding pass and a flight associated therewith. In other embodiments, the dynamic mobile document is a ticket for admittance to a movie, a sporting event, or other event and the token is one or a combination of data items that uniquely identify the dynamic mobile document.
In some embodiments of the method 500, the metadata defining the at least one data item as a dynamic data item further includes metadata associating the respective at least one data item with a network service that is callable from a mobile device via the network to retrieve an update of the respective at least one data item. The metadata in such embodiments informs a refresh process of a mobile wallet app or one or more other apps on the mobile device of a network location or process that is callable to obtain the updated data or from which updated data may be pushed to the mobile device. The updated data in some embodiments may not be retrieved, but rather an indication of the dynamic data becoming outdated indicating that the user should select a link to obtain a new mobile wallet item to including the updated data.
In some embodiments of the method 500, the data identifying the transmission mode identifies at least one of a text message or email that includes a Universal Resource Identifier from which the dynamic mobile document may be retrieved, a mobile device in-app message that includes the dynamic mobile document or a URI from which an app will retrieve the dynamic mobile document, an email that includes the dynamic mobile document therein or as an attachment. In some such embodiments, the dynamic mobile document is viewable within at least one of a mobile wallet app, a mobile app, a web browser, an image viewing app, and a document viewing app.
In some embodiments of the method 500, the dynamic mobile document includes at least one dynamic data element and a date-time stamp including date and time data of when each of the at least one dynamic data elements was last updated in the dynamic mobile document.
In some other embodiments, the method 500 includes receiving, via the network from the data source, such as the operator system 212 of
Another embodiment of the method 500 includes receiving, via the network from a mobile device, a dynamic mobile document update request including data uniquely identifying the dynamic mobile document to be updated and retrieving each of the at least one updated mobile document data items for the dynamic mobile document from the database based at least in part on the data uniquely identifying the dynamic mobile document to be updated. The method 500 in such embodiments then transmits, via the network, the retrieved at least one updated mobile document data item to the mobile device.
In another embodiment of the method 500, the received 502 dynamic mobile document generation request is a request to generate a dynamic mobile boarding pass for a transportation service segment. In such embodiments, the at least one data item to be included in the dynamic mobile document when generated and to uniquely identify the dynamic mobile document includes a transportation segment identifier, a boarding time, and a departure time. In some such embodiments, an update of the at least one dynamic mobile document data item includes an update with regard to at least one of the transportation segment identifier, the boarding time, and the departure time. In some such embodiments, the method 500 further includes, upon receipt of the update of the at least one of the transportation segment identifier, the boarding time, and the departure time, identifying all generated dynamic mobile documents for which data is stored in the database in association with the travel segment for which the update pertains. Such embodiments then generate and transmit, via the network, a dynamic mobile document update to the network destinations stored in the database to which the dynamic mobile documents were transmitted.
The method 600 includes receiving 602 an update on a mobile device of a mobile document data item for a mobile document present on the mobile device and generating 604 a notification via the mobile device. The notification may include one or more of a visual, audio, and tactile output. In some embodiments the update includes data indicating a user of the mobile device is authorized to enter an area or board a vehicle. In such embodiments, the method 600 may further include presenting a view on a display of the mobile device including a visual indicator indicating the user is allowed to enter the area or board the vehicle.
Returning to the computer 710, memory 704 may include volatile memory 706 and non-volatile memory 708. Computer 710 may include—or have access to a computing environment that includes a variety of computer-readable media, such as volatile memory 706 and non-volatile memory 708, removable storage 712 and non-removable storage 714. Computer storage includes random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD ROM), Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.
Computer 710 may include or have access to a computing environment that includes input 716, output 718, and a communication connection 720. The input 716 may include one or more of a touchscreen, touchpad, mouse, keyboard, camera, one or more device-specific buttons, one or more sensors integrated within or coupled via wired or wireless data connections to the computer 710, and other input devices. The computer 710 may operate in a networked environment using a communication connection 720 to connect to one or more remote computers, such as database servers, web servers, and other computing device. An example remote computer may include a personal computer (PC), server, router, network PC, a peer device or other common network node, or the like. The communication connection 720 may be a network interface device such as one or both of an Ethernet card and a wireless card or circuit that may be connected to a network. The network may include one or more of a Local Area Network (LAN), a Wide Area Network (WAN), the Internet, and other networks. In some embodiments, the communication connection 720 may also or alternatively include a transceiver device, such as a BLUETOOTH® device that enables the computer 710 to wirelessly receive data from and transmit data to other BLUETOOTH® devices.
Computer-readable instructions stored on a computer-readable medium are executable by the processing unit 702 of the computer 710. A hard drive (magnetic disk or solid state), CD-ROM, and RAM are some examples of articles including a non-transitory computer-readable medium. For example, various computer programs 725 or apps, such as one or more applications and modules implementing one or more of the methods illustrated and described herein or an app or application that executes on a mobile device or is accessible via a web browser, may be stored on a non-transitory computer-readable medium.
It will be readily understood to those skilled in the art that various other changes in the details, material, and arrangements of the parts and method stages which have been described and illustrated in order to explain the nature of the inventive subject matter may be made without departing from the principles and scope of the inventive subject matter as expressed in the subjoined claims.
