Activity time booking and management system

Abstract

The methods presented herein relate to the reservation and management of activity time available for performing activities, such as tea time, or other items included in the inventory, which may be bought, sold, or offered for sale. Reserved time may be monitored and managed electronically, such as in a tea time sheet containing tea time details, in order to complete a user's request to make a transaction for tea time. An electronic token may be created for each reserved time. Transactions may include listing reserved time for sale, purchasing listed time, submitting an offer to buy unlisted time, purchasing unlisted tea time, and removing time from the list. Additional services, such as guarantees and upselling, may be offered to the user when requesting a transaction.

Description

Technical Field

[0001] Claim of Priority

[0001] This is a PCT application of U.S. Patent Application No. 18 / 631,883, filed on April 10, 2024 (Attorney Docket No. 782985.000004), titled "ACTIVITY TIME RESERVATION AND MANAGEMENT SYSTEM", the entire content of which is incorporated herein by reference, claiming the benefit of both U.S. Provisional Application No. 63 / 458,401, filed on April 10, 2023 (Attorney Docket No. 782985.000001), titled "SYSTEM AND METHOD FOR BOOKING TOKENIZED TEE TIMES WHICH CREATES A SECONDARY MARKET REVENUE FOR GOLF COURSES", and U.S. Provisional Application No. 63 / 600,873, filed on November 20, 2023 (Attorney Docket No. 782985.000002), titled "ACTIVITY TIME RESERVATION AND MANAGEMENT SYSTEM".

[0002]

[0002] The present disclosure relates to managing and completing transactions related to activity time.

Background Art

[0003]

[0003] The electronic storefront enables venue owners and inventory resellers, such as golf course clubs or golf course partners, to offer users bookings, including tee times. A user, such as a golfer, can log in to a website containing available bookings for a golf course and then purchase a booking for later use. Many industries, such as the golf course booking industry, do not have access to a system that allows users to browse and purchase inventory from multiple venues at once. Furthermore, users are not able to buy, sell, offer, or resell inventory among themselves. Along with these transactions, it has also not been possible to offer additional services, merchandise, or upselling opportunities, such as types of guarantees. As a result, the offerings available to users are significantly limited, and the value of a booking is reduced, at least by the risk that the booking may be lost or canceled. [Overview of the Initiative]

[0004]

[0004] Various embodiments of this disclosure will be described with reference to the drawings. [Brief explanation of the drawing]

[0005] [Figure 1]

[0005] A diagram showing an environment that may be used to book and manage activity times according to various embodiments. [Figure 2A]

[0006] A diagram illustrating exemplary displays for reservation-related content in various embodiments. [Figure 2B] A diagram illustrating exemplary displays for reservation-related content in various embodiments. [Figure 2C] A diagram illustrating exemplary displays for reservation-related content in various embodiments. [Figure 2D]A diagram illustrating exemplary displays for reservation-related content in various embodiments. [Figure 2E] A diagram illustrating exemplary displays for reservation-related content in various embodiments. [Figure 2F] A diagram illustrating exemplary displays for reservation-related content in various embodiments. [Figure 3A]

[0007] A diagram illustrating exemplary schematic representations of market transactions in various embodiments. [Figure 3B] A diagram illustrating exemplary schematic representations of market transactions in various embodiments. [Figure 3C] A diagram illustrating exemplary schematic representations of market transactions in various embodiments. [Figure 4]

[0008] A diagram illustrating an exemplary process for completing activity time-related transactions through various embodiments. [Figure 5]

[0009] A diagram illustrating exemplary processes for making unsolicited offers for activity time through various embodiments. [Figure 6]

[0010] A diagram illustrating the logical configuration of a typical set of components for an exemplary computing device in various embodiments. [Figure 7]

[0011] A diagram illustrating an environment in which various embodiments can be implemented. [Modes for carrying out the invention]

[0006]

[0012] Various embodiments are described below. For explanatory purposes, specific configurations and details are given to provide a complete understanding of the embodiments. However, it will be apparent to those skilled in the art that these embodiments may also be practiced without their specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the embodiments described.

[0007]

[0013] The systems and methods according to various embodiments of this disclosure can overcome one or more of the above or other shortcomings experienced in conventional methods of managing and reserving inventory, such as tea time and processing-related transactions. In particular, the various embodiments provide methods for conducting transactions of items from inventory, such as tea time or other electronic offerings, buying, selling, and making offers for them, and completing related processes. Related processes may include updating inventory information, customer information, processing payments, and additional services. The systems and methods can improve the availability of inventory items to users and the ability to resell items owned by users. Furthermore, the reservation systems and methods described herein can improve the processing of payments and additional services related to activity time transactions through more efficient use of resources, such as networks, applications, and databases, without sacrificing processing capacity and output quality. Furthermore, the use of reservation systems can further improve sales processes by offering opportunities for additional purchases. Additional purchase opportunities may include insurance, warranties, goods, and upselling. In one embodiment, the reservation system may offer one or more types of insurance for activity time, such as weather-based insurance or warranties.

[0008]

[0014] Some embodiments of this disclosure may allow referencing of activity time availability, which may include information such as relevant courses and specific dates and times, for example, to complete one or more transactions related to activity time. Embodiments of this disclosure may also update the activity time availability in one or more systems or databases after the completion of transactions. The updated activity time availability may then be provided to a user, such as through a client computing device.

[0009]

[0015] Reservations for events or activities, such as tea time or concerts, can be bought and sold through electronic marketplaces. Users can browse available reservations from the inventory to find their preferred choice and make a purchase, thus acquiring ownership of the reservation. The owner can then use the reservation to attend the event and, in some cases, transfer ownership to another person. Often, reservations can become useless if the user is unable to attend the event due to weather, inaccessibility of the venue, or if the event is canceled. For example, if an event is canceled due to weather, the value of the reservation may be lost if the owner does not have insurance or other guarantees.

[0010]

[0016] The various embodiments of the method may use one or more systems to provide users, including at least venues and customers, with additional options and flexibility through transactions available for reservations or other items. Inventory from multiple venues may be presented to the user from an electronic source, such as a website or application, where the user can review listing information about items, such as price and description. Descriptions relating to a particular item may include location, date, time, price history, ownership history, and other information. Furthermore, the user may request to perform transactions on items, such as listing for sale, listing for auction, purchasing, submitting an offer, removing an offer from the list, or other suitable transactions. In some embodiments, a transaction may be a primary market transaction between the user or user representative and a commercial ticket holder, such as a golf club owner, venue owner, distributor, or e-commerce website. Primary market transactions may be offered by a system using a third party. In other embodiments, a transaction may be a secondary market transaction between two users or user representatives, such as two golfers. Secondary market transactions may be offered by a system using a third party. When a transaction for an item is requested, availability for performing the transaction may be considered to determine whether the transaction can be completed. Availability may be determined using relevant data, such as identifying the owner and specific transactions that may have been completed. If the transaction can be completed, the item's description and availability may be updated to reflect the completed transaction. At least some of the updated information may then be made accessible to the user. In some embodiments, electronic tokens may be created for each activity time, for example, by using blockchain technology.Electronic tokens can then be used to participate in secondary markets.

[0011]

[0017] Therefore, the booking systems and methods described herein may enable benefits for providers, such as golf courses. These benefits may include at least one or more of the following: generating additional revenue, reducing costs, improving customer service, and reducing or eliminating abandoned bookings. Additional revenue may be generated through the use of marketplaces and auctions. Costs may be reduced by automating the booking process and reducing the need for manual processing. Customer service may be improved by providing customers with a more convenient way to book activity time or slots. Abandoned bookings, or no-shows, may be reduced or eliminated by requiring advance payment for bookings. Course access may be increased by providing a secondary marketplace that can accommodate both requested and unrequested offers, allowing users to acquire activity time that would otherwise be unavailable. One or more databases of inventory may be centralized by combining several application programming interfaces (APIs) to enable users to use a single system for activity time transactions. Customer flexibility may be increased by providing opportunities to sell unused tee time to encourage customers to increasingly commit to tee times. By providing a secondary market to create a new market for buyers and increased market participation, new types of buyers may be introduced, including buyers who purchase and sell large blocks of tea time.

