Address Management System

Abstract

Embodiments disclosed herein relate to an address management system that includes a registration service for receiving and verifying a user's address information. Verifying a user's address information may involve consulting an authoritative information source, such as a government agency. Once verified, the registration service may publish and / or enable a user code that may be used as a key for retrieving the user's address information. When a user requests a service from an application that requires an address, the user may provide a user code instead of an address. The application may retrieve at least a portion of an address associated with a registered user code from an address server.

Description

Technical Field

[0001] The present disclosure relates to sharing and controlling user's address information. Specifically, the present disclosure is directed to allowing users to share codes representing their physical addresses, rather than disclosing the physical addresses themselves. Background Art

[0002] When a user interacts with an application to request a service or place an order, such as delivery of goods or services to a specific location, the user is often required to provide identification and address information including name, complete mailing (and / or delivery) address, and one or more telephone numbers in order to access the service. Some applications require the user to have an account in which the identification information is stored in a user profile. When a user logs into their account and orders a product to be shipped to the user's residence, the application can use the address information in the user profile to determine where to deliver the order. Other applications may require the user to provide a delivery address in each request for a service. Submitting and resubmitting address information can be a time-consuming, inefficient, and error-prone process. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] In the figures of the accompanying drawings, embodiments are illustrated by way of example and not limitation. It should be noted that references to "an embodiment" or "one embodiment" in this disclosure do not necessarily refer to the same embodiment, and they mean at least one embodiment. In the drawings:

[0004] Figure 1 is a block diagram illustrating components of an address management system according to one or more embodiments;

[0005] Figure 2 is a flow chart illustrating associating a user code with an authenticated address according to one or more embodiments;

[0006] Figure 3 is a flow chart illustrating a user requesting a service from an application that requires a physical address for fulfillment according to one or more embodiments;

[0007] Figure 4 is a flow diagram illustrating sending a user's physical address to an application that provides services to the user according to one or more embodiments;

[0008] Figure 5 is a block diagram illustrating sequential interactions between components in an address management system according to one or more embodiments;

[0009] Figure 6 is a block diagram illustrating an address repository implemented as a peer-to-peer distributed ledger network in accordance with one or more embodiments;

[0010] Figure 7is a block diagram illustrating an address registration engine interacting with one of the peers of a peer-to-peer distributed ledger network in accordance with one or more embodiments;

[0011] Figure 8 illustrates a collaborative distributed ledger network according to one or more embodiments;

[0012] Fig. 9 A block diagram illustrating a computer system in accordance with one or more embodiments is shown. DETAILED DESCRIPTION

[0013] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described with reference to block diagram form to avoid unnecessary confusion of the present invention.

[0014] 1. General Overview

[0015] Some embodiments include an address management system for managing a user's addresses. The term "address" is used herein to refer to any type of address information for a user. An address may correspond to an address including, but not limited to, a street address, a set of directions from a well-known point of interest, or map coordinates. An address may refer to a contact address, such as an email address, an application-specific handle, a messenger address, or a telephone number. Examples that reference one type of address may equally apply to other types of addresses.

[0016] The address management system is implemented separately from third-party applications that require the user's physical address to complete one or more functions (e.g., purchase goods or services). Maintaining the user's physical address separately from the third-party application can allow a single system (i.e., the address management system) to be updated, rather than updating each third-party application. Thus, the address management system can maintain the user's current address in association with the user's user code. In addition, the address management system adds a layer of security by performing an authorization process to confirm that the requesting third-party application is authorized to access the user's physical address (or portion thereof). The address management system transmits the user's address to the requesting third-party application after successfully verifying the access permission of the requesting third-party application.

[0017] The address management system is also configured to verify the user's address. As an example, verification may involve consulting an authoritative information source (such as a government agency). Once verified, the address may be stored in association with the user code corresponding to the user. The embodiments described herein are directed to third-party applications that receive user codes from users rather than address information from users. The third-party application forwards the user code to the address management system in a request for the user's address (or part thereof).

[0018] The description may include, and the claims may recite, many more embodiments than those described in this general summary.

[0019] 2. Address management system architecture

[0020] Figure 1 is a block diagram illustrating components of an address management architecture according to one or more embodiments. Components may be added, removed, modified, or combined. Functionality described with respect to one component may be implemented by another component instead. Thus, the specific components illustrated and / or described herein should not be construed as limiting the scope of any claim.

[0021] The system includes a user device 110 , an address registration engine 120 , an address authenticator 130 , an address repository 140 , an address server 150 , and an application 160 .

[0022] The user device 110 is a device, such as a mobile phone, tablet computer, laptop computer, or other computer, used by a user to interact with the address registration engine 120, the application 160, and the address server 150. Different user devices can be used to interact with each component of the address management system. For example, a user can (a) register an address with the address registration engine 120 using a laptop or desktop computer, (b) order goods to be delivered to his residence from the application 160 using a tablet computer, and (c) respond to a request from an authorized application of the address server to retrieve a delivery address using a mobile phone.

[0023] The address registration engine 120 receives an address from a user and stores the address in an address repository 140 in association with a user code. The address may include a user's mobile phone number, a complete physical address, an email address, and map coordinates (which may be specified by placing a pin on a map). In an embodiment, the map coordinates may be GPS coordinates. The user may select their user code and send the user code and address together to the address registration engine. Alternatively, the address registration engine may create a unique user code and return the unique user code to the user along with a confirmation that the address has been verified and successfully stored. Before storing the association between the user code and the address, the address registration engine may send portions of the address to one or more address authenticators 130 to verify that the corresponding portions of the address are valid and associated with the user.

[0024] The address authenticator 130 includes one or more authoritative sources of user and / or address information. Examples of authoritative sources of portions of user information may include government agencies, such as a county registrar, a motor vehicle department, or a voter registry, a credit bureau, a utility company, a bank, a public telephone directory, etc., which may be used to verify that a known user is associated with a provided address. To this end, the user may provide additional information for verification purposes, such as an ID number (such as a social security number), a telephone number, a bank account number, or a lot number of a tangible property at the address.

[0025] In an embodiment, the additional information may be sent to an address registration engine along with the address. The address registration engine may pass the information to one or more address authenticators. The address authenticator may contact the user directly to obtain the additional information needed to verify the association of the address with the user. The address authenticator 130 may be fully automated and does not require any communication with the user.

[0026] The address repository 140 can maintain the association between the user code and the user address. The address registration engine can also subsequently update the user code or address. In an embodiment, the address repository 140 may include a storage device that is directly accessible to the address registration engine. The address server 150 can maintain the repository, and the address registration engine can send new or updated address records to the address server 150. The address repository 140 can be accessed through a request to the storage management system. The address records can be stored in the address repository in JSON or XML format for easy processing.

[0027] In one or more embodiments, the address repository is any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, or any other storage mechanism). In addition, the address repository may include multiple different storage units and / or devices. Multiple different storage units and / or devices may or may not be of the same type or located at the same physical site. The address repository may be implemented or executed on the same computing system as the address registration engine and / or address server. Alternatively or additionally, the address repository may be implemented or executed on a computing system separate from the computing system on which the address registration engine and / or address server is executed.

