CN111902814A - Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration and dissemination - Google Patents

Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration and dissemination Download PDF

Info

Publication number
CN111902814A
CN111902814A CN201980022330.1A CN201980022330A CN111902814A CN 111902814 A CN111902814 A CN 111902814A CN 201980022330 A CN201980022330 A CN 201980022330A CN 111902814 A CN111902814 A CN 111902814A
Authority
CN
China
Prior art keywords
document
link
token
account
documents
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN201980022330.1A
Other languages
Chinese (zh)
Inventor
C·成-邵兰德
A·H·阿里沙希
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sheldram Co
ShelterZoom Corp
Original Assignee
Sheldram Co
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
Priority to US201862777520P priority Critical
Priority to US62/777,520 priority
Application filed by Sheldram Co filed Critical Sheldram Co
Priority to PCT/US2019/065402 priority patent/WO2020123464A1/en
Publication of CN111902814A publication Critical patent/CN111902814A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891Revocation or update of secret information, e.g. encryption key update or rekeying
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Abstract

System, method, and computer program product embodiments for managing documents using blockchains are disclosed herein. The token server system may facilitate creation of documents. The token server system may encrypt and store an encrypted version of the document and create a link to the encrypted version of the document. The token server system may also create a cryptographic hash of the document and a document token for deposit in a digital wallet to specify ownership of the document. The token server system may publish the links and hashes to the blockchain using one or more intelligent contract functions. In some embodiments, the document may be a contract. The token server system may facilitate modifications to the document from other parties. The modification may represent a counter-offer or negotiation procedure.