[0012]

[0018] In one example, a golfer may access an application through a computing device such as a computer to view available tee time slots for various golf courses. In some embodiments, the application may include tee time slots for a single golf course, partner golf courses, golf courses located within a specified area, or any other combination. Several details about each slot may be provided or displayed to the user, such as one or more locations, one or more times, the number of golfers who can attend, and other information. More information relating to the tee time slots may be provided by the application. A golfer may select one or more tee time slots to request the completion of a transaction. A transaction may include any number or type of actions, such as buying, selling, making an offer, removing from a list, auctioning, advertising, hiding, adding co-owners or attendees, and other transactions. The availability status of tee time slots may be checked, as some tee time slots may not be available for some transactions. For example, if a tee time slot is not available for purchase, the request to buy the tee time slot will not be completed. In some cases, the availability status may include information such as current ownership, acceptable transactions, and other information. Additional information may also be referenced to determine whether a transaction can be completed, such as whether the payment offered is acceptable. Tea time slots, details, availability, additional information, and any other information may be stored in one or more databases or other systems. In one embodiment, an inventory of tea time slots and related information may be available from one or more tea time sheets. For example, tea time slots for one course may be available from one tea time sheet, and tea time slots for another course may be available from another tea time sheet.If the requested transaction is deemed acceptable, the transaction may be completed, and the tee time availability status may be updated. The new availability status may be referenced when an additional transaction is requested to be completed. After completion, information relating to the tee time slots available to the user, such as golfers, may be updated. This information may be updated based on the completed transaction, the updated availability status, the time remaining until tee time, and one or more other factors.

[0013]

[0019] Figure 1 shows the components of an environment 100 that may be used to manage and facilitate activity time reservations and associated transactions in various embodiments. The environment 100 may include an application hosting network 102 that may include an application load balancer 104, an application cluster 106, and a database cluster 108 to host applications that can be accessed by a user 110 via one or more client computing devices 112. The application hosting network 102 may be one or more networks, or a system of interconnected electronic components, circuits, or other elements. The application load balancer 104 may be one or more load balancers, or a program for distributing traffic across nodes of an application or cluster. The application cluster 106 may be one or more applications, or a software package that performs a specific function. The database cluster 108 may be one or more databases, or structured information electronically stored in a computer system. The application hosting network 102 may include other elements for hosting and running one or more applications.

[0014]

[0020] The application hosting network 102 may communicate with the activity sheet network 120 to process reservations and manage activity times, such as tee times, for the application hosting network 102 and referenced from the activity sheet network 120. The activity sheet network 120 may include an activity sheet application cluster 122 and an activity sheet database cluster 124. The activity sheet application cluster 122 and the activity sheet database cluster 124 may process activity times as requested by the application hosting network 102. The activity sheet network 120 may include other elements for hosting and running one or more applications related to processing activity times. The application hosting network 102 may have integrations with various activity sheet providers, such as tee sheet providers, which may be part of one or more activity sheet networks 120 or related to the activity sheet network 120 in one or more other ways. Activity sheet providers may offer varying levels of capabilities, such as retrieving course information, retrieving price classifications such as general, member, etc., retrieving activity times, retrieving customer information, booking activity times, and retrieving bookings. The application hosting network 102 and the activity sheet provider may be integrated using one or more APIs. In some embodiments, there may be no uniform way to call the APIs because different levels of capability exist. Therefore, each activity sheet API may differ from others. The application hosting network 102 may have to call one or more APIs and organize the results to provide a uniform response to the application.

[0015]

[0021] In one embodiment, an activity sheet such as a tee sheet can be used as an inventory management system for a group such as a golf course. The tee sheet may need [to be] updated if the reservation is purchased through the primary or secondary market. In one example, price, buyer name, seller name, and golfer name are entered into the tee sheet after purchase. Since the tee sheet and tee sheet provider may use different formats, APIs, request responses, etc., a program or software may be used to integrate the application that makes reservation transactions with the tee sheet.

[0016]

[0022] The application hosting network 102 can communicate with a payment processing network 130 to process payments and financial transactions for the application hosting network 102. The payment processing network 130 may include a payment application cluster 132. In some embodiments, the payment processing network 130 may include one or more databases or database clusters. The payment application cluster 132 can process payments as requested by the application hosting network 102. The payment processing network 130 may host and operate one or more applications related to processing activity times such as tee times and may include other elements for this purpose. In one or more embodiments, a payment aggregator may be used with one or more of the application hosting network 102 and the payment processing network 130.

[0017]

[0023] The application hosting network 102 can communicate with an additional service network 140 to provide additional services for the application hosting network 102, such as insurance transactions, protection, warranties, merchandise, or retail purchases. The additional service network 140 can include an additional service application cluster 142. In some embodiments, the additional service network 140 can include one or more databases or database clusters. The additional service cluster 142 can provide additional services, including processing insurance, protection, warranties, merchandise, upselling, or other services related to the application as requested by the application hosting network 102. The additional service network 140 can include other elements for hosting and operating one or more applications related to providing the additional services. In some embodiments, one or more of the activity sheet network 120, the payment processing network 130, and the additional service network 140 can be partially or fully integrated with the application hosting network 102 or another network, or a part of the application hosting network 102 or another network.

[0018]

[0024] In one example, user 110 may use device 112 connected to application hosting network 102 to access an interface that enables user 110 to view the availability of activity time at one or more providers and to book activity time reservations. The interface may be received by a booking application to execute and verify transactions and record information about the implementation of transactions in an activity sheet or blockchain, etc. Recording may enable pre-guaranteed scheduling between multiple parties. User 110 may also use device 112 connected to application hosting network 102 to access an interface that enables user 110 to trade activity time through a secondary market associated with environment 100 or a third-party system. User 110 may complete activity time trades or transactions, such as buying, listing, selling, or auctioning. In one embodiment, user 110 may buy, list, sell, or auction tokenized activity time, or transfer tokenized activity time to individual wallets. Blockchain technology may be used to create tokens, such as a non-fungible token (NFT) for each activity time. Tokens may be created when an activity time is created, first booked, or under other favorable conditions. A tokenization system may create one for each booked activity time. Activity time may be restricted from being traded or transacted on one or more marketplaces, such as the primary marketplace or other authorized marketplaces. For example, an activity sheet software provider API may restrict access to activity time to authorized entities only.

[0019]

[0025] Figure 2A shows an exemplary content display 200, where the content includes reservations 202, such as tee times, from an inventory of reservations that may be offered for consumption through an electronic marketplace. In one embodiment, the content may include reservations 202 of multiple types, ownership, availability, price, location, industry, or other category classifications. In another embodiment, the displayed reservations 202 may be related by sharing one or more characteristics, such as including a tee time, being located at the same venue, or being offered by the same owner, such as a golf course or a group of golf courses. In one embodiment, an application or group of applications may provide a service for an electronic marketplace that offers reservations 202 to users through a display 200, etc. In another embodiment, a website or other source may lead a user to the current content to find reservations 202. As shown, reservations 202 may be displayed whether or not they are listed for sale. In this example, reservations 202 may be owned by a course, a user that may be represented by a profile, or another preferred representation of ownership. In another embodiment, a website or application associated with an individual golf course may provide access to or information about a master course directory. Information shared between websites or applications may be collected, analyzed, reviewed, managed, and processed.

[0020]

