CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit under 35 U.S.C. § 1 19 of U.S. Provisional Application No. 62/576,055, filed on October 23, 2017.

TECHNICAL FIELD

[0002] The present disclosure relates generally to performing transactions where goods are sold or otherwise transferred.

BACKGROUND

[0003] Private transactions frequently employ websites such as Craigslit®. However, because buyers and sellers often don't know each other, criminals have employed these websites to assault, rob, or commit other violent crimes against users of the websites. The criminal may pose as the buyer or seller.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The accompanying drawings incorporated herein and forming a part of the specification illustrate the example embodiments.

[0005] FIG. 1 is a block diagram illustrating an example of a system for performing transactions where goods are sold or otherwise transferred.

[0006] FIG. 2 is a block diagram illustrating an example of a transaction server upon which an example embodiment may be implemented.

[0007] FIG. 3 is a block diagram illustrating an example of a locker upon which an example embodiment may be implemented.

[0008] FIG. 4 is a block diagram illustrating an example of a seller computing device upon which an example embodiment may be implemented.

[0009] FIG. 5 is a block diagram illustrating an example of a buyer computing device upon which an example embodiment may be implemented.

[0010] FIG. 6 is a block diagram illustrating an example of a system for performing transactions that employ a distributed database.

[0011] FIG. 7 is a block diagram illustrating an example of a blockchain node upon which an example embodiment may be implemented.

[0012] FIG. 8 is a block diagram that illustrates a computer system upon which an example embodiment may be implemented.

[0013] FIG. 9 is a block diagram that illustrates an example of a methodology for employing lockers to transfer goods in accordance with a first example embodiment where the seller rents a locker before the goods are sold.

[0014] FIG. 10 is a block diagram that illustrates an example of a methodology for employing lockers to transfer goods in accordance with a second example embodiment where the seller rents a locker after the goods are sold.

[0015] FIG. 1 1 is a block diagram that illustrates an example of a methodology for employing lockers to transfer goods in accordance with a third example embodiment where the purchaser rents the locker.

SUMMARY OF EXAMPLE EMBODIMENTS

[0016] The following presents a simplified overview of the example embodiments in order to provide a basic understanding of some aspects of the example embodiments. This overview is not an extensive overview of the example embodiments. It is intended to neither identify key or critical elements of the example embodiments nor delineate the scope of the appended claims. Its sole purpose is to present some concepts of the example embodiments in a simplified form as a prelude to the more detailed description that is presented later. [0017] In accordance with an example embodiment, there is disclosed herein a method for selling goods that employs lockers so that the purchaser and seller do not have to meet in person. In particular embodiments, a cryptocurrency associated with a distributed database such as a blockchain may be employed so that the buyer's and seller's identities are not disclosed.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0018] This description provides examples not intended to limit the scope of the appended claims. The figures generally indicate the features of the examples, where it is understood and appreciated that like reference numerals are used to refer to like elements. Reference in the specification to "one embodiment" or "an embodiment" or "an example embodiment" means that a particular feature, structure, or characteristic described is included in at least one embodiment described herein and does not imply that the feature, structure, or characteristic is present in all embodiments described herein.

[0019] Described in an example embodiment herein is a system for selling an article that employs a distributed database architecture (e.g., blockchain) and a locker that the seller can use to transfer the article to the buyer. In an example embodiment, a system comprises two users (e.g., buyer and seller). Two smart contracts are created by the seller. One for a locker rental fee and one for the sale of an article. The locker rental fee contract may be executed immediately and the sale price contract may include a "haggle" period to allow the buyer and seller to negotiate.

[0020] In an example embodiment, the seller registers with the system employs an access code for accessing the locker. Any suitable type of access code may be employed. For example, the access code can be implemented via the user's identity on the blockchain (e.g., only the user who is registered as the buyer or seller can open the locker at times determined by the contract). As another, example, a FUSION access code can be employed. The access code can be entered manually or via tapping the locker's terminal with a mobile device having a near field communication ("NFC") interface. In other embodiments, other ways of communicating the access code can be used, such as, for example, barcode or a two-dimensional ("2D") barcode. The code is used by the seller to access their goods at any time during the process. For example, a seller who is intending to sell or transfer a good to a buyer can authenticate using the access code) to reserve a locker, indicate the sale price, and places the good into the locker. A notification is delivered to the seller's mobile device indicating the locker has been rented, provide the duration of the rental (e.g., 1 , 3, or 7 days), and the cost of the rental. If the seller decides to cancel the transaction for any reason, the locker rental fee is retained and the sale price contract is voided.

[0021] The buyer may also be registered with the system, but the buyer's identity is anonymous to the seller. The buyer can see goods that are available to him via a general listing or can receive a notification on their mobile device that a specified good is available for them to retrieve. The buyer can initiate an intent to buy at the sale price or at a lower price. At any point, the seller has the ability to accept, reject, or renegotiate the sale price contract. Once the price is agreed upon, the sale price contract is executed. The buyer proceeds to the locker, authenticates with the locker, and removes the good. The buyer may authenticate by manually entering the access code, tapping their mobile device on an interface, or by providing a bar code (e.g., on their mobile device's display). Upon delivery of the good to the seller, digital receipts are delivered to both the buyer and the seller.

