Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
MANAGEMENT SYSTEM FOR INVENTORIES INCLUDING FUNDING CARDS
Document Type and Number:
WIPO Patent Application WO/2024/105457
Kind Code:
A1
Abstract:
Systems and methods of managing inventory include holding title to the inventory in a third party after the inventory has been delivered to a location accessible to a producer (user of the inventory). The cost and accounting of the inventory can then be managed separately from the physical possession of the inventory. The producer may then access and take title to the inventory on demand (as needed).

Inventors:
DORAN MICHAEL C (US)
BONDE SANJAY (US)
SANDY SHIVA (US)
Application Number:
PCT/IB2023/055990
Publication Date:
May 23, 2024
Filing Date:
June 10, 2023
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
TRADE CAPITAL CORP (US)
International Classes:
G06Q10/087; G06Q10/0631; G06Q30/06; G06Q30/02; G06Q40/00
Attorney, Agent or Firm:
COLBY, Steven et al. (US)
Download PDF:
Claims:
CLAIMS

What is claimed is:

1. An inventory management system comprising: data storage configured to store at least inventory data and optionally to store: smart contracts, a blockchain, and/or any of the logic discussed herein; request logic configured to receive a request for inventory (optionally including goods) from a producer, the request including delivery of the goods to a location accessible to the producer; purchase order (PO) generation logic configured for a title holder to generate a purchase order for purchase of the goods from a supplier, the purchase order requiring delivery of the goods to the location accessible to the producer and transfer of title in the goods to the title holder; optional contract logic configured to generate an inventory management contract between the producer and the title holder, the inventory management contract including fee for holding title to the goods and a designation of the location accessible to the producer; inventory logic configured to track inventory on-hand for the producer and to update the inventory data, the goods being listed as on-hand inventory of the producer while title of the goods is held by the title holder; title logic configured to transfer title of the goods from the title holder to the producer after the goods have been stored at the location accessible to the producer, the title transfer being initiated by a purchase order received from the producer, the title transfer optionally being performed according to the inventory management contract, and a microprocessor configured to execute at least the purchase order generation logic or the title logic.

2. The system of claim 1, further comprising card logic configured to generate a physical or digital label for the goods at the location of the requester.

3. The system of claim 1 or 2, further comprising finance logic configured to receive offers to fund purchase of the goods by the title holder. 4. The system of claim 1, 2 or 3, further comprising blockchain logic configured to log ownership of the goods and the title transfer from the title holder to the purchaser.

5. The system of claim 1-3 or 4, further comprising an application programing interface (API) configured to receive the request for goods from an ERP (enterprise resource planning) system.

6. The system of claim 1-4 or 5, wherein the inventory data is configured to distinguish between on-hand goods in which the producer has title and on-hand goods in which the producer does not have title.

7. The system of claim 1-5 or 6, wherein the request logic is further configured to specify terms of a purchase of the goods, the terms including any combination of: a quantity, a part number, a price, payment terms, an interest rate, a fee for holding title to the goods, an identifier of the location accessible to the producer, and a maximum holding period in which the title holder will hold title to the goods.

8. The system of claim 1-6 or 7, wherein the request logic is configured to assure that the request for goods includes terms allowed or required by the supplier.

9. The system of claim 1-7 or 8, wherein the purchase order requires payment for the goods to be made from the title holder to the supplier, and designates the title holder as owner of the goods as of delivery or shipment of the goods.

10. The system of claim 1-8 or 9, wherein the location accessible to the producer is a physically secured location or container, optionally monitored by an access device configured to detect access to the goods and to communicate this access to the title logic, wherein the title logic is optionally configured to generate access credentials to the physically secured location or container.

11. The system of claim 1-9 or 10, wherein the inventory management contract is a smart contract executed automatically in response to, for example, passage of a designated maximum hold time for which the title holder is required to hold title to the goods, the producer accessing the location accessible to the producer, removal of the goods from the location accessible to the producer, receipt of a request for the goods from the producer, and/or data stored in a blockchain.

12. The system of claim 1-10 or 11, wherein the contract logic is further configured to execute an insurance contract configured to assure that the producer will perform under the contract. 13. The system of claim 1-11 or 12, wherein the inventory logic is configured to change a designation of on-hand inventory from on-hand but not owned to on-hand and owned, optionally responsive to the transfer of title of the goods.

14. The system of claim 1-12 or 13, wherein the title logic is configured to process payment for the goods from the producer to the title-holder, optionally automatically according the inventory management contract.

15. The system of claim 1-13 or 14, wherein the physical label for the goods is configured for placement at the location accessible to the producer, the physical label optionally including a printed label or an electronic label, the physical label optionally including any combination of the title holder of the goods, an identifier of the goods, a use-by date for the goods, a description of the goods, and an inventory entry for the goods.

16. The system of claim 1-14 or 15, wherein the card logic is configured to associate a physical or virtual card with the goods, the card optionally being associated with an account and a specific inventory management contract and/or purchasing agent, the card optionally being associated with specific contract terms and/or financial or other limits.

17. The system of claim 1-15 or 16, wherein the card logic is configured to distribute a plurality of cards to a plurality of purchasing agents, the distribution of cards representing the limits on purchases that can be made by each of the purchasing agents.

18. The system of claim 1-16 or 17, wherein the card logic is configured to set the fee for holding the inventory based on a level of risk associated with the producer, and optionally configured to calculate a credit rating for a particular purchase of goods.

19. The system of claim 1-17 or 18, wherein the card logic is configured to generate and/or distribute the cards responsive to a master contract between the producer and the title holder.

20. The system of claim 1-18 or 19, wherein the finance logic is configured to accept the offers to fund purchase of the goods, optionally from among multiple offers, and is optionally configured to bundle interests in fees charged for holding title to inventory for sale to investors.

21. The system of claim 1-19 or 10, wherein the blockchain logic is configured to store a record of any combination of: title to the goods, contract terms (e.g., fees, prices, maximum hold times), location of the goods, and shipping data, tracking numbers, delivery events, pull requests, and

22. A method of managing inventory, the method comprising: receiving a request for goods from a producer; optionally generating a contract between the producer and a title holder, the contract specifying that the title holder will hold title to the goods and the producer will purchase the goods from the title holder in the future; generating a purchase order for the goods; transmitting or supplying the purchase order to a supplier of the goods; paying the supplier for the goods; having the goods delivered to a location accessible to the producer; receiving a request to transfer title to the goods from the producer, optionally while the goods are located in the location accessible to the producer or the producer is in physical possession of the goods; optionally receiving payment from the producer for purchase of the goods; optionally receiving a fee or making a profit for holding title to the goods; and transferring title to the goods from the title holder to the producer.

23. The system or method of claim 1-22, further comprising Caas wallet logic configured to allow the use of any card logic stored and allow seamless transactions with all of them.

24. The system or method of claim 1-23, further comprising factoring card logic configured to allow increased cashflow for agents of the requester, individually or in aggregate, through the sale of accounts receivable based on an overall financial limit set by the Title Holder by leveraging proprietary intelligence to find the best combinations of buyers and sellers.

25. The system or method of claim 1-24, further comprising reverse factoring card logic configured to allow increased cashflow for customers of the requester, individually or in aggregate, based on an overall financial limit set by the Title Holder, the requester can set terms and help their customers in predefined logic leveraging proprietary intelligence to find the best combinations of buyers and sellers.

26. The system or method of claim 1-25, further comprising securitization card logic configured to allow reduced risk and increased access to capital for the requester, individually or in aggregate, based on an overall financial limit set by the Title Holder, the user can instantaneously get accesses to capital for their assets. 27. The system or method of claim 1-26, wherein The CaaS assessment score logic for assessing and quantifying the capital worthiness of a user based on data concerning an associated user, characteristics of the company using the factoring card, types of receivables sold using the factoring card, and/or the location of the suppliers and shippers used for the receivables using artificial intelligence. 28. The system or method of claim 1-27, wherein claims 1-27 operate in conjunction with any 2 single or multiple claims therein.

Description:
MANAGEMENT SYSTEM FOR INVENTORIES INCLUDING FUNDING CARDS Cross-Reference to Related Applications

This application is related to and claims benefit from the following US patent applications, each of which is hereby incorporated herein by reference in their entirety: 63/281,472 Filed 19-NOV-2021; 63/311,975 Filed 19-FEB-2022; 63/320,339 Filed 16-MAR-2022; 17/990,340 Filed 18-NOV-2022.

Background

Field of the Invention

The invention is in the field of inventory management, and in some embodiments managing title to inventory.

Related Art

Holding inventory represents an undesirable financial burden. However, even companies practicing "just in time" inventories require some inventory on hand. Holding inventory adversely impacts a company's financial standing and its balance sheet and therefore has disadvantages. OEMs, Suppliers and Contract Manufacturers try to push inventories to each other, and it is therefore a cause of friction for effective collaboration amongst these parties.

Summary