[0028] Application 160 is an application that provides a user interface through which a user requests that goods or services be delivered to a user at a specific address. In an embodiment, a user can interact with the application through the Internet, and a web browser can provide a user interface. In an embodiment, the application can be run on a user device and provide an application-specific user interface. In an embodiment, a user can have an account set up with an application. The account can include a user profile for storing user information for authentication, specifying preferences, payment options, and / or delivery address information. For example, a user can set up an account with an application through which the user often places an order. The user can provide a user code in place of address information to be stored in the user profile. Thereafter, each time a user places an order, the user does not need to provide address information. Instead, the application can retrieve the user's address information from an address server using a user code stored in the profile. By retrieving the address each time an address is needed to fulfill an order instead of caching the address locally, the application can always receive the latest address information. The user does not need to update the profile information in each individual application in which the user has previously provided an address.

[0029] In an embodiment, a user places an order with an application in which the user does not have an account. An example may involve a user trying a new pizza delivery service. When ordering a pizza, the user may provide a user code instead of a physical address. Neither the physical address nor the user code need to be stored for future use.

[0030] The address server 150 receives requests from applications that provide user services that require a physical address to perform, such as shipping goods, delivering food, or dispatching maintenance personnel or contractors to a physical address. The address server can receive a user code with an application's request to obtain a physical address associated with a user code. The address server can allow a user to authorize an application to obtain the user's physical address for fulfilling a specific user order. Even if a user provides a user code to an application, the user can deny access to any specific use of the user code.

[0031] If the user authorizes the application to obtain the physical address, the address server sends the user's physical address information to the application. The address server may send all of the address information (referred to herein as the entire address) to the application. Alternatively, the address server may send only a portion of the address information. If a portion of the address information is specifically requested or if only the requesting application is authorized to access that portion of the address, then that portion of the address information is sent instead of the entire address.

[0032] In an embodiment, the address server 150 may receive a verification request from an application. The verification request may include sending all or part of the user's physical address information along with a corresponding user code, and the address server may verify that the address information sent with the verification request is consistent with the address information stored in the address repository. Thus, the response to the verification request may be a binary indicator of whether the physical address information is valid.

[0033] 3. Processing Description

[0034] Figure 2 , Figure 3 , Figure 4 and Figure 5 The entire address management system process is illustrated. Operations and components may be added, removed, modified, or combined. Functionality described with respect to one operation or component may alternatively be implemented by another operation or component. Thus, the specific operations and components illustrated and / or described herein should not be construed as limiting the scope of any claim.

[0035] Figure 2 is a flow diagram illustrating associating a user code with an authenticated address in accordance with one or more embodiments.As described above, any other type of address may be equally applicable to the examples reciting a particular type of address, such as an address.

[0036] In operation 210, the address registration engine 120 may receive a request to register a user code associated with an address from the user device 110. The request includes at least a physical address. The registration request may also include a user code selected by the user. If the request includes a user code selected by the user, the address registration engine may verify the uniqueness of the selected user code among other user codes stored in the address repository. For example, a universal (global) address service may require that the user code is globally unique. A national address service may only require that the user code is unique among user codes associated with a physical address located in the country. If no user code is provided, the address registration engine may construct a unique user code among user codes stored in the address repository, and the newly constructed user code may be sent back to the user. In an embodiment, the address registration engine may contact the user through the user device to receive a new or different user code from the user. The user may be prompted to approve the generated user code or to select from a list of generated user codes. For example, whenever a user enters a non-unique code, the user may be prompted to enter a new user code. As another example, the address registration engine may construct several alternative unique user codes, and the user may select one. In an embodiment, the address registration engine may modify the user code provided by the user to ensure the uniqueness of the user code, such as by adding numbers or other characters.

[0037] In operation 220, the address registration engine may verify that the physical address provided by the user is known to be associated with the user. The user's request may also include an image of an authentication document, such as an image of a birth certificate, passport, property tax bill, utility bill, etc., which includes the user's name and some combination of a physical address, telephone number, and / or other user identification (such as a social security number or tax identification number). Such authentication documents provide evidence that the user resides or conducts personal or professional business at the physical address. The address registration engine may contact the address authenticator 130 to verify the user's physical address based on some combination of authentication documents.

[0038] Operation 230 tests whether (one or more) address authenticators have successfully verified that the physical address is associated with the user. If not verified, then in operation 240, the user code may not be stored in association with the address. If the address is verified, then in operation 250, the verified address may be stored in association with the user code in the address repository 140. In operation 260, the user may be notified of the successful storage of the user code in association with the address. The notification to the user may include the user code provided with the request, the user code provided with the request modified by the address registration engine, or a new user code generated by the address registration engine.

[0039] In operation 270, the address registration engine waits to receive further requests. The address registration engine may also receive a request to modify a user address or user code that has been stored in association with the user. Upon receiving a request to modify information that has already been stored, the address information may be retrieved from the repository and the new information may be verified.

[0040] Figure 3 1 is a flow diagram illustrating a user requesting a service from an application that requires a physical address for fulfillment according to one or more embodiments. In an embodiment, a user may have an account with application 160. User information provided to the application may be stored in a profile. In operation 310, the user provides a user code that the application stores in the user profile instead of storing a physical street address and / or phone number.

[0041] In the embodiment illustrated by this flow, the application stores the user code in the user profile without storing the address information (operation 320). Therefore, the application does not need to retrieve the address after storing the user code in the profile. The application can only retrieve the address when the user requests a specific service from the application that requires a certain portion of the address. After retrieving the address from the address server, the application can use the address to fulfill the instant order and may not cache the address in the user profile. If the address information changes in the future, the updated information will be automatically provided when resolving the user code.

[0042] In an embodiment, the application can use the user code to resolve the address during account setup. The physical address obtained from the address server can be stored in the profile instead of storing the user code. However, if the physical address information changes in the future, the user may have to log in to the account and manually update the address information stored in the profile.

[0043] After setting up the user profile, the user can request a service from the application (operation 330). The requested service may require physical address information to provide the service. In operation 340, the application can retrieve a user code from the user's profile and, in operation 350, send the user code to the address server to obtain the portion of the physical address required to provide the service to the user.

[0044] In operation 360, if the application receives the requested portion of the user's physical address, then the application uses the physical address information to deliver the service to the user in operation 380. Otherwise, in operation 370, the application denies the user's service request.

[0045] In an embodiment, the application may be a combination of different services. For example, the application may have an order entry component that interacts with the user to construct a purchase order. The order entry component may calculate the total cost of the order and receive payment information. However, another component of the application may handle order fulfillment and shipping. In an embodiment where the total cost of the purchase order does not depend on the location to which the item is shipped, the order entry component does not require an address. For example, when free shipping is provided or a standard shipping rate that does not depend on the delivery destination is used, the shipping cost may not depend on the destination address. Similarly, even when the order receiving component needs to calculate the shipping cost to request payment from the user, the zip code may be sufficient to calculate the cost, and the entire address may not be required. The shipping service may resolve the user code into a shipping address, but is not authorized to access other user profile information.