[0022] In an example embodiment, if the buyer rejects or otherwise does not purchase the goods. The buyer can return the goods to the locker, and upon confirmation that the goods were returned, the buyer's funds may be refunded. The seller may continue to advertise the goods until another buyer is founds or until the time period for the contract expires.

[0023] In an example embodiment, the buyer and/or seller may purchase the locker and/or goods using a cryptocurrency such as Bitcoin, Ethereum, Litecoin, Monerom, etc, The cryptocurrency may employ a distributed database such as blockchain for performing the transactions. [0024] In an example embodiment, the contracts for purchasing the locker and/or goods may be network-based smart contracts. In particular embodiments, at least one or both of the smart contracts are anonymous smart contracts (e.g., the identities of the buyer and seller are not disclosed to each other). The smart contracts may settle transactions without the need for expertise in cryptocurrencies such as Ethereum, blockchain, or smart contracts in general. All the operations for the transaction may be performed in the back-end by a server,

[0025] FIG. 1 is a block diagram illustrating an example of a system 100 for performing transactions where goods are sold or otherwise transferred. The system comprises a transaction server 102, a locker 104, a buyer computing device 108, and a seller computing device 106 that are coupled together by a network 1 10. The transaction server 102, locker 104, seller computing device, and buyer computing device 108 comprise logic for performing the functionality described herein. "Logic", as used herein, includes but is not limited to hardware, firmware, software and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another component. For example, based on a desired application or need, logic may include a software controlled microprocessor, discrete logic such as an application specific integrated circuit (ASIC), a programmable/programmed logic device, memory device containing instructions, or the like, or combinational logic embodied in hardware. Logic may also be fully embodied as software that performs the desired functionality when executed by a processor.

[0026] The transaction server 102, locker 104, seller computing device 106, and buyer computing device 108 are operable to communicate with each other via network 1 10. Network 1 10 may suitably comprise, wired, wireless, or a combination and wired and wireless links.

