WO2014056185A1 - Notarisation basée sur des transactions de devises - Google Patents

Notarisation basée sur des transactions de devises Download PDF

Info

Publication number
WO2014056185A1
WO2014056185A1 PCT/CN2012/082851 CN2012082851W WO2014056185A1 WO 2014056185 A1 WO2014056185 A1 WO 2014056185A1 CN 2012082851 W CN2012082851 W CN 2012082851W WO 2014056185 A1 WO2014056185 A1 WO 2014056185A1
Authority
WO
WIPO (PCT)
Prior art keywords
remittances
account
hash code
digits
document
Prior art date
Application number
PCT/CN2012/082851
Other languages
English (en)
Inventor
Zhen Xiao
Original Assignee
Empire Technology Development Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Empire Technology Development Llc filed Critical Empire Technology Development Llc
Priority to PCT/CN2012/082851 priority Critical patent/WO2014056185A1/fr
Priority to US14/006,310 priority patent/US9280792B2/en
Publication of WO2014056185A1 publication Critical patent/WO2014056185A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management

Definitions

  • the embodiments described herein pertain generally to notarizing, to ensure sustainable validation, of digital content by leveraging existing infrastructures for currency transactions.
  • a method includes generating a first digital code that represents a content of a document created by a first user; and notarizing the creation of the document by triggering a plurality of remittances from a first account associated with the first user to a second account, with each of the plurality of remittances time-stamped and a respective amount of each of the plurality of remittances indicating a corresponding portion of the first digital code.
  • a computer-readable medium stores instructions that, when executed, cause one or more processor to perform operations that include receiving a document having digital content, generating a first hash code having a plurality of digits based on the digital content of the document, and triggering a plurality of remittances from a first account to a second account such that at least a portion of an amount of each remittance indicates the one or more digits of a corresponding portion of the first hash code.
  • a system includes a first component that is configured to generate a first hash code having a plurality of digits based on a digital content of a document, a second component that is configured to segment the first hash code into a plurality of portions each having one or more digits of the plurality of digits of the hash code, and a third component that is configured to trigger a plurality of remittances from a first account to a second account such that at least a portion of an amount of each remittance indicates the one or more digits of a correspond ing portion of the first hash code.
  • FIG. 1 shows an example system configuration in which notarization based on currency transactions may be implemented, arranged in accorda nce with at least some embodiments described herein;
  • FIG. 2 shows an example configuration of an application for implementing notarization based on currency tra nsactions, arra nged in accordance with at least some embodiments described herein;
  • FIG. 3 shows an example configuration of a processing flow of operations for notarization based on currency transactions, arranged in accordance with at least some embodiments described herein;
  • FIGS. 4(a) - 4(d) show an example progression of digital data as processed in at least one flow of operations for notarization based on currency transactions, in accordance with at least some embodiments described herein;
  • FIG. 5 shows a block diagram illustrating an example computing device by which various example solutions described herein may be implemented, a rranged in accordance with at least some embodiments described herein.
  • FIG. 1 shows an example system configuration 100 in which notarization based on currency transactions may be implemented, arranged in accordance with at least some embodiments described herein.
  • configuration 100 includes, at least, a client device 104 that may host and/or run an instance of an application 106 thereon, a service provider 108 having a platform that may alternatively host and/or run an instance of application 106 thereon, a first account entity 112, and a second account entity 116.
  • a user 102 may be regarded as a person or entity that exercises ownership or control of client device 104.
  • user 102 may be a person who desires to notarize, certify, or otherwise ensure sustained validation of contents of one or more digital files.
  • user 102 may be an individual or organizational entity that desires or intends to implement and sustain validation of the properties and/or content of a continuous stream of digital files. Such examples are non-limiting, but rather are intended to merely give a sense of the breadth of possibilities by which user 102 may be embodied.
  • non-limiting examples of a "digital file” may refer to any document, e.g., contract, will, purchase agreement, medical record, laboratory notebook, etc; or digital media file, e.g., photograph, video file, audio file, software application, computer program; etc.
  • user 102 as an individual or entity, may desire or intend to ensure future validation of one or more of such digital files by presently notarizing or certifying the content of the one or more digital files, in accordance with one or more of the presently described embodiments of notarization based on currency transactions, by hashing the content of the one or more digital files in a manner that may be verified by an independent third-party.
  • notarize As further referenced herein, “notarize,” “certify,” and/or “validate” may be alternately used to refer to the act and/or process of authenticating as legitimate the content of one or more digital files.
  • the legitimacy of the one or more digital files may be determined based on factors that include, but are not limited to, matching the content of the one or more digital files at the time of creation to that at the time of attempted authentication.
  • Client device 104 may refer to a processor-based electronic device on which an instance of application 106 may be hosted to implement at least portions of notarization based on currency transactions.
  • client device 104 may be configured to be communicatively coupled to service provider 108 having a platform on which an instance of application 106 may be hosted to also implement at least portions of notarization based on currency transactions.
  • Client device 104 may be implemented as a mobile (or portable) electronic device such as a mobile phone, cell phone, smartphone, personal data assistant (PDA), a personal media player device, an application specific device, or a hybrid device that includes any of the above functions.
  • Client device 104 may also be implemented as a personal computer including tablet, laptop computer, and non-laptop computer configurations, which may be connected to a wireless, wired, or mobile communications network.
  • a wireless service provider for implementing communications for client device 104 may alternatively be referred to as a mobile network carrier, wireless carrier, or even cellular company. Regardless of the alternate reference, the wireless service provider may provide network communication services for mobile communications subscribers. Non-limiting examples of such network communication services may include telephone communication services and internet connectivity services.
  • Client device 104 may be configured to communicate with service provider 108, first account entity 112, and/or second account entity 116, each of which may similarly communicate with each other. Further, client device 104 may be configured to communicate with first account entity 112 directly in a peer-to-peer networking environment.
  • Application 106 may refer to a program implemented by hardware, software, firmware, or any combination thereof that may be utilized to notarize contents of one or more digital files that are created, received, and/or stored on client device 104.
  • application 106 may be included in, or otherwise integrated with, transactional software (not shown) in order to implement notarization based on currency transactions. That is, application 106 hosted on client device 104 may enable client device 104 to, at least, hash the contents of the one or more digital files and to engage with first account entity 112 to trigger a currency transaction between first account entity 112 and second account entity 116.
  • application 106 may transmit parameters for at least one such currency transaction to first account entity 112; with the aforementioned parameters including, at least, representations of the amounts of currency to be remitted from first account entity 112 to second account entity 116, as determined by the hashed content of the one or more digital files.
  • the aforementioned currency transaction may include a series of sub-transactions, or remittances, for which the amounts to be transacted are based on a serialization of time-stamped, equal-sized segments of the hash of the contents of the one or more digital files.
  • a currency transaction may be considered to be "triggered” or otherwise initiated in accordance with at least some of the embodiments described herein.
  • the aforementioned currency transaction may further include application 106 receiving confirmation from first account entity 112 that the currency transaction between first account entity 112 and second account entity 116 has been completed.
  • the embodiments described herein may provide a reliable mechanism for ensuring sustainable validation and/or authentication of the content of the one or more digital files by providing a notarized version of a hash of the content of the one or more digital files. That notarized version of the hash may come in the form of the serialized, time-stamped sub-transactions, or remittances, that are included in the confirmation, and which may be reassembled to form the hash of the content of the one or more digital files.
  • Service provider 108 may refer to a cloud-based service and storage platform owned and/or operated by a third-party service provider.
  • Service provider 108 may include a platform framework of hardware, software, firmware, or any combination thereof, on which application 106 may be hosted and/or executed for one or more digital files that are received from client device 104. More particularly, service provider 108 may be implemented as a web-based storage and sharing service to which client device 104, first account entity 112, and/or second account entity 116 may register prior to use.
  • First account entity 112 may refer to a service and/or storage platform owned and/or operated by a financial institution, brokering entity, government entity, etc., that holds a currency account on behalf of user 102 that may be accessed in accordance with at least one example implementation of notarization based on currency transactions. Regardless of the title, description, or any affiliation thereof, first account entity 112 may facilitate a currency transaction with second account entity 116, on behalf of user 102, to ensure sustained validation of contents of one or more digital files that are created on client device 104, received at client device 104, stored on client device 104, and/or received from client device 104.
  • first account entity 112 on behalf of user 102, in accordance with at least some of the embodiments described herein, may be implemented based on a contract established by user 102 and first account entity 112.
  • the aforementioned currency transaction may include a series of sub-transactions, or remittances, by which the amounts transacted are based on the aforementioned serialization of time-stamped, equal-sized segments of a hash of the contents of the one or more digital files.
  • Second account entity 116 may refer to a service and/or storage platform owned and/or operated by a separate financial institution, brokering entity, government entity, etc., that may serve as an independent participant in notarization based on currency transactions. Regardless of title, description, or even any affiliation thereof, second account entity 116 may participate in implementation of the currency transaction with first account entity 112 by transmitting a confirmation of at least a portion of the currency transaction from first account entity 112 and/or by reciprocating the receipt of the aforementioned series of sub-transactions, or remittances, with a repayment of the amounts in the sub-transactions back to first account entity 112. In at least some embodiments, a service fee for participation in the currency transaction may be withheld by second account entity 116 prior to processing the reciprocal repayment back to first account entity 112.
  • Communication link 110 may refer to a communication link enabled by a protocol utilized to transmit data and/or information between application 106, via client device 104, and service provider 108.
  • Communication link 114 may refer to a communication link enabled by a protocol utilized to transmit data and/or information, including instructions to trigger a currency transaction, between client device 104 or service provider 108, whichever is hosting an active instance of application 106, and first account entity 112.
  • Communication link 118 may refer to a communication link enabled by a protocol utilized to transmit data and/or information pertaining to a currency transaction between first account entity 112 and second account entity 116.
  • the aforementioned protocols referring to communication links 110, 114, and 118 may include any mobile communications technology, e.g., Global System for Mobile Communications (GSM), Code Division M ultiple Access (CDMA), etc., depending upon the technologies supported by particular wireless service providers to which services client device 104, service provider 108, first account entity 112, and/or second account entity 116 may be assigned or subscribed.
  • GSM Global System for Mobile Communications
  • CDMA Code Division M ultiple Access
  • one or more of the aforementioned communication links 110, 114, and 118 may be implemented utilizing non-cellular technologies such as conventional analog AM or FM radio, Wi-FiTM, wireless local area network (Wireless Local Area Network (WLAN) or IEEE (Institute of Electrical and Electronics Engineers) 802.11), (Worldwide I nteroperability for M icrowave Access) WiMAXTM, BluetoothTM, hard-wired connections, e.g., cable, phone lines, and other analog and digital wireless voice and data transmission technologies.
  • non-cellular technologies such as conventional analog AM or FM radio, Wi-FiTM, wireless local area network (Wireless Local Area Network (WLAN) or IEEE (Institute of Electrical and Electronics Engineers) 802.11), (Worldwide I nteroperability for M icrowave Access) WiMAXTM, BluetoothTM, hard-wired connections, e.g., cable, phone lines, and other analog and digital wireless voice and data transmission technologies.
  • FIG. 1 shows an example implementation of a system configuration for notarization based on currency transactions.
  • FIG. 2 shows an example configuration of application 106 for implementing notarization based on currency tra nsactions, arra nged in accordance with at least some embodiments described herein.
  • application 106 which may be hosted and/or run on one or both of client device 104 and the platform of service provider 108, may include at least a content component 202, a hash component 204, a remittance component 206, a nd a confirmation component 208; however, this configuration is an example only, a nd is not intended to be limiting in any ma nner.
  • client device 104 may refer to a processor-based electronic device on which a n instance of application 106 may be hosted to implement at least portions of notarization based on currency transactions.
  • client device 104 may be configured to be communicatively coupled to service provider 108 having a platform on which an instance of application 106 may be hosted to also implement at least portions of notarization based on currency transactions.
  • Service provider 108 may refer to a cloud-based service and storage platform on which application 106 may be hosted and/or executed for one or more digital files that are created on or received from client device 104.
  • Content component 202 may refer to a module or component of application 106 that is configured, designed, a nd/or programmed to identify a nd/or access, based on user or automated input, one or more d igital files for processing by application 106.
  • the one or more d igital files may be created at, received at, and/or stored on client device 104.
  • the one or more digital files may be received from client device 104.
  • content component 202 may access the one or more d igital files for processing, identified by user or automated input, by download ing the one or more digital files from a network source or retrieving the one or more d igital files from a loca l storage.
  • Hash component 204 may refer to a module or component of application 106 that is configured, designed, and/or programmed to hash the content of the one or more d igital files that are identified and/or accessed by content component 202.
  • Hash component 204 may utilize a hash algorithm, e. g., Message-Digest 5 (M D5) or Secure Hash Algorithm-1 (SHA-1), to ma p the content of the one or more digital files to a smaller data set of fixed length.
  • M D5 Message-Digest 5
  • SHA-1 Secure Hash Algorithm-1
  • Remittance component 206 may refer to a module or component of application 106 that is configured, designed, and/or programmed to trigger or initiate a currency transaction, including a series of one or more remittances, between first account entity 112 and second account entity 116.
  • Remittance component 206 may transmit, or cause to be transmitted, the hash code generated by hash component 204 to first account entity 112.
  • the hash code transmitted to first account entity 112, from either of client device 104 or service provider 108, may be segmented into multiple groups of one or more digits, each of equal length.
  • each of the multiple groups may be time-stamped by hash component 204 or remittance component 206, a nd transmitted in series to first account entity 112.That is, each of the multiple groups may include encoded information that identifies, at least, a data and time at which, e.g., the content of the one or more d igital files is hashed or the resulting hash code is segmented into the respective multiple groups.
  • the format of the time stamps may be subject to customization by an entity that exercises administrative control over application 106.
  • remittance component 206 effectively "triggers" or otherwise initiates a currency transaction, in accordance with at least some of the embod iments described herein.
  • each of the multiple groups of the segmented hash code may represent an order for a currency transaction, on behalf of user 102, between first account entity 112 and second account entity 116. More pa rticularly, as configured, designed, a nd/or programmed as pa rt of application 106, the digits included in of each of the groups of the segmented hash code may represent a currency amount that is to be transferred from a first account for user 102 at first account entity 112 to second account entity 116.
  • each of the multiple groups of the segmented hash code may represent a U.S. dollar amount that is to be transferred from first account entity 112 to second account entity 116, on behalf of user 102.
  • the first digit may represent a dollar amount and the second digit may represent a cents amount to be remitted to second account entity 116.
  • a sample hash code generated by hash component 204 may be 389267145.
  • the first group of digits including "389” may be understood by first account entity 112 as an instruction to remit $3.89 to second account entity 116; the second group of digits including "267” may be understood by first account entity 112 as an instruction to further remit $2.67 to second account entity 116; and the third group of digits including "145" may be understood by first account entity 112 as an instruction to further remit $1.45 to second account entity 116.
  • an ordinal number i.e., the number representing the placement in a serialization of the multiple groups, may represent the dollar amount.
  • an alternative first group of digits may include "38,” which may be understood by first account entity 112 as an instruction to remit $1.38 to second account entity 116; an alternative second group of digits may include “92,” which may be understood by first account entity 112 as an instruction to remit $2.92 to second account entity 116; an alternative third group of digits may include "67,” which may be understood by second account entity 112 as an instruction to remit $3.67 to second account entity 116; an alternative fourth group of digits may include "14,” which may be understood by first account entity 112 as an instruction to remit $4.14 to second account entity 116; and an alternative fifth group of digits may include "5,” which may be understood by first account entity 112 as an instruction to remit $5.50 to second account entity 116.
  • the currency transaction based on the hash code produced by hash component 204 may trigger a currency transaction that includes serial, time-stamped instructions to remit $3.89, $2.67, a nd $1.45 from a first account for user 102 at first account entity 112 to second account entity 116; or a lternatively, a currency transaction that include seria l, time- stamped instructions to remit $1.38, $2.92, $3.67, $4.14, a nd $5.50 from the account for user 102 at first account entity to second account entity 116.
  • the remittances are seria l, based on the segmented order of the hash code produced by hash component 204, in order to preserve the integrity of the hash code; further, each of the groups of digits may be encoded or otherwise affixed with a time stamp.
  • the serial remittances when juxtaposed in order of tra nsmission/receipt and voided of any reference to currency a nd correspond ing time stamps, may provide a representation of the hash code generated by hash component 204, which is a hash of the content of the one or more d igital files created at, received by, or received from client device 104.
  • Application 106 may be configured, designed, and/or programmed to accommodate the number of digits per segmented group to multiple nationa l currencies. Therefore, the number of digits referenced herein is described in the context of non-limiting examples, a lthough the number of digits may be influenced by minima l transactiona l amounts accepted and/or required by at least second account entity 116. Further, the currency transactions may be implemented utilizing a network currency, e.g., "BitCoin,” that accommodates small acceptable transfer amounts and relatively quick completion rates.
  • a network currency e.g., "BitCoin”
  • application 106 may be a lternatively configured, designed, and/or programmed to seria lly transmit the time-stamped remittances in an order that is d ifferent than the order of the corresponding digits in the generated hash code, so long as the hash code may be reconstructed based on the remittances by any one or more of application 106, first account entity 112, or second account entity 116.
  • Confirmation component 208 may refer to a module or component of application 106 that is configured, designed, a nd/or programmed to receive and/or record a confirmation of the remittances between first account entity 112 and second account entity 116. Further, in accorda nce with at least some embodiments, confirmation component 208 may store an a lternative version of the confirmation of the remittances, with references to currency and time stamps removed therefrom. Thus, the alternative version of the confirmation of the remittances may be regarded as a reconstruction of the hash code generated by hashing the content of the one or more digital files.
  • second account entity 116 may be configured, designed, and/or programmed to return the remitted currency amounts back to the first account for user 102 at first account entity 112, along with a confirmation of receipt.
  • second account entity 116 may return the remitted currency amounts back to first account entity 112 with an agreed upon service charge withheld.
  • the listing of the time-stamped remittances from first account entity 112 to second account entity 116 on the confirmation of receipt may provide the basis of a representation of the hash code generated by hash component 204 that is notarized or certified to ensure sustainable validation thereof. Further, in accordance with various embodiments of notarization based on currency transactions, remittance component 206 may trigger or initiate multiple remittances, with the currency amounts based on segmented groups of the hash code generated by hash component 204, between first account entity 112 and second account entity 116.
  • Receipt of the confirmation of the currency exchanges may be transmitted from first account entity 112 to application 106, although alternative embodiments of notarization based on currency transactions may contemplate second account entity 116 transmitting confirmation of the serial remittances directly to application 106.
  • FIG. 2 shows an application by which a time-stamped representation of the hash code generated by hash component 204 may be generated, to provide a sustainable validation of the content of one or more digital files created at, received by, or received from client device 104.
  • FIG. 3 shows an example configuration of a processing flow 300 of operations for notarization based on currency transactions, arranged in accordance with at least some embodiments described herein.
  • processing flow 300 may include sub-processes executed by various components that are included as part of application 106, as hosted and/or run on either of client device 104 or the platform of service provider 108.
  • processing flow 300 is not limited to such components, as obvious mod ifications may be made by re-ordering two or more of the sub-processes described here, eliminating at least one of the sub-processes, adding further sub- processes, substituting components, or even having various components assuming sub- processing roles accorded to other components in the following description.
  • Processing flow 300 may include various operations, functions, or actions as illustrated by one or more of blocks 302, 304, 306, and/or 308. Processing may begin at block 302.
  • Block 302 may refer to content component 202 identifying and/or preparing, based on user input, one or more digita l files for processing by application 106.
  • the one or more digital files may be created, received, and/or stored on client device 104.
  • the one or more digital files may be received from client device 104.
  • Processing flow 300 may continue from block 302 to block 304.
  • Block 304 may refer to hash component 204 hashing the content of the one or more digital files that are identified and/or accessed by content component 202.
  • Hash component 204 may utilize any known hash algorithm, e.g., M D5 or SHA-1, that has been configured to map the content of the one or more digital files to a smaller data set of a known and fixed length in order to generate a digital code to represent the content of the one or more digital files.
  • Processing flow 300 may continue from block 304 to block 306.
  • Block 306 may refer to remittance component 206 triggering or initiating a currency transaction, which may include a series of one or more remittances, between first account entity 112 and second account entity 116 by transmitting, to first account entity 112, representations of the amounts of currency amounts to be remitted to second account entity 116.
  • the triggering of the currency transaction may include the transmission of the hash code generated by hash component 204 to first account entity 112 from either of client device 104 or service provider 108.
  • the transmitted hash code may be segmented into multiple groups of equal length and each of the multiple groups may be time-stamped by hash component 204 or remittance component 206, prior to or concurrent with the serial transmission thereof to first account entity 112.
  • each of the multiple groups of the segmented hash code may represent for a pa rameter for the currency transaction. That is, the digits included in of each of the groups of the segmented hash code may represent a currency amount that is to be tra nsferred from a first account for user 102 at first account entity 112 to second account entity 116.
  • the transferred amount of currency may be received at second account entity 116, e.g., into an account designed by or for user 102 or into a genera l account that may be designated for use for notarization based on currency transactions.
  • Application 106 may be configured, designed, and/or programmed so that the number of d igits per segmented group may vary to accommodate multiple nationa l currencies on a small but acceptable scale. Further, the currency tra nsactions may be implemented utilizing a network currency, e.g., "BitCoin,” that accommodates small acceptable tra nsfer amounts and relatively q uick completion rates.
  • a network currency e.g., "BitCoin”
  • application 106 may be alternatively configured, designed, and/or programmed to serially tra nsmit the time-stamped remittances in an order that is d ifferent than the order of the corresponding digits in the generated hash code, so long as the hash code may be reconstructed based on the remittances by any one or more of a pplication 106, first account entity 112, or second account entity 116. Processing flow 300 may continue from block 306 to block 308.
  • Block 308 may refer to confirmation component 208 receiving and/or record ing a confirmation of the remittances between first account entity 112 and second account entity 116.
  • Second account entity 116 may be configured, designed, and/or programmed to return remitted currency amounts back to the first account for user 102 at first account entity 112, along with a confirmation of receipt. Regardless of the amount of currency returned to first account entity 112, the listing of the time-stamped remittances on the confirmation of receipt, with any reference to currency and time stamps removed therefrom, may provide a reconstruction or representation of the hash code generated by hash component 204.
  • confirmation component 208 may then ca use the confirmation of receipt to be stored locally on client device 104 and/or at service provider 108, thus preserving a verifiable notarization, certification, and/or authentication of a hash code representation of the one or more d igital files created on, stored on, or received from client device 104.
  • FIG. 3 shows an example processing for ensuring a sustainable authentication of a hash code representation of one or more digital files.
  • FIGS. 4(a) - 4(d) show an example progression 400 of digital data as processed in at least one flow of operations for notarization based on currency transactions, in accorda nce with at least some embod iments described herein. As depicted, progression 400 genera lly depicts digital data in accordance with respective components of application 106 and respective blocks of process 300, as described herein. Progression 400 is not limited to the example embodiments of FIGS.
  • 4(a) - 4(d) may be rea lized made, e.g., in accorda nce with different hash functions utilized by hash component 204, d ifferent national currencies utilized by application 106, d ifferent business models agreed upon by owners/controllers of first account entity 112 and/or second account entity 116, etc.
  • FIG. 4(a) shows an example representation 402 of the content of one or more d igital files that have been created, received, and/or stored on client device 104 or received at service provider 108 from client device 104.
  • the digital files may include a document, e.g., contract, will, purchase agreement, medica l record, la boratory notebook, etc; and/or digital media file, e.g., photograph, video file, audio file, software application, computer program; etc.
  • User 102 as an individ ual or entity, may desire or intend to ensure future validation of the one or more digital files by presently notarizing or certifying.
  • Representation 402 of the content of the one or more digital files may further be identified and/or accessed, based on user or a utomated input, for further processing by application 106.
  • FIG. 4(b) shows a n example representation 404 of the hash code of the content of the one or more d igital generated by hash component 204.
  • the representation 404 of the hash code may be generated by a hash a lgorithm, e.g., M D5 or SHA-1, to convert the content of the one or more digital files to a smaller data set of a known and fixed length in order to generate a digital code to represent the content thereof.
  • FIG. 4(c) shows an example representation 406 of the hash code which may be segmented one or more groups of equa l length, and each of the multiple groups may be time-stamped, by hash component 204 or remittance component 206.
  • each of the groups may include encoded information that identifies, at least, a data and time at which, e.g., the content of the one or more digital files is hashed or the resulting hash code is segmented into the respective multiple groups.
  • the format of the time stamps may be subject to customization by a n entity that exercises administrative control over application 106.
  • the generated hash code is 389267145
  • the first group of d igits including "389,” which may be understood by first account entity 112 as an instruction to remit $3.89 to second account entity 116, may be time-stamped with time-stamp "TS1," which represents an actual time of hashing or transmission.
  • the second group of d igits includ ing "267,” which may be understood by first account entity 112 as a n instruction to further remit $2.67 to second account entity 116, may be time-stamped with time-stamp "TS2,” which represents an actual time of hashing or transmission; and the third group of digits including "145,” which may be understood by first account entity 112 as an instruction to further remit $1.45 to second account entity 116, may be time-stamped with time-stamp "TS3,” which represents an actua l time of hashing or transmission.
  • FIG. 4(d) shows an example representation 408 of the serial tra nsmission of the currency transaction from first account entity 112 to second account entity 116, in the form of a series of one or more remittances.
  • the serial, time-stamped remittances when juxtaposed in order of transmission and/or receipt and voided of any references to currency or time, may provide a reconstruction or representation of the hash code generated by hash component 204, which is a hash of the content of the one or more d igital files created at, received by, or received from client device 104.
  • FIGS. 4(a) - 4(d) show an example progression of the processing of d igital data in accordance with various embodiments of notarization based on currency transactions.
  • FIG. 5 shows a block diagram illustrating an example computing device 500 by which various example solutions described herein may be implemented, arranged in accorda nce with at least some embod iments described herein.
  • FIG. 5 shows an illustrative computing embod iment, in which any of the processes and sub-processes described herein may be implemented as computer-readable instructions stored on a computer-readable med ium.
  • the computer- readable instructions may, for example, be executed by a processor of a device, as referenced herein, having a network element a nd/or a ny other device correspond ing thereto, pa rticularly as applicable to the applications and/or programs described above corresponding to the configuration 100 for notarization based on currency transactions.
  • a computing device 500 may typically include one or more processors 504 and a system memory 506.
  • a memory bus 508 may be used for communicating between processor 504 and system memory 506.
  • processor 504 may be of any type includ ing but not limited to a microprocessor ( ⁇ ), a microcontroller ( ⁇ ), a digital signal processor (DSP), or any combination thereof.
  • the processor 504 may include one or more levels of caching, such as a level one cache 510 and a level two cache 512, a processor core 514, and registers 516.
  • An example processor core 514 may include an arithmetic logic unit (ALU), a floating point unit (FPU), a d igital signal processing core (DSP Core), or any combination thereof.
  • An example memory controller 518 may also be used with the processor 504, or in some implementations the memory controller 518 may be an internal part of the processor 504.
  • system memory 506 may be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or a ny combination thereof.
  • System memory 506 may include an operating system 520; one or more applications 522, includ ing application 106; a nd program data 524.
  • Application 522 which may include a client application 523 (e.g., application 106), may be configured to tra nsmit or receive identification information pertaining to client device 104, service provider 108, first account entity 112, and/or second account entity 116, and further transmit device data as described previously with respect to FIGS. 1 - 3.
  • Program data 524 may include a table 525, which may be useful for implementing actuation of appropriate components or modules as described herein.
  • System memory 506 is an example of computer storage media.
  • Computer storage media may include, but not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, d igital versatile disks (DVD) or other optica l storage, magnetic cassettes, magnetic tape, magnetic d isk storage or other magnetic storage devices, or any other medium which may be used to store the desired information and which may be accessed by computing device 500. Any such computer storage media may be part of computing device 500.
  • the network communication link may be one example of a communication media.
  • Communication med ia may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media.
  • a "modulated data signal" may be a signa l that has one or more of its characteristics set or cha nged in such a manner as to encode information in the signal.
  • communication media may include wired med ia such as a wired network or direct-wired connection, and wireless media such as acoustic, rad io frequency (RF), microwave, infrared (I R) and other wireless media.
  • RF rad io frequency
  • I R infrared
  • the term computer reada ble med ia as used herein may include both storage media and communication media.
  • the implementer may opt for a ma inly hardware and/or firmware vehicle; if flexibility is paramount, the implementer may opt for a mainly software implementation; or, yet again alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.
  • a signal bearing medium examples include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc.; and a transmission type medium such as a digital and/or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).
  • a typical data processing system generally includes one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signa l processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and/or control systems includ ing feedback loops and control motors, e.g., feedback for sensing position and/or velocity; control motors for moving and/or adjusting components and/or quantities.
  • a typica l data processing system may be implemented utilizing any suitable commercia lly available components, such as those typically found in data computing/communication and/or network computing/communication systems.
  • any two components so associated can also be viewed as being “operably connected”, or “operably coupled”, to each other to achieve the desired functiona lity
  • any two components ca pable of being so associated can also be viewed as being “operably couplable”, to each other to achieve the desired functionality.
  • Specific examples of opera bly couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Technology Law (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Dans un exemple, un procédé comprend la génération d'un premier code numérique qui représente un contenu d'un document créé par un premier utilisateur ; et la notarisation de la création du document par le déclenchement d'une pluralité de paiements d'un premier compte associé au premier utilisateur vers un second compte, chacun de la pluralité de paiements étant horodaté et une somme respective de chacun de la pluralité de paiements indiquant une partie correspondante du premier code numérique.
PCT/CN2012/082851 2012-10-12 2012-10-12 Notarisation basée sur des transactions de devises WO2014056185A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2012/082851 WO2014056185A1 (fr) 2012-10-12 2012-10-12 Notarisation basée sur des transactions de devises
US14/006,310 US9280792B2 (en) 2012-10-12 2012-10-12 Notarization based on currency transactions

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2012/082851 WO2014056185A1 (fr) 2012-10-12 2012-10-12 Notarisation basée sur des transactions de devises

Publications (1)

Publication Number Publication Date
WO2014056185A1 true WO2014056185A1 (fr) 2014-04-17

Family

ID=50476287

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2012/082851 WO2014056185A1 (fr) 2012-10-12 2012-10-12 Notarisation basée sur des transactions de devises

Country Status (2)

Country Link
US (1) US9280792B2 (fr)
WO (1) WO2014056185A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020027408A1 (fr) * 2018-08-01 2020-02-06 주식회사 스트리미 Dispositif électronique et procédé de mise en correspondance d'opérations de change de cryptomonnaies

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
WO2015142765A1 (fr) 2014-03-17 2015-09-24 Coinbase, Inc Système informatique hôte pour bitcoins
US9735958B2 (en) * 2015-05-19 2017-08-15 Coinbase, Inc. Key ceremony of a security system forming part of a host computer for cryptographic transactions
US11386415B2 (en) * 2015-05-20 2022-07-12 Ripple Luxembourg S.A. Hold condition in a resource transfer system
US11481771B2 (en) * 2015-05-20 2022-10-25 Ripple Luxembourg S.A. One way functions in a resource transfer system
US20170076366A1 (en) * 2015-09-11 2017-03-16 Bank Of America Corporation Universal tokenization system
KR101772553B1 (ko) * 2015-12-29 2017-08-30 주식회사 코인플러그 파일에 대한 공증 및 검증을 수행하는 방법 및 서버
CN107306183B (zh) * 2016-04-22 2021-12-21 索尼公司 客户端、服务端、方法和身份验证系统
CN107196989B (zh) * 2017-03-21 2019-08-09 阿里巴巴集团控股有限公司 一种业务请求的处理方法及装置
US11394543B2 (en) 2018-12-13 2022-07-19 Coinbase, Inc. System and method for secure sensitive data storage and recovery
CN114730420A (zh) 2019-08-01 2022-07-08 科恩巴斯公司 用于生成签名的系统和方法
WO2021076868A1 (fr) * 2019-10-16 2021-04-22 Coinbase, Inc. Systèmes et procédés de réutilisation de clés de stockage à froid
US12099997B1 (en) 2020-01-31 2024-09-24 Steven Mark Hoffberg Tokenized fungible liabilities

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101122985A (zh) * 2006-08-09 2008-02-13 阿里巴巴公司 一种身份认证方法及其系统
US20090061831A1 (en) * 2007-08-31 2009-03-05 Vishwanath Shastry Mobile remittances/payments

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6076084A (en) * 1994-01-03 2000-06-13 Norton-Lambert Corp. File transfer method and apparatus utilizing delimiters
KR100241350B1 (ko) 1997-10-27 2000-02-01 정선종 전자 거래에서 안전한 전자 공증문서 생성방법
US7213005B2 (en) * 1999-12-09 2007-05-01 International Business Machines Corporation Digital content distribution using web broadcasting services
US6397224B1 (en) * 1999-12-10 2002-05-28 Gordon W. Romney Anonymously linking a plurality of data records
US7167844B1 (en) * 1999-12-22 2007-01-23 Accenture Llp Electronic menu document creator in a virtual financial environment
EP1154609A1 (fr) * 2000-05-08 2001-11-14 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Procédé pour l'autorisation de transactions
JP2002215893A (ja) * 2001-01-19 2002-08-02 Mitsubishi Corp 送金管理システム、決済管理システム、送金管理方法、決済管理方法及びプログラム
DE10112166A1 (de) * 2001-03-12 2002-09-26 Jan Wendenburg Verfahren zum Transaktionsnachweis
US6820081B1 (en) * 2001-03-19 2004-11-16 Attenex Corporation System and method for evaluating a structured message store for message redundancy
US7752136B2 (en) * 2001-05-18 2010-07-06 Meadow William D Check authorization system and method
EP1396142B8 (fr) * 2001-06-12 2005-06-08 International Business Machines Corporation Procede d'authentification d'une pluralite de fichiers lies a un document texte
US7069250B2 (en) * 2001-10-15 2006-06-27 Payformance Corporation Check based online payment and verification system and method
US7020782B2 (en) * 2002-03-08 2006-03-28 Arcot Systems, Inc. Size-dependent hashing for credit card verification and other applications
US7529929B2 (en) * 2002-05-30 2009-05-05 Nokia Corporation System and method for dynamically enforcing digital rights management rules
US20040091111A1 (en) * 2002-07-16 2004-05-13 Levy Kenneth L. Digital watermarking and fingerprinting applications
US7735144B2 (en) 2003-05-16 2010-06-08 Adobe Systems Incorporated Document modification detection and prevention
WO2004109610A1 (fr) * 2003-06-04 2004-12-16 Zingtech Limited Traitement de transactions
US7506812B2 (en) * 2004-09-07 2009-03-24 Semtek Innovative Solutions Corporation Transparently securing data for transmission on financial networks
US7512625B2 (en) * 2005-04-01 2009-03-31 International Business Machines Corporation Method, system and program for joining source table rows with target table rows
US20090006842A1 (en) 2007-06-26 2009-01-01 John Gordon Ross Sealing Electronic Data Associated With Multiple Electronic Documents
US8793257B2 (en) * 2009-05-24 2014-07-29 Roger Frederick Osmond Method for improving the effectiveness of hash-based data structures
US8645002B2 (en) * 2009-07-06 2014-02-04 Netgear, Inc. System and method for facilitating and monitoring provisioning of wireless devices
FR2948793B1 (fr) * 2009-07-28 2014-10-31 Thales Sa Procede securise de reconstruction d'une mesure de reference d'une donnee confidentielle a partir d'une mesure bruitee de cette donne, notamment pour la generation de cles cryptographiques
US8244767B2 (en) * 2009-10-09 2012-08-14 Stratify, Inc. Composite locality sensitive hash based processing of documents
US8930332B2 (en) * 2010-03-12 2015-01-06 Salesforce.Com, Inc. Method and system for partitioning search indexes
US20110295672A1 (en) * 2010-05-25 2011-12-01 Dimitriadis Christos K Methods and a system for detecting fraud in betting and lottery games
US8738656B2 (en) * 2010-08-23 2014-05-27 Hewlett-Packard Development Company, L.P. Method and system for processing a group of resource identifiers
US8838977B2 (en) * 2010-09-16 2014-09-16 Verance Corporation Watermark extraction and content screening in a networked environment
US8468610B2 (en) * 2011-01-27 2013-06-18 Echostar Technologies L.L.C. Determining fraudulent use of electronic devices utilizing matrix codes
US20130018800A1 (en) * 2011-07-15 2013-01-17 Rangaraju Devaraju Secure Authorization of a Financial Transaction

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101122985A (zh) * 2006-08-09 2008-02-13 阿里巴巴公司 一种身份认证方法及其系统
US20090061831A1 (en) * 2007-08-31 2009-03-05 Vishwanath Shastry Mobile remittances/payments

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020027408A1 (fr) * 2018-08-01 2020-02-06 주식회사 스트리미 Dispositif électronique et procédé de mise en correspondance d'opérations de change de cryptomonnaies

Also Published As

Publication number Publication date
US9280792B2 (en) 2016-03-08
US20140108223A1 (en) 2014-04-17

Similar Documents

Publication Publication Date Title
WO2014056185A1 (fr) Notarisation basée sur des transactions de devises
Ozercan et al. Realizing the potential of blockchain technologies in genomics
Yeow et al. Decentralized consensus for edge-centric internet of things: A review, taxonomy, and research issues
US20210035096A1 (en) Stored value smart contracts on a blockchain
CN110675145B (zh) 基于区块链的数据处理方法、装置、终端及存储介质
US20200293515A1 (en) Service processing system and method based on blockchain
US10904009B2 (en) Blockchain implementing delta storage
CN110383791B (zh) 基于区块链的地图应用众包
US20220103378A1 (en) System and method for off-chain cryptographic transaction verification
US20200084615A1 (en) Switching mobile service provider using blockchain
US20190207767A1 (en) Block chain supporting multiple one-way functions used for verification of blocks
US9530010B2 (en) Energy usage data management
AU2023255004A1 (en) A computer implemented method for processing a financial transaction and a system therefor
WO2019001139A1 (fr) Dispositif et procédé d'exécution d'un code de chaîne
US11133936B1 (en) Methods and systems for introducing self-contained intent functionality into decentralized computer networks
WO2020073715A1 (fr) Procédé, dispositif et système anti-contrefaçon de code bidimensionnel basés sur une application de sécurité
US11887107B2 (en) Method and device for providing transaction service for cryptocurrencies based on different blockchains
US20190378069A1 (en) Maximizing retention of transaction results for blockchain block creation
EP3082078A1 (fr) Sous-échantillonnage authentifié de données de série chronologique
WO2020100126A1 (fr) Systèmes, procédés et dispositifs de registre distribué
US11316385B2 (en) Wireless energy transfer
CN110400217B (zh) 智能合约的规则变更处理方法及装置
JP2023542681A (ja) ブロックチェーンの許可フレームワークへのデバイスアイデンティティの統合
US11870654B2 (en) Methods and systems for introducing self-contained intent functionality into decentralized computer networks
Merrad et al. Blockchain: Consensus algorithm key performance indicators, trade-offs, current trends, common drawbacks, and novel solution proposals

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 14006310

Country of ref document: US

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

Ref document number: 12886441

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12886441

Country of ref document: EP

Kind code of ref document: A1