[0026] The content of the display 200 may also include functions for users to interact with relevant information. One function may include the ability to sort 204 reservations 202 by time, price, number of participants, or other preferred characteristics. Another function may include the ability to filter 202 reservations 206 by start time, whether certain features are included or excluded, availability status, number of participants, price range, or other preferred characteristics. Another function may include the ability to specify 208 specific information about one or more reservations 202. For example, a user may save or “favorite” a reservation 202 so that it can be more easily referenced, such as by adding it to a watchlist, cart, or golf bag with similar functionality or otherwise associated with the user profile. One function may include the ability to specify 208 that additional details should be provided for a reservation 202. In another example, a user may specify 208 that a reservation 202 should be purchased. Other preferred functions may also be included.

[0021]

[0027] Figure 2B shows an exemplary content display 220, where the content includes reservation details 222, such as tee time details, for reservations that may be offered for consumption through an electronic marketplace. The reservation details 222 may include information relating to an individual reservation or a group of reservations. The reservation details 222 may include time, date, location, number of attendees, price, purchase history, predicted weather at the time and location of the reservation, and other relevant information. Users may be able to access or view the reservation details 222 relating to an individual reservation or a group of reservations. The content of display 220 may also include venue data 224, such as the name, location, and other information relating to the venue for the reservation. For example, the venue may be a golf course, and the information may include address, number of holes, par, and course length, or other information. The content of display 220 may also include transaction data 226 about the reservation related to the reservation details 222. The transaction data 226 may include the transaction history for the reservation related to the reservation details 222. For each transaction, transaction data 226 may include a listing of who purchased the reservation, the date of purchase, the selling price, and other relevant information.

[0022]

[0028] The content of the display 220 may also include functions for the user to interact with the reservation associated with the reservation details 222. In one embodiment, the function may allow the user to specify information 228 to share the reservation details 222 or the reservation associated with the reservation details 222. The user may share using a preferred method of communication, such as email, text, or messaging systems associated with an electronic marketplace. In one embodiment, the function may allow the user to specify information 226 to save or “favorite” the reservation so that it can be more easily referenced, such as by adding it to a watchlist, cart, golf bag with similar functionality, or otherwise associated with the user profile. In one embodiment, the function may allow the user to specify information 228 to complete the purchase of the reservation associated with the reservation details 222, such as by selecting a link to buy. When purchasing a reservation, the user may be able to select the number of participants that should be included for the reservation, such as three separate golfers who will be attending.

[0023]

[0029] Figure 2C shows an exemplary display 240 of content, where the content includes user profile data 242 and associated booking history that may be offered for consumption through the electronic marketplace. The user may be an individual, a group of individuals, a business, or other entity. In one example, the profile data 242 may be public and viewable by some other user or visitor, or may be specified with a certain level of privacy to exclude one or more individuals or groups from accessing at least a certain level of information. In another example, the profile may be linked to payment methods, accounts, or other systems that may be used to make and accept payments. A user may create a profile associated with the profile data 242 by disclosing identifying information or by using other preferred methods. In some examples, a username for identifying the user may be generated or selected by the user. An administrative profile 242 or account may be maintained if the profile or account is the original owner of the booking or may maintain a partnership with the original booking owner. An administrative account may enable users to manage inventory, access primary market revenue, access secondary market revenue, provide and use analytical tools, and other functionalities.

[0024]

[0030] Profile data 242 may include user-related information and reservations, such as upcoming tea time reservations 244, past tea time reservations 246, and information related to those tea times. Upcoming tea time reservations 244 related to profile data 242 may include one or more of the following: venue name, reservation date, time, location, previous seller, number of participants, price, or other information. Past tea time reservations 246 related to profile data 242 may be included as tea time history. Past tea time reservations 246 may include one or more of the following: venue name, reservation date, time, location, previous seller, number of participants, price, or other information.

[0025]

[0031] The content of display 240 may also include functions for the user to interact with relevant information. One function may include the ability to specify 248 specific information about one or more reservations. For example, the user may save or “favorite” the reservations in question so that they can be more easily referenced, such as by adding them to a watchlist, cart, golf bag with similar functions or otherwise associated with the user profile. One function may include the ability to specify 248 that additional details should be provided for the reservation 242. Other preferred functions may also be included.

[0026]

[0032] Figure 2D shows an exemplary content display 260, in which the content includes categorized transactions 262 for reservations associated with a user or user profile, which may be offered for consumption through an electronic marketplace. The categorized transactions 262 may be presented for viewing or collected in a location available to the user, such as "My Tee Box". The categorized transactions 262 may be grouped in category 264. Category 264 may include owned reservations, owned reservations listed for sale, offers sent for unlisted reservations, received offers for owned reservations, transaction history, and other categories.

[0027]

[0033] The content of display 260 may also include functions for users to interact with relevant information related to categorized transactions 262. One function may include the ability to specify 266 reservations currently owned that should be offered for sale by selecting the reservation, setting a desired price, and then paying a service fee. Another function may include the ability to make counter-offers 266 to outstanding offers received from other users for reservations currently owned, without considering, accepting, rejecting, or taking any other action, specifying a set minimum auction price (reserve price), and setting criteria for automatic sale. Other functions may include the ability to specify 266 information related to categorized transactions 262 that should be managed. In another embodiment, users may be provided with recommendations, such as available reservations, based on information relevant to them.

[0028]

[0034] Figure 2E shows an exemplary display 280 of content, in which the content includes a reservation auction 282 for reservations that may be offered for consumption through an electronic marketplace. In one embodiment, the reservation auction 282 may include reservation information 284 relating to a reservation offered for sale, auction information 286 relating to the auction, and other information. The reservation information 284 relating to a reservation may include the reservation date, time, location, venue name, etc. The auction information 286 relating to a reservation may include the auction name, end date, end time, time remaining for the auction, starting bid price, highest bid price, number of bids, etc.

[0029]

[0035] The content of display 280 may also include functions for the user to interact with relevant information related to the reservation auction 282. One function may include the ability to enter a bid amount for a reservation related to the auction and specify information 288 to make a bid. Another function may include the ability to specify information 288 to consider a bid for a reservation related to the auction before making that bid. Another function may include the ability to specify information 288 to buy a reservation related to the auction now or to purchase it immediately for cash.

[0030]

[0036] Figure 2F shows an exemplary display 290 of content, where the content includes transaction details 292 of a reservation that may be offered for consumption through an electronic marketplace. Transaction details 292 may include information such as venue name, reservation date, time, location, number of participants, price, or other information. In one embodiment, transaction details 292 may be editable by the user, such as changing the payment method, the number of participants, or the names to be listed in the reservation. In some embodiments, additional transactions 294 may be added to the transaction. Additional transactions 294 may include insurance, services, warranties, goods, etc. For example, if the reservation may be unavailable due to weather and insurance payments may be made, weather coverage, weather guarantee, or weather insurance may be added. In some embodiments, the reservation may be non-refundable. Payment information 296 for transaction details 292 may also be included or available for user input. Payment information 296 may include the ability to use express checkout, such as using payment information associated with the user or user profile, or to provide certain payment data, such as credit card information.

[0031]

[0037] The content of display 290 may also include functions for the user to interact with relevant information related to transaction details 292. One function may include the ability to specify information 288 to remove or delete a reservation or transaction from transaction details 292. Another function may include the ability to specify information 288 to add an additional transaction 294 to transaction details 292. Another function may include the ability to specify information 288 to buy now or confirm the purchase of a transaction or reservation contained in transaction details 292.

[0032]

