DISSEMINATION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.

62/777,520, entitled“Blockchain-Powered Industry-Agnostic, One-Stop Deal and Service Marketplace, and New Demand-Driven and Integrated Value Chain,” which was filed on December 10, 2018, and which is hereby incorporated by reference in its entirety.

BACKGROUND

Field

[0002] This field is generally related to document tokenization and modification using blockchain technology, their applications to create, deliver, disseminate and collaborate on confidential documents, their applications to extend marketplaces and e-Commerce websites into more sophisticated instant negotiation and deal making places, their applications to move a supply-driven marketplace model to a demand-driven marketplace model, as well as their applications to generate ubiquitous marketplaces, e-Commerce or trading platforms, for example for real estate, automobile, digital assets, tangible asserts, or other goods and services.

Related Art

[0003] As individuals, businesses, and governments interact, parties often exchange many documents to communicate. These documents may include written desires or may be contractual obligations. For example, the exchange of offers or invitations to negotiate may initiate a process execute a transaction such as a purchase of property, goods, or services. Parties may also exchange documents during a negotiation process. For example, parties may exchange modifications to an agreement document or a contract. These modifications may be electronically mailed with tracked changes.

[0004] During negotiations, however, parties may exchange many versions of a document with complex modifications. Tracking the changes may become difficult to manage. Further, this negotiation process is further complicated in situations with multiple parties to a particular transaction. Encrypting and preserving a true record of modifications that may be relied upon by the parties to represent parties’ true desires and contractual positions may also be difficult when using unsecure technology such as electronic mail.

[0005] The lack of auditable real time negotiation and instant contract exchange

capabilities restrains many marketplaces and e-Commerce websites within the realm of buying or selling relatively low value products or constrains the products/services a marketplace could offer. Instantly trading products and services via a complex contract structure is difficult to achieve in conventional marketplaces.

[0006] Furthermore, buying or selling goods and services online are generally confined within marketplace or e-Commerce platforms, largely due to the trust issue and technological limitations. This method not only requires marketplace participants such as vendors or consumers to go through several setup steps, but also does not provide them the flexibility to target the audience that they believe are more likely to buy their products or offer them services they need. In countries and regions where online marketplaces are limited, traders from those developing markets could be significantly disadvantaged.

[0007] Additionally, common marketplace transactions limit inventory to those listed by a seller. For example, typical online transactions begin with online retailers listing items for purchase. Similarly, individuals listing real estate property may list the availability of property for purchasing or renting. Beginning transactions with listings from sellers restricts the inventory of goods, services, and/or real estate to those that have been listed for sale. Further, traditional online retailers typically connect a business to a consumer to allow the consumer to purchase from the business. This inflexible model prevents transactions from different parties with different roles. For example, these approaches do not facilitate transactions between businesses or between consumer stores.

[0008] The listing model used in the real estate industry further prevents buyers from submitting offers and initiating transactions themselves. The listing model only accounts for approximately 2% of the real estate market which excludes most of the market.

Further, these real estate transactions typically require face-to-face interactions among parties as well as a great deal of paperwork. The lack of technological capabilities to accomplish legally-binding property purchases, leases, and rentals rapidly and in a secure manner further complicates this process. Users also face issues with data security and the concern that important personal data may be hacked, mined, and harvested. This lack of security may dissuade buyers and renters from making online offers and may dissuade sellers from disclosing pertinent information. In this manner, buyers and sellers may lack the ability and desire to provide online offers.

[0009] Further, because real estate transactions may be infrequent for buyers and sellers, buyers and sellers may heavily rely on and may feel compelled to use real estate agents and professionals. In some cases, agents may perform negotiations with offers and counteroffers without transparency and auditability for the buyers and sellers. Buyers and sellers may not have an overview of the transaction system. For example, potential buyers may not be able to easily track the status of an offer while sellers may not be able to easily track the offers received without speaking to an agent. Similar issues may arise during the rental property application process.

BRIEF SUMMARY

[0010] Disclosed herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for managing documents using blockchain technology.

[0011] In an embodiment, a token server system may facilitate and manage documents and document modifications using document tokens, digital wallets, and a blockchain.

The token server system may generate document tokens representing digital document ownership and/or document modification permissions. The token server system may distribute document tokens to digital wallets specified by an owner of the document. The token server system may also encrypt the document, store the encrypted version 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 the link on a blockchain using one or more smart contract functions. The token server system may also consume processing tokens and/or a cryptocurrency to perform the blockchain operations.

[0012] The token server system may also perform similar operations to manage

modifications of a document. For example, a party having permissions to modify the original document may perform a modification such as, for example, inserting, deleting, and/or modifying text as facilitated by a graphical user interface generated by the token server system. The token server system may then generate a separate document token corresponding to this modified document. The token server system may perform similar operations to the modified document such as encryption, hashing, and generating of a link to the modified document. The token server system may also publish a hash and a link to an encrypted version of this modified document to a blockchain to preserve the modification. The token server system may also distribute the document token to the owner of the modification as well as the original document. In this manner, the publication to the blockchain may preserve the modification and provide trust that the modification was intended and free from interference. The token server system may provide a graphical user interface to each party to view and/or modify these documents in a human-readable manner even while using a blockchain preservation system.

[0013] In some embodiments, a computer-implemented method for managing a document using a blockchain may be used by the token server system. 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 the creation of a document, encrypt the document, and store an encrypted version of the document. The token server system may create a link to the encrypted version of the document and generate a cryptographic 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 a blockchain using one or more smart contract functions.

[0014] In some embodiments, a computer-implemented method for providing graphical user interface icons to generate documents may be used by the token server system. The token server system may generate a graphical user interface (GUI) including a first icon used to initiate a link generation process. The first icon, for example, may be a document action button such as the“Offer Now” button as described further below. In response to receiving an interaction with the first icon, the token server system may generate an interface for attaching one or more documents to a link. This linking may be referred to as the“1-Link” process as further described below. The token server system may receive an indication to attach one or more documents to the link via the GUI and generate a document token for each of the one or more documents. The document tokens may be deposited in a digital wallet indicating ownership of each of the one or more documents. The token server system may publish blockchain links to the one or more documents to a blockchain and generate a message corresponding to the link. The message may include the blockchain links and a second icon used to initiate a document generation process.

[0015] In some embodiments, a computer-implemented method for managing documents generated from different account types may be used by the token server system. For example, the different account types may represent a demand-driven value chain for transactions. The token server system may receive a document creation request from a first account corresponding to a first digital wallet, wherein the first account corresponds to a first account type. The token server system may facilitate the creation of a first document and create a document token corresponding to the first document. The token server system may transmit the document token to the first digital wallet and 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 smart contract functions. The token server system may then transmit a notification to a second account corresponding to a second digital wallet, wherein the second account corresponds to a second account type that differs from the first account type. The token server system may then facilitate the creation of a second document by the second account.

[0016] Various embodiments can use these technical features to achieve improvements in, for example, the real estate industry. The token server system may generate GUI elements such as the“Offer Now” button, which may be used to generate a real estate offer preserved on a blockchain. Other document action buttons may also be used to generate real estate offers, such as buttons displaying the words“Lease Now”;“Rent Now”;“Apply Now”; and/or“Buy Now”. Sellers may also use document action buttons such as a“List Now” and/or a“Manage Now” button to create a listing and/or offer document to offer a property for sale or rent. The token server system may facilitate a streamlined document generation process and also may preserve a hash of the generated document using a blockchain to maintain confidentiality while utilizing the immutable nature of the blockchain.

[0017] The token server system may be used to manage real estate documents using the blockchain in this manner as well. For example, the token server system may manage offers, counteroffers, and/or other negotiated modifications of a contract document. The token server system may preserve these document modifications using a blockchain. Further, the token server system may preserve other documents related to a real estate transaction, such as, for example, loan approvals, inspection reports, real estate deeds, contracts, agreements, and/or other real estate documents. This management may track the progress and/or execution of real estate transactions as well as the documents used in the transactions.

[0018] Along with the management of documents, the token server system may also

provide a“1-Link” process, either independently with its graphical user interface (GUI) or as part of another workflow, providing link management and/or distribution of documents. The link may represent a document that is preserved by a blockchain and that may further provide access to other documents preserved by the blockchain. For example, a user may generate a link to an offer document to provide an offer to purchase real estate. The link may be a document that includes links to other documents such as a loan approval document. The user may then transmit this link to the owner of the property as an offer. In some embodiments, the links may correspond to embedded email messages such that the email message includes the links to the other messages. In this manner, the 1-Link process may provide a streamlined document transmittal process facilitated by the token server system.

[0019] The token server system may further use the technical features described in this disclosure to provide a demand-driven value chain. The demand-driven value chain may allow parties who have a demand to generate documents in industries that traditionally utilize a supply-driven transaction marketplace. For example, buyers may generate offers and/or offer documents, sellers may generate sales documents, and/or buyer agents may generate offer documents on their clients’ behalf. For example, traditional online retailers may list items and receive purchase orders from buyers. In a demand-driven value chain, a buyer may submit an offer for goods, services, and/or real estate even if a seller has not provided a listing. In this manner, the token server system may facilitate offers, counteroffers, and/or negotiations between parties independent of roles or account types. Buyers and/or sellers may initiate transactions. Further, different party and/or account types, such as businesses, stores, enterprises, and/or consumers may use the demand- driven value chain to initiate and/or facilitate transactions with blockchain preservation.

In this manner, the token server system may support a decentralized marketplace for transactions using a blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings are incorporated herein and form a part of the

specification.

[0021] FIG. 1 depicts a block diagram of a document management environment,

according to some embodiments.

[0022] FIG. 2 depicts a flowchart illustrating a method for publishing a document to a blockchain, according to some embodiments.

[0023] FIG. 3 A depicts a flowchart illustrating a method for dividing document

permissions, according to some embodiments.

[0024] FIG. 3B depicts a flowchart illustrating a method for designating a secrecy setting for a document, according to some embodiments.

[0025] FIG. 4 depicts a flowchart illustrating a method for modifying a document,

according to some embodiments.

[0026] FIG. 5 depicts a flowchart illustrating a method for document negotiation,

according to some embodiments.

[0027] FIG. 6 depicts a flowchart illustrating a method for generating a graphical user interface for document negotiation, according to some embodiments.

[0028] FIG. 7 depicts a block diagram of a graphical user interface including segmented document portions, according to some embodiments.

[0029] FIG. 8A depicts a block diagram of a graphical user interface including a

document action button that may display the words“Offer Now”;“Lease Now”;“Rent Now”;“Apply Now”;“Buy Now”; List Now”; and/or“Manage Now”, according to some embodiments.

[0030] FIG. 8B depicts a block diagram of a graphical user interface for link management and generating a 1-Link process, according to some embodiments.

[0031] FIG. 8C depicts a block diagram of a graphical user interface of a message

including a document action button and document links, according to some embodiments.

[0032] FIG. 9 depicts a flowchart illustrating a method for generating a message

including a document action button and document links, according to some embodiments.

[0033] FIG. 10 depicts a block diagram of a document chain environment providing a demand-driven value chain, according to some embodiments. [0034] FIG. 11 A depicts a flowchart illustrating a method for role-based document generation, according to some embodiments.

[0035] FIG. 1 IB depicts a flowchart illustrating a method for demand matching,

according to some embodiments.

[0036] FIG. 12 depicts an example computer system useful for implementing various embodiments.

[0037] In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