[0027] In the examples described herein, a seller employs a seller computing device 106 to offer goods for sale. A buyer employs a buyer computing device 108 to purchase goods. The buyer and seller computing devices 106, 108 may be any suitable type of computing device such as, for example, a desktop computer, a laptop computer, a mobile device such as a smartphone, or any other suitable computing device. [0028] In an example embodiment, the transaction server 102 is operable to receive data representative of a first contract to rent the locker 104 for selling an item from the seller computing 106. For example, a seller may rent a locker for a time period in order to offer an item for sale. The transaction server 102 is operable to obtain data representative of a second contract for purchase of the item from the seller computing device 106. For example, after advertising the item, the seller may receive an offer from the buyer. The buyer and seller may further negotiate the terms of the sale (e.g., price, delivery options, etc.). The transaction server 102 receives data confirming the sale and the terms (e.g., price and optionally how long the seller will hold the goods for the buyer) from the buyer computing device 108. The transaction server 102 is operable to obtain payment for the first contract from the buyer computing device 108 and the second contract from the seller computing device 108. The transaction server 102 is operable to receive a signal from the locker 104 indicating when the item has been placed into the locker 104. In particular embodiments, the item may be placed in the locker 104 prior to the buyer and seller negotiating the sale. The transaction server 102 is operable to send a notification to the seller computing device 106 that the item is in the locker 104. The notification may further comprise direction to the locker and instructions on how to access the item within the locker (e.g., employ a previously described access code and/or may send a token, for example a two-dimensional bar code to the buyer computing device 108. The transaction server 102 is operable to receive a signal from the locker 104 indicating that the item was removed from the locker 104. There are many different ways the locker 104 can determine whether the item was removed. For example, if the locker 104 was accessed by the buyer, which can be determined if the locker was opened with a code or token the transaction server 102 provided to the buyer. Alternatively, or in addition, the locker 104 may comprise sensors that can tell whether item is still in the locker. For example, the locker may have sensors that determine the weight of items placed in the locker and/or sensors that can detect an object within the locker such as light beams that are transmitted from one side of the locker and received by sensors at the other side of the locker if not blocked. Upon determining that the buyer has obtained the item, the transaction server 102 is operable to provide payment to the seller. [0029] In an example embodiment, the payment for the first contract is made via a cryptocurrency. This can allow the seller to remain anonymous to the buyer.

[0030] In an example embodiment, the payment for the second contract made via cryptocurrency. This can allow the buyer to remain anonymous to the seller.

[0031] In particular embodiments, the payments for both the first and second contracts may be made via cryptocurrencies allowing both the buyer and seller to remain anonymous to each other.

[0032] In an example embodiment, the first, second or both the first and second contracts are smart contracts. The smart contracts employed herein may be used to set terms and trigger events upon terms being fulfilled. For example, a smart contract may be triggered to provide the buyer with access to the locker 104 upon receiving payment of the item. Depending upon the terms of the contract, the smart contract may hold the payment to the seller until the buyer has accepted the goods. For example, if the buyer finds the goods are defective, the buyer may return the goods to the locker 104 and cancel the contract. In an example embodiment, a smart contract collects fees for locker rentals as well as transaction fees for using the locker which may be charged to the buyer, seller, or both depending upon the terms of the contract.

[0033] In an example embodiment, the locker 104 is a selected locker 104 from a plurality of lockers 104 (see e.g., FIG. 6). The plurality of lockers 104 may be at a single location, or in some embodiments, the plurality of lockers 104 are located in a plurality of locations. For example, the transaction server may randomly select a locker. In other embodiments, the transaction server 102 may send data representative of available lockers to the seller computing device 106 allowing the seller to select a locker and/or location.

[0034] In an example embodiment, the transaction server 102 is operable to send a first code to the seller computing device 106 to allow access to the locker 104 so the seller can place the item into the locker 104. The transaction server 102 is operable to send a second code to the buyer computer device to allow the buyer access to the locker 104 to retrieve the item from the locker 104. In an example embodiment, the second code is not sent to the buyer computing device 108 until after the seller places the item into the locker 104. In particular embodiments, the first and second codes may be the same while in other embodiments the first and second codes are different. In an example embodiment, the number of times a code can be used may be limited. For example, once the seller puts the item into the locker 104, the seller's code may be canceled to prevent the seller from removing the item from the locker 104 before the buyer can pick it up. If the sale is canceled, the seller may still be excluded from access to the locker 104 until the payment for the locker 104 has been made.

[0035] In an example embodiment, the transaction server 102 employs a distributed database, such as blockchain, for conducting the transaction (see e.g., FIG. 6). For example, as illustrated in FIG. 6, a distributed database comprising M nodes (where M is an integer greater than 1 ) as represented by database nodes 614A ... 614M, that are coupled to blockchain nodes 612A ... 612M respectively. Blockchain allows the transaction to be recorded in a secure and transparent manner while at the same time allowing the use of cryptocurrencies which can allow the parties to the transaction to remain anonymous to each other. Moreover, blockchain can facilitate the use of smart contracts for the transaction.

[0036] In another example embodiment, instead of the seller renting a locker prior to offering the item for sale, the transaction server 102 is operable to obtain data representative of a first contract between a buyer and seller for a purchase of an article from the seller computing device 106 and execute a second contract for use of a locker for transferring the article. The transaction server 102 can execute a second contract with either the purchaser (e.g., buyer), seller or both the buyer and seller (e.g., they can agree to split the cost of the locker rental) for renting a locker 104 for transferring the article from the seller to the purchaser.

[0037] The transaction server 102 is operable to send data representative of the locker 104 and data indicating how to access the locker 104 to the seller computing device 106 and the buyer computing device 108. The transaction server 102 is operable to obtain data from the locker 104 indicating the article has been placed in the locker 104. The transaction server 102 is operable to obtain data verifying that the purchaser has deposited funds for the article. In an example embodiment, the transaction server may send data to the buyer computing device 108 allowing access to the locker responsive to obtaining the data from the locker 104 indicating the article has been placed in the locker 104 and obtaining the data verifying that the purchaser has deposited funds for the article. The transaction server 102 is operable to obtain data indicating the purchaser has removed the article from the locker 104. In an example embodiment, the transaction server 102 is operable to provide a digital receipt to the seller computing device 106 and the buyer computing device 108.

[0038] In an example embodiment, the transaction server 102 communicates with a plurality of blockchain nodes associated with a distributed database (see e.g., FIG. 6) to complete the transaction. In particular embodiments, the transaction server 102 obtains data representative of a first payment for the first contract, wherein the data representative of the first payment is a cryptocurrency and the purchaser remains unknown to the transaction server 102 and the seller computing device 196. The transaction server 102 is operable to verify the first payment via the distributed database. In an example embodiment, the transaction server 102 is further operable to obtain data representative of a second payment for the second contract, wherein the data representative of the second payment is a cryptocurrency and the seller remains unknown to the transaction server 102 and to the buyer (purchaser). The transaction server 102 is operable to verify the second payment with the distributed database.

[0039] In an example embodiment, the transaction server 102 is operable to provide an access code to the seller computing device 106 for the locker 104 responsive to verifying payment for the locker 104 was made. The access code may be an alphanumeric code, barcode (e.g., a one or two-dimensional barcode), and/or a token.

[0040] In an example embodiment, the transaction server 102 is operable to provide an access code to the purchaser computing device 108 for accessing the locker 104. The access code can be sent responsive to determining the seller has placed the article into the locker 104 and verifying payment from the purchaser for the first contract.

[0041] In an example embodiment, the locker 104 is selected from a plurality of lockers. The selection of lockers may be made by the transaction server 102, or the transaction server can send data representative of available lockers to the seller computing device 106 and/or the buyer computing device 108 allowing the buyer and/or seller to select a locker for the transaction. In particular embodiments, the location of the selected locker 104 is selected from a plurality of locations. For example, the transaction server 102 can select the location and/or locker based on either the location of the buyer, seller, or both. In another example embodiment, the transaction server 102 provides the seller computing device 106 with a plurality of locations where lockers are available, and the seller selects the location, and optionally the locker too. For example, the seller can select a location convenient for the seller or convenient for the purchaser. If the seller and purchaser are far apart, the seller may provide a third-party delivery service with the access code for the locker and have the third party delivery service put the article into the locker. Delivery charges may be included as part of the contract for purchase of the article. As another example, the buyer may rent a locker convenient to the buyer and have a third party delivery service retrieve the item from the seller. The buyer may provide the third-party delivery service with the access code for the locker and have the third party delivery service put the article into the locker.

[0042] FIG. 2 is a block diagram illustrating an example of a transaction server 102 upon which an example embodiment may be implemented. The transaction server 102 comprises transaction logic 202 coupled with a communication interface 204. The transaction logic 202 can perform the functionality described herein for the transaction server 102. The communication interface 204 allows the transaction server 102 to communicate via a network (e.g., network 1 10 in FIG. 1 ) to external devices such as logic associated with locker 104, seller computing device 106, and buyer computing device 108. The communication interface 204 may employ any suitable wired and/or wireless communication protocol.

[0043] In an example embodiment, the transaction logic 202 is operable to receive data representative of a first contract to rent the locker 104 (FIG. 1 ) for selling an item from the seller computing device 106 (FIG. 1 ) via the communication interface 204. The transaction logic 202 is operable to obtain data representative of a second contract for purchase of the item from the seller computing device 106 (FIG. 1 ) via communication interface 204. The transaction logic 202 is operable to obtain payment for the second contract. The transaction logic 202 is operable to receive a signal from the locker 104 (FIG. 1 ) via the communication interface 204 indicating when the item has been placed into the locker. The transaction logic 202 is operable to send a notification via the communication interface 204 to the buyer computing device 108 (Fig. 1 ) indicating that the item is in the locker. The transaction logic 202 is operable to receive via communication interface 204 a signal from the locker 104 (FIG. 1 ) indicating that the item was removed from the locker 104 (FIG. 1 ). The transaction logic 202 is operable to provide payment to the seller. In particular embodiments, the transaction logic 202 may send a signal via communication interface 204 to the seller computing device 106 (FIG. 1 ) indicating that payment was made.

[0044] In an example embodiment, the payment for the first contract is made via a cryptocurrency and the seller is anonymous to the buyer. In another example embodiment, payment for the second contract made via cryptocurrency and the buyer is anonymous to the seller. In still yet another example embodiment, payment for both the first contract and the second contract is made via a cryptocurrency.

[0045] In an example embodiment, the first contrast is a smart contract. In another example embodiment, the second contract is a smart contract. In particular embodiments, both the first and second contracts are smart contracts.

[0046] In an example embodiment, the transaction logic 202 selects a locker 104 (FIG. 1 ) from a plurality of lockers. In another example embodiment, the transaction logic 202 send data representative of available lockers via communication interface 204 to the seller computing device 106 (FIG. 1 ) via communication interface 204 and receives data representative of a selected locker from the seller computing device 106 (FIG. 1 ) via communication interface 204. In yet another example embodiment, the transaction logic 202 sends data representative of available lockers via communication interface 204 to the buyer computing device 108 (FIG. 1 ) via communication interface 204 and receives data representative of a selected locker from the buyer computing device 108 (FIG. 1 ) via communication interface 204. In still yet another example embodiment, the transaction logic 202 sends data representative of available lockers to both the seller computing device 106 (FIG. 1 ) and the buyer computing device 108 (FIG. 1 ) and obtains data representative of a selected locker from the seller computing device 106 (FIG. 1 ) and/or the buyer computing device 108 (FIG. 1 ) via the communication interface 204. In an example embodiment, the available lockers may be located at a plurality of locations.

[0047] In an example embodiment, the transaction logic 202 is operable to send a first code to the seller computing device 106 (FIG. 1 ) to allow access to the locker 104 (FIG. 1 ) to place the item into the locker 104 (FIG. 1 ). The code may be an alphanumeric code, token, or any other suitable code to access the locker 104 (FIG. 1 ). The code may be a one-time code (e.g., once the item is placed in the locker the code expires) or a multi-use code allowing the seller to remove the item (e.g., if the sale is canceled).

[0048] In an example embodiment, the transaction logic 202 is operable to send a second code to the buyer computing device 108 via communication interface 204 to allow access to the locker to remove the item from the locker. The second code may be the same or different from the first code. The code may be a one-time code, or in other embodiments may be used multiple times during a predefined time period (e.g., during the locker rental period) which can allow the buyer to return the item if it is defective.

[0049] In an example embodiment, the locker 104 (FIG. 1 ) may be rented prior to the sale in anticipation of a transaction by either the buyer, the seller, or both. In another example embodiment, the locker 104 (FIG. 1 ) is rented after an agreement is made between the buyer and seller.

[0050] FIG. 3 is a block diagram illustrating an example of a locker 104 upon which an example embodiment may be implemented, the locker 104 comprises locker logic 302 coupled with a user interface 304 that comprises an input device 306. The input device can be employed to receive a code to open the locker 104. The door is controlled by locker logic 302.

[0051] The user input 306 may be any suitable device for receiving a code to access the locker. For example, the user interface 306 may suitable comprise a keypad input, a barcode scanner, a RFID tag reader, and/or any other suitable device for obtaining a code. [0052] In an example embodiment, the locker logic 304 receives the appropriate codes from the transaction server 102 (FIG. 1 ) via the communication interface 310. When the code entered at the input device 306 matches a code received via the communication interface 310, the locker logic unlocks the door 308. In an example embodiment, the locker 104 may have sensors to determine whether an item was placed into or removed from the locker.

[0053] FIG. 4 is a block diagram illustrating an example of a seller computing device 106 upon which an example embodiment may be implemented. The seller computing device 106 comprises seller transaction logic 402 which is controls the operation of seller computing device 106. A user interface 404 and a communication interface 406 are coupled with the seller transaction logic 402.

[0054] In an example embodiment, the user interface 404 is employed by a seller to input data representative of an item or article to be sold. The data representative of the time may be communicated to a transaction server (e.g., transaction server 102 (FIG. 1 ) via communication interface 406. The user interface 404 may also display or output data from either the transaction server 102 (FIG. 1 ) or the buyer computing device 108 (FIG. 1 ) that are received via the communication interface. For example, the communication interface 406 may receive data for negotiating a sale of the item. The communication interface 406 may also be employed to exchange data with the transaction server 102 (FIG. 1 ) to provide details of the sale of the item and/or to rent the locker 104 (FIG. 1 ).

[0055] FIG. 5 is a block diagram illustrating an example of a buyer computing device 108 upon which an example embodiment may be implemented. The buyer computing device 108 comprises seller transaction logic 502 which is controls the operation of seller computing device 106. A user interface 504 and a communication interface 506 are coupled with the seller transaction logic 502.

[0056] In an example embodiment, the user interface 504 is employed by a buyer to input data to search for items for sale. The input data is provided to transaction server 102 (FIG. 1 ) via the communication interface 506. The user interface 504 is operable to receive data representative of items for sale from the transaction server 102 (FIG.1 ) via the communication interface 506 and output data representative of the items for sale via the user interface 504. The buyer may input an offer via the user interface 504 which is sent to the seller via the communicating interface 506. The buyer may be notified of acceptance of the offer via data received via communication interface that is output via use interface 504. The communication interface 506 may also be employed to exchange data with the transaction server 102 (FIG. 1 ) to provide details of the sale of the item and/or to rent the locker 104 (FIG. 1 ).

[0057] FIG. 6 is a block diagram illustrating an example of a system 600 for performing transactions that employ a distributed database. The transaction server 102, locker 104, seller computing device 106, and seller computing device 108 function as described herein.

[0058] In the illustrated example, the distributed database is a blockchain database that comprises blockchain nodes 612-1 to 612-M and data storage modules 614-1 to 614-M (where M is an integer greater than 1 and can be any physically realizable number). The blockchain nodes 612-1 to 612-M suitably comprise logic for performing the functionality described herein. In an example embodiment, the blockchain database employs cryptography to store transaction data for the sale of the item and/or rental of the locker 104. This can also allow the buyer and/or seller to use a cryptocurrency to pay for the item and/or locker without disclosing the identity of the buyer and/or seller to each other. In addition, the blockchain nodes 612-1 to 612-M may employ a smart contract for implementing the sale of the item and/or the rental of a locker 104.

[0059] In the illustrated example, the system 600 also comprises a plurality of lockers 104-1 to 104-N (where N is an integer greater than 1 and can be any physically realizable number). The lockers 104-1 to 104-N may be located a single location, be distributed at a plurality of locations, or may have a plurality of lockers at a plurality of locations.

[0060] FIG. 7 is a block diagram illustrating an example of a blockchain node 612 upon which an example embodiment may be implemented. The blockchain node 612 comprises distributed database logic 702 that is coupled with a communication interface 704 and a data storage device 614. The distributed database logic 702 employs the communication interface 704 to communicate with the transaction server 102 (FIG. 1 ) via network 1 10 (FIG. 1 ), and optionally buyer computing device 106 and the seller computing device 108. For example, the distributed database logic 702 may receive data representative of a transaction for purchase of an item or rental of a locker 104 (FIG. 1 ) via the communication interface 704. The distributed database logic 702 encrypts and stores the data representative of the transaction into storage device 614. In particular embodiments, payment for the purchase of the item and/or locker 104 (FIG. 1 ) may be made with a cryptocurrency. Data representative of the transfer of the cryptocurrency to the seller and/or the party controlling the locker 104 is also stored in data storage device 614. In an example embodiment, the distributed database logic 702 employs smart contracts to implement the sale of the item and/or rental of the locker 104 (FIG. 1 ).

[0061] FIG. 8 is a block diagram that illustrates a computer system 800 upon which an example embodiment may be implemented. Computer system 800 can be employed to implement any of transaction logic 202 (FIG. 2), locker logic 302 (FIG. 3), seller transaction logic 402 (FIG. 4), buyer transaction logic 502 (FIG. 5), or distributed database logic 702.

[0062] The computer system 800 includes a bus 802 or other communication mechanism for communicating information and a processor 804 coupled with bus 802 for processing information. Computer system 800 also includes a main memory 806, such as random access memory (RAM) or other dynamic storage device coupled to bus 802 for storing information and instructions to be executed by processor 804. Main memory 806 also may be used for storing a temporary variable or other intermediate information during execution of instructions to be executed by processor 804. Computer system 800 further includes a read only memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing information and instructions.

[0063] In an example embodiment, computer system 800 may be coupled via bus 802 to a display 812 such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. An input device 814, such as a keyboard including alphanumeric and other keys is coupled to bus 802 for communicating information and command selections to processor 804. Another type of user input device is cursor control 816, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 804 and for controlling cursor movement on display 812. This input device typically has two degrees of freedom in two axes, a first axis (e.g. x) and a second axis (e.g. y) that allows the device to specify positions in a plane.

[0064] In an example embodiment, computer system 800 is employed for transactions for transferring goods that employ a locker. According to an example embodiment, transactions for transferring goods that employ a locker is provided by computer system 800 in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another computer-readable medium, such as storage device 810. Execution of the sequence of instructions contained in main memory 806 causes processor 804 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 806. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement an example embodiment. Thus, embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0065] The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 804 for execution. Such a medium may take many forms, including but not limited to non-volatile media, Nonvolatile media include for example optical or magnetic disks, such as storage device 810. Common forms of computer-readable media include for example floppy disk, a flexible disk, hard disk, magnetic cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASHPROM, CD, DVD or any other memory chip or cartridge, or any other medium from which a computer can read.

[0066] Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be borne on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 800 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus 802 can receive the data carried in the infrared signal and place the data on bus 802. Bus 802 carries the data to main memory 806 from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.

[0067] Computer system 800 also includes a communication interface 818 coupled to bus 802. Communication interface 818 provides a two-way data communication coupling computer system 800 to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. As another example, communication interface 818 may be an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. Wireless links may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0068] Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer (not shown) or to data equipment operated by an Internet Service Provider (ISP) (not shown). The ISP in turn provides data communications through the worldwide packet data communication network, now commonly referred to as the "Internet."