[0038] Figure 3A is a schematic representation of a primary market transaction 300, where a set of transaction steps 302 for completing a transaction relating to activity time slots, in particular for purchasing tea time slots. While the configurations shown, and other configurations shown, may relate to step 302, embodiments of the present disclosure are not limited to steps and may include other processes, such as programs. A primary market transaction may include transactions relating to the purchase and sale of publicly available inventory items, where publicly available items may be purchased. In one example, during a primary market transaction, available tea time may be selected to be purchased. A user may purchase different numbers of tea time, such as one or two to a maximum of four or five, which may depend on individual slots or courses of tea time. When these tea time are purchased, the transaction may be marked as complete, and the tea sheet may be communicated and updated with appropriate reservation details.

[0033]

[0039] In this example, a set of transaction steps 302 for purchasing a tea time slot can be completed using a client device 312, an application 314, a tea sheet 316, and a payment processor 318. In this example, the client device 312 may be used to browse for tea times from the application 314. The client device 312 may then be used to purchase tea times through the application 314. The application 314 may then attempt to reserve tea times by communicating with the tea sheet 316. The tea sheet 316 may be used to determine if the reservation has been successfully completed, which is communicated to the application 314. The application 314 may then request that payment for the reservation be processed by the payment processor 318, and the payment processor 318 may indicate to the application 314 whether the payment has been successfully processed. If the payment is successful, the application 314 may provide the client device 312 with a conformance of the completed transaction.

[0034]

[0040] Figure 3B is a schematic representation 330 of a secondary market transaction, where a set of transaction steps 332 for completing a transaction relating to a tea time slot, in particular for making an unsolicited offer on a tea time slot. A secondary market transaction may include transactions relating to buying and selling available inventory items, which may involve making at least an unsolicited offer and a solicited offer. In one example, an unsolicited offer may select all items included in the inventory available to the application, regardless of whether they are available for purchase. Items that have been previously purchased and are not available for resale by the original buyer may be clearly marked. Users may make unsolicited offers on these items, such as tea time reservations or event tickets. In one embodiment, tea time, or tea time slots or reservations, may be purchased on the application platform or on a third-party platform. If tea time is purchased on the application platform, the tea time information to be displayed may already be controlled to accept unsolicited offers. If tea time is sold on another platform, the application may use tea sheet integration to retrieve that information. Therefore, tea time may always be available for presentation to the user. In another embodiment, the application may have a default floor price limit to avoid offers below an acceptable offer value. The limit may be applied during the offer time and may be used to encourage higher prices. The original buyer may adjust the limit. In yet another embodiment, when an unsolicited offer is made, the application may communicate with the tea sheet, retrieve owner information, and send a notification to the owner. If tea time is purchased on the application platform, a notification may always be sent for the original purchase.When an unsolicited offer is made, the application may send a notification to the original buyer, such as by email or SMS. The original buyer may have a time limit to accept the offer, counter the offer, reject the offer, or take any other action. If the offer is accepted, the buyer's payment method may be changed, and golfer information may be overwritten on the tee sheet. If the offer is countered, the ability to respond and take action may be passed back to the owner to accept, counter again, or take any other action, and this may cycle until a final acceptance or rejection. If the offer is rejected, there may be no other action to be taken. The offer may automatically expire when the reservation expiration date is reached. The offer may automatically expire when the time limit for responding is reached.

[0035]

[0041] In this example, a set of transaction steps 332 for making an unsolicited offer for a tea time slot can be completed using a secondary client device 340, a primary client device 342, an application 344, a tea sheet 346, and a payment processor 348. In this example, first, the primary client device 342 may be used to browse for tea times from the application 344. The primary client device 342 may then be used to purchase tea times through the application 344. The application 344 may then attempt to reserve tea times by communicating with the tea sheet 346. The tea sheet 346 may be used to determine that the reservation has been successfully completed, which is communicated to the application 344. The application 344 may then request that payment for the reservation be processed by the payment processor 348, which may then inform the application 344 whether the payment has been successfully processed. Upon successful payment, application 344 can provide primary client device 342 with confirmation of the completed transaction. The above actions may be performed in generally the same manner as shown in Figure 3A. To implement an unsolicited offer, secondary client device 340 may be used to browse for tea times from application 344, including items on the secondary marketplace. Secondary client device 340 may then be used to make an unsolicited offer for tea times via application 344. Application 344 may notify primary client device 342, which was used for the initial purchase, of the unsolicited offer. Primary client device 342 may then send a counter-offer to application 344, which may then use to notify secondary client device 340 of the counter-offer. Secondary client device 340 may then accept the counter-offer via application 344. Application 344 may then modify the tea time reservation in tea sheet 346.Application 344 may request that payment for the offer be processed by payment processor 348. Application 344 may send a notification of change of ownership or hands of the reservation to primary client device 342. Application 344 may send a notification of confirmation of purchase of the reservation to secondary client device 340.

[0036]

[0042] Figure 3C is a schematic representation of a secondary market transaction 360, showing a set of transaction steps 362 for completing a transaction related to tee time slots, in particular for making a request offer for a tee time slot. In one example, a request offer allows a reservation holder, such as a user who has purchased tee time, to make their purchased item available on the application platform for sale. Inventory items, such as tee time, can be purchased on the application platform or on a third-party platform. In the case of a request offer, a tee time owner can make their entire tee time round or a subset of their round available for sale. If tee time is purchased in the application, the original buyer information may already be in control, and the reservation on the tee seat may be changed. If tee time is not purchased in the application, the golfer may need to manually enter information into the application platform to confirm their ownership of that tee time. When the application is used to sell tee time that was not purchased on the application platform, the ownership status may be changeable using the application, or another service, such as a customer service representative or an automated electronic solution, may change the ownership. In some embodiments, it may be possible for a secondary buyer to complete a solicited offer transaction.

[0037]

[0043] In this example, a set of transaction steps 362 for making a request-based offer for a tea time slot can be completed using a secondary client device 370, a primary client device 372, an application 374, a tea sheet 376, and a payment processor 378. In this example, first, the primary client device 372 may be used to browse for tea times from the application 374. The primary client device 372 may then be used to purchase tea times through the application 374. The application 374 may then attempt to reserve tea times by communicating with the tea sheet 376. The tea sheet 376 may be used to determine that the reservation has been successfully completed, which is communicated to the application 374. The application 374 may then request that payment for the reservation be processed by the payment processor 378, and the payment processor 378 may indicate to the application 374 whether the payment has been successfully processed. If the payment is successful, the application 374 may provide the primary client device 372 with a conformity of the completed transaction. The above actions may be carried out in generally the same manner as shown in Figure 3A. To carry out a request-type offer, primary client device 372 may be used to place its tea time for sale in the secondary market on application 344. Secondary client device 370 may then be used to browse for tea time from application 374, including the secondary market. Secondary client device 370 may then be used to purchase secondary market tea time via application 374. Application 374 may then modify the tea time reservation in tea sheet 376. Application 374 may request that payment for the reservation be processed by payment processor 378. Application 374 may send a notification of change of owner or ownership of the reservation to primary client device 372. Application 374 may send a notification of confirmation of purchase of the reservation to secondary client device 370.

[0038]

[0044] Figure 4 shows an exemplary process 400 for completing a transaction related to a scheduled activity or event, such as tea time, which may be used according to various embodiments. While this figure, and any other process descriptions contained herein, may illustrate functional operation in a particular sequence, the process is not necessarily limited to the particular order or operation shown. Those skilled in the art will understand that the various operations depicted in this figure or other figures may be modified, rearranged, performed in parallel, or adapted in various ways. Furthermore, it should be understood that some operations or sequences of operations may be added to or omitted from the process without departing from the scope of the various embodiments. Moreover, the process descriptions contained herein are intended to illustrate the concept of process flow rather than specifying an actual sequence of code execution, which may be implemented as different flows or sequences, optimized for performance, or otherwise modified in various ways.

[0039]