DETAILED DESCRIPTION

[0038] Provided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for managing documents using blockchain technology. The embodiments disclosed herein may facilitate the generation of a document by providing a front-end user interface while managing the document using a connected, associated, or related back-end system interfaced with a 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 the document, manage document modifications from different parties, and/or view documents linked on a blockchain in a human-readable manner.

[0039] The back-end may manage documents using a document token process and a

blockchain interface. As will be further explained below, document tokens may be used to represent ownership and/or permissions corresponding to a document. Document tokens may also be used to track document modifications and/or segment permissions for different portions of a document. Further, document tokens may be generated for each version of a modified document. These document tokens may represent ownership of the modifications and may be used with the blockchain to provide proof of a document modification. For example, on either a public or private blockchain, modifications may be tracked as updated blocks and/or code executed on a blockchain using smart contract functions.

[0040] The publication to a blockchain may provide security and trust that modifications are immutable. Further, distributed ledger technology may provide a streamlined manner of tracking modifications and presenting these modifications to parties communicating and/or editing a document. As will be further described below, the embodiments described herein further 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 related to blockchain transaction times.

[0041] The embodiments described herein may further be used in contract negotiations to provide a streamlined contract platform for tracking and viewing offers and counteroffers. For example, users may generate offers to purchase goods, services, property, insurance, and/or other contractual obligations. These offers may be represented as documents. The systems described below may facilitate the generation of these offers and publish these offers to a blockchain. The immutability of the blockchain may preserve these offers. Further, utilizing encryption may maintain confidentiality of sensitive information when making these offers. By managing these offer documents using a blockchain, parties to a contract may present offers that may be relied upon by other parties in a more trusted manner.

[0042] Further, counteroffers may also be managed in a similar manner. For example, counteroffers may be modified offers which may be represented as documents with corresponding document tokens. These counteroffers may also be managed using the blockchain in a similar manner. By managing offers and counteroffers, the document platform may streamline a negotiation process that preserves confidentiality while maintaining a high degree of trust. Parties using the document platform may negotiate contractual terms and/or provide digital signatures representing an acceptance of an offer. In this manner, the document platform may facilitate the execution of a contract. In some embodiments, this negotiation and execution may be performed in a decentralized manner and/or provide a decentralized marketplace for peer-to-peer transactions.

[0043] The document action button and/or the 1-Link process may further be

implemented using the systems described below to streamline the document generation, document delivery, and document dissemination process. In some embodiments, this streamlining may be particularly useful in documents preserved using a blockchain. The document action button, such as an“Offer Now”;“Lease Now”;“Rent Now”;“Apply Now”;“Buy Now”; List Now”; and/or“Manage Now” button may allow a user to quickly generate a document using fewer GUI interactions. The reduction of interactions may aid in reducing wasted computational resources or unnecessary web navigation. Further, the document action button may aid in reducing network traffic due to the reduced number of interactions. Similarly, the 1-Link process may deliver blockchain- preserved documents in a similar and compact manner. Users accessing the link may access various blockchain preserved documents and/or may generate another document using a 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.

[0044] Various embodiments of these features will now be discussed with respect to the corresponding figures.

[0045] FIG. 1 depicts a block diagram of a document management environment 100, according to some embodiments. Document management environment 100 may include token server system 110, blockchain 120, user interfaces 130, and/or user devices 140. Token server system 110 may include one or more servers and/or databases that may instantiate user interfaces 130A-130B for user devices 140A-140B. Token server system 110 may include object storage, a web service interface, storage for Internet applications, and/or cloud computing and/or storage. In some embodiments, token server system 110 may use a peer-to-peer network and/or protocol for storing and/or sharing data in a distributed file system. For example, token server system 110 may use content addressing to uniquely identify files in a global namespace to network user devices 140.

In some embodiments, token server system 110 may use the Interplanetary File System (IPFS) protocol and/or servers such as Amazon S3 ®.

[0046] Token server system 110 may include an interface with blockchain 120.

Blockchain 120 may be a private or public blockchain. Token server system 110 may use one or more smart contract functions to interface and/or publish data to blockchain 120. The smart contract functions may include protocols to digitally facilitate, verify, and/or enforce transactions. The transactions may be trackable and irreversible. As will be further described 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 a document and/or a link to a human-readable representation of the document. [0047] In some embodiments, token server system 110 may also manage processing tokens used to interact with blockchain 120. For example, token server system 110 may manage digital wallet information related to cryptocurrencies. Token server system 110 may use and/or consume digital currencies to execute transactions to blockchain 120. For example, token server system 110 may also manage gas, transaction, and/or mining fees used to conduct a transaction, execute a blockchain contract, and/or publish data onto blockchain 120 in a block. As will be further explained below, token server system 110 may also manage document tokens which may represent ownership and/or permissions for documents and/or document modifications. Token server system 110 may facilitate the publishing of document data to blockchain 120 and/or may remove processing tokens from an account corresponding to a digital wallet to perform the publishing.

[0048] Token server system 110 may provide a front-end user interface 130 to allow

users to create, manage, edit, and/or modify documents. User interface 130 may be a graphical user interface (GUI) that may be accessed and/or displayed on a user device 140. User device 140 may be a computer, laptop, tablet, phone, and/or other device that may access the Internet and/or display a user interface 130. User interface 130 may include an application programming interface (API) to provide communications between user device 140 and token server system 110.

[0049] As will be further explained below, token server system 110 may provide a front- end GUI including GUI elements allowing 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 a digital wallet, manage user account information and/or account roles, and/or other document interactions. In some embodiments, token server system 110 may facilitate the incorporation of GUI elements into web pages not managed by token server system 110 to allow users to access the operations provided by token server system 110. For example, token server system 110 may provide a web widget that may be incorporated, integrated, or overlaid onto other web pages to provide similar document functionality.

[0050] For example, token server system 110 may generate an icon and/or button

allowing a user to create a document. The user may interact with the icon or button via a selection, press, or click on a GUI. In response to this interaction, token server system 110 may generate a document creation GUI element displayed on the GUI. The document creation GUI element may be a Tillable form and/or may include editable text boxes. In some embodiments, the document creation GUI element may include an option to attach data files locally stored on a user device 140. Token server system 110 may enable the generation of a document that may be encrypted and/or stored on blockchain 120

[0051] In an embodiment, token server system 110 may provide a GUI element allowing a user to create an offer document to initiate a contractual negotiation process. For example, the GUI element may be a button displaying the text“Offer Now” on a web page. The user may be browsing a web page displaying different goods, services, property, insurance, and/or other contractual obligations and may interact with the button to generate and submit an offer document. The offer document may be a fillable form that may allow the user to input personal information and/or information such as an offer to purchase property. The user may also specify conditions and/or obligations to generate a contractual document for the owner of the property. Token server system 110 may deliver this offer document to the owner of the property to notify the owner of the pending offer. For example, token server system 110 may provide a notification via electronic mail or via a push notification to a user device 140 corresponding to a user account associated with the owner.

[0052] To manage the management and/or storage of the offer document, token server system 110 may use blockchain 120. As will be further explained below, token server system 110 may store an encrypted version of the offer document and/or create a link to the encrypted version of the document. Token server system 110 may also generate a cryptographic hash of the document. Using this information along with other information such as an owner identification and/or other metadata, token server system 110 may create a document token corresponding to the offer document. The document token may represent ownership of the offer document and/or may be transmitted to a digital wallet corresponding to the offering party. Token server system 110 may use the document token in future operations to determine access and/or modification permissions. In some embodiments, token server system 110 may transmit the document token to a digital wallet of the selling party to allow the selling party to access and/or modify the document. For example, the document token may indicate that the selling party may modify the document with a digital signature to accept the contractual offer. [0053] Token server system 1 10 may manage the offer document using blockchain 120.

For example, token server system 110 may publish the cryptographic hash of the document and/or the link to the encrypted version of the document using smart contract functions. The document may be encrypted using a key corresponding to the selling party. Publishing the document data onto blockchain 120 may preserve the

trustworthiness of the document and the legitimacy of the offer and/or content. For example, the immutable nature of blockchain 120 may protect against unauthorized document modifications or tampering. Further, the cryptographic hash may preserve privacy and may prevent other users of the blockchain 120 from viewing confidential information. For example, user device 140C may be utilizing a separate user interface 130C to access blockchain 120 separately from token server system 110. The encryption may prevent user device 140C from viewing the confidential information stored on blockchain 120.

[0054] Upon delivering the notification of the offer document to the selling party, the selling party may access the offer document using a user device 140 and a corresponding user interface 130 to access token server system 110. In particular, token server system 110 may confirm that a digital wallet corresponding to the selling party includes a document token corresponding to the offer document. Token server system 110 may also identify the permissions corresponding to this document token, such as permissions to view, access, and/or modify the offer document. Token server system 110 may further verify that the offer document has not been altered by verifying the cryptographic hash stored on blockchain 120. Token server system 110 may also provide the link to the encrypted version of the offer document to the selling party. The selling party or token server system 110 may then decrypt the encrypted document using a digital signature key corresponding to the selling party. If the selling party accepts the offer presented in the offer document, the selling party may provide a digital signature to confirm the acceptance. This digital signature may also be keyed to the selling party to provide verification and additional trustworthiness that the signature is legitimate and protected against interference or tampering. In some embodiments, the digital signature may also be reflected in the human-readable portion of the offer document.

[0055] In an embodiment, the digital signature may be a modification to the offer

document. Token server system 110 may manage this modification in a manner similar to generating a document so that the modified document may be preserved using blockchain 120. For example, the signed document may be encrypted and stored as a modified version of the offer document. Token server system 110 may generate a corresponding link to this encrypted version of the signed document and/or generate a cryptographic hash of the signed document. Token server system 110 may create a document token corresponding to the signed document and may transmit this document token to a digital wallet corresponding to the selling party and/or the offering party. Token server system 110 may publish the hash and/or the link to the encrypted version of the signed document to blockchain 120. Similarly, the encryption may have been performed using a key corresponding to the offering party to preserve confidentiality. In this manner, token server system 110 may facilitate the offer and acceptance of a contract using a document management process using blockchain 120.

[0056] Similar to this offer and acceptance process, token server system 110 may manage a negotiation process via document modification. This negotiation process may include one or more rounds of offers and counteroffers between parties. The parties may digitally negotiate using token server system 110 and modify different portions of a document.

For example, the parties may negotiate different contractual terms and/or obligations. Token server system 110 may use a tokenization process to manage different portions of a document and/or to manage counteroffers.

[0057] For example, the selling party may receive an offer document from an offering party. The selling party may disagree with one or more contractual terms provided in the offer document, such as, for example, the offered price to purchase a property. In this case, the selling party may perform a modification to the offer document via a user interface 130. The selling party may modify the text of the offer document. In some embodiments, the selling party may modify elements of a fillable form to modify the offer document.

[0058] Token server system 110 may manage this modification in a manner similar to generating a document so that the modified document may be preserved using blockchain 120. The modified document may be encrypted and stored as a modified version of the offer document. Token server system 110 may generate a corresponding link to this encrypted version of the modified document and/or generate a cryptographic hash of the modified document. Token server system 110 may create a document token corresponding to the modified document and may transmit this document token to a digital wallet corresponding to the selling party and/or the offering party. Token server system 110 may publish the hash and/or the link to the encrypted version of the modified document to blockchain 120. Similarly, the encryption may have been performed using a key corresponding to the offering party to preserve confidentiality. In this manner, token server system 110 may facilitate the negotiation of a contract using a document management process using blockchain 120. Token server system 110 may further continue to manage additional modifications and/or counteroffers from either party in this manner.