[0069] In view of the foregoing structural and functional features described above, methodologies in accordance with an example embodiments will be better appreciated with reference to FIGS. 9-1 1 . hile, for purposes of simplicity of explanation, the methodologies of FIGS. 9-1 1 are shown and described as executing serially, it is to be understood and appreciated that the example embodiments are not limited by the illustrated order, as some aspects could occur in different orders and/or concurrently with other aspects from that shown and described herein. Moreover, not all illustrated features may be required to implement the methodologies described herein. The methodology described herein is suitably adapted to be implemented in hardware, software when executed by a processor, or a combination thereof. For example, the methodologies described in FIGS 9-1 1 may be implemented by computer system 800 described in FIG. 8.

[0070] FIG. 9 is a block diagram that illustrates an example of a methodology 900 for employing lockers to transfer goods in accordance with a first example embodiment where the seller rents a locker before the goods are sold. In an example embodiment, portions of methodology 900 is performed by transaction server 102 (FIG. 1 ) which is in data communication with locker 104 (FIG. 1 ), seller computing device 106 (FIG. 1 ), and buyer computing device 108 (FIG. 1 ) via network 1 10 (FIG. 1 ). For example, at least part of methodology 900 may be implemented by transaction logic 202 (FIG. 2) or computer system 800 (FIG. 8).

