The specification relates generally to computing methods and systems, and specifically to methods and systems for mitigating the impact on provider computing systems associated with transfer of provider-dependent items.
The use of certain items, such as tickets providing access to venues, vehicles, or the like, is dependent on provider entities other than the holder of the item. In the case of an airline ticket, for example, use of the ticket (La, travel on the corresponding flight) is dependent on an airline operating an aircraft and related computing and other systems to manage such operation. These items may therefore be referred to as provider-dependent items. A provider-independent item, in contrast, can typically be used, consumed, or the Ike, under the control of the holder of the provider-independent item alone. For example, the holder (e.g., the owner) of an item of apparel may generally use that item of apparel independently of the provider from which the apparel was purchased.
While provider-independent items such as the item of apparel mentioned above may be readily transferred to other holders, the transfer of a provider-dependent item is complicated, or in some cases rendered impossible, by the very dependency of the item's use on the item's provider. In the case of an airline ticket as noted above, for example, use of the ticket may be require (i.e., may be dependent) on identifying information for a specific traveler who holds the ticket being stored in a computing system maintained by the airline. In some systems, such information cannot be updated, and transferring the ticket is therefore impossible. Further, even when updating such identifying information is possible, such updates may impose a substantial computational burden on the above computing system, e.g., to propagate updated information to various databases and/or other components of the system. As will be apparent, each successive transfer of the ticket to a further holder imposes such a burden on the system.
An aspect of the specification provides a method, comprising: maintaining, for a pool of items, an available quantity indicator; selecting a transferrable quantity associated with the pool of items; updating the available quantity indicator according to the transferrable quantity; obtaining a set of unique item identifiers equal in number to the transferrable quantity; publishing a set of transferrable item definitions equal in number to the transferrable quantity, each transferrable item definition including (i) a respective unique identifier, (ii) a cost, and (iii) an expiry time; receiving, prior to the expiry time, a conversion request including a unique identifier from a published transferrable item definition; and responsive to authentication of the conversion request, receiving purchaser identification data associated with the conversion request, and generating a purchase record corresponding to an item from the pool, the purchase record linking the purchaser identification data with the item.
Embodiments are described with reference to the following figures, in which:
The system 100 includes a provider subsystem 108, e.g., operated by or on behalf of the above-mentioned provider entity, including various computing components enabling the deployment of assets such as the aircraft 104, as well as the sale of tickets granting access to the aircraft 104.
In particular, the provider subsystem 108 includes a reservation repository 112 containing a variety of data defining provider-dependent items such as flight tickets, and related data. For example, the repository 112 can include records defining scheduling information for flights operated by the provider, using the aircraft 104 and/or other aircraft. The repository 112 can also include pricing data for the above-mentioned flights. Further, the repository 112 can include purchase records defining any issued tickets for a given flight operated using the aircraft 104. A purchase record, i.e., a ticket, includes or is otherwise associated with identifying information for the holder of that ticket. The identifying information can be stored, for example, in a passenger name record (PNR) or the like, as will be apparent to those skilled in the art. The identifying information can include a name, residence information (e.g., an address of residence), a travel document identifier such as a passport number, and the like.
Purchase records can be created in the repository 112 by a reservation application 116 of the provider subsystem 108. The reservation application 116 (which may also be referred to as a central reservation system, or CRS) can be executed, for example, by one or more servers or other suitable computing hardware deployed within the provider subsystem 108. The reservation application 116 can implement or otherwise interconnect with computing infrastructure to implement a website and/or other distribution channels enabling travelers or other entities acting on behalf of such travelers to purchase flight tickets (leading to the creation of purchase records in the repository 112). For example, the provider subsystem 108 can be connected to a network 120 including any suitable combination of local and wide-area networks, to which a plurality of client devices 124-1, 124-2, and 124-3 (collectively, the client devices 124, and generically, a client device 124) are also connected. Each client device 124 can include a personal computing device such as a smart phone, tablet computer, desktop computer or the like, or a further subsystem consisting of servers or other suitable computing devices, e.g., operated by a travel agency, aggregator entity, or the like. The client devices 124, of which there may be fewer or more than the three illustrated in
The provider subsystem 108 can also include an inventory repository 128, containing data defining flights operated by the provider entity, as well as a number of seats available (i.e., not yet associated with a purchase record) for each such flight. In some examples, the inventory repository 128 is integrated with the reservations repository 128. In this example, however, the repository 128 is illustrated separately from the reservations repository 112 for clarity. The generation of a purchase record in the repository 112 may therefore involve, among other stages, interaction between a client device 124 and the reservation application 116, and querying of the inventory repository 128 by the reservation application 116.
The provider subsystem 108 also includes, in this example, an access control application 132. The application 132 can be executed on one or more servers within the provider subsystem 108, whether the same devices as those executing the reservation application 116 or distinct devices. In the context of air travel, the application 132 may also be referred to as a departure control system (DCS). The access control application 132 implements various functions related to controlling access to the aircraft 104 for a given flight. For example, the application 132 can be configured to retrieve information from the repository 112, generate access documents (e.g., boarding passes) corresponding to purchase records from the repository 112 responsive to confirming that travelers requesting such access documents are the travelers identified in the purchase records. The application 132 may also be configured to provide traveler identifying information to regulatory entities external to the provider subsystem 108, for example. Any or all of the above data may be stored in an access control repository 136 connected with the application 132.
As will be apparent from the above discussion, the generation of a purchase record indicating that a particular individual can be granted access to the aircraft 104 at a specified time can involve the transmission, processing, and storage of data by numerous components of the provider subsystem 108. The above operations therefore impose a computational burden on the provider subsystem 108, in the form of computing time, storage capacity, network bandwidth, and the like. The above burden may render the transfer of a purchase record from one holder to another—that is, transferring the right to access the aircraft 104 from one individual to another—technically impractical, even if such a transfer is permissible under various regulatory regimes. Specifically, transferring ownership of a ticket may involve further interaction between a client device 124 and the application 116, followed by further updates to the repository 112, which in turn may trigger further computational activity by the application 132 and updates applied to the repository 136. Omitting such updates may result in an individual attempting to access the aircraft 104 presenting identifying information that does not match the repositories 112 and 136. Therefore, each transfer (e.g., if a ticket is transferred more than once) requires the same computationally intensive set of updates (again, when such updates are even permissible).
For the above reasons, many provider subsystems 108 do not implement functionality enabling the transfer of purchase records. That is, in many systems, a purchased flight ticket is permanently linked to a specific individual, and cannot enable any other individual to access the aircraft 104.
In contrast the above-mentioned systems, the system 100 includes certain components, and implements certain functionality, to enable transfer of provider-dependent items such as flight tickets. The system 100, as will be discussed below, enables transfer of provider-dependent items while mitigating the computational impact noted above that would typically result from such transfers, and involving minimal modifications to many components of the provider subsystem 108.
In particular, the provider subsystem 108 also includes a publication application 140, which may be executed by a further computing device or set of devices (e.g., one or more servers) within the provider subsystem 108. The publication application 140, in other examples, may be integrated with the reservation application 116, but is illustrated separately in
Each client device 124 executes a respective client application 152-1, 152-2, and 152-3 (collectively, the client applications 152, and generically, a client application 152). The client applications 152 can be deployed to the client devices 124 from the ledger subsystem 148 or, in some examples, from the provider subsystem 108. In general, execution of the client applications 152 by the client devices 124 enables the client devices 124 to interact with the provider subsystem 108 and the ledger subsystem 148 to purchase transferrable provider-dependent items. Further, following such purchase, the client devices 124 can transfer ownership of the transferrable items to other entities via interactions with the ledger subsystem 148, without any involvement on the part of the provider subsystem 108. The above-mentioned transferrable items can be converted, one time only, to purchase records according to the process outlined above via interaction between a client device 124 associated with the current holder of a transferrable item, and the provider subsystem 108. That is, a transferrable item can be converted to a flight ticket according to the process set out earlier, regardless of how many transfers of ownership have occurred previously to such conversion, and without the involvement of the applications 116 or 132, or the repositories 112 and 136, in such transfers.
Before discussing the functionality implemented by the system 100 in greater detail, certain components of the provider subsystem 108 will be described with reference to
The processor 200 is also interconnected with a communications interface 208, which enables the provider subsystem 108 to communicate with the other computing devices of the system 100 via the network 120. The communications interface 208 therefore includes any necessary components (e.g., network interface controllers (NICs), radio units, and the like) to communicate via the network 120. The specific components of the communications interface 208 are selected based on upon the nature of the network 120. The provider subsystem 108 can also include input and output devices connected to the processor 200, such as keyboards, mice, displays, and the like (not shown).
The components of the provider subsystem 108 mentioned above can be deployed in a single enclosure, or in a distributed format. In some examples, therefore, the provider subsystem 108 includes a plurality of processors, either sharing the memory 204 and communications interface 208, or each having distinct associated memories and communications interfaces.
The memory 204 stores a plurality of computer-readable programming instructions, executable by the processor 200, The instructions stored in the memory 204 include the applications 116, 132, and 140 mentioned above. The memory 204 also stores the repositories 112, 136, and 128 in this example. In other examples, any one or more of the repositories 112, 136, and 128 can be stored at a distinct computing device and accessed by the processor 200 via the communications interface 208.
Turning to
At block 305, the provider subsystem 108 is configured to obtain a transferrable quantity. For example, the processor 200, via execution of the publication application 140, can receive input data (e.g., from an operator computing device coupled to the provider subsystem 108, from a local input device, or the like) defining the transferrable quantity. In the present example, the transferrable quantity represents a number of seats on a specific flight operated by the provider to be enabled for transferrable sale. By default (in the absence of block 305), all seats on a flight may be designated only for legacy sale mechanisms, in which purchase of a seat leads to the generation of a non-transferrable flight ticket as outlined earlier in connection with the reservation application 116 and the repository 112.
The transferrable quantity can represent any portion of the seats on a flight. More generally, the transferrable quantity can represent any portion (up to and including all) of a pool of provider-dependent items. The transferrable quantity can also be determined automatically, e.g. by the publication application 140 according to any suitable business logic that is beyond the scope of the present discussion. The transferrable quantity can take the form of an absolute number, or a fraction (e.g., one half of the available pool of provider-dependent items). In embodiments where the transferrable quantity is received as input data from an administrator or the like, the application 140 can be configured to host an interface (e.g., a web-based user interface or the like) enabling the receipt of input data. For instance, the application 140 can be configured to query the inventory repository 128 for a list of upcoming flights, present those flights via the above-mentioned interface, and receive input data selecting one or more flights and specifying corresponding transferrable quantities.
At block 310, in response to receiving the transferrable quantity at block 305, the application 140 is configured to update an availability indicator associated with the pool of provider-dependent items in the inventory repository 128. The repository 128 can, for example, include a count of remaining (e.g., unsold) items in the pool (e.g., seats on a flight), and/or a count representing items that are no longer available for purchase, having already been purchased or otherwise allocated to travelers. The above-mentioned count can therefore be incremented by the transferrable quantity from block 305.
Turning to
The available quantity indicator(s) in the repository 128, as will be apparent to those skilled in the art, can be employed by the reservation application 116 in connection with processing future ticket purchases. For example, the reservation application 116 can be configured to determine, from the “inventory” and “allotment” fields shown in
Returning to
Obtaining the identifiers at block 315 can include generating, by the application 140 itself, the identifiers in the form of random strings, hashes based on an identifier of the application 140 itself or the provider subsystem 108 more generally. For example, a private encryption key of the application 140 can be used as input for generating the identifiers at block 315. In other examples, the application 140 can request the unique identifiers from the ledger subsystem 148, which can in turn be configured to generate a set of unique identifiers and return the identifiers to the application 140. In some examples, the unique identifiers can be stored in the repository 128 once they are obtained, but storage in the repository 128 can also be omitted, as the unique identifiers will also be tracked in the ledger 144.
At block 320, the application 140 is configured to publish a set of transferrable item definitions, equal in number to the transferrable quantity 400 from block 305. Each item definition includes one of the identifiers from block 315, as well as one or more additional attributes. The application 140 is therefore configured to obtain, prior to publication; the above-mentioned attributes. The attributes include at least a cost associated with each transferrable item identifier, and an expiry time associated with each transferrable item identifier. The cost represents a price to be paid to the provider entity in order to transfer ownership of the relevant transferrable item definition to the paying entity. The cost attribute can be received as input data, e.g., from an administrator similarly to the input process described earlier in connection with the transferrable quantity itself. In other examples, the cost can be determined automatically or semi-automatically by the application 140, e.g., by querying the reservation application 116 for pricing information corresponding to the relevant flight.
The expiry time attribute indicates a time by which the transferrable item definition must be converted to a purchase record in the repository 112 in order to secure access to the aircraft 104 (or any other provider-dependent item, as will be apparent). In other words, if a conversion process, described below in greater detail, is not performed before the expiry time, the transferrable item definition becomes inert, and does not provide access to the aircraft 104. The expiry time can also be received as input as mentioned above. In other examples, the expiry time can be obtained by the application 140 by querying the access control application 132. For instance, in the context of air travel, the access control application 132 may determine a departure control window, which specifies a time period prior to the departure of a flight by which all passenger information must be finalized. Upon closure of the departure control window, for example, it may no longer be possible to create further reservations purchase records (i.e., it may not longer be possible to sell tickets on the flight). The expiry time can therefore be set as the departure control window, e.g., in the form of a number of hours or days before the departure time of the corresponding flight.
Publication of the set of transferrable item definitions includes providing the definitions to the ledger 144. The specific mechanisms by which the item definitions are written to the ledger 144 depend on the nature of the ledger 144 and the underlying ledger subsystem 148. For example, in the case of a centrally managed ledger 144, the application 140 can be configured to establish a connection with the ledger subsystem 148, e.g., by providing account credentials or the like, and can then transmit a request to write the transferrable item definitions into the ledger 144. In other examples, in which the ledger 144 is a distributed ledger, the application 140 can generate one or more transaction records (e.g., five transaction records in this example, one for each transferrable item definition) and propagate the transaction records (e.g., blocks) to the other nodes of the distributed ledger.
Turning to
In addition, each definition 500 is associated with an owner identifier (“Owner ID”) in the ledger 144. The owner identifier indicates which entity holds the right convert the relevant transferrable item definition into a purchase record, and/or to transfer the item definition to another holder. In the example shown in
Returning to
The determination at block 325 can be performed in a wide variety of ways. For example, as noted earlier, the application 116 or an associated component of the provider subsystem 108 can host a website or other distribution mechanism enabling the client applications 152 to obtain definitions of available flights to book seats on. The reservation application 116 can therefore transmit a list of flights and/or other items to a client device in response to a search request received from the client device 124. The search request, e.g., generated via execution of the corresponding application 152, can include search parameters such as a travel date, origin and destination locations, and the like. In response to the search request, the reservation application 116 can be configured to retrieve search results from the repositories 112 and 128 and present the search results to the client device 124. In addition, the application 116 can query the application 140 for transferrable item definitions corresponding to any of the flights identified in the above-mentioned search results. The client device 124 may therefore present selectable items for purchase that include either or both of conventional tickets whose purchase results in the creation of a purchase record in the repository 112, and transferrable item definitions.
Selection of a transferrable item definition at the client device 124 can initiate a payment flow implemented by the application 116. Rather than initiate a conventional ticket-purchase process to create a purchase record in the repository 112, however, the application 116 can transmit a command to the application 140 to initiate a transfer of ownership for the selected transferrable item definition.
The determination at block 325 can therefore include a determination, at the application 140, of whether any commands to initiate such a transfer have been received, whether from the application 116 or from another source.
When the determination at block 325 is affirmative, the application 140 proceeds to block 330, and initiates a transfer of ownership of the relevant transferrable item definitions. The transfer updates the owner identifier associated with the transferrable item definition(s) to be transferred from the identifier of the application 140 itself, to another owner identifier, such as an identifier of a client application 152.
Turning to
In response to the message 608, the ledger 144 is updated as shown in
In other examples, the transfer command initiating the performance of block 330 can originate at an external entity, such as a marketplace that lists transferrable item definitions from the ledger, collects payment for the purchase of such definitions, and upon completion of a payment process, transmits a command to the previous holder of the purchase transferrable item (e.g., and also transfers a portion of the payment to the entity operating the application 140). The transfer, in other words, need not be initiated by any portion of the provider subsystem 108.
Following the transfer at block 330, or following a negative determination at block 325, the provider subsystem 108 proceeds to block 335. At block 335, the application 140 can determine whether the expiry time mentioned earlier has arrived for any of the transferrable item definitions 500 in the ledger 144 (regardless of current ownership of the definitions 500). When the determination at block 335 is affirmative, the application 140 can instruct the ledger subsystem 148 to discard the expired definitions 500. The ledger subsystem 148 can also notify the relevant owners (e.g., client devices 124) of expiry and/or impending expiry of transferrable item definitions 500. In other examples, rather than notifications being generated and transmitted to the client devices 124, by the subsystem 148, the client devices 124 themselves can be configured, via execution of the applications 152, to query the subsystem 148 periodically for notifications and/or other information. For example, the client devices 124 can query the subsystem 148 for changes to definitions, for definitions associated with the relevant application 152 that are near expiry, and the like. Other notifications, such as those indicative of changes to a flight (e.g., a modified departure time), can also lead to notifications from the application 140 to the client devices 124 via the ledger subsystem 148. In other examples, the ledger subsystem 148 can implement block 340 automatically, without any involvement by the application 140.
At block 345, e.g., following a negative determination at block 335 for at least one transferrable item definition 500, the provider subsystem 108 is configured to determine whether a conversion request has been received in connection with a valid (i.e., not expired) definition 500. As will be apparent, conversion requests need not closely follow the initial transfer of a definition 500 from block 330. In fact, the transfer at block 330 can occur days, weeks, or months prior to a conversion request. Of particular note, following the transfer at block 330, the provider subsystem 108 has collected payment for the corresponding definition 500, but has not performed the processing and updating of the repositories 112 and 136 involved in generating a purchase record (e.g., a flight ticket). The applications 116 and 132 of the provider subsystem 108, in fact, need not perform any actions in connection with the transferred definition until a conversion request is received, despite the fact that the transferred definition 500 may be transferred to any number of additional entities in the meantime. Such transfers are tracked at the ledger subsystem 148, and need not involve the provider subsystem 108, thus reducing the computational impact of ownership transfers on the provider subsystem 108.
For example, turning to
Turning to
Returning briefly to
At block 355, in response to authenticating the conversion request 800, the application 116 is configured to obtain purchaser data, such as the identifying information mentioned earlier, and to generate a purchase record for storage in the repository 112. As will be apparent to those skilled in the art, the generation of the purchase record may also trigger additional processes at the application 132, e.g., to update the repository 136. Following the conversion request 800, the client application 152-2 can also be configured, in some examples, to send a final transfer request to the ledger subsystem 148, to return ownership of the definition 500-2 to the application 140, as the definition 500-2 has effectively been exchange with a flight ticket. Alternatively, the application 140 can instruct the ledger subsystem 148 to discard or otherwise inactivate the definition 500-2 in response to successful authentication of the conversion request 800.
Various additional functionality can be implemented by the system 100, in addition to that set out above. For example, in some implementations, transferrable item definitions 500 can include auxiliary attributes, obtained at block 315, prior to publication. Examples of auxiliary attributes include links from one definition 500 to another (e.g., an auxiliary attribute can include the unique identifier of another definition 500). Such links serve to package definitions 500 together, e.g., imposing a requirement that the definitions 500 be transferred together. Other examples of auxiliary attributes include conditions defining whether definitions 500 can be linked after their initial publication, e.g., by third parties such as the client applications 152.
In some examples, separate ledgers 144 (e.g., separate distributed ledgers, or separate repositories within the ledger subsystem 148) may be created for each pool of transferrable items (e.g., each individual flight, in the air travel context). Following expiry of the transferrable items for a given pool, the corresponding repository can then simply be discarded, reducing the storage requirements at the ledger subsystem 148, and/or the computational load associated with maintaining distributed ledgers.
The scope of the claims should not be limited by the embodiments set forth in the above examples, but should be given the broadest interpretation consistent with the description as a whole.