[0059] In some embodiments, token server system 110 may preserve negotiations and/or counteroffers locally prior to publishing a document to blockchain 120. For example, in cases where publishing a document to blockchain 120 may consume digital currency or gas, parties may elect to perform negotiations and/or counteroffers using memory local or accessible to token server system 110. Token server system 110 may publish agreed upon documents to blockchain 120 when negotiations and document modifications have been completed. For example, token server system 110 may identify matching terms and/or digital signatures indicating acceptance prior to publishing a document to blockchain 120.

[0060] While token server system 110 has been described as managing an offer document from an offering party to a selling party, token server system 110 may also manage document transmissions from different contractual roles. For example, a selling party may generate an offer document to a buying party. The buying party in this case may accept the offer and/or may provide a counteroffer. Similarly, parties may negotiate services and/or other contractual exchanges using token server system 110 and blockchain 120. The document management provided by token server system 110 may provide confidentiality in document exchanges as well as provide trustworthiness in the immutable nature of blockchain 120 to represent party positions. Similarly, token server system 110 may be used to manage documents such as rental agreements, leases, real estate documents, auctions, and/or other documents.

[0061] As will be further explained below, the document management process used by 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 a buyer’s agent, seller’s agent, attorneys, mortgage lenders, and/or other parties may be involved in a transaction. Token server system 110 may manage these different account roles and/or may provide permissions to different users depending on their role in the transaction. For example, a mortgage lender may be required to provide documentation that a buyer is qualified and/or approved to borrow a certain amount. The mortgage lender may provide this documentation to token server system 110. In some embodiments, token server system 110 may provide a form to the mortgage lender that may be a modifiable document where the mortgage lender may include information such as the qualified amount. Using the mortgage lender’s digital signature, this document may be verified and/or stored on blockchain 120.

Further, the buyer may be able to use this document in more than one transaction if the buyer is submitting multiple offers to different sellers.

[0062] In some embodiments, a master document may be compiled with different

portions being assigned to different roles of a transaction. For example, the mortgage lender may modify a portion of the master document while the seller’s agent may be assigned to modify a different portion. Token server system 110 may manage and/or administer these modifications to ensure that corresponding roles are performing their designated modifications without tampering from other individuals. Further, these modifications may be preserved on blockchain 120. In this manner, parties may be accountable for modifications that may be trusted and correlated to the particular accounts and/or account roles supplying the document modification.

[0063] Token server system 110 may manage varying levels of secrecy related to

documents. For example, a user generating the document may designate a document as being open, semi-secret, or secret. This designation may be stored as metadata

corresponding to the document. For example, the secrecy designation may be a visibility flag. In some embodiments, the secrecy designation may correspond to a listing of a good, service, and/or real estate for sale. For example, the secrecy designation may correspond to the listing of real estate property for sale or for lease. The secrecy may facilitate a real estate owner’s decision to list a property using a document that may be preserved by blockchain 120 while entertaining offers confidentially. For example, a celebrity may not wish to publicly list a property and/or list property identification information but may still wish to entertain potential offers. Based on the secrecy designation by the user, token server system 110 may reveal the listing document to a desired agent, buyer, and/or renter. For example, token server system 110 may transmit a document token with corresponding permissions to interact with the listing document to the user as will be further described below.

[0064] In some embodiments, token server system 110 may manage these listings to aid in matching parties to listings. For example, an“open” designation may indicate that a listing document may be openly available to be matched by token server system 110. An “open” designation may allow public accessing and/or browsing of the listing. A buyer or renter may transmit an offer request and/or offer document to token server system 110, and token server system 110 may attempt to match the request with a listing document. For example, the buyer may indicate a particular price, geographic area, house specifications such as bedrooms and bathrooms, and/or other requirements for a property. Token server system 110 may provide the“open” listing document to the buyer if the conditions identified for the listing are satisfied and/or matched by the price and/or requirements provided by the buyer.

[0065] A“semi-secret” designation may indicate that the listing document may be

revealed when a buyer and/or renter has submitted an offer, and 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, “semi-secret” documents may only be searchable by certain fields, e.g., the exact address is kept confidential, but the postcode is searchable.“Semi-secret” documents may include additional conditions prior to being revealed to a user. For example, a“semi secret” listing document may include a price condition. Token server system 110 may reveal the listing document if the buyer provides a sufficient offer price. Similarly, a user may designate a listing document as“semi-secret” and available only to certain individuals such as particular agents. For a buyer who provides a request and/or an offer with different conditions, token server system 110 may facilitate a demand-driven value chain as will be further described below.

[0066] A“secret” designation may indicate that token server system 110 may reveal the listing document after a real estate property owner has evaluated a request or offer and has provided an affirmative confirmation to reveal the listing document. This“secret” designation may indicate a desire for confidentiality that may include input from the listing party prior to providing identifying information to the offering party. Using these designations, token server system 110 may manage confidentiality related to listing documents posted on blockchain 120 while still facilitating the preservation of the listing document. The added confidentiality may further allow additional participation in listing properties.

[0067] In addition to listing documents, token server system 110 may facilitate the

creation of contract documents. To illustrate an example embodiment, a user, Ted, may wish to use token server system 110 to sell a house. Ted may create a contract document using token server system 110. Ted may also have a real estate agent assisting with the sale of the house. Ted may provide user information to token server system 110 for the real estate agent and provide the agent rights to manage parts of the contract document. The agent may then search for buyers and/or provide a link to potential buyers to provide buyers with access to the contract document. Buyers accessing the link may cause token server system 110 to create a copy of the contract document including the buyer’s rights and obligations.

[0068] In some cases, the buyer may disagree with terms in the contract document and may initiate a negotiation process. For example, the buyer may edit text of the contract document such as rights and obligations and/or the final price. The buyer may leave comments on some conditions of the contract document. The negotiation process may be managed and/or performed by the agent depending on 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 terms and/or content of the contract document match for the seller and the buyer. Ted may view counteroffers and/or select a buyer to execute the contract document by providing a digital signature on an agreeable contract document modification. Ted may locally save a copy of the contract document from token server system 110 onto user device 140. For example, this copy may be a PDF document. Ted may also access blockchain 120 using a blockchain explorer to view the transaction information as preserved by token server system 110.

[0069] A business or enterprise may use token server system 110 to manage documents.

For example, John may be the owner of a company and may create a workflow, which may designate departments and/or account roles corresponding to company employees. The employees may use token server system 110 to generate documents, edit documents, transmit documents to external parties, and/or negotiate with these external parties. The external parties may be external individuals, vendors, contractors, and/or other parties external to John’s company. Using token server system 110 and blockchain 120, John may verify the authenticity of documents created by employees and/or received from external parties.

[0070] Token server system 110 may manage multiparty contracts. For example, token server system 110 may manage a one-to-many, a many-to-one, and/or a many-to-many multiparty contract. In an example embodiment, a user, Sam, may wish to enter into a contract as an owning side. Sam may use token server system 110 to create a set of contract documents with the intention for negotiation. Sam may designate portions of each contract document where terms may be changed. These portions may represent fields of the contract document.

[0071] Sam may be an employee working at a company with a treasury or deputy

treasurer. Sam may transmit the set of contract documents to the deputy treasurer who may review, sign, and/or edit the contract documents. The deputy treasurer may return a contract document back to Sam for further edits. In the case where the deputy treasurer signs the contract documents, token server system 110 may generate a notification such as an email to Sam. Sam may then use token server system 110 to transmit one or more links to the contract documents to one or more counter parties. These counter parties may be external to the company.

[0072] The counter parties may create counter offers which may include a set of variable fields. For example, the counter parties may choose to edit terms of the contract document and/or not edit terms. In the case where field values diverge, a negotiation process may begin as managed by token server system 110. The owner of the contract document and/or the counter party may continue to alter values of a field. With each alteration, the other party may receive a notification from token server system 110 and/or may accept or reject the offer. The contract document may be agreed upon via an acceptance from a party and/or until each field includes the same value from each party. The parties may apply digital signatures to the contract document to finalize the contractual obligations.

[0073] In some embodiments, Sam may utilize different versions of the contract

document for different counter parties. Token server system 110 may provide GUIs for Sam to manage these different contract documents and/or links corresponding to the contract documents. If a counter party agrees with their corresponding terms as provided by Sam, Sam may sign and/or complete the negotiation process with that counter party.

[0074] Token server system 110 may also manage templates of documents and/or

contract documents. A law firm may create these templates. Token server system 110 may provide these templates for purchase and for use by a user. These templates may include rental and/or lease documents. For example, Sara may wish to rent her apartment. She may use token server system 110 to identify a standard rental agreement document template. Sara may purchase the template using digital currency and/or using processing tokens, which will be further described below. Sara may edit some of the conditions listed in the template. Token server system 110 may generate a link providing access to the rental agreement document and/or other information provide by Sara about the apartment. Three potential tenants may access the link to respond to the document created by Sara. Sara may communicate with each of them and may finalize and execute the contract with one of them using a digital signature provided to token server system 110

[0075] While token server system 110 may provide template contracts or documents, token server system 110 may also gather statistics related to modifications to the templates. For example, token server system 110 may identify trends of modifications. Law firms may analyze these statistics to identify frequently used contracts and/or modifications. For example, many users may modify a particular paragraph of a rental agreement. The law firm may modify the template to improve the template’s usability.

[0076] Token server system 110 may manage documents other than contract documents.

For example, James may wish to use a single electronic medical card, which may include medical records and/or insurance information. James may create the medical card from a template provided by token server system 110. When James visits a doctor, James may designate access to a portion of the card for the doctor. For example, James may provide permissions to the doctor to modify the medical record portion of the medical card document. Using a link provided by token server system 110, the doctor may enter new data in the medical history and/or provide prescriptions via a modification of the document. The doctor may also provide a uniquely identifiable digital signature for the modification, which may be preserved using blockchain 120. At the pharmacy, James may present the signed prescription which the pharmacist may verify using token server system 110 and/or blockchain 120. In this manner, James may avoid the issue of losing or damaging a physical medical card. Token server system 110 may provide a reliable document management service where modifications may be recorded on blockchain 120.

[0077] Token server system 110 may manage and/or preserve copyright information

and/or other date sensitive documents. For example, Alice may have written a science article. To preserver her copyright, Alice uses token server system 110 to preserve the document using blockchain 120. Based on the immutable nature of blockchain 120, Alice may confirm the copyright date and time and/or rely on blockchain 120 as proof.

[0078] In some embodiments, 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 preserve documents using blockchain 120. These documents may include certificates such as a birth certificate, marriage certificate, driver’s license, college degree, and/or other documents which a user may deem as being official. The preservation on blockchain 120 may indicate that the document is authentic. For example, a university, government agency, and/or other institutions may preserve documents on blockchain 120 related to a user to confirm the authenticity of the document and/or that a particular certificate was actually issued by the institution. Token server system 110 may manage document tokens related to these certificates and/or transmit document tokens to digital wallets corresponding to a user. The user may be able to use token server system 110 to track, view, and/or manage documents throughout a user’s lifetime. Token server system 110 may provide a repository for these documents while maintaining confidentiality and providing verifiable proof of authenticity.

[0079] Other functions and/or operations of token server system 110 will now be further described with reference to the other figures of this disclosure.

