Patent ID: 12190195

DETAILED DESCRIPTION OF THE DRAWINGS

As shown inFIG.1, the system may comprise a set of devices110for creating, maintaining, and receiving updates to a unit database120. The unit database may identify a product122, product codes123, a code unique to the product124, a particular unit of the product124, and a code126unique to each unit of the product. Thus, each unit may have a product code, which is shared amongst all units of that product, as well as its own unit code, which is unique and designated for it alone. The devices may be configured to scan the unit codes of actual physical products in order to access, update, and view the various parameters of given units.

To facilitate updates to the unit database, the unit code may be represented by a graphical signifier104thereof, and this graphical signifier may be affixed to the physical unit102. The graphical signifier may in turn be scanned using a scanning device106configured or otherwise adapted to scanning graphical signifiers.

The unit database may identify the physical location128of a given unit, such as an address or any meaningful subdivision or internal location, such as a warehouse lot and bin number. The scanning device may be configured to detect the proximity of various electromagnetic chips108which may indicate the warehouse lot and bin number.

As shown inFIG.2, in the unit database, a basic price may be set for the product, but a separate price can also be set for each unit of the product. Thus, as an example, there may be ten thousand units manufactured for a given product, and each of those ten thousand units may have the same price, or they may be divided into sets of units with each unit within a set having the same price, or each unit may have its price set individually. Price setting may be manual, automatic, based on a set of manually created rules, or based on automatic rules. Thus, sets of rules may be set for a given product210, with the sets being offered by the system or created by users. A first or base price for a product may be set212, a set of price rules may be selected214, and then based on the rules, prices may be set for each unit of the product216. An example of a rule may be that each progressively higher number of a unit has an incrementally higher price—thus the first unit may be set at a dollar, the second at a dollar and ten cents, the third at a dollar and twenty cents, the fourth at a dollar and thirty cents, and so on. If the base price is changed218, the unit pricing may be accordingly adjusted by the system for all remaining units220.

As shown inFIG.3, upon a unit being scanned by a scanning device310, the database data may then be updated automatically312based on various system parameters, and/or manually314by a user of the scanning device. System updates may also occur based on a combination of manual and automatic updates.

As shown inFIG.4, system parameters may include the identity of the user of the device410, the time at which scanning occurs412, the location at which the scanning occurs414, or detection of various proximal electromagnetic chips416by the device at the moment of scanning or recently thereto and the identification thereof418. The user identity may be entered manually during a scanning session, prior to the scanning session during a login session, or may have been previously set to the device. The time parameter may be detected based on an internal clock operating via software installed on the device. The location parameter may be detected using a GPS or alternative preferably highly precise location detection component. The electromagnetic chips detected by the device may include RFID or similar components which may be installed, integrated, or embedded in the physical structures in which the products and units are stored, such as in the bin, on the floor or ceiling, on the wall, on a cart or truck, etc. Detection of the proximity of these electromagnetic chips enables a degree of location precision which is otherwise not possible using GPS alone.

A user of the device may effectively update the database regardless of whether or not they know that their actions constitute or trigger an update of the database. For example, a worker may scan a unit before loading it onto a truck, or a buyer may scan a unit in order to purchase it—in both cases, the user has some particular action in mind, and they may or may not be aware that the unit database has been apprised of that action or some other circumstance or context relating to that unit.

The unit database may receive, for example from users of scanning devices, updates to units, as described above. In addition, as shown inFIGS.5-8, units may be identified as having been manufactured500, being ready for pick-up510, being in transit via truck520, boat and/or plane522, being delivered to a warehouse524, being stored in a warehouse526, being removed from a warehouse location528, being placed on another truck530, being delivered to a retail store532, being positioned on a shelf534, being under a discount536, having been scanned by a customer for tentative purchase538, having been added to a real or virtual cart540, being purchased and paid for542, being in transit to a buyer544, being received by the buyer546, reported to have a manufacturing defect546, reported to have been mislabeled548, reported to have been damaged during transit550, identified as having been damaged by a customer552, being outside a return window554, being packaged for return556, having been received for return delivery558, being in transit as a returned item560, having been returned to a retail store or warehouse562, having been destroyed or otherwise liquidated564, etc.

The unit database may also identify parties whose goods or services were involved in the design, development, intellectual property, material sourcing, manufacturing, managing, logistics, advertising, wholesale, retail, e-commerce, stocking, shipping, storing, or other activity or responsibility pertaining the product. Each such party may be designated a flat or percentile of the purchase price, the apportionment thereof being recorded in the unit database. The unit database may also identify the buyer of the product, as well as the parties responsible for the product if returned. Costs incurred due to defects in the product as manufactured, or damages to the product during storing or shipping, may also be applied to the relevant party. All of these payments and costs are tethered in the unit database to the unit and unit code.