Systems and Methods of managing inventory include an automated system configured to transfer and manage title to physical, virtual or digital assets needed by a producer, supplier, and/or other holder of inventory so as to 1) keep title to the goods in a third party, while at the same time 2) allowing the goods to be physically present at a desired location of the producer/supplier/ title holder. The transfer of title and/or physical possession are optionally automatically performed using smart contracts configured to perform nearly instantaneous just in time inventory management.

The systems and methods described here are typically computer software-based systems configured to manage both inventory and title to the inventory.

While traditional inventory management includes optimizing inventory levels, lead times and critical last-minute scheduling of goods delivery, such approaches minimize inventory carrying costs at the expense of greater supply chain risk and resiliency due to unreasonably lower inventory levels or delayed cashflow to suppliers. The systems and methods disclosed herein allow for delivery of goods prior to title transfer in the good, thus achieving advantages of just in time inventory while avoiding many of the disadvantages. They allow for unconstrained holding of inventories to mitigate both risks and costs. Using the smart contracts (and execution systems disclosed herein), more optimal cost distribution is achieved and risk reduced. The financial burden of carrying inventory is separated from the inventory itself, creating a marketable and financeable derivative as a secondary advantage. Such, advantages are achieved using new types of inventory management logic and devices, as is further described herein.

Various embodiments of the invention include an inventory management system comprising: data storage configured to store at least inventory data and optionally to store: smart contracts, a blockchain, and/or any of the logic discussed herein; request logic configured to receive a request for goods from a producer, the request including delivery of the goods to a location accessible to the producer; purchase order (PO) generation logic configured for a title holder to generate a purchase order for purchase of the goods from a supplier, the purchase order requiring delivery of the goods to the location accessible to the producer; optional contract logic configured to generate an inventory management contract between the producer and the title holder, the inventory management contract including fee for holding title to the goods and a designation of the location accessible to the producer; inventory logic configured to track inventory on-hand for the producer and to update the inventory data, the goods being listed as on-hand inventory of the producer while title of the goods is held by the title holder; title logic configured to transfer title of the goods from the title holder to the producer after the goods have been stored at the location accessible to the producer, the title transfer being initiated by a purchase order received from the producer, the title transfer optionally being performed according to the inventory management contract, and a microprocessor configured to execute at least the purchase order generation logic or the title logic.

Various embodiments of the invention include a method of managing inventory, the method comprising: receiving a request for goods from a producer; optionally generating a contract between the producer and a title holder, the contract specifying that the title holder will hold title to the goods and the producer will purchase the goods from the title holder in the future; optionally title held until: a purchase order is received from the producer, a maximum hold time is reached, the producer accesses the goods; generating a purchase order for the goods; transmitting or supplying the purchase order to a supplier of the goods; paying the supplier for the goods; having the goods delivered to a location accessible to the producer; receiving a request to transfer title to the goods, optionally while the goods are located in the location accessible to the producer or the producer is in physical possession of the goods. Optionally, receiving payment from the producer for purchase of the goods; optionally receiving a fee for holding title to the goods (or making a profit on the payments), and/or transferring title to the goods from the title holder to the producer.

Brief Description of the Drawings

FIG. 1 illustrates an automated inventory management system, for managing inventory and title thereto, according to various embodiments of the invention.

FIG. 2 illustrates methods of managing title to inventory, according to various embodiments of the invention.

Detailed Description

3PL shall mean a third party logistics service provider.

5G+ shall mean fifth generation or later cellular networks, and presently the fastest wireless technologies

Access credentials shall mean any user name, identification number, password, license or security key, security token, PIN, or other security code, method, technology, or device used, alone or in combination, to verify an individual or device's identity and authorization to access and use services.

Access Device shall mean any Card, plate, code, account number, electronic serial number, mobile identification number, personal identification number, or other telecommunications service, equipment, or instrument identifier, or other means of account access that can be used, alone or in conjunction with another access device, to obtain money, goods, services, or any other thing of value, or that can be used to initiate a transfer of funds. An access device may include, for example, a smartphone, tablet computer, an internet browser, a personal computer, and/or the like. Alert shall mean a warning or alarm of an impending event. An alert may be communicated via a telephone call, a text message, an e-mail, TCP/IP, or any electronic, visual or audio communication means.

API shall mean "application programming interface" a set of protocols used by programmers to create applications for a specific operating system, to interface between the different modules of an application, or to interface between different (possibly remote) applications. Assets shall mean property owned by a person or entity, regarded as having value and optionally available to meet debts or commitments.

ASN or advanced shipment notice shall mean a message, electronic or otherwise, sent from the shipper to the receiver prior to the departure of the shipment from a shipper's facility. Automated shall mean operated by mostly automatic equipment or software or without human intervention.

Balance Sheet shall mean a statement of the assets, liabilities, and capital of a business or other organization at a particular point in time, detailing the balance of income and expenditure over the preceding period.

Big Data Analytics shall mean the use of advanced analytic techniques against very large, diverse data sets that include structured, semi-structured and unstructured data, from different sources, and in different sizes from terabytes to zettabytes and more.

Blockchain shall mean a system in which records of transactions are duplicated and maintained across several computers that are linked in a peer-to-peer network in an effort to add trust and authenticity.

Branded Factoring Card is a factoring card which is branded by an entity, including for example a bank, for issuance to customers or a specific group thereof.

CaaS Assessment Score shall mean a calculated score for assessing and quantifying the capital worthiness of a user. Such CaaS Assessment Score may be calculated using a unique combination of inputs and/or a machine learning system (e.g., neural network) and may have a variety of uses as described herein.

CaaS Wallet shall mean a system that securely stores a user's information and Cards; or an embodiment of various Cards offering services described herein, to include but not limited to Inventory Cards, Factoring Cards, Securitization Cards, Leasing Cards.

Cards shall mean any one of or combination of Inventory Cards, Factoring Cards, Reverse Factoring Cards and Securitization Cards, and/or other Cards discussed herein. Cards may be represented by virtual systems, data records, smart contract, logic, and/or other elements described herein. For example, Cards may be implemented in hardware, firmware, and/or software embodied in a non-transient computer readable medium. Specific Cards are configured to represent the functionality and/or have specific characteristics as described in the various examples disclosed herein.

Cloud computing shall mean the on-demand availability of computer system resources, especially data storage and computing power, without direct active management by the user.

Computing Device shall mean a functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations without human intervention or a machine (real or virtual) for performing calculations automatically (including, but not limited to, computer, servers, routers, switches, integrated circuits, digital memory, etc.). A computing device may consist of a standalone unit or several interconnected units in a network, directly or indirectly.

Contract Manufacturer or CM shall mean a company, organization, firm or business that performs contract manufacturing.

Contract Manufacturing shall mean the process of hiring another entity to make products on behalf of a business or company, typically with the objective to keep costs low or without having to build or run an onsite factory to routinely build its own products.

Contract shall mean an agreement between two or more parties for the doing or not doing of something specified; or an agreement that is intended to be enforceable by law.

Credit Rating shall mean a classification of credit risk based on investigation of a customer's or potential customer's financial resources, prior payment pattern, and history or degree of responsibility for debts incurred.

Crypto shall mean information or assets stored in decentralized consensus databases, e.g. blockchain, and secured by cryptography. Crypto may include crypto currency or noncurrency information or assets.

Currency shall mean a system of money in general use in a country or region.

Cybersecurity shall mean the state of being protected against the criminal or unauthorized use of electronic data, or the measures taken to achieve this.

Cybersecurity risk shall mean the probability of exposure or loss resulting from a cyber attack or data breach and the potential loss or harm related to technical infrastructure, use of technology or reputation of an entity

Data shall mean individual facts, statistics, or items of information; information in digital format, as encoded text or numbers, or multimedia images, audio, or video; or a body of facts or information.

Data Storage shall mean the use of recording non-transient media to retain data using computers or other devices.

Delivery shall mean the transfer of the physical possession of personal property from one person or entity to another person or entity.

Delivery Event shall mean an instance of delivery.

Derivative shall mean an asset whose value is based on a source other than the asset itself. Designate shall mean to nominate or select for a duty, office, purpose, etc.; appoint; assign. Designation shall mean an act of designating.

Electronic shall mean of or noting computerized products, services, or technologies, for example, including electronic circuits.

ERP shall mean "enterprise resource planning," a system that integrates enterprise-wide. Information including human resources, financials, manufacturing, and distribution as well as connects the organization to its customers and suppliers.

Factoring shall mean the process by which a business representative sells pending accounts receivable for a discount to generate cash flow. Logic disclosed herein may be configured to automatically perform Factoring.

Factoring Card shall mean an account offered by a Title Holder or prospective Title Holder and accessed by an Access Device by which an approved user can sell accounts receivable at a predefined rate and volume limit or at a rate and volume limit arrived at by a process agreed upon in advance. Such account may be represented by a Card.

Fee shall mean a fixed or variable price charged for a service.

Fund shall mean to allocate payment or provide payment, e.g., to fund purchase of goods.

Future purchase - a purchase by a party of goods at a future date.

Generate shall mean to bring into existence; cause to be; or produce.

