Note: Descriptions are shown in the official language in which they were submitted.
INTEGRATED MANAGEMENT OF DISPARATE DATA FROM ISOLATED DATA SOURCES
TECHNICAL FIELD
[0001] The present application is related to data management systems, and
more specifically
to methods and systems of integrated management of disparate data from
isolated data sources.
BACKGROUND
[0002] Data resource management involves developing and executing
architectures, policies,
practices, and procedures that properly manage a full data lifecycle that
enhance the value of data
and information assets. A disparate system or a disparate data system includes
computer data
processing systems designed to operate as a fundamentally distinct data
processing system without
exchanging data or interacting with other computer data processing systems. A
disparate system is
often characterized as an information silo because of the data system's
isolation from or
incompatibility with any other data systems.
[0003] An information silo, or a group of such silos, is an insular
management system in
which one information system or subsystem is incapable of reciprocal operation
with others that are,
or should be, related. Thus information is not adequately shared but rather
remains sequestered
within each system or subsystem, figuratively trapped within a container like
grain is trapped within
a silo.
SUMMARY
[0004] Certain aspects of the invention involve integrating disparate data
sources retrieved
from an air traffic server and a ticket vendor server to derive air traffic
insights. An integrated
management server can be employed to extract, transform, and load data from
heterogeneous
sources into a single view schema so data from different sources become
compatible.
CA 3021282 2018-10-18
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 is a block diagram illustrating an integrated management
system, according to
various embodiments.
[0006] FIG. 2A is a block diagram illustrating a control server, according
to various
embodiments.
[0007] FIG. 2B is a block diagram illustrating components of the integrated
management
system, according to various embodiments.
[0008] FIG. 2C is a block diagram illustrating disparate data retrieved
from disparate data
sources, according to various embodiments.
[0009] FIG. 3 is a graphical illustration of a control server performing a
method, according to
various embodiments.
[0010] FIG. 4A is a graphical illustration of the control server providing
congestion premium
data to a graphical user interface, according to various embodiments.
[0011] FIG. 4B is a flow diagram illustrating a method of determining an
estimated
congestion delay function, according to various embodiments.
[0012] FIG. 4C is a simplified illustration of a congestion delay function
determined through
regression analysis, according to various embodiments.
[0013] FIG. 4D is a simplified illustration of a ticket acquisition
function determined through
regression analysis, according to various embodiments.
[0014] FIG. 5 is a flow diagram illustrating a sample process for managing
air traffic
congestion, according to various embodiments.
[0015] FIGS. 6A-6B are a flow diagram illustrating another sample process
for managing air
traffic congestion, according to various embodiments.
[0016] FIG. 7A illustrates taxi time functions for a runway having three
configurations,
according to various embodiments.
2
CA 3021282 2018-10-18
[0017] FIG. 7B illustrates a deviation between a taxi time function and an
unimpeded
function, according to various embodiments.
[0018] FIG. 7C illustrates a taxi time functions for a runway having three
configurations,
according to various embodiments.
[0019] FIG. 8 is a flow diagram illustrating a sample process for computing
airport usage
polynomials, according to various embodiments.
[0020] FIG. 9 is a flow diagram illustrating a sample process for
generating airport delay
polynomial tables, according to various embodiments.
[0021] FIG. 10 is a flow diagram illustrating a sample process for
extracting delay data
associated with a cause category, according to various embodiments.
[0022] FIG. 11 is a flow diagram illustrating a sample process for
computing a maximum slot
limit, according to various embodiments.
[0023] FIG. 12 is a flow diagram illustrating a sample process for
computing limits for a
delay function, according to various embodiments.
[0024] FIG. 13 is a diagrammatic representation of a machine in the example
form of a
computer system within which a set of instructions, for causing the machine to
perform any one or
more of the methodologies or modules discussed herein, may be executed.
[0025] The figures depict various embodiments of this disclosure for
purposes of illustration
only. One skilled in the art will readily recognize from the following
discussion that alternative
embodiments of the structures and methods illustrated herein may be employed
without departing
from the principles of the invention described herein.
DETAILED DESCRIPTION
[0026] Certain aspects of the technology disclosed involve integrated
management of
disparate data from isolated data sources. Application integration is an
integration framework
composed of a collection of technologies and services which form a middleware
or "middleware
framework" to enable integration of systems and applications. The various
systems that need to be
linked together may reside on different operating systems, use different
database solutions or
3
CA 3021282 2018-10-18
computer languages, or different date and time formats, or may be legacy
systems that are no longer
supported by the vendor who originally created them. In some cases, such
systems include
components compiled in a way that makes modification challenging.
[0027] Disparate systems can be located, for example, in a legacy aviation
server and a ticket
vendor server. The aviation server can include a technical architecture,
application architecture,
and/or data architecture that is incompatible with the ticket vendor server.
Likewise, the ticket
vendor server can include a technical architecture, application architecture,
and/or data architecture
incompatible with the aviation server.
[0028] An integrated management system can be employed to extract,
transform, and load
data from heterogeneous sources into a single view schema so data from
different sources become
compatible. For instance, the integrated management server retrieves
incompatible data from the
aviation server and the ticket vendor server. The integrated management server
transforms retrieved
data into a compatible format to enable large-scale data integration.
Integrated data from previously
disparate data sources can be analyzed to glean insights that would not be
possible without the
integration of the disparate data sources.
[0029] Embodiments of the disclosed technique can integrate disparate data
sources retrieved
from an aviation server and a ticket vendor server to derive air traffic
insights not previously
performable by a computing device. In an embodiment, an airport congestion
management method
and system can be used to reduce congestion delays. Embodiments include
querying an air traffic
database for air traffic data of an airport including schedules of a number of
flights utilizing a slot of
the airport. A slot may be a period of time for an aircraft to take-off or
land at the airport. A
congestion delay resulting from the number of flights utilizing the slot of
the airport may be
determined based on the air traffic data. A congestion delay target based on
an estimated time value
of a plurality of passengers may be selected. A utilization level of the slot
may be determined based
on the selected congestion delay target. A premium schedule database may be
updated to allocate
the congestion premium among tickets for one or more flights scheduled during
the slot. The
congestion premium may be provided to a ticket vendor server.
[0030] Embodiments may reduce congestion delays by altering passenger
ticket selection
patterns to conform to a determined utilization level of a runway for a period
of time (e.g., a slot
4
CA 3021282 2018-10-18
utilization level). Embodiments include obtaining ticket acquisition data over
a time period from a
ticket vendor server and reevaluating the congestion premium for the one or
more flights scheduled
during the slot based on the ticket acquisition data. The premium schedule
database may be updated
with the reevaluated congestion premium. The reevaluated congestion premium
may be provided to
the ticket vendor server.
[0031] A slot may be a half-hour time span in which an aircraft may be
permitted to conduct a
flight. Slots may be associated with an airline, airport, and time range. An
airline may have a right
to operate a flight in a slot. An airline may forfeit a right to operate a
flight in a slot. For example,
an airline may fail to operate a flight in a slot resulting in forfeiture. In
another example, a number
of passengers on flights in a slot (e.g., 11:00 am - 11:30 am slot) may fall
below a threshold (e.g.,
fifty percent) for a designated number of times (e.g., four consecutive days)
resulting in forfeiture.
In another example, an airline may elect to forfeit a slot (e.g., if ticket
purchases fall below a
threshold for a flight in a slot).
[0032] A number of flights within any time slot must be less than the
maximum capacity of
the airport. A congestion delay may be determined based on a number of flights
utilizing a
particular slot. A non-congestion related delay can include random variation
in process times caused
by, for example, weather, personnel delays, mechanical malfunctions, etc. Slot
management may
include controlling the number of flights per slot to reduce a congestion
delay resulting from the
number of flights utilizing a slot of an airport. A number of flights per slot
may be reduced by
disincentivizing ticket purchases for flights in the slot with a congestion
premium.
[0033] Congestion premiums may allow operational flexibility to meet flight-
to-flight
challenges while disincentivizing chronic congestion delays. Enacting
congestion management may
reduce a number of slots available for flights. Competition between passengers
for peak-time
service may increase as slots are taken out of service. Passengers willing to
pay more for peak-time
service may pay a congestion premium that may collect into an account
specifically targeted to
improving service at an airport. Some slots may be returned to service and
some slots may be
created from increased flight volume at non-congested times or from expanded
flight capacity
created from new airport infrastructure.
CA 3021282 2018-10-18
[0034] FIG. 1 is a block diagram illustrating an integrated management
system 100,
according to various embodiments. The integrated management system 100 may
include an air
traffic activity system (ATAS) server 104, control server 102, and ticket
vendor server 106.
[0035] The ATAS server 104 may contain air traffic operation data available
for public or
non-public release. The ATAS server 104 may be operated by the Federal
Aviation Administration.
The ATAS server 104 may contain data associated with historical, current, or
future air traffic
operations (e.g., scheduled air traffic data), or any combination of
historical, current, or future air
traffic operations. The air traffic operation data may include information
regarding a plurality of
flights utilizing a plurality of slots at a plurality of airports. For
example, the air traffic operation
data may indicate that six flights utilized a slot (e.g., 10:00 am - 10:30 am
slot) of runway 13R-31L
at John F. Kennedy International Airport on August 1, 2015. The ATAS server
104 may include an
interface 114 configured to communicate with an interface 112 of the control
server 102. The
ATAS server 104 may provide air traffic operation data to the control server
102 by utilizing
interface 114 to communicate the air traffic operation data to interface 112.
[0036] Ticket vendor server 106 may contain ticket data for public or non-
public release. The
ticket vendor server 106 may be operated by, for example, an airline or a
third-party ticket vendor.
The ticket data may include a number of tickets available for a number of
flights, a number of
tickets sold for a number of flights, a price of a number of tickets, or any
combination thereof. The
ticket data may include reference information, such as, for example, a date,
time, flight number, etc.
for the number of flights. The ticket vendor server 106 may include an
interface 116 configured to
communicate with an interface 122 of the control server 102. The ticket vendor
server 106 may
provide ticket data to the control server 102 by utilizing interface 116 to
communicate the air traffic
operation data to interface 122. The ticket vendor server 106 may receive data
associated with a
congestion premium from the control server 102 via interface 116.
[0037] Control server 102 may determine a congestion premium for tickets
for a number of
flights. Control server 102 may include databases (e.g., including data
received from one or more
other servers) at least one processor (e.g., a processor to determine a
congestion premium), at least
one interface to communicate with other server(s). The databases can include,
for example, an air
traffic database, ticket database, passenger time valuation database, and
premium schedule database.
6
CA 3021282 2018-10-18
The databases may be contained on separate physical memory devices within the
control server 102
or can be maintained in separate addresses of physical memory within the
control server 102.
Control server 102 may communicate with the ATAS server 104 and the ticket
vendor server 106.
Control server 102 may communicate with ATAS server 104 using, for example,
interface 112.
Control server 102 may communicate with ticket vendor server 106 using, for
example, interface
122. Control server 102 may receive ticket data from ticket vendor server 106
and transmit data
associated with a congestion premium for tickets of a number of flights to
ticket vendor server 106.
Embodiments of various elements within control server 102 are described below
with reference to
FIG. 2.
[0038] FIG. 2A is a block diagram illustrating the control server 102,
according to various
embodiments. Control server 102 may include at least one processor (e.g., to
determine a
congestion premium), databases (e.g., to store air traffic data and ticket
data), and interfaces (e.g., to
communicate with other servers). A processor (e.g., processor 250) may execute
a congestion
control application to manage the databases (e.g., air traffic database 210,
ticket database 230, etc.).
The congestion control application may be a computer program designed to
perform a group of
coordinated functions, including managing databases associated with the
control server 102. The
congestion control application may be designed to create, query, update, and
administer databases
(e.g., air traffic database 210) within or connected via an interface (e.g.,
interface 112, interface 122,
etc.) to the control server 102.
[0039] The control server 102 may include processor 250. Processor 250 may
be, for
example, a stand-alone central processing unit (CPU), one of a plurality of
specialized processors,
or one of a plurality of CPUs. For example, processor 250 may be part of a
multi-core processor,
where processors of the multi-core processor can carry out instructions at the
same time to increase
speed via parallel computing. In another example, processor 250 may be one
processor of a multi-
processor computer. In another example, processor 250 may be part of a
computer clustered with a
plurality of other computers to carry out computation in parallel. Due to
potentially large volumes
of air traffic data and ticket data, parallel computing (e.g., multiple
processors and/or multiple
computers performing operations synchronously) may enable computations to be
performed in a
reasonable time frame. In addition, determining a congestion premium may be an
iterative process
requiring feedback from the ticket vendor server 106 to reevaluate a
congestion premium. An
7
CA 3021282 2018-10-18
iterative process requiring computations for potentially many thousands of
flights may be
performed in parallel by utilizing multiple processors running in parallel to
enable computation in
near real time. Significant delays in computation may make integration of a
congestion premium
into a vendor server impractical or impossible. In addition, protracted
computation may make
performance of iterative reevaluation of a congestion premium impractical or
impossible. Thus,
embodiments enabling expeditious computations are preferred. The at least one
processor (e.g.,
processor 250) may carry out instructions (e.g., instructions 252) of a
congestion control program
by performing a series of operations specified by the instructions. The at
least one processor (e.g.,
processor 250) may fetch the instructions from a memory device and execute the
instructions by
directing coordinated operations between an arithmetic logic unit (ALU),
registers, and other
components.
[0040] The databases of the control server 102 may include, for example,
air traffic database
210, passenger time valuation database 220, ticket database 230, and premium
schedule database
240. The databases may be, for example, primary storage, secondary storage, or
tertiary storage.
The databases may include, for example, non-volatile memory, dynamic random-
access memory,
and/or static random-access memory. The databases may be included in a single
memory device or
a plurality of memory devices.
[0041] Air traffic database 210 may be an organized collection of air
traffic data 212 having a
data model that reflects the structure of the air traffic data 212. The
processor 250 may obtain air
traffic data from the ATAS server 104 via interface 112 and populate and/or
update the air traffic
database 210 with the obtained air traffic data. Populated and/or updated data
in air traffic database
210 may be referred to as air traffic data 212.
[0042] The air traffic data 212 may include data indicating a number of
flights associated
with a slot (or plurality of slots) at an airport (or a plurality of
airports). The air traffic data 212 may
indicate, for example, an actual and/or scheduled takeoff time, an actual
and/or scheduled landing
time, an actual and/or scheduled departure location, an actual and/or
scheduled arrival location, a
type of aircraft, passenger capacity, an actual and/or scheduled number of
passengers, crew details,
or any combination thereof. Air traffic database 210 may have a data model
that reflects a flight and
details associated with the flight (e.g., scheduled and actual takeoff time of
the flight, etc.).
8
CA 3021282 2018-10-18
[0043] Passenger time valuation database 220 may be an organized collection
of passenger
time valuation data 222 having a data model that reflects the structure of the
passenger time
valuation data 222. A passenger time valuation method may be implemented to
generate passenger
time valuation data 222. In an embodiment, some data may be extracted from the
air traffic database
210 (e.g., distance of travel) and some data may be extracted from the ticket
database 230 (e.g.,
ticket type). The congestion control application may extract passenger data
from the air traffic data
212 and the ticket database 230 to generate passenger time valuation data 222
in passenger time
valuation database 220. For example, data associated with a number of
passengers scheduled for a
flight may be extracted from the air traffic database 210 and included in a
passenger time valuation
model based on one or more variables such as, for example, trip purpose (e.g.,
business or personal
travel), identified characteristics of passenger (e.g., age, sex, education,
employment, income, etc.),
distance of travel, and ticket type (e.g., economy, business, first class,
etc.).
[0044] Ticket database 230 may be an organized collection of ticket data
232 having a
conceptual data model that reflects the structure of the ticket data 232. The
processor 250 may
obtain ticket data from a remote server (e.g., ticket vendor server 106) via
the interface 122 and
populate and/or update the ticket database 230. Populated and/or updated data
in ticket database 230
may be referred to as ticket data 232.
[0045] Ticket data 232 may include data indicating, for example, a number
of tickets sold for
a flight, number of tickets available for a flight, ticket value, taxes and/or
fees associated with a
ticket, characteristics of a passenger (e.g., age, sex, education, employment,
income, etc.) associated
with a ticket, trip purpose (e.g., business or personal travel), and ticket
type (e.g., economy,
business, first class, etc.). The processor 250 may periodically obtain ticket
data from the remote
server to update the ticket database 230. For example, the processor 250 may
request ticket data
from the remote server subsequent to an elapse of a time period (e.g., a
minute, several minutes,
hour, several hours, day, etc.). Updated ticket data 232 may be used in
iterative determinations
performed by the processor 250. For example, the processor 250 may reevaluate
a congestion
premium based on updated ticket data 232.
[0046] In an embodiment, additional information may be obtained from the
ticket vendor
server 106 (e.g., in the event the ticket vendor is an airline). The processor
250 may obtain
9
CA 3021282 2018-10-18
additional data from a remote server (e.g., ticket vendor server 106) via
interface 122 and populate
and/or update a database (e.g., ticket database 230) with the additional data.
The additional data
may include, for example, a number of crew members associated with a flight,
crew details (e.g.,
job title, working hours, experience level, etc.), etc.
[0047] Premium schedule database 240 may be an organized collection of
premium schedule
data 242 having a data model that reflects the structure of the premium
schedule data 242. A
premium schedule valuation method may be implemented to generate premium
schedule data 242.
The premium schedule valuation method may include determining a congestion
delay resulting
from a number of flights utilizing a slot of an airport, selecting a
congestion delay target based on
an estimated time value of a plurality of passengers (e.g., extracted from the
passenger time
valuation database 220), determining a utilization level of the slot based on
the selected congestion
delay target, and determining a congestion premium for flights scheduled
during the slot to achieve
the determined utilization level. Various embodiments of the premium schedule
valuation method
are described below with reference to FIGS. 5-6B. Premium schedule database
240 may be updated
to reflect the determined congestion premium. The congestion premium may be
allocated among
tickets for one or more flights scheduled during the slot. Premium schedule
data 242, including a
congestion premium allocated among tickets, may be provided to the ticket
vendor server 106 via
interface 112.
[0048] In an embodiment, the congestion premium may be periodically
reevaluated based on
updated data (e.g., ticket data 232) in one or more databases (e.g., ticket
database 230). For
example, ticket data 232 may be updated subsequent to providing the premium
schedule data 242 to
the ticket vendor server 106. Updated ticket data 232 may indicate, for
example, a number of tickets
sold in a time period (e.g., an hour) after implementation of the congestion
premium. Based on the
number of tickets sold in the period, the congestion premium may be
reevaluated. For example, if a
rate of ticket sales is less than needed to achieve the determined utilization
level, the congestion
premium may be reduced. In another example, if the rate of ticket sales is
more than needed to
achieve the determined utilization level, the congestion premium may be
increased. In an
embodiment, a change in a congestion premium may be reflected in a final
charge to a passenger
(e.g., by refunding the passenger for a subsequently reduced congestion
premium).
CA 3021282 2018-10-18
[0049] FIG. 2B is a block diagram illustrating components of the integrated
management
system, according to various embodiments. The integrated management system can
include an
interface 112 and/or another interface configured to query travel application
servers and/or travel
webpage 206. The interface 112 can iteratively retrieve ticket data for
analysis by a ticket node 234.
The ticket node 234 can determine acquisition information based on changes in
the ticket data
retrieved from by the interface 122 over various iterations. The ticket node
234 generates an
acquisition table 238. The ticket node 234 employs a customer relationship
management (CRM)
model to predict acquisition over time. Acquisition prediction can be based on
characteristics of a
number of customers, identified acquisition trends, adjustments to a premium,
or any combination
thereof.
[0050] A congestion node 260 can execute an aviation model to predict
congestion for an
airport having a particular configuration. An airport can have one or more
configurations. For
example, La Guardia Airport (LGA) operates in three typical configurations
that re-route aircraft
operations (e.g., takeoff and landing) to different runways. Different
configurations can result in
different congestion even with the same number of flight operations in a slot.
Predicting an airport's
configurations for a slot can greatly increase accuracy of likely congestion
from a number of flight
operations. Congestion node 260 can include an events table indicative of
flight operations, flight
duration, flight status, and premium status. Congestion node 260 can include a
premium table
indicative of a predicted premium to lower congestion to a target congestion.
[0051] FIG. 2C is a block diagram illustrating disparate data integrated
into a plurality of
tables, according to various embodiments. For example, ticket data can be
analyzed to determine
acquisition data (e.g., an acquisition rate of tickets, total ticket
acquisition, and ticket premium).
Acquisition data can be sorted and stored in an acquisition table 235. A
premium table 265 can
include an updated premium and a timestamp corresponding to a time stamp in
the acquisition table
235. The air traffic database 210 can be iteratively queried to identify
events and event changes.
Identified events and event changes can be sorted and stored in an events
table 205.
[0052] A parameters table can include a profile for each airport. The
airport profile can be
indicative of one or more airport configurations. The airport profile can
include cross-reference
information corresponding to configurations of other airports. Configurations
indicate aircraft
11
CA 3021282 2018-10-18
operation locations at an airport (e.g., where aircraft takeoff and land).
Some airports can
reconfigure to several operations (e.g., LGA can operate in three different
configurations). In an
example, a first configuration of LGA can be cross-referenced with a second
configuration at JFK
but not with any configuration at LAX. The cross-reference information can
include a probability of
alteration of a configuration at a particular airport upon a change of a
configuration at another
airport. The cross-reference information can be used to predict a particular
configuration for an
airport at a particular slot. The particular configuration during the slot can
be used to generate a
delay function (e.g., a delay polynomial). If a particular configuration is
less than a threshold level
of certainty, a delay function can be generated for a plurality of
configurations. A weighting (e.g., a
value between 0 and 1) corresponding to the probability of each configuration
can be associated
with each delay function. The weighting can be used to generate a weighted
average delay function
indicative of a delay from possible configurations.
[0053] FIG. 3 is a graphical illustration of the control server 102
providing congestion
premium data to a user device 302, according to various embodiments. In an
embodiment, control
server 102 may provide congestion premium data to the ticket vendor server
106, and the ticket
vendor server 106 may provide congestion premium data to the user device 302.
Although not
illustrated, embodiments also include control server 102 providing congestion
premium data
directly to the user device 302.
[0054] A user can interface with a browser and/or mobile application
executed by a user
device (e.g., user device 302) configured to connect to a flight search
engine. The browser and/or
mobile application can receive flight selections from the user. The browser
and/or mobile
application can generate a query and transmit the generated query to the
flight search engine (315).
[0055] The flight search engine can receive the query generated by the
browser and/or mobile
application. The flight search engine can execute a search query. The search
query can be
performed by mining data available in databases or open directories (e.g., one
or more generated
tables). The flight search engine can maintain real-time information by
running an algorithm on one
or more ticket vendor servers and one or more air traffic servers.
[0056] The user device 302 may include a graphical user interface
configured to generate one
or more graphical elements (e.g., congestion premium module 306) to display on
a display 304. The
12
CA 3021282 2018-10-18
graphical user interface may generate the congestion premium module 306
including a congestion
premium associated with a flight. For example, the congestion premium module
306 may indicate a
congestion premium of $107.95 associated with flight "6 Jammed Airlines" which
departs John F.
Kennedy International Airport ("JFK") at 9 PM Eastern Time and arrives at San
Francisco
International Airport ("SFO") at 12 AM Pacific Time. In another example, a
congestion premium
module may indicate a congestion premium of -$8.46 associated with flight "86
Jammed Airlines"
which departs JFK at 4 AM Eastern Time and arrives at SFO at 7 AM Pacific
Time. A congestion
premium determined for various slots throughout a day may vary based on a
reduction of a number
of flights necessary to achieve a utilization level for the various slots.
[0057] A user of the user device 302 may select a ticket for a flight
having a congestion
premium allocated to the ticket. The allocated congestion premium may be based
on a congestion
premium determined by the control server 102. For example, if the control
server 102 determines
that a congestion premium of $194,150 may achieve the determined utilization
level (e.g., 75% of
maximum runway capacity) for a slot (e.g., 11:00 AM - 11:30 AM) and 1,000
tickets are available
for flights during the slot, the control server 102 may allocate the
congestion premium among
available tickets. The control server 102 may allocate the congestion premium
evenly among tickets
or based on one or more other factors (e.g., ticket type, ticket price,
aircraft type of flight, leg room
available, etc.). For example, a congestion premium may be allocated evenly by
dividing a
congestion premium (e.g., $194,150) by a number of tickets available during a
slot (e.g., 1,000
tickets) to obtain an allocated congestion premium (e.g., a congestion premium
$194.15 per
available ticket). In another example, a congestion premium may be allocated
by aircraft type so
that tickets associated with an aircraft occupying a larger duration of
takeoff time are allocated a
proportionally larger portion of the congestion premium.
[0058] A positive congestion premium may result in fewer flights in a slot,
whereas a
negative congestion premium may result in more flights in a slot. For example,
the congestion
premium of $107.95 allocated to tickets for flights in a slot (e.g., 9 PM -
9:30 PM) may
disincentivize flights operating during the slot. In another example, the
congestion premium of -
$8.46 allocated to tickets for flights in a slot (e.g., 4:00 AM - 4:30 AM) may
incentivize additional
flights to operate during the slot.
13
CA 3021282 2018-10-18
[0059] Referring to FIGS. 1-3, physical and functional components (e.g.,
devices, engines,
modules, and databases, etc.) associated with the congestion server 102, the
ATAS server 104, the
ticket vendor server 106, and/or the user device 302 can be implemented as
circuitry, firmware,
software, other executable instructions, or any combination thereof For
example, the functional
components can be implemented in the form of special-purpose circuitry, in the
form of one or more
appropriately programmed processors, a single board chip, a field programmable
gate array, a
general-purpose computing device configured by executable instructions, a
virtual machine
configured by executable instructions, a cloud computing environment
configured by executable
instructions, or any combination thereof For example, the functional
components described can be
implemented as instructions on a tangible storage memory capable of being
executed by a processor
or other integrated circuit chip. The tangible storage memory can be computer
readable data
storage. The tangible storage memory may be volatile or non-volatile memory.
In some
embodiments, the volatile memory may be considered "non-transitory" in the
sense that it is not a
transitory signal. Memory space and storages described in the figures can be
implemented with the
tangible storage memory as well, including volatile or non-volatile memory.
[0060] Each of the components may operate individually and independently of
other
components. Some or all of the functional components may be executed on the
same host device or
on separate devices. The separate devices can be coupled through one or more
communication
channels (e.g., wireless or wired channel) to coordinate their operations.
Some or all of the
components may be combined as one component. A single component may be divided
into sub-
components, each sub-component performing separate method step or method steps
of the single
component.
[0061] In some embodiments, at least some of the components share access to
a memory
space. For example, one component may access data accessed by or transformed
by another
component. The components may be considered "coupled" to one another if they
share a physical
connection or a virtual connection, directly or indirectly, allowing data
accessed or modified by one
component to be accessed in another component. In some embodiments, at least
some of the
components can be upgraded or modified remotely (e.g., by reconfiguring
executable instructions
that implements a portion of the components). Other arrays, systems and
devices described above
may include additional, fewer, or different components for various
applications.
14
CA 3021282 2018-10-18
[0062] FIG. 4 is a graphical illustration of a control server 102
performing a method,
according to various embodiments. Embodiments include one or more processors
(e.g., processor
250) of the control server 102 executing a congestion control application to
utilize air traffic data
212 to determine a congestion premium. More specifically, the congestion
control application may
obtain air traffic data and ticket data (step 402) from the air traffic
database 210 and the ticket
database 230, determine expected delays for passengers travelling during a
slot (step 406), estimate
value for passenger time (step 408), determine a utilization level of a runway
at an airport (step
410), determine an initial congestion premium to achieve the determined
utilization level (step 412),
obtain updated ticket data from the ticket database 230 (step 414), reevaluate
the congestion
premium based on updated ticket data (step 416), and update premium schedule
data in the
premium schedule database 240 based on the reevaluated congestion premium
(step 418). Arrows
may be shown to denote a chronological flow of the method. However, the arrows
are included
merely to show examples of a possible method flow and should not be construed
as a limitation of
possible method flows. Embodiments include steps of the method being performed
in various orders
that may differ from those depicted in FIG. 4. A person skilled in the art
would appreciate the
various embodiments disclosed herein.
[0063] In step 402, the congestion control application may obtain air
traffic data and ticket
data from the air traffic database 210 and the ticket database 230. The
congestion control
application may transmit a message to the ATAS server 104 including a query
for air traffic data
(e.g., via a communication interface). In response for the query for air
traffic data, the ATAS server
104 may transmit a message to the control server 102 including the air traffic
data. The control
server 102 may receive the air traffic data transmitted by the ATAS server
104. The processor 250
may identify the data received from the ATAS server 104 as air traffic data by
evaluating the
message transmitted from the ATAS server to determine, for example, a host
identification
(host_ID) associated with the message, a data structure of the message, a
tuple and/or list associated
with air traffic data, or any combination thereof. For example, the processor
250 may identify a first
tuple (e.g., a sequence of immutable Python objects) associated with a
plurality of airports and a
second tuple associated with a plurality of flights. Based on the
identification of the first tuple and
the second tuple, the processor 250 may determine that the received data is
air traffic data. In
response to determining the received data is air traffic data, the processor
250 may store the
CA 3021282 2018-10-18
received data in the air traffic database 210. Air traffic data stored in the
air traffic database 210
may be utilized in one or more subsequent steps.
[0064] The congestion control application may transmit a message to the
ticket vendor server
106 including a query for ticket data (e.g., via a communication interface).
In response for the query
for ticket data, the ticket vendor server 106 may transmit a message to the
control server 102
including the ticket data. The control server 102 may receive the ticket data
transmitted by the ticket
vendor server 106. The processor 250 may identify the data received from the
ticket vendor server
106 as ticket data by evaluating the message transmitted from the ticket
vendor server 106 to
determine any of a host ID associated with the message, a data structure of
the message, a tuple
and/or list associated with air traffic data, or any combination thereof. For
example, the processor
250 may identify a first tuple (e.g., a sequence of immutable Python objects)
associated with a
plurality of available tickets and a second tuple associated with a plurality
of ticket prices. Based on
the identification of the first tuple and the second tuple, the processor 250
may determine that the
received data is ticket data. In response to determining the received data is
ticket data, the processor
250 may store the received data in the ticket database 230. Ticket data stored
in the ticket database
230 may be utilized in one or more subsequent steps.
[0065] In step 406, the congestion control application may determine a
congestion delay. The
congestion delay may be determined based on the number of flights utilizing a
slot of an airport. For
example, if five flights are scheduled to utilize a runway at an airport
during between 11:00 AM and
11:30 AM, and a seven minute gap is required between a takeoff of each flight,
a five-minute
congestion delay may result.
[0066] In an embodiment, a congestion delay determined for a slot may
account for delays
determined from previous slots. For example, if one or more prior slots (e.g.,
10:30 AM - 11:00 AM
slot, 10:00 AM - 10:30 AM slot, etc.) are determined to have a congestion
delay, the congestion
delay of the prior slot may be added to the congestion delay of a subsequent
slot. If a number of
flights scheduled during the 10:30 AM - 11:00 AM slot are determined to result
in a six-minute
delay and the 11:00 AM - 11:30 slot is determined to result in a five-minute
delay, the congestion
delay for the 11:00 AM - 11:30 AM slot may be determined to be eleven minutes.
Thus, the
16
CA 3021282 2018-10-18
congestion delay for a slot may be a cumulative delay resulting from a number
of flights in the slot
and flights from previous slots that may affect the slot.
[0067] In an embodiment, a congestion delay determined for a slot may not
include delays
from a previous slot if an intervening slot is determined to compensate for
the delay. For example, if
a first number of flights in a first slot (e.g., 8:00 AM - 8:30 AM) is
determined to result in a 10-
minute delay, a second number of flights in a second slot (e.g., 8:30 AM -
9:00 AM) is determined
to result in a 10-minute surplus of time, and a third number of flights in a
third slot (e.g., 9:00 AM -
9:30 AM) is determined to result in a 5-minute delay, the congestion delay for
the third slot may be
determined to be 5 minutes since the second slot may cancel out the delay from
the first slot.
[0068] In an embodiment, a congestion delay determined for a slot may
account for a residual
delay from one or more previous slots. A residual delay may be an estimated
remaining delay after
a prior slot. For example, if a first number of flights in a first slot (e.g.,
8:00 AM - 8:30 AM) is
determined to result in a 14 minute delay, a second number of flights in a
second slot (e.g., 8:30 AM
- 9:00 AM) is determined to result in a 10-minute surplus of time, and a third
number of flights in a
third slot (e.g., 9:00 AM - 9:30 AM) is determined to result in a 5-minute
delay, the congestion
delay for the third slot may be determined to be 9 minutes since the second
slot may reduce a
residual delay from the first slot.
[0069] In step 408, the congestion control application may estimate a value
for passenger
time. Data for estimating the value for passenger time may be extracted from,
for example, the air
traffic database 210 (e.g., data indicating a distance of travel) and the
ticket database 230 (e.g., data
indicating a ticket type). Data associated with the value for passenger time
may be stored in the
passenger time valuation database 220.
[0070] Estimating a value for passenger time may be based on one or more
variables such as,
for example, trip purpose (e.g., business or personal travel), identified
characteristics of passenger
(e.g., age, sex, education, employment, income, etc.), distance of travel, and
ticket type (e.g.,
economy, business, first class, etc.). Various embodiments for estimating a
value for passenger time
are discussed below. Some embodiments may determine different values for
different passengers.
Some embodiments may estimate a same value for one or more passengers based on
one or more
common variables shared between the passengers.
17
CA 3021282 2018-10-18
[0071] In an embodiment, the value of time for a passenger may be estimated
to be the same
as the value of travel time savings (VTTS) determined by the United States
Department of
Transportation (USDOT). Data associated with the VTTS may be obtained from a
USDOT server
via the control server 102. VTTS may vary depending on one or more other
variables. For example,
VTTS for a trip purpose defined as "business" may be $60.00 per hour. In
another example, VTTS
for a trip purpose defined as "personal" may be $32.60 per hour. Embodiments
include assuming an
annual rate of growth of 1.2 percent of real median household income to
determine an increase in
VTTS in any given year.
[0072] In an embodiment, a value of time for a passenger may be estimated
by dividing an
annual income of the passenger divided by 2,080 hours per year to obtain an
hourly value of time
for the passenger. Annual income of a passenger may be extracted from the
ticket database 230
(e.g., $100,000 per year). The extracted annual income of $100,000 per year
may be divided by
2,080 hours to obtain an estimated hourly value of time for the passenger of
$48.08. In an
embodiment, if income data is not available for a passenger, a default annual
income value may be
used. The default annual income value may be the median annual of airline
travelers. For example,
the median annual income of airline travelers in a given year (e.g., $70,000)
may be divided by
2,080 hours to obtain an estimated hourly value of time for the passenger of
$33.65. If data of a
current year median annual income is not available, data associated with a
prior year median annual
income may be used and an annual rate of growth of 1.2 percent for median
annual income may be
assumed.
[0073] In step 410, the congestion control application may determine a
utilization level of a
runway at an airport. The utilization level of the runway at the airport may
be a percentage of a
maximum capacity of the runway at the airport. For instance, under ideal
conditions (e.g., perfect
weather, no human error, etc.) an airport may be determined to have a maximum
throughput of 45
scheduled operations per slot (e.g., 45 scheduled operations per half hour).
[0074] The utilization level (e.g., 87% of maximum capacity) may be
determined based on a
determined congestion delay target (e.g., 6-minute delay). The airport may
have 40 operations (e.g.,
flight takeoffs and/or landings) actually scheduled for the slot. A congestion
delay (based on, for
example, historical air traffic data) of 10 minutes may be determined for the
40 operations during
18
CA 3021282 2018-10-18
the slot. A congestion delay target of 6 minutes may be selected for the slot
based on, for example, a
determined convergence between a cost of reducing the congestion delay and a
value of time of
passengers. For example, a value of time of 5000 passengers scheduled for the
40 operations may
amount to $190,400 per hour (e.g., if 1000 business passenger have a time
value of $60 per hour
and 4000 personal passengers have a time value of $32.60 per hour) or $12,693
for 4 minutes.
Reducing the congestion delay by 4 minutes (e.g., from 10 minutes to 6
minutes) may require
reducing the 40 operations to 39 operations by discontinuing operation of a
single small aircraft
during the slot, which may cost $12,700. Since the cost of discontinuing
operation of the small
aircraft achieves a 4-minute congestion delay reduction which is approximately
equal to the
estimated value of 4 minutes for the passengers during the slot, a congestion
delay reduction of 4
minutes may be selected. A convergence between the cost of reducing the
congestion delay and the
value of time of passengers may be determined by identifying a closest match
between the cost of
reducing the congestion delay and the value of time of passengers.
[0075] If a maximum capacity of a slot at an airport is 45 scheduled
operations and reducing
operations to 39 may achieve a determined congestion delay target, a
utilization level of 87% (i.e.,
39 operations divided by maximum capacity of 45 operations) may be determined.
[0076] In step 412, the congestion control application may determine an
initial congestion
premium to achieve the determined utilization level. Achieving the determined
utilization level may
involve, for example, disincentivizing flights during peak slots and/or
incentivizing flights during
non-peak slots. Achieving the determined utilization level may involve, for
example, a decrease in
ticket selection for flights during a peak slot and/or an increase in ticket
selection for flights during
a non-peak slot. In an embodiment, the congestion control application may
determine a cost of
reducing the congestion delay (e.g., the cost of discontinuing operation of
one or more flights). The
cost of reducing the congestion delay may be allocated among tickets for
flights during a slot.
[0077] In another embodiment, the congestion control application may
evaluate ticket
purchase patterns identified in ticket data to determine an initial congestion
premium. For example,
if a 5% decrease in ticket selection is needed to achieve the determined
utilization level, a value
corresponding to a decrease in ticket selection by 5% may be identified in the
ticket data based on
historical reductions in ticket selection. If a value of $50 is determined to
decrease ticket selection
19
CA 3021282 2018-10-18
by 5%, the congestion control application may determine that an initial
congestion premium of $50
may achieve the determined utilization level.
[0078] The initial congestion premium may be stored in the ticket database
230. The initial
congestion premium may be allocated among tickets for one or more flights
scheduled during the
slot. The congestion premium may be provided to the ticket vendor server 106.
The congestion
premium may be provided to a user device (e.g., user device 302).
[0079] In step 414, the congestion control application may obtain updated
ticket data from,
for example, the ticket vendor server 106. The updated ticket data may be
obtained subsequent to
providing the congestion premium to the ticket vendor server 106. The updated
ticket data may
include data associated with one or more selections of a ticket including the
congestion premium.
[0080] In an embodiment, the congestion control application may receive
ticket data from the
ticket vendor server 106. The ticket vendor server 106 may transmit ticket
data representing
available tickets at a given time for a specific flight. For example, the
ticket data may illustrate that
historically, 30 tickets are available on June 1 for a flight departing July 1
of the same year. The
ticket data may represent a historical overview of available tickets for a
flight at a specific time for
previous flights. For example, the ticket data can represent data showing that
on June 1 from 2001-
2011 an average of 35 tickets are available on June 1 for a flight departing
July 1 of the same year.
[0081] The congestion control application may generate an expected ticket
acquisition
function based on the ticket data received from the ticket vendor server 106.
The expected ticket
acquisition function may be a polynomial generated by the congestion control
application based on
historical ticket acquisition data over time prior to the departure for a
specific flight. The
polynomial may be a first order or second order polynomial utilizing curve
fitting to generate a
polynomial based on the historical ticket acquisition information received by
the ticket vendor
server 106.
[0082] The congestion control application may estimate the number of
available seats at a
specific time prior to the time slot of a flight based on the expected ticket
acquisition function. The
congestion control application may evaluate the expected ticket acquisition
function based on the
amount of time remaining before the scheduled time slot of a specific flight.
The expected ticket
CA 3021282 2018-10-18
acquisition function may determine the estimated available seats remaining for
a specific flight
based on historical ticketing data.
[0083] In some embodiments, the congestion control application may
determine whether the
congestion premium has disincentivized air passengers from purchasing peak
time slot flights based
on the ticket acquisition data received from the ticket vendor application.
The congestion control
application may compare the actual ticket acquisition information with the
estimated available seats
remaining based on the expected ticket acquisition function. For example, the
estimated available
seats remaining at a specific time may estimate that 40 seats should be
available, but the actual
ticket acquisition data shows that 10 seats are available. In this example,
the congestion premium
may be too low, as air passengers were continued to purchase peak time slot
flights with a
congestion premium.
[0084] In another example, the estimated available seats remaining at a
specific time may
estimate that 40 seats should be available, but the actual ticket acquisition
data shows that 50 seats
are available. In this example, the congestion premium may be appropriate or
too high of a value, as
the congestion premium has discouraged air passengers from purchasing the peak
tickets at a rate
greater than the historical average. Comparing the available seats for a
flight with a historical
expected ticket acquisition function may demonstrate whether the congestion
premium value is
appropriate or inappropriate. This comparison may be utilized in reevaluating
and updating the
congestion premium (e.g., step 416).
[0085] In step 416, the congestion control application may reevaluate the
congestion premium
based on updated ticket data. The congestion control application may
determine, based on the
updated ticket data, a selection rate of tickets including the congestion
premium. The selection rate
may be used to reevaluate the congestion premium. A determined selection rate
lower than an
expected selection rate may result in decreasing the congestion premium. For
example, if an
expected selection rate is 12 tickets per business day and a determined
selection rate is 2 tickets per
business day, the congestion premium for the tickets may be decreased. A
determined selection rate
higher than expected may result in increasing the congestion premium. For
example, if an expected
selection rate is 12 tickets per business day and a determined selection rate
is 20 tickets per business
day, the congestion premium may be increased.
21
CA 3021282 2018-10-18
L00861 The congestion premium may be reevaluated by the congestion control
application
based on multiple sources of data received from multiple applications. The
congestion control
application may receive ticket acquisition data from the ticket vendor
application. The congestion
control application may generate an expected ticket acquisition function based
on the historical
ticket acquisition data. The congestion control application may dynamically
receive updated actual
ticket acquisition data from the ticket vendor application. The congestion
control application may
evaluate the expected ticket acquisition function for a specific time prior to
the scheduled time slot
of the flight. The congestion control application may compare the evaluated
expected ticket
acquisition function with the actual ticket acquisition data to determine a
difference between
expected available seats and actual available seats for a specific time prior
to the time slot of a
flight.
[0087] The congestion control application may utilize the difference
between expected
available seats and the actual available seats to reevaluate the congestion
premium. The congestion
premium may be changed depending on whether the actual available seats
information exceeds or
falls below the expected available seats derived from the expected ticket
acquisition function.
[0088] For a first example, the expected available seats evaluated from the
expected ticket
acquisition function four weeks before the scheduled peak time slot of a
flight may return 50
expected available seats. If the actual ticket acquisition data indicates that
only 25 seats are left for
the flight four weeks before the scheduled time slot, 25 more seats were
bought by air passengers
paying the congestion premium. This may indicate that the congestion premium
should be increased
to discourage ticket sales for the peak time slot flight.
[0089] To determine how much to change the congestion premium, multiple
processes may
be performed. In some embodiments, the expected available seats may be divided
by the actual
number of available seats. In the first example, if the congestion premium is
$100, for example, and
the expected available seats are 50, and the actual available seats are 25
seats. The ratio of expected
available seats to actual available seats is 2. In the first example, the
congestion premium of $100
may be multiplied by the ratio of expected/actual available seats, which may
determine an updated
congestion premium of $200.
22
CA 3021282 2018-10-18
[0090] In an embodiment, the congestion premium may be reevaluated by
taking the
difference between the expected available seats and the actual available
seats, and multiplying the
difference by the congestion premium. The congestion control application may
evaluate the
estimated ticket acquisition function at various points in time. For example,
the congestion control
application may evaluate the estimated ticket acquisition function at the
scheduled time slot of the
flight, i.e. the last time to purchase a ticket. The congestion control
function may determine the
difference between the estimated ticket acquisition function at the scheduled
time slot of the flight
and the estimated ticket acquisition function at a given point in time prior
to the scheduled time slot
of the flight.
[0091] In an embodiment, the updated congestion premium may be bounded by a
minimum
congestion premium and a maximum congestion premium. The updated congestion
premium may
not exceed the maximum congestion premium. The updated congestion premium may
not fall
below the minimum congestion premium.
[0092] In step 418, the congestion control application may update premium
schedule data in
the premium schedule database 240 based on the reevaluated congestion premium.
The reevaluated
congestion premium may be stored in the premium schedule database 240. The
reevaluated
congestion premium may be provided to the ticket vendor server 106 and
allocated to tickets of one
or more flights scheduled during the slot.
[0093] Steps 414, 416, and 418 may be performed iteratively until the
determined selection
rate is within a threshold of the expected selection rate. The threshold may
be, for example, less
than two standard deviations, less than one standard deviation, less than one-
half of one standard
deviation, less than one-quarter of one standard deviation, or any other
proportion of one standard
deviation.
[0094] Figure 4B illustrates an example method 450 of determining an
expected congestion
delay. The method as illustrated in FIG. 4B may be utilized to determine a
congestion delay. The
control server 102 may determine the expected congestion delay.
[0095] In step 452, a historical congestion delay may be determined. The
historical
congestion delay may be determined using a control server (e.g. 102). The
control server 102 may
utilize airport data including, for example, airplane takeoff/landing times,
historical airport delays,
23
CA 3021282 2018-10-18
plane model and size, and passengers per plane. The airport data may be
provided by an air traffic
activity system (ATAS) server. The control server 102 may dynamically receive
historical data by
the ATAS server to update historical data for each airport. The control server
102 may distinguish
historical data for a specific date. The control server may distinguish each a
time slot for each flight
during the specific date, and determine the congestion delay of each flight on
a specific date.
[0096] The control server 102 may utilize mathematical functions to
determine historical
congestion delays. Finding historical congestion delay functions can be
advantageous to utilize
historical flight information to reasonably predict future congestion delays
of a flight for a specific
time slot and date.
[0097] The control server 102 may determine a historical congestion delay
function at each
airport as a function of time. For example, the control server 102 may
determine the historical
congestion delay function at John F. Kennedy International airport (JFK) for
the date of July 1,
2011. To determine the historical congestion delay function, the control
server 102 may receive
many years' worth of airport and flight information from the ATAS server. For
example, the control
server 102 may generate a historical congestion delay function based on
airport data for JFK airport
from 2001-2011 to determine an estimated congestion delay for July 1,2011.
[0098] The control server 102 may determine each data point using
historical airport
information from the ATAS server. For example, each data point may represent
congestion delay
during a specific time slot on a specific prior date. The control server 102
may determine congestion
delay for each time slot on a specific date using the prior airport
information from the ATAS server.
For example, the control server 102 may determine congestion delay for a
specific date by
analyzing differences between expected departure times and actual departure
times for each flight
within a time slot.
[0099] The historical congestion delay function may be represented in the
form of a
polynomial. The polynomial may be in the first order, or the polynomial may be
determined at a
higher order based on computational resources. If the polynomial is of a
higher order, the
polynomial may exhibit greater accuracy, but the high-order polynomial may
require greater
computational resources to determine expected congestion delay. The historical
congestion delay
function may be determined by utilizing curve fitting on the data points.
Curve fitting may include
24
CA 3021282 2018-10-18
generating a polynomial based on generating a curve, or a mathematical
function, based on a best fit
to the series of data points as a function of time.
[00100] The historical congestion delay function may be determined by
utilizing regression
analysis, a statistical model for estimating the relationship between the data
points. One such
technique may include least squares type regression analysis. FIG. 4C is a
graph of a polynomial
function describing a relationship between congestion delay and a time of day.
Congestion delay
can increase over the course of a day as previous delays compound subsequent
delays.
[00101] The historical congestion delay function may be numerically derived
at the control
server 102. The historical congestion delay function may represent a function
of historical
congestion delay as a function of time. The historical congestion delay
function may be represented
as a numerical polynomial. A historical congestion delay function may be
generated for each airport
for a given date. The control server 102 may utilize the airport-specific
historical congestion delay
functions for each airport to determine the estimated congestion delay based
on flights departing
and arriving at each airport.
[00102] In step 454, the control server 102 may determine a minimum
congestion delay. The
minimum congestion delay may be the minimum possible delay for a specific time
slot at a specific
airport. The control server 102 may utilize the historical congestion delay
function found in step
452.
[00103] The minimum congestion delay may be determined recursively. For
example, the
control server 102 may begin with a first flight in a time slot. The control
server 102 determine the
unimpeded taxi time for a flight, which may include the duration of time for a
flight to leave the
gate and takeoff without any delay. The control server 102 may determine the
minimum congestion
delay for the first flight based on an analysis of the historical congestion
delay function as a
function of time. The control server 102 may determine the taxi duration of
the first flight based on
the unimpeded taxi time in addition to the historical congestion delay
incurred at the given time
from the polynomial generated for the historical congestion delay function.
For example, if the first
flight has an unimpeded taxi time of 6 minutes, and the historical congestion
delay function
determines that, at the specific time slot, the congestion delay is
historically 2 minutes, it may take 8
minutes for the first flight to take off.
CA 3021282 2018-10-18
[00104] The control server 102 may recursively add flights for a given time
slot and
determining their taxi duration based on the historical congestion delay
function and known
unimpeded taxi delay times. The control server 102 may keep recursively adding
flights until the
estimated delay for a given time slot is above the unimpeded taxi time for
flights at the specific
airport. The control server 102 may recursively add flights based on number of
passengers and
known taxi durations. For example, the control server 102 may add flights with
the greatest amount
of passengers as to increase the number of passengers that may takeoff in the
time slot without a
congestion delay. Different combinations of flights may be added to generate
the maximum number
of flights that may take off with unimpeded taxi time to generate the minimum
congestion delay.
The minimum congestion delay may be given a default value, such as 15 minutes,
for example.
[00105] In step 456, the control server 102 may determine the maximum
congestion delay for a
time slot. The control server 102 may receive a maximum amount of operations
allowed for a given
time slot. The maximum amount of operations may be dictated by regulation by
an airport
regulation body, or a government agency, for example. The control server 102
may determine a
maximum congestion by evaluating the historical congestion delay function
using the maximum
allowed number of operations for a given time slot. This evaluation will
determine the maximum
allotted congestion delay given the historical congestion delay function
determined in step 452.
[00106] The maximum congestion delay for a time slot may be determined
using data from
multiple sources. The control server 102 may be in electrical communication
with a server
containing data relating to on-time arrival performance and causes for
cancellations for each airport.
For example, the United States Department of Transportation (U.S. DOT) Bureau
of Transportation
Statistics (BTS) may comprise a database of average on-time operations,
cancelled operations, and
reasons for each operation to be cancelled, such as weather, air carrier
delay, or aircraft arriving
late, for example. The control server 102 may receive the operation
cancellation database from a
source such as the U.S. DOT BTS, or another similar source.
[00107] The control server 102 may receive operation taxi data from a
remote server. The
server may comprise a known database of average flight taxi times for arriving
and departing flights
in each time slot. A governmental agency may store a database of average taxi
times, such as the
26
CA 3021282 2018-10-18
U.S. Federal Aviation Administration (FAA) Aviation System Performance Metrics
(ASPM)
database.
[00108] The control server 102 may be in electrical communication with a
U.S. DOT BTS
server and a U.S. FAA ASPM server. The control server 102 may utilize the
operation cancellation
statistics and the average taxi times to determine a maximum congestion delay.
The maximum
congestion delay may be determined by finding the maximum number of allotted
flights for a time
slot at a given airport. The control server 102 may multiply the maximum
number of allotted flights
by the average cancelation rate for a given time slot at the given airport to
find a maximum
cancellation allotment. The control server 102 may multiply the maximum
cancellation allotment
with the average taxi times for each flight in a time slot at an airport to
find a maximum congestion
delay for a time slot at an airport.
[00109] In step 458, the control server 102 may determine the expected
congestion delay. The
expected congestion delay may be the congestion delay. The expected congestion
delay may
comprise the expected delay for each flight in a time slot based on historical
data and flight data
received by the control server 102. The expected congestion delay generally
may comprise a value
greater than the minimum congestion delay and a value less than the maximum
congestion delay.
The expected congestion delay may be desirable to be a value close to the
minimum congestion
delay, as this will allow for minimal expected delays.
[00110] The control server 102 may utilize the historical congestion delay
function determined
in step 452. The control server 102 may receive data representing the number
of flights reserved for
a given time slot. The data representing the number of flights may be
transmitted by a ticket vendor
server 106, the ATAS server 104, or another scheduling database. The control
server 102 may
receive data representing the amount of flights planning to offer passenger
tickets for each flight in
a time slot, the average price of the ticket, and the amount of tickets
available.
[00111] The expected congestion delay may be determined by evaluating the
number of flights
reserved for a given time slot by the historical congestion delay function.
The historical congestion
delay function may be a polynomial that may provide an estimated congestion
delay in minutes
based on the time slot and the number of operations planning to use the time
slot. Evaluating the
historical congestion delay function and the number of flights reserved for a
given time slot may
27
CA 3021282 2018-10-18
allow for an estimated congestion delay based on the time slot given and
historical data representing
previous flight times and delays.
[00112] FIG. 5 is a flow diagram illustrating a sample process for managing
air traffic
congestion, according to various embodiments. The sample process of FIG. 5 may
involve selecting
a congestion premium, based on air traffic data, designed to reduce a
congestion delay for a slot of
an airport. The sample process may include querying an air traffic database
for air traffic data of an
airport (step 510), determining a congestion delay resulting from the number
of flights utilizing the
slot of the airport (step 520), selecting a congestion delay target based on
an estimated time value of
a plurality of customers (step 530), determining a utilization level of the
slot based on the selected
congestion delay target (step 540), determining a congestion premium for one
or more flights
scheduled during the slot to achieve the defined utilization level (step 550),
and updating a premium
schedule database to allocate the congestion premium among tickets for one or
more flights
scheduled during the slot (step 560).
[00113] In step 510, the congestion control application may query an air
traffic database for air
traffic data of an airport. The air traffic data may include schedules of a
number of flights utilizing a
slot of the airport. The slot may be a period of time for an aircraft to take-
off or land at the airport.
[00114] Querying the air traffic database may include identifying data in
the air traffic
database associated with a number of flights utilizing a slot of an airport
and extracting the data
associated with the number of flights utilizing a slot of the airport. The
extracted data may be used
in one or more subsequent steps.
[00115] The air traffic database may be populated with data received from
one or more remote
servers (e.g., a server associated with the United States Department of
Transportation). The air
traffic database may be part of a control server, such as, for example, the
control server 102
discussed in FIG. 2.
[00116] In step 520, the congestion control application may determine,
based on the air traffic
data, a congestion delay resulting from the number of flights utilizing the
slot of the airport. The
congestion delay may be determined based on the number of flights utilizing a
slot of an airport. For
example, a number of flights (e.g., 5 flights) may be scheduled to utilize a
runway at an airport
during a slot (e.g., between 11:00 AM and 11:30 AM). Various time gaps may be
required between
28
CA 3021282 2018-10-18
a takeoff of each flight based on a wake created by each aircraft (e.g., large
aircraft may create a
large wake and require a larger time gap). If a time gap required for the
flights scheduled during a
slot exceeds a time duration of the slot, a congestion delay may result. A
residual delay from one or
more previous slots may also result in a congestion delay for a slot. Various
embodiments for
determining a congestion delay based on one or more flights utilizing a slot
and a residual delay
from prior slots are contemplated.
[00117] In an embodiment, a congestion delay determined for a slot may
account for delays
determined from previous slots. For example, if one or more prior slots (e.g.,
10:30 AM - 11:00 AM
slot, 10:00 AM - 10:30 AM slot, etc.) is determined to have a congestion
delay, the congestion
delay of the prior slot may be added to the congestion delay of a subsequent
slot. If a number of
flights scheduled during the 10:30 AM - 11:00 AM slot is determined result in
a six-minute delay
and the 11:00 AM - 11:30 slot is determined to result in a five-minute delay,
the congestion delay
for the 11:00 AM - 11:30 AM slot may be determined to be eleven minutes. Thus,
the congestion
delay for a slot may be a cumulative delay resulting from a number of flights
in the slot and flights
from previous slots that may affect the slot.
[00118] In an embodiment, a congestion delay determined for a slot may not
include delays
from a previous slot if an intervening slot is determined to compensate for
the delay. For example, if
a first number of flights in a first slot (e.g., 8:00 AM - 8:30 AM) is
determined to result in a 10-
minute delay, a second number of flights in a second slot (e.g., 8:30 AM -
9:00 AM) is determined
to result in a 10-minute surplus of time, and a third number of flights in a
third slot (e.g., 9:00 AM -
9:30 AM) is determined to result in a 5 minute delay, the congestion delay for
the third slot may be
determined to be 5 minutes since the second slot may cancel out the delay from
the first slot.
[00119] In an embodiment, a congestion delay determined for a slot may
account for a residual
delay from one or more previous slots. A residual delay may be an estimated
remaining delay after
a prior slot. For example, if a first number of flights in a first slot (e.g.,
8:00 AM - 8:30 AM) is
determined to result in a 14 minute delay, a second number of flights in a
second slot (e.g., 8:30 AM
- 9:00 AM) is determined to result in a 10-minute surplus of time, and a third
number of flights in a
third slot (e.g., 9:00 AM - 9:30 AM) is determined to result in a 5 minute
delay, the congestion
29
CA 3021282 2018-10-18
delay for the third slot may be determined to be 9 minutes since the second
slot may reduce a
residual delay from the first slot.
[00120] In step 530, the congestion control application may select a
congestion delay target
based on an estimated value of time for a plurality of passengers. A
congestion delay target may be
selected for a slot based on, for example, a determined convergence between a
cost of reducing the
congestion delay and an estimated value of time for passengers. The congestion
delay target may be
equal to the minimum congestion delay, as determined in FIG 4B, for example.
[00121] Estimating a value of time for passengers may be based on one or
more variables such
as, for example, trip purpose (e.g., business or personal travel), identified
characteristics of
passenger (e.g., age, sex, education, employment, income, etc.), distance of
travel, and ticket type
(e.g., economy, business, first class, etc.). In an embodiment, the value of
time for a passenger may
be estimated to be the same as the value of travel time savings (VTTS)
determined by the United
States Department of Transportation (USDOT). In another embodiment, the
estimated value of time
for passengers may utilize a U.S. DOT stated policy for air passenger hourly
value of time. The
estimated passenger value of time may be updated if the USDOT stated policy
for air passenger
hourly value of time is updated. In another embodiment, a value of time for a
passenger may be
estimated by dividing an annual income of the passenger divided by 2,080 hours
per year to obtain
an hourly value of time for the passenger.
[00122] The estimated value of time for passengers may vary by population
or cost of living of
the region served by the airport. The estimated value of time for a plurality
of passengers may be
refined for a flight by slot time, route and day of week for each flight by
scaling the value of time
by normalized publically available demand elasticity estimates. The estimated
value of time for a
plurality of passengers may be determined by utilizing data from various
sources. The control
server 102 may receive the average air passenger value of time from a
database, such as the U.S.
DOT database. The control server 102 may determine the average number of
passengers per flight
for each time slot by, for example, retrieving passenger data from a database
(e.g., the U.S. DOT
BTS load factor statistics) and evaluating a number of passengers indicated
for a particular time
slot. The control server 102 may receive the number of expected flights
sharing each time slot from
a database such as the ATAS server 104 or ticket vendor server, for example.
The control server
CA 3021282 2018-10-18
102 may determine the estimated value of time for the plurality of passengers
in a time slot. The
estimated value of time may be determined by multiplying the average air
passenger value of time,
the average number of passengers per flight, and each expected flight sharing
each time slot.
[00123] The control server 102 may determine the congestion delay target
based on an
estimated value of time for a plurality of passengers. The control server 102
may dynamically
receive and update various flight data from multiple servers. This may be
advantageous, as the
control server 102 may dynamically process and update resulting values, which
may lead to greater
accuracy in determining values such as an expected congestion delay or an
estimated value of time
for a plurality of passengers, for example.
[00124] A convergence between the estimated value of time for the plurality
of passengers and
the cost of reducing the congestion delay for increments of time may be used
to select the
congestion delay target. For example, a value of time of 5000 passengers
scheduled for the 40
operations may amount to $190,400 per hour (e.g., if 1000 business passenger
have a time value of
$60 per hour and 4000 personal passengers have a time value of $32.60 per
hour) or $12,693 for 4
minutes. Reducing the congestion delay by 4 minutes (e.g., from 10 minutes to
6 minutes) may
require reducing the 40 operations to 39 operations by discontinuing operation
of a single small
aircraft during the slot, which may cost $12,700. Since the cost of
discontinuing operation of the
small aircraft achieves a 4-minute congestion delay reduction which is
approximately equal to the
estimated value of 4 minutes for the passengers during the slot, a congestion
delay reduction of 4
minutes may be selected. A convergence between the cost of reducing the
congestion delay and the
value of time of passengers may be determined by identifying a closest match
between the cost of
reducing the congestion delay and the value of time of passengers.
[00125] In step 540, the congestion control application may determine a
utilization level of the
slot based on the selected congestion delay target. The utilization level may
be a percentage of a
maximum capacity of a runway at an airport. The utilization level (e.g., 87%
of maximum capacity)
may be determined based on a selected congestion delay target (e.g., 6-minute
delay). For example,
if a maximum capacity of a slot at an airport is 45 scheduled operations and
reducing operations to
39 may achieve a determined congestion delay target, a utilization level of
87% (i.e., 39 operations
divided by maximum capacity of 45 operation) may be determined.
31
CA 3021282 2018-10-18
[00126] The control server 102 may determine a utilization level of the
time slot based on the
congestion target. The control server 102 may utilize the historical
congestion delay function (step
452). The control server 102 may recursively evaluate the historical
congestion delay function
polynomial with a first flight. This may return an estimated amount of time
for the flight to taxi
including a potential delay. The control server 102 may recursively add
flights in a given time slot,
and evaluate the flights using the historical congestion delay function
polynomial. The utilization
level may be determined when the control server 102 finds that the recursively
added flights
exceeds the threshold of the congestion delay target, and dividing the number
of flights by the
maximum number of flights possible for a given time slot. The congestion delay
target may
comprise a predetermined amount of time. The congestion delay target may
comprise the minimum
congestion delay, as determined in step 454, for example.
[00127] In step 550, the congestion control application may determine a
congestion premium
for one or more flights scheduled during the slot to achieve the determined
utilization level.
Achieving the determined utilization level may involve, for example,
disincentivizing flights during
peak slots and/or incentivizing flights during non-peak slots. For example, a
premium resulting in a
reduction of a flight among flights scheduled for a slot may be the congestion
premium. Achieving
the determined utilization level may involve, for example, a decrease in
ticket selection for flights
during a peak slot and/or an increase in ticket selection for flights during a
non-peak slot. In an
embodiment, the congestion control application may determine a cost of
reducing the congestion
delay (e.g., the cost of discontinuing operation of one or more flights). For
example, the cost of
reducing the congestion delay may be the congestion premium.
[00128] In an embodiment, the congestion premium may be determined by
dynamically
receiving and utilizing data from multiple external sources in electrical
communication with the
control server 102. The control server 102 may receive U.S. DOT average hourly
value of air
passenger time from a database such as the U.S. DOT BTS, or another known
database. The
minimum congestion premium may be the average hourly value of air passenger
time. The
maximum congestion premium may be the minimum congestion premium multiplied by
ten. The
control server 102 may multiply the average hourly value of passenger time and
the expected
congestion delay (e.g., step 456) to determine the congestion premium of one
or more flights in a
time slot.
32
CA 3021282 2018-10-18
[00129] The congestion premium can be determined by generating an
elasticity function
derived from ticket acquisition data (e.g., public historical acquisition data
and/or acquisition data
maintained locally by the system). The elasticity function can mathematically
describe a variation
of slot utilization resulting from possible congestion premiums. If a target
slot utilization is known,
a congestion premium corresponding to the target slot utilization can be
determined. The elasticity
function can be derived specifically for a particular time of day, date,
season, arrival airport,
destination airport, or any combination thereof. A plurality of elasticity
functions can be derived for
specific particular scenarios (e.g., flight from La Guardia to Boston Logan at
10:00 am in January,
flight from Los Angeles to Seattle at 8 PM on August 22, etc.).
[00130] An initial congestion premium may be determined by utilizing a
particularized
elasticity function derived from route-specific or slot-specific historic data
for the airport and/or
route. If a route between LaGuardia and Boston Logan has public historic
public averages for the
average airfare and their elasticity over the day and day of week, then,
instead of a nationwide
average time-value, a more accurate initial estimate of the initial congestion
premium can be
computed. For example, if the airfare for a 10:00 am flight from LaGuardia to
Boston Logan is
$400.00 and the price elasticity is -1.75, and the congestion delay target
requires reducing number
of seats sold by 25%, then a more accurate estimate for the starting
congestion premium would
be .25 x 1.75 x $400.00 = $175.00. This refined estimate still understates the
value to passengers,
since the current data does not offer insight into the value of reduced
congestion or congestionless
service. In subsequent seasons, the accuracy of the estimate for the initial
value of the congestion
premium could be equal to a value of the previous season.
[00131] In an embodiment, the congestion control application may receive
data associated with
a bid for utilizing a slot at an airport. The congestion application may
analyze bid data to determine
a congestion premium. For example, the bid data may include an index having
associations between
a plurality of flight operators (e.g., commercial airlines and other aircraft
operators) and a bid value
for a particular slot. The congestion premium may be iteratively reevaluated.
The congestion control
application may dynamically update tracked bid data whenever a time slot of an
airport receives a
predetermined number of quotes for bid data events. The congestion premium may
iteratively
reevaluate the congestion premium in real-time or in batch mode. The
congestion control
33
CA 3021282 2018-10-18
application may iteratively reevaluate the congestion premium by updating the
tracking bid data
events upon a predetermined number of quotes received and based on time period
in batch mode.
[00132] Based on a utilization level determined, a number of flights may be
able to utilize the
slot to achieve the congestion delay target. For example, 5 flights may be
able to operate in the slot
to achieve a congestion delay target of a 10-minute delay. A plurality of
highest bid values may be
determined, and a lowest bid value of the plurality of highest bid values may
be selected as the
congestion premium. For example, if 5 flights can operate during the slot to
achieve the congestion
delay target, and the 5 highest bids are $5000, $4950, $4920, $4875, and
$4865, the congestion
premium of $4865 may be determined. Although some operators may have bid a
higher value, the
determined congestion premium (e.g., $4865) may be applied to each flight
operator for the slot.
[00133] In another embodiment, the congestion control application may
identify ticket
purchase patterns in ticket data to determine the congestion premium. For
example, if a 5% decrease
in ticket selection is needed to achieve the determined utilization level, a
value corresponding to a
decrease in ticket selection by 5% may be identified in the ticket data based
on historical reductions
in ticket selection. If a value of $20 per ticket is determined to decrease
ticket selection by 5%, the
congestion control application may determine that a congestion premium, for
example, of $20,000
for 1000 tickets available during a slot, may achieve the determined
utilization level.
[00134] In another embodiment, the congestion control application may
determine the
congestion premium by a two-step process including (1) analyzing bid data and
(2) identifying
ticket purchase patterns in ticket data. For example, bid data may be analyzed
to determine an initial
value for a congestion premium. The initial value of for the congestion
premium may be determined
to be, for example, a lowest value of a plurality of values of bids where a
number of the plurality of
values is equal to the number of flights determined to be able to utilize the
slot to achieve the
congestion delay target. For example, if 5 flights are determined to be able
to utilize the slot to
achieve a 10-minute delay target, then a lowest bid of the top 5 bids may be
determined to be an
initial congestion premium. The congestion premium may be allocated to a
plurality of tickets (as
discussed below with reference to step 560) and ticket acquisition data may be
obtained from a
ticket vendor server indicating a number of tickets sold having the congestion
premium. Based on
the ticket acquisition data, the congestion control application may reevaluate
the congestion
34
CA 3021282 2018-10-18
premium. The ticket acquisition data may be analyzed to determine whether to a
value of the
congestion premium may be changed. For example, if a determined selection rate
is greater than an
expected selection rate, the congestion premium may be increased. In another
example, if a
determined selection rate is less than an expected selection rate, the
congestion premium may be
decreased.
[00135] In an embodiment, the congestion premium to achieve a utilization
level based on a
congestion delay target may result in an estimated yield loss. Yield loss may
be loss in revenue by
the airline or the airport by reducing the number of flights in a time slot. A
yield loss function can
be derived by smoothing or interpolation of yield loss data for various
congestion levels. A
passenger time value function can be derived by smoothing or interpolation of
estimated passenger
time for various congestion levels. A convergence of the yield loss function
with the passenger
time value function can indicate a point at which the estimated yield loss
from reducing the number
of flights to achieve a congestion delay target equals the estimated value of
air passenger time for
each passenger scheduled to use the removed flight. To remove a flight from a
time slot, the
removed flight may either be displaced or redirected. A displaced flight may
be canceled from the
time slot. A redirected flight may comprise a flight moved from a peak time to
an off-peak time
slot. A flight may be redirected or displaced to allow the time slot to meet a
congestion delay target
value.
[00136] The congestion control application may determine an initial value
of a congestion
premium. The congestion premium may be further dictated by iterative changes
in vendor data.
Iterative changes in vendor data can indicate a shift in flights from peak
time slot flights to off-peak
time slots.
[00137] In step 560, the congestion control application may update a
premium schedule
database to allocate the congestion premium among tickets for one or more
flights scheduled during
the slot. The premium schedule database may be part of a control server, as
described with
reference to FIG. 2. The congestion premium may be allocated among, for
example, operators of
one or more flights and/or tickets for one or more flights scheduled during
the slot. For example, if
flights are scheduled for a slot, a congestion premium of $5000 may be charged
to an operator
(e.g., a cargo delivery company) of one flight (e.g., a cargo aircraft) and
allocated among tickets for
CA 3021282 2018-10-18
the other 4 flights (e.g., passenger aircraft). Allocating the congestion
premium among tickets may
involve splitting the congestion premium evenly or distributing based on one
or more variables
(e.g., ticket price, ticket type, aircraft type, aircraft takeoff time
requirement, aircraft landing time
requirement, etc.). For example, the congestion premium may be allocated
proportionally based on
ticket price. In another example, the congestion premium may be allocated
based on an aircraft
takeoff time requirement, where tickets for an aircraft requiring a longer
takeoff time may be
allocated a proportionally larger portion of the congestion premium. The
congestion premium may
be provided to a ticket vendor server. The congestion premium may be provided
to a user device.
[00138]
FIGS. 6A-6B are a flow diagram illustrating another sample process for
managing air
traffic data, according to various embodiments. The sample process of FIG. 5
may involve an
iterative process for determining a congestion premium, based on air traffic
data and periodically
updated ticket data, designed to reduce a congestion delay for a slot of an
airport. The iterative
process for determining a congestion premium may include, for example,
obtaining air traffic data
from an air traffic activity system server (step 600), storing the air traffic
data into an air traffic
database (e.g., air traffic database 210) within the control server (step
605), querying an air traffic
database for air traffic data of an airport (step 610), determining, based on
the air traffic data, a
congestion delay resulting from the number of flights utilizing the slot of
the airport (step 620),
estimating a value of time for a plurality of expected passengers of the
number of flights (step 625),
selecting a congestion delay target based on the estimated time value of a
plurality of passengers
(step 630), determining a utilization level of the slot based on the selected
congestion delay target
(step 640), determining a congestion premium for one or more flights scheduled
during the slot to
achieve the defined utilization level (step 650), updating a premium schedule
database to allocate
the congestion premium among tickets for one or more flights scheduled during
the slot (step 660),
providing the congestion premium allocated among tickets for the one or more
flights scheduled
during the slot to a ticket vendor server (step 665), obtaining ticket
acquisition data over a time
period from the ticket vendor server (step 670), reevaluating the congestion
premium for the one or
more flights scheduled during the slot based on the ticket acquisition data
over the time period (step
680), and updating the premium schedule database with the reevaluated
congestion premium (step
690). Various embodiments for determining a congestion premium to reduce a
congestion delay are
discussed below.
36
CA 3021282 2018-10-18
[00139] In step 600, the congestion control application of the control
server may obtain air
traffic data from an air traffic activity system (ATAS) server. The air
traffic data may include
schedules of a number of flights utilizing a plurality of slots of a plurality
of airports. A slot is a
period of time for an aircraft to take-off or land at the airport.
[00140] The control server may obtain air traffic data from the ATAS server
by transmitting a
message to the ATAS server including a query for the air traffic data. In
response to the message,
the ATAS server may transmit the air traffic data to the control server. The
control server may
receive the air traffic data from the ATAS server. The control server may
identify the received data
as air traffic data by, for example, recognizing a host identification of the
ATAS server and/or a
data structure of the received data. Received data identified as air traffic
data may be stored in an air
traffic database, as discussed below with reference to step 605.
[00141] In step 605, the congestion control application of the control
server may store the air
traffic data into an air traffic database (e.g., air traffic database 210)
within the control server. The
air traffic database may be a memory device (or a portion of a memory device)
of the control server
configured to store the air traffic data. The air traffic database may be
electrically connected to a
processor of the control server such that the processor may query the air
traffic database.
[00142] In step 610, the congestion control application may query an air
traffic database for air
traffic data of an airport. The air traffic data may include schedules of a
number of flights utilizing a
slot of the airport. Various embodiments for querying the air traffic database
are discussed with
reference to step 510 in FIG. 5.
[00143] In step 620, the congestion control application may determine,
based on the air traffic
data, a congestion delay resulting from the number of flights utilizing the
slot of the airport. Various
embodiments for determining the congestion delay are discussed with reference
to step 520 in FIG.
5.
[00144] In step 625, the congestion control application may estimate a
value of time for a
plurality of expected passengers of the number of flights. Estimating a value
for passenger time may
be based on one or more variables such as, for example, trip purpose (e.g.,
business or personal
travel), identified characteristics of passenger (e.g., age, sex, education,
employment, income, etc.),
distance of travel, and ticket type (e.g., economy, business, first class,
etc.). Various embodiments
37
CA 3021282 2018-10-18
for estimating a value for passenger time are discussed below. Some
embodiments may determine
different values for different passengers. Some embodiments may estimate a
same value for one or
more passengers based on one or more common variables shared between the
passengers.
[00145] In an embodiment, the value of time for a passenger may be
estimated to be the same
as the value of travel time savings (VTTS) determined by the United States
Department of
Transportation (USDOT). Data associated with the VTTS may be obtained from a
USDOT server
via the control server 102. VTTS may vary depending on one or more other
variables. For example,
VTTS for a trip purpose defined as "business" may be $60.00 per hour. In
another example, VTTS
for a trip purpose defined as "personal" may be $32.60 per hour. Embodiments
include assuming an
annual rate of growth of 1.2 percent of real median household income to
determine an increase in
VTTS in any given year.
[00146] In an embodiment, a value of time for a passenger may be estimated
by dividing an
annual income of the passenger divided by 2,080 hours per year to obtain an
hourly value of time
for the passenger. Annual income of a passenger may be extracted from the
ticket database 230
(e.g., $100,000 per year). The extracted annual income of $100,000 per year
may be divided by
2,080 hours to obtain an estimated hourly value of time for the passenger of
$48.08. In an
embodiment, if income data is not available for a passenger, a default annual
income value may be
used. The default annual income value may be the median annual of airline
travelers. For example,
the median annual income of airline travelers in a given year (e.g., $70,000)
may be divided by
2,080 hours to obtain an estimated hourly value of time for the passenger of
$33.65. If data of a
current year median annual income is not available, data associated with a
prior year median annual
income may be used and an annual rate of growth of 1.2 percent for median
annual income may be
assumed.
[00147] In step 630, the congestion control application may select a
congestion delay target
based on an estimated time value of a plurality of customers. Various
embodiments for selecting the
congestion delay target are discussed with reference to step 530 in FIG. 5.
[00148] In step 640, the congestion control application may determine a
utilization level of the
slot based on the selected congestion delay target. Various embodiments for
determining the
utilization level are discussed with reference to step 540 in FIG. 5.
38
CA 3021282 2018-10-18
[00149] In step 650, the congestion control application may determine a
congestion premium
for one or more flights scheduled during the slot to achieve the defined
utilization level. The
congestion control application may determine the congestion premium based on,
for example, bid
data associated with one or more flight operators and/or ticket acquisition
data. Determining the
congestion premium may be an iterative process involving receiving updated bid
data and/or
updated ticket acquisition data to reevaluate the congestion premium. Various
embodiments for
determining the congestion premium for the one or more flights are discussed
with reference to step
550 in FIG. 5.
[00150] In step 660, the congestion control application may update a
premium schedule
database with the congestion premium determined in step 650. The premium
schedule database may
be located within the control server. The premium schedule database may be
updated by a processor
within the control server. The congestion premium may be allocated among, for
example, operators
of one or more flights and/or tickets for one or more flights scheduled during
the slot. For example,
if 5 flights are scheduled for a slot, a congestion premium of $5000 may be
charged to an operator
(e.g., a cargo delivery company) of one flight (e.g., a cargo aircraft) and
allocated among tickets for
the other 4 flights (e.g., passenger aircraft). The congestion premium may be
allocated evenly or
unevenly among the operators and/or tickets. For example, the congestion
premium may be divided
evenly among a plurality of tickets of flights scheduled during a slot. In
another example, one or
more variables (e.g., ticket price, ticket type, takeoff time of aircraft,
aircraft type, flight duration,
etc.) may be used to allocate the congestion premium proportionally based on
the one or more
variables. Tickets for flights having a longer takeoff time may be allocated a
larger portion of the
congestion premium since the longer takeoff time may cause more of a delay
than a flight having a
shorter takeoff time. A larger time gap between flights may be required for
larger aircraft due to a
larger wake created by large aircraft compared to small aircraft. A larger
portion of the congestion
premium may be allocated to tickets for large aircraft to account for a large
wait time required after
takeoff of a large aircraft.
[00151] In step 665, the congestion control application may provide the
congestion premium
allocated among tickets for the one or more flights scheduled during the slot
to a ticket vendor
server. The congestion premium allocated among tickets for the one or more
flights may be
transmitted electronically by the control server to the ticket vendor server.
The ticket vendor server
39
CA 3021282 2018-10-18
may provide tickets and the allocated congestion premium to a user device. One
or more users of
one or more user devices may select tickets having the allocated congestion
premium over a period
of time (e.g., an hour, several hours, a day, etc.). Data associated with
selected tickets having the
allocated congestion premium may be stored in the ticket vendor server. The
ticket acquisition data
(i.e. data associated with selected tickets having the allocated congestion
premium) may be obtained
by the control server, as discussed below with reference to step 670.
[00152] In step 670, the congestion control application may obtain ticket
acquisition data over
a time period from the ticket vendor server. The time period may a period of
time (e.g., an hour,
day, etc.) subsequent to providing the allocated congestion premium to the
ticket vendor server. The
ticket acquisition data may be obtained by transmitting a message to the
ticket vendor server
including a query for ticket acquisition data. The ticket vendor server may
transmit the ticket
acquisition data to the control server. The control server may identify the
received data as ticket
acquisition data by, for example, examining a host identification of the
transmitting device and/or a
data structure of the received data. The obtained ticket acquisition data may
be used to reevaluate
the congestion premium, as discussed below with reference to step 680.
[00153] In step 680, the congestion control application may reevaluate the
congestion premium
for the one or more flights scheduled during the slot based on the ticket
acquisition data over the
time period. The ticket acquisition data may be analyzed to determine a
selection rate for tickets
associated with a flight. If a determined selection rate is greater than an
expected selection rate, the
congestion premium may be increased. If a determined selection rate is less
than an expected
selection rate, the congestion premium may be decreased.
[00154] In step 690, the congestion control application may update the
premium schedule
database with the reevaluated congestion premium. Updating the premium
schedule database may
include storing the reevaluated congestion premium in the premium schedule
database.
[00155] The reevaluated congestion premium may be allocated among tickets
for one or more
flights. The allocated reevaluated congestion premium may be provided to the
ticket vendor server.
Steps 665, 670, 680, and 690 may be repeated if a difference between a
determined selection rate
exceeds an expected selection rate by a threshold value, such as, for example,
one standard
deviation, two standard deviations, or any fraction of a standard deviation.
CA 3021282 2018-10-18
[00156] While processes or blocks are presented in a given order,
alternative embodiments
may perform routines having steps, or employ systems having blocks, in a
different order, and some
processes or blocks may be deleted, moved, added, subdivided, combined, and/or
modified to
provide alternative or sub-combinations. Each of these processes or blocks may
be implemented in
a variety of different ways. In addition, while processes or blocks are at
times shown as being
performed in series, these processes or blocks may instead be performed in
parallel, or may be
performed at different times. When a process or step is "based on" a value or
a computation, the
process or step should be interpreted as based at least on that value or that
computation.
[00157] FIG. 7A illustrates taxi time functions for a runway having three
configurations,
according to various embodiments. An airport can have one or more
configurations. For example,
La Guardia Airport (LGA) operates in three typical configurations that re-
route aircraft operations
(e.g., takeoff and landing) to different runways. Different configurations can
result in different
congestion even with the same number of flight operations in a slot.
Predicting an airport
configuration for a slot can greatly increase accuracy of likely congestion
from a number of flight
operations scheduled during the slot.
[00158] FIG. 7B illustrates a deviation between a taxi time function and an
unimpeded
(congestion free) function, according to various embodiments. A weighted
average of samples taxi
times across a plurality of days having no identified delay other than excess
volume (e.g., no
identified weather event). The unimpeded function (shown as a dashed line) is
determined by
analyzing arrival samples above a minimum departure delay within a
corresponding time period
(e.g., within a same time period or within a threshold time differential). The
unimpeded function
can be mapped onto a region where arrival samples begin to encroach upon
departure samples.
Arrival samples typically taxi directly to a gate and thus typically represent
a quickest possible taxi
for a given airport. In contrast, departure samples may indicate that a
waiting period occurred due
to excess volume. The taxi time function indicates when the delay polynomial
derived from daily
operations deviates from a linear projection of the unimpeded (congestion
free) taxi rate and a
number of flights beyond a pre-defined threshold.
[00159] FIG. 7C is a line chart illustrating congestion delay predicted by
the taxi time
functions for a runway having three configurations by utilizing a time series
method, according to
41
CA 3021282 2018-10-18
various embodiments. A time series is a series of data points indexed (or
listed or graphed) in time
order. The time series can include a sequence taken at successive equally
spaced points in time (e.g.
1 hour slots). The time series is plotted on the line chart shown.
[00160] Time series analysis can be performed by either of auto-correlation
and/or cross-
correlation analysis. Autocorrelation analysis can be employed to identify
serial dependence. A time
series of a slot can have serial dependence if the slot at some time in the
series is statistically
dependent on the slot at another time. A series is serially independent if
there is no dependence
between any pair.
[00161] The time series analysis technique can include parametric or non-
parametric methods.
The parametric approach can assume that the underlying stationary stochastic
process has a certain
structure which can be described using a small number of parameters (for
example, using an
autoregressive or moving average model). The parameters of the model can be
estimated to describe
the stochastic process. A non-parametric approach can explicitly estimate the
covariance or the
spectrum of the process without assuming that the process has any particular
structure. The time
series analysis can be linear or non-linear, and univariate or multivariate.
[00162] FIG. 8 is a flow diagram illustrating a sample process 800 for
computing airport usage
functions (e.g., polynomial functions), according to various embodiments. The
process for
computing airport usage polynomials can include selecting an airport (e.g.,
manually or in response
to another action) (805). Daily usage metrics for the selected airport can be
retrieved from a usage
metrics library (e.g., within a database). A mean usage and/or a weighted
average of usage is
determined. The mean and/or weighted average usage is converted to a
cumulative form according
to a number of days of usage (810). Interpolating polynomial, 1-1, 0-2
Inflections, and continuity is
computed (815). An airport usage polynomial table is updated according to the
computed
interpolating polynomial (820).
[00163] FIG. 9 is a flow diagram illustrating a sample process 900 for
generating airport delay
polynomial tables, according to various embodiments. An airport delay
polynomial update query
can be received and an airport can be selected (e.g., manually or in response
to another action)
(905). Upon receiving the query and airport selection, airport operation
metrics can be retrieved
from an operation metrics library (e.g., within a database). Taxi samples
associated with a cause
42
CA 3021282 2018-10-18
label other than a volume label (e.g., a weather label) can be removed (910).
A histogram of
operations can be generated and binned by number of operations per slot and
minutes of delay
(915). The computed histogram of operations can be reduced to a two-
dimensional array by
computing a mean and/or weighted average of delays per bin (920). A curve fit
can be generated by
employing a least squares monotonic, 1-1 continuous method (925). The curve
fit can generate a
delay polynomial. The delay polynomial can be written to the airport delay
polynomial table (930).
[00164] FIG. 10 is a flow diagram illustrating a sample process 1000 for
extracting delay data
(e.g., taxi time data) associated with a cause category, according to various
embodiments. The
system can extract delay data associated with a cause label (e.g., volume
caused delay). For
example, the system can analyze and label delay causes for delay data (e.g.,
including taxi times
associated with aircraft operations) associated with an airport. Cause tables
having corresponding
time stamps with delay data can be generated and sorted by cause labels
(1010). Delay data can be
stored by delay category (1015). The cause tables can be populated with
probabilities corresponding
to each of a plurality of cause labels. If a weather event (e.g., snow storm)
is associated with a time
stamp corresponding to a slot time, a high probability is generated for the
cause label corresponding
to weather event for the slot time(s) in which the weather event occurred. If
a probability above a
threshold (e.g., above 50%) is associated with an event other than high
volume, a cause label
associated with the non-volume event can be presumed to be dominant. Cause
data can be
associated with delay data according to corresponding time stamps (1020).
Delay data associated
with cause data having a threshold association with a non-volume event can be
removed (1025).
Associations between delay duration data and delay cause data can be written
to a file object and
indexed by airport (1030).
[00165] FIG. 11 is a flow diagram illustrating a sample process 1100 for
computing a
maximum slot limit, according to various embodiments. The maximum slot limit
can be computed
by retrieving flight delay data (e.g., including taxi times associated with
aircraft operations)
associated with an airport (1110), retrieving cancellation data for the
airport (1115), removing delay
samples not associated with volume delays (1120), joining cause data with
delay data according to
date (1125), computing interpolation for cancellations by daily flight volume
(1130), evaluating
interpolation at a threshold interpolation value (1135), setting a maximum
delay and maximum slot
43
CA 3021282 2018-10-18
limit to a value (1140), and storing the maximum delay and maximum slot limit
to a parameters
table (1145).
[00166] FIG. 12 is a flow diagram illustrating a sample process 1200 for
computing limits for a
delay function, according to various embodiments. The system can set a maximum
delay to evaluate
a function (e.g., a polynomial function) at a particular slot limit (1205).
The minimum delay can be
set according to sorted minimum delay data (1210). Minimum delay data can
include minimum taxi
times associated with aircraft operations. The system can determine whether
there are more than
one runway configurations expected at the airport (1212).
[00167] If there is more than one runway configuration expected at the
airport (1212-Yes), the
system calculates a congestion free volume among the configurations (1215).
The system sets the
slot to a target volume (1220). The set number of flights for unimpeded taxi
time is determined
(1245). The maximum delay and number of flights is stored to a parameters
table (1250).
[00168] If there is not more than one runway configuration expected at the
airport (1212-No),
the system sets the slot to a target volume (1225). The system sets a delay to
evaluate a polynomial
function for the slot (1230). The system determines whether a differential
between delay and
unimpeded taxi exceeds a threshold value (1232).
[00169] If the differential between delay and the unimpeded taxi exceeds
the threshold value
(1232-Yes), the set number of flights for unimpeded taxi time is determined
(1245). The maximum
delay and number of flights is stored to a parameters table (1250).
[00170] If the differential between delay and the unimpeded taxi does not
exceed the threshold
value (1232-No), the slot is decremented (1235). The delay is reset to
evaluate a polynomial
function for the reset slot (1240). The system re-determines whether a
differential between delay
and unimpeded taxi exceeds a threshold value (1232). This process can repeat
until the differential
between delay and the unimpeded taxi exceeds the threshold value.
Computer
[00171] FIG. 13 is a diagrammatic representation of a machine in the
example form of a
computer system 1300 within which a set of instructions, for causing the
machine to perform any
one or more of the methodologies or modules discussed herein, may be executed.
For example, the
44
CA 3021282 2018-10-18
computer system 1300 may implement with the congestion server 102, the ATAS
server 104, the
ticket vendor server 106, and/or the user device 302.
[00172] In the example of FIG. 13, the computer system 1300 includes a
processor, memory,
non-volatile memory, and an interface device. Various common components (e.g.,
cache memory)
are omitted for illustrative simplicity. The computer system 1300 is intended
to illustrate a hardware
device on which any of the components described in the example of FIGS. 1-12
(and any other
components described in this specification) may be implemented. The computer
system 1300 may
be of any applicable known or convenient type. The components of the computer
system 1300 may
be coupled together via a bus or through some other known or convenient
device.
[00173] This disclosure contemplates the computer system 1300 taking any
suitable physical
form. As example and not by way of limitation, computer system 1300 may be an
embedded
computer system, a system-on-chip (SOC), a single-board computer system (SBC)
(such as, for
example, a computer-on-module (COM) or system-on-module (SOM)), a desktop
computer system,
a laptop or notebook computer system, an interactive kiosk, a mainframe, a
mesh of computer
systems, a mobile telephone, a personal digital assistant (PDA), a server, or
a combination of two or
more of these. Where appropriate, computer system 1300 may include one or more
computing
devices be unitary or distributed; span multiple locations; span multiple
machines; or reside in a
cloud, which may include one or more cloud components in one or more networks.
Where
appropriate, one or more computer systems 1300 may perform without substantial
spatial or
temporal limitation one or more steps of one or more methods described or
illustrated herein. As an
example and not by way of limitation, one or more computer systems 1300 may
perform in real
time or in batch mode one or more steps of one or more methods described or
illustrated herein.
One or more computer systems 1300 may perform at different times or at
different locations one or
more steps of one or more methods described or illustrated herein, where
appropriate.
[00174] The processor may be, for example, a conventional microprocessor
such as an Intel
Pentium microprocessor or Motorola PowerPC microprocessor. One of skill in the
relevant art will
recognize that the terms "machine-readable (storage) medium" or "computer-
readable (storage)
medium" include any type of device that is accessible by the processor.
CA 3021282 2018-10-18
[00175] The memory is coupled to the processor by, for example, a bus. The
memory may
include, by way of example but not limitation, random access memory (RAM),
such as dynamic
RAM (DRAM) and static RAM (SRAM). The memory may be local, remote, or
distributed.
[00176] The bus also couples the processor to the non-volatile memory and
drive unit. The
non-volatile memory is often a magnetic floppy or hard disk, a magnetic-
optical disk, an optical
disk, a read-only memory (ROM), such as a CD-ROM, EPROM, or EEPROM, a magnetic
or
optical card, or another form of storage for large amounts of data. Some of
this data is often written,
by a direct memory access process, into memory during execution of software in
the computer
system 1300. The non-volatile storage may be local, remote, or distributed.
The non-volatile
memory is optional because systems may be created with all applicable data
available in memory. A
typical computer system will usually include at least a processor, memory, and
a device (e.g., a bus)
coupling the memory to the processor.
[00177] Software is typically stored in the non-volatile memory and/or the
drive unit. Indeed,
storing an entire large program in memory may not even be possible.
Nevertheless, it should be
understood that for software to run, if necessary, it is moved to a computer
readable location
appropriate for processing, and for illustrative purposes, that location is
referred to as the memory in
this paper. Even when software is moved to the memory for execution, the
processor will typically
make use of hardware registers to store values associated with the software,
and local cache that,
ideally, serves to speed up execution. As used herein, a software program is
assumed to be stored at
any known or convenient location (from non-volatile storage to hardware
registers) when the
software program is referred to as "implemented in a computer-readable
medium." A processor is
considered to be "configured to execute a program" when at least one value
associated with the
program is stored in a register readable by the processor.
[00178] The bus also couples the processor to the network interface device.
The interface may
include one or more of a modem or network interface. It will be appreciated
that a modem or
network interface may be considered to be part of the computer system 1300.
The interface may
include an analog modem, ISDN modem, cable modem, token ring interface,
satellite transmission
interface (e.g., "direct PC"), or other interfaces for coupling a computer
system to other computer
systems. The interface may include one or more input and/or output devices.
The I/O devices may
46
CA 3021282 2018-10-18
include, by way of example but not limitation, a keyboard, a mouse or other
pointing device, disk
drives, printers, and other input and/or output devices, including a display
device. The display
device may include, by way of example but not limitation, a cathode ray tube
(CRT), liquid crystal
display (LCD), or some other applicable known or convenient display device.
For simplicity, it is
assumed that controllers of any devices not depicted in the example of FIG. 13
reside in the
interface.
[00179] In operation, the computer system 1300 may be controlled by
operating system
software that includes a file management system, such as a disk operating
system. One example of
operating system software with associated file management system software is
the family of
operating systems known as Windows from Microsoft Corporation of Redmond,
Washington, and
their associated file management systems. Another example of operating system
software with its
associated file management system software is the LinuxTM operating system and
its associated file
management system. The file management system is typically stored in the non-
volatile memory
and/or drive unit and causes the processor to execute the various acts
required by the operating
system to input and output data and to store data in the memory, including
storing files on the non-
volatile memory and/or drive unit.
[00180] Some portions of the detailed description may be presented in terms
of algorithms and
symbolic representations of operations on data bits within a computer memory.
These algorithmic
descriptions and representations are the means used by those skilled in the
data processing arts to
most effectively convey the substance of their work to others skilled in the
art. An algorithm is here,
and generally, conceived to be a self-consistent sequence of operations
leading to a desired result.
The operations are those requiring physical manipulations of physical
quantities. Usually, though
not necessarily, these quantities take the form of electrical or magnetic
signals capable of being
stored, transferred, combined, compared, and otherwise manipulated. It has
proven convenient at
times, principally for reasons of common usage, to refer to these signals as
bits, values, elements,
symbols, characters, terms, numbers, or the like.
[00181] It should be borne in mind, however, that all of these and similar
terms are to be
associated with the appropriate physical quantities and are merely convenient
labels applied to these
quantities. Unless specifically stated otherwise as apparent from the
following discussion, it is
47
CA 3021282 2018-10-18
appreciated that throughout the description, discussions utilizing terms such
as "processing" or
"computing" or "calculating" or "determining" or "displaying" or "generating"
or the like, refer to
the action and processes of a computer system, or similar electronic computing
device, that
manipulates and transforms data represented as physical (electronic)
quantities within the computer
system's registers and memories into other data similarly represented as
physical quantities within
the computer system memories or registers or other such information storage,
transmission or
display devices.
[00182] The algorithms and displays presented herein are not inherently
related to any
particular computer or other apparatus. Various general purpose systems may be
used with
programs in accordance with the teachings herein, or it may prove convenient
to construct more
specialized apparatus to perform the methods of some embodiments. The required
structure for a
variety of these systems will appear from the description below. In addition,
the techniques are not
described with reference to any particular programming language, and various
embodiments may
thus be implemented using a variety of programming languages.
[00183] In alternative embodiments, the machine operates as a standalone
device or may be
connected (e.g., networked) to other machines. In a networked deployment, the
machine may
operate in the capacity of a server or a client machine in a client-server
network environment, or as
a peer machine in a peer-to-peer (or distributed) network environment.
[00184] The machine may be a server computer, a client computer, a personal
computer (PC),
a tablet PC, a laptop computer, a set-top box (STB), a personal digital
assistant (PDA), a cellular
telephone, an iPhone, a Blackberry, a processor, a telephone, a web appliance,
a network router,
switch or bridge, or any machine capable of executing a set of instructions
(sequential or otherwise)
that specify actions to be taken by that machine.
[00185] While the machine-readable medium or machine-readable storage
medium is shown in
an exemplary embodiment to be a single medium, the term "machine-readable
medium" and
"machine-readable storage medium" should be taken to include a single medium
or multiple media
(e.g., a centralized or distributed database, and/or associated caches and
servers) that store the one
or more sets of instructions. The term "machine-readable medium" and "machine-
readable storage
medium" shall also be taken to include any medium that is capable of storing,
encoding or carrying
48
CA 3021282 2018-10-18
a set of instructions for execution by the machine and that cause the machine
to perform any one or
more of the methodologies or modules of the presently disclosed technique and
innovation.
[00186] In general, the routines executed to implement the embodiments of
the disclosure, may
be implemented as part of an operating system or a specific application,
component, program,
object, module or sequence of instructions referred to as "computer programs."
The computer
programs typically comprise one or more instructions set at various times in
various memory and
storage devices in a computer, and that, when read and executed by one or more
processing units or
processors in a computer, cause the computer to perform operations to execute
elements involving
the various aspects of the disclosure.
[00187] Moreover, while embodiments have been described in the context of
fully functioning
computers and computer systems, those skilled in the art will appreciate that
the various
embodiments are capable of being distributed as a program product in a variety
of forms, and that
the disclosure applies equally regardless of the particular type of machine or
computer-readable
media used to actually effect the distribution.
[00188] Further examples of machine-readable storage media, machine-
readable media, or
computer-readable (storage) media include but are not limited to recordable
type media such as
volatile and non-volatile memory devices, floppy and other removable disks,
hard disk drives,
optical disks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital
Versatile Disks,
(DVDs), etc.), among others, and transmission type media such as digital and
analog
communication links.
[00189] In some circumstances, operation of a memory device, such as a
change in state from a
binary one to a binary zero or vice-versa, for example, may comprise a
transformation, such as a
physical transformation. With particular types of memory devices, such a
physical transformation
may comprise a physical transformation of an article to a different state or
thing. For example, but
without limitation, for some types of memory devices, a change in state may
involve an
accumulation and storage of charge or a release of stored charge. Likewise, in
other memory
devices, a change of state may comprise a physical change or transformation in
magnetic orientation
or a physical change or transformation in molecular structure, such as from
crystalline to amorphous
or vice versa. The foregoing is not intended to be an exhaustive list in which
a change in state for a
49
CA 3021282 2018-10-18
binary one to a binary zero or vice-versa in a memory device may comprise a
transformation, such
as a physical transformation. Rather, the foregoing is intended as
illustrative examples.
[00190] A storage medium typically may be non-transitory or comprise a non-
transitory
device. In this context, a non-transitory storage medium may include a device
that is tangible,
meaning that the device has a concrete physical form, although the device may
change its physical
state. Thus, for example, non-transitory refers to a device remaining tangible
despite this change in
state.
Remarks
[00191] The foregoing description of various embodiments of the claimed
subject matter has
been provided for the purposes of illustration and description. It is not
intended to be exhaustive or
to limit the claimed subject matter to the precise forms disclosed. Many
modifications and
variations will be apparent to one skilled in the art. Embodiments were chosen
and described in
order to best describe the principles of the invention and its practical
applications, thereby enabling
others skilled in the relevant art to understand the claimed subject matter,
the various embodiments,
and the various modifications that are suited to the particular uses
contemplated.
[00192] While embodiments have been described in the context of fully
functioning computers
and computer systems, those skilled in the art will appreciate that the
various embodiments are
capable of being distributed as a program product in a variety of forms, and
that the disclosure
applies equally regardless of the particular type of machine or computer-
readable media used to
actually effect the distribution.
[00193] Although the above Detailed Description describes certain
embodiments and the best
mode contemplated, no matter how detailed the above appears in text, the
embodiments may be
practiced in many ways. Details of the systems and methods may vary
considerably in their
implementation details, while still being encompassed by the specification. As
noted above,
particular terminology used when describing certain features or aspects of
various embodiments
should not be taken to imply that the terminology is being redefined herein to
be restricted to any
specific characteristics, features, or aspects of the invention with which
that terminology is
associated. In general, the terms used in the following claims should not be
construed to limit the
CA 3021282 2018-10-18
invention to the specific embodiments disclosed in the specification, unless
those terms are
explicitly defined herein. Accordingly, the actual scope of the invention
encompasses not only the
disclosed embodiments, but also all equivalent ways of practicing or
implementing the
embodiments under the claims.
[00194]
The language used in the specification has been principally selected for
readability and
instructional purposes, and it may not have been selected to delineate or
circumscribe the inventive
subject matter. Accordingly, the disclosure of various embodiments is intended
to be illustrative,
but not limiting, of the scope of the embodiments, which is set forth in the
following claims.
51
CA 3021282 2018-10-18
