WO2023082008A1 - Systems and methods for providing a digital media rental platform - Google Patents

Systems and methods for providing a digital media rental platform Download PDF

Info

Publication number
WO2023082008A1
WO2023082008A1 PCT/CA2022/051665 CA2022051665W WO2023082008A1 WO 2023082008 A1 WO2023082008 A1 WO 2023082008A1 CA 2022051665 W CA2022051665 W CA 2022051665W WO 2023082008 A1 WO2023082008 A1 WO 2023082008A1
Authority
WO
WIPO (PCT)
Prior art keywords
nft
rental
terms
renter
user
Prior art date
Application number
PCT/CA2022/051665
Other languages
French (fr)
Inventor
Kevin Nguyen
Evgenii PECHERKIN
Oleksandr DYMOV
Joseph Nguyen
Dmitry GLUBOCHANSKY
Cristian Gonzalez
Original Assignee
Technologies Facerent Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Technologies Facerent Inc. filed Critical Technologies Facerent Inc.
Publication of WO2023082008A1 publication Critical patent/WO2023082008A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the method comprises: transferring the rental NFT to a renter account with restrictions preventing export of the rental NFT to other digital wallets; and returning the rental NFT after the determined period of time to the owner account.
  • NFT non-fungible token
  • the user device 110 may be a computing device that is operated by a user.
  • the user device 110 may be, for example, a smartphone, a smartwatch, a tablet computer, a laptop, a virtual reality (VR) device, or an augmented reality (AR) device.
  • the user device 110 may also be, for example, a combination of computing devices that operate together, such as a smartphone and a sensor.
  • the user device 110 may also be, for example, a device that is otherwise operated by a user, such as a drone, a robot, or remote-controlled device; in such a case, the user device 110 may be operated, for example, by a user through a personal computing device (such as a smartphone).
  • the user device 110 may be configured to run an application (e.g., a mobile app) that communicates with other parts of the system 100, such as the server 120.
  • an application e.g., a mobile app
  • an owner initiates the method 200.
  • the system 100 may populate a media NFT data record 250 with a user ID, an owner address, and/or a metadata secure hash (e.g., SHA).
  • a metadata secure hash e.g., SHA
  • the front end determines whether an NFT has already been created. If an NFT has not been created, the method 400 proceeds to 424. If the NFT has been created, the method 400 proceeds to 470, with the front end sending to the back end an API request to create the NFT.
  • the back end deducts an online currency (e.g., Cointiks) as fees from the seller or the buyer as agreed to create the NFT.
  • an online currency e.g., Cointiks
  • a buyer sends a message to a front end to buy an NFT (from 512 to 522).
  • the front end may validate the buyer and the NFT (from 522 back to 522).
  • the front end may send a message to the buyer to wait (from 522 to 512).
  • the back end meta storage creates metadata for the NFT, for example, using a secure hash (e.g., SHA) of the terms as one of its fields.
  • the back end may also calculate the secure hash (e.g., SHA) of that metadata.
  • the system 100 may produce a secure hash by, for example, producing checksums such as MD5, NTLM, LANMAN, RIPEMD, AES, BLAKE, or SHA.
  • checksums such as MD5, NTLM, LANMAN, RIPEMD, AES, BLAKE, or SHA.
  • the blockchain may be configured to: (a) receive the rental NFT ID from the application; (b) read the rental NFT based on the rental NFT ID; (c) send the metadata URL obtained from the rental NFT to the application; and (d) send the rental NFT fields associated with the rental NFT ID to the rental meta provider.
  • the rental meta provider may be configured to: (a) receive the metadata URL from the application; (b) send a read rental NFT request to the blockchain; and (c) send the rental NFT fields to the application.
  • the front-end III 915 may be run on one or more platforms, including, for example, the web, a PWA, Android, or iOS.
  • the front-end III 915 may have a development stack, using a language such as TypeScript.
  • the front-end III 915 may employ one or more technologies, including, for example, ReactJS, React Native, NodeJS, GraphQL, or Redux.
  • the front-end III 915 may be a user interface that is present as a single-page application (e.g., PWA for mobile, desktop website) and native applications for mobile (e.g., iOS, Android).
  • the front-end III 915 may use a Redux approach to process a user’s interactions and manage views.
  • the rental meta provider 950 receives data from the third-party applications 945 and stores data on the blockchain 970.
  • the rental meta provider 950 may make rental NFTs compatible with applications that work with ERC-1155 tokens.
  • the rental meta provider 950 may return the information stored on a rental contract, such as an ID of the rented NFT, a renter wallet address, an expiration date, a secure hash (e.g., SHA) of the terms, and an address of the NFT contract.
  • the rental meta provider 950 may return a name and description by ID of the rental NFT formatted as metadata.
  • the state 1040 may be a post state.
  • the front-end loads posts, including the list of posts with its data, and the page of the list loaded.
  • the following shows an example script of a post state:
  • III components 1050 process changes of the states 1040 and show the results on the display.
  • FIG. 11 showing a block diagram of an example embodiment of back-end module interaction 1100 in a rental NFT system (or “app”).
  • the back-end module interaction 1100 may be that of the back end 935 of the system architecture 900.
  • the NFT module 1150 is configured to create NFTs from files.
  • the post likes 1235 may have one or more components, including: a post, a user, and/or a creation date.
  • the post may be of type bigint and category PK and/or FK1 .
  • the user may be of type bigint and category PK and/or FK2.
  • the creation date may be of type datetime.
  • One or more of the components of the post likes 1235 may have the value of (or be initialized as) not null.
  • the NFT metadata 1255 may have one or more components, including: secure hash (e.g., SHA), social data, file metadata, media link, author address, and/or NFT terms.
  • secure hash e.g., SHA
  • the secure hash may be of type varchar(num), where num is an integer such as 64, and type PK.
  • the social data may be of type bigint.
  • the file metadata may be of type JSONB.
  • the media link may be of type text.
  • the author address may be of type text.
  • the NFT terms may be of type varchar(num), where num is an integer such as 64, and category FK1 .
  • One or more of the components of the NFT metadata 1255 may have the value of (or be initialized as) not null.
  • the users 1220 may be connected to the wallets 1215, the user followers 1225, the rental NFTs 1230, the post likes 1235, and/or the NFT sells 1240.
  • the wallet of a user 1220 may be stored in a wallet 1215.
  • the users 1310 may have an N:M buy 1314 relationship with the NFTs 1330. For example, one or more of the users 1310 buy 1314 one or more of the NFTs 1330.
  • FIG. 15 showing a block diagram of an example embodiment of a metadata storage architecture 1500 in a rental NFT system (or “app”).
  • the metadata storage architecture 1500 may be that of the metadata storage 940 of the system architecture 900.
  • the metadata database design 1600 provides an example of the database structure for use with meta storage.
  • the database structure may have one or more of four tables: authorized apps 1610, users 1620, metadata 1630, and/or terms 1640.
  • the standalone rental NFT smart contract 1800 may have one or more minter- only functions, including: mint rent (to asset ID, to address, expiration, terms hash).
  • the standalone rental NFT smart contract 1800 may be operable with the use of a microservice which presents custom fields of the rental NFT (e.g., ID of rented NFT, renter wallet address, expiration date, terms secure hash (e.g., SHA)) as metadata.
  • the standalone rental NFT smart contract 1800 may also be formatted to provide the same “look and feel” of the ERC-721.
  • FIGS. 25 to 31 shown therein are screen captures of examples of sign-up steps for a rental NFT system (or “app”).
  • FIG. 26 shows a screen capture of an example of a Step 2 page 2600 of the sign-up (which may be the step of verifying the user) for a rental NFT system (or “app”).
  • the Step 2 page 2600 may be used by the front end of the system architecture 900.
  • the Step 2 page 2600 may include GUI elements from the Step 1 page 2500 and an option to accept a verification code.
  • the Step 2 page 2600 may also include a button to re-send a verification code to the user-selected option (e.g., SMS or email), and may also include a countdown timer to provide a time frame within which the user must provide a correct verification code.
  • the Step 2 page 2600 may also include a next button to confirm successful user verification.
  • the Step 2 page 2600 may also include legal statements including links to the terms of service and privacy policy.
  • FIG. 29 shows a screen capture of an example of an upload profile picture page 2900 for a rental NFT system (or “app”).
  • the edit profile page 2900 may be used by the front end of the system architecture 900.
  • the GUI elements may provide options to access a camera, photo library on the user’s device, or user’s cloud storage (e.g., Google Drive etc.) to enable the user to click or upload the profile picture.
  • the upload profile picture page 2900 may also provide a menu bar having options to add additional information, buy Cointiks, access main menu/feed, access user profile, and access settings.
  • the easy done page 3100 may also include legal statements including links to the terms of service and privacy policy.
  • FIG. 32 shown therein is a screen capture of an example of a main feed page 3200 for a rental NFT system (or “app”).
  • the main feed page 3200 may be used by the front end of the system architecture 900.
  • the main feed page 3200 may include elements like information related to Cointiks owned by the user (for example, R 500 ($122USD)), notifications (e.g., a bell icon), a search bar, number of items for sale (e.g., 756 items for sale), brief information regarding NFT item(s), and the menu bar.
  • the settings page 3300 may be used by the front end of the system architecture 900.
  • the settings page 3300 may be accessed using a menu bar.
  • the settings page 3300 may include GUI elements providing options to the user to access profile and edit profile, access notifications, access/change privacy settings, reset PIN, access terms and conditions, and log out.
  • the settings may also include an option to learn more about the features of the application, a link to provide user feedback, and a menu bar.
  • the menu bar may include options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
  • the stats may include statistics related to the NFT item like number of users that have liked the item (for example, 112), number of users that have viewed the item (for example, 756), number of times the item has been purchased (for example, 3 Times), duration since the item is trending (for example, last 30 days), days since the item was last purchased (for example, 180), date the item was last purchased (for example, Jan 12, 2021 ).
  • the stats may also include a link to view detailed history related to the NFT item.
  • FIGS. 38 to 40 shown therein are screen captures of examples of add content pages for a rental NFT system (or “app”).
  • the user view of the user profile page 4200 may also provide a scale option to adjust view of number of available NFTs, and a filter option to view user’s NFTs (e.g., all NFTs, user’s original NFTs, NFTs that are pending sell, and purchased NFTs).
  • the NFTs maybe be image thumbnails that are displayed on the user view of the user profile.
  • the user view of the user profile page 4200 may also include NFT price on the NFT image thumbnails.
  • the user view of the user profile page 4200 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.

Abstract

A system and method for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time are provided. The system has a front-end computing device and a back-end computing device. The front end is configured to: receive a request to create a rental NFT; send an issue rental NFT request to a back end; and show a notification to the renter account of the completion of the rental NFT creation. The back end is configured to: receive the issue rental NFT request; create terms for the rental NFT; calculate a terms secure hash; send a mint rental NFT instruction to a blockchain; receive a rental NFT ID from the blockchain; store a rental NFT data record for the rental NFT; and send the notification to the front-end computing device of the completion of the rental NFT creation.

Description

SYSTEMS AND METHODS FOR PROVIDING A DIGITAL MEDIA RENTAL PLATFORM
CROSS-REFERENCE TO PREVIOUS APPLICATON
[0001 ] This application claims priority from United States provisional patent application no. 63/278,764 filed on November 12, 2021 , which is incorporated herein by reference in its entirety.
FIELD
[0002] Various embodiments are described herein that generally relate to a system for securely transferring a non-fungible token of a digital media file, as well as the methods.
BACKGROUND
[0003] The following paragraphs are provided by way of background to the present disclosure. They are not, however, an admission that anything discussed therein is prior art or part of the knowledge of persons skilled in the art.
[0004] Non-fungible tokens (NFTs) provide a unique and non-interchangeable unit of data for storage on a digital ledger. NFTs can be used to represent easily reproducible items such as photos, videos, audio, and other types of digital files. Blockchain technology can be used to establish a verified and public proof of ownership.
[0005] Smart contracts are computer programs that are intended to automatically execute, control, or document relevant events and actions according to the terms of a contract or an agreement. Smart contracts can reside on a blockchain.
[0006] Existing technology does not provide a means for combining smart contracts, blockchain technology, and the NFT format in such a manner that an NFT of a digital media file can be securely transferred with specific terms of use such as an expiry date.
[0007] There is a need for a system and method that addresses the challenges and/or shortcomings described above. SUMMARY OF VARIOUS EMBODIMENTS
[0008] Various embodiments of a system and method for securely transferring a non- fungible token of a digital media file, as well as the methods, and computer products for use therewith, are provided according to the teachings herein.
[0009] According to one aspect of the invention, there is disclosed a method of operating a system for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the method comprising: receiving a request to create a rental NFT from the NFT of the digital media file, the NFT linked to an owner account; creating a terms document for the rental NFT; hashing the terms document, thereby producing a terms secure hash; calling a smart contract to create the rental NFT, using the terms secure hash, the rental NFT being assigned a rental NFT ID upon creation.
[0010] In at least one embodiment, the hashing the terms document is produced by a secure hashing algorithm (SHA) and the terms secure hash is a SHA hash.
[0011 ] In at least one embodiment, the method further comprises: reserving an amount of online currency from a renter account, the renter account comprising a renter wallet address; and transferring the amount of online currency to the owner account.
[0012] In at least one embodiment, the method comprises: creating a rental NFT data record for the rental NFT, the rental NFT data record comprising at least one of: the rental NFT ID, a renter wallet address, an expiration date, or a checksum corresponding to the terms secure hash.
[0013] In at least one embodiment, the method comprises: issuing the rental NFT to a renter account.
[0014] In at least one embodiment, the method comprises: issuing the rental NFT to the owner account for transfer to a renter account.
[0015] In at least one embodiment, the method comprises: transferring the rental NFT to a renter account with restrictions preventing export of the rental NFT to other digital wallets; and returning the rental NFT after the determined period of time to the owner account. [0016] According to another aspect of the invention, there is disclosed a method of operating a system for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the method comprising: receiving a request to transfer the NFT of the digital media file, the NFT linked to an owner account; creating a terms document for a transfer of the NFT for the determined period of time; hashing the terms document, thereby producing a terms secure hash; and transferring the NFT for the determined period of time to a renter account.
[0017] In at least one embodiment, the method comprises: returning the NFT to the owner account after the determined period of time.
[0018] According to another aspect of the invention, there is disclosed a system for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the system comprising: a front-end computing device and at least one back-end computing device. The front-end computing device has a non-transitory computer-readable medium having stored thereon instructions to cause the front-end computing device to: receive a request to create a rental NFT from the NFT of the digital media file for a renter account, the NFT being linked to an owner account; send an issue rental NFT request to at least one back-end computing device; and upon receiving a notification from the at least one back end computing device of completion of creation of the rental NFT, show a notification to the renter account of said completion. The at least one back-end computing device has a non-transitory computer readable medium having stored thereon instructions to cause the at least one back-end computing device to: receive the issue rental NFT request; create terms for the rental NFT for the renter account; calculate a terms secure hash; create the rental NFT based at least in part on the terms secure hash; and send the notification to the frontend computing device of the completion of the creation of the rental NFT.
[0019] In at least one embodiment, the NFT comprises an NFT ID and the renter account comprises a renter address.
[0020] In at least one embodiment, the issue rental NFT request comprises the NFT ID and an expiration date for the rental NFT. [0021 ] In at least one embodiment, the at least one back-end computing device creates the rental NFT by: sending a mint rental NFT instruction to a blockchain using the NFT ID, the renter address, the expiration date, and the terms secure hash; receiving a rental NFT ID from the blockchain; and storing a rental NFT data record for the rental NFT.
[0022] According to another aspect of the invention, there is disclosed a back-end computing device for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time to a front-end computing device, the back-end computing device having a non-transitory computer readable medium having stored thereon instructions to cause the back-end computing device to: receive an issue rental NFT request for a rental NFT to be created from the NFT of the digital media file for a renter account; create terms for the rental NFT for the renter account; calculate a terms secure hash; create the rental NFT based at least in part on the terms secure hash; and send a notification to the front-end computing device of completion of creation of the rental NFT.
[0023] In at least one embodiment, the NFT comprises an NFT ID and the renter account comprises a renter address.
[0024] In at least one embodiment, the issue rental NFT request comprises the NFT ID and an expiration date for the rental NFT.
[0025] In at least one embodiment, the back-end computing device creates the rental NFT by: sending a mint rental NFT instruction to a blockchain using the NFT ID, the renter address, the expiration date, and the terms secure hash; receiving a rental NFT ID from the blockchain; and storing a rental NFT data record for the rental NFT.
[0026] According to another aspect of the invention, there is disclosed a non-transitory computer-readable medium having stored thereon a smart contract for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the smart contract comprising: smart contract properties; smart contract functions; and minter-only functions. The smart contract properties comprise: a rental NFT ID for rental of the NFT; a rental NFT data record comprising an owner address, an expiration date, and a rental terms hash; a rental NFT contract address; and a minter address. The smart contract functions comprise: rental of the NFT, which creates a rental NFT; rental NFT data creation by the rental NFT ID; and contract execution for the rental NFT. The m inter-only functions comprise: minting of the rental NFT to a renter address, the rental NFT comprising the expiration date and the rental terms hash.
[0027] In at least one embodiment, the smart contract properties further comprise: a mapping from an NFT ID for the NFT to the rental NFT ID; and a list of additional rental NFTs, each additional rental NFT comprising a corresponding rental NFT ID.
[0028] In at least one embodiment, the smart contract further comprises: ERC-1155 compatibility properties comprising a uniform resource identifier (URI) associated with the rental NFT ID; and ERC-1155 compatibility functions comprising retrieval of a balance associated with the rental NFT ID and retrieval of metadata pointed to by the URI.
[0029] According to another aspect of the invention, there is disclosed a system for processing data related to a transfer of a non-fungible token (NFT) of a digital media file for a determined period of time that creates a rental NFT, the system comprising: an application, a blockchain, and a rental meta provider. The application is configured to: receive, from a user device, a request for information on the rental NFT based on an associated rental NFT ID; send the rental NFT ID to the blockchain; receive a metadata URL from the blockchain; send the metadata URL to a rental meta provider; and generate a display of full NFT information to be presented to the user device based at least in part on receipt of rental NFT fields from the rental meta provider. The blockchain is configured to: receive the rental NFT ID from the application; read the rental NFT based on the rental NFT ID; send the metadata URL obtained from the rental NFT to the application; and send the rental NFT fields associated with the rental NFT ID to the rental meta provider. The rental meta provider is configured to: receive the metadata URL from the application; send a read rental NFT request to the blockchain; and send the rental NFT fields to the application.
[0030] Other features and advantages of the present application will become apparent from the following detailed description taken together with the accompanying drawings. It should be understood, however, that the detailed description and the specific examples, while indicating preferred embodiments of the application, are given by way of illustration only, since various changes and modifications within the spirit and scope of the application will become apparent to those skilled in the art from this detailed description. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] For a better understanding of the various embodiments described herein, and to show more clearly how these various embodiments may be carried into effect, reference will be made, by way of example, to the accompanying drawings which show at least one example embodiment, and which are now described. The drawings are not intended to limit the scope of the teachings described herein. In the drawings:
[0032] FIG. 1 shows a block diagram of an example embodiment of a system for securely transferring a non-fungible token of a digital media file;
[0033] FIG. 2 shows a block diagram of an example embodiment of a method of creating an NFT;
[0034] FIG. 3 shows a flow diagram of an example embodiment of data flow for creating an NFT;
[0035] FIG. 4 shows a block diagram of an example embodiment of a method of purchasing an NFT;
[0036] FIG. 5 shows a flow diagram of an example embodiment of data flow for purchasing an NFT;
[0037] FIG. 6 shows a flow diagram of an example embodiment of data flow for renting an NFT;
[0038] FIG. 7 shows a flow diagram of an example embodiment of data flow for reading a rental NFT;
[0039] FIG. 8 shows a block diagram of an example embodiment of a system architecture for a rental NFT system;
[0040] FIG. 9 shows a block diagram of an example embodiment of a system architecture for a rental NFT system;
[0041] FIG. 10 shows a block diagram of an example embodiment of data flow of a front end of a rental NFT system; [0042] FIG. 11 shows a block diagram of an example embodiment of back-end module interaction in a rental NFT system;
[0043] FIG. 12 shows a block diagram of an example embodiment of a data structure of a database in a rental NFT system;
[0044] FIG. 13 shows a block diagram of an example embodiment of an entityrelationship (ER) model for a rental NFT system;
[0045] FIG. 14 shows a block diagram of an example embodiment of background jobs management in a rental NFT system;
[0046] FIG. 15 shows a block diagram of an example embodiment of a metadata storage architecture in a rental NFT system;
[0047] FIG. 16 shows a block diagram of an example embodiment of a metadata database design in a rental NFT system;
[0048] FIG. 17 shows an example template of an NFT smart contract in a rental NFT system;
[0049] FIG. 18 shows an example template of a standalone rental NFT smart contract in a rental NFT system;
[0050] FIG. 19 shows an example template of a smart contract with embedded rental in a rental NFT system;
[0051] FIG. 20 shows a screen capture of an example of a new user landing page for a rental NFT system;
[0052] FIG. 21 shows a screen capture of an example of a log in - after log out page for a rental NFT system;
[0053] FIGS. 22 to 24 show screen captures of examples of various options in a tour menu for a rental NFT system;
[0054] FIGS. 25 to 31 show screen captures of examples of sign-up steps for a rental NFT system; [0055] FIG. 32 shows a screen capture of an example of a main feed page for a rental NFT system;
[0056] FIG. 33 shows a screen capture of an example of a settings page for a rental NFT system;
[0057] FIG. 34 shows a screen capture of an example of a main feed item details page for a rental NFT system;
[0058] FIGS. 35 and 36 show screen captures of example pages of buy item steps for a rental NFT system;
[0059] FIG. 37 shows a screen capture of an example of an item details - item zoomed page for a rental NFT system;
[0060] FIGS. 38 to 40 show screen captures of examples of add content pages for a rental NFT system;
[0061 ] FIGS. 41 and 42 show screen captures of examples of a user profile page for a rental NFT system;
[0062] FIG. 43 shows a screen capture of an example of a Cointiks - buy more overlay page for a rental NFT system; and
[0063] FIG. 44 shows a screen capture of an example of mobile screen interactions for a rental NFT system.
[0064] Further aspects and features of the example embodiments described herein will appear from the following description taken together with the accompanying drawings.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0065] Various embodiments in accordance with the teachings herein will be described below to provide an example of at least one embodiment of the claimed subject matter. No embodiment described herein limits any claimed subject matter. The claimed subject matter is not limited to devices, systems, or methods having all of the features of any one of the devices, systems, or methods described below or to features common to multiple or all of the devices, systems, or methods described herein. It is possible that there may be a device, system, or method described herein that is not an embodiment of any claimed subject matter. Any subject matter that is described herein that is not claimed in this document may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicants, inventors, or owners do not intend to abandon, disclaim, or dedicate to the public any such subject matter by its disclosure in this document.
[0066] It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Also, the description is not to be considered as limiting the scope of the embodiments described herein.
[0067] It should also be noted that the terms “coupled” or “coupling” as used herein can have several different meanings depending in the context in which these terms are used. For example, the terms coupled or coupling can have a mechanical or electrical connotation. For example, as used herein, the terms coupled or coupling can indicate that two elements or devices can be directly connected to one another or connected to one another through one or more intermediate elements or devices via an electrical signal, electrical connection, or a mechanical element depending on the particular context.
[0068] It should also be noted that, as used herein, the wording “and/or” is intended to represent an inclusive-or. That is, “X and/or Y” is intended to mean X or Y or both, for example. As a further example, “X, Y, and/or Z” is intended to mean X or Y or Z or any combination thereof.
[0069] It should be noted that terms of degree such as “substantially”, “about” and “approximately” as used herein mean a reasonable amount of deviation of the modified term such that the end result is not significantly changed. These terms of degree may also be construed as including a deviation of the modified term, such as by 1 %, 2%, 5%, or 10%, for example, if this deviation does not negate the meaning of the term it modifies. [0070] Furthermore, the recitation of numerical ranges by endpoints herein includes all numbers and fractions subsumed within that range (e.g., 1 to 5 includes 1 , 1.5, 2, 2.75, 3, 3.90, 4, and 5). It is also to be understood that all numbers and fractions thereof are presumed to be modified by the term “about” which means a variation of up to a certain amount of the number to which reference is being made if the end result is not significantly changed, such as 1 %, 2%, 5%, or 10%, for example.
[0071 ] It should also be noted that the use of the term “window” in conjunction with describing the operation of any system or method described herein is meant to be understood as describing a user interface for performing initialization, configuration, or other user operations.
[0072] The example embodiments of the devices, systems, or methods described in accordance with the teachings herein may be implemented as a combination of hardware and software. For example, the embodiments described herein may be implemented, at least in part, by using one or more computer programs, executing on one or more programmable devices comprising at least one processing element and at least one storage element (i.e., at least one volatile memory element and at least one non-volatile memory element). The hardware may comprise input devices including at least one of a touch screen, a keyboard, a mouse, buttons, keys, sliders, and the like, as well as one or more of a display, a printer, and the like depending on the implementation of the hardware.
[0073] It should also be noted that there may be some elements that are used to implement at least part of the embodiments described herein that may be implemented via software that is written in a high-level procedural language such as object-oriented programming. The program code may be written in C++, C#, JavaScript, Python, or any other suitable programming language and may comprise modules or classes, as is known to those skilled in object-oriented programming. Alternatively, or in addition thereto, some of these elements implemented via software may be written in assembly language, machine language, or firmware as needed. In either case, the language may be a compiled or interpreted language.
[0074] At least some of these software programs may be stored on a computer readable medium such as, but not limited to, a ROM, a magnetic disk, an optical disc, a USB key, and the like that is readable by a device having a processor, an operating system, and the associated hardware and software that is necessary to implement the functionality of at least one of the embodiments described herein. The software program code, when read by the device, configures the device to operate in a new, specific, and predefined manner (e.g., as a specific-purpose computer) in order to perform at least one of the methods described herein.
[0075] At least some of the programs associated with the devices, systems, and methods of the embodiments described herein may be capable of being distributed in a computer program product comprising a computer readable medium that bears computer usable instructions, such as program code, for one or more processing units. The medium may be provided in various forms, including non-transitory forms such as, but not limited to, one or more diskettes, compact disks, tapes, chips, and magnetic and electronic storage. In alternative embodiments, the medium may be transitory in nature such as, but not limited to, wire-line transmissions, satellite transmissions, internet transmissions (e.g., downloads), media, digital and analog signals, and the like. The computer useable instructions may also be in various formats, including compiled and non-compiled code.
[0076] In accordance with the teachings herein, there are provided various embodiments for a system for securely transferring a non-fungible token of a digital media file, and computer products for use therewith.
[0077] The system provides a platform offering secure and sophisticated face rental functionalities allowing users to rent their face for commercial and/or private use during a determined period of time. At the same time, these rentals are secured and deemed to be respected according to the underlying smart contract which encompasses the necessary information with regards to the rental service. As part of the specifics of the face rental process, the techniques rely on the transfer of a rental NFT token associated with the original NFT token containing the facial features of a user. These facial features are present in the form of an embedding suitable for replacement in digital media.
[0078] There is provided a system, method, and computer program for securely renting a digital media file for a determined period of time. This can include generation of facial machine learning (ML) embeddings to a smart contract based blockchain network. One example use is where a user would like to rent their face to a marketing company for usage in their promotional contents for a determined period of time. In one aspect, the method can further allow ML processing of the user’s face to ensure its authenticity across the system’s database.
[0079] The system allows users to create/purchase/rent/loan assets of other users. Each asset represents the personality-related aspects of the creator. An easy example: a photo of a person, video of a moment, voice recording.
[0080] The system provides certain advantages to online users of NFTs, such as: (a) passive income for regular users; (b) access for enterprise users to a wide variety of faces/moments/voices to use in online advertisements; (c) means for online collectors to purchase and exchange personal and unique digital content (e.g., of celebrities); (d) means for game/movie makers to acquire digital content for their video games or cinematic (e.g., CGI) production.
[0081 ] The system combines technologies to achieve these advantages, among others. The system uses blockchain technologies to represent each media asset as an NFT, which holds information strictly linked to the media asset. It stores the ID of the NFT and the secure hash (e.g., SHA) of its metadata.
[0082] The metadata of the asset is stored in a content-addressable storage (meta storage). A key to access the content may be provided, such as a checksum of the content. In that case, the metadata of those NFTs cannot be altered with altering the stored checksum. The metadata is public information available on the blockchain.
[0083] The system stores the terms of each interaction with an NFT (create, buy, rent) within a private document that stores additional data for these interactions. Only a direct participant of an operation (creator, owner, renter) can read it via the front end. As for the metadata, a key to access the content is the checksum of the content. That means the terms of the NFT cannot be changed.
[0084] The structure of the terms of the NFT may include: (a) terms of service and privacy policy active at the date of the operation; (b) a contract, which may be used to set additional agreements between seller/buyer, renter/owner, or user / system administrator; and/or (c) price, such as for renting and selling of the NFT. In the cases of renting or selling, the price may be set using a form of online currency or any other form of exchange value, such as other NFTs, tokens, physical checks, or cash. The online currency may include digital currency known to the system, such as Bitcoin or Ethereum, or created by the system, such as Cointiks or Rentiks. The names Cointiks and Rentiks may be used interchangeably to represent the same online currency used by the system described herein. In the cases of loaning of the NFT, the NFT may leave out the price or provide a substitute for the price, such as an exchange of points or virtual currency.
[0085] The owner of an NFT may be allowed to use the corresponding asset in a wide variety of cases (e.g., advertisement, movie making, etc.), including an ability to sell. The renter of an NFT may be allowed to do the same activities as the owner, except selling the NFT. Users may be able to define custom contracts for rent/sell operations.
[0086] The system may use machine learning solutions to provide a high level of security, such as: (a) verify a user by face at the purchase/rent moments; (b) verify assets of the user belonging to the user themself, and not to anyone else (e.g., by checking all faces on the picture, blurring those which are not of the user); and/or (c) verify validity of the content (e.g., uniqueness, decent quality, not relating to violence or pornography).
[0087] In various embodiments of the system described herein, the system may include various features to achieve the above advantages, among others.
[0088] One such feature is the use of ownership of NFTs to represent actual legal rights to use personal data (e.g., image, voice) of one user (e.g., creator) by another user or business (e.g., owner or renter).
[0089] Another feature is that on purchase of an NFT, the system may create the terms document, which is strictly linked to the transaction. The system may create a custom fully ERC-1155 compatible blockchain smart contract for that. Alternatively, or in addition, the system may create a blockchain smart contract that is compatible with another token standard (e.g., a successor of or alternative to ERC-1155).
[0090] Another feature is that instead of transferring the original NFT and holding collateral for safety, the system may issue rental NFTs to represent a rental contract of an NFT with personal data. The system may use a custom blockchain smart contract to issue rental NFTs. The smart contract may be semi-compatible with ERC-1155, where all the read functions are implemented, but the rental NFT generated cannot be transferred.
[0091 ] Another feature is that the system may store crucial rental NFT data on the blockchain, allowing it to be checked by other smart contracts. The system may have additional services to show that data as metadata for compatibility.
[0092] Another feature is that the system may allow issuing multiple rental NFTs for one NFT with the original personal data. This allows for multiple persons to own rights to the same content simultaneously.
[0093] Another feature is that on rental of an NFT, the system may create a terms document, which is strictly linked to the transaction, just like on purchase. The terms document for the rental NFT may include conditions of use and general contract information.
[0094] Another feature is that metadata and terms that the system creates may be referenced by hash, which is immutable and stored in the NFT contract (directly or in metadata). Consequently, their content cannot be changed once an NFT is created. This approach may provide additional trust to online users and other online entities (e.g., online privacy regulators).
[0095] Reference is first made to FIG. 1 , showing a block diagram of an example embodiment of a system 100 for securely transferring a non-fungible token (NFT) of a digital media file. The system 100 may provide the hardware and software for a rental NFT system (or “app”). The system 100 includes at least one user device 110 and at least one server 120. The user device 110 and the server 120 may communicate, for example, wirelessly or over the Internet.
[0096] The user device 110 may be a computing device that is operated by a user. The user device 110 may be, for example, a smartphone, a smartwatch, a tablet computer, a laptop, a virtual reality (VR) device, or an augmented reality (AR) device. The user device 110 may also be, for example, a combination of computing devices that operate together, such as a smartphone and a sensor. The user device 110 may also be, for example, a device that is otherwise operated by a user, such as a drone, a robot, or remote-controlled device; in such a case, the user device 110 may be operated, for example, by a user through a personal computing device (such as a smartphone). The user device 110 may be configured to run an application (e.g., a mobile app) that communicates with other parts of the system 100, such as the server 120.
[0097] The server 120 may run on a single computer, including a processor unit 124, a display 126, a user interface 128, an interface unit 130, input/output (I/O) hardware 132, a network unit 134, a power unit 136, and a memory unit (also referred to as “data store”) 138. In other embodiments, the server 120 may have more or less components but generally function in a similar manner. For example, the server 120 may be implemented using more than one computing device.
[0098] The processor unit 124 may include a standard processor, such as the Intel Xeon processor. Alternatively, there may be a plurality of processors that are used by the processor unit 124, and these processors may function in parallel and perform certain functions. The display 126 may be, but not limited to, a computer monitor or an LCD display such as that for a tablet device. The user interface 128 may be an Application Programming Interface (API) or a web-based application that is accessible via the network unit 134. The network unit 134 may be a standard network adapter such as an Ethernet or 802.11 x adapter.
[0099] The processor unit 124 may execute a predictive engine 152 that functions to provide predictions by using machine learning models 146 stored in the memory unit 138. The predictive engine 152 may build a predictive algorithm through machine learning. The training data may include, for example, image data, video data, audio data, and text.
[0100] The processor unit 124 can also execute a graphical user interface (GUI) engine 154 that is used to generate various GUIs. The GUI engine 154 provides data according to a certain layout for each user interface and also receives data input or control inputs from a user. The GUI then uses the inputs from the user to change the data that is shown on the current user interface or changes the operation of the server 120 which may include showing a different user interface.
[0101 ] The memory unit 138 may store the program instructions for an operating system 140, program code 142 for other applications, an input module 144, a plurality of machine learning models 146, an output module 148, and a database 150. The machine learning models 146 may include, but are not limited to, image recognition and categorization algorithms based on deep learning models and other approaches. The database 150 may be, for example, a local database, an external database, a database on the cloud, multiple databases, or a combination thereof.
[0102] In at least one embodiment, the machine learning models 146 include a combination of convolutional and recurrent neural networks. Convolutional neural networks (CNNs) are designed to recognize images, patterns. CNNs perform convolution operations, which, for example, can be used to classify regions of an image, and see the edges of an object recognized in the image regions. Recurrent neural networks (RNNs) can be used to recognize sequences, such as text, speech, and temporal evolution, and therefore RNNs can be applied to a sequence of data to predict what will occur next. Accordingly, a CNN may be used to read what is happening on a given image at a given time, while an RNN can be used to provide an informational message.
[0103] The programs 142 comprise program code that, when executed, configures the processor unit 124 to operate in a particular manner to implement various functions and tools for the system 100.
[0104] Reference is made to FIG. 2, showing a block diagram of an example embodiment of a method 200 of creating an NFT. The method 200 may be used by the system 100.
[0105] At 210, an owner initiates the method 200.
[0106] At 220, the front end sends to the back end an API request to create the NFT.
[0107] At 230, the back end receives the API request from the front end. The back end initiates the process to create the NFT.
[0108] At 240, the back end executes instructions to create the NFT.
[0109] At 242, the back end deducts an online currency (e.g., Cointiks) as fees from the seller or the buyer as agreed to create the NFT. [0110] At 244, the back end meta storage creates terms, which is an electronic document with, for example, terms of service, a privacy policy, and a contract. The back end may also calculate the secure hash (e.g., SHA) of that document for ensuring its authenticity, which may prevent later updates.
[0111 ] At 246, the back end meta storage creates metadata for the NFT, for example, using the secure hash (e.g., SHA) of the terms as one of its fields. The back end may also calculate the secure hash (e.g., SHA) of that metadata.
[0112] At 248, the back end calls a smart contract (e.g., on Polygon) to create the NFT, using the metadata secure hash (e.g., SHA), which is used as part of a uniform resource identifier (URI) to access that metadata.
[0113] In method 200, the system 100 may have a strict link from the NFT to its terms. In this case, the secure hash (e.g., SHA) of the metadata is written onto a blockchain (forever), the metadata can be validated with the associated secure hash (e.g., SHA), the metadata can contain the secure hash (e.g., SHA) of the terms, and the terms can be validated as well.
[0114] In method 200, the system 100 may populate a media NFT data record 250 with a user ID, an owner address, and/or a metadata secure hash (e.g., SHA).
[0115] In method 200, the system 100 may populate a metadata record 260 with file metadata, social data, a media link, an author address, and/or a terms secure hash (e.g., SHA). The metadata record 260 may have an associated secure hash (e.g., SHA) key.
[0116] In method 200, the system 100 may populate a creation terms record 270 with terms of service, a privacy policy, and/or a contract. The creation terms record 270 may have an associated secure hash (e.g., SHA) key.
[0117] In method 200, the system 100 (or any component thereof) may produce a secure hash by, for example, producing checksums such as MD5, NTLM, LANMAN, RIPEMD, AES, BLAKE, or SHA.
[0118] Reference is made to FIG. 3, showing a flow diagram of an example embodiment of data flow 300 for creating an NFT. The data flow 300 may represent the flow of data during execution of method 200. [0119] At 310, an author sends a message to a front end to create an NFT from a post (from 312 to 322). The front end may validate the post and the author (from 322 back to 322). The front end may send a message to the author to wait (from 322 to 312).
[0120] At 320, the front end sends an issue NFT (from the post) instruction to the back end (from 322 to 342). The back end may validate the post and the author (from 342 back to 342). The back end may set the NFT creation start data based on the post and may deduct fees from the author (from 342 back to 342). The back end may send a message to the front end as a response that the process has started (from 342 to 322).
[0121 ] At 330, a gateway may manage (e.g., route) communication between the front end and the back end (between 322 and 342). The gateway may also manage communication between background jobs and the front end (between 324 and 362).
[0122] At 340, the back end sends an issue NFT (from the post) instruction to the background jobs (from 342 to 362).
[0123] At 350, a remote dictionary server (Redis) may manage communication between the back end and the background jobs (between 342 and 362).
[0124] At 360, the background jobs send a create terms of creation (including, e.g., terms of service, privacy policy, contract) instruction to meta storage (from 362 to 372). The meta storage returns a terms secure hash (e.g., SHA) to the background jobs (from 372 to 362). The background jobs send a create NFT metadata (including, e.g., file link, file metadata, social data, author, address, terms secure hash (e.g., SHA)) instruction to the meta storage (from 362 to 374). The meta storage returns the metadata secure hash (e.g., SHA) to the background jobs (from 374 to 362). The background jobs send a mint NFT instruction (using, e.g., the author address, the metadata secure hash (e.g., SHA)) to a blockchain (from 362 to 382). The blockchain returns an NFT ID (from 382 to 362). The background jobs update the post and create the NFT based on, for example, the post, the NFT ID, and the metadata secure hash (e.g., SHA) (from 362 back to 362). The background jobs send a notification to the front end of the completion of the NFT creation (from 362 to 324). [0125] At 320, upon completion of the NFT creation, the front end shows a notification to the author of the completion of the NFT creation (from 324 to 314).
[0126] Reference is made to FIG. 4, showing a block diagram of an example embodiment of a method 400 of purchasing an NFT. The method 400 may be used by the system 100.
[0127] At 410, a buyer initiates the method 400.
[0128] At 420, a front end initiates a process for buying an NFT.
[0129] At 422, the front end determines whether an NFT has already been created. If an NFT has not been created, the method 400 proceeds to 424. If the NFT has been created, the method 400 proceeds to 470, with the front end sending to the back end an API request to create the NFT.
[0130] At 424, the front end determines whether an NFT is allowed to be automatically created. If an NFT has not been allowed to be automatically created, the method 400 proceeds 430. If an NFT has been allowed to be automatically created, the method 400 proceeds to 440, with the front end sending to the back end an API request to create an NFT.
[0131 ] At 430, the front end asks the owner if they want to convert digital property to an NFT to allow it to be sold.
[0132] At 440, the back end receives the API request to create the NFT from the front end. The back end initiates the process to create the NFT.
[0133] At 450, the back end executes instructions to create the NFT.
[0134] At 452, the back end deducts an online currency (e.g., Cointiks) as fees from the seller or the buyer as agreed to create the NFT.
[0135] At 454, the back end meta storage creates terms, which is an electronic document with, for example, terms of service, a privacy policy, and a contract. The back end may also calculate the secure hash (e.g., SHA) of that document for ensuring its authenticity, which may prevent later updates. [0136] At 456, the back end meta storage creates metadata for the NFT, for example, using a secure hash (e.g., SHA) of the terms as one of its fields. The back end may also calculate the secure hash (e.g., SHA) of that metadata.
[0137] At 458, the back end calls a smart contract (e.g., on Polygon) to create the NFT, using the metadata secure hash (e.g., SHA), which is used as part of a URI to access that metadata.
[0138] At 460, the back end initiates the process to transfer the NFT, following creation of the NFT.
[0139] At 470, the back end initiates the process to transfer the NFT, following receipt of the API request to transfer the NFT to the buyer.
[0140] At 480, the back end executes instructions to transfer the NFT.
[0141] At 482, the back end reserves an amount of online currency (e.g., Cointiks) from the buyer. Alternatively, or in addition, the back end may reserve any other form of exchange value, such as other NFTs, tokens, physical checks, or cash.
[0142] At 484, the back end calls meta storage to create terms and gets it hashed, thereby producing a secure hash (e.g., SHA) of the terms (or “terms secure hash”).
[0143] At 486, the back end calls a smart contract (e.g., on Polygon) to transfer NFT ownership from the seller to the buyer, using the secure hash (e.g., SHA) of the terms.
[0144] At 488, the back end adds the amount of online currency (e.g., Cointiks) to the seller. The system 100 may deduct a service fee at this point.
[0145] In method 400, the system 100 may populate a purchase terms data record 490 with terms of service, a privacy policy, a contract, and/or a price. The purchase terms data record 490 may have an associated secure hash (e.g., SHA) key.
[0146] In method 400, the system 100 may store a custom smart contract and store the secure hash (e.g., SHA) of the terms in Polygon. In this case, the terms are written there forever, and the terms can be validated for authenticity using the associated secure hash (e.g., SHA). [0147] In method 400, the purchasing price may be written within the terms, thereby being private by default. The secure hash (e.g., SHA) in this case represents the total hash of the terms details.
[0148] In method 400, the system 100 (or any component thereof) may produce a secure hash by, for example, producing checksums such as MD5, NTLM, LANMAN, RIPEMD, AES, BLAKE, or SHA.
[0149] Reference is made to FIG. 5, showing a flow diagram of an example embodiment of data flow 500 for purchasing an NFT. The data flow 500 may represent the flow of data during execution of method 400.
[0150] At 510, a buyer sends a message to a front end to buy an NFT (from 512 to 522). The front end may validate the buyer and the NFT (from 522 back to 522). The front end may send a message to the buyer to wait (from 522 to 512).
[0151 ] At 520, the front end sends a purchase NFT (identifying the buyer and the NFT) instruction to the back end (from 522 to 542). The back end may validate the buyer and the NFT (from 542 back to 542). The back end may set the NFT purchase as started and may deduct fees and the price from the author (from 542 back to 542). The back end may send a message to the front end as a response that the process has started (from 542 to 522).
[0152] At 530, a gateway may manage (e.g., route) communication between the front end and the back end (between 522 and 542). The gateway may also manage communication between background jobs and the front end (between 524 and 562).
[0153] At 540, the back end sends a purchase NFT (identifying the buyer and the NFT) instruction to the background jobs (from 542 to 562).
[0154] At 550, a remote dictionary server (Redis) may manage communication between the back end and the background jobs (between 542 and 562).
[0155] At 560, the background jobs send a create terms of purchase (including, e.g., terms of service, a privacy policy, a contract, a price) instruction to meta storage (from 562 to 572). The meta storage returns a terms secure hash (e.g., SHA) to the background jobs (from 572 to 562). The background jobs send a transfer NFT instruction (using, e.g., the NFT ID, the buyer address, and the metadata secure hash (e.g., SHA)) to a blockchain (from 562 to 582). The blockchain returns a response of success (from 582 to 562). The background jobs update the post based on, for example, the NFT and the buyer (from 562 back to 562). The background jobs send a notification to the front end of the completion of the NFT purchase (from 562 to 524).
[0156] At 520, upon completion of the NFT creation, the front end shows a notification to the buyer of the completion of the NFT purchase (from 524 to 514).
[0157] Reference is made to FIG. 6, showing a block diagram of an example embodiment of a method 600 of renting an NFT. The method 600 may be used by the system 100. The act of renting an NFT may be considered to be the act of transferring the NFT from one online digital account, or “owner” (or seller), to another online digital account, or “renter” (or buyer), for a determined period of time such that possession of the NFT reverts back to the owner at the end of that time period.
[0158] At 610, a renter initiates the method 600. Alternatively, an owner may initiate method 600. In the event that the owner initiates method 600, the owner may have previously designated a renter as the recipient of a rental NFT.
[0159] At 620, a front end initiates a process for renting an NFT. The process may be run on a progressive web application (PWA), for example.
[0160] At 622, the front end determines whether an NFT has already been created. If an NFT has not been created, the method 600 proceeds to 624. If the NFT has been created, the method 600 proceeds to 660, with the front end sending to the back end an API request to issue a rental NFT.
[0161 ] At 624, the front end determines whether an NFT is allowed to be automatically created. If an NFT has not been allowed to be automatically created, the method 600 proceeds 626. If an NFT has been allowed to be automatically created, the method 600 proceeds to 630, with the front end sending to the back end an API request to mint and rent an NFT.
[0162] At 626, the front end asks the owner if they want to convert digital property to an NFT to allow it to be rented. [0163] At 630, the back end receives the API request to create the NFT from the front end. The back end initiates the process to mint and rent the NFT.
[0164] At 640, the back end executes instructions to create the NFT.
[0165] At 642, the back end deducts an online currency (e.g., Cointiks) as fees from the seller or the buyer as agreed to create the NFT. In some implementations, the back end may forgo deducting an online currency or carry out a substitute act, such as transmitting loan terms. In some implementations, the back end may require collateral from the renter.
[0166] At 644, the back end meta storage creates terms, which is an electronic document with, for example, terms of service, a privacy policy, and a contract. The back end may also calculate the secure hash (e.g., SHA) of that document for ensuring its authenticity, which may prevent later updates.
[0167] At 646, the back end meta storage creates metadata for the NFT, for example, using a secure hash (e.g., SHA) of the terms as one of its fields. The back end may also calculate the secure hash (e.g., SHA) of that metadata.
[0168] At 648, the back end calls a smart contract (e.g., on Polygon) to create the NFT, using the metadata secure hash (e.g., SHA), which is used as part of a URI to access that metadata.
[0169] At 650, the back end initiates the process to issue the rental NFT, following creation of the NFT.
[0170] At 660, the back end initiates the process to issue the rental NFT, following receipt of the API request to issue the rental NFT.
[0171 ] At 670, the back end executes instructions to issue the rental NFT.
[0172] At 672, the back end reserves an amount of online currency (e.g., Cointiks) from the renter. Alternatively, or in addition, the back end may reserve any other form of exchange value, such as other NFTs, tokens, physical checks, or cash.
[0173] At 674, the back end calls meta storage to create terms and gets it hashed, thereby producing a secure hash (e.g., SHA) of the terms. [0174] At 676, the back end calls a smart contract (e.g., on Polygon) to create the rental NFT, using the secure hash (e.g., SHA) of the terms. The act of creating the rental NFT may also be referred to as “minting” or “generating” the rental NFT. The back end may then issue the rental NFT (which may be transferable or non-transferable) to the renter’s digital wallet. Alternatively, the back end may issue the rental NFT to the original owner’s digital wallet for them to transfer it to the renter.
[0175] At 678, the back end adds the amount of online currency (e.g., Cointiks) to the owner. The system 100 may deduct a service fee at this point. Alternatively, or in addition, the back end adds any other form of exchange value, such as other NFTs, tokens, physical checks, or cash, to the owner.
[0176] In method 600, the system 100 may populate a rental NFT data record 680 with an ID of the renter, an ID of the rented NFT, a renter wallet address, an expiration date, and/or a terms secure hash (e.g., SHA). The rental NFT data record 680 may be registered in the system 100 or a component thereof (such as a cache, database, memory, or other persistence system) for faster and/or cheaper access.
[0177] In method 600, the system 100 may populate a rental terms data record 690 with terms of service, a privacy policy, a contract, and/or a price. The rental terms data record 690 may have an associated secure hash (e.g., SHA) key.
[0178] In method 600, the system 100 may issue a rental NFT for each rental. The rental NFT may be an NFT with a custom format. The rental NFT may store: (a) the ID of the rental NFT; (b) the renter wallet address; and (c) the expiration date explicitly set in the NFT itself. In such a case, the rental NFT may be designated as non-transferrable.
[0179] In method 600, each rental NFT may have its own terms (validatable and unchangeable), which can store all the necessary legal documents for renting. In such a case, users are able to sign custom contracts if they want to, and such a contract is then stored in the rental contract field of the terms.
[0180] In method 600, the rental price may belong to the terms, thus being private by default. [0181 ] In method 600, the system 100 may transfer a rental NFT from the original creator to the renter with restrictions preventing its export to digital wallets other than the renter’s user wallet (e.g., controlled by the system 100). After the specified rental period (e.g., on the expiration date), the system 100 may return the rental NFT to the original creator and make it available for another rental.
[0182] In method 600, the system 100 (or any component thereof) may produce a secure hash by, for example, producing checksums such as MD5, NTLM, LANMAN, RIPEMD, AES, BLAKE, or SHA.
[0183] In at least one embodiment, the system 100 may carry out a modified version of method 600 in which the original NFT is transferred to a renter without creating a separate rental NFT. For example, the modified method comprises: (a) receiving a request to transfer the NFT, the NFT linked to the owner account; (b) creating a terms document for a transfer of the NFT for a determined period of time; (c) hashing the terms document, thereby producing a terms secure hash; and (d) transferring the NFT for the determined period of time to a renter account. The modified method may also comprise: (e) returning the NFT to the owner account after the determined period of time. The modified method may serve the purpose of transferring the NFT between wallets registered and controlled within the system 100. The modified method may be used, for example, by creators of NFTs to rent their NFTs to other accounts within the system 100 with the security of knowing that their NFTs will be returned to them after a specified rental period (e.g., on an expiration date).
[0184] Reference is made to FIG. 7, showing a flow diagram of an example embodiment of data flow 700 for renting an NFT. The data flow 700 may represent the flow of data during execution of method 600.
[0185] At 710, a renter sends a message (or “request”) to a front end to rent an NFT (from 712 to 722). The renter may send this message from their renter account, which may have a renter address. The NFT may have an NFT ID. The NFT may be linked to an owner account. The front end may validate the renter and the NFT (from 722 back to 722). The front end may send a message to the renter to wait (from 722 to 712). [0186] At 720, the front end sends an issue rental NFT (including, e.g., the renter, the NFT, and/or the expiration date) instruction to the back end (from 722 to 742). The issue rental NFT instruction (or “request”) may include the NFT ID. The issue rental NFT instruction may include an expiration date for the rental NFT. The back end may validate the renter and the NFT (from 742 back to 742). The back end may set the rental NFT creation as started (including, e.g., the renter and the NFT) and may deduct fees and the price from the renter (from 742 back to 742). In some implementations, the back end may require collateral from the renter. The back end may send a message to the front end as a response that the process has started (from 742 to 722).
[0187] At 730, a gateway may manage (e.g., route) communication between the front end and the back end (between 722 and 742). The gateway may also manage communication between background jobs and the front end (between 724 and 762).
[0188] At 740, the back end sends an issue rental NFT (including, e.g., the renter, the NFT, and/or the expiration date) instruction to the background jobs (from 742 to 762).
[0189] At 750, a remote dictionary server (Redis) may manage communication between the back end and the background jobs (between 742 and 762).
[0190] At 760, the background jobs send a create terms of rent (including, e.g., terms of service, a privacy policy, a contract, a price) instruction to meta storage (from 762 to 772). The meta storage returns a terms secure hash (e.g., SHA) to the background jobs (from 772 to 762). At a high level, the back end creates the rental NFT based on, for example, the terms secure hash (e.g., SHA). In particular, the background jobs send a mint rental NFT instruction (using, e.g., the NFT ID, the renter address, the expiration date, and/or the terms secure hash (e.g., SHA)) to a blockchain (from 762 to 782). The blockchain returns a rental NFT ID (from 782 to 762). The background jobs create the rental NFT based on, for example, the NFT, the renter, the rental NFT ID, the expiration date, and/or the terms secure hash (e.g., SHA) (from 762 back to 762). The background jobs send a notification to the front end of the completion of the rental NFT creation (from 762 to 724). The background jobs may store a rental NFT data record for the rental NFT in the system 100 or a component thereof (such as a cache, database, memory, or other persistence system) for faster and/or cheaper access. The rental NFT data record may be populated with an ID of the renter, an ID of the rented NFT, a renter wallet address, an expiration date, and/or a terms secure hash (e.g., SHA).
[0191 ] At 720, upon completion of the rental NFT creation, the front end shows a notification to the renter of the completion of the rental NFT creation (from 724 to 714).
[0192] In at least one embodiment, a back-end computing device controls some or all of the data flow 700 to securely transfer an NFT of a digital media file for a determined period of time to a front-end computing device. In such an embodiment, the back-end computing device: (a) receives an issue rental NFT request for a rental NFT to be created from the NFT of the digital media file for a renter account; (b) creates terms for the rental NFT for the renter account; (c) calculates a terms secure hash; create the rental NFT based at least in part on the terms secure hash; and (d) sends a notification to the front-end computing device of completion of creation of the rental NFT. The back-end computing device may create the rental NFT by: (i) sending a mint rental NFT instruction to a blockchain using the NFT ID, the renter address, the expiration date, and the terms secure hash; (ii) receiving a rental NFT ID from the blockchain; and (iii) storing a rental NFT data record for the rental NFT.
[0193] Reference is made to FIG. 8, showing a flow diagram of an example embodiment of data flow 800 for reading a rental NFT. The data flow 800 may be used by the system 100.
[0194] At 810, a user sends a message to a third-party application to get information about a rental NFT from its ID (from 812 to 822). The third-party application may be configured to read ERC-1155 tokens.
[0195] At 820, the third-party application sends the rental NFT ID to a blockchain (from 822 to 832). The blockchain may, for example, use the rental NFT ID to read the rental NFT as an ERC-1155 NFT. The blockchain returns a metadata URL to the third-party application (from 832 to 822). The third-party application sends the metadata URL to a rental meta provider (from 822 to 852). The rental meta provider returns the read rental NFT to the blockchain (from 852 to 834). [0196] At 830, the blockchain sends the rental NFT fields (including, e.g., an ID of the rented NFT, an expiration date, a renter wallet, an address, and a terms URL) to the rental meta provider (from 834 to 852).
[0197] At 840, a gateway may manage (e.g., route) communication between the third- party application and the rental meta provider (between 822 and 852).
[0198] At 850, the rental meta provider sends the rental NFT fields to the third-party application (from 852 to 822).
[0199] At 820, upon receipt of the rental NFT fields, the third-party application presents full NFT information to the user (from 822 to 812).
[0200] In data flow 800, the system 100 may store crucial rental NFT data on the blockchain, allowing it to be checked by other smart contracts. The system 100 may have additional services to show that data as metadata for compatibility.
[0201 ] In at least one embodiment, the third-party application (or “application”) controls some or all of the data flow 800. In such an embodiment, the application: (a) receives, from a user device, a request for information on the rental NFT based on an associated rental NFT ID; (b) sends the rental NFT ID to a blockchain; receives a metadata URL from the blockchain; (c) sends the metadata URL to a rental meta provider; and (d) generates a display of full NFT information to be presented to the user device based at least in part on receipt of rental NFT fields from the rental meta provider. In such an embodiment, the blockchain may be configured to: (a) receive the rental NFT ID from the application; (b) read the rental NFT based on the rental NFT ID; (c) send the metadata URL obtained from the rental NFT to the application; and (d) send the rental NFT fields associated with the rental NFT ID to the rental meta provider. In such an embodiment, the rental meta provider may be configured to: (a) receive the metadata URL from the application; (b) send a read rental NFT request to the blockchain; and (c) send the rental NFT fields to the application.
[0202] Reference is made to FIG. 9, showing a block diagram of an example embodiment of a system architecture 900 for a rental NFT system. The rental NFT system may represent a distributed architecture of system 100. [0203] The system architecture 900 comprises one or more of the following microservices: a front-end user interface (III) 915, a gateway 920, file storage 930, a back end 935, meta storage 940, a rental meta provider 950, background jobs 955, and a blockchain 970.
[0204] The system architecture 900 may also comprise one or more of the following components: a front-end service 925, third-party applications 945, a database 960, a Redis 965, and a metadata database 975.
[0205] The front end of the system architecture 900 may consist of one or two parts: the front-end III 915 and/or a front-end service 925.
[0206] The front-end III 915 may be run on one or more platforms, including, for example, the web, a PWA, Android, or iOS. The front-end III 915 may have a development stack, using a language such as TypeScript. The front-end III 915 may employ one or more technologies, including, for example, ReactJS, React Native, NodeJS, GraphQL, or Redux.
[0207] The front-end III 915 may be a user interface that is present as a single-page application (e.g., PWA for mobile, desktop website) and native applications for mobile (e.g., iOS, Android). The front-end III 915 may use a Redux approach to process a user’s interactions and manage views.
[0208] The front-end service 925 may be configured to run assets and server-side rendering (SSR). The front end may be configured such that none of its parts work with the blockchain 970 directly.
[0209] The front-end service 925 may be a simple NodeJS application that delivers Web/PWA applications to users. In addition, the front-end service 925 may be configured to render some pages on a server for SEO purposes.
[0210] The gateway 920 manages communication between one or more of the frontend III 915, the front-end service 925, the files storage 930, the back end 935, the meta storage 940, and the third-party applications 945.
[0211] The gateway 920 may be the main entrance to access the rental NFT system. The gateway 920 may provide a single endpoint to access several microservices. The gateway 920 may proxy requests to proper microservices, handle security (SSL connection), and cache content and files. The gateway 920 may be an Nginx gateway.
[0212] The files storage 930 provides files storage for the back end 935 and/or the background jobs 955.
[0213] The back end 935 provides a hub that communicates with one or more of the gateway 920, the files storage 930, the meta storage 940, the background jobs 955, the database 960, the Redis 965, and the blockchain 970.
[0214] The back end 935 may provide data for the front end 915, manage all the data and files, and integrate with the blockchain 970 and NFTs.
[0215] The back end 935 may be on a development stack using a language such as TypeScript and technologies such as NestJS, NodeJS, and/or PostgreSQL.
[0216] The meta storage 940 manages the storage of metadata, coming from one or more of the gateway 920, the back end 935, the background jobs 955, and the blockchain 970. The meta storage 940 may save data and documents on the metadata database 975.
[0217] The third-party applications 945 communicate with one or more of the gateway 920, the rental meta provider 950, and the blockchain 970.
[0218] The rental meta provider 950 receives data from the third-party applications 945 and stores data on the blockchain 970. The rental meta provider 950 may make rental NFTs compatible with applications that work with ERC-1155 tokens. The rental meta provider 950 may return the information stored on a rental contract, such as an ID of the rented NFT, a renter wallet address, an expiration date, a secure hash (e.g., SHA) of the terms, and an address of the NFT contract. The rental meta provider 950 may return a name and description by ID of the rental NFT formatted as metadata.
[0219] The rental meta provider 950 may be on a development stack using a language such as TypeScript and technologies such as NodeJS and/or ExpressJS. On each request, the rental meta provider 950 may call the blockchain 970 to get all information about a rental NFT and return it as a JSON response. [0220] The background jobs 955 run jobs that provide output to one or more of the files storage 930, the back end 935, the meta storage 940, the database 960, the Redis 965, and the blockchain 970.
[0221 ] The database 960 provides storage for the back end 935 and the background jobs 955.
[0222] The Redis 965 is a remote dictionary server used by the back end 935 and the background jobs 955.
[0223] The blockchain 970 receives data and/or input from one or more of the back end 935, the third-party applications 945, the rental meta provider 950, and the background jobs 955. The blockchain 970 may communicate with the meta storage 940.
[0224] The metadata database 975 provides a data repository for the meta storage 940.
[0225] The system architecture 900 may include one or more modules: an authentication module, a feed module, a user profile module, a social interaction module, a wallet module, a navigation module, a theme module, a localization module, a static content module, and an error handling module.
[0226] Authentication module. This module is configured to allow users to sign up and log into the rental NFT system (the “app”) while making sure that a user's sensitive data remains secure and unbreachable throughout the lifecycle of the app. It may integrate with third-party services such as Facebook login that is used for prefilling sign-up form fields as well as email providers for emailing verification codes to users required for successful signup. It may act as a guard for non-public pages and content that only authenticated users can access within the app.
[0227] Feed module. This module is configured to manage an often-used function of the app, a feed list of NFTs created by all of the users of the app. It may incorporate an infinite scroll mechanism that loads new feed items on-the-fly as the user is scrolling down the page and handles and preserves all the feed data in store. It may include a call to action for liking other users’ NFTs, following them, navigating to their profile, initiating NFT purchase flow, etc. [0228] User profile module. This module is configured to contain and manage all personalized user data, from general information such as name, email, profile picture, biography, followers count, etc. to listing a full history of the user’s created, bought, and sold NFTs. It may operate in two variations throughout the app: logged-in user’s profile and other app’s user profiles.
[0229] Social interaction modules. This module is configured to manage the follow, like, and other social interaction mechanisms (e.g., comment or share) throughout the app (feed, post, and profile pages) which users can use to gain popularity within the app, build a reputation, and increase visibility in other users’ searches and feeds.
[0230] Wallet module. This module is configured to manages one’s online currency (e.g., Cointiks) balance and allows one to exchange (e.g., convert from real money to Cointiks), which can then be used in-app for buying NFTs as well as getting paid when others buy one’s NFTs.
[0231 ] Navigation module. This module is configured to define and connect page routes and control navigation through the app. It can be used imperatively, by invoking navigation helper methods, or declaratively via link components in the app such as a navigation footer, a back button, or a standard link which can be internal or external.
[0232] Theme module. This module is configured to define and control overall theming of the app by, for example, defining app-wide color palette, typography, and spacing, as well as managing switching between dark and light themes.
[0233] Localization module. This module is configured to defines different language translation content and manages switching between languages in the app.
[0234] Static content module. This module is configured to provide static info pages such as terms of service, privacy policy, contact us, FAQ, and similar pages.
[0235] Error handling module. This module is configured to handle various errors across the app and makes sure that no error on any app level degrades the user’s trust in the app’s reliability that might break them from a smooth user experience. It may handle errors that happen during view rendering, API calls, network status changes, etc. [0236] The modules contribute to the app's design and technologies to bring mobile and web experiences closer together, and therefore mimic mobile native features on mobile web such as double-tap actions, navigation, and popup behavior and looks. The modules allow for reusability of code between web and mobile platforms, such as reaction-based app logic and views, css-in-js styles, etc.
[0237] Reference is made to FIG. 10, showing a block diagram of an example embodiment of data flow 1000 of a front end of a rental NFT system (or “app”). The data flow 1000 may be that of the front-end III 915 of the system architecture 900.
[0238] The front end is configured so that users interact with III components, triggering actions. Each component is a single, atomic III element present on the screen. One example is a single post with an image. Another example is a “Like” icon on the image. Another example is a text box to enter the user’s email. An action may take the form of a simple object in a specific format.
[0239] The following shows an example script of a component:
{ type : ' string_with_action_name ' , payload : { fan object with data, related to action' }
}
[0240] Actions 1010 are sent to all reducers 1020 that are present.
[0241 ] A reducer 1020 is a function, which is programmed to process specific actions 1010. The reducers 1020 are programmed to handle actions 1010 and update the store 1030.
[0242] The store 1030 contains states for all sub-modules of the application.
[0243] The state 1040 is an object that defines the current state for part of the application. The application may have multiple states. [0244] The state 1040 may be a user state. For example, when the user is logged in, the front end loads its data, and the user’s data itself. The following shows an example script of a user state:
{ is Loggedln : boolean; is Loading: boolean; islnitialized : boolean; user : { id : string; email : string; firstName : string; lastName : string; phoneNumber : string; role : string;
}
}
[0245] The state 1040 may be a post state. For example, the front-end loads posts, including the list of posts with its data, and the page of the list loaded. The following shows an example script of a post state:
{ is Loading? : boolean; posts : { id : string; url : string; title : string; author : string; price : number; likes : number;
}[ ] ; page : number;
}
[0246] The state 1040 may be a modal state. For example, the front end represents if and how any modal window is shown. The following shows an example script of a modal state:
{ isOpen : boolean; view: ModalViewType; data : any; actions : any; style : any, isImageViewerOpen : boolean; images : any[ ] ;
}
[0247] The state 1040 may be an error state. For example, the front end shows what are the errors and how to present them to the user. The following shows an example script of an error state:
{ modalErrorMessage : string; formErrors : Record<string, string>;
} [0248] The state 1040 may be the general state of the application. The following shows an example script of the general state:
{ routeParams : Recorc string, string>; mobile : Recorc string, any>; installEvent? : BeforelnstallPromptEvent;
}
[0249] The III components 1050 process changes of the states 1040 and show the results on the display.
[0250] Reference is made to FIG. 11 , showing a block diagram of an example embodiment of back-end module interaction 1100 in a rental NFT system (or “app”). The back-end module interaction 1100 may be that of the back end 935 of the system architecture 900.
[0251 ] The back end consists of one or more of six modules to manage the information that the rental NFT system needs. These six modules are: an authentication module 1110, a users module 1120, a posts module 1130, a wallet module 1140, an NFT module 1150, and a files module 1160.
[0252] The authentication module 1110 manages the user’s credentials. It may interact with the users module 1120 to verify user information. The authentication module may provide users with the ability to obtain authentication tokens that they will need to perform some actions in the app.
[0253] The users module 1120 manages information about users. It may provide methods to let the authentication module 1110 verify user information. The users module 1120 may interact with other modules. The users module 1120 may interact with the wallet module 1140 when a user is created. The users module 1120 may interact with the posts module 1130 when a user creates posts to verify user information. The users module 1120 may interact with the NFT module 1150 when users buy NFTs. [0254] The posts module 1130 manages posts created by users, which contain files. To be able to perform what was previously described, the posts module 1130 may interact with the users module 1120 and/or the files module 1 160.
[0255] The wallet module 1140 is configured to create a wallet when users are created.
[0256] The NFT module 1150 is configured to create NFTs from files.
[0257] The files module 1160 is configured to upload or create files when posts are created.
[0258] Reference is made to FIG. 12, showing a block diagram of an example embodiment of a data structure 1200 of a database in a rental NFT system (or “app”). The data structure 1200 may be that of the database 960 of the system architecture 900.
[0259] The data structure 1200 has one or more of the following data records: wallet transactions 1210, wallets 1215, users 1220, user followers 1225, rental NFTs 1230, post likes 1235, NFT sells 1240, original NFTs 1245, files 1250, NFT metadata 1255, and NFT terms 1260.
[0260] The wallet transactions 1210 may have one or more components, including: a customer ID, an origin, a destination, an amount, and/or a description. The customer ID may be of type integer and category PK. The origin may be of type big integer (or “bigint”) and category FK1 . The destination may be of type bigint and category FK2. The amount may be of type decimal. The description may be of type text. One or more of the components of the wallet transactions 1210 may have the value of (or be initialized as) not null.
[0261 ] The wallets 1215 may have one or more components, including: an ID, a balance, and/or a status. The ID may be of type bigint and category PK. The balance may be of type decimal. The status may be of type varchar(num), where num is an integer such as 50. One or more of the components of the wallets 1215 may have the value of (or be initialized as) not null.
[0262] The users 1220 may have one or more components, including: an ID, a first name, a last name, a password, an email, an origin, a status, and/or a wallet. The ID may be of type bigint and category PK. The first name may be of type varchar(num), where num is an integer such as 100. The last name may be of type varchar(num), where num is an integer such as 100. The password may be of type text. The email may be of type varchar(num), where num is an integer such as 50, and category UQ. The origin may be of type varchar(num), where num is an integer such as 50. The status may be of type varchar(num), where num is an integer such as 50. The wallet may be of type bigint and category FK1 . One or more of the components of the users 1220 may have the value of (or be initialized as) not null.
[0263] The user followers 1225 may have one or more components, including: a user, a follower, and/or a creation date. The user may be of type bigint and category PK and/or FK1 . The follower may be of type bigint and category PK and/or FK2. The creation date may be of type datetime. One or more of the components of the user followers 1215 may have the value of (or be initialized as) not null.
[0264] The rental NFTs 1230 may have one or more components, including: an ID, a title, a file, a status, a price, a user, and/or a creation date. The ID may be of type bigint and category PK. The title may be of type char(num), where num is an integer such as 100. The file may be of type bigint and category FK1 . The status may be of type varchar(num), where num is an integer such as 50. The price may be of type decimal. The user may be of type bigint and category FK2. The creation date may be of type datetime. One or more of the components of the rental NFTs 1215 may have the value of (or be initialized as) not null.
[0265] The post likes 1235 may have one or more components, including: a post, a user, and/or a creation date. The post may be of type bigint and category PK and/or FK1 . The user may be of type bigint and category PK and/or FK2. The creation date may be of type datetime. One or more of the components of the post likes 1235 may have the value of (or be initialized as) not null.
[0266] The NFT sells 1240 may have one or more components, including: an ID, an owner, a buyer, an NFT, a price, and/or a creation date. The ID may be of type bigint and category PK. The owner may be of type FK1 and category FK1. The buyer may be of type bigint and category FK2. The NFT may be of type bigint and category FK3. The price may be of type decimal. The creation date may be of category datetime. One or more of the components of the NFT sells 1235 may have the value of (or be initialized as) not null. [0267] The original NFTs 1245 may have one or more components, including: an ID, a file, an owner address, and/or a metadata secure hash (e.g., SHA). The ID may be of type bigint and category PK The file may be of type bigint and category FK1 . The owner address may be of type text. The metadata secure hash (e.g., SHA) may be of type varchar(num), where num is an integer such as 64, and category FK2. One or more of the components of the original NFTs 1245 may have the value of (or be initialized as) not null.
[0268] The files 1250 may have one or more components, including: ID, checksum, size, mime type, and/or URL. The ID may be of type bigint and category PK. The checksum may be of type char(num), where num is an integer such as 50. The size may be of type decimal. The mime type may be of type char(num), where num is an integer such as 50. The URL may be of type char(num), where num is an integer such as 50. One or more of the components of the files 1250 may have the value of (or be initialized as) not null.
[0269] The NFT metadata 1255 may have one or more components, including: secure hash (e.g., SHA), social data, file metadata, media link, author address, and/or NFT terms. The secure hash (e.g., SHA) may be of type varchar(num), where num is an integer such as 64, and type PK. The social data may be of type bigint. The file metadata may be of type JSONB. The media link may be of type text. The author address may be of type text. The NFT terms may be of type varchar(num), where num is an integer such as 64, and category FK1 . One or more of the components of the NFT metadata 1255 may have the value of (or be initialized as) not null.
[0270] The NFT terms 1260 may have one or more components, including: secure hash (e.g., SHA), privacy terms, and/or contract. The secure hash (e.g., SHA) may be of type varchar(num), where num is an integer such as 64, and category PK. The privacy terms may be of type JSONB. The contract may be of type JSONB. One or more of the components of the NFT terms 1260 may have the value of (or be initialized as) not null.
[0271 ] The connecting lines in the data structure 1200 show where particular data records or components thereof may be accessed, duplicated, read from, written to, or stored in. [0272] The wallet transactions 1210 may be connected to the wallets 1215. For example, the origin of a wallet transaction 1210 may access a wallet 1215 when the origin of the wallet transaction 1210 is the same as the ID of the wallet 1215. For example, the destination of a wallet transaction 1210 may access a wallet 1215 when the destination of the wallet transaction 1210 is the same as the ID of the wallet 1215.
[0273] The wallets 1215 may be connected to the wallet transactions 1210 and/or the users 1220.
[0274] The users 1220 may be connected to the wallets 1215, the user followers 1225, the rental NFTs 1230, the post likes 1235, and/or the NFT sells 1240. For example, the wallet of a user 1220 may be stored in a wallet 1215.
[0275] The user followers 1225 may be connected to the users 1220. For example, the user of a user follower 1225 may be stored in a user 1220. For example, the follower of a user follower 1225 may be stored in a user 1220.
[0276] The rental NFTs 1230 may be connected to the users 1220, the post likes 1235, and/or the files 1250. For example, the user of a rental NFT 1230 may be stored in a user 1220. For example, the file of a rental NFT 1230 may be stored in a file 1250.
[0277] The post likes 1235 may be connected to the users 1220 and/or the rental NFTs 1230. For example, the post of a post like 1235 may be stored in a rental NFT 1230 when the post of the post like 1235 is the same as the ID of the rental NFT 1230. For example, the user of a post like 1235 may be stored in a user 1220.
[0278] The NFT sells 1240 may be connected to the users 1220 and/or the original NFTs 1245. For example, the owner of an NFT sell 1240 may be stored in a user 1220. For example, the buyer of an NFT sell 1240 may be stored in a user 1220. For example, the NFT of an NFT sell 1240 may be stored in an original NFT 1245.
[0279] The original NFTs 1245 may be connected to the NFT sells 1240, the files 1250, and/or the NFT metadata 1255. For example, the metadata secure hash (e.g., SHA) of an original NFT 1245 may be stored as the secure hash (e.g., SHA) in an NFT metadata 1255.
[0280] The files 1250 may be connected to the rental NFTs 1230 and/or the original NFTs 1245. For example, a file 1250 may be stored as the file of an original NFT 1245. [0281 ] The NFT metadata 1255 may be connected to the original NFTs 1245 and/or the NFT terms 1260. For example, the NFT terms of an NFT metadata 1255 may be stored as NFT terms 1260 when the secure hash (e.g., SHA) of the NFT metadata 1255 is the same as the secure hash (e.g., SHA) of the NFT terms 1260.
[0282] The NFT terms 1260 may be connected to the NFT metadata 1255.
[0283] Reference is made to FIG. 13, showing a block diagram of an example embodiment of an entity-relationship (ER) model 1300 for a rental NFT system (or “app”). The ER model 1300 may be that of the system architecture 900.
[0284] The ER model 1300 has one or more of the following entities: users 1310, wallets 1320, NFTs 1330, posts 1340, files 1350, NFT metadata 1360, and/or NFT terms 1370.
[0285] The users 1310 may have one or more components, including: an ID, an email, a first name, a last name, a password, and/or an origin.
[0286] The wallets 1320 may have one or more components, including: an ID and/or a balance.
[0287] The NFTs 1330 may have one or more components, including: an ID and/or an owner address.
[0288] The posts 1340 may have one or more components, including: an ID, a title, a price, and/or a status.
[0289] The files 1350 may have one or more components, including: an ID, an URL, a size, a checksum, and/or a mime type.
[0290] The NFT metadata 1360 may have one or more components, including a secure hash (e.g., SHA), social data, file metadata, a media link, and/or an author address.
[0291 ] The NFT terms 1370 may have one or more components, including a secure hash (e.g., SHA), privacy and terms, and/or a contract.
[0292] The connecting lines in the ER model 1300 show the relationships between the entities. The relationships include one or more of the following: has 1312, follow 1313, buy 1314, create 1315, like 1316, transfer 1322, require 1332, include 1333, contain 1342, and need/or 1362. Some relations may have a date field that identifies when the relationship between entities of the same type or of different types was formed. The relations that may have a date field include, for example: follow 1313, buy 1314, create 1315, like 1316, and/or transfer 1322.
[0293] The users 1310 may have a 1 :1 has 1312 relationship with the wallets 1320. For example, a user 1310 has 1312 a wallet 1320.
[0294] The users 1310 may have an N:M follow 1313 relationship with other users 1310. For example, one or more of the users 1310 follow 1313 another one or more of the users 1310.
[0295] The users 1310 may have an N:M buy 1314 relationship with the NFTs 1330. For example, one or more of the users 1310 buy 1314 one or more of the NFTs 1330.
[0296] The users 1310 may have a 1 :N create 1315 relationship with the posts 1340. For example, one of the users 1310 creates 1315 a post 1315.
[0297] The users 1310 may have an N:M like 1316 relationship with the posts 1340. For example, one or more of the users 1310 like 1316 one or more of the posts 1340.
[0298] The wallets may have an N:M transfer 1322 relationship with other wallets 1320. For example, one or more of the wallets 1320 transfers 1322 to another one or more of the wallets 1320.
[0299] The NFTs may have a 1 :1 require 1332 relationship with NFT metadata 1360. For example, one of the NFTs 1330 requires 1332 NFT metadata 1360.
[0300] The NFTs may have a 1 :1 include 1333 relationship with the files 1350. For example, one of the NFTs 1330 includes 1333 files 1350.
[0301] The posts 1340 may have a 1 :N contain 1342 relationship with the files 1350. For example, one of the posts 1340 contains 1342 one or more files 1350.
[0302] The NFT metadata 1360 may have a 1 :1 need 1362 relationship with the NFT terms. For example, the NFT metadata 1360 need 1362 NFT terms 1370.
[0303] Reference is made to FIG. 14, showing a block diagram of an example embodiment of background jobs management 1400 in a rental NFT system (or “app”). The background jobs management 1400 may be applied to the background jobs 955 of the system architecture 900.
[0304] The background jobs management 1400 is a non-interactive service that runs behind the normal interactive operations. The background jobs may run in parallel and may be configured so as not to disturb interactive processes and operations. The background jobs management 1400 provides a service that may be a direct part of the back end, using the same codebase, database, architecture, etc.
[0305] The background jobs management 1400 may include one or more of the following components: a back-end server 1410, other resources 1420 (such as a blockchain, files storage, metadata storage, and/or a database), a background jobs process 1430, and a Redis 1440.
[0306] The back-end server 1410 may manage the other resources 1420. The back- end server 1410 may schedule jobs in the Redis 1440, for example, by creating a record in the Redis 1440 with all required info for the job. The background jobs process 1430 may read these records and perform the jobs (or “pick and process” from the Redis 1440). The background jobs process may process the jobs for output to the other resources 1420.
[0307] The other resources 1420 may include files storage. In such a case, the files storage may store and manage media files created by the user. The files storage may be implemented using cloud storage.
[0308] The other resources 1420 may include a blockchain. In such a case, the blockchain may issue, manage, and store NFTs. The blockchain may use the ERC-1155 token standard. The blockchain may be an EVM-compatible blockchain, meaning compatible with the Ethereum Virtual Machine (EVM). An EVM-compatible blockchain allows users to withdraw NFTs to Ethereum. The blockchain may use the Polygon protocol. The blockchain may store smart contracts for: (1 ) NFTs of media files created by users of the rental NFT system 100; and (2) rental NFTs, which represents renting of NFTs of media files over the rental NFT system 100.
[0309] The other resources 1420 may include metadata storage (or “meta storage”). The metadata storage may be implemented using a language such as TypeScript and technologies such as NodeJS, NestJS, and/or MongoDB. The metadata storage may provide content-addressable storage, and it may store and provide public metadata for NFTs. At the same time, the metadata storage may store private information (e.g., terms) per each action with an NFT (e.g., create, buy, rent).
[0310] The metadata storage may be configured so that its content is accessible using the checksum of the content itself. In such a case, what is written to this storage cannot be changed in the future. As a result, any device can read the metadata of NFTs, but only trusted applications can read terms of the NFTs.
[0311 ] Reference is made to FIG. 15, showing a block diagram of an example embodiment of a metadata storage architecture 1500 in a rental NFT system (or “app”). The metadata storage architecture 1500 may be that of the metadata storage 940 of the system architecture 900.
[0312] The modules in the metadata storage architecture 1500 include one or more of the following modules: API view 1510, API controller 1520, admin III 1530, admin controller 1540, authentication module 1550, data model 1560, and/or database 1570.
[0313] The API 1510 may provide responses in JSON format for API Users.
[0314] The API controller 1520 may hold logic on receiving requests from API users and preparing responses.
[0315] The admin Ul 1530 may provide a web interface for human users.
[0316] The admin controller 1540 may hold logic on receiving requests and preparing responses for users who work with a web interface.
[0317] The authentication module 1550 may control what data can be provided to a user of a service. Terms may be considered private, in which only a limited amount of users and applications can get access to the terms.
[0318] The data model 1560 may represent the data model of the app, holding business logic on retrieving data from the database 1570.
[0319] The database 1570 may be MongoDB storage for metadata and the terms. [0320] Reference is made to FIG. 16, showing a block diagram of an example embodiment of a metadata database design 1600 in a rental NFT system (or “app”). The metadata database design 1600 may be that of the metadata storage 940 of the system architecture 900.
[0321 ] The metadata database design 1600 provides an example of the database structure for use with meta storage. The database structure may have one or more of four tables: authorized apps 1610, users 1620, metadata 1630, and/or terms 1640.
[0322] The authorized apps 1610 may holds access keys for each application, which can read the terms 1640. The authorized apps 1610 may be a table that includes one or more of: an ID of type number; a key of type string; an app name of string; a created at of type date; and/or an expired at of type date.
[0323] The users 1620 may contain the identities of the people who can access the III of the app. The users 1620 may be a table that includes one or more of: an ID of type number; an email of type string; a username of type string; a role of type string; and/or a created at of type date.
[0324] The metadata 1630 may include metadata for each NFT issued by the app. The metadata 1630 may be a table that includes one or more of: a secure hash (e.g., SHA) of type string; a file link of type string; file metadata of type JSON; social data of type JSON; an author address of type string; a terms secure hash (e.g., SHA) of type string; and/or a created at of type date.
[0325] The terms 1640 may store private information for each interaction with an NFT (e.g., create, buy, rent). The terms 1640 may be a table that includes one or more of: a secure hash (e.g., SHA) of type string; privacy and terms of type string; a contract of type string; a price of type number; and a created at of type date.
[0326] Reference is made to FIG. 17, showing an example template of an NFT smart contract 1700 in a rental NFT system (or “app”). The NFT smart contract 1700 may be used by one or more components of the system architecture 900.
[0327] The NFT smart contract 1700 has one or more properties, including: balances (asset ID -> address -> balance); approvals (asset ID -> address -> Boolean); metadata hashes (asset ID -> hash); purchase terms hashes (asset ID -> hashes); URI (default with hash substitution); rental contract address; and/or m inter address.
[0328] The NFT smart contract 1700 has one or more functions, including: safe transfer from; safe batch transfer from safe transfer from with terms (terms hash is saved or emitted); balance of (address, asset ID); balance of batch; set approval for all; is approved for all; URI (for asset ID, points to metadata); purchase terms hashers (for asset ID); and/or rental contract address.
[0329] The NFT smart contract 1700 may have one or more minter-only functions, including: mint asset (to address, metadata hash).
[0330] The NFT smart contract 1700 may be ERC-1155 compliant but with additional features. A first example is there may be per ID metadata URIs made from a hash specified on asset creation. This way URIs become content-addressable, such that making changes to the terms document will change its address. A second example is that purchase terms hashes may be supplied with a special transfer function and stored for each token. In this case, there may also be a function to obtain the purchase terms hashes. A third example is that an address of a rental contract may be stored. A fourth example is the storage of a secure hash (e.g., SHA) of purchase terms for each NFT transfer.
[0331 ] Reference is made to FIG. 18, showing an example template of a standalone rental NFT smart contract 1800 in a rental NFT system (or“app”). The standalone rental NFT smart contract 1800 may be used by one or more components of the system architecture 900.
[0332] The standalone rental NFT smart contract 1800 has one or more properties, including: rents of asset (asset ID -> rent IDs); rents (rent ID -> owner address, expirations, rental terms hash); asset contract address; and/or m inter (e.g., original creator) address. The standalone rental NFT smart contract 1800 may have additional properties, such as: a map of the asset ID to the rent ID; and/or a list of rental NFTs which are identified by the rent ID.
[0333] The standalone rental NFT smart contract 1800 may have one or more ERC- 1155 compatibility properties, including: URI (default with ID substitution). [0334] The standalone rental NFT smart contract 1800 has one or more functions, including: rents of asset; rent data (by rent ID); and/or asset contract.
[0335] The standalone rental NFT smart contract 1800 may have one or more ERC- 1155 compatibility functions, including: balance of (address, asset ID); balance of batch; and/or URI (for rent, points to metadata).
[0336] The standalone rental NFT smart contract 1800 may have one or more minter- only functions, including: mint rent (to asset ID, to address, expiration, terms hash).
[0337] The standalone rental NFT smart contract 1800 may be a custom contract that is compatible with ERC-1155. In such a case, applications which work with ERC-1155 tokens are able to work with rental NFTs using the standalone rental NFT smart contract 1800. This means that the applications that work with ERC-1155 tokens are able to display these rental NFTs properly.
[0338] The standalone rental NFT smart contract 1800 may be operable with the use of a microservice which presents custom fields of the rental NFT (e.g., ID of rented NFT, renter wallet address, expiration date, terms secure hash (e.g., SHA)) as metadata. The standalone rental NFT smart contract 1800 may also be formatted to provide the same “look and feel” of the ERC-721.
[0339] The standalone rental NFT smart contract 1800 may have compatibility functions that allow for querying balance(s) and metadata just like with regular ERC-1155 contracts. The standalone rental NFT smart contract 1800 may have one or more of the following features: (1 ) removal of all transfer functions; (2) no balance for tokens, they are explicitly unique; (3) added properties and functions to keep track of an asset contract address and rents for specific tokens; (4) expiration date and rental terms hashes stored on the contract; and/or (5) metadata for compatibility only, being derived from contract properties.
[0340] Reference is made to FIG. 19, showing an example template of a smart contract with embedded rental 1900 in a rental NFT system (or “app”). The smart contract with embedded rental 1900 may be used by one or more components of the system architecture 900. [0341 ] The smart contract with embedded rental 1900 has one or more properties, including: balances (asset ID -> address -> balance); approvals (asset ID -> address -> boolean); purchase terms hashes (asset ID -> hashes); rents of asset (asset ID -> rent IDs); rents (rents ID -> owner address, expirations, rental terms hash); URI(s) (one default or per ID with hash substitution); rental terms URI(s) (one default or per ID); and/or minter address.
[0342] The smart contract with embedded rental 1900 has one or more functions, including: safe transfer from; safe batch transfer from; safe transfer from with terms (terms hash is saved or emitted); balance of (address, asset ID); balance of batch; set approval for all; is approved for all; URI (for ID, points to metadata); purchase terms hashes (for asset ID); rents of asset; and/or rent data (by rent ID).
[0343] The smart contract with embedded rental 1900 may have one or more minter- only functions, including: mint asset (to address, metadata hash); and/or mint rent (to asset ID, to address, expiration, terms hash).
[0344] The smart contract with embedded rental 1900 may be considered to be a combination of NFT smart contract 1700 with the standalone rental NFT smart contract 1800. This combination eliminates the need to keep references of contracts to each other. It also eliminates the possibility for multiple rental contracts to exist for the single NFT contract. Rents still cannot be transferred.
[0345] Referring now to FIG. 20, shown therein is screen capture of an example of a new user landing page 2000 for a rental NFT system (or “app”). The new user landing page 2000 may be used by the front end of the system architecture 900. The new user landing page 2000 includes graphic user interface (GUI) elements for navigability on a device. The new user landing page 2000 may be for a social media NFT marketplace and may include GUI elements for signing up or signing in. The GUI elements may include options for continuing with Google or a Facebook account, a button for easy sign-up, a link for signing in if a user already has an account, and/or a button to learn more about a social media marketplace. The GUI elements may also provide legal statements including terms of service and privacy policy. [0346] Referring now to FIG. 21 , shown therein is screen capture of an example of a log in - after log out page 2100 for a rental NFT system (or “app”). The log in - after log out page 2100 may be used by the front end of the system architecture 900. The log in - after log out page 2100 may show graphic user interface (GUI) elements for navigability on a device. The log in - after log out page 2100 may be displayed for a returning user who has already signed up by using the new user landing page 2000. The log in - after log out page 2100 may include GUI elements that provide options for continuing with the user’s Google or Facebook or Instagram account, login options, a link to retrieve or reset forgotten password, a button for logging in link, and legal statements including links to the terms of service and privacy policy. The login options may include an interface to provide a user’s login information like login ID, such as john.doe@mydomain.com, and a password. The link to retrieve or reset a forgotten password may direct the user to another page where the user may need to provide additional details for retrieving or resetting the password. When the user has successfully logged in by providing a correct login ID and password, and clicking the login button, the user may be directed to various tour options.
[0347] Referring now to FIGS. 22 to 24, shown therein are screen captures of examples of various options in a tour menu for a rental NFT system (or “app”).
[0348] FIG. 22 shows a screen capture of an example of a Tour 1 st page 2200 for a rental NFT system (or “app”). The Tour 1 st page 2200 may be used by the front end of the system architecture 900. The Tour 1 st page 2200 may include an overview of the functioning of the app. The overview may include details about the social media marketplace, as well as buying and selling NFTs for profit or investment. The Tour 1 st page 2200 may also include options to swipe and go to a next tour page, and a link to cancel the tour. The Tour 1 st page 2200 may include legal statements including links to the terms of service and privacy policy. The details about the social media marketplace may include text like “Think of this as a social community where one can showcase digital art and sell or buy them. You don’t have to be an artist to be part of the community.” The details about buying and selling NFTs for profit or investment may include text like “One of the big selling points of NFTs (Non-fungible Token) is that they allow digital artists to claim ownership of their work. Previously it was difficult to earn anything from files that people could download and share for free (often without the artist’s permission). A seller can sell for a higher price or the item gets popular and increases in value. This it can become an investment.”
[0349] FIG. 23 shows a screen capture of an example of a Tour 2nd page 2300 for a rental NFT system (or “app”). The Tour 2nd page 2300 may be used by the front end of the system architecture 900. The Tour 2nd page 2300 may include information regarding a digital currency (e.g., Cointiks). The information related to Cointiks may include details regarding what are Cointiks and may include text like “Cointiks is a new digital currency unique to this platform that can be purchased and exchanged for content/ NFT’s only within the Facerent platform. Kinda like a new crypto currency. A user can purchase Cointiks at any time, and in the future will be allowed to cash in for real currency. 500 Cointiks = $ 10”. The Tour 2nd page 2300 may also include options to swipe and go to a next tour page, and a link to cancel tour. The Tour 2nd page 2300 may also include legal statements including links to the terms of service and privacy policy.
[0350] FIG. 24 shows screen capture of an example of a Tour 3rd page 2400 for a rental NFT system (or “app”). The Tour 3rd page 2400 may be used by the front end of the system architecture 900. The Tour 3rd page 2400 may include information regarding other content ideas. The information related to other content ideas may include details regarding buying and selling, pricing, and how do royalties work. The Tour 3rd page 2400 may also include options for displaying more information, swiping to go to a previous tour page, and a “Done” button for ending the tour. The Tour 3rd page 2400 may also include legal statements including links to the terms of service and privacy policy.
[0351 ] Referring now to FIGS. 25 to 31 , shown therein are screen captures of examples of sign-up steps for a rental NFT system (or “app”).
[0352] FIG. 25 shows a screen capture of an example of a Step 1 page 2500 of signup for a rental NFT system (or “app”). The Step 1 page 2500 may be used by the front end of the system architecture 900. The Step 1 page 2500 may include GUI elements to accept user information for creating a profile of the user and signing-up the user to use the app. The GUI elements may include an interface to accept the user’s login ID (for example, an email address) and mobile number. The GUI elements may also include an option to send a verification code to the user by an SMS or email, and a button to confirm that the verification code must be sent to the user-selected option. The Step 1 page 2500 may also include legal statements including links to the terms of service and privacy policy.
[0353] FIG. 26 shows a screen capture of an example of a Step 2 page 2600 of the sign-up (which may be the step of verifying the user) for a rental NFT system (or “app”). The Step 2 page 2600 may be used by the front end of the system architecture 900. The Step 2 page 2600 may include GUI elements from the Step 1 page 2500 and an option to accept a verification code. The Step 2 page 2600 may also include a button to re-send a verification code to the user-selected option (e.g., SMS or email), and may also include a countdown timer to provide a time frame within which the user must provide a correct verification code. The Step 2 page 2600 may also include a next button to confirm successful user verification. The Step 2 page 2600 may also include legal statements including links to the terms of service and privacy policy.
[0354] FIG. 27 shows a screen capture of an example of a Step 3 page 2700 of the sign-up step (which may be a simple prompt) for a rental NFT system (or “app”). The Step 3 page 2700 may be used by the front end of the system architecture 900. The Step 3 page 2700 may include GUI elements for providing a password and accepting terms and conditions of the app. The Step 3 page 2700 may also include a next button to accept additional inputs from the user. The Step 3 page 2700 may also include legal statements including links to the terms of service and privacy policy.
[0355] FIG. 28 shows a screen capture of an example of an edit profile page 2800 on successful sign-up for a rental NFT system (or “app”). The edit profile page 2800 may be used by the front end of the system architecture 900. The edit profile page 2800 may include GUI elements to accept additional information from the user. The GUI elements on the edit profile page may include options to upload/edit a profile picture, add a display name, full name, password, user’s bio (e.g., information related to the user that the user would want people to know), and a PIN for security. The edit profile page 2800 may also include a save button to save accepted user information, and a menu bar for quick navigation to menu options. The menu bar may include options to add additional information, buy Cointiks, access main menu/feed, access user profile, and access settings. [0356] FIG. 29 shows a screen capture of an example of an upload profile picture page 2900 for a rental NFT system (or “app”). The edit profile page 2900 may be used by the front end of the system architecture 900. When a user wishes to upload/edit a profile picture, the user can do so using options provided by the GUI elements on the upload profile picture page. These GUI elements may provide options to access a camera, photo library on the user’s device, or user’s cloud storage (e.g., Google Drive etc.) to enable the user to click or upload the profile picture. The upload profile picture page 2900 may also provide a menu bar having options to add additional information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0357] FIG. 30 shows screen capture of an example of a profile updated page 3000 when a user profile is successfully updated for a rental NFT system (or “app”). The profile updated page 3000 may be used by the front end of the system architecture 900. The profile updated page 3000 may display user information accepted from the user with the help of GUI elements. The user information may include a profile picture, a display name (for example, John TheFaceRenter), full name (for example, John Doe), password, user’s bio (for example, “I am a popular social media influencer. I have been known for my crazy expressions and unique face.”), and a PIN for security (for example, 1373). The profile updated page 3000 may also include a save button to save the user information, and a menu bar for quick navigation to menu options. The menu bar may include options to add additional information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0358] FIG. 31 shows a screen capture of an example of an easy done page 3100 when a user profile is successfully completed for a rental NFT system (or “app”). The easy done page 3100 may be used by the front end of the system architecture 900. The easy done page 3100 may display a simple prompt to confirm that the user profile has been completed, and may also include a note. The simple prompt may read “Awesome!”. The note may include text like “Feel free to check out the application. However, before you can upload content, sell or buy items you will have to update your profile and select a PIN”. The easy done page 3100 may also include a link to redirect the user to update their profile, and a button to go to the feed/main menu. The easy done page 3100 may also include legal statements including links to the terms of service and privacy policy. [0359] Referring now to FIG. 32, shown therein is a screen capture of an example of a main feed page 3200 for a rental NFT system (or “app”). The main feed page 3200 may be used by the front end of the system architecture 900. The main feed page 3200 may include elements like information related to Cointiks owned by the user (for example, R 500 ($122USD)), notifications (e.g., a bell icon), a search bar, number of items for sale (e.g., 756 items for sale), brief information regarding NFT item(s), and the menu bar. The details regarding brief information regarding NFT item(s) may include an image, item owner’s name, NFT item name, number of likes (e.g., number of other users that have liked the NFT item), and price of the NFT item (e.g., in Cointiks). The menu bar may include options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0360] Referring now to FIG. 33, shown therein is a screen capture of an example of a settings page 3300 for a rental NFT system (or “app”). The settings page 3300 may be used by the front end of the system architecture 900. The settings page 3300 may be accessed using a menu bar. The settings page 3300 may include GUI elements providing options to the user to access profile and edit profile, access notifications, access/change privacy settings, reset PIN, access terms and conditions, and log out. The settings may also include an option to learn more about the features of the application, a link to provide user feedback, and a menu bar. The menu bar may include options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0361 ] Referring now to FIG. 34, shown therein is a screen capture of an example of a main feed item details page 3400 for a rental NFT system (or “app”). The main feed item details page 3400 may be used by the front end of the system architecture 900. The main feed item details page 3400 provides detailed information related to an NFT item on the main feed. Detailed information related to an NFT item may be obtained by clicking on the respective NFT item image. The main feed item details may include elements like NFT item image, price in Cointiks and dollars (for example, 250 Cointiks ($5)), a button to buy the NFT item, NFT item creator’s name (for example, JoetheNFTCreator), seller’s name (for example, HollyWarnerSeller), NFT item name (for example, MyFirstNFTArt) and details related to the item, a button/icon to copy link and share the NFT item details, a drop-down menu providing details about the artist/creator, a drop-down menu providing stats related to the NFT item, and a drop-down menu providing specs (specifications) of the NFT item. The stats may include statistics related to the NFT item like number of users that have liked the item (for example, 112), number of users that have viewed the item (for example, 756), number of times the item has been purchased (for example, 3 Times), duration since the item is trending (for example, last 30 days), days since the item was last purchased (for example, 180), date the item was last purchased (for example, Jan 12, 2021 ). The stats may also include a link to view detailed history related to the NFT item. The specs may include NFT item specifications like create data, i.e., the date when the item was created (e.g., Jan 23, 2021 ), type of item (e.g., JPEG image), dimensions of the item (for example, 1240 x 768 px -> 300 DPI). The main feed item details page 3400 may also provide details related to the user’s current Cointiks balance (e.g., 500 Cointiks ($10 USD)), a shortcut to access notifications (e.g., the bell icon), and a note notifying the user that they have enough Cointiks to buy the NFT item that is being viewed. The main feed item details page 3400 may also include the menu bar providing options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0362] Referring now to FIGS. 35 and 36, shown therein are screen captures of example pages of buy item steps for a rental NFT system (or “app”).
[0363] FIG. 35 shows a screen capture of an example of a buy item Step 1 page 3500 for a rental NFT system (or “app”). The buy item Step 1 page 3500 may be used by the front end of the system architecture 900. The buy item Step 1 page 3500 provides GUI elements to the user to buy an NFT item. The GUI elements may be provided to the user when the user clicks buy button provided with the main feed item details. The buy item Step 1 page 3500 provides Cointiks balance of the user (e.g., 500 Cointiks ($10 USD)), name of the NFT item (for example, MyFirstNFTArt), and price of the NFT item (e.g., 250 ($5 USD)). The GUI elements may provide options to insert the user’s PIN for security reasons (for example, 1373), and buttons to purchase the NFT item or cancel purchase. The buy item Step 1 page 3500 may also provide an option to the user to buy more Cointiks if they do not have enough Cointiks to buy the NFT item. The buy item Step 1 page 3500 may also provide details related to the user’s current Cointiks balance (e.g., 500 Cointiks ($10 USD)), a shortcut to access notifications (e.g., the bell icon), and the note notifying the user that they have enough Cointiks to buy the NFT item that is being viewed. The buy item Step 1 page 3500 may also provide the menu bar providing options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0364] FIG. 36 shows screen capture of an example of a buy item Step 2 page 3600 for a rental NFT system (or “app”). The buy item Step 2 page 3600 may be used by the front end of the system architecture 900. The buy item Step 2 page 3600 may provide a prompt text like “Congratulations, you have just made a purchase!” on successful purchase of the NFT item, and may also provide the user’s current Cointiks balance (e.g., 250 Cointiks ($5 USD)). The buy item Step 2 page 3600 may also provide GUI elements like a button to view the purchased NFT item, and close the buy item Step 2 page. The purchased NFT item may be viewed in the content area on the user’s profile. The buy item Step 2 page 3600 may also provide details related to the user’s current Cointiks balance (e.g., 250 Cointiks ($5 USD)), a shortcut to access notifications (e.g., the bell icon), and the note notifying the user that they have enough Cointiks to buy the NFT item. The buy item Step 2 page 3600 may also provide the menu bar providing options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0365] Referring now to FIG. 37, shown therein is a screen capture of an example of an item details - item zoomed page 3700 for a rental NFT system (or “app”). The item details - item zoomed page 3700 may be used by the front end of the system architecture 900. The item details - item zoomed page 3700 provides a zoomed in or zoomed out view of an NFT item image to the user. The user may use simple hand gestures (pinch finger) to zoom in and zoom out on the NFT image. The item details - item zoomed page 3700 may also provide details related to the user’s current Cointiks balance (e.g., 500 Cointiks ($10 USD)), and a shortcut to access notifications (e.g., the bell icon). The item details - item zoomed page 3700 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0366] Referring now to FIGS. 38 to 40, shown therein are screen captures of examples of add content pages for a rental NFT system (or “app”).
[0367] FIG. 38 shows a screen capture of an example of an upload content form page 3800 when content to be uploaded is an image for a rental NFT system (or “app”). The upload content form page 3800 may be used by the front end of the system architecture 900. The upload content form page 3800 provides GUI elements to add content (e.g., NFT item). Content may only be added if the user has all rights and agrees to terms and condition. The GUI elements to add content may include a box to upload an image, and information text like “Images can be in PNG, JPG or X format. System will create Thumbnail”. The GUI elements may also include options to provide an NFT title, description, date created, and an option to save content and content details. The GUI elements may also include options to provide a price of the content (e.g., Cointiks) which can be provided later, and a checkbox to select whether the content (e.g., image) needs to be posted immediately for sale. The upload content form page 3800 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0368] FIG. 39 shows a screen capture of an example of a select image overlay page 3900 related to the upload content form for a rental NFT system (or “app”). The select image overlay page 3900 may be used by the front end of the system architecture 900. The select image overlay page 3900 provides GUI elements to add content (e.g., image). The GUI elements may include a box to upload an image and information text like “Images can be in PNG, JPG or X format. System will create Thumbnail”. The GUI elements may also include options to click an image using user’s device camera, upload an image from a photo library, and download an image from the cloud (e.g., Google Drive). A note may also be provided to notify the user to connect to WiFi if they wish to download image from the cloud. The select image overlay page 3900 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0369] FIG. 40 shows a screen capture of a filled-out form page 4000 when content (e.g., image) has been uploaded for a rental NFT system (or “app”). The filled-out form page 4000 may be used by the front end of the system architecture 900. The filled-out form page 4000 may provide GUI elements to display and edit added content (e.g., NFT item). Content may only be added if the user has all rights and agrees to terms and condition. The filled-out form page 4000 may display an uploaded image, information text like “Images can be in PNG, JPG or X format. System will create Thumbnail”, and information related to the uploaded imaged (for example, File Size: xxx MB, Type: JPEG, Dimensions: xxx by xxx pixels, DPI: 300). The filled-out form page 4000 may also display an NFT title (e.g., ShannaNFT #1 ), description (e.g., “This is a photo and retouching I did in the beginning of 2021. The blank n white gives in a sultry feel and adds to the character and personality.”), date created (e.g., January 25, 2021 ), and an option to save content and content details. The filled-out form page 4000 may also include the option to provide a price of the content (e.g., 250 Cointiks), and a checkbox to select whether the content (e.g., image) needs to be posted immediately for sale. The filled-out form page 4000 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0370] Referring now to FIGS. 41 and 42, shown therein are screen captures of examples of a user profile page for a rental NFT system (or “app”).
[0371 ] FIG. 41 shows a screen capture of an example of a public view of the user profile page 4100 for a rental NFT system (or “app”). The public view of the user profile page 4100 may be used by the front end of the system architecture 900. The public view of the user profile page 4100 may provide a user’s information and content including user’s image, user followers (e.g., 1657 followers), an option to follow the user, user’s member details (e.g., the user has been member since xxxxx), user’s name (e.g., JoetheNFTCreator), user’s details, a drop-down list to see user’s stats, and available NFTs by the user. The public view of the user profile page 4100 may also provide a scale option to adjust view of number of available NFTs, and a filter option to view the user’s NFTs (e.g., all NFTs, user’s original NFTs, and purchased NFTs). The NFTs may be be image thumbnails that are displayed on the public view of the user profile page 4100. The public view of the user profile page 4100 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0372] FIG. 42 shows a screen capture of a user view of the user profile page 4200 for a rental NFT system (or “app”). The user view of the user profile page 4200 may be used by the front end of the system architecture 900. The user view of the user profile page 4200 may provide the user’s information and content including user’s image, user followers (e.g., 1657 followers), an option edit profile, user’s member details (e.g., member since xxxxx), user’s name (e.g., JoetheNFTCreator), user’s details, a drop-down list to see user’s stats, and user’s NFTs. The user view of the user profile page 4200 may also provide a scale option to adjust view of number of available NFTs, and a filter option to view user’s NFTs (e.g., all NFTs, user’s original NFTs, NFTs that are pending sell, and purchased NFTs). The NFTs maybe be image thumbnails that are displayed on the user view of the user profile. The user view of the user profile page 4200 may also include NFT price on the NFT image thumbnails. The user view of the user profile page 4200 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0373] Referring now to FIG. 43, shown therein is a screen capture of an example of a Cointiks - buy more overlay page 4300 for a rental NFT system (or “app”). The Cointiks - buy more overlay page 4300 may be used by the front end of the system architecture 900. The Cointiks - buy more overlay page 4300 may be displayed when the user wants to buy Cointiks. The Cointiks - buy more overlay page 4300 may provide current Cointiks balance of the user (e.g., 500 Cointiks ($10 USD)), and an information link providing more help with Cointiks and how to use them. The Cointiks - buy more overlay page 4300 may also provide GUI elements to add/buy more Cointiks. The GUI elements may provide options to buy 500 Cointiks ($10 USD), 1000 Cointiks ($20 USD), and any other user suitable amount of Cointiks. The Cointiks - buy more overlay page 4300 may also provide the menu bar for easy access including options to add information, buy Cointiks, access main menu/feed, access user profile, and access settings.
[0374] Referring now to FIG. 44, shown therein is an example of mobile screen interactions 4400 that may be used while using a rental NFT system (or “app”) on a user’s device. The mobile screen interactions 4400 may be used by the front end of the system architecture 900. An icon 4410 (e.g., bell icon of notifications) may be held and swiped down with the help of the user’s finger to display notifications 4420 and may be swiped up to close notifications 4430. Displayed notifications may be deleted with a left swipe 4440. A left swipe may provide a delete notification option, and a hard/fast left swipe may instantly delete a notification. Example gesture image 4450 shows various hand gestures/motions that may be used for different mobile screen interactions.
[0375] While the applicant’s teachings described herein are in conjunction with various embodiments for illustrative purposes, it is not intended that the applicant’s teachings be limited to such embodiments as the embodiments described herein are intended to be examples. On the contrary, the applicant’s teachings described and illustrated herein encompass various alternatives, modifications, and equivalents, without departing from the embodiments described herein, the general scope of which is defined in the appended claims.

Claims

1 . A method of operating a system for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the method comprising:
- receiving a request to create a rental NFT from the NFT of the digital media file, the NFT linked to an owner account;
- creating a terms document for the rental NFT;
- hashing the terms document, thereby producing a terms secure hash; and
- calling a smart contract to create the rental NFT, using the terms secure hash, the rental NFT being assigned a rental NFT ID upon creation.
2. The method of claim 1 , wherein the hashing the terms document is produced by a secure hashing algorithm (SHA) and the terms secure hash is a SHA hash.
3. The method of claim 1 , further comprising:
- reserving an amount of online currency from a renter account, the renter account comprising a renter wallet address; and
- transferring the amount of online currency to the owner account.
4. The method of claim 1 , further comprising:
- creating a rental NFT data record for the rental NFT, the rental NFT data record comprising at least one of: the rental NFT ID, a renter wallet address, an expiration date, or a checksum corresponding to the terms secure hash. The method of claim 1 , further comprising:
- issuing the rental NFT to a renter account. The method of claim 1 , further comprising:
- issuing the rental NFT to the owner account for transfer to a renter account. The method of claim 1 , further comprising:
- transferring the rental NFT to a renter account with restrictions preventing export of the rental NFT to other digital wallets; and
- returning the rental NFT after the determined period of time to the owner account. A method of operating a system for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the method comprising:
- receiving a request to transfer the NFT of the digital media file, the NFT linked to an owner account;
- creating a terms document for a transfer of the NFT for the determined period of time;
- hashing the terms document, thereby producing a terms secure hash; and
- transferring the NFT for the determined period of time to a renter account. The method of claim 8, further comprising:
- returning the NFT to the owner account after the determined period of time. A system for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the system comprising:
- a front-end computing device having a non-transitory computer-readable medium having stored thereon instructions to cause the front-end computing device to:
- receive a request to create a rental NFT from the NFT of the digital media file for a renter account, the NFT being linked to an owner account;
- send an issue rental NFT request to at least one back-end computing device; and
- upon receiving a notification from the at least one back-end computing device of completion of creation of the rental NFT, show a notification to the renter account of said completion; and
- the at least one back-end computing device having a non-transitory computer readable medium having stored thereon instructions to cause the at least one back- end computing device to:
- receive the issue rental NFT request;
- create terms for the rental NFT for the renter account;
- calculate a terms secure hash;
- create the rental NFT based at least in part on the terms secure hash; and
- send the notification to the front-end computing device of the completion of the creation of the rental NFT. The system of claim 10, wherein the NFT comprises an NFT ID and the renter account comprises a renter address. The system of claim 11 , wherein the issue rental NFT request comprises the NFT ID and an expiration date for the rental NFT. The system of claim 12, wherein the at least one back-end computing device creates the rental NFT by:
- sending a mint rental NFT instruction to a blockchain using the NFT ID, the renter address, the expiration date, and the terms secure hash;
- receiving a rental NFT ID from the blockchain; and
- storing a rental NFT data record for the rental NFT. A back-end computing device for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time to a front-end computing device, the back-end computing device having a non-transitory computer readable medium having stored thereon instructions to cause the back-end computing device to:
- receive an issue rental NFT request for a rental NFT to be created from the NFT of the digital media file for a renter account;
- create terms for the rental NFT for the renter account;
- calculate a terms secure hash;
- create the rental NFT based at least in part on the terms secure hash; and
- send a notification to the front-end computing device of completion of creation of the rental NFT. The back-end computing device of claim 14, wherein the NFT comprises an NFT ID and the renter account comprises a renter address. The back-end computing device of claim 15, wherein the issue rental NFT request comprises the NFT ID and an expiration date for the rental NFT. The back-end computing device of claim 16, wherein the back-end computing device creates the rental NFT by:
- sending a mint rental NFT instruction to a blockchain using the NFT ID, the renter address, the expiration date, and the terms secure hash;
- receiving a rental NFT ID from the blockchain; and
- storing a rental NFT data record for the rental NFT. A non-transitory computer-readable medium having stored thereon a smart contract for securely transferring a non-fungible token (NFT) of a digital media file for a determined period of time, the smart contract comprising:
- smart contract properties comprising:
- a rental NFT ID for rental of the NFT;
- a rental NFT data record comprising an owner address, an expiration date, and a rental terms hash;
- a rental NFT contract address; and
- a m inter address;
- smart contract functions comprising: - rental of the NFT, which creates a rental NFT;
- rental NFT data creation by the rental NFT ID; and
- contract execution for the rental NFT; and
- minter-only functions comprising:
- minting of the rental NFT to a renter address, the rental NFT comprising the expiration date and the rental terms hash. The non-transitory computer-readable medium of claim 18, wherein the smart contract properties further comprise:
- a mapping from an NFT ID for the NFT to the rental NFT ID; and
- a list of additional rental NFTs, each additional rental NFT comprising a corresponding rental NFT ID. The non-transitory computer-readable medium of claim 18, wherein the smart contract further comprises:
- ERC-1155 compatibility properties comprising:
- a uniform resource identifier (URI) associated with the rental NFT ID; and
- ERC-1155 compatibility functions comprising:
- retrieval of a balance associated with the rental NFT ID; and
- retrieval of metadata pointed to by the URI. A system for processing data related to a transfer of a non-fungible token (NFT) of a digital media file for a determined period of time that creates a rental NFT, the system comprising:
- an application configured to:
- receive, from a user device, a request for information on the rental NFT based on an associated rental NFT ID;
- send the rental NFT ID to a blockchain;
- receive a metadata URL from the blockchain;
- send the metadata URL to a rental meta provider; and
- generate a display of full NFT information to be presented to the user device based at least in part on receipt of rental NFT fields from the rental meta provider;
- the blockchain configured to:
- receive the rental NFT ID from the application;
- read the rental NFT based on the rental NFT ID;
- send the metadata URL obtained from the rental NFT to the application; and
- send the rental NFT fields associated with the rental NFT ID to the rental meta provider; and
- a rental meta provider configured to:
- receive the metadata URL from the application;
- send a read rental NFT request to the blockchain; and
- send the rental NFT fields to the application.
PCT/CA2022/051665 2021-11-12 2022-11-11 Systems and methods for providing a digital media rental platform WO2023082008A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202163278764P 2021-11-12 2021-11-12
US63/278,764 2021-11-12

Publications (1)

Publication Number Publication Date
WO2023082008A1 true WO2023082008A1 (en) 2023-05-19

Family

ID=86334798

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2022/051665 WO2023082008A1 (en) 2021-11-12 2022-11-11 Systems and methods for providing a digital media rental platform

Country Status (1)

Country Link
WO (1) WO2023082008A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117591229A (en) * 2024-01-10 2024-02-23 航粤智能电气股份有限公司 Device data viewing and displaying method and system based on gateway embedded Web

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020092900A2 (en) * 2018-11-02 2020-05-07 Verona Holdings Sezc A tokenization platform

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020092900A2 (en) * 2018-11-02 2020-05-07 Verona Holdings Sezc A tokenization platform

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "ERC-1155: Multi Token Standard", ETHEREUM, 17 June 2018 (2018-06-17), XP093067444, Retrieved from the Internet <URL:https://eips.ethereum.org/EIPS/eip-1155> [retrieved on 20230726] *
FOREST FANG: "ERC809/1201: Tokenizing Non-fungible Access", 2 September 2018 (2018-09-02), XP093067445, Retrieved from the Internet <URL:https://medium.com/coinmonks/erc809-1201-tokenizing-non-fungible-access-abdc5018c49> [retrieved on 20230726] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117591229A (en) * 2024-01-10 2024-02-23 航粤智能电气股份有限公司 Device data viewing and displaying method and system based on gateway embedded Web
CN117591229B (en) * 2024-01-10 2024-04-09 航粤智能电气股份有限公司 Device data viewing and displaying method and system based on gateway embedded Web

Similar Documents

Publication Publication Date Title
US8571992B2 (en) Methods and apparatus for title structure and management
US11687661B2 (en) Compartments
US20140358745A1 (en) Automated accounting method
US20050234860A1 (en) User agent for facilitating transactions in networks
US20210217006A1 (en) Accessing and Providing Distributed Applications
AU2019346668A1 (en) Smart contracts
US10516667B1 (en) Hidden compartments
EP3799401B1 (en) Systems and methods for facilitating authentication of emails sent by 3rd parties
CN115134108A (en) System for secure automated and accelerated resource allocation
US20220327509A1 (en) Systems and methods for mobile point-of-sale transactions
WO2023082008A1 (en) Systems and methods for providing a digital media rental platform
US20220398572A1 (en) Systems and methods for controlling transfers of digital assets
US20220351156A1 (en) Systems and methods for authentication using existing credential
US20240015030A1 (en) Methods and systems for authorizing transactions based on a derived public key
US20200279265A1 (en) Secure pin entry via moble device
US20220036298A1 (en) Systems and methods for obtaining information from a digital message
US11522862B2 (en) Systems and methods for a trusted entity to facilitate authentication of emails sent by 3rd parties
US20240013199A1 (en) Methods and systems for pre-validating token-based access control
Sutopo Unlocking the Future: Building Web3 Websites with Unstoppable Domain
CA2914639C (en) Unauthenticated access to artifacts in commerce networks
US20160063647A1 (en) System and Method for Providing Access to Member Content of a Dating Website to a Third Party Dating Website Provider
US20240020683A1 (en) Methods and systems for multiple gating verifications based on a blockchain wallet
US20230401571A1 (en) Maintaining blockchain state when performing non-blockchain commerce workflow
US20230289776A1 (en) Systems and methods of personalizing services associated with restaurants for providing a marketplace for facilitating transactions
US20160063646A1 (en) System and Method for Controlling Access to Member Content in a Dating Website

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22891246

Country of ref document: EP

Kind code of ref document: A1