[0080] FIG. 2 depicts a flowchart illustrating a method 200 for publishing a document to a blockchain 120, according to some embodiments. Method 200 shall be described with reference to FIG. 1; however, method 200 is not limited to that example embodiment.

[0081] In an embodiment, token server system 110 may facilitate the generation of a document and the preservation of the document on blockchain 120. While method 200 is described with reference to token server system 110, method 200 may be executed 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 executing on a processing device), or a combination thereof.

[0082] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 2, as will be understood by a person of ordinary skill in the art.

[0083] At 205, token server system 110 may receive a document creation request from a user account corresponding to a digital wallet. Token server system 110 may interface with a user device 140 via a user interface 130 to receive the document creation request. For example, token server system 110 may provide graphical user interface (GUI) to be displayed one user device 140. User device 140 may interact with the GUI via API interactions. In some embodiments, token server system 110 may manage user accounts and/or user profiles. A user may log-in to the token server system 110 to generate a document creation request. Token server system 110 may manage digital wallet information corresponding to the user account. The digital wallet may represent a cryptographic wallet and/or may include a corresponding cryptocurrency balance.

[0084] In some embodiments, the document creation request may be initiated from an interaction with a web widget on a web page. For example, a website may include a widget that may trigger token server system 110 to facilitate the creation of a document.

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 property. In cases where the widget is implemented in a webpage, the creation of the document may request digital wallet information for providing electronic transactions. As will be further explained below, the widget may be a document action button. The widget and/or action button may be located on a webpage not managed by token server system 110. For example, the website may be managed by a third-party system and/or administrator while token server system 110 may facilitate document creation in response to a user interacting with the widget. The widget may be a plug-in for the website.

[0085] At 210, token server system 110 may facilitate the creation of a document. Token server system 110 may generate a GUI element to be displayed on user device 140 to allow a user to generate a document. For example, the GUI element may be a fillable form allowing a user to input textual inputs. In some embodiments, the Tillable form may include fields indicating requested textual data. A user may input textual data to designate 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 to provide an offer to another party. The user may provide an identification of the other party to which the document is to be communicated.

[0086] In some embodiments, the user may be viewing a property listing and/or may be considering the purchase of a good or item on a web page. The seller of the property may have provided some initial identification information to list the property for sale. Upon interacting with the GUI element, token server system 110 may generate a template form to allow the user to input contractual terms to generate an offer to purchase the property. Token server system 110 may identify the recipient of the created document based on the listing and the previously provided identification information of the seller.

[0087] While the user may generate a document via typewritten text and/or a Tillable form, the creation of the document may also allow the user to attach additional documents. For example, the user may include links to documents stored in a cloud storage system to be included in the generated document.

[0088] Token server system 110 may also facilitate the creation of a document by

providing a library of templates for a user to select. For example, the templates may be different contracts. The templates may include letters of intent, non-disclosure agreements, leases, real estate contracts, and/or other contracts. Token server system 110 may facilitate the creation of a document by providing access to the library of templates. The user may select a template and may provide additional information and/or modify default terms to match an intended contractual 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 which may be incorporated in the library for sale and purchase by users of the system.

[0089] At 215, token server system 110 may encrypt and/or store an encrypted version of the document. For example, token server system 110 may encrypt the document using a digital key corresponding to the user generating the document and/or the user intended to receive the document. Token server system 110 may facilitate the distribution of keys to the recipient of the document. In some embodiments, the recipient of the document may be a seller of property who has listed property for sale on a web page. In this manner, the seller may have previously provided a cryptographic key to token server system 110 to generate the listing. Token server system 110 may use this key to encrypt the document generated by the offering party. In some embodiments, the offering party may provide a cryptographic key, and token server system 110 may use the offering party’s key to encrypt the document. Token server system 110 may then provide this key to the recipient for decrypting the document.

[0090] In some embodiments, token server system 110 may store an encrypted version of the document in a database. The database may be web-accessible and may be accessed using a link generated at 220. At 220, 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 identifying the storage location of the encrypted document. Because the stored document is encrypted, discovery of the link may still maintain confidentiality due to the encrypted nature of the document.

[0091] At 225, 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 proof of work algorithm or other types of blockchain proof algorithms or methodologies. The hash may further provide proof that a document has not experienced tampering and is a true representation of the document.

[0092] At 230, 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, token server system 110 may use document tokens to segment different permissions related to the document. A document token may be a type of digital token, crypto token, or virtual currency that may be used with digital wallets to designate ownership. A document token, however, may differ from a cryptocurrency as document tokens may be non-fungible and instead may be unique to each created document. In some embodiments, the permissions may correspond to a secrecy designation related to the document as previously described. The secrecy designation may be metadata corresponding to the document token. [0093] At 235, token server system 110 may transmit or transfer the document token to the digital wallet. For example, token server system 110 may transmit the document token to the digital wallet of the offering party who created the document. In some embodiments, a document token may be transmitted to the party receiving the document. As will be further described below, one or more document tokens may be generated and/or disseminated to segment different portions of the document with different permissions.

[0094] At 240, token server system 110 may publish the hash of the document and/or the link to the encrypted version of the document to blockchain 120 using one or more smart contract functions. Publishing the hash of the document and/or the link to the encrypted version of the document may preserve the document and indicate a version of the document that may be trusted as free from tampering. The publication of these elements may further preserve a party’s contractual position. In an embodiment where method 200 is used to generate an initial offer, token server system 110 may preserve this offer at 240 to provide confidence to the party receiving the offer. In an embodiment where method 200 is used to preserve an agreed-upon contract that has been negotiated offline, token server system 110 may publish the hash and the link to preserve the agreed-upon contract.

[0095] In an embodiment, token server system 110 may consume processing tokens to publish the document to blockchain 120. A processing token may be a fungible token asset that may be used as a processing fee to perform a blockchain operation. A processing token may be a cryptocurrency or digital currency. In some embodiments, the processing token may be a utility token. The digital wallet may include a balance of processing tokens used to perform blockchain 120 transactions. Token server system 110 may use processing tokens to publish data to blockchain 120.

[0096] To publish the data to blockchain 120, token server system 110 may use one or more smart contract functions. The smart contract functions may include a set of computer code executed on blockchain 120 or on top of blockchain 120. The smart contract functions may include a set of rules which are agreed upon by the involved parties. Upon execution, if these set of pre-defmed rules are met, the smart contract executes itself to produce an agreed-upon output. Smart contract codes may allow for decentralized automation by facilitating, verifying, and enforcing the conditions of an underlying agreement. Smart contract functions may be automatically executable lines of code stored on blockchain 120 which include predetermined rules. When the rules are met, the code may execute on its own and provide a corresponding output. In an embodiment, the terms of a contract document may be programmed using one or more smart contract functions. In this manner, blockchain 120 may execute contract terms of the document.

[0097] FIG. 3A depicts a flowchart illustrating a method 300A for dividing document permissions, according to some embodiments. Method 300A shall be described with reference to FIG. 1; however, method 300A is not limited to that example embodiment.

[0098] In an embodiment, token server system 110 may facilitate the division of permissions for a document. While method 300A is described with reference to token server system 110, method 300 A may be executed 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 executing on a processing device), or a combination thereof.

[0099] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 3 A, as will be understood by a person of ordinary skill in the art.

[0100] At 305, token server system 110 may receive a request to access an encrypted document. A user may have already created a document using method 200 as described with reference to FIG. 2. Token server system 110 may have previously provided a document token corresponding to the document to the creator of the document and/or to a recipient of the document. Token server system 110 may receive the request based on an accessing of the previously generated link to the encrypted version of the document.

[0101] At 310, token server system 110 may decrypt the encrypted document in response to identifying a corresponding first document token in a first digital wallet associated with the request. For example, the first digital wallet may correspond to the owner of the document. In some embodiments, the owner of the document may have granted a permission to the recipient of the document to modify permissions. In this case, the first digital wallet may correspond to the recipient of the document.

[0102] At 315, token server system 110 may generate a graphical user interface (GUI) displaying the decrypted document. 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.

[0103] At 320, 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 textual portion, such as, for example, body text, header information, a signature block, and/or other portions of the document. The first permission may include read and/or write permissions. These permissions may be designated based on a user identification, user account type, user role, and/or other identifying information. In this manner, a user may indicate that a particular portion is modifiable by a particular user. Similarly, a user may indicate that a particular portion may be read-only. A user may perform this designation using a GUI and/or user interface 130. In some embodiments, the permissions may correspond to a secrecy designation related to the document as previously described. For example, the secrecy designation may be an“open”,“semi secret”, or“secret” designation. The secrecy designation may be metadata corresponding to the document token. This secrecy designation will be further described with reference to FIG. 3B.

[0104] At 325, token server system 110 may identify a second portion of the document and associate a second permission with the second portion. The second portion of the document may differ from the first portion and the second permission may differ from the first permission. In this manner, an owner of a document or another owner given the permission to designate permissions may parse the document into different sections and designate different users to interact with the different sections. In some embodiments, the second permission may correspond to a secrecy designation.

[0105] At 330, token server system 110 may transmit or transfer the document token to a second digital wallet to provide interaction with the first portion according to the first permission. At 335, token server system 110 may transmit or transfer the document token to a third digital wallet to provide interaction with the second portion according to the second permission. In this manner, different users may interact with different portions of the document based on the distributed document token. This tokenization may provide permissions and aid in dividing the document into portion with different access permissions. The permissions may be managed by token server system 110 while the document token may be disseminated to individuals being granted permission to interact with the document. The tokenization may also aid in providing specific modification permissions, such as signatory authority to a particular individual. Because the document token may represent ownership and/or permission to interact with a specific portion of a document, parties may trust that modifications provided in those corresponding portions are from the appropriate parties. Further, owners of the document may segment the document for multiparty use. For example, when multiple parties are involved with a transaction, the document owner may segment each section of the document for each party. In some embodiments, parties may be able to view the document but may only be able to modify portions designated by their corresponding permission.

[0106] In some embodiments, this division of a document may correspond to multiple documents. For example, a document may be a large document with multiple parts or sections for different parties. This larger document may be divided into individual document portions. A document token corresponding to the larger document may be distributed to relevant parties.

[0107] FIG. 3B depicts a flowchart illustrating a method 300B for designating a secrecy setting for a document, according to some embodiments. Method 300B shall be described with reference to FIG. 1; however, method 300B is not limited to that example embodiment.

[0108] In an embodiment, token server system 110 may facilitate the setting of a secrecy designation related to a document. For example, the secrecy designations may be“open”, “semi-secret”, or“secret”. While method 300B is described with reference to token server system 110, method 300B may be executed 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 executing on a processing device), or a combination thereof.

[0109] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 3B, as will be understood by a person of ordinary skill in the art.

[0110] At 340, token server system 110 may receive a document creation request from a user account corresponding to a 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, token server system 110 may facilitate the creation of a first document. The creation of the first document may be performed in a similar manner to 210 as described with reference to FIG. 2. At 350, token server system 110 may create a document token corresponding to the first document. The document token may be created in a manner similar to 230 as described with reference to FIG. 2. At 355, token server system 110 may transmit or transfer the document token to the digital wallet. Token server system 110 may transmit the document token in a manner similar to 235 as described with reference to FIG. 2. At 360, token server system 110 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 smart contract functions. Token server system 110 may execute 215, 220, 225, and/or 240 as described with reference to FIG. 2 to perform 360.

