Patent Application
20170061333
The present application is related to traffic management systems, and more specifically to methods and systems of airport congestion management to reduce aircraft interference at peak times.
A majority of congestion delays emanate from chronically congested airports serving large populations. Despite a long history of flight congestion delays experienced by airline passengers at airports serving large populated regions, no solution for relieving congestion delays has been established.
Ground based air traffic personnel may direct aircraft operations (e.g., a takeoff or landing) at an airport. Air traffic personnel may enforce traffic separation rules, which ensure aircraft maintain a minimum amount of empty space around them at all times. Air traffic trailing separation rules may increase aircraft safety by reducing the likelihood of an aircraft flying into a wake of a leading aircraft and stalling. Air traffic separation rules may also contribute to airport congestion by mandating a time period between aircraft operations.
Certain aspects of the invention involve an airport congestion management method and system 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.
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 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.
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.
Certain aspects of the technology disclosed involve an airport congestion management method and system to reduce congestion delays. Many airports serving high population areas are plagued with chronic congestion. Due to a “use it or lose it” policy for slots, airlines are willing to tolerate congestion delays that may cost passengers valuable time. Embodiments of the present invention may account for the value of passenger time in determining a utilization reduction for a time slot. Embodiments may seamlessly integrate into existing infrastructure and create incentives to reduce congestion, for example, at peak times.
Embodiments may reduce congestion delays by altering ticket selection patterns to conform to a determined utilization level of a runway for a period of time (e.g., a slot). Embodiments include determining a congestion premium for one or more flights scheduled during a slot capable of achieving a determined utilization level.
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).
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.
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 capacity at non-congested times.
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 Aug. 1, 2015. The ATAS server 104 may include an interface 114 configured to communicate with an interface 112 of the congestion control server 102. The ATAS server 104 may provide air traffic operation data to the congestion control server 102 by utilizing interface 114 to communicate the air traffic operation data to interface 112.
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 congestion control server 102. The ticket vendor server 106 may provide ticket data to the congestion 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 congestion control server 102 via interface 116.
Congestion control server 102 may determine a congestion premium for tickets for a number of flights. Congestion 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. The databases may be contained on separate physical memory devices within the congestion control server 102 or can be maintained in separate addresses of physical memory within the congestion control server 102. Congestion control server 102 may communicate with the ATAS server 104 and the ticket vendor server 106. Congestion control server 102 may communicate with ATAS server 104 using, for example, interface 112. Congestion control server 102 may communicate with ticket vendor server 106 using, for example, interface 122. Congestion control server 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 congestion control server 102 are described below with reference to
The congestion 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 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.
The databases of the congestion 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.
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.
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.).
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.).
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.
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.
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 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.
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
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).
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 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.
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 congestion control server 102. For example, if the congestion 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 congestion control server 102 may allocate the congestion premium among available tickets. The congestion 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.
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 disincentive 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.
Referring to
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.
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.
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 congestion control server 102 including the air traffic data. The congestion 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 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.
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 congestion control server 102 including the ticket data. The congestion 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.
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.
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 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.
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.
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.
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.
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.
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 congestion 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.
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.
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).
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 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.
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.
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.
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 by 5%, the congestion control application may determine that an initial congestion premium of $50 may achieve the determined utilization level.
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).
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.
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 expected 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.
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.
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.
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.
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.
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 congestion control server, such as, for example, the congestion control server 102 discussed in
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 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.
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.
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.
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.
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.
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, 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.
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.
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.
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.
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. 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.
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.
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 indicated a number of tickets sold having the congestion premium. Based on the ticket acquisition data, the congestion control application may reevaluate the congestion 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.
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 congestion control server, as described with reference to
In step 600, the congestion control application of the congestion 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.
The congestion 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 congestion control server. The congestion control server may receive the air traffic data from the ATAS server. The congestion 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.
In step 605, the congestion control application of the congestion control server may store the air traffic data into an air traffic database (e.g., air traffic database 210) within the congestion control server. The air traffic database may be a memory device (or a portion of a memory device) of the congestion control server configured to store the air traffic data. The air traffic database may be electrically connected to a processor of the congestion control server such that the processor may query the air traffic database.
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
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
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 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.
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 congestion 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.
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.
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
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
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
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 congestion control server. The premium schedule database may be updated by a processor within the congestion 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.
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 congestion control server to the ticket vendor server. The ticket vendor server 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 congestion control server, as discussed below with reference to step 670.
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 congestion control server. The congestion 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.
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.
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.
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.
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 subcombinations. 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.
In the example of
This disclosure contemplates the computer system 700 taking any suitable physical form. As example and not by way of limitation, computer system 700 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 700 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 700 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 700 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 700 may perform at different times or at different locations one or more steps of one or more methods described or illustrated herein, where appropriate.
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.
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.
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 700. 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.
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.
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 700. 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 include, by way of example but not limitation, a keyboard, a mouse or other pointing device, disk drives, printers, a smayner, 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
In operation, the computer system 700 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, Wash., and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux™ 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.
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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.
This application claims the benefit of U.S. provisional patent application No. 62/209,226, filed on Aug. 24, 2015, which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62209226 | Aug 2015 | US |