Human augmentation shall mean the creating of cognitive and physical technological improvements as an integral part of the human body.

Goods shall mean physical or virtual items that can be used and stored, for example, electronic components, food stuffs, mechanical components, digital artifacts, etc.

Holder shall mean a person or entity that holds something, physically or digitally.

Holding period shall mean a period that a person or entity holds something, e.g., the period between the purchase and sale of an asset.

Image Recognition shall mean the ability of software to identify objects, places, people, symbols, writing and actions in images.

Insurance shall mean the act, system, or business of insuring property, life, persons, etc., against loss or harm arising in specified contingencies, as fire, accident, death, disablement, or the like, in consideration of a payment proportionate to the risk involved.

Intelligent Process Automation shall mean the application of Artificial Intelligence and related new technologies, including Computer Vision, Cognitive automation and Machine Learning to automation.

Inventory Card shall mean an account offered by a Title Holder or prospective Title Holder and accessed by an Access Device by which an approved user can order assets, goods or services for the user's future use without taking title to such assets, goods or services until some future time.

Inventory shall mean assets, including physical, digital, or virtual assets, held for use in a trade, business, or other economically productive activity.

Inventory Handling and Safekeeping Contract (IHSC) is a service contract between the titleholder and producer or producer's designee to manage and report on inventories on behalf of title holder for a fee.

Inventory Management shall mean services, supervision and decision making in relation to inventory.

Internet of things (IOT) shall mean physical objects (or groups of such objects) that are embedded with sensors, processing ability, software, and other technologies, and that connect and exchange data with other devices and systems over the Internet or other communications networks.

Just in time shall mean a manufacturing system or process in which materials or components are delivered (e.g., made available on-hand) immediately before they are required in order to minimize inventory costs.

Label shall mean a word or phrase indicating that which is associated with the label belongs in a particular category or classification.

Lien shall mean a charge imposed upon specific property, real or personal, by which it is made security for the performance of an act; a qualified right of property which a creditor has in or over specific property of his debtor, as security for the debt or charge or for performance of some act.

Logic shall mean hardware, firmware, and/or software stored on a non-transient computer readable medium.

Machine Vision Technology shall mean systems, such as a camera and/or artificial intelligence logic, configured to achieve image recognition.

Master contract shall mean an agreement that consolidates and separates related agreements between the same parties.

Method shall mean a particular form of procedure for accomplishing or approaching something.

Microprocessor shall mean an integrated computer circuit that performs all the functions of a central processing unit.

On-hand shall mean present or available for a specified purpose, for example, stored at nearby location for immediate use.

Optical Character Recognition or Optical Character Reader shall mean the electronic or mechanical conversion of images of typed, handwritten or printed text into machine- encoded text, whether from a scanned document, a photo of a document, a scene-photo or from subtitle text superimposed on an image.

Outlier shall mean an observation or data point that is well outside of the expected range of values.

Part number shall mean an identifier of a particular part, design or material used to simplify reference to that item.

Payment terms shall mean the conditions surrounding the payment part of a sale.

Physical possession shall mean to exercise dominion or control over tangible property.

Physical shall mean of or relating to that which is material.

Pre-population shall mean insertion of data into a form or similar document in advance of the completion of same by a person.

Price shall mean the amount of money expected, required, or given in payment for something. Procurement shall mean the action of obtaining or procuring something.

Producer or Original Equipment Manufacturer or OEM shall mean a person or entity who creates economic value or produces goods and services.

Profit shall mean pecuniary gain resulting from a transaction.

Pull order shall mean a notice or instruction issued by the producer to the title holder for the purchase of goods.

Pull Ordering System shall mean the ordering of stock to replace the stock that has been sold. An inventory replacement system that is used by companies or others to replenish their stocks that are for sale.

PO or Purchase Order shall mean a written, virtual or electronic document or set of instructions that a buyer sends to a seller to document the sale of physical, virtual or digital products and services specifying some or all of delivery date, price, quantity, quality, technical specifications, location and/or other terms and conditions.

Purchase Price Variance or PPV shall mean the difference between the actual purchased price of an item and a standard (or baseline) purchase price of that same item.

Purchasing Agent shall mean a person or computer program or algorithm who purchases products, goods or services after screening the products for various qualities and specifying prices and quantities.

Quantity shall mean the amount or number of a material or immaterial thing not usually estimated by spatial measurement.

Quantum computing shall mean a process of computing focused on developing computer technology based on the principles of quantum theory

Risk shall mean the hazard or chance of loss.

Reverse Factoring Card shall mean an account offered by a Title Holder or prospective Title Holder and accessed by an Access Device by which an approved user can ensure a supplier gets paid in cash at an earlier date while the approved user does not have to pay cash until a later date , with the approved user paying for the service at a predefined rate and volume limit or at a rate and volume limit arrived at by a process agreed upon in advance.

Sales Order shall mean a document or set of electronic instructions that a seller sends to a buyer to document the sale of products and services to be delivered at an appointed date, location and upon certain terms and conditions. Security shall mean an obligation, pledge, mortgage, deposit, lien, etc., given by a debtor in order to make sure the payment or performance of his debt, by furnishing the creditor with a resource to be used in case of failure in the principal obligation.

Securitization Card shall mean a card representing an account offered by a bank or finance company to customers and accessed by an Access Device by which an approved user can order and / or secure physical access to assets, goods or services for the user's future use without taking title to such assets, goods or services until some future time, and (i) the assets, goods or services are bundled and / or packaged into securities, (ii) such securities are sold to generate the cash to pay the sellers of such assets, goods or services and (iii) such securities provide the purchasers with a predefined rate of return and are subject to predefined limit, or are sold pursuant to an agreement which provides a mechanism to define the rate of return and limits.

Shipping data shall mean data regarding shipping instructions covering such variables as service mix or distribution, domestic or international destinations, import or export codes, weight distributions, payee, and zone or lane distribution.

Smart Contracts shall mean a self-executing contract with the terms of the agreement between buyer and seller, optionally being directly written into lines of code.

Software shall mean programs and other operating information used by a computer Specifications shall mean a detailed precise representation of something or of a plan or proposal for something, software is typically stored on non-transient computer readable media.

Supplier shall mean a person or entity that provides something needed, including goods, a product or service.

Supply chain shall mean the sequence of processes involved in the production and distribution of a commodity, good, asset or service.

Title shall mean ownership of property that is cognizable or enforceable in a court of law, or one that is complete and perfect in terms of the apparent right of ownership.

Title Holder shall mean a person or entity in who holds title to an asset.

Track shall mean to follow or pursue the path or physical location of something.

Tracking Number shall mean a unique identifying number profit associated with a shipment and used to track it.

Transfer of Title shall mean conveyance of title from one title holder to another on land, sea, in space, virtually, or in any other jurisdiction.

UCC shall mean the Uniform Commercial Code as adopted by various jurisdictions, or any set of laws governing commercial transaction anywhere in the world.

User shall mean a person who uses a computer, device, or application.

Virtual shall mean existing, seen, or happening other than in person or in the physical world. Branded Inventory Card - an inventory card which is associated with a particular issuer, sponsor, collaborator or other entity and carries identifying brand names or logos of such entity.

Usage Points - a means by which various aspects of the use of an inventory card can be quantitative and measured, including the frequency and volume of transactions initiated using the card, different types goods for which the card is utilized, geography, credit quality or industry of suppliers, etc.

Rewards Points - numerical units of measurement of the use of an inventory card, which may be tracked, accumulated, transferred and/or redeemed for something of value to the user of the inventory card.

The system and methods described herein may be used in transactions involving two, three or more parties. In an illustrative example, three parties are involved. These parties are referred to herein as a "producer," a "supplier" and a "title holder." The producer is a party that receives inventory from a supplier for the purpose of using the inventory to produce additional goods, to sell goods, to provide a service, and/or otherwise consume the inventory. The supplier is a party that provides the inventory to the producer. The supplier may be an original equipment manufacturer (OEM), or an intermediate producer in a supply chain. The title holder is a party that holds title to inventory, optionally after the inventory has been delivered to a location accessible to the producer, until the producer is ready to use the inventory at which time the title holder transfers title to the producer. The title holder typically takes title from the supplier. The title holder is typically a third party and may be the manager or a subscriber to the system described in FIG. 1. In alternative embodiments, the role of "title holder" is performed by the "supplier."

In an exemplary use case: the producer will determine a future need for inventory (e.g., including goods), the producer will send a request for this inventory to the supplier and/or the title holder. The title holder generates a purchase order that transfers title of the inventory from the supplier to the title holder and requests that the inventory be delivered to a location accessible to the producer. When the producer is ready to use the inventory, the producer notifies the title holder, and the title holder transfers title to the producer (and makes payment for the inventory to the title holder). Such notice is optionally automatically generated by tracking movement of the inventory from the location accessible to the producer to, for example, a production floor. Payment is optionally performed according to a smart contract. In this process, the producer avoids taking title to the inventory until needed, while at the same time, the inventory is positioned in convenient location for access by the producer and is considered "on-hand."