[0071] At 902, the seller, employing a computing device such as the seller computing device 106 (FIG. 1 ) obtains access codes. In an example embodiment, the seller registers with the system 100 (FIG. 1 ) and receives, via a mobile application, an access code, such as, for example, a FUSION access code. The seller may obtain the access codes from a third-party vendor, or in some embodiments, the seller may obtain the access codes from the transaction server 101 (FIG. 1 ).

[0072] At 904, the seller reserves the locker. The locker may be reserved for any time period, e.g., one day, one week, one month, etc. Responsive to successfully renting the locker (e.g., selecting an available locker and paying for the locker), the seller is notified that the locker is rented as illustrated at 906. In an example embodiment, the seller may rent the locker anonymously (e.g., the seller's identity is not disclosed to the buyer) and pay for the locker with a cryptocurrency.

[0073] At 908, the seller delivers the goods to the locker. In an example embodiment, the seller uses one of the access codes obtained at 902. In another example embodiment, the seller may obtain an access code from the locker 104 (FIG. 1 ) and/or transaction server 102 (FIG. 1 ).

[0074] At 910, the buyer, employing a computing device such as buyer computing device 108 (FIG. 1 ), searches for goods. Upon deciding to purchase the seller's goods, the buyer makes an offer as illustrated at 912. At this point, in an example embodiment, the buyer and seller may negotiate terms of a sale, e.g., price, delivery options, etc. Upon completion of the negotiations and/or the buyer's acceptance of the seller's terms, the offer is accepted as indicated at 914.

[0075] At 916, the buyer pays for the goods, or in the case of an electronic contract, funds the contract. In an example embodiment, the buyer may pay for the goods with a cryptocurrency and the buyer's identify is not disclosed to the seller and/or the transaction server 102 (FIG. 1 ).

[0076] At 918, the buyer is provided with an access code to the locker. In an example embodiment, the buyer's access code is different than the user's access code. The access code may be any suitable access code which can be delivered to a computing device associated with the buyer, such as buyer computing device 108 (FIG. 1 ), such as, for example, an alphanumeric code, a token, etc. In an example embodiment, the access code is the access code provided at 902. In For example, the code may be a code provided by the seller, via seller computing device 106 (FIG. 1 ) to the buyer via buyer computing device 108 (FIG. 1 ). In another example embodiment, the access code may be generated by transaction server 102 (FIG. 1 ) and provided to the buyer computing device 108 (FIG. 1 ).

[0077] At 920, the buyer retrieves the goods. In an example embodiment, the buyer has the opportunity to inspect the goods and return them within a predefined time period if unacceptable. If the goods are not returned within the predefined time period, the goods are considered accepted.

[0078] At 922, the seller is paid for the goods. In an example embodiment, the transaction server 102 (FIG. 1 ) may deduct a transaction fee that is separate from the locker rental fee. In particular embodiments, the buyer and/or seller receive electronic receipts via buyer computing device 106 (FIG. 1 ) and/or seller computing device 108 (FIG. 1 ) respectively.

[0079] FIG. 10 is a block diagram that illustrates an example of a methodology 1000 for employing lockers to transfer goods in accordance with a second example embodiment where the seller rents a locker after the goods are sold. In an example embodiment, portions of methodology 1000 is performed by transaction server 102 (FIG. 1 ) which is in data communication with locker 104 (FIG. 1 ), seller computing device 106 (FIG. 1 ), and buyer computing device 108 (FIG. 1 ) via network 1 10 (FIG. 1 ). For example, at least part of methodology 1000 may be implemented by transaction logic 202 (FIG. 2) or computer system 800 (FIG. 8).

[0080] At 1002, the buyer, employing a computing device such as buyer computing device 108 (FIG. 1 ) and the seller employing a computing device such as seller computing device 106 (FIG. 1 ) negotiate and agree to terms (e.g., price but those skilled in the art can readily appreciate that other terms may also be negotiated such as delivery, time period for delivering goods, etc.). For example, the buyer may search for available goods and upon selecting the seller's goods may send an offer. The buyer may accept the offer or may further negotiate sales terms.

[0081] At 1004, a (first) contract for purchase of the goods is sent to the buyer. In an example embodiment, the contract is sent to the buyer via buyer computing device 108 (FIG. 1 ). In particular embodiments, the transaction server 102 (FIG. 1 ) may employ a smart contract for the transaction and send a contract to the buyer via buyer computing device 108 (FIG. 1 ).

[0082] At 1006, the buyer funds the first contract. In an example embedment, the buyer may employ a cryptocurrency to fund the first contract in order to remain anonymous with respect to the seller.

[0083] At 1008, the seller reserves the locker. The locker rental may be referred to herein as a second contract. The locker may be reserved for any time period, e.g., one day, one week, one month, etc. In an example embodiment, the seller may rent the locker without disclosing the seller's identity and pay for the locker with a cryptocurrency. In an example embodiment, the seller may select a locker that is convenient for the buyer and/or seller. For example, if the buyer is a long distance away, the seller may rent a locker near the seller and have the goods delivered via a delivery service, or have the goods deposited in a locker near the seller and the buyer can employ a delivery service to retrieve the goods.

[0084] At 1010, the seller is provided with an access code for the locker. The seller may obtain the access from any source acceptable to the vendor associated with the locker. For example, the seller may purchase access codes such as FUSION codes or codes may be provided to the seller either from the transaction server 102 (FIG. 1 ) and/or the locker 104 (FIG. 1 ). The access code provided to the seller may be the same code or a different code than the buyer's code. The access code may be an alphanumeric code that may be keyed into the locker or may be a token which can be wirelessly provided to the locker (e.g., a code that can be transmitted via NFC or optically scanned from the seller computing device 106 (FIG. 1 ) by the locker 104 (FIG. 1 )).

[0085] At 1012, the seller put the goods into the locker. The seller employs an access code provided at 1010 to gain access into the locker.

[0086] At 1014, the buyer is notified that the goods are available. The notification may be sent by either the transaction server 102 (FIG. 1 ) or locker 104 (FIG. 1 ) to the buyer computing device 108 (FIG. 1 ). In an example embodiment, the buyer is provided with an access code with the notification. The access code provided to the buyer may be the same code or a different code than the seller's code. The access code may be an alphanumeric code that may be keyed into the locker or may be a token which can be wirelessly provided to the locker (e.g., a code that can be transmitted via NFC or optically scanned from the buyer computing device 108 (FIG. 1 ) by the locker 104 (FIG. 1 )).

[0087] At 1016, the buyer retrieves the goods. In an example embodiment, the buyer has the opportunity to inspect the goods and return them within a predefined time period if unacceptable. If the goods are not returned within the predefined time period, the goods are considered accepted.

[0088] At 1018, the seller is paid for the goods. In an example embodiment, the transaction server 102 (FIG. 1 ) may deduct a transaction fee that is separate from the locker rental fee. In particular embodiments, the buyer and/or seller receive electronic receipts via buyer computing device 106 (FIG. 1 ) and/or seller computing device 108 (FIG. 1 ) respectively.

[0089] FIG. 1 1 is a block diagram that illustrates an example of a methodology 1 100 for employing lockers to transfer goods in accordance with a third example embodiment where the purchaser rents the locker. In an example embodiment, portions of methodology 1 100 is performed by transaction server 1 12 (FIG. 1 ) which is in data communication with locker 1 14 (FIG. 1 ), seller computing device 1 16 (FIG. 1 ), and buyer computing device 1 18 (FIG. 1 ) via network 1 10 (FIG. 1 ). For example, at least part of methodology 1 100 may be implemented by transaction logic 202 (FIG. 2) or computer system 800 (FIG. 8).

[0090] At 1 102, the buyer, employing a computing device such as buyer computing device 1 18 (FIG. 1 ) and the seller employing a computing device such as seller computing device 1 16 (FIG. 1 ) negotiate and agree to terms (e.g., price but those skilled in the art can readily appreciate that other terms may also be negotiated such as delivery, time period for delivering goods, etc.). For example, the buyer may search for available goods and upon selecting the seller's goods may send an offer. The buyer may accept the offer or may further negotiate sales terms.

[0091] At 1 104, a (first) contract for purchase of the goods is sent to the buyer. In an example embodiment, the contract is sent to the buyer via buyer computing device 1 18 (FIG. 1 ). In particular embodiments, the transaction server 1 12 (FIG. 1 ) may employ a smart contract for the transaction and send a contract to the buyer via buyer computing device 1 18 (FIG. 1 ).

[0092] At 1 106, the buyer funds the first contract. In an example embedment, the buyer may employ a cryptocurrency to fund the first contract without disclosing the buyer's identity to the seller.

[0093] At 1 108, the buyer reserves the locker. The locker rental may be referred to herein as a second contract. The locker may be reserved for any time period, e.g., one day, one week, one month, etc. In an example embodiment, the buyer may rent the locker without this disclosing their identify (e.g., anonymously) and pay for the locker with a cryptocurrency. In an example embodiment, the buyer may select a locker that is convenient for the buyer and/or seller. For example, if the buyer is a long distance away, the buyer may rent a locker near the seller and have the goods delivered via a delivery service, or the buyer may rent a locker near the buyer and have the goods delivered from the seller via a delivery service.

[0094] At 1 1 10, the seller is provided with an access code for the locker. The buyer may obtain the access from any source acceptable to the vendor associated with the locker and provide an access code to the seller. For example, the buyer may purchase access codes such as FUSION codes or codes may be provided to the buyer either from the transaction server 1 12 (FIG. 1 ), and/or the locker 1 14 (FIG. 1 ) which are provided to the buyer seller computing device 106 (FIG. 1 ). The access code may be an alphanumeric code that may be keyed into the locker or may be a token which can be wirelessly provided to the locker (e.g., a code that can be transmitted via NFC or optically scanned from the seller computing device 106 (FIG. 1 ) by the locker 1 14 (FIG. 1 )).

[0095] At 1 1 12, the seller put the goods into the locker. The seller employs an access code provided at 1 1 10 to gain access into the locker. The access code provided to the buyer may be the same code or a different code than the seller's code.

[0096] At 1 1 14, the buyer is notified that the goods are available. The notification may be sent by either the transaction server 1 12 (FIG. 1 ) or locker 1 14 (FIG. 1 ) to the buyer computing device 1 18 (FIG. 1 ). In an example embodiment, the buyer is provided with an access code with the notification. The access code provided to the buyer may be the same code or a different code than the seller's code. The access code may be an alphanumeric code that may be keyed into the locker or may be a token which can be wirelessly provided to the locker (e.g., a code that can be transmitted via NFC or optically scanned from the buyer computing device 1 18 (FIG. 1 ) by the locker 1 14 (FIG.

1 )).