[0046] Figure 4 4 is a flow diagram illustrating sending a user's address to an application that provides services to the user according to one or more embodiments. In operation 410, the address server 150 receives a request from the application 160 to receive address information associated with a user code of the user. The application may request a portion of the address information (such as a phone number or city / state), or the request may request the entire address (i.e., all information in the address record).

[0047] In an embodiment, authorizing an application to receive address information may include (a) authenticating the application itself or (b) authenticating possession of a user code. In an embodiment, the address server 150 may authenticate the application 160 before continuing to process the request. It will be appreciated by those of ordinary skill in the art that any mutual authentication means between the two entities may be used to establish trust between the application and the address server, such as a previous registration of the application to the server and two-factor authentication or a public / private key encryption protocol. In an embodiment, authorizing an application to receive address information may include authenticating the user code. Authenticating the user code ensures that the application receives the user code from the user, which is not forged and is not forwarded from an external entity without the user's permission. For example, in an embodiment where the application retrieves the address shortly after receiving the user code, an additional dynamically changing alphanumeric code may be sent with the user code to establish authenticity to the address server. Before the user provides the user code to the application, the user may request a temporary alphanumeric code that expires after a short period of time (such as after a few minutes). The application may send the alphanumeric code together with the user code to the address server to prove that the application receives the user code from the user.

[0048] However, any means of authentication data may be used for determining that the user code is associated with the user and / or that the application received the user code from the user rather than from some other source.

[0049] In operation 420, the address server may contact the user via the user device 110 to obtain authorization for the application to receive the requested portion of the address. In operation 430, the address server may receive a response from the user via the user device that grants or denies authorization to provide the address information to the application. Even though the user may have provided the application with a user code, there may be several reasons why the user did not grant authorization. For example, the user may not have requested a service from the application at that time, or the application may have requested more information than was required to fulfill the user's service request. In an embodiment, the user may authorize a portion of the address information that may be different from the requested portion of the address information.

[0050] In operation 440, if the user denies authorization, the application's request to the address server may be denied in operation 450. If the user grants authorization, the address server may send the authorized portion of the address information to the application in operation 460.

[0051] 4. Examples

[0052] Using a user code to represent a user's address can be a human-friendly way to eliminate the need to manually enter a complete address each time a user registers to a new application or website. The address validation process can identify errors in the address provided by the user, such as typographical errors or misremembered zip codes. Storing the exact location map coordinates provides more precise input for navigation applications, resulting in better navigation instructions.

[0053] Example addresses can include:

[0054] KIM CRUISE

[0055] NO.17,DENVER ELKS LODGE

[0056] 2475 WEST 26TH AVENUE

[0057] DENVER,COLORADO 80211

[0058] USA

[0059] Mobile: +12607601234

[0060] Email: kimcruise@gmail.com