The unit database may be in transactional communication with a cryptocurrency blockchain, with ownership of both the product as well as receipt of various portions of one or more cryptocurrency units being encoded and communicated as instructions to be executed by and recorded in the blockchain, as shown inFIG.8. Such instructions may be communicated automatically upon scans associated with various parameters are detected. For example, as soon as a unit of a product is purchased, the detection of which occurs via a scan by a buyer810, the price in crypto is subtracted from a crypto wallet owned by the buyer812and then transferred to the relevant parties814based on the portions owned to them as designated in the unit database. Similarly, if the item is returned, as detected by a return scan816, the initial purchase amount in crypto, minus certain costs, may be subtracted from the wallets of the relevant parties818reassigned to the buyer820and. Responsibility for the return, based on an error or omission, is determined822, penalties may be imposed onto parties responsible for defects, damages, or delays824. Such penalties may be transmitted to the administrative wallet of the system826, or subtracted from future payments to the same parties.

In one embodiment, as shown inFIG.9, payment to relevant parties occurs according to a specified order, with the order previously designated and saved in the unit database. The order may be entered into a interface field or an upload of a template or other document900and thereafter captured and incorporated into a so-called smart contract910, which may be accessed and viewed914at any time via scanning and access request912of an applicable unit code or product code. The specified order entails the payment received from the buyer first awarded to the first relevant party in the specified order. For example, if the order is: producer, first logistics, distributor, first warehouse, second logistics, retailer, third logistics, vendor, then the purchase price in crypto is first assigned to the producer, then a portion thereof is re-assigned to the first logistics party, then a portion thereof is re-assigned to the distributor, then to the warehouse, then to the second logistics, then to the retailer, then to the third logistics, and then to the vendor. The exact order will be the result of negotiations of these parties in creating the smart contract. In another embodiment, payment to relevant parties occurs simultaneously and in real time and in accordance to the flat or percentile-based payment designated for each relevant party. The system may be configured to execute order payment instructions by engaging in an API type connection with a platform configured to engage with the smart contract916

In one embodiment, each party is not necessarily aware of how much of the payment is transmitted to them and how much is transmitted to other relevant parties. Instead, they may only be aware of their portion of the transaction. For example, a manufacturer may be aware that a product has been sold, but only know the initial vendor or distributor involved in the chain, but not the logistics entities or the retailer.

The buyer may cart-scan a plurality of unit codes for the same or for a plurality of products. This scan does not result in a direct purchase, however, but instead to the adding of these cart-scanned units to a virtual cart from which the buyer may choose to keep or subtract units. Alternatively, the buyer may buy-it scan, in which the addition of the units to the virtual cart is skipped and instead purchased immediately upon being buy-it scanned. Payment for the units may occur in real time upon being buy-it scanned, or after approved for purchase in the virtual cart.

In one embodiment, when a buyer scans a unit code, a listing appears on their scanning device to confirm that the unit code pertains to the particular product being purchased. This prevents the purchase of units onto which the wrong unit code has been attached. The listing may show a variety of views of the product as well as a description as to what the product is, its condition, and its various features. The listing may also designate the identity of the recipients of the product, including their contact information, addresses, etc., thereby enabling a user to contact the recipients if the product is defective.

In one embodiment, the listing may indicate the price of the instant unit, and also the price of subsequent units, so that the buyer is aware of any inevitable price increases if the buyer does not use the opportunity to buy the instant unit price before it is purchased by another buyer.

As shown inFIGS.10-11, a user may cart-scan a group of units1000, listings for each of the units with their prices may be displayed on the scanning device1010, and prices for subsequent units (i.e., those which will be available after a current set of units are purchased) may also be displayed1012. The user may confirm purchase of the units1014, and the prices may be subtracted from the user's virtual (crypto) wallet1016. A blockchain may be updated to reflect the transfer of ownership of the unit1020. The (crypto) payment may be transmitted to relevant parties1022based on a previously designated order. If the user scans the units again or performs a return scan1030, the user may indicate a desire to return the units1032, and identify the reason for the return1034. The system will determine, based on the reason for the return, which relevant party is responsible1036, and then a portion or all of the payment made to the relevant party will be subtracted from that party or what that party is owed on future transactions1038. The system may receive an appeal from the relevant party1040, together with a transmission of digitized evidence1042, and if the appeal is accepted (i.e., granted)1044, return the subtracted payment1046.

A prospective buyer may perform a status scan of the unit code to determine if the product has any recalls associated with it, or whether or not it has been listed as stolen by a government agency or other relevant party. To prevent the same product from being purchased several times before being shipped to the buyer, a purchase scan may display on any subsequent buyer's scanning device that the unit has already been sold, thereby informing them that they will need to find a different unit.

In one embodiment, the unit code is incorporated into a product such that it cannot be removed, such as by permanently embedding a unit code formed of a durable material, such as a hard resin or metal, into the product itself. In another embodiment, the unit code is embedded in an electromagnetic chip such as an RFID, which is in turn embedded within the product. This prevents separation of the unit from its purchase history, thereby preventing theft and preserving the purchase history. Access to the unit database is account-password protected to prevent parties who not privy to the chain from inspecting the price, party, and purchase history. In another embodiment, all information pertaining to a unit is publicly available to see on the blockchain, so if an individual has access to a part of the history pertaining to a unit, the remainder can be discovered.