[0097] At 1 1 16, the buyer retrieves the goods. In an example embodiment, the buyer has the opportunity to inspect the goods and return them within a predefined time period if unacceptable. If the goods are not returned within the predefined time period, the goods are considered accepted.

[0098] At 1 1 18, the seller is paid for the goods. In an example embodiment, the transaction server 1 12 (FIG. 1 ) may deduct a transaction fee that is separate from the locker rental fee. In particular embodiments, the buyer and/or seller receive electronic receipts via buyer computing device 1 16 (FIG. 1 ) and/or seller computing device 1 18 (FIG. 1 ) respectively.

[0099] As those skilled in the art can readily appreciate, an aspect of the example embodiments described herein allow the buyer and seller to conduct transactions without having to meet each other. Thus, the buyer and seller do not have to worry about being victimized by criminals, who may be violent, as has been known to happen with transactions conducted on many websites. Moreover, with the employment of a cryptocurrency, which may also include a smart contract, the buyer and seller may remain anonymous to each other, while at the same time, a distributed database such as blockchain may be employed to record and verify the transaction.

[0100] Described above are example embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the example embodiments, but one of ordinary skill in the art will recognize that many further combinations and permutations of the example embodiments are possible. Accordingly, it is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of any claims filed in the present application and/or applications claiming priority hereto interpreted in accordance with the breadth to which they are fairly, legally and equitably entitled.