[0111] At 365, token server system 110 may receive a secrecy designation for the first document indicating a condition for revealing the first document to a requesting party or a party attempting to access the first document. As previously described, a user may provide a secrecy designation to designate the document as being open, semi-secret, or secret. The token server system 110 may receive this designation via a user interaction with a graphical user interface (GUI) allowing the user to view and/or interact with the document. For example, to supply a designation, the user may use a drop-down menu and/or select a GUI element. As previously explained, an“open” designation may indicate that a listing document may be openly available to be matched by token server system 110. An“open” designation may allow public accessing and/or browsing of the listing. A“semi-secret” designation may indicate that the listing document may be revealed when a buyer and/or renter has submitted an offer, and 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, “semi-secret” documents may only be searchable by certain fields, e.g., the exact address is kept confidential, but the postcode is searchable.“Semi-secret” documents may include additional conditions prior to being revealed to a user. A“secret” designation may indicate that token server system 110 may reveal the listing document after a real estate property owner has evaluated a request or offer and has provided an affirmative confirmation to reveal the listing document. This“secret” designation may indicate a desire for confidentiality that may include input from the listing party prior to providing identifying information to the offering party.

[0112] At 370, token server system 110 may associate the secrecy designation with the first document via document metadata. This designation may be stored as metadata corresponding to the document. For example, the secrecy designation may be a visibility flag.

[0113] At 375, token server system 110 may receive a second document from the

requesting party satisfying the condition. The second document may be an offer document. For example, the second document may indicate an offer to purchase a good, service, real estate property, and/or other offer. The second document may indicate a particular price, geographic area, house specifications such as bedrooms and bathrooms, and/or other requirements for a property. Token server system 110 may receive this second document and/or aid in facilitating the generation of the second document in response to a requesting party interacting with a document action button as will be further described below.

[0114] At 380, token server system 110 may reveal the first document to the requesting party in response to receiving the second document and determining that the condition is satisfied. Depending on the secrecy designation, token server system 110 may execute a process to reveal the first document to the requesting party. For example, token server system 110 may display the first document on a GUI for viewing by the requesting party. If the secrecy designation is“open”, token server system 110 may allow browsing of the first document and/or public access to the first document. In some embodiments, token server system 110 may provide the“open” document to the requesting party if a condition identified in the second document matches content from the first document.

[0115] A“semi-secret” designation may indicate that the first document may be revealed when a requesting party has submitted a second document, and token server system 110 has identified that content of the second document satisfies conditions corresponding to the first document.“Semi-secret” documents may include additional conditions prior to being revealed to a user. For example, a“semi-secret” document may be a listing of real estate property which may include a price condition. Token server system 110 may reveal the listing document if a buyer provides a sufficient offer price in the second document. Similarly, a user may designate a listing document as“semi-secret” and available only to certain individuals such as particular agents. Token server system 110 receive an indication of the requesting party’s status as the second document to provide access to the first document.

[0116] A“secret” designation may indicate that token server system 110 may reveal the first document after the party generating the first document has evaluated the second document and has provided an affirmative confirmation to reveal the first document. This “secret” designation may indicate a desire for confidentiality that may include input from the party generating the first document prior to providing identifying information to the requesting party. Using these designations, token server system 110 may manage confidentiality related to documents posted on blockchain 120 while still facilitating the preservation of the documents.

[0117] FIG. 4 depicts a flowchart illustrating a method 400 for modifying a document, according to some embodiments. Method 400 shall be described with reference to FIG.

1; however, method 400 is not limited to that example embodiment.

[0118] In an embodiment, token server system 110 may facilitate the modification of a previously generated document. While method 400 is described with reference to token server system 110, method 400 may be executed 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 executing on a processing device), or a combination thereof.

[0119] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 4, as will be understood by a person of ordinary skill in the art.

[0120] At 405, token server system 110 may receive a request to access an encrypted document. Similar to 305, the request may be received from a link access and/or from a user account accessing the encrypted document via a user account profile managed by token server system 110.

[0121] At 410, token server system 110 decrypt the encrypted document in response to identifying a corresponding first document token in a digital wallet associated with the request, wherein the first document token indicates permission to modify a portion of the document. Similar to 310, token server system 110 may identify the presence of a document token in a digital wallet. For example, a user may have previously received this document token. The document token may have provided permission to the user to modify a portion of the document. For example, in an embodiment where a user may sign a contract document, the document portion may allow a user to apply a digital signature to a signature block as a modification of the document.

[0122] At 415, token server system 110 may generate a graphical user interface (GUI) displaying the decrypted document. 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.

[0123] At 420, token server system 110 may receive a modification of the portion of the 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 restricted to modifying the portion corresponding to the document token. For example, the portion may be the signature block of a contract. In some embodiments, the portion may be particular terms of a contract. For example, one or more portions may be negotiated such as rights, obligations, warranties, covenants, and/or other document terms. The modification may be an edit to these terms and may be received via the GUI displaying the decrypted document. Upon modifying the document, a user may select to preserve and/or save this modification. Token server system 110 may perform this modification locally but may also preserve the modification using blockchain 120. To preserve the modification using blockchain 120, token server system 110 may perform similar operations to the generation of a document.

[0124] In particular, token server system 110 may encrypt and store an encrypted version of the modified document at 425; may create link to the encrypted version of the modified document at 430; and may create a hash of the modified document at 435. Similar to the elements described with reference to FIG. 2, token server system 110 may perform these operations to generate a modified version of the document while adhering to the immutable nature of blockchain 120. In some embodiments, the generation of the modified document may be a separate document from the original document. The modified document may be preserved on the blockchain in a subsequent block that may represent an updated version of the document or a counteroffer. In this manner, the changes to the document may be tracked while retaining the benefits provided from publishing updates to the blockchain.

[0125] At 440, token server system 110 may create a second document token

corresponding to the modified document. At 445, token server system 110 may transmit or transfer the second document token to the digital wallet. At 450, token server system 110 may publish the hash of the modified document and the link to the encrypted version of the modified document to a blockchain using one or more smart contract functions.

The creation of the second document token, transmission of the second document token, and publication of the hash and/or link may be similar to the corresponding elements described with reference to FIG. 2.

[0126] Using similar operations for the creation of a document as well as modifying a document, token server system 110 may simplify and/or streamline the document modification process. Rather than maintaining different protocols for document creation and modification, utilizing similar operations may aid in more compact processing with less computational overhead. Even if multiple parties are performing many complex modifications and/or negotiations, token server system 110 may manage and preserve these modifications in a streamlined manner. Further, token server system 110 may perform this management asynchronously to avoid long transaction times when writing to blockchain 120.

[0127] FIG. 5 depicts a flowchart illustrating a method 500 for document negotiation, according to some embodiments. Method 500 shall be described with reference to FIG.

1; however, method 500 is not limited to that example embodiment.

[0128] In an embodiment, token server system 110 may facilitate the negotiation of document terms between different parties. Method 500 may use elements of methods 200, 300A, 300B, and 400 but may further provide details illustrating the interaction between multiple digital wallets. While method 500 is described with reference to token server system 110, method 500 may be executed 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 executing on a processing device), or a combination thereof.

[0129] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 5, as will be understood by a person of ordinary skill in the art.

[0130] At 505, token server system 110 may receive an interaction with a GUI element corresponding to a first account to generate a document to send to a second account. The GUI element may be, for example, a button or widget on a web page. For example, a user of the second account may have listed a property for sale and the GUI element may be an “Offer Now” button allowing a user of the first account to provide an offer document to the second. The user of the first account may provide information and/or text in the manner described above to generate the document.

[0131] At 510, token server system 110 may generate a first document token

corresponding to the document. This document token may represent the ownership of the document by the first account. At 515, token server system 110 may publish a hash of the document and a link to an encrypted version of the document to a blockchain using one or more smart contract functions. This process may be performed in a manner similar to that described with reference to FIG. 2.

[0132] At 520, token server system 110 may transmit or transfer the first document token to a first digital wallet corresponding to the first account and to a second digital wallet corresponding to the 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 a negotiation process.

[0133] At 525, token server system 110 may receive a request to access the document from the second account. For example, the second account may have accessed the link to the encrypted version of the document and/or may have provided log-in credentials to a website and/or cloud platform managed by token server system 110 to access the document. Token server system 110 may utilize user interface 130 to generate a GUI to be displayed on user device 140 for the user of the second account.

[0134] At 530, token server system 110 may receive a modification of the document from the second account to generate a modified document. For example, the user

corresponding to the second account may modify the document using a GUI displayed on user device 140. This modification may represent disagreement with a term in the document. In some embodiments, the modification may include an addition, insertion, deletion, replacement, and/or other document modification 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 modifications via the web browser to token server system 110.

[0135] At 535, 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 FIG. 4, the second document token may indicate a modified document while still preserving the original document corresponding to the first document token. The second document token may be used to designate ownership and/or modification permissions as well as preserve a record of the modifications.

[0136] At 540, token server system 110 may transmit or transfer the second document token to the first digital wallet and the second digital wallet. In this manner, the original offering party as well as the counteroffering party may both access and/or modify the modified document. At 545, token server system 110 may publish a hash of the modified document and/or a link to an encrypted version of the modified document to blockchain 120 using one or more smart contract functions. Similar to the original document, token server system 110 may preserve the modified document in a similar manner in view of the immutable characteristics of blockchain 120. Similar to the other processes described above, token server system 110 may consumer processing tokens to publish data to blockchain 120.

[0137] In some embodiments, method 500 may be used for further counteroffers. For example, parties may continue to negotiate and may continue to modify terms until the parties agree. In this case, the parties may designate that token server system 110 not publish documents or modified documents onto blockchain 120 until an agreement is reached. In some embodiments, the publication of modified documents may occur for each returned counteroffer and/or modification.

[0138] FIG. 6 depicts a flowchart illustrating a method 600 for generating a graphical user interface (GUI) for document negotiation, according to some embodiments. Method 600 shall be described with reference to FIG. 1; however, method 600 is not limited to that example embodiment.

[0139] In an embodiment, token server system 110 may generate a GUI to display contract negotiations for parties of a transaction. An example embodiment of this GUI is depicted in FIG. 7. While method 600 is described with reference to token server system 110, method 600 may be executed 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 executing on a processing device), or a combination thereof.

[0140] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 6, as will be understood by a person of ordinary skill in the art.

[0141] At 605, 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, wherein the document corresponds to a document link stored on blockchain 120. An example embodiment of this first GUI display is depicted in FIG. 7. For example, the first set and the second set of segmented portions 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 preserved on blockchain 120.

[0142] At 610, token server system 110 may generate a second GUI displaying 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 a user device 140 that may differ from a user device 140 displaying the first GUI. For example, an offering party may view the first GUI while a party receiving an offer may view the second GUI. The segmented portions of the document may represent modifications and/or edits provided by either party.

[0143] At 615, token server system 110 may receive a modification of a segmented

portion of the first set of segmented portions via the second GUI. For example, a party receiving an offer document may view the offer document via the second GUI. The offer document may be segmented into different portions. The party may then modify one of these portions. For example, the modification may be a modification to a contractual term and/or other text or objects of the contractual document. The modification may include an addition, insertion, deletion, replacement, and/or other document modification performed by the user of the second account. If the first set of segmented portions is displayed to the left of the second set of segmented portions, user may enter these modifications into these left-side segments.