FIG. 1 illustrates an automated Inventory Management System 100, configured, for managing inventory and title thereto, according to various embodiments of the invention. Inventory Management System 100 may be embodied in a single computing device or a network of connected computing devices using software to execute logic mentioned herein. Inventory Management System 100 is distinguished, in part, by elements configured for designating and transferring title to goods separately from the physical possession of the goods. For example, a producer may need inventory to produce a product, physical or digital, then using Inventory Management System 100, may take physical possession of the inventory prior to taking title to the inventory. Title is optionally held by a third party until the inventory is needed to be utilized by the producer.

Inventory Management System 100 includes a Data Storage 110. Data Storage 110 is configured to store at least inventory data 111 and, in various embodiments, store smart contracts 112, blockchain data 113, procurement and purchase order data 114 any of the logic discussed herein, executable computer code, procurement information, sales information, pricing, libraries of good and specifications, maximum and minimum future sales dates and/or the like.

Data Storage 110

Data storage is configured to store at least inventory data 111 and optionally to store: smart contracts 112, blockchain data 113, and/or any of the logic discussed herein via executable software; Whereas the inventory data 111 is configured to distinguish between on-hand goods in which the producer has title and on-hand goods in which the producer does not have title but may have future rights and obligations associated with the inventory. The storage of the inventory data 111 or the logic may be stored on premise or may be on cloud or on distributed computing systems operating together in unison or under a common command structure. The inventory data 111 may expand and/or updated over time based on the occurrence of events or transactions associated with inventory and stored accordingly for ease of retrieval. Inventory data 111 is optionally stored in a blockchain.

In some embodiments, the Data is further enhanced by the capabilities of intelligent process automation to learn and preconfigure repetitive tasks e.g., automated or nonautomated tagging.

In some embodiments, the data stored in Data Storage 110 is optionally collected over 5G+ networks using IOT devices to offer near real time data tracking.

In some embodiments, the Data Storage 110 is further enhanced by the capabilities of big data management to analyze trends and offer predictions, outliers and other relevant inferences for the management of inventories and title and manage cyber security risks e.g., the addition of master data and/or meta data elements targeted to enrich and enhance the capabilities of the data logic.

Request Logic 115

Request logic is configured to receive a request for immediate or future acceptance of goods from a producer under a master contract, the request including any combination of quantity, date, price and terms, specifications, shipping conditions, and/or delivery of the goods to a location accessible to the producer, wherein such location may be owned and operated by the producer or by a contracted third-party holding physical custody of the goods. Such requests for goods may be sent and received electronically or physically. Optionally, the location accessible to the producer is typically a physically secured location or container, optionally monitored by an access device configured to detect access to the goods and to communicate this access to the title logic, wherein the title logic is optionally configured to generate access credentials to the physically secured location or container. The logic (Request Logic 115) referred herein allows for generating of access credentials for purchaser based on selfdetermination of purchase decisions of available or to-be available goods on predetermined terms. As used herein "location accessible to the producer" is meant to refer to a location from which the producer can easily retrieve inventory, e.g., a warehouse proximate to a manufacturing facility at which the inventory is consumed. For example, a location accessible to a user may be a warehouse from which the producer can retrieve truckloads or pallets of inventory during a day's production run. The location accessible to a user may be located on a production floor. A location accessible to a producer is one more conveniently accessible than a source of the goods. Typically, inventory is stored at the location accessible to the producer until needed by the producer.

In some embodiments, the request logic 115 is further configured to generate specifications of terms of a purchase of the goods, including any combination of: a quantity, a part number, a price, payment terms, an interest rate, a fee for holding title to the goods, an identifier of the location accessible to the producer, and a maximum holding period in which the title holder will hold title to the goods.

In some embodiments, the request logic 115 is further enhanced by the capabilities of intelligent process automation to learn and preconfigure repetitive tasks e.g., forecasting and auto population of purchase or sales orders, detection of outliers and alerts thereto, and population of recommendations.

In some embodiments, the entirety of this request logic 115 is configured to assure that the request for goods includes terms allowed or required by the supplier on a pre-agreed basis pursuant to Contract logic 125 below and entered into smart contracts based on a block chain.

In some embodiments, the Data logic 115 is further enhanced by the capabilities of quantum computing for the purpose of handle operations at speeds substantially higher than conventional computers

In some embodiments, the Data logic 115 is optionally executed over cloud computing for the purpose of offering amongst other benefits - back-up and restore data, improved collaboration, accessibility, lower maintenance cost, high response, use of mobility devices, services in the pay-per-use model, substantial data storage capacity and data security.

PO Generation Logic 120

The three parties involved in purchase order generation logic are (a) producer; (b) title holder or prospective title holder; and (c) supplier. Purchase order (PO) generation logic 120 is configured for use by a prospective title holder to automatically import, from a producer, requisite purchasing and contractual data necessary to generate a purchase order for purchase of the goods from a supplier based on producer requests received from Request logic 115 and copied over into a block chain smart contract for further execution. The purchase order optionally requiring delivery of the goods to the location accessible to the producer; and/or automatic pre-population of purchase order information by usage of data from producers ERP system and strategic procurement systems. In some embodiments, PO generation logic 120 automatically uploads and updates 3PL and shipping contracts associated with a PO for tracking of physical inventories from dispatch by a supplier until future purchase by producer, onto blockchain logic 150.

In some embodiments, the PO generation logic 120 is further enhanced by the capabilities of intelligent process automation to learn and preconfigure repetitive tasks e.g., forecasting and auto population of purchase or sales orders, detection of outliers, intelligent recommendations.

In some embodiments, the purchase order requires payment for the goods to be made by the title holder to the supplier on terms imported from producer requests into a smart contract which designates the title holder as owner of the goods as of delivery or shipment of the goods. Wherein a first right for purchase of the goods by the producer is granted and recorded in the smart contract and associated block chain. After issuance of the purchase order, associated data is stored in the Data Storage 110 with further addition of data related to financing of the goods purchase and recording of insurances, liens, and rights related to return of goods to suppliers.

Contract Logic 125

Optional contract logic 125 is configured to generate an inventory management contract between the producer and the title holder. The inventory management contract sets terms including fee for holding title to the goods and a designation of the location accessible to the producer for future purchase;

In some embodiments, the inventory management contract is a smart contract executed automatically in response to, for example, passage of a designated maximum hold time for which the title holder is required to hold title to the goods, the producer accessing the location accessible to the producer, removal of the goods from the location accessible to the producer, receipt of a purchase order for the goods, and/or data stored in a blockchain.

In some embodiments, the contract logic 125 is further configured to execute an insurance contract configured to assure that the producer will perform under the contract. Contract logic describes liens, UCC registrations, cost allocations, rights and responsibilities for safeguarding of goods and purchase terms including but not limited to pricing, payment currency including crypto currency and other terms agreed by the producer for future purchase of the goods as set in Request logic 115. Optionally, contract terms are loaded onto a smart contract and associated blockchain.

Optionally, contract logic 125 is also configured to generate an Inventory Handling and Safekeeping Contract (IHSC) between the titleholder and producer or producer's designee to manage inventories on behalf of title holder for a fee. The IHSC sets service terms including producer's obligations, fees for managing inventories pursuant to any service level agreements, and obligations of the producer on reporting on inventory status, real-time or otherwise, and all data associated with inventory pursuant to data logic 115. Inventory Logic 130

Optional inventory logic 130 configured to track inventory on-hand, real-time or otherwise, for the producer and to update the inventory data, the goods being listed as on-hand inventory of the producer while title of the goods is held by the title holder;

In some embodiments, the inventory logic 130 is configured to provide first right of use of onhand inventory by producer and copied over on blockchain logic 150 with associated smart contracts e.g., forecasting and auto population of purchase or sales orders, detection of outliers and alerts thereto, and population of recommendations.

In some embodiments, the Inventory logic 130 is further enhanced by the capabilities of intelligent process automation to learn and preconfigure repetitive tasks e.g. forecasting and auto population of purchase or sales orders, detection of outliers, intelligent recommendations. In some embodiments, the Inventory logic 130 is further enhanced by the capabilities of human augmentation to automatically collect data related to any physical movement of inventories e.g., forecasting and auto population of purchase or sales orders, detection of outliers and alerts thereto, and population of recommendations.

In some embodiments, the Inventory logic 130 is optionally executed over 5G+ networks using IOT devices to offer near real time data tracking e.g. forecasting and auto population of purchase or sales orders, detection of outliers and alerts thereto, and population of recommendations.

In some embodiments, the inventory logic 130 is configured to change a designation of onhand inventory from on-hand (available) but not owned to on-hand and owned, optionally responsive to the transfer of title of the goods. Inventory logic 130 may be inserted onto smart contracts and associated blockchains to host contract logic 125 and execute PO Generation logic 120.

Title Logic 135

Title logic 135 configured to transfer title of the goods from the title holder to the producer after the goods have been stored at the location accessible to the producer, the title transfer being initiated by a pull order received from the producer or an automated sales order issued by the title holder, the title transfer optionally being performed according to the Inventory Management Contract, and Request Logic 115;

In some embodiments, the title logic 135 is configured to process payment terms for the goods from the producer to the title holder, optionally automatically according to the inventory management contract commonly called a vender managed inventory contract, automatic filing of UCC filings, related changes in security interests and liens, producer's rights for return of goods, automatic confirmation of amounts due and payable by the producer.

In some embodiments, the Title logic 135 is optionally executed over 5G+ networks using IOT devices to offer near real time data tracking optionally using Intelligent Process Automation and optionally RFID tags and other software to track physical movement of goods.

CaaS Wallet Logic 137

CaaS Wallet Logic 137 is configured to store one or more of Inventory Card Logic 140 (discussed further elsewhere herein). Leasing Card Logic 138, Factoring Card Logic 141 or Reverse Factoring Card logic 142 or Securitization Card Logic 143. CaaS Wallet Logic 137 is configured to allow the use of any card logic stored and seamless transactions with all of them. The holder of the CaaS wallet is configured to store financial accounts to allow movement of funds and to execute transactions and track histories.

In some embodiments, the CaaS Wallet logic 137 is configured for associated PINs or biometrics of holders to be associated with specific cards. For example, CaaS Wallet Logic 137 may be required to perform various levels of authentication for selecting various cards in the wallet. It may also be used to delegate authority to others to use the cards.

In some embodiments, the CaaS Wallet Logic 137 is configured to is configured to allow payments between different CaaS Wallet Logic 137 holders. For example, a CaaS wallet holder can leverage the wallet to pay a supplier if that supplier also has a CaaS wallet.

In some embodiments, the CaaS Wallet Logic 137 is configured to allow usage across different cards in a Caas Wallet Logic 137. For example, a user of a CaaS Wallet Logic may use the Securitization Card to secure inventory ordered on the Inventory Card in order to obtain more favorable terms.

In some embodiments, the CaaS Wallet Logic 137 is configured to is configured to generate alerts and reports based on the usage of the cards in that wallet.

Inventory Card Logic 140

Inventory Card Logic 140 is configured to allow financial purchasing power to purchasing agents of the requester, individually or in aggregate, based on an overall financial limit set by the Title Holder in contrast to a credit card, where a user can immediately purchase assets against which a liability is simultaneously created or a debit card where a user can purchase by simultaneous use of a current cash or other asset balance. Inventory Card Logic may be configured to provide users with virtual "inventory cards," with which they can place orders for or related to inventory.

In some embodiments, the Inventory card logic is configured to distribute multiple inventory purchasing Inventory Cards associated with a master financial account to a number of purchasing agents, each Inventory card representing the limits on purchases that can be made by each of the purchasing agents.

In some embodiments, the Inventory Card Logic 140 is associated with limits other than financial amounts. For example, an "inventory card" may be restricted to particular product types, specific vendors, specific smart contract terms, particular assessment scores, and/or the like. For example, in some embodiments, Inventory Card Logic 140 is configured to provide inventory cards to purchasing agents, the inventory cards have different financial limits (e.g., dollar amount limits) as a function of an assessment score representing a financial risk associated with an inventory supplier. In another example, an inventory card may require different smart contract terms, (e.g., interest rates, prices, time lengths) responsive to a transaction amount and/or assessment score. Inventory Card Logic 140 may be configured to provide different inventory cards to different users, the different inventory cards having different limitations.

In some embodiments, the Inventory Card Logic 140 is associated with factoring of invoices. For example, an "inventory card" may be restricted invoices, specific vendors, specific smart contract terms, particular assessment scores, and/or the like. For example, in some embodiments, Inventory Card Logic 140 is configured to provide inventory cards to purchasing agents, the inventory cards have different financial terms (e.g., invoice turn around time) as a function of an assessment score representing a financial risk associated with an inventory supplier. In another example, an inventory card may require different smart contract terms, (e.g., interest rates, prices, time lengths) responsive to a transaction amount and/or assessment score. Inventory card Logic 140 may be configured to provide different inventory cards to different users, the different inventory cards having different limitations.

In some embodiments, the Inventory Card Logic 140 is associated with leasing terms. For example, an "inventory card" may be restricted assets e.g. buildings or materials that are to be leased as opposed to owned, specific vendors, specific smart contract terms, particular assessment scores, and/or the like. For example, in some embodiments, Inventory Card Logic 140 is configured to provide inventory cards to purchasing agents, the inventory cards have different financial terms (e.g., preapproved leasing terms) as a function of an assessment score representing a financial risk associated with a supplier. In another example, an inventory card may require different smart contract terms, (e.g., interest rates, prices, time lengths) responsive to the asset to be leased and/or assessment score. Inventory Card Logic 140 may be configured to provide different inventory cards to different users, the different inventory cards having different limitations.

In some embodiments, the Inventory Card Logic 140 is configured to allow for securitization of the assets being purchased. For example, an "inventory card" may allow the issuing entity to sell securitized bundles of these assets for better financing rates to parties funding the Inventory card.

In some embodiments, the Inventory Card logic is configured to calculate an Inventory Assessment Score associated to the purchasing agent, the scores associated with a master financial account affects the finance logic. The inventory assessment score can be based on, for example, experience/seniority of an associated user, characteristics of the company using the inventory card, types of inventory purchased using the inventory card, and/or the location of the suppliers and shippers used for the inventory. The carbon footprint involved in the process may be used. An Inventory assessment Score may be used as a term in a smart contract, which impacts execution and/or output of the smart contract.

In some embodiments, the Inventory Card logic is configured for associate PINs to purchasing agents and to be associated with specific contract terms and limits. For example, Inventory Card Logic 140 may be required to perform various levels of authentication for transactions made using an inventory card, these levels are optionally responsive to the parties of the transaction, inventory type, and/or transaction amounts. It may also be used to delegate authority and to dispute transactions.

In some embodiments, Inventory Card Logic 140 is configured for branding by entities such as a bank for specific customers. These are deemed Branded Inventory Cards. Association of Inventory Cards with a brand (e.g., a financial company or manufacturing company), is optionally used to set default restrictions and/or terms on the Inventory Cards. Branded Inventory Cards can also be used in "white label" arrangements, where the entity whose branding is on the card contracts with another entity to issue, manage, and / or assist with the inventory card.

In some embodiments, Inventory Card Logic 140 is configured for geolocation features that is configured to associated with specific contract terms and limits. In some embodiments, Inventory Card Logic 140 is configured to allow messages to be broadcast to users associated with the inventory cards.

In some embodiments, Inventory Card Logic 140 is configured to calculate Usage points, these points can be used to affect finance logic.

In some embodiments, Inventory Card Logic 140 is configured to calculate Rewards Points. Rewards Points can be used to incentivize or reward users of the inventory card in preference to alterative means of funding inventories.

In some embodiments, Inventory Card Logic 140 is configured to issue inventory cards in tiers, each tier being associated with specific contract terms and limits.

In some embodiments, Inventory Card Logic 140 includes fraud detection logic. The fraud detection logic may be configured to perform fraud detection on a per order basis, on a per contract basis, on a per supplier basis, and/or the like.

In some embodiments, Inventory Card Logic 140 will capture financial considerations associated with the purchase of the inventory, title, asset values and description, related obligations and liabilities associated with specific contract terms and/or limits and generate automated reports and statements thereof at set period of time indicating balances outstanding and settled.

In some embodiments, Inventory Card Logic 140 also generates a physical/digital label for the goods at the location of the requester. Wherein the physical label for the goods is configured for placement at the location accessible to the producer, the physical label optionally including a printed label or an electronic label, the physical label optionally including any combination of the title holder of the goods, an identifier of the goods, a use- by date for the goods, a description of the goods, and an inventory entry for the goods.

In some embodiments, Inventory Card Logic 140 is configured to associate a physical or virtual card with the goods, the Inventory card optionally being associated with a specific inventory management contract and/or purchasing agent, the Inventory card optionally being associated with specific contract terms and/or limits.

In some embodiments, Inventory Card Logic 140 is optionally configured to set the fee for holding the inventory based on a level of risk associated with the producer, and optionally configured to calculate a credit rating for a particular purchase of goods.

In some embodiments, Inventory Card Logic 140 is configured to generate and/or distribute the Inventory cards responsive to a master contract between the producer and the title holder pursuant to Contract logic 125.

Factoring Card Logic 141

Factoring Card Logic 141 is configured to allow increased cashflow for agents of the requester, individually or in aggregate, based on an overall financial limit set by the Title Holder in contrast to the standard process where an agent has to or would like to find a purchaser and negotiate fees and limits. These are predefined in the Factoring Card Logic 141, leveraging proprietary intelligence to find the best factoring combinations . Factoring Card Logic 141 may be configured to provide users with virtual "Factoring Cards," which they can use to sell their accounts receivables.

In some embodiments, Factoring Card Logic 141 is configured to distribute multiple accounts receivable selling Factoring Cards associated with a master financial account to a number of agents, each Factoring Card representing the limits on accounts receivable that can be made by each of the agents.

In some embodiments, the Factoring Card Logic 141 is associated with limits other than financial amounts. For example, a "Factoring Card" may be restricted to particular product types, specific vendors, specific smart contract terms, particular assessment scores, and/or the like. For example, in some embodiments, Factoring Card Logic 141 is configured to provide factoring cards to agents, the factoring cards have different financial limits (e.g., dollar amount limits) as a function of an assessment score representing a financial risk associated with a receivable. In another example, a factoring card may require different smart contract terms, (e.g., rates, prices, time periods) responsive to a transaction amount and/or assessment score. Factoring Card Logic 141 may be configured to provide different factoring cards to different users, the different Factoring Cards having different limitations.

In some embodiments, the Factoring Card logic 141 is configured to calculate a CaaS Assessment Score associated to the selling agent, the scores associated with a master financial account affects the Finance Logic 145. The CaaS Assessment Score can be based on, for example, experience/seniority of an associated user, characteristics of the company using the factoring card, types of receivables sold using the factoring card, and/or the location of the suppliers and shippers used for the receivables. The carbon footprint involved in the process may be used. A CaaS Assessment Score may be used as a term in a smart contract, which impacts execution and/or output of the smart contract.

In some embodiments, the Factoring Card logic 141 is configured for associate PINs to selling agents and to be associated with specific contract terms and limits. For example, Factoring Card Logic 141 may be required to perform various levels of authentication for transactions made using a factoring card, these levels are optionally responsive to the parties of the transaction, receivables type, and/or transaction amounts. It may also be used to delegate authority and to dispute transactions.

In some embodiments, Factoring card logic 141 is configured for branding by entities such as a bank for specific customers. These are deemed Branded Factoring Cards. Association of Factoring Cards with a brand (e.g., a financial company or manufacturing company), is optionally used to set default restrictions and/or terms on the Factoring Cards. Branded Factoring Cards can also be used in "white label" arrangements, where the entity whose branding is on the card contracts with another entity to issue, manage, and / or assist with the factoring card.

In some embodiments, Factoring Card Logic 141 is configured for geolocation features that are associated with specific contract terms and limits.

In some embodiments, Factoring Card Logic 141 is configured to allow messages to be broadcast to users associated with the Factoring cards.

In some embodiments, Factoring Card Logic 141 is configured to calculate Usage points, these points can be used to affect fees, terms and conditions and/or other parameters to be applied in the finance logic.

In some embodiments, Factoring Card Logic 141 is configured to calculate Rewards Points. Rewards Points can be used to incentivize or reward users of the factoring card in preference to alterative means of funding inventories.

In some embodiments, Factoring Card Logic 141 is configured to issue factoring cards in tiers, each tier being associated with specific contract terms and limits.

In some embodiments, Factoring Card Logic 141 includes fraud detection logic. The fraud detection logic may be configured to perform fraud detection on a per sale basis, on a per contract basis, on a per supplier basis, and/or the like.

In some embodiments, Factoring Card Logic 141 will capture financial considerations associated with the sale of the receivables, title, asset values and description, related obligations and liabilities associated with specific contract terms and/or limits and generate automated reports and statements thereof at set period of time indicating balances outstanding and settled.

In some embodiments, Factoring 141 card logic is configured to also generate a physical/digital label for the goods at the location of the requester. Wherein the physical label for the goods is configured for placement at the location accessible to the producer, the physical/label optionally including a printed label or an electronic label, the physical label optionally including any combination of the title holder of the goods, an identifier of the goods, a use-by date for the goods, a description of the goods, and an inventory entry for the goods.

In some embodiments, Factoring Card Logic 141 is configured to associate a physical or virtual card with the receivables, the Factoring Card optionally being associated with a specific receivables management contract and/or selling agent, the Factoring Card optionally being associated with specific contract terms and/or limits.

In some embodiments, Factoring Card Logic 141 is optionally configured to set the fee for holding the receivables based on a level of risk associated with the producer, and optionally configured to calculate a credit rating for a particular sale of goods.

In some embodiments, Factoring Card Logic 141 is configured to generate and/or distribute the Factoring cards responsive to a master contract between the producer and the title holder pursuant to Contract logic 125.

Reverse Factoring Card Logic 142

Reverse Factoring Card Logic 142 is configured to allow increased cashflow for customers of a requester, individually or in aggregate, based on an overall financial limit set by the Title Holder, in contrast to the standard process where the customer has to request an advance, find a lender and negotiate fees and limits, the requester can set terms and help their customers in predefined logic that are predefined in the Reverse Factoring Card logic 142 may be configured for leveraging proprietary intelligence to find the best combinations. Reverse Factoring Card Logic 142may be configured to provide users with virtual "Reverse Factoring Cards," with which they give to their customers to sell their accounts receivables.

In some embodiments, the Reverse Factoring Card Logic 142 is configured to distribute multiple accounts receivable Reverse Factoring Cards associated with a master financial account to a number of customers, each Reverse Factoring card representing the limits on the receivables sales that can be made by each of the customers. In some embodiments, the Reverse Factoring Card Logic 142 is associated with limits other than financial amounts. For example, a "Reverse Factoring Card" may be restricted to particular product types, specific vendors, specific smart contract terms, particular assessment scores, and/or the like. For example, in some embodiments, Reverse Factoring Card Logic 142 is configured to provide factoring cards to agents, the Reverse factoring cards have different financial limits (e.g., dollar amount limits) as a function of an assessment score representing a financial risk associated with a receivable. In another example, a Reverse Factoring Card may require different smart contract terms, (e.g., rates, prices, time lengths) responsive to a transaction amount and/or assessment score. Reverse Factoring Card Logic 142 may be configured to provide different reverse factoring cards to different users, the different reverse factoring cards having different limitations.

In some embodiments, Reverse Factoring Card Logic 142 is configured to calculate a CaaS Assessment Score associated to the selling agent, the scores associated with a master financial account affects the finance logic. The CaaS Assessment Score can be based on, for example, experience/seniority of an associated user, characteristics of the company using the factoring card, types of receivables sold using the factoring card, and/or the location of the suppliers and shippers used for the receivables. The carbon footprint involved in the process may be used. An CaaS Assessment Score may be used as a term in a smart contract, which impacts execution and/or output of the smart contract.

In some embodiments, Reverse Factoring Card Logic 142 is configured to associate PINs to selling agents and to be associated with specific contract terms and limits. For example, Reverse Factoring Card Logic 142 may be required to perform various levels of authentication for transactions made using a Reverse Factoring Card, these levels are optionally responsive to the parties of the transaction, receivables type, and/or transaction amounts. It may also be used to delegate authority and to dispute transactions.

In some embodiments, Reverse Factoring Card Logic 142 is configured for branding by entities such as a customer for specific suppliers. These are deemed Branded Factoring Cards. Association of Reverse Factoring Cards with a brand (e.g., a manufacturing company), is optionally used to set default restrictions and/or terms on the Reverse Factoring Cards. Branded Reverse Factoring Cards can also be used in "white label" arrangements, where the entity whose branding is on the card contracts with another entity to issue, manage, and / or assist with the reverse factoring card.

In some embodiments, Reverse Factoring Card Logic 142 is configured for geolocation features that is configured to associated with specific contract terms and limits.

In some embodiments, Reverse Factoring Card Logic 142 is configured to allow messages to be broadcast to users associated with the Reverse Factoring cards.

In some embodiments, Reverse Factoring Card Logic 142 is configured to calculate Usage points, these points can be used to affect finance logic.

In some embodiments, Reverse Factoring Card Logic 142 is configured to calculate Rewards Points. Rewards Points can be used to incentivize or reward users of the reverse factoring card in preference to alternative means of funding inventories.

In some embodiments, Reverse Factoring Card Logic 142 is configured to issue reverse factoring cards in tiers, each tier being associated with specific contract terms and limits.

In some embodiments, Reverse Factoring Card Logic 142 includes fraud detection logic. The fraud detection logic may be configured to perform fraud detection on a per sale basis, on a per contract basis, on a per supplier basis, and/or the like.

In some embodiments, Reverse Factoring Card Logic 142 is configured to capture financial considerations associated with the sale of the receivables, title, asset values and description, related obligations and liabilities associated with specific contract terms and/or limits and generate automated reports and statements thereof at set period of time indicating balances outstanding and settled.

In some embodiments, Reverse Factoring card logic 142 is configured to also generate a physical/digital label for the goods at the location of the requester. Wherein the physical label for the goods is configured for placement at the location accessible to the producer, the physical label optionally including a printed label or an electronic label, the physical label optionally including any combination of the title holder of the goods, an identifier of the goods, a use-by date for the goods, a description of the goods, and an inventory entry for the goods.

In some embodiments, Reverse Factoring Card Logic 142 is configured to associate a physical or virtual card with the receivables, the Reverse Factoring card optionally being associated with a specific receivables management contract and/or selling agent, the Reverse Factoring card optionally being associated with specific contract terms and/or limits.

In some embodiments, Reverse Factoring Card Logic 142 is optionally configured to set the fee for holding the receivables based on a level of risk associated with the producer, and optionally configured to calculate a credit rating for a particular sale of goods.

In some embodiments, Reverse Factoring Card Logic 142 is configured to generate and/or distribute the Reverse Factoring cards responsive to a master contract between the producer and the title holder pursuant to Contract logic 125.

Securitization Card Logic 143

Securitization Card Logic 143 is configured to allow reduced risk and increased access to Capital for the requester, individually or in aggregate, based on an overall financial limit set by the Title Holder in contrast to the standard process where the Title Holder has to set up complex arrangements and invoicing with capital providers and manage that relationship, the user can instantaneously (or in real-time) get accesses to capital for to fund assets. Securitization Card Logic may be configured to provide users with virtual "Securitization Cards," with which they can create derivatives on existing assets. In some embodiments, the Securitization Card Logic 143 is configured to distribute multiple accounts utilizing Securitization Card Logic associated with a master financial account to a number of agents, each Securitization Card Logic card representing the limits on the derivatives that can be made by each of the agents.

In some embodiments, the Securitization Card Logic 143 is associated with limits other than financial amounts. For example, a "Securitization Card Logicl43" may be responsive to particular product types, specific vendors, specific smart contract terms, particular assessment scores, and/or the like. For example, in some embodiments, Securitization Card Logic 143 is configured to provide securitization cards to agents, the securitization cards have different financial limits (e.g., dollar amount limits) as a function of an assessment score representing a financial risk associated with a receivable. In another example, a securitization card may require different smart contract terms, (e.g., rates, prices, time lengths) responsive to a transaction amount and/or assessment score. Securitization Card Logic 143 may be configured to provide different Securitization Cards to different users, the different Securitization Cards having different limitations.

In some embodiments, the Securitization Card Logic 143 is configured to calculate a CaaS Assessment Score associated to the selling agent, the scores associated with a master financial account affects the finance logic. The CaaS Assessment Score can be based on, for example, experience/seniority of an associated user, characteristics of the company using the securitization card, types of derivatives sold using the Securitization Card, and/or the location of the suppliers and shippers used for the assets. The carbon footprint involved in the process may be used. A CaaS Assessment Score may be used as a term in a smart contract, which impacts execution and/or output of the smart contract.

In some embodiments, Securitization Card logic 143 is configured for associate PINs to selling agents and to be associated with specific contract terms and limits. For example, Securitization Card 143 may be required to perform various levels of authentication for transactions made using a reverse factoring card, these levels are optionally responsive to the parties of the transaction, receivables type, and/or transaction amounts. It may also be used to delegate authority and to dispute transactions.

In some embodiments, Securitization Card Logic 143 is configured for branding by entities such as a customer for specific suppliers. These are deemed Branded Factoring Cards. Association of Securitization Card with a brand (e.g., a bank may issue it to some of their customers for certain assets), is optionally used to set default restrictions and/or terms on the Securitization Cards. Securitization Card scan also be used in "white label" arrangements, where the entity whose branding is on the card contracts with another entity to issue, manage, and / or assist with the Securitization Card.

In some embodiments, Securitization Card Logic 143 is configured for geolocation features that is configured to associated with specific contract terms and limits.

In some embodiments, Securitization Card logic 143 is configured to allow messages to be broadcast to users associated with the Reverse Factoring cards.

In some embodiments, Securitization Card logic 143 is configured to calculate Usage points, these points can be used to affect finance logic.

In some embodiments, Securitization Card Logic 143 is configured to calculate Rewards Points. Rewards Points can be used to incentivize or reward users of the reverse factoring card in preference to alternative means of funding inventories.

In some embodiments, Securitization Card Logic 143 is configured to issue reverse factoring cards in tiers, each tier being associated with specific contract terms and limits.

In some embodiments, Securitization Card Logic 143 includes fraud detection logic. The fraud detection logic may be configured to perform fraud detection on a per sale basis, on a per contract basis, on a per supplier basis, and/or the like.

In some embodiments, Securitization Card Logic 143 is configured to capture financial considerations associated with the sale of the receivables, title, asset values and description, related obligations and liabilities associated with specific contract terms and/or limits and generate automated reports and statements thereof at set period of time indicating balances outstanding and settled.

In some embodiments, Securitization Card Logic 143 is configured to also generates a physical/digital label for the goods at the location of the requester. Wherein the physical label for the goods is configured for placement at the location accessible to the producer, the physical label optionally including a printed label or an electronic label, the physical label optionally including any combination of the title holder of the goods, an identifier of the goods, a use-by date for the goods, a description of the goods, and an inventory entry for the goods.

In some embodiments, Securitization Card logic 143 is configured to associate a physical or virtual card with the receivables, the Reverse Factoring card optionally being associated with a specific receivables management contract and/or selling agent, the Reverse Factoring Card optionally being associated with specific contract terms and/or limits.

In some embodiments, Securitization Card Logic is 143 optionally configured to set the fee for holding the receivables based on a level of risk associated with the producer, and optionally configured to calculate a credit rating for a particular sale of goods.

In some embodiments, Securitization Card Logic 143 is configured to generate and/or distribute the Securitization Card cards responsive to a master contract between the producer and the title holder pursuant to Contract logic 125.

Finance Logic 145

Finance Logic 145 is configured to receive offers to fund purchase of the goods by the title holder and executed by Inventory Card Logic 140 pursuant to Contract Logic 125.

In some embodiments, finance logic 145 is configured to accept the offers to fund purchase of the goods, optionally from among multiple offers, and is optionally configured to bundle interests in fees charged for holding title to inventory for sale to investors.

In some embodiments, finance logic 145 is configured to accept all currencies including crypto to enable purchase of the goods, optionally from among multiple currencies and transfer interse from one to another and is optionally configured to bundle interest in fees charged based on variable interest rates such as LIBOR and Prime.

In some embodiments, finance logic 145 is configured to accept fixed fees and in lieu of variable rates and optionally providing for the reconciliation and balances due or recoverable based on such reconciliation and generate automated reports and statements thereof at set period of time indicating balances outstanding and settled as PPV.

In some embodiments, Finance logic 145 is further enhanced by the capabilities of intelligent process automation to learn and preconfigure repetitive tasks.

In some embodiments, finance logic 145 is configured to associate each inventory item held against its financier and cause a lien in favor of that financier to be recorded automatically pursuant to Title Logic 135.

Blockchain Logic 150

Blockchain logic configured to log each transaction associated with the origination of ownership of the goods and the title transfer from the title holder to the purchaser pursuant to logic 105, 110, 115, 120, 125, 130, 135, 140 and 145 stated herein.

In some embodiments, Blockchain Logic 150 is configured to store a record of any combination of: title to the goods, contract terms (e.g., fees, prices, maximum hold times, currencies, payment terms), location of the goods, and shipping data, tracking numbers, delivery events, pull requests, goods returns, liens, financier details and all associated terms in a smart contract to enforce compliance of contractual obligations. In some embodiments, Blockchain Logic 150 is further enhanced by the capabilities of Intelligent Process Automation to learn and preconfigure repetitive tasks.

In some embodiments, Blockchain Logic 150 is further enhanced by the capabilities of quantum computing for the purpose of handle operations at speeds substantially higher than conventional computers.

In some embodiments, Blockchain Logic 150 is optionally executed over cloud computing for the purpose of offering, amongst other benefits, back-up and restore data, improved collaboration, accessibility, lower maintenance cost, use of mobility devices, services in the payper-use model, substantial data storage capacity and data security.

API 155

Application programing interface (API) Logic 155 is configured to receive the request for goods from an ERP (enterprise resource planning) system 180 for the use by title holder to purchase goods pursuant to contract logic 125.

In some embodiments, API Logic 155 is configured and logged into blockchain logic 150 to associate each purchase request so as to get recorded in databases via data logic 105 for future reconciliation under inventory logic 130, contract logic 125 and finance logic 140.

Microprocessor 190

A microprocessor configured to execute at least the purchase order generation logic or the title logic and log all transaction details over block chain logic 150 and report onto Data logic 110. The microprocessor 190 including electronic or optical circuits.

FIG. 2 illustrates methods of managing title to inventory, according to various embodiments of the invention. In these methods, title holder purchases, pays for, and holds title to inventory based on purchase intents previously issued by a producer that detail specifications and terms and conditions for such purchase. Inventory may optionally be located close to a producer or contract manufacturer, and in some case collocated with them in a clearly marked and segregated location within the premises under control of the title holder. The producer or contract manufacturer has visibility to the inventory specifications and quantity available and can pull (i.e. purchase) via pull order any items from the inventory as needed to support producers manufacturing operations. Purchasers optionally issue a PO to the title holder and/or the title holder may issue a sales order to the producer for such items pulled.

All purchases of inventory items by title holder shall be pursuant to a master contract between title holder and the producer and optionally a supplier 185 from whom such items are to be purchased. Such contract shall specify the amount of inventory that may be purchased and held by title holder at any time, the list of authorized components, pricing terms and related authorized suppliers including supply locations if relevant.