[0061] Coordinates: (39°44'27.6"N, 104°59'31.0"W)

[0062] An example template for a user code representing an address may include: <userid> @ <jurisdiction>, where jurisdiction represents the area over which the userid is unique, such as a city, state, country, or region. An example user code for Kim Cruise of this form might be kimcruise01@denver or kimcruise01@colorado. Alternatively, the user code may be an automatically generated unique identifier, such as 938172635467348 or Kimcruise789.

[0063] In the example below, Kim orders a pizza from a restaurant with which Kim has no prior contact. The pizza restaurant, Pizzas'R Us, has never delivered pizza to Kim before. Figure 5 is a block diagram illustrating sequential interactions between components in an address management system according to one or more embodiments. Figure 5 The numbered interactions in , explain the processing of the pizza delivery to Kim.

[0064] Kim registers her user code with the address registration engine 120 (step 1). She provides a user code (kimcruise01@denver), a mobile phone number, an email address, a complete physical address, and GPS coordinates (latitude and longitude). Kim can also provide a copy of her passport and her most recent phone bill to prove that the address and phone number provided are hers. The registration engine sends the address information and additional documents to the trusted address authenticator 130 to verify that the address provided by Kim is indeed Kim's address information (step 2). If Kim's information passes the check, a record is created in the address repository 140 that associates Kim's user code with her address information (step 3). Moreover, once the information is verified, Kim receives a notification that her registration has been approved and can now use her user code (step 4).

[0065] Kim decides, either immediately or at some later time, e.g., weeks or months after registering Kim's user code, to order a pizza online from a new pizza place, Pizzas'R Us. When prompted to enter her delivery address, Kim enters her user code as: kimcruise01@denver instead of entering her actual delivery address (step 5). The application 160 that accepts pizza orders from Pizzas'R Us receives Kim's order and requests the delivery address from the address server 150 (step 6). The application (in case of doubt about Kim's order) sends a request to the address server to receive the complete physical address and telephone number corresponding to kimcruise01@denver. The address server looks up Kim's physical address based on the user code kimcruise01@denver and retrieves the physical address from the repository (step 7).

[0066] In step 8, Kim Cruise receives a request from the address server for Kim's authorization to share her physical address and phone number with Pizzas'R Us for pizza delivery. Kim authorizes the release of the information (step 9), and the address server sends the delivery address including GPS coordinates and phone number to Pizzas'R Us (step 10). Pizzas'R Us uses the exact map coordinates from the physical address to easily find the location to deliver Kim's pizza (step 11).

[0067] 5. Use distributed ledger technology

[0068] A distributed ledger (also known as a shared ledger or distributed ledger technology (DLT)) is a consensus of replicated, shared, and synchronized digital data geographically distributed across multiple sites, countries, or institutions. There is no central administrator or centralized data storage. A peer-to-peer network and consensus algorithms are used to ensure replication across nodes. One form of distributed ledger design is the blockchain system.

[0069] A blockchain is a growing list of records called blocks that are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. By design, blockchains are resistant to modification of data because they can efficiently record transactions between parties and permanently record transactions between parties in a verifiable manner. In order to function as a distributed ledger, peers in a peer-to-peer network use decentralized consensus to verify blocks of data. Once recorded, the data in any given block cannot be retroactively changed without changing all subsequent blocks, which requires the consent of the majority of the network. Hyperledger is one of the many frameworks for building distributed ledgers and is used as an example to describe how the present invention can be implemented with distributed ledger technology. For example, components under the hyperledger umbrella include identity and permission management and blockchain managers.

[0070] Figure 6 1 is a block diagram illustrating an address repository implemented as a peer-to-peer distributed ledger network according to one or more embodiments. In this example, the address repository 140 is implemented as a network of three peers 610, 620, and 630. In an embodiment, each peer maintains a copy of a state database and a corresponding ledger. The state database stores address information in association with user code, and the ledger that can be implemented by the blockchain records transactions applied to the state database (semantically similar to a transaction log file). Each peer in the network can independently receive transaction requests, fulfill requests, and pass transactions and state changes to other peers in the network.

[0071] The address registration engine and the address server may each be assigned an identity known to the distributed ledger network. Each identity may be associated with an appropriate level of access to data stored in the repository. For example, in one embodiment, the identity of the address registration engine may be associated with authorization to create new user codes / addresses in the repository or to modify existing associations that already exist in the repository. In an embodiment, the identity of the address server may be associated with authorization to read information stored in the repository.

[0072] Figure 7 is a block diagram illustrating an address registration engine interacting with one of the peers of a peer-to-peer distributed ledger network in accordance with one or more embodiments. Those skilled in the art will appreciate that there are many ways to select one of a set of identical peers. Any of the peers may be selected to receive a request based on, for example, physical proximity, current load, polling, or random selection. Figure 7 In the example of , the address registration engine interacts with a peer 610 of the address repository 140. The address registration engine can send a new user code / address association to the peer 610 along with a request to create a new association in the database.

[0073] The transaction interface 710 can receive transactions related to the address management system. Using the word "asset" as a shorthand for the user code / address association in the repository, examples of transactions can include creating assets, modifying assets, deleting assets, and reading assets. Therefore, the address registration engine sends a create asset request to the transaction interface 710. The transaction interface 710 receives the transaction request and provides the transaction to the transaction manager 720. In order to process the create asset transaction, the transaction manager 720 writes a transaction such as (create kimcruise01@denver) to the ledger 730. The ledger 730 can be a blockchain. The transaction manager 720 can also write a new record for kimcruise01@denver to the state database 740. The peer coordinator 750 can send the newly created transaction to other peers. In an embodiment, the new database record can also be sent to the peers in the network. In an embodiment, each peer that receives the transaction can apply the transaction that creates a new record in its local state database. When completed, each peer can have a ledger and a state database with the same content, which includes the new user code and address.

[0074] In the context of an address management system, a distributed ledger network can have a specific geographic scope. Figure 8 Illustrated is a collaborative distributed ledger network in accordance with one or more embodiments. Figure 8 A global ledger network is illustrated including a United States (US) distributed ledger network 810, an Indian distributed ledger network 820, and a United Kingdom (UK) distributed ledger network 830. For example, the US network 810 may manage physical addresses located in the United States, and all peers in the US network may maintain ledgers and databases for US physical addresses only. All peers participating in the Indian network 820 may maintain ledgers and databases for Indian physical addresses only. Likewise, the UK network 830 may maintain ledgers and databases for managing UK addresses only.

[0075] In an embodiment, the distributed ledger network itself may include the ability to communicate between independent distributed ledger networks to provide a global distributed network. For example, a company located in the United States may need the physical address of the user code of a user located in India. The application for the company can send the user code and the request to receive the corresponding physical address to the address server 150A in the United States. The address server 150A in the United States can send a read asset transaction to the local peer of the US network 810, thereby requesting the Indian physical address. In the global distributed network, the peer in the US network 810 can forward the request to the peer in the Indian network 820. If the Indian user who provides the desired user code to the Indian network 820 grants permission, the peer in the Indian network 820 can retrieve the desired physical address and send the physical address to the peer in the US network 810 that issued the request. The peer in the US network can relay the physical address back to the address server 150A. The address server 150A can then provide the Indian address to the application of the US company that issued the request.

[0076] Collaboration between ledger networks may require peers in one ledger network to have an identity known to the other ledger networks and associated with the necessary authorizations. For example, a peer in the US network 810 may have an identity known to the Indian network 820 and the UK network 830, with associated read-only access.

[0077] In an embodiment, each distributed ledger may be independent of each other, with no inter-ledger connection or cooperation. In an embodiment, each address server may be known to the associated local ledger network. For example, address server 150A may have an identity known to the US network 810; address server 150B may have an identity known to the Indian network 820; and address server 150C may have an identity known to the UK network 830. The identity of address server 150A may also be known to address server 150B, and vice versa. An application of a US company that wants to retrieve an Indian physical address may send an Indian user code with a request to retrieve the corresponding physical address to address server 150A. Address server 150A may forward the request to its trusted counterpart (address server 150B). Address server 150B may retrieve the physical address information from the Indian ledger network 820 and forward the physical address back to address server 150A. In turn, address server 150A may send the Indian physical address information to the application of the US company that issued the request.

[0078] 6. Computer Networks and Cloud Networks

[0079] In one or more embodiments, a computer network provides connectivity between a collection of nodes. The nodes may be local to each other and / or remote from each other. The nodes are connected by a collection of links. Examples of links include coaxial cables, unshielded twisted pairs, copper cables, optical fibers, and virtual links.

[0080] A subset of nodes implements a computer network. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes uses a computer network. Such nodes (also referred to as "hosts") can execute client processes and / or server processes. A client process makes a request for a computing service (such as the execution of a particular application and / or the storage of a particular amount of data). The server process responds by performing the requested service and / or returning corresponding data.

[0081] A computer network may be a physical network, comprising physical nodes connected by physical links. A physical node is any digital device. A physical node may be a function-specific hardware device, such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, a physical node may be a general-purpose machine configured to execute various virtual machines and / or applications that execute corresponding functions. A physical link is a physical medium that connects two or more physical nodes. Examples of links include coaxial cables, unshielded twisted cables, copper cables, and optical fibers.

[0082] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in the overlay network corresponds to a corresponding node in the underlying network. Therefore, each node in the overlay network is associated with both an overlay address (addressing the overlay node) and an underlying address (addressing the underlying node that implements the overlay node). An overlay node may be a digital device and / or a software process (such as a virtual machine, an application instance, or a thread). The link connecting the overlay nodes is implemented as a tunnel through the underlying network. The overlay nodes at either end of the tunnel treat the underlying multi-hop path between them as a single logical link. Tunneling is performed by encapsulation and decapsulation.

[0083] In an embodiment, the client may be located locally and / or remote from the computer network. The client may access the computer network through other computer networks, such as a private network or the Internet. The client may transmit the request to the computer network using a communication protocol, such as a hypertext transfer protocol (HTTP). The request is transmitted through an interface, such as a client interface, such as a web browser, a program interface, or an application programming interface (API).

[0084] In an embodiment, a computer network provides connectivity between a client and network resources. Network resources include hardware and / or software configured to execute a server process. Examples of network resources include processors, data storage devices, virtual machines, containers, and / or software applications. Network resources are shared between multiple clients. Clients request computing services from a computer network independently of each other. Network resources are dynamically allocated to requests and / or clients on demand. The network resources allocated to each request and / or client can be expanded or reduced based on, for example, (a) computing services requested by a specific client, (b) aggregate computing services requested by a specific tenant, and / or (c) the requested aggregate computing services of the computer network. Such a computer network may be referred to as a "cloud network."

[0085] In an embodiment, a service provider provides a cloud network to one or more end users. The cloud network can implement various service models, including but not limited to software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). In SaaS, a service provider provides the end user with the ability to use the service provider's applications that are being executed on network resources. In PaaS, a service provider provides the end user with the ability to deploy customized applications on network resources. Customized applications can be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, a service provider provides the end user with the ability to supply processing, storage, network, and other basic computing resources provided by network resources. Any arbitrary application, including an operating system, can be deployed on network resources.

[0086] In an embodiment, a computer network can implement various deployment models, including but not limited to private cloud, public cloud and hybrid cloud. In a private cloud, network resources are supplied to a specific group of one or more entities for exclusive use (the term "entity" as used herein refers to an enterprise, organization, individual or other entity). Network resources can be local and / or remote from the premises of a specific entity group at the premises of a specific entity group. In a public cloud, cloud resources are supplied to multiple entities (also referred to as "tenants" or "customers") that are independent of each other. A computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network can be referred to as a "multi-tenant computer network". Several tenants can use the same specific network resources at different times and / or at the same time. Network resources can be local and / or remote from the premises of a tenant. In a hybrid cloud, a computer network includes a private cloud and a public cloud. The interface between a private cloud and a public cloud allows portability of data and applications. Data stored at a private cloud and data stored at a public cloud can be exchanged through an interface. Applications implemented at a private cloud and applications implemented at a public cloud may have dependencies on each other. Calls from an application at the private cloud to an application at the public cloud (and vice versa) may be performed through the interface.

[0087] In an embodiment, the tenants of a multi-tenant computer network are independent of each other. For example, the business or operation of one tenant can be separated from the business or operation of another tenant. Different tenants may have different network requirements for the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, elasticity requirements, quality of service (QoS) requirements, tenant isolation and / or consistency. The same computer network may need to implement different network requirements required by different tenants.

[0088] In one or more embodiments, in a multi-tenant computer network, tenant isolation is implemented to ensure that applications and / or data of different tenants are not shared with each other. Various tenant isolation methods can be used.

[0089] In an embodiment, each tenant is associated with a tenant ID. Each network resource of the multi-tenant computer network is marked with a tenant ID. Only when the tenant and the specific network resource are associated with the same tenant ID, the tenant is allowed to access the specific network resource.

[0090] In an embodiment, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with the tenant ID. Additionally or alternatively, each data structure and / or data set stored by the computer network is tagged with the tenant ID. A tenant is allowed to access a specific application, data structure, and / or data set only if the tenant and the specific application, data structure, and / or data set are associated with the same tenant ID.

[0091] As an example, each database implemented by a multi-tenant computer network can be marked with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a particular database. As another example, each entry in a database implemented by a multi-tenant computer network can be marked with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a particular entry. However, a database can be shared by multiple tenants.

[0092] In an embodiment, the subscription list indicates which tenants have access to which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. Only when the tenant ID of a tenant is included in the subscription list corresponding to a specific application, the tenant is allowed to access the specific application.

[0093] In an embodiment, network resources corresponding to different tenants (such as digital devices, virtual machines, application instances, and threads) are isolated to tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, a data packet from any source device in a tenant overlay network can be sent only to other devices within the same tenant overlay network. The encapsulation tunnel is used to prohibit any transmission from a source device on a tenant overlay network to devices in other tenant overlay networks. Specifically, a data packet received from a source device is encapsulated in an outer data packet. The outer data packet is sent from a first encapsulation tunnel endpoint (communicating with a source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with a destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer data packet to obtain the original data packet sent by the source device. The original data packet is sent from the second encapsulation tunnel endpoint to a destination device in the same specific overlay network.

[0094] 7. Hardware Overview

[0095] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform the present technology, or can include a digital electronic device permanently programmed to perform the present technology, such as one or more application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or network processing units (NPUs), or can include one or more general-purpose hardware processors programmed to perform the present technology according to program instructions in firmware, memory, other storage devices, or combinations. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs, FPGAs, or NPUs with customized programming to implement the present technology. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that implements the present technology in combination with hard-wired and / or program logic.

[0096] For example, Fig. 9 900 is a block diagram illustrating a computer system 900 upon which embodiments of the present invention may be implemented. Computer system 900 includes a bus 602 or other communication mechanism for communicating information and a hardware processor 604 coupled with bus 602 for processing information. Hardware processor 604 may be, for example, a general purpose microprocessor.

[0097] The computer system 600 also includes a main memory 606, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 902 for storing information and instructions to be executed by the processor 904. The main memory 906 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 904. Such instructions, when stored in a non-transitory storage medium accessible to the processor 904, render the computer system 900 a special-purpose machine customized to perform the operations specified in the instructions.

[0098] Computer system 900 also includes a read only memory (ROM) 908 or other static storage device coupled to bus 902 for storing static information and instructions for processor 904. A storage device 910, such as a magnetic or optical disk, is provided and coupled to bus 902 for storing information and instructions.

[0099] The computer system 900 may be coupled via the bus 902 to a display 912, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 914, including alphanumeric and other keys, is coupled to the bus 902 for communicating information and command selections to the processor 904. Another type of user input device is a cursor control 916, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 904 and for controlling cursor movement on the display 912. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify a position in a plane.

[0100] The computer system 900 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, makes the computer system 900 a special purpose machine or programs the computer system 900 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 900 in response to the processor 904 executing one or more sequences of one or more instructions contained in the main memory 906. These instructions may be read into the main memory 906 from another storage medium, such as the storage device 910. Execution of the sequences of instructions contained in the main memory 906 causes the processor 904 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0101] The term "storage medium" as used herein refers to any non-transitory medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 910. Volatile media include dynamic memory, such as main memory 906. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with hole patterns, RAM, PROM and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cassette, content addressable memory (CAM) and ternary content addressable memory (TCAM).

[0102] Storage media are distinct from but may be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that comprise bus 902. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0103] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 904 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to the computer system 900 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 902. Bus 902 carries the data to main memory 906, from which processor 904 retrieves and executes the instructions. The instructions received by main memory 906 may optionally be stored on storage device 910 before or after execution by processor 904.

[0104] Computer system 900 also includes a communication interface 918 coupled to bus 902. Communication interface 918 provides a two-way data communication coupled to a network link 920, wherein network link 920 is connected to a local network 922. For example, communication interface 918 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a telephone line of a corresponding type. As another example, communication interface 918 can be a LAN card that provides a data communication connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communication interface 918 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0105] The network link 920 typically provides data communication to other data devices through one or more networks. For example, the network link 920 can provide a connection to a host computer 924 or to data equipment operated by an Internet Service Provider (ISP) 926 through a local network 922. The ISP 926 in turn provides data communication services through a global packet data communication network now commonly referred to as the "Internet" 928. Both the local network 922 and the Internet 928 use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 920 and through the communication interface 918 are example forms of transmission media, which carry digital data to or from the computer system 900.

[0106] Computer system 900 can send messages and receive data, including program code, through the network(s), network link 920, and communication interface 918. In the Internet example, server 930 can transmit the requested code for an application program through Internet 928, ISP 926, local network 922, and communication interface 918.

[0107] The received code may be executed by processor 904 as it is received, and / or stored in storage device 910 or other non-volatile storage for later execution.

[0108] Embodiments are directed to a system having one or more devices including a hardware processor and configured to perform any of the operations described herein and / or as recited in any of the following claims.

[0109] In an embodiment, a non-transitory computer-readable storage medium comprises instructions that, when executed by one or more hardware processors, cause performance of any of the operations described herein and / or recited in any of the claims.

[0110] According to one or more embodiments, any combination of the features and functions described herein may be used. In the foregoing description, embodiments have been described with reference to many specific details, which may vary from implementation to implementation. Therefore, the description and drawings should be viewed in an illustrative rather than a restrictive sense. The only and exclusive indication of the scope of the invention and what the applicant intends to be the scope of the invention is the literal and equivalent scope of the resulting claims in the specific form of a set of claims generated by this application, including any subsequent corrections.

[0111] Appendix A

[0112] WIKIPEDIA

[0113] Hyperledger

[0114] _____________________________________________________________________

[0115] Hyperledger (or the Hyperledger project) is an umbrella project of open source blockchains and related tools, [1] started in December 2015 by the Linux Foundation , [2] to support the collaborative development of blockchain-based Distributed ledgers .

[0116] Contents

[0117] ___________________

[0118] History and aims

[0119] Members and governance

[0120] Hyperledger Frameworks

[0121] Hyperledger Burrow

[0122] Hyperledger Fabric

[0123] Hyperledger Iroha

[0124] Hyperledger

[0125] Sawtooth

[0126] Hyperledger Indy

[0127] Hyperledger Tools

[0128] Hyperledger Caliper

[0129] Hyperledger Cello

[0130] Hyperledger Composer

[0131] Hyperledger

[0132] Explorer

[0133] Hyperledger Quilt

[0134] References

[0135] External links

[0136] History and aims

[0137] _____________________________________________________________________

[0138] In December 2015,the Linux Foundation announced the creation of theHyperledger Project.The founding members of the project were announced inFebruary 2016 and ten further members and the makeup of the governing boardwere announced March 29. [3] On May 19, Brian Behlendorf was appointed executivedirector of the project. [4]

[0139] The objective of the project is to advance cross-industrycollaboration by developing blockchains and distributed ledgers,with aparticular focus on improving the performance and reliability of thesesystems(as compared to comparable cryptocurrency designs)so that they arecapable of supporting global business transactions by major technological,financial and supply chain companies. [5] The project will integrate independentopen protocols and standards by means of a framework for use-specificmodules,including blockchains with their own consensus and storage routines,as well as services for identity,access control and smart contracts.Early onthere was some confusion that Hyperledger would develop its own bitcoin-typecryptocurrency,but Behlendorf has unreservedly stated that the HyperledgerProject itself will never build its own cryptocurrency. [6]

[0140] In early 2016,the project began accepting proposals for incubation ofcodebases and other technologies as core elements.One of the first proposalswas for a codebase combining previous work by Digital Asset , Blockstream 'slibconsensus and IBM 's OpenBlockchain. [7] This was later named Fabric. [8] In May,Intel's distributed ledger,named Sawtooth, [9] was incubated.

[10] On 12 July 2017the project announced its production-ready Hyperledger Fabric 1.0 and itstarted to gain popularity in the Initial coin offering market.

[11] In July2017, London Stock Exchange Group in a partnership with IBM announced that itwill create a blockchain platform designed for digitally issuing shares ofItalian companies with Hyperledger Fabric as the basis of the platform.

[12] InAugust 2017, Oracle joined the Hyperledger consortium and announced itsBlockchain Cloud Service offering.

[13]

[14] In September 2017 the Royal Bank of Canada (RBC)started using Hyperledger for its US-Canada interbank settlements.

[15]

[0141] Members and governance

[0142] _____________________________________________________________________

[0143] Early members of the initiative included blockchain ISVs,(Blockchain, ConsenSys , Digital Asset , R3 ,Onchain),wellknown technology platform companies( Cisco , Fujitsu , Hitachi , IBM , Intel , NEC , NTT DATA , Red Hat , VMware ),financialservices firms( ABN AMRO , ANZ Bank , BNY Mellon , CLS Group , CME Group ,the Depository Trust & Clearing Corporation (DTCC), Deutsche Group , JPMorgan , State Street , SWIFT , Wells Fargo ),business software companies like SAP ,academicinstitutions(Cambridge Centre for Alternative Finance,Blockchain at Columbia,UCLA Blockchain Lab),systems integrators and others( Accenture ,Calastone, Wipro ,Credits, Guardtime ,IntellectEU, Nxt Foundation , Symbiont ).

[0144] The governing board of the Hyperledger Project consists of twentymembers chaired by Blythe Masters ,(CEO of Digital Asset),and a twelve-memberTechnical Steering Committee chaired by Christopher Ferris ,CTO of OpenTechnology at IBM.

[0145] Hyperledger Frameworks

[0146] _____________________________________________________________________

[0147] Hyperledger Burrow

[0148] Burrow

[16] is a blockchain client including a built-to-specification Ethereum Virtual Machine.Contributed by Monax

[17] and sponsored by Monax and Intel .

[18]

[0149] Hyperledger Fabric

[0150] Hyperledger Fabric is a permissioned blockchain infrastructure,originally contributed by IBM

[19] and Digital Asset,providing a modulararchitecture with a delineation of roles between the nodes in theinfrastructure,execution of Smart Contracts (called"chaincode"in Fabric)andconfigurable consensus and membership services.A Fabric Network comprises"Peer nodes",which execute chaincode,access ledger data,endorse transactionsand interface with applications."Orderer nodes"which ensure the consistencyof the blockchain and deliver the endorsed transactions to the peers of thenetwork,and MSP services,generally implemented as a Certificate Authority,managing X.509 certificates which are used to authenticate member identityand roles.

[20]

[0151] Fabric is primarily aimed at integration projects,in which aDistributed Ledger Technology(DLT)is required,offering no user facingservices other than an SDK for Node.js , Java and Go .Fabric supports chaincodein Go and JavaScript (via Hyperledger Composer ,or natively sincev1.1)out-of-the-box,and other languages such as Java by installing appropriate modules.Itis therefore potentially more flexible than competitors that only support aclosed Smart Contract language.

[0152] Hyperledger Iroha

[0153] Based on Hyperledger Fabric,with a focus on mobileapplications.Contributed by Soramitsu.

[21]

[0154] Hyperledger Sawtooth

[0155] Originally contributed by Intel,Sawtooth includes a dynamic consensusfeature enabling hot swapping consensus algorithms in a running network.Amongthe consensus options is a novel consensus protocol known as"Proof of ElapsedTime,"a lottery-design consensus protocol that optionally builds on trustedexecution environments provided by Intel's Software Guard Extensions (SGX).

[22] Sawtooth supports Ethereum smart contracts via"seth"(a Sawtooth transactionprocessor integrating the Hyperledger Burrow EVM).

[23] In addition to Soliditysupport,Sawtooth includes SDKs for Python,Go,Javascript,Rust,Java,and C++

[24]

[0156] Hyperledger Indy

[0157] Indy

[25] is a Hyperledger project for supporting independent identityon distributed ledgers.It provides tools,libraries,and reusable componentsfor providing digital identities rooted on blockchains or other distributedledgers.Contributed by the Sovrin Foundation.

[26]

[0158] Hyperledger Tools

[0159] _____________________________________________________________________

[0160] Hyperledger Caliper

[0161] Hyperledger Caliper is a blockchain benchmark tool and one of theHyperledger projects hosted by The Linux Foundation.Hyperledger Caliperallows users to measure the performance of a specific blockchainimplementation with a set of predefined use cases.Hyperledger Caliper willproduce reports containing a number of performance indicators,such as TPS(Transactions Per Second),transaction latency,resource utilisation etc.Theintent is for Caliper results to be used by other Hyperledger projects asthey build out their frameworks,and as a reference in supporting the choiceof a blockchain implementation suitable for a user’s specific needs.

[0162] Hyperledger Caliper was initially contributed by developers fromHuawei,Hyperchain,Oracle,Bitwise,Soramitsu,IBM and the Budapest University ofTechnology and Economics.

[27]

[0163] Hyperledger Cello

[0164] Hyperledger Cello is a blockchain module toolkit and one of theHyperledger projects hosted by The Linux Foundation.Hyperledger Cello aims tobring the on-demand"as-a-service"deployment model to the blockchain ecosystemto reduce the effort required for creating,managing and terminatingblockchains.It provides a multi-tenant chain service efficiently andautomatically on top of various infrastructures,e.g.,baremetal,virtualmachine,and more container platforms.Hyperledger Cello was initiallycontributed by IBM,with sponsors from Soramitsu,Huawei and Intel.

[28]

[0165] Baohua Yang and Haitao Yue from IBM Research are committed part-timeto developing and maintaining the project.

[0166] Hyperledger Composer

[0167] Hyperledger Composer is a set of collaboration tools for buildingblockchain business networks that make it simple and fast for business ownersand developers to create smart contracts and blockchain applications to solvebusiness problems.Built with JavaScript,leveraging modern tools includingnode.js,npm,CLI and popular editors,Composer offers business-centricabstractions as well as sample apps with easy to test devops processes tocreate robust blockchain solutions that drive alignment across businessrequirements with technical development.

[29]

[0168] Blockchain package management tooling contributed by IBM.Composer isa user-facing rapid prototyping tooling,running on top of Hyperledger Fabric,which allows the easy management of Assets(data stored on the blockchain),Participants(identity management,or member services)and Transactions(Chaincode,a.k.a Smart Contracts,which operate on Assets on the behalf of aParticipant).The resulting application can be exported as a package(a BNAfile)which may be executed on a Hyperledger Fabric instance,with the supportof a Node.js application(based on the Loopback application framework)andprovide a REST interface to external applications.

[0169] Composer provides a GUI user interface"Playground"for the creation ofapplications,and therefore represents an excellent starting point for Proofof Concept work.

[0170] Hyperledger Explorer

[0171] Hyperledger Explorer is a blockchain module and one of theHyperledger projects hosted by The Linux Foundation.Designed to create auser-friendly Web application,Hyperledger Explorer can view,invoke,deploy orquery blocks,transactions and associated data,network information(name,status,list of nodes),chain codes and transaction families,as well as anyother relevant information stored in the ledger.Hyperledger Explorer wasinitially contributed by IBM,Intel and DTCC.

[30]

[0172] Hyperledger Quilt

[0173] Hyperledger Quilt is a business blockchain tool and one of theHyperledger projects hosted by The Linux Foundation.

[0174] Hyperledger Quilt offers interoperability between ledger systems byimplementing the Interledger protocol(also known as ILP),which is primarily apayments protocol and is designed to transfer value across distributedledgers and nondistributed ledgers.The Interledger protocol provides atomic swaps between ledgers(even non-blockchain or distributed ledgers)and a singleaccount namespace for accounts within each ledger.With the addition of Quiltto Hyperledger,The Linux Foundation now hosts both the Java(Quilt)andJavaScript(Interledger.js)Interledger implementations.Hyperledger Quilt wasinitially contributed by NTT Data and Ripple.

[31]

[0175] References

[0176] _____________________________________________________________________

[0177] 1.Ehsani,Farzam Buzzwordto Watchword in 2016"(http: / / www.coindesk.com / blockchain-finance-buzzword-watchword-2016 / ).CoinDesk(News).Retrieved 22 December 2016.