[0045] In this example, a request is received to complete a tea time slot transaction (402). The request may be submitted by a suitable user, such as an individual user or customer, a provider on behalf of a customer, a reseller such as a third-party business, or other suitable user. The request may be received through an interface, such as a website or application, and may be processed using one or more networks. Transactions may include buying, listing, selling, auctioning, etc. Information related to tea time may be retrieved from a tea time sheet (404). Information related to tea time may include transaction availability status. Transaction availability status may include at least the current ownership of the time slot and any acceptable transactions for the time slot. A tea time sheet may be associated with a tea sheet provider. A tea sheet may be used as an inventory management system. The transaction availability status of a tea time slot may be determined (406). The transaction availability status may be recorded on the tea sheet, or as an electronic token created by blockchain technology, etc. The transaction availability status may depend on one or more factors or conditions.

[0040]

[0046] Transaction availability for a tea time slot 408 may be determined to be either yes or no. Transaction availability may be determined by any preferred method. Transaction availability may depend at least in part on the transaction availability status. If a transaction is available, the transaction relating to the tea time slot may be caused to be completed 410. Payment may be processed before, during, or after the transaction is completed. If a transaction is not available, the request for the transaction relating to the tea time slot may be caused to be rejected 412. If a transaction is not available, a notification may be sent indicating that the transaction has been caused to be rejected. An updated transaction availability status may be generated for the tea time slot 414. The updated transaction availability status may be updated in the tea time sheet. The updated transaction availability status may include at least one of the updated current ownership or available transactions. Information relating to the tea time slot may be presented on the client device 416. The information presented may include one or more of the following: updated transaction availability status, updated current ownership, or acceptable transactions. The information presented may also include notification that a transaction has been triggered to be completed.

[0041]

[0047] Figure 5 shows an exemplary process 500 for making an unsolicited offer for activity time, which can be used according to various embodiments. In this example, a request is received from the secondary market to make an unsolicited offer for a reservation 502. The request may be received through an electronic device, using an application or web page. The unsolicited offer may be sent by a first client, the requester, for a reservation controlled or owned by a second client, the owner. Before processing the request, a check of the reservation's availability status may be completed. A notification may be generated to the client who owns the reservation 504. The notification may be sent using a preferred format, such as a notification in an application or web page, or through email or other messaging systems. The notification may include information relevant to the request, such as the specific reservation, the offer purchase price, the reservation time, the reservation location, or other relevant information. A request may be received from the client to send a counter-offer 506. The request to send a counter-offer may be generated automatically or based on input from the client. The counter-offer may include changes to any relevant characteristics of the reservation that may be negotiable or variable, such as the number of participants or the price of the reservation. A notification of an unsolicited offer may be generated to the requesting party. The notification may be generated based on a request to send a counter-offer. The notification may be sent using a preferred format, such as a notification in an application or web page, or via email or other messaging system. An acknowledgment of the counter-offer may be received from the requesting party. The acknowledgment of the counter-offer may be generated automatically or based on input from the client.

[0042]

[0048] Information related to the reservation may be updated in the tea sheet 512. The information may be updated in the tea sheet based on the acceptance of a counter-offer. The update of the information may be completed automatically when the offer is accepted. The tea sheet may be stored on the same network as the network that processes the offer, or on a separate network from the network that processes the offer. The sheet may be updated at least partially using an API. The information may be updated using blockchain technology. Payment for the reservation may be processed by the requesting party using a payment processor 514. Payment processing may be completed automatically when the offer is accepted. Payment processing may be performed on the same network as the network that processes the offer, or on a separate network from the network that processes the offer. If payment cannot be processed, a notification that the transaction cannot be completed may be sent to the requesting party and the owner. If payment cannot be processed, information related to the reservation may not be updated. A notification to the client of purchase confirmation or change of ownership may be generated 516. The generation of the notification to the client may be completed automatically when payment processing is successful. The notification may be sent using a preferred format, such as a notification in an application or web page, or via email or other messaging system. A notification may be generated to the requesting party confirming the purchase or the change of ownership.518 The generation of the notification to the requesting party may be completed automatically upon successful processing of the payment. The notification may be sent using a preferred format, such as a notification in an application or web page, or via email or other messaging systems. An acknowledgment of the change of ownership input in the tea sheet may be sent to the client or requesting party as a notification. The generation of a notification regarding the acknowledgment of the change of ownership input in the tea sheet may be completed automatically upon successful processing of the payment. The notification may be sent using a preferred format, such as a notification in an application or web page, or via email or other messaging systems.Notification of changes in ownership on the tee sheet may be sent if payment for the reservation is not completed using the payment processor. If payment for the reservation is not completed using the payment processor, payment may be completed manually.

[0043]

[0049] One or more waitlist technologies may be incorporated to manage and complete transactions related to activity time. Waitlist technologies may include waitlist management software, virtual waitlists, appointment scheduling, event registration, queue management, waitlist applications, messaging, and analytics. For example, in addition to or instead of another competing transaction for activity time, a user may join a waitlist for activity time via an application or computing device. Waitlist data for activity time may be stored in a database and / or activity time sheet that shows the status of each activity time, such as the number of users on the waitlist, available, sold, reserved, and available participants. The waitlist may be accessible online, for example, by one or more computing devices, and a corresponding waitlist display may be presented to the user. Waitlist functionality may be available to allow users to add themselves to a waitlist for activity time or other offerings. Ordering functionality may be available to allow users to complete another transaction, such as purchasing activity time or other offerings. For example, a waiting list function and an order function may relate to the same or different transaction, purchase, or checkout application. For example, a waiting list function and an order function may relate to the same or different market or vendor.

[0044]

[0050] One or more neural networks may be employed to develop trained models for managing and completing activity time-related transactions, including proposing prices for activity time, recommending activity time to users, suggesting additional services, and determining information about activity time. For example, activity time associated with user profile data about users who have purchased activity time, along with one or more activity times rejected by users, may be provided to a neural network. The neural network may be trained to evaluate those activity times and select the activity times that are likely to be purchased by users. Thus, once trained with information about activity times and users who purchase activity time, the neural network can apply one or more models to determine additional activity times that users might like. Once evaluated, the activity times and potential purchasers or associated profile data may be stored in an evaluation database for further analysis.

[0045]

[0051] As stated, neural networks, deep learning, artificial intelligence, and other machine learning techniques have applications for this purpose. Various neural network types may be applied, including, but are not limited to, feedforward, recurrent, modular, and self-organizing neural networks, as is known in neural network and artificial intelligence techniques. Prior to use in a production environment, non-production sample datasets of typical activity-time content may be employed to train neural network models for activity-time processing and analysis. Metrics derived through machine learning may help the system and method track and understand patterns in activity-time. While graphics processing units ("GPUs") are effective for many deep learning neural network applications, the system and method may be used with GPU-based systems or central processing unit ("CPU")-based systems.

[0046]

[0052] More specifically, object detection performance has improved dramatically with the advent of deep convolutional neural networks ("CNNs"), a programming and information processing paradigm that enables machines to learn from data. CNNs are a family of statistical learning models used in machine learning applications to estimate or approximate functions that depend on a large number of inputs. Various inputs are interconnected with connections that have numerical weights that can be adjusted over time, allowing the network to "learn" based on additional information. Different layers of the network can be configured for different purposes. There are input layers, which, together with a set of adjacent layers, form the convolutional part of the network. The lowest layer of the convolutional layer, together with the lower layers and output layers, constitutes the fully connected part of the network. Among such options, several output values ​​can be determined from the output layer, which may include several items determined to be related to the input items.

[0047]

[0053] Any type of neural network employed in this disclosure will likely require adjustments and / or additions or substitutions to adapt to the specific details of a particular situation. In some embodiments, training a CNN may involve a significant use of computational resources and time, and therefore this may correspond to a preliminary step in servicing content display requests and / or may be performed relatively infrequently and / or according to a schedule with respect to the requested service. As is known in object-oriented and other computer science techniques, the following machine learning features may be achieved by using separate software modules running on feature maps.