[0144] At 620, 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 a counteroffer presented by the second party to the first party. For example, the first party may view the first GUI and may view the modifications presented by the second party in the second set of segmented portions. In this manner, the first party may view their own modifications in the first set of segmented portions while viewing the modifications of the second party in the second set of segmented portions. This GUI display may further provide side-by-side scrolling to allow a user to view the segmented portions and compare modified portions. The first GUI may also emphasize the modifications using techniques such as highlighting, color, font size, and/or other GUI elements to indicate a modified term that differs between the two sets of segmented portions. In this manner, the GUI may provide a view of human-readable text and preserved blockchain modifications. This GUI modification may allow users to easily compare offers and/or counteroffers as well as modify documents during a negotiation process to achieve agreeable terms.

[0145] 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. Token server system 110 may generate GUI 700 to be displayed on a user device 140 using user interface 130. As described with reference to FIG. 6, GUI 700 may display documents 710A, 710B with corresponding segmented portions. Document 710A may include the same content as document 710B but may differ in displaying modifications proposed by each party. For example, segmented portion 712A of document 710A may include the same content as segmented portion 712B of document 710B. In some embodiments, document 710A, 710B may be a contract and may include different sections corresponding to the segmented portions 712A-718A, 712B-718B. For example, segmented portion 716A and 716B may correspond to warranties granted by a seller. Segmented portion 714A and 716B may include an offer price. In this manner, GUI 700 may depict two versions of the contract for users to make and/or view modifications. [0146] A first party viewing GUI 700 may supply modifications to document 710A. For example, the user may edit segmented portion 714A to alter an offer price. The segmented portions may include editable text and/or fillable forms for providing information. For the first party viewing GUI 700, document 710B may include modifications generated by a second party. For example, document 710B may include counteroffers on contractual terms. GUI 700 may display both modifications generated by the first party and the second party to allow for a comparison of modifications.

[0147] In some embodiments, token server system 110 may generation a version of GUI

700 for the second party. Token server system 110 may flip the positions of documents 710A and 710B. For example, the second party may edit document 710A as displayed on a user device 140 corresponding to the second user. This modification may appear as a modification of document 710B for the first user viewing GUI 700 on a user device 140 corresponding to the first user. In this manner, independent of the user role in a transaction, the user may perform document modifications in document 710A while viewing other parties’ edits in document 710B.

[0148] While two documents 710A, 710B may be depicted in FIG. 7, other versions of document 710 may be displayed in multiparty transactions and/or negotiations. For example, GUI 700 may depict multiple versions of the document with different modifications from different parties.

[0149] GUI 700 may provide a human-readable interface for interacting with documents managed via document tokens and a blockchain. As explained above, the documents and/or modified documents may correspond to document tokens with corresponding permissions. For example, parties may be restricted to modifying only certain segmented portions. Further, modifications may be saved and/or published to a blockchain to preserve a record of the modifications. In this manner, GUI 700 may provide a manner to view and/or interact with documents managed using blockchain 120.

[0150] In addition to displaying the segmented portions, GUI 700 may include one or more navigation interfaces 720 A, 720B. Navigation interfaces 720 may provide document manage GUI elements provided by token server system 110. For example, navigation interface 720 may include GUI icons or buttons to identify, view, and/or select contracts. For example, a user may be negotiating multiple contracts, and navigation interfaces 720 may allow the user to select and view different contracts. [0151] Navigation interfaces 720 may include a library link to allow a user to create a new document or contract. In some embodiments, the user may generate documents and supply a customized segmentation to portions of the document. Similar to the segmentation described above with reference to FIG. 3 A, the user may specify permissions corresponding to the portions. In some embodiments, token server system 110 may provide selectable document and/or contract templates with pre-formed content and/or segmentation. Users may select and/or modify these templates.

[0152] Navigation interfaces 720A, 720B may also include a messaging interface, a list of tasks for the user, a management screen for managing a digital wallet, and/or other GUI elements that may be used during the document modification and/or negotiation process.

[0153] 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“Offer Now”;“Lease Now”;“Rent Now”; “Apply Now”;“Buy Now”; List Now”;“Manage Now”; and/or other words indicating the generation of a document.

[0154] GUI 800A may be a web browser and/or may include a web page enabled to include widgets and/or GUI buttons or icons. GUI 800A may include an address entry portion 810A for specifying a website. A 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 rent. The user may be searching for a home to purchase and/or rent and may use GUI 800A to view information related to the real estate property. Further, GUI 800A may include document action button 850A which may initiate a document generation process and will be further described below. In some embodiments, websites listing real estate property may 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, token server system 110 may generate GUI 800A and/or manage web sites related to real estate transactions.

[0155] GUI 800A may display an image 820A, text data 830A, and/or additional details

840A. The additional details 840 may include descriptions and/or additional text information that may be formatted differently than text data 830 A. In some embodiments, a user may enter and/or navigate to a web page listing a property for sale.

In this case, image 820A may depict an image of the property, text data 830A may include high level details related to the property, and additional details 840A may include a paragraph description and/or other bullet points related to the property. The user may view this information to learn about the property.

[0156] GUI 800A may include a document action button 850A. Document action button

850A may be a GUI element that may provide an interface with token server system 110. For example, document action button 850A may be a widget embedded in a webpage displaying a property listing. In some embodiments, document action button 850A may display the words“Offer Now”;“Lease Now”;“Rent Now”;“Apply Now”;“Buy Now”; and/or other terms to indicate to a user that a document may be generated. In some embodiments, document action button 850A may be used for other documents such as to list a property using a“List Now” and/or a“Manage Now” option.

[0157] Upon interacting with document action button 850A via a selection, press, and/or click, the widget may generate a call to token server system 110 to provide a document generation process. For example, token server system 110 may provide a Tillable form and/or template that may be displayed on GUI 800A for the user to draft a document and/or provide information into a template. Token server system 110 may provide an overlay on GUI 800A for a user to enter this information. Upon entering the requested information, token server system 110 may transmit the offer to an intended recipient. Token server system 110 may also generate a corresponding document token and/or preserve the document on blockchain 120.

[0158] In this way, GUI 800A provides various technical improvements. GUI 800A may provide a streamlined manner for document generation preserving generated documents using blockchain 120. Document action button 850A, which may be an“Offer Now”; “Lease Now”;“Rent Now”;“Apply Now”;“Buy Now”; List Now”; and/or“Manage Now” button, may allow a user to quickly generate a document using fewer GUI interactions. The reduction of interactions may aid in reducing wasted computational resources on unnecessary web navigation. Further, document action button 850A may aid in reducing network traffic due to the reduced number of interactions.

[0159] As previously explained, document action button 850A may be a widget and/or plug-in embedded in a third party website or webpage. Document action button 850A may be located on a webpage not managed by token server system 110. For example, the website may be managed by a third party system and/or administrator while token server system 110 may facilitate document creation in response to a user interacting with document action button 850A. Document action button 850A may be used to generate documents related to transactions for goods, services, and/or real estate. Further, document action button 850A may initiate the document tokenization and blockchain preservation process facilitated by token server system 110. In some embodiments, document action button 850A may be used to facilitate a transaction process which may include offers and counteroffers. The transaction process may include offers,

negotiations, acceptance, and/or closing. Via interaction with document action button 850A, users may generate documents and/or transactions via a decentralized marketplace.

[0160] FIG. 8B depicts a block diagram of a graphical user interface (GUI) 800B for link management and generating a 1-Link process, according to some embodiments. A user may use GUI 800B to manage links and/or documents transmitted to other parties. For example, a buyer may provide offers to purchase real estate using a link. GUI 800B may allow the buyer to manage different offers. Similarly, a seller may use GUI 800B to manage offers for sale. These offer documents may also be managed via a link. Parties may use GUI 800B to generate documents and/or links corresponding to the documents as well as manage the recipients of the documents and/or links.

[0161] A user may use GUI 800B to manage links, such as, for example, links to property listings and/or links to other documents and/or offer documents created by a user using token server system 110. A link may represent a document that may be preserved by blockchain 120 which may further include access to other documents preserved by blockchain 120. In this manner, a link may be a delivery system for other blockchain- based documents, and the link itself may be a blockchain-based document.

[0162] 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 as described with reference to FIG. 9 describes an example embodiment of generating a message including links to blockchain-managed documents. In some embodiments, generating a link may include generating a link to a document managed by token server system 110 using blockchain 120. For example, the links may provide access to one or more documents preserved using blockchain 120. [0163] A user may access token server system 110 and/or use GUI 800B when generating multiple offer messages and/or transmitting multiple documents. GUI 800B may arrange one or more links into rows and columns to manage the links. The links may be links to a web page and/or electronic message with a corresponding document. For example, FIG. 8C may depict a message interface which may be accessed from a link.

[0164] Returning to GUI 800B, a user may use GUI 800B to create a link to a document and/or create a document with a corresponding link. For example, the user may interact with create link button 870B displayed on GUI 800B. This document may allow the user to input text and/or may be a Tillable form. Create link button 870B may be an icon and/or button allowing the user to create a new link. The creation of a new link may include a fillable form, wizard, and/or other prompting to allow the user to specify information for different fields related to the links. GUI 800B may also include management for received links.

[0165] GUI 800B may include several fields for organizing links that have been

generated. For example, GUI 800B may include a selection field 810B, an address field 820B, a recipient field 830B, a role field 840B, a sent detail field 850B, and/or interaction buttons 860B. Selection field 810B may allow a user to select one or more links. This selection may allow for management of multiple links. Address field 820B may include details related to a physical address of a property. 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 the link. For example, the recipient field may include one or more email addresses. Role field 840B may list a role corresponding to the recipient and/or user generating the link. For example, in a real estate transaction, role field 840B may include roles such as“buyer”,“seller”,“agent”,“lender”, and/or other roles. Sent detail field 850B may display one or more items related to the transmission of the link. For example, sent detail field 850B may indicate whether the link was sent or whether the link is a draft. In some embodiments, sent detail field 850B may also indicate a sender of the link. Interaction buttons 860B may include GUI elements allowing a user to interact with a link. For example, interaction buttons 860B may include the ability to edit a link and/or document corresponding to the link, copy the link, view the link, view messages related to the link, and/or other link operations. In some embodiments, token server system 110 may facilitate message related to documents and a“view message” interaction button 860B may allow a user to view the corresponding message. While these field have been described, GUI 800B may also use other fields to organize links and/or corresponding documents.

[0166] In this way, GUI 800B may provide a streamlined manner for link creation and/or link management to deliver blockchain-preserved documents. Users creating a link via create link button 870B may access a 1-Link process to quickly generate a blockchain- preserved document associated with a link that may include links to other blockchain- preserved documents. In this manner, the use of GUI 800B and/or the 1-Link process may provide for the generation of linked and blockchain-preserved documents while also reducing the number of user interactions and computational transactions while also reducing network traffic.

[0167] The 1-Link process may provide a decentralized process for buying, selling,

and/or trading goods and/or services online. In some embodiments, users may avoid the use of a virtual marketplace or existing e-commerce website. Users may perform peer-to- peer transactions, including offers and counteroffers, using the 1-Link process. The link generated from the 1-Link process may be used, transmitted, and/or dispersed in electronic communications including but not limited to text messages, emails, websites, social media, chat room, instant messages, and/or voice transmissions. In some embodiments, the link may be communicated via analog processes such as a hand-written message.