Description

Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration and dissemination
Cross reference to related applications
The present application claims the benefit of U.S. provisional patent application No. 62/777,520 entitled "block Chain-Powered Industry Agnostic, One-Stop floor and Service markertplace, and New Demand-Driven and aggregated Value Chain," filed on 12, 10, 2018, which is hereby incorporated by reference in its entirety.
Technical Field
The field generally relates to document tokenization (tokenization) and modification using blockchain techniques, their application for creating, communicating, propagating and collaborating on confidential documents, their application for extending marketing and e-commerce web sites to more complex point-of-care and transaction-conducting venues, their application for converting supply-driven marketing patterns to demand-driven marketing patterns, and their application for creating ubiquitous markets, e-commerce or transaction platforms, for example, for real estate, automobiles, digital assets, tangible assets, or other goods and services.
Background
With the interaction of individuals, business enterprises, and governments, parties often exchange many documents for communication. These documents may include written requirements or may be contractual obligations. For example, exchange offers (offers) or invitation negotiations may initiate a process to perform a transaction, such as purchasing an asset, good or service. The parties may also exchange documents during the negotiation process. For example, the parties may exchange modifications to the agreement document or contract. These modifications may be sent via email and have changes tracked.
However, during negotiation, the parties may exchange many versions of the document with complex modifications. Tracking changes may become unmanageable. Furthermore, this negotiation process is more complicated in the case of multiple parties for a particular transaction. Encrypting and maintaining a real record of the modifications that parties may rely on to represent the parties' real desires and contractual positions can also be difficult when using unsecured techniques such as email.
The lack of auditable real-time negotiation and immediate contract exchange capabilities limits many marketplaces and e-commerce web sites to the area of purchasing or selling relatively low value products or to the products/services that the marketplaces may offer. In the traditional market, it is difficult to trade products and services on the fly via a complex contract structure.
Furthermore, online trading of goods and services is often limited within the marketplace or e-commerce platform, largely due to trust issues and technical limitations. This approach not only requires market participants (such as suppliers or consumers) to go through several setup steps, but also does not provide them with the flexibility to locate audiences they find more likely to purchase their products or provide them with the services they desire. In countries and regions where the online market is limited (limited), traders from those developing markets may be at a significant disadvantage.
In addition, common market transactions limit inventory to that listed by the seller. For example, a typical online transaction begins with an online retailer listing items for purchase. Similarly, an individual listing a property asset may list the availability of the asset for purchase or rental. Starting the transaction from a listing from the seller limits the inventory of goods, services, and/or real estate to those listed for sale. In addition, conventional online retailers often associate commercial establishments with consumers to allow consumers to make purchases from the commercial establishments. This inflexible mode prevents transactions from different parties with different roles. For example, these methods do not facilitate transactions between commercial enterprises or between consumer stores.
The listing (listing) model used in the real estate industry also prevents buyers from submitting quotes and initiating transactions themselves. The listing mode accounts for only about 2% of the real estate market, which precludes a large portion of the market. In addition, these real estate transactions typically require face-to-face interaction between the parties as well as extensive paperwork. This process is further complicated by the lack of technical ability to complete legally binding asset purchases, rentals (leases) and rentals (rentals) quickly and in a secure manner. Users are also faced with data security issues and concerns that important personal data may be hacked, mined, and acquired. This lack of security may prevent buyers and tenants (renters) from making online quotes and may prevent sellers from disclosing relevant information. In this manner, buyers and sellers may lack the ability and desire to provide online offers.
Further, because real estate transactions may be infrequent for buyers and sellers, buyers and sellers may rely heavily on and may have to use real estate agents and professionals. In some cases, the agent may perform negotiations using offers and counter-offers without transparency and auditability for the buyer and seller. The buyer and seller may not be aware of the profile of the transaction system. For example, a potential buyer may not be able to easily track the status of an offer, while a seller may not be able to easily track a received offer without talking to an agent. Similar problems may arise during the rental asset application process.
Disclosure of Invention
Disclosed herein are system, apparatus, device, method, and/or computer program product embodiments, and/or combinations and subcombinations thereof, for managing documents using blockchain techniques.
In embodiments, the token server system may use document tokens (tokens), digital wallets, and blockchains to facilitate and manage documents and document modifications. A token server system may generate a document token that represents ownership of a digital document and/or document modification permissions. The token server system may distribute document tokens to digital wallets specified by the document owner. The token server system may also encrypt the document, store an encrypted version of the document, generate a hash of the document, and create a link to the encrypted version of the document. The token server system may then store the hash and link on the blockchain using one or more intelligent contract functions. The token server system may also consume process tokens and/or cryptocurrency to perform block chain operations.
The token server system may also perform similar operations to manage modification of documents. For example, a party with permission to modify an original document may perform modifications as facilitated by a graphical user interface generated by the token server system, such as, for example, inserting, deleting, and/or modifying text. The token server system may then generate an individual document token corresponding to this modified document. The token server system may perform similar operations on the modified document, such as encrypting, hashing, and generating a link to the modified document. The token server system may also publish the hash and a link to an encrypted version of this modified document to the blockchain to save the modification. The token server system may also distribute document tokens to the owners of modified and original documents. In this way, the publication to the blockchain can preserve the modifications and provide trust that the modifications are intentional and undisturbed. Even when using a blockchain saving system, the token server system may provide each party with a graphical user interface to view and/or modify these documents in a human readable manner.
In some embodiments, the token server system may use a computer-implemented method for managing documents using blockchains. The token server system may receive a document creation request from a user account corresponding to a digital wallet. The token server system may facilitate creation of documents, encrypting documents, and storing encrypted versions of documents. The token server system may create a link to an encrypted version of the document and generate an encrypted hash of the document. The token server system may also generate a document token corresponding to the document and transmit the document token to the digital wallet. The token server system may publish the link and the cryptographic hash to the blockchain using one or more intelligent contract functions.
In some embodiments, the token server system may use a computer-implemented method for providing graphical user interface icons to generate documents. The token server system may generate a Graphical User Interface (GUI) including a first icon for initiating a link generation process. For example, the first icon may be a document action button, such as an "immediate quote" button as described further below. In response to receiving the interaction with the first icon, the token server system may generate an interface for attaching one or more documents to the link. As described further below, this linking may be referred to as a "1-Link" process. The token server system may receive, via the GUI, an indication to attach one or more documents to the link and generate a document token for each of the one or more documents. Document tokens may be deposited in a digital wallet to indicate ownership of each of one or more documents. The token server system may publish a blockchain link to one or more documents to the blockchain and generate a message corresponding to the link. The message may include a blockchain link and a second icon for initiating a document generation process.
In some embodiments, the token server system may use a computer-implemented method for managing documents generated from different account types. For example, different account types may represent a demand-driven value chain for a transaction. The token server system may receive a document creation request from a first account corresponding to a first digital wallet, where the first account corresponds to a first account type. The token server system may facilitate creation of a first document and create a document token corresponding to the first document. The token server system may send the document token to a first digital wallet using one or more intelligent contract functions and publish a hash of the first document and a link to an encrypted version of the first document to a blockchain. The token server system may then send the notification to a second account corresponding to a second digital wallet, where the second account corresponds to a second account type different from the first account type. The token server system may then facilitate the second account to create a second document.
Various embodiments may use these technical features to realize improvements in, for example, the real estate industry. The token server system may generate a GUI element, such as an "immediate quote" button, which may be used to generate a real estate quote that is saved on the blockchain. Other document action buttons may also be used to generate real estate offers, such as buttons displaying the words "rent immediately," apply immediately, "and/or" buy immediately. The seller may also use document action buttons (such as "immediate listing" and/or "immediate management" buttons) to create inventory and/or offer documents to offer for the asset for sale or lease. The token server system can facilitate a simplified document generation process and can also use blockchains to save hashes of generated documents to maintain confidentiality while taking advantage of the immutable nature of blockchains.
The token server system may also be used in this manner to manage real estate documents using blockchains. For example, the token server system may manage the modification of offers, counter-offers, and/or other negotiations of contract documents. The token server system may save these document modifications using a blockchain. In addition, the token server system may maintain other documents related to real estate transactions, such as, for example, loan approvals, inspection reports, real estate contracts, agreements, and/or other real estate documents. This management can track the progress and/or performance of real estate transactions as well as the documents used in the transactions.
In addition to document management, the token server system may also provide a "1-Link" process using its Graphical User Interface (GUI) alone or as part of another workflow, thereby providing Link management and/or document distribution. The links may represent documents that are held by the blockchain and may also provide access to other documents held by the blockchain. For example, a user may generate a link to a bid document to provide a bid for purchasing real estate. The link may be a document that includes links to other documents, such as loan approval documents. The user may then send this link as an offer to the owner of the asset. In some embodiments, the link may correspond to an embedded email message such that the email message includes links to other messages. In this manner, the 1-Link process may provide a simplified document sending process facilitated by the token server system.
The token server system may also use the technical features described in this disclosure to provide a demand driven value chain. The demand-driven value chain may allow parties with demand to generate documents in industries that traditionally utilize supply-driven trading markets. For example, the buyer may generate quotes and/or quote documents, the seller may generate sales documents, and/or the buyer agent may generate quote documents on behalf of its customers. For example, a conventional online retailer may list items and receive a purchase order from a buyer. In a demand-driven value chain, buyers can submit offers for goods, services, and/or real estate even if sellers have not provided listings. In this manner, the token server system may facilitate offers, counter-offers, and/or negotiations between parties independent of role or account type. The buyer and/or seller may initiate the transaction. Further, different parties and/or account types, such as business enterprises (businesses), stores, enterprises (enterprises), and/or consumers, may utilize a demand driven value chain to save initiation and/or facilitate transactions using blockchains. In this way, the token server system may support a decentralized market that uses blockchains to conduct transactions.
Drawings
The accompanying drawings are incorporated herein and form a part of the specification.
FIG. 1 depicts a block diagram of a document management environment, according to some embodiments.
FIG. 2 depicts a flowchart that illustrates a method for publishing documents to a blockchain in accordance with some embodiments.
FIG. 3A depicts a flow diagram that illustrates a method for partitioning document permissions, according to some embodiments.
FIG. 3B depicts a flow diagram that illustrates a method for specifying privacy settings for a document, according to some embodiments.
FIG. 4 depicts a flow diagram that illustrates a method for modifying a document, in accordance with some embodiments.
FIG. 5 depicts a flow diagram that illustrates a method for document negotiation, according to some embodiments.
FIG. 6 depicts a flowchart that illustrates a method for generating a graphical user interface for document negotiation, in accordance with some embodiments.
FIG. 7 depicts a block diagram of a graphical user interface including a segmented document portion, according to some embodiments.
FIG. 8A depicts a block diagram of a graphical user interface including document action buttons that may display the words "immediately quote," "immediately rent," "immediately apply," "immediately buy," "immediately hang up," and/or "immediately manage," according to some embodiments.
FIG. 8B depicts a block diagram of a graphical user interface for Link management and generation of a 1-Link process, according to some embodiments.
FIG. 8C depicts a block diagram of a graphical user interface for a message including a document action button and a document link, according to some embodiments.
FIG. 9 depicts a flowchart that illustrates a method for generating a message that includes a document action button and a document link, in accordance with some embodiments.
FIG. 10 depicts a block diagram of a document chain environment that provides a demand-driven value chain in accordance with some embodiments.
FIG. 11A depicts a flowchart that illustrates a method for role-based document generation, in accordance with some embodiments.
FIG. 11B depicts a flow diagram that illustrates a method for demand matching, in accordance with some embodiments.
FIG. 12 depicts an example computer system useful for implementing various embodiments.
In the drawings, like reference numbers generally indicate the same or similar elements. In addition, generally, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears.
Detailed Description
Provided herein are system, apparatus, device, method, and/or computer program product embodiments and/or combinations and subcombinations thereof for managing documents using blockchain techniques. Embodiments disclosed herein may facilitate the generation of documents by providing a front-end user interface while managing the documents using a connected, associated, or related back-end system that interfaces with the blockchain. The front end may be a user interface, such as a Graphical User Interface (GUI), that allows a user to manage document creation, permissions corresponding to documents, manage document modifications from different parties, and/or view documents linked to a blockchain in a human-readable manner.
The backend may manage documents using document token processes and a block link interface. As will be explained further below, a document token may be used to represent ownership and/or permissions corresponding to a document. The document token may also be used to track modifications of the document and/or segmentation permissions for different portions of the document. Additionally, a document token may be generated for each version of the modified document. These document tokens may represent ownership of the modifications and may be used with blockchains to provide evidence of document modifications. For example, on a public or private blockchain, modifications may be tracked as updated blocks and/or code executing on the blockchain using intelligent contract functionality.
Publication to the blockchain may provide trust and security that is immutable to modification. Further, the distributed ledger technique may provide a simplified way to track modifications and present those modifications to parties that transfer and/or edit a document. As will be described further below, the embodiments described herein also provide faster and more efficient back-end processing for blockchain operations. In particular, the use of asynchronous calls to the blockchain may provide increased speed and may avoid delays associated with blockchain transaction times.
Embodiments described herein may also be used in contract negotiations to provide a simplified contract platform for tracking and viewing offers and counter-offers. For example, a user may generate an offer to purchase goods, services, assets, insurance, and/or other contractual obligations. These offers may be represented as documents. The system described below may facilitate the generation of these offers and the publication of these offers to the blockchain. The immutability of the blockchain may preserve these quotations. In addition, the confidentiality of sensitive information may be maintained using encryption when making such offers. By managing these quotation documents using blockchains, parties to the contract can present quotations that can be relied upon by other parties in a more trusted manner.
Further, counter offers may also be managed in a similar manner. For example, the counter-offer may be a modified offer that may be represented as a document with a corresponding document token. These counter offers may also be managed in a similar manner using blockchains. By managing offers and counter-offers, the document platform can simplify the negotiation process, which preserves confidentiality while maintaining high trust. Parties using the document platform may negotiate terms of the contract and/or provide a digital signature indicative of acceptance of the offer. In this way, the document platform can facilitate execution of the contract. In some embodiments, this negotiation and execution may be performed in a decentralized manner and/or to provide a decentralized marketplace for peer-to-peer transactions.
The document action buttons and/or 1-Link processes may also be implemented using the system described below to simplify document generation, document delivery, and document propagation processes. In some embodiments, this simplification may be particularly useful in documents saved using blockchains. Document action buttons, such as "quote immediately," "rent immediately," "apply immediately," "buy immediately," "hang up immediately," and/or "manage immediately" buttons, may allow a user to quickly generate a document using fewer GUI interactions. The reduction in interaction may help reduce wasted computing resources or unnecessary network navigation. Further, the document action button may help reduce network traffic due to the reduced number of interactions. Similarly, the 1-Link process can deliver blockchain saved documents in a similar and compact manner. A user accessing the link may access the documents saved in the various blockchains and/or may generate another document using the document action button. In this manner, the 1-Link process may also reduce the number of user interactions and computational transactions, while also reducing network traffic.
Various embodiments of these features will now be discussed with reference to the corresponding figures.
FIG. 1 depicts a block diagram of a document management environment 100 according to some embodiments. The document management environment 100 may include a token server system 110, a blockchain 120, a user interface 130, and/or a user device 140. The token server system 110 may include one or more servers and/or databases that may instantiate the user interfaces 130A-130B of the user devices 140A-140B. The token server system 110 may include object storage, web service interfaces, storage for internet applications, and/or cloud computing and/or storage. In some embodiments, the token server system 110 may use a peer-to-peer network and/or protocol to store and/or share data in a distributed file system. For example, the token server system 110 may use content addressing to uniquely identify files in the global namespace for the network user device 140. In some embodiments, the token server system 110 may use the interplanetary file system (IPFS) protocol and/or protocols such as AmazonAnd the like.
The token server system 110 may include an interface to a blockchain 120. Blockchain 120 may be a private or public blockchain. The token server system 110 may use one or more intelligent contract functions to interface with the blockchain 120 and/or publish data to the blockchain 120. The smart contract functionality may include protocols for digitally facilitating, verifying, and/or carrying out transactions. The transaction may be traceable and irreversible. As will be described further below, token server system 110 may interface with blockchain 120 to store data representing documents and/or modifications to documents. This data may include a cryptographic hash of the document and/or a link to a human-readable representation of the document.
In some embodiments, the token server system 110 may also manage processing tokens for interacting with the blockchain 120. For example, the token server system 110 may manage digital wallet information related to cryptocurrency. The token server system 110 may use and/or consume digital currency to perform transactions to the blockchain 120. For example, the token server system 110 may also manage fuel, transaction, and/or mine excavation fees for conducting transactions, performing blockchain contracts, and/or posting data on blockchains 120 in a block. As will be explained further below, the token server system 110 may also manage document tokens that may represent ownership and/or permission of documents and/or document modifications. The token server system 110 may facilitate publication of document data to the blockchain 120 and/or may remove processing tokens from accounts corresponding to digital wallets to perform the publication.
The token server system 110 may provide a front end user interface 130 to allow a user to create, manage, edit, and/or modify documents. The user interface 130 may be a Graphical User Interface (GUI) that may be accessed and/or displayed on the user device 140. The user device 140 may be a computer, laptop, tablet, telephone, and/or other device that may access the internet and/or display the user interface 130. The user interface 130 may include an Application Programming Interface (API) to provide communication between the user device 140 and the token server system 110.
As will be explained further below, the token server system 110 may provide a front-end GUI including GUI elements that allow a user to create documents, modify documents, manage document permissions, generate links and/or messages corresponding to documents, manage document modifications from other parties, manage digital wallets, manage user account information and/or account roles, and/or other document interactions. In some embodiments, the token server system 110 may facilitate the incorporation of GUI elements into web pages not managed by the token server system 110 to allow users to access operations provided by the token server system 110. For example, the token server system 110 may provide a web widget that may be incorporated, integrated, or overlaid on other web pages to provide similar document functionality.
For example, the token server system 110 may generate icons and/or buttons that allow a user to create a document. The user may interact with the icons or buttons on the GUI via selection, pressing, or clicking. In response to this interaction, the token server system 110 may generate a document creation GUI element that is displayed on the GUI. The document creation GUI element may be a fillable form and/or may include an editable text box. In some embodiments, the document creation GUI element may include an option to attach a data file stored locally on the user device 140. The token server system 110 may enable the generation of documents that may be encrypted and/or stored on blockchain 120.
In an embodiment, the token server system 110 may provide a GUI element that allows a user to create an offer document to initiate a contract negotiation process. For example, the GUI element may be a button that displays the text "immediate quote" on a web page. The user may be browsing a web page that displays different goods, services, assets, insurance and/or other contractual obligations, and may interact with the buttons to generate and submit a quote document. The offer document may be a fillable form that may allow the user to enter personal information and/or information such as an offer to purchase the asset. The user may also specify conditions and/or obligations to generate a treaty document for the owner of the asset. The token server system 110 may pass this offer document to the owner of the asset to notify the owner of the pending offer. For example, the token server system 110 may provide a notification to the user device 140 corresponding to the user account associated with the owner via email or via a push notification.
To manage the management and/or storage of offer documents, the token server system 110 may use a blockchain 120. As will be explained further below, the token server system 110 may store and/or create a link to an encrypted version of the offer document. The token server system 110 may also generate a cryptographic hash of the document. Using this information, as well as other information such as owner identification and/or other metadata, the token server system 110 may create a document token corresponding to a bid document. The document tokens may represent ownership of the offer documents and/or may be sent to a digital wallet corresponding to the offeror. The token server system 110 may use the document token in future operations to determine access and/or modification permissions. In some embodiments, the token server system 110 may send the document tokens to a seller's digital wallet to allow the seller to access and/or modify the document. For example, the document token may indicate that the seller may modify the document with a digital signature to accept the contract offer.
The token server system 110 may manage the offer document using the block chain 120. For example, the token server system 110 may use intelligent contract functionality to publish a cryptographic hash of the document and/or a link to a cryptographic version of the document. The document may be encrypted using a key corresponding to the vendor. Publishing document data onto blockchain 120 may preserve the trustworthiness of the document as well as the legitimacy of the quote and/or content. For example, the immutable nature of blockchain 120 can prevent unauthorized document modification or tampering. In addition, the cryptographic hash may maintain privacy and may prevent other users of blockchain 120 from viewing confidential information. For example, the user device 140C may be utilizing a separate user interface 130C to access the blockchain 120 separately from the token server system 110. Encryption may prevent user device 140C from viewing confidential information stored on blockchain 120.
After communicating the notification of the offer document to the seller, the seller may access the token server system 110 using the user device 140 and corresponding user interface 130 to access the offer document. In particular, the token server system 110 may confirm that the digital wallet corresponding to the seller includes document tokens corresponding to offer documents. The token server system 110 may also identify permissions corresponding to this document token, such as permissions to view, access, and/or modify offer documents. The token server system 110 may also verify that the offer document has not been altered by verifying the cryptographic hash stored on the blockchain 120. The token server system 110 may also provide the seller with a link to an encrypted version of the offer document. The seller or the token server system 110 may then decrypt the encrypted document using a digital signature key corresponding to the seller. If the seller accepts the offer presented in the offer document, the seller may provide a digital signature to confirm the acceptance. This digital signature may also be transmitted (keyed to) the vendor with key encryption to provide verification and additional confidence that the signature is legitimate and protected from tampering or tampering. In some embodiments, the digital signature may also be reflected in a human-readable portion of the quotation document.
In an embodiment, the digital signature may be a modification to the quotation document. The token server system 110 may manage this modification in a manner similar to the generation of a document such that the modified document may be saved using blockchain 120. For example, the signed document may be encrypted and stored as a modified version of the bid document. The token server system 110 may generate a corresponding link to this encrypted version of the signed document and/or generate an encrypted hash of the signed document. The token server system 110 may create a document token corresponding to the signed document and may send this document token to a digital wallet corresponding to the seller and/or the offeror. The token server system 110 may publish the hash and/or a link to an encrypted version of the signed document to the blockchain 120. Similarly, encryption may be performed using a key corresponding to the offeror to maintain confidentiality. In this manner, the token server system 110 may facilitate the offer and acceptance of contracts using a document management process that utilizes blockchain 120.
Similar to this offer and acceptance process, the token server system 110 may manage the negotiation process via document modification. This negotiation process may include one or more rounds of offers and counter-offers between the parties. Parties may use the token server system 110 to digitally negotiate and modify different portions of a document. For example, the parties may negotiate different contract terms and/or obligations. The tokenization process may be used by the token server system 110 to manage different portions of a document and/or to manage counter offers.
For example, the seller may receive an offer document from an offeror. The seller may not agree with one or more contractual terms provided in the offer document, such as, for example, an offer price for purchasing the asset. In this case, the seller may perform the modification to the offer document via the user interface 130. The seller may modify the text of the offer document. In some embodiments, the seller may modify elements of the fillable form to modify the offer document.
The token server system 110 may manage this modification in a manner similar to the generation of a document such that the modified document may be saved using blockchain 120. The modified document may be encrypted and stored as a modified version of the offer document. The token server system 110 may generate a corresponding link to this encrypted version of the modified document and/or generate an encrypted hash of the modified document. The token server system 110 may create a document token corresponding to the modified document and may send this document token to a digital wallet corresponding to the seller and/or the offeror. The token server system 110 may publish the hash and/or a link to an encrypted version of the modified document to the blockchain 120. Similarly, encryption may be performed using a key corresponding to the offeror to maintain confidentiality. In this manner, the token server system 110 may facilitate negotiation of contracts using a document management process that utilizes blockchain 120. The token server system 110 may also continue to manage additional modifications and/or counter-offers from any party (the abort party) in this manner.
In some embodiments, the token server system 110 may save the negotiation and/or counter-offer locally prior to publishing the document to the blockchain 120. For example, where publishing documents to blockchain 120 may consume digital currency or fuel, parties may choose to perform negotiations and/or counter-offers using memory local or accessible to token server system 110. The token server system 110 may post the agreed-upon document to the blockchain 120 after the negotiation and document modification have been completed. For example, the token server system 110 may identify matching terms and/or digital signatures indicating acceptance prior to publishing the document to the blockchain 120.
Although the token server system 110 has been described as managing offer documents from an offeror to a seller, the token server system 110 may also manage document transmissions from different contractual roles. For example, the seller may generate an offer document to the buyer. In this case, the buying room may accept the offer and/or may provide a counter-offer. Similarly, parties can negotiate services and/or other contract exchanges using the token server system 110 and blockchain 120. The document management provided by the token server system 110 may provide confidentiality in document exchanges and provide confidence in the immutable nature of the blockchain 120 to represent party standpoints. Similarly, the token server system 110 may be used to manage documents, such as rental agreements, leases, real estate documents, auctions, and/or other documents.
As will be explained further below, the document management processes used by the token server system 110 may also facilitate multi-party document exchanges, negotiations and/or transactions. For example, in a real estate transaction, in addition to a buyer and a seller, other parties (such as an agent of the buyer, an agent of the seller, an attorney, a mortgage borrower, and/or other parties) may also participate in the transaction. The token server system 110 may manage these different account roles and/or may provide permissions to different users depending on their roles in the transaction. For example, a mortgage borrower may be required to provide proof that the buyer is entitled and/or approved to loan a certain amount. The mortgage borrower may provide this document to the token server system 110. In some embodiments, the token server system 110 may provide a mortgage borrower with a form that may be a modifiable document, where the mortgage borrower may include information such as an amount that is eligible. This document may be verified and/or stored on blockchain 120 using the mortgage borrower's digital signature. Further, if a buyer submits multiple offers to different sellers, the buyer may be able to use this document in more than one transaction.
In some embodiments, the master document may be compiled and different portions assigned to different roles of the transaction. For example, a mortgage borrower may modify a portion of a main document, while an agent for the seller may be assigned to modify a different portion. The token server system 110 may manage and/or oversee these modifications to ensure that the corresponding character is performing its specified modifications without tampering from other individuals. In addition, these modifications may be saved on blockchain 120. In this manner, parties may be responsible for modifications that may be trusted and that are related to the particular account and/or account role that provides the document modification.
The token server system 110 may manage different levels of confidentiality associated with documents. For example, a user generating a document may designate the document as open, semi-confidential, or confidential. This designation may be stored as metadata corresponding to the document. For example, the privacy designation may be a visibility flag. In some embodiments, the privacy designation may correspond to a listing of goods, services, and/or real estate for sale. For example, the privacy designation may correspond to a list of real estate assets for sale or lease. Confidentiality may facilitate the real estate owner's decision to list assets using documents that may be maintained by blockchain 120 while privately considering quotes. For example, a celebrity may not wish to publicly list assets and/or list asset identification information, but may still wish to consider potential offers. Based on the user's privacy designations, the token server system 110 may expose the manifest documents to the desired agents, buyers, and/or lessees. For example, the token server system 110 may send document tokens to the user with corresponding permissions to interact with the manifest document, as will be described further below.
In some embodiments, the token server system 110 may manage these lists to help match parties to the lists. For example, an "open" designation may indicate that the manifest document may be publicly available for matching by the token server system 110. An "open" designation may allow public access and/or browsing of listings. The buyer or lessee may send a bid request and/or bid document to the token server system 110, and the token server system 110 may attempt to match the request with the manifest document. For example, the buyer may indicate a particular price, geographic area, house specifications (such as bedrooms and bathrooms), and/or other requirements for the asset. If the buyer provided a price and/or requirement meets and/or matches the conditions identified for the manifest, the token server system 110 may provide an "open" manifest document to the buyer.
The "semi-private" designation may indicate that the listing document may be revealed when the buyer and/or lessee has submitted an offer and the token server system 110 has identified that the listing document corresponds to the offer. Unlike "open" documents, "semi-secret" documents may not be searchable. In some embodiments, a "semi-secret" document may only be searched through certain fields, e.g., the exact address is kept secret, but the zip code is searchable. The "semi-secret" document may include additional conditions before being revealed to the user. For example, a "semi-secret" manifest document may include price conditions. If the buyer provides a sufficient quote price, the token server system 110 may disclose the listing document. Similarly, a user may designate a manifest document as "semi-confidential" and available only to certain individuals (such as a particular agent). For buyers who provide requests and/or offers with different conditions, the token server system 110 may facilitate a demand-driven value chain, as will be described further below.
The designation of "secret" may indicate that the token server system 110 may reveal the manifest document after the real estate asset owner has evaluated the request or quote and has provided a positive confirmation of the disclosure of the manifest document. This "secret" designation may indicate a need for confidentiality, which may include input from the listing party prior to providing identifying information to the bidder. Using these designations, token server system 110 can manage confidentiality with respect to the manifest documents published on blockchain 120 while still facilitating the preservation of the manifest documents. The increased confidentiality may also allow additional participation in the registered assets.
In addition to the manifest document, the token server system 110 may facilitate the creation of contract documents. To illustrate an example embodiment, a user Ted may wish to sell a house using the token server system 110. Ted may create a contract document using the token server system 110. Ted may also have real estate agents that assist in selling the premises. Ted may provide the token server system 110 with user information for the real estate agent and provide the agent with the right to manage portions of the contract document. The agent may then search the buyer and/or provide a link to the potential buyer to provide the buyer with access to the treaty document. The buyer access link may cause the token server system 110 to create a copy of the contract document that includes the buyer's rights and obligations.
In some cases, the buyer may not agree to the terms in the treaty document and may initiate the negotiation process. For example, the buyer may edit the text of the treaty document, such as rights and obligations and/or final price. The buyer may leave comments on some conditions of the treaty document. The negotiation process may be managed and/or performed by the agent depending on the permissions granted to the agent. In some embodiments, the seller and/or agent may negotiate with multiple buyers simultaneously. The negotiation process may continue until the terms and/or content of the treaty document match the seller and buyer. Ted may view the counter-offer and/or select a buyer to execute the treaty document by providing a digital signature over the agreed treaty document modifications. Ted may save a copy of the contract document from the token server system 110 locally on the user device 140. This copy may be a PDF document, for example. Ted may also access blockchain 120 using a blockchain browser to view transaction information held by token server system 110.
A business enterprise or enterprise may use the token server system 110 to manage documents. For example, John may be the owner of a company and may create a workflow that may specify a department and/or account role corresponding to a company employee. The employee may use the token server system 110 to generate documents, edit documents, send documents to external parties, and/or negotiate with such external parties. The outside party may be an outside individual, supplier, contractor, and/or other party outside of John's company. Using the token server system 110 and blockchain 120, John may verify the authenticity of documents created by the employee and/or received from external parties.
The token server system 110 may manage multiparty contracts. For example, the token server system 110 may manage one-to-many, many-to-one, and/or many-to-many multiparty contracts. In an example embodiment, the user Sam may wish to enter into a contract as an owner. Sam may create a set of contract documents with negotiation intent using the token server system 110. Sam may specify the portion of each treaty document in which terms may be altered. These portions may represent fields (fields) of the treaty document.
Sam may be an employee working at a company with a financial supervisor or a secondary financial supervisor. Sam may send the contract document set to a secondary financial supervisor, who may review, sign, and/or edit the contract document. The secondary finance director may return the treaty document to Sam for further editing. In the case where the secondary finance host signs the contract document, the token server system 110 may generate a notification (such as an email) to Sam. Sam may then use the token server system 110 to send one or more links to the contract document to one or more counterparties. These transaction partners may be outside the company.
The counterparty may create an offer that may include a set of variable fields. For example, the counterparty may choose to edit the terms of the treaty document and/or not edit the terms. In the case where the field values are different, the negotiation process managed by the token server system 110 may be started. The owner and/or counterparty of the treaty document may proceed to change the value of the fields. With each change, the other party may receive a notification from the token server system 110 and/or may accept or decline the offer. The treaty document may be agreed upon via acceptance from one party and/or until each field includes the same value from each party. The parties may apply digital signatures to the contracting documents to ultimately determine contractual obligations.
In some embodiments, Sam may use different versions of the treaty document for different counterparties. The token server system 110 may provide a GUI for Sam to manage these different treaty documents and/or links corresponding to the treaty documents. If the counterparty agrees to its corresponding terms as provided by Sam, Sam may sign up with the counterparty and/or complete the negotiation process.
The token server system 110 may also manage templates for documents and/or contract documents. The law firm can create these templates. The token server system 110 may provide these templates for purchase and use by the user. These templates may include rental and/or rental documents. For example, Sara may wish to rent her apartment. She can use the token server system 110 to identify standard rental agreement document templates. Sara may use digital currency and/or use process token purchase templates, which will be described further below. Sara can edit some of the conditions listed in the template. The token server system 110 may generate a link that provides access to rental agreement documents and/or other information provided by Sara about the apartment. Three potential tenants may access the link in response to the Sara created document. Sara may communicate with each of them and may finalize and execute a contract with one of them using a digital signature provided to the token server system 110.
Although the token server system 110 may provide template contracts or documents, the token server system 110 may also collect statistical information about modifications to the templates. For example, the token server system 110 may identify modification trends. The law firm may analyze these statistics to identify frequently used contracts and/or modifications. For example, many users may modify a particular passage of a rental agreement. The law firm may modify the template to improve the usability of the template.
The token server system 110 may manage documents other than contract documents. For example, James may wish to use a single electronic medical card that may include medical records and/or insurance information. James may create a health care card from a template provided by the token server system 110. James may specify access to a portion of the card for the doctor while James visits the doctor. For example, James may provide a doctor with permission to modify the medical record portion of the health card document. Using the link provided by the token server system 110, the doctor can enter new data and/or provide a prescription in the medical record via the modified document. The doctor may also provide a uniquely identifiable digital signature for the modification, which may be saved using blockchain 120. At the pharmacy, James may present a signed prescription that the pharmacist may verify using the token server system 110 and/or blockchain 120. In this way James can avoid the problem of losing or damaging the physical health card. The token server system 110 may provide reliable document management services where modifications may be recorded on the blockchain 120.
The token server system 110 may manage and/or maintain copyright information and/or other date sensitive documents. For example, Alice may have written a scientific article. To save her rights, Alice uses the token server system 110 to save the document using the blockchain 120. Based on the immutable nature of blockchain 120, Alice can confirm the copyright date and time and/or rely on blockchain 120 as evidence.
In some embodiments, the token server system 110 may manage documents related to records and/or certificates. For example, a user may use token server system 110 to manage and/or save documents using blockchain 120. These documents may include certificates such as birth certificates, marriage certificates, driver licenses, university scholarship certificates, and/or other documents that a user may consider as official. Saving on blockchain 120 may indicate that the document is authentic. For example, a university, government agency, and/or other organization may maintain documents on blockchain 120 that are relevant to the user to confirm that the authenticity of the documents and/or that a particular certificate was indeed issued by the organization. The token server system 110 may manage and/or send document tokens related to these certificates to a digital wallet corresponding to the user. The user may be able to use the token server system 110 to track, view, and/or manage documents over the user's lifecycle. The token server system 110 may provide a repository for these documents while maintaining confidentiality and providing verifiable proof of authenticity.
Other functions and/or operations of the token server system 110 will now be further described with reference to other figures of the present disclosure.
Fig. 2 depicts a flow diagram that illustrates a method 200 for publishing documents to blockchain 120 in accordance with some embodiments. The method 200 will be described with reference to fig. 1; however, the method 200 is not limited to this example embodiment.
In embodiments, the token server system 110 may facilitate the creation of documents and the saving of documents on blockchain 120. Although the method 200 is described with reference to the token server system 110, the method 200 may be performed on any computing device, such as, for example, the computer system described with reference to figure 12 and/or processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 2.
At 205, the token server system 110 may receive a document creation request from a user account corresponding to a digital wallet. The token server system 110 may interface with the user device 140 via the user interface 130 to receive document creation requests. For example, the token server system 110 may provide a Graphical User Interface (GUI) to be displayed on one of the user devices 140. The user device 140 may interact with the GUI via API interaction. In some embodiments, the token server system 110 may manage user accounts and/or user profiles. A user may log into the token server system 110 to generate a document creation request. The token server system 110 may manage digital wallet information corresponding to a user account. The digital wallet may represent an encrypted wallet and/or may include a corresponding encrypted currency balance.
In some embodiments, the document creation request may be initiated from an interaction with a web widget on a web page. For example, the website may include a widget that may trigger the token server system 110 to facilitate document creation. In some embodiments, a website listing real estate information may include this widget and may allow a user to generate an offer document to purchase an asset. Where the widget is implemented in a web page, creation of the document may request provision of electronic wallet information to provide the electronic transaction. As will be explained further below, the widget may be a document action button. The widgets and/or action buttons may be located on web pages that are not managed by the token server system 110. For example, the website may be managed by a third party system and/or administrator, and the token server system 110 may facilitate document creation in response to user interaction with the widget. The widget may be a plug-in to a website.
At 210, the token server system 110 may facilitate creation of a document. The token server system 110 may generate GUI elements to be displayed on the user device 140 to allow the user to generate documents. For example, a GUI element may be a fillable form that allows a user to enter text input. In some embodiments, the fillable form may include a field indicating the requested text data. The user may enter text data to specify the content of the document. The GUI element may be a pop-up template or form on a web page currently being viewed on the user device 140. The GUI element may prompt the user to provide information such as, for example, digital wallet information and/or information for providing offers to another party. The user may provide an identification of another party to which the document is to be communicated.
In some embodiments, the user may be viewing an inventory of assets on a web page and/or considering purchasing goods or items. The seller of the asset may have provided some initial identifying information to list the asset for sale. After interacting with the GUI elements, the token server system 110 may generate a template form to allow the user to enter contract terms to generate an offer to purchase the asset. The token server system 110 may identify the recipient of the created document based on the manifest and the identifying information previously provided by the seller.
Although a user may generate a document via typed text and/or a fillable form, the creation of a document may also allow a user to attach other documents. For example, the user may include a link to a document stored in the cloud storage system to be included in the generated document.
The token server system 110 may also facilitate the creation of documents by providing a library of templates for selection by a user. For example, the templates may be different contracts. The templates may include an interest book, a privacy agreement, a lease, a real estate contract, and/or other contracts. The token server system 110 may facilitate the creation of documents by providing access to a library of templates. The user may select the template and may provide additional information and/or modify default terms to match the expected contract offer. In some embodiments, these templates may be offered for sale for user access. For example, a law firm may create a template of standardized contract documents that may be incorporated into a library for sale and purchase by system users.
At 215, the token server system 110 may encrypt and/or store the encrypted version of the document. For example, the token server system 110 may encrypt the document using a digital key corresponding to the user that generated the document and/or the user intended to receive the document. The token server system 110 may facilitate distribution of keys to recipients of the document. In some embodiments, the recipient of the document may be an asset vendor who has listed assets for sale on a web page. In this way, the seller may have previously provided the cryptographic key to the token server system 110 to generate the manifest. The token server system 110 may use this key to encrypt documents generated by the bidder. In some embodiments, the bidder may provide an encryption key and the token server system 110 may encrypt the document using the bidder's key. The token server system 110 may then provide this key to the recipient for use in decrypting the document.
In some embodiments, the token server system 110 may store an encrypted version of the document in a database. The database may be network accessible and may be accessed using the link generated at 220. At 220, the token server system 110 may create a link to the encrypted version of the document. The link may be a Uniform Resource Locator (URL) or other web address that identifies the location where the encrypted document is stored. Since the stored document is encrypted, the discovery of the link may still remain confidential due to the encrypted nature of the document.
At 225, the token server system 110 may generate a hash of the document. The hash may be a cryptographic hash of the document. This cryptographic hash may be a one-way hash function and/or may be used on blockchain 120 to provide block verification. This may provide a decentralized configuration for blockchain 120 using a workholding algorithm or other type of blockchain certification algorithm or method. The hash may also provide proof that the document has not undergone tampering and is a true representation of the document.
At 230, the token server system 110 may create a document token corresponding to the document. The document token may represent ownership of the document. In some embodiments, the token server system 110 may use a document token to segment different permissions related to a document. The document token may be a type of digital token, an encrypted token, or a virtual currency that may be used with a digital wallet to specify ownership. However, document tokens may differ from cryptocurrency in that document tokens may not be interchangeable and instead may be unique for each document created. In some embodiments, the permission may correspond to a security designation associated with the document, as previously described. The security designation may be metadata corresponding to the document token.
At 235, the token server system 110 may send or transfer the document token to a digital wallet. For example, the token server system 110 may send the document token to a digital wallet of the bidder that created the document. In some embodiments, the document token may be sent to the party receiving the document. As will be described further below, one or more document tokens may be generated and/or propagated to segment different portions of a document with different permissions.
At 240, the token server system 110 may publish a hash of the document and/or a link to an encrypted version of the document to the blockchain 120 using one or more intelligent contract functions. Publishing a hash of the document and/or a link to an encrypted version of the document may save the document and indicate a version of the document that may be trusted to be untampered. The publishing of these elements may also preserve the contractual position of a party. In embodiments where the method 200 is used to generate an initial offer, the token server system 110 may save this offer at 240 to provide confidence to the party receiving the offer. In embodiments where the method 200 is used to save an agreed-upon contract that has been negotiated offline, the token server system 110 may publish a hash and link to save the agreed-upon contract.
In an embodiment, the token server system 110 may consume the processing token to publish the document to the blockchain 120. The processing token may be an interchangeable token asset that may be used as a processing fee for performing the blockchain operation. The processing token may be a cryptocurrency or a digital currency. In some embodiments, the processing token may be a utility token. The digital wallet may include a balance of processing tokens for performing blockchain 120 transactions. Token server system 110 may publish data to blockchain 120 using process tokens.
To publish data to the blockchain 120, the token server system 110 may use one or more intelligent contract functions. The intelligent contract function may include a set of computer code executing on blockchain 120 or on top of blockchain 120. The smart contract functionality may include a set of rules agreed upon by the parties involved. Upon execution, if these predefined rule sets are satisfied, the smart contract will execute itself to produce an agreed upon output. The intelligent contract code may allow for decentralized automation by facilitating, validating, and enforcing the conditions of the underlying protocol. The intelligent contract function may be a line of automatically executable code stored on blockchain 120 that includes predetermined rules. When the rules are satisfied, the code may execute itself and provide a corresponding output. In an embodiment, the terms of a contract document may be programmed using one or more intelligent contract functions. In this manner, blockchain 120 may perform contractual terms of the document.
FIG. 3A depicts a flow diagram that illustrates a method 300A for partitioning document permissions, according to some embodiments. The method 300A will be described with reference to fig. 1; however, the method 300A is not limited to this example embodiment.
In embodiments, the token server system 110 may facilitate the partitioning of document licenses. Although the method 300A is described with reference to the token server system 110, the method 300A may be performed on any computing device, such as, for example, the computer system described with reference to fig. 12 and/or processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 3A.
At 305, the token server system 110 may receive a request to access an encrypted document. The user may have created a document using the method 200 as described with reference to fig. 2. The token server system 110 may have previously provided a document token corresponding to a document to the creator of the document and/or the recipient of the document. The token server system 110 may receive the request based on access to a previously generated link to an encrypted version of the document.
At 310, the token server system 110 may decrypt the encrypted document in response to identifying the corresponding first document token in the first digital wallet associated with the request. For example, a first digital wallet may correspond to an owner of a document. In some embodiments, the owner of the document may have granted permission to modify permission to the recipient of the document. In this case, the first digital wallet may correspond to a recipient of the document.
At 315, the token server system 110 may generate a Graphical User Interface (GUI) that displays the decrypted document. The token server system 110 may decrypt the document using a key provided by the owner of the first digital wallet. The GUI may display the document in a human-readable form.
At 320, the token server system 110 may identify a first portion of the document and associate a first permission with the first portion. The first portion of the document may be a text portion such as a body, header information, a signature panel, and/or other portions of the document. The first permission may include a read and/or write permission. These permissions may be specified based on user identification, user account type, user role, and/or other identifying information. In this way, the user may indicate that a particular user may modify a particular portion. Similarly, the user may indicate that a particular portion may be read-only. The user may perform this designation using the GUI and/or user interface 130. In some embodiments, the permission may correspond to a security designation associated with the document as previously described. For example, the secret designation may be an "open," "semi-secret," or "secret" designation. The security designation may be metadata corresponding to the document token. This secret assignment will be further described with reference to fig. 3B.
At 325, the token server system 110 can identify a second portion of the document and associate a second permission with the second portion. The second portion of the document may be different from the first portion and the second license may be different from the first license. In this way, the owner of the document or another owner given permission specifying permissions may parse the document into different portions and specify different users to interact with the different portions. In some embodiments, the second permission may correspond to a secret designation.
At 330, the token server system 110 may send or transfer the document token to a second digital wallet according to the first permission to provide interaction with the first portion. At 335, the token server system 110 may send or transfer the document token to a third digital wallet according to the second license to provide interaction with the second portion. In this way, different users may interact with different portions of the document based on the distributed document tokens. This tokenization may provide permissions and facilitate the partitioning of documents into portions with different access permissions. The permissions may be managed by the token server system 110, while the document tokens may be disseminated to individuals who are granted permissions to interact with the documents. Tokenization may also help provide specific modification permissions, such as signing authority for a particular individual. Because the document tokens may represent ownership and/or permissions to interact with particular portions of the document, parties may believe that the modifications provided in those corresponding portions are from the appropriate parties. Further, the owner of the document may segment the document for multi-party use. For example, when a transaction involves multiple parties, the document owner may segment each portion of the document for each party. In some embodiments, parties may be able to view the document, but only be able to modify the portion specified by their corresponding permissions.
In some embodiments, this division of documents may correspond to multiple documents. For example, a document may be a large document with multiple segments or parts for different parties. This larger document may be divided into separate document parts. Document tokens corresponding to the larger documents may be distributed to related parties.
FIG. 3B depicts a flow diagram that illustrates a method 300B for specifying privacy settings for a document, according to some embodiments. The method 300B will be described with reference to fig. 1; however, the method 300B is not limited to this example embodiment.
In an embodiment, the token server system 110 may facilitate the setting of privacy designations related to documents. For example, a privacy designation may be "open", "semi-secret", or "secret". Although the method 300B is described with reference to the token server system 110, the method 300B may be performed on any computing device, such as, for example, the computer system described with reference to fig. 12 and/or processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 3B.
At 340, the token server system 110 may receive a document creation request from a user account corresponding to the digital wallet. The receipt of the document creation request may be similar to the request described at 205 with reference to FIG. 2. At 345, the token server system 110 may facilitate creation of the first document. The creation of the first document may be performed in a similar manner as 210 described with reference to fig. 2. At 350, the token server system 110 may create a document token corresponding to the first document. A document token may be created in a similar manner as 230 described with reference to figure 2. At 355, the token server system 110 may send or transfer the document token to a digital wallet. The token server system 110 may send document tokens in a manner similar to 235 as described with reference to figure 2. At 360, the token server system 110 may publish the hash of the first document and the link to the encrypted version of the first document to the blockchain using one or more intelligent contract functions. The token server system 110 may execute 215, 220, 225, and/or 240 as described with reference to figure 2 to execute 360.
At 365, the token server system 110 can receive a security designation for the first document indicating conditions for disclosing the first document to a requesting party or party attempting to access the first document. As previously described, a user may provide a privacy designation to designate a document as open, semi-confidential, or confidential. The token server system 110 may receive this designation via user interaction with a Graphical User Interface (GUI) that allows a user to view and/or interact with the document. For example, to provide the designation, the user may use a drop down menu and/or select a GUI element. As previously explained, an "open" designation may indicate that the manifest document may be publicly available for matching by the token server system 110. An "open" designation may allow public access and/or browsing of listings. The "semi-private" designation may indicate that the listing document may be revealed when the buyer and/or lessee has submitted an offer and the token server system 110 has identified that the listing document corresponds to the offer. Unlike "open" documents, "semi-secret" documents may not be searchable. In some embodiments, a "semi-secret" document may only be searchable by certain fields, for example, the exact address is kept secret, but the zip code is searchable. A "semi-secret" document may include additional conditions before being revealed to a user. The designation of "secret" may indicate that the token server system 110 may reveal the manifest document after the real estate asset owner has evaluated the request or quote and has provided a positive confirmation of the disclosure of the manifest document. This "secret" designation may indicate a desire for confidentiality, which may include input from the listing party prior to providing the identifying information to the bidder.
At 370, the token server system 110 may associate the privacy designation with the first document via the document metadata. This designation may be stored as metadata corresponding to the document. For example, the privacy designation may be a visibility flag.
At 375, the token server system 110 may receive a second document from the requestor that satisfies the condition. The second file may be a quotation document. For example, the second document may indicate an offer to purchase a good, service, real estate asset, and/or other offers. The second document may indicate a particular price, geographic area, house specifications (such as bedrooms and bathrooms), and/or other requirements for the asset. The token server system 110 may receive this second document and/or help facilitate generation of the second document in response to a requestor interacting with a document action button, as will be described further below.
At 380, the token server system 110 may disclose the first document to the requestor in response to receiving the second document and determining that the condition is satisfied. Depending on the privacy designation, the token server system 110 may perform a process to reveal the first document to the requesting party. For example, the token server system 110 may display a first document on the GUI for viewing by the requesting party. If the privacy designation is "open," the token server system 110 may allow the first document to be viewed and/or public access to the first document. In some embodiments, the token server system 110 may provide an "open" document to the requestor if the conditions identified in the second document match the content from the first document.
The "semi-secret" designation may indicate that the first document may be revealed when the requestor has submitted the second document and the token server system 110 has recognized that the contents of the second document satisfy the conditions corresponding to the first document. A "semi-secret" document may include additional conditions before being revealed to a user. For example, a "semi-secret" document may be a listing of real estate assets that may include price conditions. If the buyer provides a sufficient bid price in the second document, the token server system 110 may disclose the listing document. Similarly, a user may designate a manifest document as "semi-confidential" and available only to certain individuals (such as a particular agent). The token server system 110 receives an indication of the status of the requestor as a second document to provide access to the first document.
The designation of "secret" may indicate that the token server system 110 may reveal the first document after the party that generated the first document has evaluated the second document and has provided a positive confirmation to reveal the first document. This "secret" designation may indicate a need for confidentiality, which may include input from the party that generated the first document prior to providing the identifying information to the requestor. Using these designations, token server system 110 can manage confidentiality with respect to documents published on blockchain 120 while still facilitating the preservation of the documents.
FIG. 4 depicts a flow diagram that illustrates a method 400 for modifying a document, in accordance with some embodiments. The method 400 will be described with reference to fig. 1; however, the method 400 is not limited to this example embodiment.
In an embodiment, the token server system 110 may facilitate modification of previously generated documents. Although the method 400 is described with reference to the token server system 110, the method 400 may be performed on any computing device, such as, for example, the computer system described with reference to figure 12 and/or processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 4.
At 405, the token server system 110 may receive a request to access an encrypted document. Similar to 305, requests may be received from link accesses and/or from user accounts accessing encrypted documents via a user account profile managed by the token server system 110.
At 410, the token server system 110 decrypts the encrypted document in response to identifying a corresponding first document token in the digital wallet associated with the request, wherein the first document token indicates a permission to modify a portion of the document. Similar to 310, the token server system 110 can identify the presence of a document token in a digital wallet. For example, the user may have previously received this document token. The document token may have provided the user with permission to modify a portion of the document. For example, in embodiments where a user can sign a treaty document, the document portion can allow the user to apply a digital signature to the signature section as a modification of the document.
At 415, the token server system 110 may generate a Graphical User Interface (GUI) that displays the decrypted document. The token server system 110 may decrypt the document using a key provided by the owner of the digital wallet. The GUI may display the document in a human-readable form.
At 420, the token server system 110 may receive a modification of a portion of a document corresponding to the first document token to generate a modified document. In some embodiments, the user may be able to view the document, but may be limited to modifying the portion corresponding to the document token. For example, the portion may be a signature panel of the contract. In some embodiments, the portion may be a particular term of the contract. For example, one or more portions, such as rights, obligations, warranties, contracts, and/or other document terms, may be negotiated. The modification may be an edit to the terms and may be received via a GUI displaying the decrypted document. After modifying the document, the user may choose to retain and/or save the modification. The token server system 110 may perform this modification locally, but the modification may also be saved using the blockchain 120. To save the modifications using blockchain 120, token server system 110 may perform operations similar to the generation of a document.
In particular, the token server system 110 may encrypt and store an encrypted version of the modified document at 425; a link to the encrypted version of the modified document may be created at 430; and a hash of the modified document may be created at 435. Similar to the elements described with reference to fig. 2, the token server system 110 may perform these operations to generate a modified version of the document while complying with the immutable nature of the blockchain 120. In some embodiments, the generation of the modified document may be a document separate from the original document. The modified document may be saved on the blockchain in a subsequent block, which may represent an updated version or counter-offer of the document. In this way, changes to the document can be tracked while preserving the benefits provided from publishing updates to the blockchain.
At 440, the token server system 110 may create a second document token corresponding to the modified document. At 445, the token server system 110 may send or transfer the second document token to a digital wallet. At 450, the token server system 110 may publish the hash of the modified document and the link to the encrypted version of the modified document to the blockchain using one or more intelligent contract functions. The creation of the second document token, the transmission of the second document token, and the publishing of the hash and/or link may be similar to the corresponding elements described with reference to figure 2.
Using similar operations for creation of documents and modification of documents, the token server system 110 may streamline and/or simplify the document modification process. Utilizing similar operations may facilitate a more compact process with less computational overhead, rather than maintaining different protocols for document creation and modification. Even if many complex modifications and/or negotiations are being performed by multiple parties, the token server system 110 may manage and maintain these modifications in a simplified manner. Furthermore, the token server system 110 may perform this management asynchronously to avoid long transaction times when writing to the blockchain 120.
FIG. 5 depicts a flow diagram that illustrates a method 500 for document negotiation, according to some embodiments. The method 500 will be described with reference to fig. 1; however, the method 500 is not limited to this example embodiment.
In an embodiment, the token server system 110 may facilitate negotiation of document terms between different parties. Method 500 may use elements of methods 200, 300A, 300B, and 400, but may provide further details showing interaction between multiple digital wallets. Although the method 500 is described with reference to the token server system 110, the method 500 may be performed on any computing device, such as, for example, the computer system described with reference to figure 12 and/or processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 5.
At 505, the token server system 110 may receive an interaction with a GUI element corresponding to a first account to generate a document to be sent to a second account. The GUI element may be, for example, a button or widget on a web page. For example, the user of the second account may have listed assets for sale, and the GUI element may be an "immediate quote" button that allows the user of the first account to provide a quote document to the second account. The user of the first account may provide information and/or text to generate the document in the manner described above.
At 510, the token server system 110 may generate a first document token corresponding to a document. This document token may represent ownership of the document by the first account. At 515, the token server system 110 may publish the hash of the document and the link to the encrypted version of the document to the blockchain using one or more intelligent contract functions. This process may be performed in a manner similar to that described with reference to fig. 2.
At 520, the token server system 110 may send or transfer the first document token to a first digital wallet corresponding to a first account and a second digital wallet corresponding to a second account. The transmission of the first document token to each account may indicate that each party may access and/or modify the document. This configuration may allow the second account to modify the document during the negotiation process.
At 525, the token server system 110 may receive a request from a second account to access a document. For example, the second account may have accessed a link to an encrypted version of the document and/or may have provided login credentials to a website and/or cloud platform managed by the token server system 110 to access the document. The token server system 110 may utilize the user interface 130 to generate a GUI for the user of the second account to be displayed on the user device 140.
At 530, the token server system 110 may receive a modification to the document from the second account to generate a modified document. For example, a user corresponding to the second account may modify the document using a GUI displayed on the user device 140. This modification may indicate a disagreement with the terms in the document. In some embodiments, the modification may include adding, inserting, deleting, replacing, and/or other document modifications performed by the user of the second account. In some embodiments, the GUI may display the document in a web browser, and the user may provide the modifications to the token server system 110 via the web browser.
At 535, the token server system 110 may create a second document token corresponding to the modified document. Similar to the second document token described with reference to figure 4, the second document token may indicate a modified document while still saving the original document corresponding to the first document token. The second document token may be used to specify ownership and/or modification permissions as well as to save modification records.
At 540, the token server system 110 may send or transfer the second document token to the first digital wallet and the second digital wallet. In this way, both the original bidder and the counter-bidder may access and/or modify the modified document. At 545, the token server system 110 may publish the hash of the modified document and/or the link to the encrypted version of the modified document to the blockchain 120 using one or more intelligent contract functions. Similar to the original document, the token server system 110 may save the modified document in a similar manner in view of the immutable nature of the blockchain 120. Similar to the other processes described above, the token server system 110 may consume process tokens to publish data onto the blockchain 120.
In some embodiments, the method 500 may be used for further counter-offers. For example, the parties may continue to negotiate and may continue to modify terms until the parties agree. In this case, the parties may specify that the token server system 110 not publish the document or modified document onto the blockchain 120 until the agreement is reached. In some embodiments, for each counter-offer and/or modification returned, publication of the modified document may occur.
FIG. 6 depicts a flow diagram that illustrates a method 600 for generating a Graphical User Interface (GUI) for document negotiation, according to some embodiments. The method 600 will be described with reference to fig. 1; however, the method 600 is not limited to this example embodiment.
In an embodiment, the token server system 110 may generate a GUI to display contract negotiations for parties to the transaction. An example embodiment of this GUI is depicted in fig. 7. Although the method 600 is described with reference to the token server system 110, the method 600 may be performed on any computing device, such as, for example, the computer system described with reference to figure 12 and/or processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 6.
At 605, the token server system 110 may generate a first GUI displaying a first set of segmented portions of a document and a second set of segmented portions of the document, where the document corresponds to a document link stored on the blockchain 120. An example embodiment of this first GUI display is depicted in fig. 7. For example, the first and second sets of partitions may correspond to the same document. The first set may display edits and/or modifications performed by a first user account, while the second set may display edits and/or modifications performed by a second user account. These edits and/or modifications may have been saved on blockchain 120.
At 610, the token server system 110 may generate a second GUI that displays the first set of segmented portions of the document and the second set of segmented portions of the document. The second GUI may be displayed on the user device 140, which may be different from the user device 140 displaying the first GUI. For example, a party receiving an offer may view a first GUI, while a party receiving the offer may view a second GUI. The segmented portions of the document may represent modifications and/or edits provided by any party.
At 615, the token server system 110 may receive, via the second GUI, a modification to the partition in the first set of partitions. For example, a party receiving the quotation document may view the quotation document via the second GUI. The offer document may be divided into different sections. The party may then modify one of the parts. For example, the modification may be a modification to the contract term and/or other text or objects of the contract document. The modifications may include additions, insertions, deletions, substitutions, and/or other document modifications performed by the user of the second account. If the first set of segments is displayed to the left of the second set of segments, the user may enter these modifications into these left-hand segments.
At 620, the token server system 110 may update the second set of segmented portions of the document of the first GUI to display the modification. This updated view may depict counter-offers made to the first party by the second party. For example, a first party may view a first GUI and may view modifications proposed by a second party in a second set of segmented portions. In this way, the first party may view their own modifications in the first set of segments while viewing the modifications of the second party in the second set of segments. This GUI display may also provide side-by-side scrolling to allow the user to view the segmented portions and compare the modified portions. The first GUI may also emphasize the modification using techniques such as highlighting, color, font size, and/or other GUI elements to indicate different modified terms between the two sets of segmented portions. In this way, the GUI may provide a view of saved blockchain modifications and human-readable text. This GUI modification may allow the user to easily compare offers and/or counter-offers and modify the document during the negotiation process to reach agreed-upon terms.
FIG. 7 depicts a block diagram of a Graphical User Interface (GUI)700 including segmented document portions 712A-718A, 712B-718B, according to some embodiments. The token server system 110 may generate a GUI 700 to be displayed on the user device 140 using the user interface 130. As described with reference to fig. 6, GUI 700 may display documents 710A, 710B having corresponding segments. Document 710A may include the same content as document 710B, but may differ in displaying the modifications proposed by the parties. For example, the segmented portion 712A of the document 710A may include the same content as the segmented portion 712B of the document 710B. In some embodiments, the documents 710A, 710B may be contracts and may include different portions corresponding to the partitions 712A-718A, 712B-718B. For example, the partitions 716A and 716B may correspond to guarantees granted by a vendor. Segments 714A and 716B may include quote prices. In this manner, GUI 700 may depict two versions of a contract for a user to make and/or view modifications.
A first party viewing GUI 700 may provide a modification to document 710A. For example, the user may edit the segment 714A to change the price of the offer. The segments may include editable text and/or fillable forms for providing information. For a first party viewing GUI 700, document 710B may include modifications generated by a second party. For example, document 710B may include a counter-offer regarding contract terms. GUI 700 may display both the modifications generated by the first and second parties to allow comparison of the modifications.
In some embodiments, the token server system 110 may generate a version of the GUI 700 for the second party. The token server system 110 may flip the position of the documents 710A and 710B. For example, the second party may edit the document 710A displayed on the user device 140 corresponding to the second user. This modification may be manifest as a modification of the document 710B for the first user to view the GUI 700 on the user device 140 corresponding to the first user. In this way, independent of the user role in the transaction, the user may perform document modifications in document 710A while viewing edits of other parties in document 710B.
Although two documents 710A, 710B may be depicted in fig. 7, other versions of the document 710 may be displayed in a multi-party transaction and/or negotiation. For example, GUI 700 may depict multiple versions of a document from different parties with different modifications.
GUI 700 may provide a human-readable interface for interacting with documents managed via document tokens and blockchains. As explained above, the document and/or the modified document may correspond to a document token with corresponding permissions. For example, parties may be limited to modifying only certain segments. In addition, modifications can be saved and/or published to the blockchain to save modification records. In this manner, GUI 700 may provide a way to view and/or interact with documents managed using blockchain 120.
In addition to displaying the split portions, the GUI 700 may also include one or more navigation interfaces 720A, 720B. The navigation interface 720 may provide document management GUI elements provided by the token server system 110. For example, the navigation interface 720 may include GUI icons or buttons for identifying, viewing, and/or selecting contracts. For example, the user may be negotiating multiple contracts, and the navigation interface 720 may allow the user to select and view different contracts.
The navigation interface 720 may include a library link to allow the user to create a new document or contract. In some embodiments, a user may generate a document and provide customized segmentation to portions of the document. Similar to the partitioning described above with reference to fig. 3A, the user may specify permissions corresponding to the portions. In some embodiments, the token server system 110 may provide alternative documents and/or contract templates with pre-formed content and/or segmentation. The user may select and/or modify these templates.
The navigation interfaces 720A, 720B may also include messaging interfaces, task lists for users, management screens for managing digital wallets, and/or other GUI elements that may be used during document modification and/or negotiation processes.
FIG. 8A depicts a block diagram of a Graphical User Interface (GUI)800A including a document action button 850A, according to some embodiments. Document action button 850A may display the words "quote immediately," "rent immediately," "apply immediately," "buy immediately," "listing immediately," "manage immediately," and/or other words that indicate the generation of a document.
GUI 800A may be a web browser and/or may include a web page that can include widgets and/or GUI buttons or icons. GUI 800A may include an address input section 810A for specifying a website. The user may view GUI 800A using a web browser on user device 140. GUI 800A may be accessed by a user viewing a web page, such as, for example, a web page listing real estate for sale and/or for lease. The user can search for houses to purchase and/or lease and can view information related to the real estate asset using GUI 800A. In addition, GUI 800A may include a document action button 850A, which document action button 850A may initiate a document generation process, and will be described further below. In some embodiments, a website listing real estate assets can implement document action button 850A on GUI 800A to facilitate user access to the document generation process provided by token server system 110. In some embodiments, the token server system 110 may generate the GUI 800A and/or manage a website related to real estate transactions.
GUI 800A may display image 820A, textual data 830A, and/or additional details 840A. Additional details 840 may include additional textual information that describes and/or may be in a different format than textual data 830A. In some embodiments, the user may enter and/or navigate to a web page listing assets for sale. In this case, the image 820A may depict an image of an asset, the textual data 830A may include high-level details related to the asset, and the additional details 840A may include paragraph descriptions and/or other points related to the asset. The user can view this information to learn about the asset.
GUI 800A may include a document action button 850A. The document action button 850A may be a GUI element that may provide an interface with the token server system 110. For example, the document action button 850A may be a widget embedded in a web page displaying an asset manifest. In some embodiments, document action button 850A may display the words "quote immediately," "rent immediately," "apply immediately," "buy immediately," and/or indicate to the user other terms by which the document may be generated. In some embodiments, the document action button 850A may be used for other documents, such as to list assets using "immediately hang" and/or "immediately manage" options.
Upon interacting with the document action button 850A via selecting, pressing, and/or clicking, the widget may generate a call to the token server system 110 to provide a document generation process. For example, the token server system 110 may provide fillable forms and/or templates that may be displayed on the GUI 800A for the user to draft documents and/or provide information into the templates. The token server system 110 may provide an overlay on the GUI 800A for the user to enter this information. After entering the requested information, the token server system 110 may send an offer to the intended recipient. The token server system 110 may also generate corresponding document tokens and/or save documents on the blockchain 120.
As such, GUI 800A provides various technical improvements. GUI 800A may provide a simplified way for document generation to save generated documents using blockchain 120. Document action buttons 850A (which may be "quote immediately," "rent immediately," "apply immediately," "buy immediately," "hang up immediately," and/or "manage immediately" buttons) may allow a user to quickly generate a document with less GUI interaction. The reduction in interactions may help reduce wasted computing resources on unnecessary network navigation. Further, the document action button 850A may help reduce network traffic as the number of interactions is reduced.
As previously described, the document action button 850A may be a widget and/or a plug-in embedded in a third-party website or webpage. The document action button 850A may be located on a web page that is not managed by the token server system 110. For example, the website may be managed by a third party system and/or administrator, while the token server system 110 may facilitate document creation in response to user interaction with the document action button 850A. The document action button 850A may be used to generate documents relating to transactions for goods, services, and/or real estate. In addition, the document action button 850A may initiate the document tokenization and blockchain saving processes facilitated by the token server system 110. In some embodiments, the document action button 850A may be used to facilitate a trading process that may include an offer and a counter-offer. The transaction process may include bidding, negotiation, acceptance and/or closing. Via interaction with the document action button 850A, a user may generate documents and/or transactions via a decentralized marketplace.
FIG. 8B depicts a block diagram of a Graphical User Interface (GUI)800B for Link management and generation of a 1-Link process, according to some embodiments. The user may use GUI 800B to manage links and/or documents sent to other parties. For example, the buyer may use the link to provide an offer to purchase real estate. GUI 800B may allow the purchaser to manage different offers. Similarly, the seller may manage sales offers using GUI 800B. These offer documents may also be managed via links. Parties may use GUI 800B to generate documents and/or links corresponding to documents and to manage recipients of the documents and/or links.
The user may use the GUI 800B to manage links, such as, for example, links to an inventory of assets and/or links to other documents and/or offer documents that the user creates using the token server system 110. Links may represent documents that may be saved by blockchain 120, which may also include access to other documents saved by blockchain 120. In this way, the link may be a delivery system for other blockchain based documents, and the link itself may be a blockchain based document.
These links may be included in a message that may also represent another type of document that may be managed via blockchain 120. Method 900, described with reference to fig. 9, describes an example embodiment of generating a message including a link to a blockchain managed document. In some embodiments, generating a link may include generating a link to a document managed by the token server system 110 using the blockchain 120. For example, a link may provide access to one or more documents saved using blockchain 120.
When generating multiple offer messages and/or sending multiple documents, the user may access the token server system 110 and/or use the GUI 800B. GUI 800B may arrange one or more links into rows and columns to manage the links. The link may be a link to a web page and/or an electronic message having a corresponding document. For example, fig. 8C may depict a messaging interface that may be accessed from a link.
Returning to GUI 800B, the user may use GUI 800B to create links to documents and/or create documents with corresponding links. For example, the user may interact with a create link button 870B displayed on GUI 800B. This document may allow the user to enter text and/or may be a fillable form. Create link button 870B may be an icon and/or button that allows the user to create a new link. The creation of a new link may include fillable forms, wizards, and/or other prompts to allow the user to specify information for the different fields associated with the link. GUI 800B may also include management of received links.
GUI 800B may include several fields for organizing the generated links. For example, GUI 800B may include a selection field 810B, an address field 820B, a recipient field 830B, a role field 840B, a details sent field 850B, and/or an interaction button 860B. Selection field 810B may allow a user to select one or more links. This selection may allow for management of multiple links. The address field 820B may include details regarding the physical address of the asset. The address field 820B may be used when the link and corresponding document relate to real estate. Recipient field 830B may include one or more identifiers for delivering a link. For example, the recipient field may include one or more email addresses. The role field 840B may list the roles corresponding to the recipient and/or the user generating the link. For example, in a real estate transaction, role field 840B can include roles such as "buyer," "seller," "agent," "depositor," and/or other roles. The sent details field 850B may display one or more entries related to the transmission of the link. For example, the sent details field 850B may indicate whether the link was sent or whether the link was drafted. In some embodiments, the sent details field 850B may also indicate the sender of the link. Interaction button 860B may include a GUI element that allows a user to interact with the link. For example, the interaction button 860B may include the ability to edit a link and/or a document corresponding to the link, copy the link, view messages related to the link, and/or other link operations. In some embodiments, the token server system 110 may facilitate messages related to documents, and the "view messages" interaction button 860B may allow the user to view the corresponding messages. Although these fields have been described, GUI 800B may use other fields to organize the links and/or corresponding documents.
In this manner, GUI 800B may provide a simplified way for link creation and/or link management to pass documents saved by the blockchain. A user creating a Link via create Link button 870B may access the 1-Link process to quickly generate a blockchain saved document associated with the Link, which may include links to other blockchain saved documents. In this manner, the use of GUI 800B and/or the 1-Link process may provide for the generation of linked and blockchain saved documents while also reducing the number of user interactions and computational transactions while also reducing network traffic.
The 1-Link process may provide a decentralized process for purchasing, selling, and/or trading goods and/or services online. In some embodiments, the user may avoid using a virtual marketplace or an existing e-commerce website. The user may perform peer-to-peer transactions, including offers and counter-offers, using the 1-Link procedure. The links generated from the 1-Link process may be used, sent, and/or propagated in electronic communications including, but not limited to, text messages, emails, websites, social media, chat rooms, instant messages, and/or voice transmissions. In some embodiments, the link may be transmitted via an analog process, such as a handwritten message.
Links may be integrated into and/or integrated with other processes, including calendar and scheduling applications, language translation processes, payment platforms, messaging and negotiation processes, chat room applications, video and/or audio chat and/or advertising or display elements. In some embodiments, the user may select a form of communication that may be an electronic trace of communication that is legally binding. The link may also provide the user with the ability to provide payment using legal currency, digital currency, and/or other forms of currency.
Existing e-commerce websites require users to use an online marketplace for users to sell, purchase, rent, and trade goods and services in exchange for either economically compensated or physical goods and services. Buyers and sellers use these existing platforms to advertise, purchase, trade, index, initiate, and/or finalize exchanges. The host market may also charge the user a premium for a commission on market use. The hosted marketplace may also restrict users from following the specifications of the marketplace when promoting terms and conditions for goods and/or transactions for sale. The hosted marketplace may limit marketing by users to audiences who they find more likely to purchase their products or provide desired services to them.
The 1-Link process may provide a method for facilitating transactions in a decentralized manner. The 1-Link process may democratize transactions between users, which may allow users to perform transactions while avoiding an online marketplace. For example, sellers, buyers, and/or traders may exchange goods and services directly using the 1-Link process. The user may provide a link to a document listing that may be quoted for goods and/or services for sale to potential buyers so that parties may perform transactions directly while avoiding the use of an online marketplace.
As previously described, the seller may use the 1-Link process to generate a Link for transmission to the buyer. In this way, the seller may avoid using the virtual marketplace as a host (host) for promoting goods or services for sale. Further, the seller may avoid multiple steps involved in the virtual marketplace transaction. Using the 1-Link process, the seller can generate a Link, custom email, and/or other communication method that embeds a Link to send to the buyer. The message and/or link may display a web page, mini-website, and/or social media page that may display goods and/or services for sale, details related to the sales offer, and/or other transaction information such as, for example, pricing, contact information, payment options, and/or other detailed information. The buyer may purchase a product or service using the link and/or negotiate with the seller to modify the terms of sale. As will be described further below, the buyer may generate a document for negotiation using a document action button accessible via a message or link.
In some embodiments, the buyer may use the 1-Link process to generate links and/or messages for purchasing goods and/or services. The buyer may use the 1-Link process even if the seller has not previously created a Link prior to the transaction. The 1-Link process may be used by a buyer when searching for and/or identifying a product or service and creating a Link describing a desired purchase. In some embodiments, the link may describe the goods or services the buyer is searching for. The buyer may send this link to the seller, which may allow the seller to quote the goods and/or services that may satisfy the buyer's request. Parties may then perform transactions via the 1-Link process that may generate corresponding document tokens. Examples of this embodiment are further described below with reference to FIGS. 10, 11A, and 11B, which describe a demand driven value chain.
The user may also use the 1-Link process to trade goods and/or services. At the time of the transaction, the parties may rely on the negotiation and/or counter-offer elements of the 1-Link process. For example, the parties may modify the terms of the document, including what goods and/or services are being transacted.
In this manner, the 1-Link process may provide a personalized market that may democratize and/or decentralize the trading process. The 1-Link process may facilitate marketing development (lead generation), marketing, promotion, sale, purchase, trade-making, and/or trading goods and/or services without relying on a third party sales platform. For developing countries where the online marketplace may be limited, the 1-Link process may provide a way to conduct transactions that may not previously exist. Furthermore, the 1-Link process may provide convenience, efficiency, cost savings, and/or trust to the user via blockchain based document preservation. The 1-Link procedure may also be used in other contexts, such as, for example, election campaigns. The 1-Link process may provide a way for a donor to contribute money to a campaign.
FIG. 8C illustrates a block diagram of a Graphical User Interface (GUI)800C of a message 810C including a document action button 850C and a document link 840C, according to some embodiments. GUI800C may include an email message that may be generated using the link management element of GUI 800B. Message 810C may represent a blockchain-based document that may include links to other blockchain-based documents via document link 840C.
The user may view GUI800C in preparation for sending a bid document to a party. For example, a real estate agent or seller can prepare message 810C in preparation for transmission to a potential buyer or interested buyer of the real estate. The inclusion of the document action button 850C in the message 810C may allow a potential buyer to generate a bid document and provide a bid to a seller in response to the message 810C. In addition, the potential buyer may also access the document link 840C to access documents stored on the blockchain 120, which may facilitate the buyer's decision-making process and/or the bid document generation process. Although a seller/buyer example is described, GUI800C may also be used in the reverse context of a buyer sending message 810C, in a tenant/landlord context, and/or in a buyer/seller context for goods and/or services.
To generate the message 810C, the user may be guided to enter one or more links by a prompt provided by the token server system 110. For example, the user may have listed assets and corresponding addresses on a web page. This address may be requested via address display 830C and compiled into GUI 800C. The user may interact with, select, press, and/or click on address display 830C to navigate to a web page listing assets. The message 810C may also include a text element 820C, which text element 820C may include text entered by the user. For example, the text may be a personalized message that provides an introduction to the document linked in message 810C.
Message 810C may include document link 840C. Document link 840C may include a link to a stored document that allows a user to download the document. In some embodiments, document link 840C may represent other documents maintained by blockchain 120. These documents may be tokenized in the manner described above. In this way, access may be made based on restricted encryption, but a user accessing document link 840C may access the document based on permissions provided by the document token. In an embodiment, the bank may send a link to the new customer, which may contain multiple confidential documents for viewing and signing. The bank may grant permission exclusively to the customer as the only party allowed to view and/or modify the document. A client can securely access a document by viewing and signing the document using an encryption key. By using the token server system 110, a bank may avoid security concerns during document exchanges and may ensure that documents are securely delivered to appropriate persons. In some embodiments, law enforcement agencies may also use links for collaboration to share documents with internal and external stakeholders for case investigation or criminal instruction control.
The message 810C may also include a document action button 850C. The document action button 850C may be similar to the document action button 850A as described with reference to fig. 8A. A document action button 850C may be embedded in the message 810C and may allow a user to generate a document via a call to the token server system 110. After interacting with document action button 850C, a web browser may be opened and a user may generate a document to be stored on blockchain 120. This document may be, for example, an offer to purchase the asset.
The message 810C may be accessed via a link generated by the token server system 110 and/or an electronic message communicated via the token server system 110. Message 810C may represent a document that may also be stored on blockchain 120. This document may include links to other documents managed by the token server system 110 and saved using the blockchain 120. The message 810C may also include a document action button 850C that allows the user to generate a new document. In this manner, message 810C may show a document held by blockchain 120 within another document held by blockchain 120. Other message 810C may show that the document saved by blockchain 120 provides the user with the ability to generate a document saved by another blockchain. As previously described, the inclusion of the document action button 850C may simplify the document generation process and may allow a user to quickly generate a blockchain saved document with fewer navigational interactions. The reduction in interactions may help reduce wasted computing resources on unnecessary network navigation. Further, the document action button 850C may help reduce network traffic as the number of interactions is reduced.
In some embodiments, message 810C may be used for security documents and/or messaging. For example, the message 810C may not include the document action button 850C. A user may create an email document and store the document token passed through the 1-Link process. The recipient may open the email and generate a second document token to sign the email. The signature may be a confirmation of receipt of the email and/or an agreement to the email content that may require signing. The generation of the second document token may indicate that the recipient has viewed the document, which may provide auditability and/or traceability. In this manner, message 810C may be used as a secure document delivery mechanism.
FIG. 9 depicts a flowchart that illustrates a method 900 for generating a message that includes a document action button and a document link, in accordance with some embodiments. The method 900 will be described with reference to fig. 1; however, method 900 is not limited to this example embodiment. Method 900 may be an embodiment of a 1-Link process.
In an embodiment, the token server system 110 may generate links and/or messages that allow a user to access documents saved by a blockchain and the document generation process. Although the method 900 is described with reference to the token server system 110, the method 900 may be performed on any computing device, such as, for example, the computer system described with reference to figure 12 and/or processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 9.
At 905, the token server system 110 may generate a GUI including a first icon to initiate a link generation process. The GUI may be, for example, GUI 800B. The link generation process may include one or more displays requesting information and/or link information from the user, which may be compiled into messages and/or other data structures that may allow the user to access the documents held by the blockchain.
At 910, the token server system 110 may receive an interaction with a first icon. This first icon interaction may initiate a document creation process similar to that described above. This document may be saved on blockchain 120 using techniques described above, which may include encryption, hashing, and/or document tokenization.
At 915, the token server system 110 can generate an interface for attaching one or more documents to the link. For example, the interface may be one or more displays that request information and/or request a user to upload a document. In some embodiments, the interface may be a fillable form. In some embodiments, the one or more documents may be personal documents that include confidential information. For example, in a real estate transaction, a document may relate to a user's credit record or loan approval amount.
At 920, the token server system 110 may receive an indication to attach one or more documents to the link via the GUI. In some embodiments, the user may specify the document location by providing a link to the document. Based on the information provided, the token server system 110 may identify the document. As explained previously, a user may upload one or more documents.
At 925, the token server system 110 may generate a document token for each of one or more documents. The token server system 110 may generate document tokens, as described above. For example, the token server system 110 may apply encryption, hashing, document tokenization, and/or digital wallet deposit. The token server system 110 may encrypt and store an encrypted version of each of one or more documents; creating a blockchain link to an encrypted version of each of the one or more documents; and generate a cryptographic hash of each of the one or more documents.
At 930, token server system 110 may post a blockchain link to one or more documents to blockchain 120. The publishing blockchain link may save the attached document. Similar to the process described above, blockchain links may be linked to encrypted versions of documents to maintain confidentiality.
At 935, the token server system 110 may generate a message corresponding to the link, where the message includes the blockchain link and a second icon for initiating a document generation process to generate a response document to be published on the blockchain 120. The message may be, for example, an email message as described in GUI 800C. The block chain link may be a document link 840C and the second icon may be a document action button 850C.
As previously described, this message may be a delivery system that sends the document saved by the blockchain to the individual and may also provide the individual with the ability to generate a response document. For example, the message may be a bid document that may include other supporting documents. The offer document may indicate a desire to purchase the asset. The support documents may include, for example, pre-approved documents indicating the loan amount of the user. The depositor may issue a pre-approval to blockchain 120, which may indicate its trustworthiness. The message may include this information and may also provide the ability to generate a response document. The response document may be, for example, a counter-offer, offer acceptance, and/or other document having a digital signature corresponding to the seller. The token server system 110 may manage the response document and may publish the response document on the blockchain 120 in the manner described above.
FIG. 10 depicts a block diagram of a document link environment 1000 that provides a demand-driven value chain in accordance with some embodiments. The document chain environment 1000 may include a token server system 1010 that may operate in a similar manner to the token server system 110. Document chain environment 1000 may also include blockchain 1020, which may operate in a manner similar to blockchain 120. The token server system 1010 may interact with several account profiles and different types of account profiles, such as a store account 1030, an enterprise account 1040, and/or a user account 1050.
These different accounts may represent different account types. For example, user account 1050 may represent a user account profile of a consumer. The store account 1030 may represent a vendor, which may be a wholesaler or retailer. The vendor may have a physical location and/or may be an online vendor. The enterprise account 1040 may represent a business enterprise and/or government that may not sell consumer goods.
From the file link environment 1000, each account may interact with other accounts of the same type and/or different types via the token server system 1010. Accounts may exchange documents including offer documents between account types. The user account 1050 may submit offers, applications, and/or suggestions to the storage account 1030 and/or the enterprise account 1040. In some embodiments, the user account 1050 may submit these offers even when the store account 1030, enterprise account 1040, and/or other user account 1050 may not list goods, services, and/or real estate assets for sale. In this manner, the token server system 1010 may provide a decentralized marketplace for the exchange of goods, services, and/or contractual obligations, which may be initiated regardless of the account type. The token server system 1010 may provide self-sufficiency and autonomy between the parties to negotiate a transaction.
Further, the offers, acceptances, and/or negotiations may not be limited by the role of a particular account. For example, each of the store account 1030, the enterprise account 1040, and/or the user account 1050 may be an offeror and/or parties that receive an offer. Similarly, each party may provide counter-offers for the transaction. In this manner, the token server system 1010 may facilitate a decentralized market between different accounts and/or account types. Additionally, the token server system 1010 may facilitate multi-party transactions between these accounts and account types.
In some embodiments, the token server system 1010 may also provide a demand driven value chain. Demand-driven value chains may allow buyers to generate quotes and/or quote documents in industries that traditionally utilize supply-driven trading markets. For example, a conventional online retailer may list items and receive a purchase order from a buyer. In a demand-driven value chain, buyers can submit offers for goods, services, and/or real estate even if sellers do not provide listings. Similarly, a lessee may provide a quote for renting assets from the landlord. By using a demand-driven value chain, parties such as buyers, sellers, lessees, landlords, agents, consumers requesting services, and/or service providers can initiate offers and/or generate offer documents.
In this manner, the token server system 1010 may facilitate offers, counter-offers, and/or negotiations between parties independent of role or account type. The buyer and/or seller may initiate the transaction. Further, different parties and/or account types, such as business enterprises, stores, businesses, and/or consumers, may use a demand-driven value chain to initiate and/or facilitate transactions with blockchain preservation. In this way, the token server system may support a decentralized market that uses blockchains to conduct transactions. Further, the token server system 1010 may provide flexibility for facilitating transactions from different parties with different roles. In this manner, the token server system 1010 may provide a one-stop store in which parties may present, initiate, negotiate, complete, and/or reference transactions and/or acquisition services in a decentralized manner.
In this demand driven model, parties that need goods and services can avoid visiting particular markets, branding websites, and/or aggregated websites to search for specific goods and services. Parties may conveniently initiate and/or generate document tokens, referred to as demand tokens, which may define their demand expectations. For example, a party may wish to purchase a new car and generate a document, specify a desire for the new car, brand Toyota, color red, price between $ 25,000 and $ 28,000, and/or delivery options to Brooklin.
Using demand tokens, the token server system 1010 may search for and/or identify other document tokens (referred to as supply tokens) having supply specifications for goods and services that closely match the specified demand. These demand or supply specifications may be stored as searchable fields in the metadata layer of the demand token. The token server system 1010 may notify the potential supply accounts that the demand for goods and services they may be able to provide is received. In some embodiments, a busy mother may attempt to find a two-day caregiver service during her trip. The mother may generate a demand document and the token server system may generate a demand token. The token server system 1010 may search for and/or identify a nanny that has generated a supply document and corresponding supply tokens with content that closely matches the busy mom's demand. This system of matching demand to supply can eliminate several steps required by both parties on both sides of the supply and demand, reducing the marketing cost of the supplier and the search time and effort of the parties requiring goods and services.
FIG. 11A depicts a flow diagram that illustrates a method 1100A for role-based document generation, in accordance with some embodiments. The method 1100A will be described with reference to fig. 10; however, the method 1100A is not limited to this example embodiment.
In embodiments, the token server system 1010 may facilitate negotiations and/or counter-offers between parties of different account types. Although the method 1100A is described with reference to the token server system 1010, the method 1100A may be performed on any computing device, such as, for example, the computer system described with reference to fig. 12 and/or processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 11A.
At 1105, the token server system 1010 may receive a document creation request from a first account corresponding to a first digital wallet, where the first account corresponds to a first account type. The first account type may be, for example, a store account 1030, an enterprise account 1040, or a user account 1050. The document creation request may have been received from an interaction with a GUI element, such as a document action button.
At 1110, the token server system 1010 may facilitate creation of a first document. This document creation process may be similar to other document creation processes previously described. At 1115, the token server system 1010 may create a document token corresponding to a first document. At 1120, the token server system 1010 may send the document token to a first digital wallet. Creation of the document token and transmission of the document token to the first digital wallet may also occur in the manner previously described. At 1125, the token server system 1010 may publish a hash of the first document and a link to an encrypted version of the first document to a blockchain using one or more intelligent contract functions. This may also be performed in the manner previously described.
At 1130, the token server system 1010 may send the notification to a second account corresponding to a second digital wallet, where the second account corresponds to a second account type different from the first account type. The notification may be, for example, a push notification or an email message. In some embodiments, the document token may be sent to a second digital wallet similar to the first digital wallet, depending on the designated permissions.
The second account type may be different from the first account type. This difference may indicate a different position and role for the party offering and the party receiving the offer. For example, the store account 1030 may send an offer document to the user account 1050, the offer document indicating an offer to sell a product. Similarly, the user account 1050 may send an offer document to the store account 1030 to purchase a product. User account 1050 may interact with enterprise account 1040 in the same manner, such as, for example, purchasing a service such as insurance. Although FIG. 11A depicts an example embodiment in which the account types are different, in some embodiments the account types may be the same account type.
At 1135, the token server system 1010 may facilitate creation of a second document for the second account. For example, the second account may generate a modified version of the first document. The second document may be a signed version and/or may include a digital signature. In some embodiments, the second document may be a counter-offer with modified terms. After creating the second document, the token server system 1010 may perform the encryption, hashing, and/or tokenization previously described. The token server system 1010 may also pass the second document to the first account. In this manner, parties may negotiate and/or execute transactions in a peer-to-peer manner that preserves contract terms via the immutability of blockchain 1020.
FIG. 11B depicts a flowchart that illustrates a method 1100B for demand matching, in accordance with some embodiments. Method 1100B will be described with reference to fig. 10; however, the method 1100B is not limited to this example embodiment.
In embodiments, the token server system 1010 may perform demand driven matching and/or identification of documents. Although the method 1100B is described with reference to the token server system 1010, the method 1100B may be performed on any computing device, such as, for example, the computer system described with reference to fig. 12 and/or processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executed on a processing device), or a combination thereof.
It should be understood that not all steps may be required to implement the disclosure provided herein. Further, as one of ordinary skill in the art will appreciate, some of the steps may be performed simultaneously, or in a different order than shown in fig. 11B.
At 1140, the token server system 1010 may receive a plurality of supply documents. The provisioning document may indicate the availability of goods, services, real estate assets, and/or other sales offers. Multiple supply documents may be provided by different users interfacing with the token server system 1010. The token server system 1010 may use a block chain 1020 to save these supply documents. The provisioning document may have been generated using the document action button as previously described. The content of the plurality of provisioning documents may differ. For example, a provisioning document may describe a listing for selling a real estate asset. In some embodiments, the provisioning document may list car and/or nanny services. The user may indicate the privacy designation corresponding to the provisioning document in the manner previously described.
At 1145, the token server system 1010 may create a supply document token corresponding to each of a plurality of supply documents. These supply document tokens may be similar to the previously described document tokens. The token server system 1010 may send the supply document tokens to digital wallets corresponding to the owners of each supply document.
At 1150, the token server system 1010 may receive a demand document including specifications for a desired transaction. For example, the requirements document may list specifications for goods, services, or real estate. The user may be searching for a new car and may enter a price and/or other details relating to the desired car. In some embodiments, the user may be searching for a nanny service, and may provide specifications such as a desired number of years of experience. These users may generate a demand document via the token server system 1010 to provide this information.
At 1155, the token server system 1010 may create a demand document token corresponding to the demand document. The token server system 1010 may create this document token type similar to other document tokens previously described. At 1160, the token server system 1010 may send or transfer the demand document token to a digital wallet. This transmission may occur similar to other transfers of document tokens to a digital wallet as previously described. In some embodiments, the digital wallet may correspond to a user who generated the requirements document.
At 1165, the token server system 1010 may analyze the content of the demand document to identify the specification. For example, the token server system 1010 may identify field values corresponding to the content of the demand document. For example, the requirements document may be a fillable form and the values may be extracted. In some embodiments, the token server system 1010 may use an optical character recognition application and/or a machine learning algorithm to identify semantic information corresponding to the specification.
At 1170, the token server system 1010 may identify a supply document of the plurality of supply documents that includes content corresponding to the specification of the demand file. Based on the analysis of the specification, the token server system 1010 may identify one or more matching and/or near-matching supply documents that include content that meets specification criteria. For example, the supply document may include a price or years of experience of real estate that meets the requirements document criteria. The token server system 1010 may perform the matching based on the extracted fields of the demand document and comparable fields from the supply document. In some embodiments, the token server system 1010 may identify searchable fields in the metadata layer that correspond to the supply documents and/or supply document tokens. In some embodiments, the token server system 1010 may utilize machine learning techniques to analyze the supply document based on the configuration and/or training of machine learning algorithms to identify matches or near matches. The token server system 1010 may notify the owners of the identified supply documents that their particular supply document has been selected.
At 1175, the token server system 1010 may send or transfer the supply document token corresponding to the identified supply document to a digital wallet. As previously described, the digital wallet may correspond to a user that provides the requirements document. The token server system 1010 may send the supply document tokens in a manner similar to that previously described. By sending the provisioning document token, a user corresponding to the digital wallet may view the provisioning document. The license may be identified because the supply document token is contained in the digital wallet. In some embodiments, the token server system 1010 may confirm that the privacy designation provides permission to share the supply document with the user providing the demand document. As previously described, this configuration of receiving an offer document may help facilitate a demand-driven trading system.
Various embodiments may be implemented, for example, using one or more well-known computer systems, such as computer system 1200 shown in fig. 12. For example, one or more computer systems 1200 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and subcombinations thereof.
Computer system 1200 may include one or more processors (also referred to as central processing units, or CPUs), such as processor 1204. The processor 1204 may be connected to a communication infrastructure or bus 1206.
The computer system 1200 may also include user input/output device(s) 1203, such as a monitor, keyboard, pointing device, etc., which may communicate with the communication infrastructure 1206 through the user input/output interface(s) 1202.
One or more of the processors 1204 may be a Graphics Processing Unit (GPU). In an embodiment, a GPU may be a processor that is a special-purpose electronic circuit designed to process mathematically intensive applications. GPUs may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common in computer graphics applications, images, video, and the like.
Computer system 1200 can also include a main or primary memory 1208, such as Random Access Memory (RAM). Main memory 1208 may include one or more levels of cache. Main memory 1208 may store control logic (i.e., computer software) and/or data therein.
Computer system 1200 may also include one or more secondary storage devices or memories 1210. Secondary memory 1210 may include, for example, a hard disk drive 1212 and/or a removable storage device or drive 1214. Removable storage drive 1214 may be a floppy disk drive, a magnetic tape drive, an optical disk drive, an optical storage device, a tape backup device, and/or any other storage device/drive.
The removable storage drive 1214 may interact with a removable storage unit 1218. The removable storage unit 1218 may comprise a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 1218 may be a floppy disk, magnetic tape, optical disk, DVD, optical storage disk, and/or any other computer data storage device. The removable storage drive 1214 may read from and/or write to a removable storage unit 1218.
Secondary memory 1210 may include other means, devices, components, tools, or other methods for allowing computer programs and/or other instructions and/or data to be accessed by computer system 1200. Such means, devices, components, tools, or other methods may include, for example, a removable storage unit 1222 and an interface 1220. Examples of a removable storage unit 1222 and interface 1220 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system 1200 may also include a communications or network interface 1224. Communications interface 1224 may enable computer system 1200 to communicate and interact with any combination of external devices, external networks, external entities, and the like, referenced individually and collectively by reference numeral 1228. For example, communication interface 1224 may allow computer system 1200 to communicate with an external or remote device 1228 via a communication path 1226, which communication path 1226 may be wired and/or wireless (or a combination thereof), and may include any combination of a LAN, a WAN, the Internet, or the like. Control logic and/or data can be sent to computer system 1200 or from computer system 1200 via communications path 1226.
Computer system 1200 may also be part of a Personal Digital Assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smartwatch or other wearable device, an appliance, an internet of things, and/or an embedded system, to name a few non-limiting examples, or any combination thereof.
Computer system 1200 may be a client or server that accesses or hosts any application and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; locally or locally deployed (on-premiums) software ("locally deployed" cloud-based solution); "as-a-service" models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or hybrid models including any combination of the above examples or other service or delivery paradigms.
Any suitable data structures, file formats, and schemas in computer system 400 may be obtained, individually or in combination, from standards including, but not limited to, JavaScript object notation (JSON), extensible markup language (XML), another markup language (YAML), extensible hypertext markup language (XHTML), Wireless Markup Language (WML), MessagePack, XML user interface language (XUL), or any other functionally similar representation. Alternatively, proprietary data structures, formats, or schemas may be used exclusively or in conjunction with known or open standards.
In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer-usable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1200, main memory 1208, secondary memory 1210, and removable storage units 1218 and 1222, as well as tangible articles of manufacture embodying any combination of the above. Such control logic, when executed by one or more data processing devices (such as computer system 1200), may cause such data processing devices to operate as described herein.
Based on the teachings contained in this disclosure, it will be apparent to a person skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems, and/or computer architectures other than that shown in FIG. 12. In particular, embodiments may operate using software, hardware, and/or operating system implementations other than those described herein.
It should be understood that the detailed description section and not any other sections are intended to be used for interpreting the claims. Other sections may set forth one or more exemplary embodiments but not all exemplary embodiments contemplated by the inventor(s), and therefore, are not intended to limit the present disclosure or the appended claims in any way.
While the present disclosure describes exemplary embodiments of exemplary fields and applications, it should be understood that the present disclosure is not limited thereto. Other embodiments and modifications thereof are possible and are within the scope and spirit of the disclosure. For example, and without limiting the generality of the paragraphs, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Furthermore, the embodiments (whether explicitly described herein or not) have significant utility for fields and applications other than the examples described herein.
Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. Boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries may be defined so long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Moreover, alternative embodiments may perform the functional blocks, steps, operations, methods, etc. in a different order than described herein.
References herein to "one embodiment," "an example embodiment," or similar phrases, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. In addition, some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments may be described using the terms "connected" and/or "coupled" to indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims appended hereto and their equivalents.