[0048]

[0054] Figure 6 shows the logical configuration of a typical set of components of an exemplary computing device 600. In this example, the device includes a processor 602 for executing instructions that may be stored in a memory device or element 604. As will be apparent to those skilled in the art, the device may include many types of memory, data storage, or non-temporary computer-readable storage media, such as a first data storage for program instructions to be executed by the processor 602, separate storage for images or data, and removable memory for sharing information with other devices. The device will generally include some type of display element 606, such as a touchscreen or liquid crystal display (LCD), although devices such as portable media players may transmit information by other means, such as through audio speakers. As described, in many embodiments, the device will include at least one input element 608 capable of receiving conventional input from a user. This conventional input may include, for example, a push button, touchpad, touchscreen, wheel, joystick, keyboard, mouse, keypad, or any other such device or element through which a user can input commands to the device. However, in some embodiments, such devices may not contain any buttons at all and may be controlled solely through a combination of visual and audio commands, so that the user can control the device without needing to touch it. In some embodiments, the computing device 600 in Figure 6 may include one or more network interface elements 610 for communicating over various networks, such as Wi-Fi®, Bluetooth®, RF, wired, or wireless communication systems. In many embodiments, the device may be able to communicate with networks such as the Internet and with other such devices.

[0049]

[0055] As described, different methods may be implemented in various environments according to the embodiments described. It should be understood that a web-based environment is used for illustrative purposes in some of the examples presented herein, but different environments may be used, as appropriate, to implement various embodiments. The system includes an electronic client device, which may be any suitable device capable of sending and receiving requests, messages, or information over a suitable network and communicating information to the user of the device. Examples of such client devices include personal computers, cell phones, handheld messaging devices, laptop computers, set-top boxes, personal information terminals, e-book readers, and the like. The network may be any suitable network, including intranets, the internet, cellular networks, local area networks, or any other such networks, or combinations thereof. The components used in such a system may depend at least in part on the type of network and / or environment selected. Protocols and components for communication over such networks are well known and are not described in detail herein. Communication over the network may be enabled via wired or wireless connections and combinations thereof. In this example, the network includes the internet, as the environment includes web servers for receiving requests and serving content in response; however, as will be apparent to those skilled in the art, other networks may use alternative devices that serve a similar purpose.

[0050]

[0056] An exemplary environment includes at least one application server and a data store. It should be understood that there may be several application servers, layers, or other elements, processes, or components, which may be linked or otherwise configured, that can interact to perform tasks such as retrieving data from a suitable data store. As used herein, the term “data store” refers to any device or combination of devices capable of storing, accessing, and retrieving data, and such devices may include any combination of data servers, databases, data storage devices, and data storage media, as well as any number of such devices, in any standard, distributed, or clustered environment. An application server may integrate with the data store as needed to run one or more aspects of an application for client devices and may include any suitable hardware and software for handling the majority of the data access and business logic about the application. The application server may work with the data store to serve access control and generate content, such as text, graphics, audio, and / or video, which should be forwarded to the user, and which in this example may be served to the user by a web server in the form of HTML, XML, or another suitable structured language. The handling of all requests and responses, as well as the delivery of content between client devices and application servers, may be handled by the web server. It should be understood that the web server and application server are not required and are merely illustrative components, as the structured code described herein can run on any suitable device or host machine, as described elsewhere herein.

[0051]

[0057] A data store may include several separate data tables, databases, or other data storage mechanisms and media for storing data relating to a particular aspect. For example, the data store shown may include mechanisms for storing content (e.g., manufacturing data) and user information, which may be used to service content for a manufacturer. The data store is also shown to include mechanisms for storing log or session data. There may be many other aspects that need to be stored in the data store, such as page image information and access rights information, and it should be understood that this information may be stored in any of the mechanisms listed above, or in additional mechanisms within the data store, as appropriate. The data store can operate by receiving commands from an application server through its associated logic and responding by retrieving, updating, or otherwise processing data. In one example, a user may submit a search request for a certain type of item. In this case, the data store may have access to user information to verify the user's identity and access to catalog details to retrieve information about that type of item. The information may then be returned to the user, for example, in a results listing on a web page that the user can view via a browser on their device. Information about specific items of interest can be viewed in a dedicated page or window in the browser.

[0052]

[0058] Each server will generally include an operating system that provides executable program instructions for the general administration and operation of the server, and will generally include a computer-readable medium that stores instructions that, when executed by the server's processor, enable the server to perform its intended functions. Preferred implementations for the server's operating system and general functions are known or commercially available and can be readily implemented by those skilled in the art, particularly in light of the disclosure herein.

[0053]

[0059] The environment in one embodiment is a distributed computing environment that utilizes several computer systems and components interconnected via communication links using one or more computer networks or direct connections. However, it will be understood by those skilled in the art that such systems may function equally well with fewer or more components than those shown. Accordingly, the diagrams of the systems in this specification should be taken as illustrative and not limiting to the scope of this disclosure.

[0054]

[0060] Various embodiments can be implemented in a wide variety of operating environments, which in some cases may include one or more user computers or computing devices that can be used to run any of several applications. User devices or client devices may include some general-purpose personal computers, such as desktop or laptop computers running standard operating systems, as well as some cellular, wireless, and handheld devices capable of running mobile software and supporting several networking and messaging protocols. Such systems may also include some workstations running any of various commercially available operating systems and other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as dummy terminals, thin clients, gaming systems, and other devices capable of communicating over a network.

[0055]

[0061] Most embodiments utilize at least one network, which will be well known to those skilled in the art, to support communication using one of a variety of commercially available protocols, such as TCP / IP, FTP, UPnP, NFS, and CIFS. The network may be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, or any combination thereof.

[0056]

[0062] In embodiments utilizing a web server, the web server may run any of a variety of servers or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java® servers, and business application servers. One or more servers may also be capable of executing programs or scripts in response requests from user devices, such as by running one or more web applications that can be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C#, or C++, or any scripting language, such as Perl, Python, or TCL, or combinations thereof. One or more servers may also include database servers, including, but are not limited to, commercially available servers from Oracle®, Microsoft®, Sybase®, and IBM®, as well as open-source servers such as MySQL®, Postgres, SQLite, and MongoDB, and any other servers capable of storing, retrieving, and accessing structured or unstructured data. Database servers may include table-based servers, document-based servers, unstructured servers, relational servers, non-relational servers, or combinations of these and / or other database servers.

[0057]

[0063] The environment may include various datastores and other memory and storage media, as described above. These may reside in various locations, such as on storage media, local to one or more computers (and / or residing in one or more), or remote from any or all computers, across a network. In a particular set of embodiments, information may reside in a storage area network (SAN) as is well known to those skilled in the art. Similarly, files necessary for performing functions attributable to computers, servers, or other network devices may be stored locally and / or remotely, as appropriate. If the system includes computerized devices, each such device may include hardware elements that can be electrically coupled via a bus, such as, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touch-sensitive display element, or keypad), and at least one output device (e.g., display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, magnetic tape drives, optical storage devices, and solid-state storage devices like random-access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, and flash cards.

[0058]

[0064] Such a device may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device), and the working memory described above. The computer-readable storage medium reader may be connected to or configured to receive computer-readable storage media representing remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices will generally also include an operating system and several software applications, modules, services, or other elements located within at least one working memory device, including application programs such as client applications or web browsers. It should be understood that alternative embodiments may have numerous variations from the embodiments described above. For example, customized hardware may also be used, and / or certain elements may be implemented in hardware, software (including portable software such as applets), or both. Furthermore, connections to other computing devices, such as network input / output devices, may be employed.

[0059]

[0065] Storage media and other non-temporary computer-readable media for containing code or portions of code may include, but are not limited to, any suitable media known or used in the art, such as volatile and non-volatile, removable and non-removable media, which are implemented in any way or technique for storing information, such as computer-readable instructions, data structures, program modules or other data, and which may be used to store desired information and may be accessed by system devices, including RAM, ROM, EEPROM®, flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other media, which may include computer-readable instructions, data structures, program modules or other data, which may be implemented in any way or technique for storing information, which may include any suitable media known or used in the art, such as volatile and non-volatile, removable and non-removable media. Based on the disclosures and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing various embodiments.

[0060]

[0066] Figure 7 shows an exemplary environment 700 in which various embodiments may be implemented. In this example, a user can utilize a client device 702 to submit requests to a resource provider environment 706 across at least one network 704. The client device may include any suitable electronic device capable of sending and receiving requests, messages, or other such information over a suitable network and communicating information to the user of the device. Examples of such client devices include personal computers, tablet computers, smartphones, and notebook computers. The network 704 may include any suitable network, including an intranet, the Internet, a cellular network, a local area network (LAN), or any other such network, or a combination thereof, and communication on the network may be enabled via wired and / or wireless connections. The resource provider environment 706 may include any suitable components for receiving requests and returning information or performing actions in response to those requests. As an example, the provider environment may include a web server and / or application server for receiving and processing requests and then returning data, web pages, videos, audio, or other such content or information in response to those requests.

[0061]

[0067] In various embodiments, the provider environment may include various types of electronic resources that can be utilized by multiple users for various different purposes. In at least some embodiments, all or part of a given resource or set of resources may be allocated to a particular user or for a particular task for at least a determined period of time. The sharing of these multitenant resources from the provider environment is often referred to as resource sharing, web services, or “cloud computing,” among such terms, and depending on the particular environment and / or implementation. In this example, the provider environment includes multiple electronic resources 714 of one or more types. These types may include, for example, application servers capable of operating to process instructions provided by a user, or database servers capable of operating to process data stored in one or more data stores 716 in response to user requests. As is known for such purposes, a user may also reserve at least a portion of the data storage in a given data store. Methods for enabling a user to reserve various resources and resource instances are well known in the art, and therefore a detailed description of the entire process and a description of all possible components will not be described in detail herein.

[0062]

[0068] In at least some embodiments, a user wishing to utilize a portion of resource 714 may submit an incoming request to the interface layer 708 of the provider environment 706. The interface layer may include an application programming interface (API) or other exposed interfaces that enable users to submit requests to the provider environment. The interface layer 708 in this example may also include other components, such as at least one web server, a routing component, or a load balancer. When a request to provision a resource is received by the interface layer 708, information about that request may be directed to a resource manager 710, or other such system, service, or component configured to manage user accounts and information, resource provisioning and usage, and other such aspects. The resource manager 710 that receives the request may perform tasks such as authenticating the identity of the user who submitted the request and determining whether the user has an existing account with the resource provider, provided that account data can be stored in at least one data store 712 in the provider environment. The user may provide the provider with any of various types of proof to authenticate their identity. These proofs may include, for example, username and password pairs, biometric data, digital signatures, or other such information.

[0063]

[0069] The resource provider can verify this information against the information stored about the user. If the user has an account with the appropriate permissions, status, etc., the resource manager can determine if there are sufficient resources available to suit the user's request, and if there are sufficient resources, it can provision those resources for the user's use in the amount specified by the request, or, in some cases, grant access to the corresponding portion of those resources. This amount may include, for example, the capacity to process a single request or perform a single task, a specified time period, or a cyclical / renewable period, among other values. If the user does not have a valid account with the provider, or the user account does not allow access to the type of resource specified in the request, or for other such reasons, communication may be sent to the user to allow the user to create or modify an account, or to modify the resource specified in the request, among other options.

[0064]

[0070] Once a user is authenticated, their account is verified, and resources are allocated, the user can utilize one or more allocated resources for a specified capacity, amount of data transfer, duration, or other such value. In at least some embodiments, the user may provide a session token or other such proof with subsequent requests to enable those requests to be processed on that user session. The user may receive resource identifiers, specific addresses, or other such information that enables the client device 702 to communicate using the allocated resources without needing to communicate with the resource manager 710, at least until a time has passed when the relevant aspect of the user account changes, the user is no longer granted access to the resources, or another such aspect changes.

[0065]

[0071] Furthermore, the resource manager 710 (or another such system or service) in this example can function as a virtual layer of hardware and software components that handles control functions in addition to management actions, such as provisioning, scaling, and replication. The resource manager may utilize dedicated APIs in the interface layer 708, where each API may be provided to receive requests for at least one specific action to be performed on the data environment, such as provisioning, scaling, cloning, or suspending instances. Upon receiving a request to one of the APIs, the web service portion of the interface layer may parse or otherwise analyze the request to determine the steps or actions required to act along with or process the call. For example, a web service call may be received that includes a request to create a data repository.

[0066]

[0072] In at least one embodiment, the interface layer 708 includes a scalable set of customer-facing servers that provide various APIs and can return appropriate responses based on API specifications. In one embodiment, the interface layer may also include at least one API service layer consisting of stateless, replicated servers that handle external customer APIs. The interface layer may be responsible for web service frontend features such as authenticating customers based on proof, authorizing customers, throttling customer requests to API servers, verifying user input, and marshalling or unmarshalling requests and responses. The API layer may also be responsible for reading and writing database configuration data to and from the administration data store in response to API calls. In many embodiments, the web service layer and / or the API service layer will be either the sole externally visible component or the sole component that is visible to and accessible by the customer of the control service. The servers in the web service layer are stateless and can be scaled horizontally, as is known in the art. API servers and persistent data stores can be spread, for example, across multiple data centers in a region, so that these servers are resilient to a single data center failure.

[0067]

[0073] Other variations fall within the scope of this specification. Thus, the techniques described are capable of various modifications and alternative configurations, some of which are illustrated embodiments shown in the drawings and described in detail above. However, it should be understood that the description is not intended to be limited to one or more specific forms described, but rather, the intention is to cover all modifications, alternative configurations, and equivalents that fall within the scope and purpose of the description, as defined in the appended claims.

[0068]

[0074] The terms “a,” “an,” and “the,” and the use of similar referents in the context of describing embodiments (particularly in the context of the following claims), should be construed as covering both singular and plural, unless otherwise specified herein or explicitly rejected by the context, and should not be construed as definitions of terms. The terms “comprising,” “having,” “including,” and “containing” should be construed as open-ended terms (meaning “including, but not limited to”) unless otherwise stated. When “connected” is unqualified and refers to a physical connection, it should be construed as being partially or completely contained, attached, or joined to one another, even if there is something intervening. The descriptions of value ranges herein are intended only as a shortened way of referring individually to each distinct value that falls within the range, unless otherwise specified herein, and each distinct value is incorporated into the specification as if it were described individually herein. In at least one embodiment, the use of the terms “set” (e.g., “set of items”) or “subset” should be interpreted as a non-empty set having one or more members, unless otherwise stated or contradicted by the context. Furthermore, unless otherwise stated or contradicted by the context, the term “subset” of a corresponding set does not necessarily refer to a suitable subset of the corresponding set, and a subset and a corresponding set may be equivalent.

[0069]

[0075] Conjunctional phrases, such as “at least one of A, B, and C” or “at least one of A, B, and C,” are generally understood in context to indicate that, unless otherwise explicitly stated or explicitly refuted by the context, an item, term, etc., may be either A, B, or C, or any non-empty subset of the set A, B, and C. For example, in the exemplary example of a set having three members, the conjunctional phrases “at least one of A, B, and C” and “at least one of A, B, and C” refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunctional phrases do not generally imply that some embodiments require the presence of at least one of A, at least one of B, and at least one of C. Furthermore, unless otherwise stated or negated by the context, the term “plurality” indicates a state of being multiple (for example, “a plurality of items” indicates multiple items). In at least one embodiment, the number of items in plural is at least two, but can be more when indicated so either explicitly or by the context. Furthermore, unless otherwise stated or otherwise evident from the context, the phrase “based on” means “based at least in part on” and does not mean “based solely on.”

[0070]

[0076] The use of any and all examples or illustrative language provided herein (e.g., "such as") is intended solely to better illustrate the embodiments described and, unless otherwise claimed, does not impose any limitation on the scope of the description. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice described.

[0071]

[0077] The description herein outlines exemplary implementations of the techniques described, but other architectures may be used to implement the functions described, and are intended to be within the scope of this description. Furthermore, while specific distributions of responsibility may be defined above for explanatory purposes, various functions and responsibilities may be distributed or divided in different ways depending on the context.

[0072]

[0078] Furthermore, while the subject matter is described using language specific to structural features and / or methodological actions, it should be understood that the subject matter asserted in the attached claims is not necessarily limited to the specific features or actions described. Rather, the specific features and actions are described as exemplary forms of implementing the claims.

[0073]

[0079] At least one embodiment of this disclosure may be described in view of the following clauses.

[0074] Article 1. Receiving a request from a client computing device to complete a transaction related to a time slot for performing an activity, Determining the transaction availability status of a time slot, and that the transaction availability status includes at least current ownership and acceptable transactions. This causes transactions related to time slots to be completed, at least partially based on the transaction availability status. To generate an updated transaction availability status for the time slot, This causes time slot-related information, including at least partially the updated transaction availability status, to be displayed on the client device's screen. A computer implementation method comprising the above. Clause 2. A computer implementation method described in Clause 1, including an unsolicited offer, in which a transaction is made. Clause 3. The computer implementation method described in Clause 1, wherein the time slot comprises tee time for golf. Article 4. Creating tokens for completed transactions for time slots. The computer implementation method described in Clause 1, further comprising: Article 5. To enable tokens to be traded on secondary markets. The computer implementation method described in Clause 4, further comprising: Article 6. Remember the updated transaction availability status for time slots. The computer implementation method described in Clause 1, further comprising: Clause 7. A computer implementation method as described in Clause 1, which includes a transaction submitting a bid in an auction for a time slot. Article 8. Offering weather insurance for the time slot along with a request to complete the transaction. The computer implementation method described in Clause 1, further comprising: Article 9. At least one processor, Memory containing instructions and A system comprising, where an instruction, when executed by at least one processor, Receiving a request from a client computing device to complete a transaction related to a time slot for performing an activity, Determining the transaction availability status of a time slot, and that the transaction availability status includes at least current ownership and acceptable transactions. This causes transactions related to time slots to be completed, at least partially based on the transaction availability status. To generate an updated transaction availability status for the time slot, This causes time slot-related information, including at least partially the updated transaction availability status, to be displayed on the client device's screen. A system that enables this to happen. Clause 10. A transaction involving a non-requested offer within the system described in Clause 9. Clause 11. The system described in Clause 9, where the time slot includes tee time for golf. Clause 12. When an instruction is executed, the system Creating tokens for completed transactions for time slots. The system described in Clause 9 further enables the following: Article 13. When an instruction is executed, the system shall, To enable tokens to be traded on secondary markets. The system described in Clause 12 further enables the following: Clause 14. When an instruction is executed, the system shall Remember the updated transaction availability status for time slots. The system described in Clause 9 further enables the following: Clause 15. The system described in Clause 9, which includes a transaction submitting a bid in an auction for a time slot. Article 16. When an instruction is executed, the system shall Offering weather insurance for the time slot along with a request to complete the transaction. The system described in Clause 9 further enables the following: Article 17. We accept reservations for multiple different time slots for conducting the activity, To enable users to view information about reservations in multiple different time slots, This allows users to make new reservations in available time slots, or to receive offers to purchase existing reservations for one or more different time slots. A computer implementation method comprising the above. Clause 18. The computer implementation method described in Clause 17, on which one or more purchases of the reservation are recorded. Article 19. Confirm that the offer to purchase has been accepted, To provide users with confirmation of acceptance and A computer implementation method as described in Clause 17, further comprising: Clause 20. The computer implementation method described in Clause 17 for a user to make an offer to purchase an existing reservation from a secondary marketplace.

[0075]

[0080] Therefore, this specification and the drawings should be considered illustrative rather than restrictive. However, it will be apparent that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as described in the claims.

Claims

1. Receiving a request from a client computing device to complete a transaction related to a time slot for performing an activity, Determining the transaction availability status of the time slot, and determining that the transaction availability status includes at least current ownership and acceptable transactions. To cause the transaction with respect to the time slot to be completed, at least in part based on the transaction availability status, To generate an updated transaction availability status for the aforementioned time slot, This causes information related to the time slot, including at least partially the updated transaction availability status, to be displayed on the client device's display. A computer implementation method comprising the following features.

2. The computer implementation method according to claim 1, wherein the transaction includes an unsolicited offer.

3. The computer implementation method according to claim 1, wherein the time slot comprises tee time for golf.

4. Creating a token for the completed transaction for the aforementioned time slot. The computer implementation method according to claim 1, further comprising:

5. To enable the aforementioned token to be traded on a secondary market. The computer implementation method according to claim 4, further comprising:

6. To store the updated transaction availability status for the time slot. The computer implementation method according to claim 1, further comprising:

7. The computer implementation method according to claim 1, wherein the transaction includes submitting a bid in an auction for the time slot.

8. Along with the request to complete the aforementioned transaction, offer weather insurance for the aforementioned time slot. The computer implementation method according to claim 1, further comprising:

9. At least one processor, Memory containing instructions and A system comprising, where the instruction, when executed by the at least one processor, Receiving a request from a client computing device to complete a transaction related to a time slot for performing an activity, Determining the transaction availability status of the time slot, and determining that the transaction availability status includes at least current ownership and acceptable transactions. To cause the transaction with respect to the time slot to be completed, at least in part based on the transaction availability status, To generate an updated transaction availability status for the aforementioned time slot, This causes information related to the time slot, including at least partially the updated transaction availability status, to be displayed on the client device's display. A system that enables this to happen.

10. The system according to claim 9, wherein the transaction includes an unsolicited offer.

11. The system according to claim 9, wherein the time slot comprises tee time for golf.

12. When the aforementioned instruction is executed, the system, Creating a token for the completed transaction for the aforementioned time slot. The system according to claim 9, further comprising the following steps.

13. When the aforementioned instruction is executed, the system will: To enable the aforementioned token to be traded on a secondary market. The system according to claim 12, further comprising the following:

14. When the aforementioned instruction is executed, the system, To store the updated transaction availability status for the time slot. The system according to claim 9, further comprising the following steps.

15. The system according to claim 9, wherein the transaction includes submitting a bid in an auction for the time slot.

16. When the aforementioned instruction is executed, the system, Along with the request to complete the aforementioned transaction, offer weather insurance for the aforementioned time slot. The system according to claim 9, further comprising the following steps.

17. We accept reservations for multiple different time slots for conducting the activity, To enable the user to view information about the reservation in the multiple different time slots, The user is made to be able to make a new reservation in an available time slot, or to be offered the purchase of an existing reservation for one or more of the different time slots. A computer implementation method comprising the following features.

18. The computer implementation method according to claim 17, wherein one or more of the aforementioned reservations are recorded as purchases.

19. Confirmation of acceptance of the aforementioned offer for purchase, To provide the aforementioned user with a notification of acceptance. The computer implementation method according to claim 17, further comprising:

20. The computer implementation method according to claim 17, wherein the user makes the offer to purchase the existing reservation from the secondary market.

Images