[0168] The link may be integrated into other processes and/or integrate other processes including calendar and scheduling applications, language translation processes, payment platforms, messaging and negotiation processes, a chat room application, video and/or audio chat, and/or advertising or display elements. In some embodiments, the users may select a form of communication that may be a legally binding electronic trail of communication. The link may also provide users with the ability to provide payments using fiat money, digital currency, and/or other forms of currency.

[0169] Existing e-commerce websites require users to use an online marketplace for users to sell, buy, lease, and trade goods and services in exchange for financial compensation or in-kind goods and services. Buyers and sellers use these existing platforms to advertise, purchase, trade, place bids, initiate, and/or finalize exchanges. The host marketplace may also charge users an extra cost for commission for usage of the marketplace. The host marketplace may further restrict users to following the

specification of the marketplace when promoting the goods for sale and/or terms and conditions of a transaction. The host marketplace may restrict users from marketing to the audience that they believe are more likely to buy their products or offer them services they need.

[0170] 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. Users may provide a link to potential buyers to a document listing which may offer goods and/or services for sale so that the parties may execute a transaction directly while avoiding the use of an online marketplace.

[0171] As previously described, a seller may use the 1-Link process to generate a link for transmission to a buyer. In this manner, the seller may avoid the use of a virtual marketplace as a host for promotion of goods or services for sale. Further, sellers may avoid multiple steps involved in virtual marketplace transactions. Using the 1-Link process, sellers may generate a link, customized email, and/or other communication method that embeds the 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 offer for sale, and/or other transaction information, such as, for example, pricing, contact information, payment options, and/or other details. Buyers may purchase the product or services using the link and/or enter into a negotiation with the seller to modify the terms of sale. As will be further described below, the buyer may use a document action button accessible via the message or link to generate a document for negotiation.

[0172] In some embodiments, a buyer may use the 1-Link process to generate a link and/or message for purchasing goods and/or services. The buyer may use the 1-Link process even if a seller has not previously created a link in advance of the transaction.

The buyer may use the 1-Link process when the buyer searches for and/or identifies a product or service and creates a link describing the desired purchase. In some

embodiments, the link may describe a good or service for which the buyer is searching. The buyer may transmit this link to the seller which may allow the seller to offer goods and/or services which may satisfy the buyer’s request. The parties may then perform the transaction via the 1-Link process which may generate corresponding document tokens. Examples of this embodiment are further described below with reference to FIG. 10, FIG. 11 A, and FIG. 1 IB which describe a demand-driven value chain.

[0173] Users may also use the 1-Link process to trade goods and/or services. When

trading, parties may rely on the negotiation and/or counteroffer elements of the 1-Link process. For example, parties may modify terms of a document including what goods and/or services are being traded.

[0174] In this manner, the 1-Link process may provide a personalized marketplace that may democratize and/or decentralize the transaction process. The 1-Link process may aid in lead generation, marketing, promoting, selling, buying, deal-making, and/or trading goods and/or services without relying on a third-party sales platform. For developing countries where online marketplaces may be limiting, the 1-Link process may provide a manner for conducting transactions that may not have previously existed. Further, the 1- Link process may provide users with convenience, efficiency, cost-savings, and/or trust via blockchain-based document preservation. The 1-Link process may also be used in other contexts such as, for example, political campaigns. The 1-Link process may provide a manner for donors to donate to a political campaign.

[0175] FIG. 8C depicts a block diagram of a graphical user interface (GUI) 800C of a message 8 IOC including a document action button 850C and document links 840C, according to some embodiments. GUI 800C may include an electronic mail message that may be generated using the link management elements of GUI 800B. The message 8 IOC may represent a blockchain-based document that may include links to other blockchain- based documents via document links 840C.

[0176] A user may view GUI 800C in preparation for sending an offer document to a party. For example, a real estate agent or a seller may prepare message 810C in preparation for transmission to a potential buyer or interested buyer of real estate.

Including document action button 850C in message 8 IOC may allow a potential buyer to generate an offer document in response to message 8 IOC and provide an offer to the seller. Further, the potential buyer may also access document links 840C to access documents preserved on blockchain 120 that may aid in the buyer’s decision making process and/or offer document generation process. While a seller/buyer example is described, GUI 800C may also be used in the reverse context where the buyer is transmitting message 810C, in a renter/landlord context, and/or in a purchaser/seller context for goods and/or services.

[0177] To generate message 810C, the user may be guided by prompts provide by token server system 110 to input one or more links. For example, the user may have listed a property on a web page with a corresponding address. This address may be requested and compiled into GUI 800C via address display 830C. A user may interact with, select, press, and/or click address display 830C to navigate to the web page listing the property. Message 8 IOC may also include text element 820C which may include text entered by a user. For example, the text may be a personalized message providing an introduction to the documents linked in message 8 IOC.

[0178] Message 810C may include document links 840C. Document links 840C may include links to stored documents allowing a user to download the documents. In some embodiments, document links 840C may represent other documents preserved by blockchain 120. These documents may be tokenized in the manner described above. In this manner, access may be restricted based encryption, but a user accessing a document link 840C may access the document based on the permissions provided by the document token. In an embodiment, a bank may send a new client a link that may contain several confidential documents for review and signing. The bank may grant permission specifically to the client as the sole party allowed to view and/or modify the documents. The client may access the documents securely by using the encrypted key to review and sign the documents. Using token server system 110, the bank may avoid security concerns during the document exchange and may ensure that the documents are securely delivered to the right person. In some embodiments, a law enforcement agency may also use the link for collaboration to share documents with both internal and external stakeholders for a case investigation, or a criminal charge.

[0179] Message 810C may further include document action button 850C. Document action button 850C may be similar to document action button 850A as described with reference to FIG. 8 A. Document action button 850C may be embedded in message 8 IOC and may allow a user to generate a document via a call to token server system 110. Upon interacting with document action button 850C, a web browser may be opened and the user may generate a document to be stored on blockchain 120. For example, this document may be an offer to purchase property.

[0180] Message 810C may be accessed via a link generated by token server system 110 and/or via an electronic message delivered by token server system 110. Message 8 IOC may represent a document which may also be stored on blockchain 120. This document may include links to other documents managed by token server system 110 and preserved using blockchain 120. Message 810C may further include document action button 850C allowing a user to generate a new document. In this manner, message 8 IOC may illustrate a document preserved by a blockchain 120 within another document preserved by blockchain 120. Further message 810C may illustrate the ability for a document preserved by blockchain 120 to provide the capability to a user to generate another blockchain-preserved document. As previously described, the inclusion of document action button 850C may streamline the document generation process and may allow a user to quickly generate a blockchain-preserved document with fewer navigation interactions. The reduction of interactions may aid in reducing wasted computational resources on unnecessary web navigation. Further, document action button 850C may aid in reducing network traffic due to the reduced number of interactions.

[0181] In some embodiments, message 8 IOC may be used for secure document and/or message delivery. For example, message 8 IOC may not include document action button 850C. A user may create an email document and store a document token delivered through the 1-Link process. A recipient may open the email and generate a second document token to sign the email. The signature may be an acknowledgement of receiving the email and/or an agreement to content of the email that may require a signature. The generation of a second document token may indicate that the recipient has viewed the document which may provide auditability and/or traceability. In this manner, message 8 IOC may be used as a secure document delivery mechanism.

[0182] FIG. 9 depicts a flowchart illustrating a method 900 for generating a message including a document action button and document links, according to some embodiments. Method 900 shall be described with reference to FIG. 1; however, method 900 is not limited to that example embodiment. Method 900 may be an embodiment of the 1-Link process. [0183] In an embodiment, token server system 110 may generate a link and/or a message allowing a user to access blockchain-preserved documents as well as a document generation process. While method 900 is described with reference to token server system 110, method 900 may be executed 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 executing on a processing device), or a combination thereof.

[0184] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 9, as will be understood by a person of ordinary skill in the art.

[0185] At 905, 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 display screens requesting information from the user and/or link information that may be compiled into a message and/or other data structure that may allow a user to access blockchain-preserved documents.

[0186] At 910, token server system 110 may receive an interaction with the first icon.

This first icon interaction may initiate a document creation process similar to those described above. This document may be preserved on blockchain 120 using the techniques described above, which may include encryption, hashing, and/or document tokenization.

[0187] At 915, token server system 110 may generate an interface for attaching one or more documents to a link. For example, the interface may be one or more display screens requesting information and/or requesting that a user upload documents. In some embodiments, the interface may be a Tillable form. In some embodiments, the one or more documents may be personal documents including confidential information. For example, in a real estate transaction, the documents may relate to a user’s credit history or loan approval amount.

[0188] At 920, 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 a document location by providing a link to the document. Based on the information provided, token server system 110 may identify the document. As previously explained, the user may upload the one or more documents.

[0189] At 925, token server system 110 may generate a document token for each of the one or more documents. Token server system 110 may generate a document token as previously described. For example, token server system 110 may apply encryption, hashing, document tokenization, and/or digital wallet depositing. Token server system 110 may encrypt and store an encrypted version of each of the one or more documents; create blockchain links to the encrypted version of each of the one or more documents; and generate a cryptographic hash of each of the one or more documents.

[0190] At 930, token server system 110 may publish blockchain links to the one or more documents to blockchain 120. Publishing the blockchain links may preserve the attached documents. Similar to the processes described above, the blockchain links may link to encrypted versions of the documents to preserve confidentiality.

[0191] At 935, token server system 110 may generate a message corresponding to the link, wherein the message includes the blockchain links and a second icon to initiate a document generation process to generate a response document to be published on blockchain 120. The message may be, for example, an email message as depicted in GUI 800C. The blockchain links may be document links 840C and the second icon may be document action button 850C.

[0192] As previously described, this message may be a delivery system that transmits blockchain-preserved documents to an individual and may also provide the individual with the ability to generate a response document. For example, the message may be an offer document which may include other supporting documents. The offer document may indicate a desire to purchase a property. The supporting documents may include, for example, a document indicating a user’s pre-approval for a loan amount. The lender may be published the 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 counteroffer, an acceptance of the offer, and/or other document having a digital signature corresponding to the seller. Token server system 110 may manage the response document and may publish the response document on blockchain 120 in the manner described above. [0193] FIG. 10 depicts a block diagram of a document chain environment 1000 providing a demand-driven value chain, according to some embodiments. Document chain environment 1000 may include token server system 1010 which may operate in a manner similar to token server system 110. Document chain environment 1000 may also include blockchain 1020 which may operate in a manner similar to blockchain 120. Token server system 1010 may interact with several account profiles and different types of account profiles such as store accounts 1030, enterprise accounts 1040, and/or user accounts 1050.

[0194] These different accounts may represent different account types. For example, user account 1050 may represent user account profiles for consumers. Store account 1030 may represent a retailer which may be wholesale or retail. The retailer may have a physical location and/or may be an online retailer. Enterprise account 1040 may represent businesses which may not sell consumer goods and/or governments.

[0195] As seen from document chain environment 1000, each account may interact with other accounts of the same type and/or of a different type via token server system 1010. Accounts may exchange documents including offer documents between account types. User accounts 1050 may submit offers, applications, and/or proposals to store accounts 1030 and/or enterprise accounts 1040. In some embodiments, user accounts 1050 may submit these offers even when store accounts 1030, enterprise accounts 1040, and/or other user accounts 1050 may not list a good, service, and/or real estate property for sale. In this manner, token server system 1010 may provide a decentralized marketplace for the exchange of goods, services, and/or contractual obligations that may be initiated regardless of account type. Token server system 1010 may provide self-sufficiency and autonomy among the parties to negotiate transactions.

[0196] Further, an offer, acceptance, and/or negotiation may not be limited by the role of a particular account. For example, each of store accounts 1030, enterprise accounts 1040, and/or user accounts 1050 may be offering parties and/or parties receiving offers.

Similarly, each party may provide counteroffers to transactions. In this manner, token server system 1010 may facilitate a decentralized marketplace between different accounts and/or account types. Further, token server system 1010 may facilitate multiparty transactions among these accounts and account types.

[0197] In some embodiments, token server system 1010 may further provide a demand- driven value chain. The demand-driven value chain may allow buyers to generate offers and/or offer documents in industries traditionally utilized a supply-driven transaction marketplace. For example, traditional online retailers may list items and receive purchase orders from buyers. In a demand-driven value chain, a buyer may submit an offer for goods, services, and/or real estate even if a seller has not provided a listing. Similarly, renters may provide offers to rent a property from a landlord. Using the demand-driven value chain, parties such as buyers, sellers, renters, landlords, agents, consumers requesting a service, and/or service providers may initiate offers and/or generate offer documents.

[0198] In this manner, token server system 1010 may facilitate offers, counteroffers, and/or negotiations between parties independent of roles or account types. Buyers and/or sellers may initiate transactions. Further, different party and/or account types, such as businesses, stores, enterprises, and/or consumers may use the demand-driven value chain to initiate and/or facilitate transactions with blockchain preservation. In this manner, the token server system may support a decentralized marketplace for transactions using a blockchain. Further, token server system 1010 may provide flexibility for facilitating transactions from different parties with different roles. In this manner, token server system 1010 may provide a one-stop-shop where parties may showcase, initiate, negotiate, consummate, and/or refer deals and/or acquire services in a decentralized manner.

[0199] In this demand-driven model, parties who require goods and services may avoid visiting a particular marketplace, listing website, and/or an aggregated website to search for specific goods and services. Parties may conveniently initiate and/or generate a document token, referred to as a demand token, which may define their demand desires. For example, a party may wish to purchase a new car and generate a document specifying the desire for a new car, the make being a Toyota, the color being red, a price ranging from $25,000 to $28,000, and/or a delivery option to Brooklyn.

[0200] Using the demand token, token server system 1010 may search for and/or identify other document tokens, referred to as supply tokens, with supply specifications for goods and services closely matching the specified demands. Those requirements or supply specifications may be stored in the demand token’s metadata layer as searchable fields. Token server system 1010 may notify possible supply accounts that demands are received for goods and services they may be able to provide. In some embodiments, a busy mother may attempt to find a nanny service for two days while she travels. The mother may generate a demand document, and token server system may generate a demand token. Token server system 1010 may search for and/or identify nannies who have generated supply documents and corresponding supply tokens with content closely matching the busy mother’s requirements. This systematic matching of demand to supply may eliminate several steps required from parties on both demand and supply sides, reduce marketing costs for suppliers as well as the search time and effort for parties who require goods and services.

[0201] FIG. 11 A depicts a flowchart illustrating a method 1100A for role-based

document generation, according to some embodiments. Method 1100 A shall be described with reference to FIG. 10; however, method 1100A is not limited to that example embodiment.

[0202] In an embodiment, token server system 1010 may facilitate negotiations and/or counteroffers between parties of different account types. While method 1100A is described with reference to token server system 1010, method 1100 A may be executed 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 executing on a processing device), or a combination thereof.

[0203] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 11 A, as will be understood by a person of ordinary skill in the art.

[0204] At 1105, token server system 1010 may receive a document creation request from a first account corresponding to a first digital wallet, wherein the first account

corresponds to a first account type. The first account type may be, for example, a store account 1030, enterprise account 1040, or user account 1050. The document creation request may have been received from an interaction with a GUI element such as a document action button.

[0205] At 1110, token server system 1010 may facilitate the creation of a first document.

This document creation process may be similar to the other document creation processes previously described. At 1115, token server system 1010 may create a document token corresponding to the first document. At 1120, token server system 1010 may transmit the document token to the first digital wallet. The creation of the document token as well as the transmission of the document token to the first digital wallet may also occur in a manner previously described. At 1125, token server system 1010 may publish a hash of the first document and a link to the encrypted version of the first document to a blockchain using one or more smart contract functions. This may also be performed in the manner previously described.

[0206] At 1130, token server system 1010 may transmit a notification to a second account corresponding to a second digital wallet, wherein the second account corresponds to a second account type that differs 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 transmitted to the second digital wallet similar to the first digital wallet depending on the permissions designated.

[0207] The second account type may differ from the first account type. This difference may demonstrate the different positions and roles of the offering party and the party receiving the offer. For example, a store account 1030 may transmit an offer document to a user account 1050 indicating an offer to sell a product. Similarly, the user account 1050 may transmit an offer document to 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. While FIG. 11 A describes an example embodiment where the account types differ, in some embodiments, the account types may be the same account type.

[0208] At 1135, token server system 1010 may facilitate the creation of a second

document by 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 counteroffer with modified terms. Upon creating the second document, token server system 1010 may perform the encryption, hashing, and/or tokenizati on previously described. Token server system 1010 may further deliver the second document to the first account. In this manner, the parties may negotiate and/or perform transactions in a peer-to-peer manner that preserves contractual terms via the immutability of blockchain 1020. [0209] FIG. 1 IB depicts a flowchart illustrating a method 1100B for demand matching, according to some embodiments. Method 1100B shall be described with reference to FIG. 10; however, method 1100B is not limited to that example embodiment.

[0210] In an embodiment, token server system 1010 may perform a demand-driven matching and/or identification of documents. While method 1100B is described with reference to token server system 1010, method 1100B may be executed 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 executing on a processing device), or a combination thereof.

[0211] It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in FIG. 1 IB, as will be understood by a person of ordinary skill in the art.

[0212] At 1140, token server system 1010 may receive a plurality of supply documents.

The supply documents may indicate the availability of a good, service, a real estate property, and/or other offer for sale. The plurality of supply documents may be supplied by different users interfacing with token server system 1010. Token server system 1010 may preserve these supply documents using blockchain 1020. The supply documents may have been generated using a document action button as previously described. The content of the plurality of supply documents may vary. For example, the supply documents may describe a listing for sale of a real estate property. In some embodiments, the supply documents may list automobiles and/or nanny services. Users may indicate a secrecy designation corresponding to the supply documents in the manner previously described.

[0213] At 1145, token server system 1010 may create a supply document token

corresponding to each of the plurality of supply documents. These supply document tokens may be similar to the previously described document tokens. Token server system 1010 may transmit the supply document tokens to digital wallets corresponding to the owner of each supply document.

[0214] At 1150, token server system 1010 may receive a demand document including specifications for a desired transaction. For example, the demand document may list specifications for a good, service, or real estate. A user may be searching for a new car and may input a price and/or other details related to a desired car. In some embodiments, a user may be searching for nanny services and may supply specifications such as a desired number of years of experience. These users may generate a demand document via token server system 1010 to provide this information.

[0215] At 1155, token server system 1010 may create a demand document token

corresponding to the demand document. Token server system 1010 may create this type of document token similar to other document tokens previously described. At 1160, token sever system 1010 may transmit or transfer the demand document token to a digital wallet. This transmission may occur similar to other transfers of a document token to a digital wallet as previously described. In some embodiments, the digital wallet may correspond to a user generating the demand document.

[0216] At 1165, token server system 1010 may analyze content of the demand document to identify the specifications. For example, token server system 1010 may identify field values corresponding to the content of the demand document. For example, the demand document may be a tillable form and the values may be extracted. In some embodiments, token server system 1010 may use an optical character recognition application and/or a machine learning algorithm to identify semantic information corresponding to the specifications.

[0217] At 1170, token server system 1010 may identify a supply document of the

plurality of supply documents including content corresponding to the specifications of the demand document. Based on an analysis of the specifications, token server system 1010 may identify one or more matching and/or near matching supply documents including content satisfying the criteria of the specifications. For example, the supply document may include a price of real estate or years of experience satisfying criteria of the demand document. Token server system 1010 may perform this matching based on the extracted fields of the demand document with comparable fields from the supply documents. In some embodiments, token server system 1010 may identify searchable fields in a metadata layer corresponding to supply documents and/or supply document tokens. In some embodiments, token server system 1010 may utilize a machine learning technique to analyze the supply documents to identify a match or near-match based on the configuration and/or training of a machine learning algorithm. Token server system 1010 may notify the owner of the identified supply document that their particular supply document has been selected.

[0218] At 1175, token server system 1010 may transmit or transfer a supply document token corresponding to the identified supply document to the digital wallet. As previously described, the digital wallet may correspond to the user providing the demand document. Token server system 1010 may transmit the supply document token in a manner similar to that previously described. By transmitting the supply document token, the user corresponding to the digital wallet may view the supply document. This permission may be identified due to the inclusion of the supply document token in the digital wallet. In some embodiments, token server system 1010 may confirm that a secrecy designation provides permission to share the supply document with the user providing the demand document. As previously described, this configuration of receiving offer documents may aid in facilitating a demand-driven transaction system.

[0219] Various embodiments may be implemented, for example, using one or more well- known computer systems, such as computer system 1200 shown in FIG. 12. One or more computer systems 1200 may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

[0220] Computer system 1200 may include one or more processors (also called central processing units, or CPUs), such as a processor 1204. Processor 1204 may be connected to a communication infrastructure or bus 1206.

[0221] Computer system 1200 may also include user input/output device(s) 1203, such as monitors, keyboards, pointing devices, etc., which may communicate with

communication infrastructure 1206 through user input/output interface(s) 1202.

[0222] One or more of processors 1204 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0223] Computer system 1200 may 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 have stored therein control logic (i.e., computer software) and/or data. [0224] Computer system 1200 may also include one or more secondary storage devices or memory 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, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.

[0225] Removable storage drive 1214 may interact with a removable storage unit 1218.

Removable storage unit 1218 may include 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, compact disk, DVD, optical storage disk, and/ any other computer data storage device. Removable storage drive 1214 may read from and/or write to removable storage unit 1218.

[0226] Secondary memory 1210 may include other means, devices, components,

instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 1200. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 1222 and an interface 1220. Examples of the removable storage unit 1222 and the 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.

[0227] Computer system 1200 may further include a communication or network interface

1224. Communication interface 1224 may enable computer system 1200 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 1228). For example, communication interface 1224 may allow computer system 1200 to

communicate with external or remote devices 1228 over communications path 1226, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 1200 via communication path 1226.

[0228] Computer system 1200 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

[0229] Computer system 1200 may be a client or server, accessing or hosting any

applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on premise” cloud-based solutions);“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 a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

[0230] Any applicable data structures, file formats, and schemas in computer system 400 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

[0231] In some embodiments, a tangible, non-transitory apparatus or article of

manufacture comprising a tangible, non-transitory computer useable 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 foregoing. 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.

[0232] Based on the teachings contained in this disclosure, it will be apparent to persons 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 can operate with software, hardware, and/or operating system implementations other than those described herein.

[0233] It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

[0234] While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.

[0235] Embodiments have been described herein with the aid of functional building

blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.

[0236] References herein to“one embodiment,”“an embodiment,”“an example

embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can 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 would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can 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 can 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, can 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.

[0237] The breadth and scope of this disclosure should not be limited by any of the

above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.