Claims (62)

1. A computer-implemented method, comprising:
receiving a document creation request from a user account corresponding to a digital wallet;
facilitating the creation of a document;
encrypting and storing an encrypted version of the document;
creating a link to the encrypted version of the document;
generating a cryptographic hash of the document;
creating a document token corresponding to the document;
sending the document token to the digital wallet; and
the link and the cryptographic hash are issued to a blockchain using one or more intelligent contract functions.
2. The computer-implemented method of claim 1, further comprising:
receiving a privacy designation for the document, the privacy designation indicating a condition of disclosure of the document to a party attempting to access the document; and
associating the privacy designation with the document via metadata corresponding to the document.
3. The computer-implemented method of claim 1, further comprising:
receiving a modification of a portion of the document to generate a modified;
encrypting and storing an encrypted version of the modified document;
creating a second link corresponding to the encrypted version of the modified document;
generating a second cryptographic hash corresponding to the modified document; and
publishing the second link and the second cryptographic hash to the blockchain using one or more intelligent contract functions.
4. The computer-implemented method of claim 3, further comprising:
creating a second document token corresponding to the modified document; and
sending the second document token to the digital wallet.
5. The computer-implemented method of claim 3, wherein the digital wallet corresponds to a first user account, the modification is received from a second user account, and wherein the method further comprises:
sending the document token to a second digital wallet corresponding to the second user account.
6. The computer-implemented method of claim 1, further comprising:
generating a Graphical User Interface (GUI) that displays a first set of the document's segmented portions and a second set of the document's segmented portions, wherein the first set and the second set correspond to the same segmented portion of the document.
7. The computer-implemented method of claim 6, further comprising:
facilitating, via the first set of segments, a modification to the document from a first user; and
displaying the modifications from the second user in the second set of partitions.
8. A system, comprising:
a memory; and
at least one processor coupled to the memory and configured to:
receiving a document creation request from a user account corresponding to a digital wallet;
facilitating the creation of a document;
encrypting and storing an encrypted version of the document;
creating a link to the encrypted version of the document;
generating a cryptographic hash of the document;
creating a document token corresponding to the document;
sending the document token to the digital wallet; and
the link and the cryptographic hash are issued to a blockchain using one or more intelligent contract functions.
9. The system of claim 8, wherein the at least one processor is further configured to:
receiving a privacy designation for the document, the privacy designation indicating a condition of disclosure of the document to a party attempting to access the document; and
associating the privacy designation with the document via metadata corresponding to the document.
10. The system of claim 8, wherein the at least one processor is further configured to:
receiving a modification of a portion of the document to generate a modified;
encrypting and storing an encrypted version of the modified document;
creating a second link corresponding to the encrypted version of the modified document;
generating a second cryptographic hash corresponding to the modified document; and
publishing the second link and the second cryptographic hash to the blockchain using one or more intelligent contract functions.
11. The system of claim 10, wherein the at least one process is further configured to:
creating a second document token corresponding to the modified document; and
sending the second document token to the digital wallet.
12. The system of claim 10, wherein the digital wallet corresponds to a first user account, the modification is received from a second user account, and wherein the at least one process is further configured to:
sending the document token to a second digital wallet corresponding to the second user account.
13. The system of claim 8, wherein the at least one processor is further configured to:
generating a Graphical User Interface (GUI) that displays a first set of the document's segmented portions and a second set of the document's segmented portions, wherein the first set and the second set correspond to the same segmented portion of the document.
14. The system of claim 13, wherein the at least one processor is further configured to:
facilitating, via the first set of segments, a modification to the document from a first user; and
displaying the modifications from the second user in the second set of partitions.
15. A non-transitory computer-readable device having instructions stored thereon, which, when executed by at least one computing device, cause the at least one computing device to perform operations comprising:
receiving a document creation request from a user account corresponding to a digital wallet;
facilitating the creation of a document;
encrypting and storing an encrypted version of the document;
creating a link to the encrypted version of the document;
generating a cryptographic hash of the document;
creating a document token corresponding to the document;
sending the document token to the digital wallet; and
the link and the cryptographic hash are issued to a blockchain using one or more intelligent contract functions.
16. The non-transitory computer-readable device of claim 15, the operations further comprising:
receiving a privacy designation for the document, the privacy designation indicating a condition of disclosure of the document to a party attempting to access the document; and
associating the privacy designation with the document via metadata corresponding to the document.
17. The non-transitory computer-readable device of claim 15, the operations further comprising:
receiving a modification of a portion of the document to generate a modified;
encrypting and storing an encrypted version of the modified document;
creating a second link corresponding to the encrypted version of the modified document;
generating a second cryptographic hash corresponding to the modified document; and
publishing the second link and the second cryptographic hash to the blockchain using one or more intelligent contract functions.
18. The non-transitory computer-readable device of claim 17, the operations further comprising:
creating a second document token corresponding to the modified document; and
sending the second document token to the digital wallet.
19. The non-transitory computer-readable device of claim 17, wherein the digital wallet corresponds to a first user account, the modification is received from a second user account, and the operations further comprise:
sending the document token to a second digital wallet corresponding to the second user account.
20. The non-transitory computer-readable device of claim 15, the operations further comprising:
generating a Graphical User Interface (GUI) that displays a first set of the document's segmented portions and a second set of the document's segmented portions, wherein the first set and the second set correspond to the same segmented portion of the document.
Facilitating, via the first set of segments, a modification to the document from a first user; and
displaying the modifications from the second user in the second set of partitions.
21. A computer-implemented method, comprising:
generating a graphical user interface, GUI, comprising an icon for initiating a link generation process;
receiving an interaction with the icon;
generating an interface for attaching one or more documents to the link;
receiving, via the GUI, an indication to attach one or more documents to the link;
generating a document token for each of the one or more documents, wherein the document token is deposited in a digital wallet to indicate ownership of each of the one or more documents;
publishing a blockchain link to the one or more documents to a blockchain; and
generating a message corresponding to the link, wherein the message includes the blockchain link and a document action button for initiating a document generation process.
22. The computer-implemented method of claim 21, further comprising:
a second GUI for managing the one or more links is generated.
23. The computer-implemented method of claim 21, wherein the link generation process comprises a prompt displayed on the GUI.
24. The computer-implemented method of claim 21, further comprising:
encrypting and storing an encrypted version of each of the one or more documents;
creating a blockchain link to the encrypted version of each of the one or more documents; and
generating a cryptographic hash of each of the one or more documents.
25. The computer-implemented method of claim 21, further comprising:
identifying an interaction with the document action button;
facilitating a document generation process to generate a response document; and
sending the response document for display on the GUI.
26. The computer-implemented method of claim 25, wherein the response document includes a digital signature.
27. The computer-implemented method of claim 25, further comprising:
and publishing the response document on the block chain.
28. A system, comprising:
a memory; and
at least one processor coupled to the memory and configured to:
generating a graphical user interface, GUI, comprising an icon for initiating a link generation process;
receiving an interaction with the icon;
generating an interface for attaching one or more documents to the link;
receiving, via the GUI, an indication to attach one or more documents to the link;
generating a document token for each of the one or more documents, wherein the document token is deposited in a digital wallet to indicate ownership of each of the one or more documents;
publishing a blockchain link to the one or more documents to a blockchain; and
generating a message corresponding to the link, wherein the message includes the blockchain link and a document action button for initiating a document generation process.
29. The system of claim 28, wherein the at least one processor is further configured to:
a second GUI for managing the one or more links is generated.
30. The system of claim 28, wherein the link generation process includes a prompt displayed on the GUI.
31. The system of claim 28, wherein the at least one processor is further configured to:
encrypting and storing an encrypted version of each of the one or more documents;
creating a blockchain link to the encrypted version of each of the one or more documents; and
generating a cryptographic hash of each of the one or more documents.
32. The system of claim 28, wherein the at least one processor is further configured to:
identifying an interaction with the document action button;
facilitating a document generation process to generate a response document; and
sending the response document for display on the GUI.
33. The system of claim 32, wherein the response document includes a digital signature.
34. The system of claim 32, wherein the at least one processor is further configured to:
and publishing the response document on the block chain.
35. A non-transitory computer-readable device having instructions stored thereon, which, when executed by at least one computing device, cause the at least one computing device to perform operations comprising:
generating a graphical user interface, GUI, comprising an icon for initiating a link generation process;
receiving an interaction with the icon;
generating an interface for attaching one or more documents to the link;
receiving, via the GUI, an indication to attach one or more documents to the link;
generating a document token for each of the one or more documents, wherein the document token is deposited in a digital wallet to indicate ownership of each of the one or more documents;
publishing a blockchain link to the one or more documents to a blockchain; and
generating a message corresponding to the link, wherein the message includes the blockchain link and a document action button for initiating a document generation process.
36. The non-transitory computer-readable device of claim 35, the operations further comprising:
a second GUI for managing the one or more links is generated.
37. The non-transitory computer-readable device of claim 35, wherein the link generation process comprises a prompt displayed on the GUI.
38. The non-transitory computer-readable device of claim 35, the operations further comprising:
encrypting and storing an encrypted version of each of the one or more documents;
creating a blockchain link to the encrypted version of each of the one or more documents; and
generating a cryptographic hash of each of the one or more documents.
39. The non-transitory computer-readable device of claim 35, the operations further comprising:
identifying an interaction with the document action button;
facilitating a document generation process to generate a response document;
sending the response document for display on the GUI; and
and publishing the response document on the block chain.
40. The non-transitory computer-readable device of claim 39, wherein the response document includes a digital signature.
41. A computer-implemented method, comprising:
receiving a document creation request from a first account corresponding to a first digital wallet, wherein the first account corresponds to a first account type;
facilitating creation of a first document;
creating a document token corresponding to the first document;
sending the document token to the first digital wallet;
publishing the hash of the first document and the link to the encrypted version of the first document to a blockchain using one or more intelligent contract functions;
sending a notification to a second account corresponding to a second digital wallet, wherein the second account corresponds to a second account type different from the first account type; and
facilitating creation of a second document by the second account.
42. The computer-implemented method of claim 41, wherein the first account type corresponds to a user account, and wherein the second account type corresponds to a store account.
43. The computer-implemented method of claim 41, wherein the first account type corresponds to a store account, and wherein the second account type corresponds to a user account.
44. The computer-implemented method of claim 41 wherein the second document is a modified version of the first document.
45. The computer-implemented method of claim 41 wherein the second document is a counter-offer document.
46. The computer-implemented method of claim 41 wherein the second document includes a digital signature.
47. The computer-implemented method of claim 41, further comprising:
sending the document token to the second digital wallet.
48. A system, comprising:
a memory; and
at least one processor coupled to the memory and configured to:
receiving a document creation request from a first account corresponding to a first digital wallet, wherein the first account corresponds to a first account type;
facilitating creation of a first document;
creating a document token corresponding to the first document;
sending the document token to the first digital wallet;
publishing the hash of the first document and the link to the encrypted version of the first document to a blockchain using one or more intelligent contract functions;
sending a notification to a second account corresponding to a second digital wallet, wherein the second account corresponds to a second account type different from the first account type; and
facilitating creation of a second document by the second account.
49. The system of claim 48, wherein the first account type corresponds to a user account, and wherein the second account type corresponds to a store account.
50. The system of claim 48, wherein the first account type corresponds to a store account, and wherein the second account type corresponds to a user account.
51. The system of claim 48 wherein the second document is a modified version of the first document.
52. The system of claim 48, wherein the second document is a counter-offer document.
53. The system of claim 48, wherein the second document includes a digital signature.
54. The system of claim 48, wherein the at least one processor is further configured to:
sending the document token to the second digital wallet.
55. A non-transitory computer-readable device having instructions stored thereon, which, when executed by at least one computing device, cause the at least one computing device to perform operations comprising:
receiving a document creation request from a first account corresponding to a first digital wallet, wherein the first account corresponds to a first account type;
facilitating creation of a first document;
creating a document token corresponding to the first document;
sending the document token to the first digital wallet;
publishing the hash of the first document and the link to the encrypted version of the first document to a blockchain using one or more intelligent contract functions;
sending a notification to a second account corresponding to a second digital wallet, wherein the second account corresponds to a second account type different from the first account type; and
facilitating creation of a second document by the second account.
56. The non-transitory computer readable device of claim 55, wherein the first account type corresponds to a user account, and wherein the second account type corresponds to a store account.
57. The non-transitory computer readable device of claim 55, wherein the first account type corresponds to a store account, and wherein the second account type corresponds to a user account.
58. The non-transitory computer-readable device of claim 55, wherein the second document is a modified version of the first document.
59. The non-transitory computer-readable device of claim 55, wherein the second document is a counter-offer document.
60. The non-transitory computer-readable device of claim 55, wherein the second document includes a digital signature.
61. A computer-implemented method, comprising:
generating a message corresponding to a document action button that, when pressed, causes a document generation process to be initiated;
when the document generation process is initiated:
generating a document token for a document corresponding to the message, wherein the document token is deposited in a digital wallet to indicate ownership of the document; and
the document is published to a blockchain.
62. A computer-implemented method, comprising:
generating an interface for attaching the document to the link;
generating a document token for the document, wherein the document token is deposited in a digital wallet to indicate ownership of the document;
publishing a blockchain link to the document to a blockchain; and
generating a message corresponding to the link, wherein the message includes the blockchain link.
CN201980022330.1A 2018-12-10 2019-12-10 Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration and dissemination Pending CN111902814A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US201862777520P true 2018-12-10 2018-12-10
US62/777,520 2018-12-10
PCT/US2019/065402 WO2020123464A1 (en) 2018-12-10 2019-12-10 Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration, and dissemination