A purchase order to a supplier may be done by the title holder placing a purchase order directly with the supplier stipulating that the Bill-To-Party (the party to be billed) shall be the title holder, and listing the item(s), quantity(s), price, ship-to-location, shipping incoterms, shipping date. Confirmation and change orders prior to order fulfillment and shipment shall be negotiated directly between the title holder with the Supplier based on terms agreed between the producer and the supplier. Title holder shall relay the received notifications to the producer and vice versa.

Advanced Ship Notices - ASNs - The Supplier ASN shall be relayed to and made visible to 3 parties, the title holder, producer, and the logistics provider. The mechanism to achieve this visibility is the supplier to send the ASN to the logistics provider who then forwards a copy to title holder and the OEM or the supplier to send the ASN to the title holder who then forwards a copy to logistics company and the producer.

Verification of receipt of items shall be conducted by the title holder or its agent who could be the logistics provider or the producer. Such agent will certify that goods are received in good condition and that the ASN details are accurate. Release of payment to supplier by the title holder shall be conducted thereafter upon agreed terms and conditions. Producer or CM Pull of Inventory shall trigger an invoice from the title holder to the producer or CM and inventory shall be depleted in the title holders accounting records and an appropriate amount receivable from the producer shall be recorded. Producer or CM shall thereafter make payment to title holder on agreed terms.

In a Receive Request Step 210,

A Request is configured in Producers IT systems to issue automated procurement instructions i.e. requests, for certain goods or materials from the title holder at a prescribed date and simultaneously log all transaction details over block chain logic 150 and report onto Data logic 110. Such requests may be altered by the producer on pre-agreed terms and optionally issue a fresh set of instructions.

Generate Contract Step 215

Optionally generating a contract between the producer and a title holder, the contract specifying any combination of the following: that the title holder will hold title to the goods until a request or notice for the goods is received by the title holder from the producer, a maximum hold time is reached, the producer accesses the goods and optionally will purchase the goods from the title holder in the future, terms, conditions, purchase obligations associated with the future purchase obligation of the producer, automated sales, transfers, scrapping and return rights; such contract details shall be simultaneously logged over block chain logic 150 and report onto Data logic 110. Pursuant to such contract, the title holder may optionally issue the producer and/or its agents an inventory card setting privileges to the producer and/or its agents the ability to issue to a title holder procurement intents for goods.

Generate PO Step 220 (convey to supplier)

Optionally generating a purchase order for the goods; transmitting or supplying the purchase order to a supplier of the goods together with goods specifications based on Request Step 210.

The purchase order is optionally generated by the title holder and delivered to the supplier. The PO is optionally automatically generated and configured in title holders IT systems to replicate procurement instructions from producer for certain goods or materials and simultaneously logged over block chain logic 150 and report onto Data logic 110. The purchase order is typically subject to the terms of the contract generated in Generate Contract Step 215.

Generate Goods acceptance or rejection Step 222 (convey to supplier)

Optionally generating a goods acceptance or rejection step for the goods to be accepted upon meeting specifications set in the PO Step 220; transmitting acceptance or rejection order to a supplier of the goods and simultaneously logged over block chain logic 150 and report onto Data logic 110. Verification of goods shall be conducted by the title holder or its agent who could be the logistics provider or the producer.

Pay Supplier Step 225

Title holder or its agent will certify that goods are received in good condition and that the ASN details are accurate. Release of payment to supplier by the title holder shall be conducted thereafter upon agreed terms and conditions ..Optionally this may be effected by generating a wire instruction or any other form of payment instructions to the title-holders bank for the payment of goods ordered by title-holder pursuant to PO step 225; transmitting or supplying the payment instruction based on goods accepted logic 222 and simultaneously logged over block chain logic 150 and report onto Data logic 110.

In a Deliver Step 230

The title holder may receive title to the goods upon shipment by the supplier or on acceptance of delivery at sea, on land, in space, virtually or any other jurisdiction, according to the terms and conditions prescribed in the purchase order or as set in a purchase contract. Having the goods delivered by title holder to a location accessible to the producer upon completion of step 222; Optionally generating a goods warehouse with title holders details labeled appropriately for distinguishing between producer-owned and title holder owned goods or materials and simultaneously logged over block chain logic 150 and report onto Data logic

110. In a Receive Title Transfer Request Step 235

The title holder receives a request to transfer title to the inventory from the producer, optionally while the goods are located in the location accessible to the producer or the producer is in physical possession of the goods. For example, the producer may request title to the (on-hand) inventory that they intend to use on a particular day or a particular production run. In some embodiments, a title transfer request is automatically generated by detection of removal of the inventory from the secure location accessible to the producer. For example, goods may be detected as having been removed visually or using a tracking technology such as RFID or barcodes.

The producer or contract manufacturer has visibility to the inventory specifications and quantity available and can pull (i.e., purchase) via pull order any items from the inventory as needed to support producers manufacturing operations. Optionally this may be effected by configuring a Pull Ordering System in producers ERP or IT system for ordering of goods or materials from title holder over an inventory replacement system that is used by to replenish their inventory levels and simultaneously logged over block chain logic 150 and report onto Data logic 110.

In a Receive Payment Step 240 (may include fee or profit)

Receiving payment from the producer for purchase of the goods from the title holder on terms set in producers purchase order; optionally receiving a fee for holding title to the goods (or making a profit on the payments) and simultaneously logged over block chain logic 150 and report onto Data logic 110.

In a Transfer Title Step 250

Producer or CM pull of inventory shall trigger an invoice from the title holder to the producer or CM and inventory shall be depleted in the title holders accounting records transferring title of the goods to the producer. Simultaneously, based on the pre-agreed terms of sale, an amount receivable from the producer shall be recorded. Thus, transferring title to the goods from the title holder to the producer shall be concluded.

Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations are covered by the above teachings and within the scope of the appended claims without departing from the spirit and intended scope thereof. For example, while the term "producer" is used herein as a way of example, this term is meant to include any holder of inventory/materials used to manufacture goods. It is further intended to include a user, assembler, producer, packager, and/or modifier of goods. For example, the term producer may apply to a party that assembles or modifies parts produced by others, or that consumes good for the provision of a service. The term "producer" may apply to an airline that uses inventory assets (e.g., aircraft and crew and aviation fuel) to provide a transport service. Further, the systems and methods described herein may be applied to any holder of goods and/or resources for the purposes of manufacture, sale and/or distribution of goods to other parties; or providers of services requiring goods or assets. The systems and methods discussed herein may further be applied to sub-assemblies of parts. For example, a producer may produce a sub-assembly and transfer title of the sub-assembly until the subassembly is need for further assembly or use, at which time title is transferred back. In this case the producer may also take the role of a supplier. In some embodiments, the systems and methods described herein are used by more than three parties in a supply chain. For example, a first supplier may provide inventory to a first producer who is a second supplier to a second producer. The first producer/second supplier uses inventory received from the first supplier to produce goods that are then passed on to the second producer for use. In such situations, title may be held by a title holder though more than one step in the supply chain, e.g., the first producer may not ever take title in the inventory provided by the first supplier and title only transferred from the title holder upon use of the (possibly improved inventory) by the second producer.

The embodiments discussed herein are illustrative of the present invention. As these embodiments of the present invention are described with reference to illustrations, various modifications or adaptations of the methods and or specific structures described may become apparent to those skilled in the art. All such modifications, adaptations, or variations that rely upon the teachings of the present invention, and through which these teachings have advanced the art, are considered to be within the spirit and scope of the present invention. Hence, these descriptions and drawings should not be considered in a limiting sense, as it is understood that the present invention is in no way limited to only the embodiments illustrated.

Computing systems and/or logic referred to herein can comprise an integrated circuit, a microprocessor, a personal computer, a server, a distributed computing system, a communication device, a network device, or the like, and various combinations of the same. A computing system or logic may also comprise volatile and/or non-volatile memory such as random-access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), magnetic media, optical media, nano-media, a hard drive, a compact disk, a digital versatile disc (DVD), optical circuits, and/or other devices configured for storing analog or digital information, such as in a database. A computer-readable medium, as used herein, expressly excludes paper. Computer-implemented steps of the methods noted herein can comprise a set of instructions stored on a computer-readable medium that when executed cause the computing system to perform the steps. A computing system programmed to perform particular functions pursuant to instructions from program software is a special purpose computing system for performing those particular functions. Data that is manipulated by a special purpose computing system while performing those particular functions is at least electronically saved in buffers of the computing system, physically changing the special purpose computing system from one state to the next with each change to the stored data. The "logic" discussed herein is explicitly defined to include hardware, firmware or software stored on a non-transient computer readable medium, or any combinations thereof. This logic may be implemented in an electronic and/or digital device (e.g., a circuit) to produce a special purpose computing system. Any of the systems discussed herein optionally include a microprocessor, including electronic and/or optical circuits, configured to execute any combination of the logic discussed herein. The methods discussed herein optionally include execution of the logic by said microprocessor.