[0178] 2." Linux Foundation Unites Industry Leaders to Advance Blockchain Technology - The Linux Foundation"(http: / / www.linuxfoundation.org / news-media / announcements / 2015 / 12 / linux-foundation-unites-industryleaders-advance- blockchain .The Linux Foundation.2015-12-17.Retrieved 2018-04-28.

[0179] 3."Open Source Blockchain Effort for the Enterprise Elects LeadershipPositions and Gains New Investments-Hyperledger"(https: / / www.hyperledger.org / announcements / 2016 / 03 / 29 / open-source-blockchain-effort-for-theenterprise-elects-leadership-positions-and-gains-new-investments).Hyperledger.2016-03-29.Retrieved 2018-04-28.

[0180] 4. "Founder of the Apache Software Foundation Joins Linux Foundation to Lead HyperledgerProject"(https: / / www.hyperledger.org / announcements / 2016 / 05 / 19 / founder-of-the-apache-software-foundation-joinslinux-foundation-to- lead-hyperledger-project) .2016-05-19. Archived(https: / / web.archive.org / web / 20160610162631 / https: / / www.hyperledger.org / news / an nouncement / 2016 / 05 / founderapache-software-foundation-joins-linux-foundation-lead-hyperledger) from the original on 2016-06-10.

[0181] 5."Linux Foundation's Hyperledger Project Announces 30 FoundingMembers and Code Proposals To Advance Blockchain Technology"(https: / / www.hyperledger.org / announcements / 2016 / 02 / 09 / linux-foundations-hyperledgerproject-announces-30-founding-members-and-code-proposals-to- 2016-02-09.

[0182] Archived

[0183] (https: / / web.archive.org / web / 20160225023123 / https: / / www.hyperledger.org / news / an nouncement / 2016 / 02 / hyperledgerproject-announces-30-founding-members)from the original on 2016-02-25.Retrieved 2016-02-17.

[0184] 6. "Hyperledger Blockchain Project Is Not About Bitcoin"(http: / / www.eweek.com / cloud / hyperledger-blockchain-projectis-not-about-bitcoin.html) .eWEEK.Retrieved 2018-04-28.

[0185] 7. "Incubating Project Proposal:Joint DAH / IBM proposal"(https: / / docs.google.com / document / d / 1XECRVN9hXGrjAjysrnuNSdggzAKYm6XESR6KmABwhkE / edit) .

[0186] Tamas Blummer,Christopher Ferris.March 29,2016.Retrieved June 21,2016.

[0187] 8. "hyperledger / fabric"(https: / / github.com / hyperledger / fabric) .GitHub.Retrieved 2016-06-23.

[0188] 9. "hyperledger / sawtooth-core"(https: / / github.com / hyperledger / sawtooth-core) .GitHub.Retrieved 2018-04-28.

[0189] 10."Sawtooth Lake Hyperled ger Incubation Proposal"(https: / / docs.google.com / document / d / 1j7YcGLJH6LkzvWdOYFIt2kpkVlLEmILErXL6t-Ky2zU / edit).Mic Bowman,Richard Brown.April 14,2016.Retrieved June 21,2016.11. "ICO Statistics-By Blockchain Platform"(https: / / icowatchlist.com / statistics / blockchain) .ICO Watch List.Retrieved 2018-04-28.

[0190] 12. "Italian Stock Exchange to Develop Hyperledger-Based Blockchain Shares Platform"(https: / / cointelegraph.com / news / italian-stock-exchange-to- develop-hyperledger-based-blockchain-sharesplatform) .Cointelegraph.19 July2017.

[0191] 13. "Database Giant Oracle Joins Hyperledger Blockchain Project- CoinDesk"(https: / / www.coindesk.com / databasegiant-oracle-joins-hyperledger- blockchain-project / ) .CoinDesk.2017-08-31.Retrieved 2017-11-15.

[0192] 14. "Oracle Launches Enterprise-Grade Blockchain Cloud Service" (https: / / www.oracle.com / corporate / pressrelease / oow17-oracle-launches- blockchain-cloud-service100217.html) .www.oracle.com.Retrieved 2017-11-15.

[0193] 15."Hyperledger Blockchain'Shadows'Canadian Bank's International Paymen ts"(https: / / cointelegraph.com / news / hyperledger-blockchain-shadows-canadian-banks-internationalpayments).Cointelegraph.28 September 2017.

[0194] 16. "hyperledger / burrow"(https: / / github.com / hyperledger / burrow) .GitHub.Retrieved 2018-04-28.

[0195] 17. "Monax"(https: / / monax.io) .Monax.Retrieved 2018-04-28.

[0196] 18.Keirns,Garrett. "Monax Adds Blockchain Code to Hyperledger GitHub Repository"(http: / / www.coindesk.com / monaxadds-blockchain-code-hyperledger- github-repository / ) .Coindesk.Coindesk.Retrieved 12 April 2017.

[0197] 19. "Hyperledger Fabric Website"(https: / / hyperledger.org / projects / fabric) .Retrieved 2018-02-07.

[0198] 20.Androulaki,Elli;Barger,Artem;Bortnikov,Vita;Cachin,Christian;Christidis,Konstantinos;"De Caro",Angelo;Enyeart,David;Ferris,Christopher;Laventman,Gennady;Manevich,Yacov;Muralidharan,Srinivasan;Murthy,Chet;Nguyen,Binh;Sethi,Manish;Singh,Gari;Smith,Keith;Sorniotti,Alessandro;Stathakopoulou,Chrysoula; Marko;"Weed Cocco",Sharon;Yellick,Jason(2018)."HyperledgerFabric:A Distributed Operating System for Permissioned Blockchains".arXiv:1801.10228(https: / / arxiv.org / abs / 1801.10228)[cs.DC(https: / / arxiv.org / archive / cs.DC)].

[0199] 21.Higgins,Stan. "Hyperledger Eyes Mobile Blockchain Apps With'Iroha' Project"(http: / / www.coindesk.com / hyperledger-mobile-blockchain-apps-iroha- project / ) .Coindesk.com.Coindesk.Retrieved 18 May 2017."Iroha was firstunveiled during a meeting of the project’s Technical Steering Committee lastmonth.Iroha is being pitched as both a supplement to other Hyperledger-tiedinfrastructure projects like IBM’s Fabric(on which it is based)and Intel’sSawtooth Lake."

[0200] 22.Bucci,Debbie."Blockchain and Its Emerging Role in Health IT andHealth-related research"(https: / / oncprojectracking.healthit.gov / wiki / download / attachments / 14582699 / 19-Blockchain_Whitepaper_Intel_Final.pdf)(PDF).U.S.Department of Health and Human Services,Office of the NationalCoordinator for Health Information Technology.Retrieved 18 May 2017.

[0201] 23.Bollen,Benjamin. "Introduce a start for Burrow EVM as Sawtooth Transaction Processor"(https: / / github.com / hyperledger / sawtooth-core / pull / 415) .github.com.Hyperledger.Retrieved 18 May 2017.

[0202] 24. https: / / sawtooth.hyperledger.org / docs / core / releases / latest / app_ developers_guide / sdk_table.html

[0203] 25."Getting Started with Indy"(https: / / github.com / hyperledger / indy-node / blob / master / getting-started.md).GitHub.Retrieved January 23,2018.

[0204] 26. "Sovrin"(https: / / sovrin.org / ) .Sovrin.Retrieved January 23,2018.

[0205] 27."Measuring Blockchain Performance with H yperledger Caliper- Hyper ledger"(https: / / www.hyperledger.org / blog / 2018 / 03 / 19 / measuring-blockchain-performance-with-hyperledgercaliper).Hyperledger.2018-03-19.Retrieved 2018-06-16.

[0206] 28. "Hyperledger Cello-Hyperledger"(https: / / www.hyperledger.org / projects / cello) .Hyperledger.Retrieved 2018-04-28.

[0207] 29. "Hyperledger Composer-Hyperledger"(https: / / www.hyperledger.org / projects / composer) .Hyperledger.Retrieved 2018-04-28.

[0208] 30."Hyperledger Explorer-Hyperledger"(https: / / www.hyperledger.org / projects / explorer).Hyperledger.Retrieved 2018-04-28.

[0209] 31. "Hyperledger Quilt-Hyperledger"(https: / / www.hyperledger.org / projects / quilt) .Hyperledger.Retrieved 2018-04-28.

[0210] External links

[0211] _____________________________________________________________________

[0212] ■ org / )

[0213] ■List of Hyperledger Members(https: / / www.hyperledger.org / about / members)

[0214] _____________________________________________________________________

[0215] Retrieved from

[0216] " https: / / en.wikipedia.org / w / index.php?title=Hyperledger&oldid= 856136330 "

[0217] This page was last edited on 23 August 2018,at 03:55(UTC).

[0218] Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply.By using this site,you agree to the Terms of Use and Privacy Policy . is a registered trademark of the Wikimedia Foundation,Inc. ,a non-profit organization.< / jurisdiction> < / userid>

Claims

1. A method for managing address information, comprising: The address of the receiving end user; Verify the end user's address; In response to verifying the address: generating a first record associating the address with a user code corresponding to an end user, the user code comprising: (a) a set of characters representing a particular geographic region and (b) a user identifier unique among the user codes associated with the particular geographic region; storing the first record in a regional distributed blockchain ledger associated with the particular geographic region, the regional distributed blockchain ledger being one of a plurality of regional distributed blockchain ledgers associated with respective geographic regions; receiving a verification request from an application, the verification request comprising a user code and at least a portion of the address corresponding to the end user; retrieving the at least a portion of the end user's address from a first record of the regional distributed blockchain ledger based on the user code; verifying that the at least a portion of the address corresponding to the end user is consistent with an address stored in association with the first record; and A confirmation message is returned to the application indicating that the at least a portion of the address corresponding to the end user is verified.

2. The method of claim 1, wherein the at least a portion of the address included in the verification request comprises at least one of: a street address, a telephone number, a unique identifier issued by a government agency, and an email address.

3. A system comprising: at least one hardware device including a processor; as well as A system configured to perform the method according to any one of claims 1-2.

4. One or more non-transitory machine-readable media storing instructions which, when executed by one or more processors, cause the method of any one of claims 1-2 to be performed.

Images