Publications (1)

Publication Number Publication Date
CN111902814A true CN111902814A (en) 2020-11-06

Family

ID=71076591

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980022330.1A Pending CN111902814A (en) 2018-12-10 2019-12-10 Decentralized marketplace and ecosystem powered by blockchain-based document delivery, collaboration and dissemination

Country Status (3)

Country Link
JP (2) JP7064651B2 (en)
CN (1) CN111902814A (en)
WO (1) WO2020123464A1 (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11475453B2 (en) * 2019-12-31 2022-10-18 Capital One Services, Llc System and techniques for utilizing a smart contracts library
FR3114467A1 (en) * 2020-09-24 2022-03-25 Davron Translations Process and platform for traceability of an additional document generated by a third party from an original document via a blockchain system.
WO2022072624A1 (en) * 2020-09-30 2022-04-07 Surfdash Inc. System and method for providing a secure network
WO2022174096A1 (en) * 2021-02-11 2022-08-18 Tang Young A Ai-activated links & correlative gui

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10789373B2 (en) * 2011-10-31 2020-09-29 Reid Consulting Group, Inc. System and method for securely storing and sharing information
CA2991211A1 (en) 2015-07-02 2017-01-05 Nasdaq, Inc. Systems and methods of secure provenance for distributed transaction databases
US20170011460A1 (en) 2015-07-09 2017-01-12 Ouisa, LLC Systems and methods for trading, clearing and settling securities transactions using blockchain technology
US10915874B2 (en) * 2015-11-10 2021-02-09 Loyyal Corporation System and process for tokenization of digital media

Also Published As

Publication number Publication date
JP2022009897A (en) 2022-01-14
JP2021518028A (en) 2021-07-29
WO2020123464A1 (en) 2020-06-18
JP7064651B2 (en) 2022-05-10

Similar Documents

Publication Publication Date Title
Grover et al. Diffusion of blockchain technology: Insights from academic literature and social media analytics
US11393057B2 (en) Interactive real estate contract and negotiation tool
Khan Electronic commerce: A study on benefits and challenges in an emerging economy
US8818888B1 (en) Application clusters
US8661148B2 (en) System and method for enabling industry based channels in an IP marketplace
JP7064651B2 (en) Decentralized marketplaces and ecosystems enabled by blockchain-based document distribution, collaboration, and distribution
US20190108576A1 (en) Blockchain systems and methods for procurement
US20080301055A1 (en) unified platform for reputation and secure transactions
US20110282762A1 (en) SYSTEM AND METHOD FOR ENABLING IP MARKETPLACE APIs
US20200058023A1 (en) Decentralized Data Marketplace
US20160321722A1 (en) Systems and methods for obtaining consumer data
JP2022502768A (en) Smart contract
JP2019505931A (en) Method and system for allocating price discovery mechanisms in the data market
Gietzmann et al. Blockchain and other distributed ledger technologies: where is the accounting?
Azcoitia et al. A survey of data marketplaces and their business models
US10192250B1 (en) Systems and methods for providing access to data sets owned by different entities
CA2848458A1 (en) System and method for searching marketing channels in an ip marketplace
Girasa Technology Underlying Cryptocurrencies and Types of Cryptocurrencies
US20150254773A1 (en) Specification handling system
US20220130005A1 (en) Digital asset management systems and methods
US20220051192A1 (en) Document, drive and process management for contract of things and document of things
Karkeraa Unlocking Blockchain on Azure
Datta et al. Sanskriti—A Distributed E-Commerce Site Implementation Using BlockChain
US20160203532A1 (en) Method and system for providing real-estate transaction opportunities
CA2960891A1 (en) Method and system for transacting intellectual property

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination