Patent Application
20200349564
One or more implementations relate to the field of data management; and more specifically, to enabling interoperability between blockchain networks with different architectures and protocols.
A blockchain is a continuously expanding list of records/blocks that are linked and secured using cryptography. In particular, every block in a blockchain may include a cryptographic hash of the immediately preceding block, a timestamp for the current block, and transaction data (e.g., the addition/modification of information associated with a peer in a blockchain network). Further, the blockchain may be shared and managed through a peer-to-peer network via a system of verifying/validating new blocks to be added to the chain such that a block in a blockchain cannot be altered without alteration of all subsequent blocks, which requires network consensus. This architecture allows for security of information stored within blocks through the use of cryptography; sharing/distribution of information through the use of peer-to-peer networks; trust through the use of consensus of block addition; and immutability of information stored within blocks through the use of cryptography, chaining/linking of blocks, and peer distribution (e.g., each peer in the blockchain network may maintain a ledger of all verified/validated transactions in the network).
There are different blockchain architectures where different encryption algorithms are utilized, the blocks of the blockchain have differing data fields and where different consensus algorithms are utilized. Due to these differences between blockchain networks the blockchain and transactions stored within one blockchain network are not interoperable with other blockchain networks. Even where similar encryption and consensus algorithms are utilized, different blockchain networks will have different configurations and different set of participating nodes.
Consensus algorithms in blockchain architectures are distributed algorithms where the participating nodes implement a process to agree on the transactions to validate and the blocks to add to the blockchain. There are four primary consensus algorithms utilized in blockchain networks, namely, practical byzantine fault tolerance algorithm (PBFT), proof of work (PoW), proof of stake (PoS), and delegated proof of stake (DPoS). Each of these consensus algorithms can be utilized in a decentralized and distributed decision making scenario such as in blockchain networks.
While a given blockchain network is an open and public type of decentralized database. Each blockchain network operates independently from all other blockchain networks. A user could interact separately with multiple blockchain networks, but such interaction would require the user to independently interact with each blockchain network according to the protocols of each network without any mechanisms to correlate information and transactions in one blockchain network with the information and transactions of another blockchain network.
The following figures use like reference numbers to refer to like elements. Although the following figures depict various exemplary implementations, alternative implementations are within the spirit and scope of the appended claims. In the drawings:
The blockchain network A 101 and blockchain network B 102 can each include any number of participating nodes (e.g., nodes A1-4 and nodes B1-4, respectively) and implement any combination of blockchain technologies. The architecture of blockchain network A 101 and blockchain network B can differ in any aspect and any number of aspects. The blockchain network A 101 and blockchain network B 102 can implement any blockchain protocols including any blockchain block and transaction format and any consensus algorithm. Examples of existing blockchain protocols are utilized as part of cryptocurrencies (e.g., Bitcoin, and Ethereum), for data storage, smart contracts, and similar applications. Blockchain can be utilized in relation to customer relations management (CRM), for example tracking user loyalty points and similar data. In one example embodiment, provided for purpose of illustration, blockchain network A 101 is a Salesforce blockchain network that manages CRM data.
The blockchain network A 101 can include any number of participating nodes that either participate in the consensus protocol, mine blocks, and/or provide storage for the blockchain. The blockchain network A manages at least one blockchain that stores data and metadata. Metadata can include any descriptive information related to the transactions and blocks of transactions in the blockchain of blockchain network A 101. The blockchain of blockchain network A 101 can be any size and contain any number of blocks and any type of data stored therein consistent with the blockchain protocol implemented by the blockchain network A 101.
Similarly, the blockchain network B 102 can include any number of participating nodes that either participate in the consensus protocol, mine blocks, and/or provide storage for the blockchain. The blockchain network B 102 manages at least one blockchain that stores data and metadata. The metadata of blockchain network B 102 will differ from that of blockchain network A 101 and can include any descriptive information related to the transactions and blocks of transactions in the blockchain of blockchain network B 102. The blockchain of blockchain network B 102 can be any size and contain any number of blocks and any type of data stored therein consistent with the blockchain protocol implemented by the blockchain network B 102.
In the illustrated example, the blockchain network A 101 includes a set of participant nodes A1-A3. Similarly, the blockchain network B 102 includes a set of participant nodes B1-B3. These nodes implement the respective blockchain consensus algorithm of each blockchain network (e.g., a proof of stake, proof of work or similar consensus algorithm). The participant nodes A1-3 and B1-3 can participate in the consensus algorithm, blockchain storage, block mining and similar aspects of the blockchain management of the respective blockchain network. As mentioned, the blockchain network A 101 and blockchain network B 103 operate independently and do not have a capability to directly access or affect the transactions and content of the blockchain in the other blockchain networks, even where a relationship between the data in the two blockchain networks may be relevant to a user of both blockchain networks.
The embodiments provide an interoperability network 103 to enable each blockchain network to interact with the data in the blockchain of the other blockchain networks connected to the interoperability network 103. The interoperability network 103 can also be a separate blockchain network. The interoperability network 103 can include any number of participating nodes that either participate in the consensus protocol, mine blocks, and/or provide storage for the blockchain of the interoperability network 103. The interoperability network 103 manages at least one blockchain that stores data and metadata. The interoperability network 103 also includes at least one mapper 117 that maps the metadata of each connected blockchain network to each of the other blockchain networks that participate in the interoperability network 103. The mapper can utilize declarative mappings and/or derived mappings from the interoperability network 103 blockchain. The interoperability network 103 blockchain is a combination of the data from all of the connected blockchain networks. The interoperability network 103 participates or subscribes to each of the participating blockchain networks to add blocks with data equivalent to each of the blocks of the connected blockchain networks as they are added to the respective networks. Metadata mappings can include any correlations between any of the metadata or regular data fields of the different blockchain networks including mappings of the descriptive information related to the transactions and blocks of transactions in the blockchains of blockchain network A 101 and blockchain network B 103. The blockchain of interoperability network 103 can be any size and contain any number of blocks and any type of data stored therein consistent with the blockchain protocol implemented by the interoperability 103.
The interoperability network 103 supports a delegated consensus process and a consensus on consensus process whereby the interoperability network 103 receives a delegated consensus from one serviced blockchain network and then determines another blockchain network that can resolved the delegated consensus, maps the delegated consensus to the metadata format and data format of the identified blockchain network, and then forwards the transformed delegated consensus to the identified blockchain network. The interoperability network 103 then receives a resolution of the delegated consensus from the identified blockchain network upon which consensus is performed creating a consensus on consensus, the outcome of which is returned to the blockchain network that initially delegated the consensus to the interoperability network 103, which enables the initial blockchain network and user to resolve the delegated consensus of the initial blockchain network. In turn, the initial blockchain network can notify the interoperability network 103, which enables the interoperability network 103 to complete the resolution of the set of related delegated consensus requests.
The operation of the interoperability network 103 can be understood with reference to the illustrated example of
The interoperability network 103 facilitates interoperability by mapping transactions from one blockchain network (e.g., blockchain network A 101) into another blockchain network (e.g., blockchain network B 102). In this example, blockchain network A 101 processes the product purchase transaction to confirm that the retailer has a product available by searching the blockchain in blockchain network A 101 for inventory and begins a consensus process that emits a transaction that can include an entity type (product), entity data (product code or similar information), cost (e.g., in cryptocurrency value), and user or similar information. Blockchain network A 101 cannot resolve the transaction and delegates final consensus to the interoperability network 103.
The blockchain network A 101 and its constituent nodes need not have specific knowledge of the interoperability network 103. A node or set of nodes of the interoperability network 103 can participate in or monitor the transactions of the blockchain network A 101. The node that participates in the blockchain network A 101 can vary or be dynamically selected to prevent a given node from interfering with interoperability and to distribute load. A mapper 107 can implement the transaction servicing and mapping in the interoperability network and can be implemented at any node of the interoperability network 103 or can be a distributed process. The emitted transaction of blockchain network A 101 awaits final consensus and thereby delegates consensus to the interoperability network 103.
The interoperability network 103 processes the emitted transaction via the mapper 107, which identifies mappings for the blockchain network 101 to apply to the emitted transaction. The mappings can be declarative (e.g., defined by developers or similar entity associated with blockchain network A 101) or derived (e.g., from an associated smart contract). The mappings can be a one-to-one or many-to-many relationship. The mapper 107 identifies the mappings to be applied by determining each of the other blockchain networks that are needed to resolve the transaction. The mapper 107 can examine the fields and values of the transaction and compare with the blockchain of the interoperability network 103 to find matches. In the example, a search of the blockchain of interoperability network 103 can find a match between the user and cryptocurrency in the emitted transaction in a block that originated from blockchain network B 102. Matches with multiple blockchain networks are possible. With each map the transaction received from blockchain network A 101 can be mapped to a transaction in a matching blockchain network using mappings specific to the relationship between the blockchain network that emitted the transaction and the blockchain network with matching data. The interoperability network 103 can then emit the transformed transaction to the respective blockchain network.
The interoperability network 103 includes nodes that are participating in each blockchain network. In the example, node B in the interoperability network 103 is designated dynamically to emit the transformed transaction for blockchain network B 102. In this manner the interoperability network 103 delegates consensus to the blockchain networks with relevant data, in this example, blockchain network B 102. The blockchain networks receiving transformed transactions process them as any internally generated transaction. In this example, the blockchain network B is a cryptocurrency blockchain that would deduct the cost of the product in cryptocurrency from the cryptocurrency held by the user. If the user has sufficient currency, then the transaction would be validated, and consensus reached in blockchain network B 102. The blockchain network B 102 would add the transformed transaction as a block to its blockchain.
The interoperability network 103 network would receive via the participating nodes of the blockchain network B 102 (e.g., node B) the outcome of the consensus algorithm. If consensus was not reached in blockchain network B 102, then the failure of the transaction would cascade back to the originating blockchain network A 101. For example, if the user did not have sufficient cryptocurrency for the transaction, consensus would not be reached, and the transaction would not be added to the blockchain of blockchain network B 102. The interoperability network 103 would then examine its state upon monitoring the failed consensus and determine that it was awaiting the outcome of the transaction to complete its own consensus process. Transactions can be tracked based on a transaction identifier, which can be any explicit or derived value unique to a given transaction. Thus, the consensus algorithm for the transformed transaction would similarly fail in the interoperability network 103. In turn, the node A participating in blockchain network A 101 would relay the failed transaction to cause the delegated consensus of blockchain network A 101 to similarly fail.
If the blockchain network B 102 does reach consensus and ad the transaction to its blockchain, then the interoperability network 103 would continue its consensus algorithm in response by examining the state of the consensus algorithm in light of the consensus of the blockchain network B 102. If the interoperability network 103 has detected that all transformed transactions have reached consensus in their respective blockchain networks, then the interoperability network 103 can reach consensus on consensus. In addition to the delegated consensus the interoperability network 103 can also examine additional criteria in reaching consensus such network conditions, timeliness and similar criteria. The interoperability network 103 adds a block to its blockchain for a transaction that is committed to the blockchain network B 102.
The blockchain network A 101 receives the consensus on consensus from the interoperability network 103 via the participating node A. The blockchain network A 101 can then complete its consensus algorithm which is also a consensus on consensus scenario. The blockchain network A 101 completes its consensus algorithm and commits the transaction to its blockchain. The interoperability network 103 receives the result of this consensus via a participating node (e.g., node A) and completes its consensus algorithm, as another consensus on consensus scenario. As a result, the transaction of blockchain A 101 is added to the blockchain of the interoperability network 103 thereby completing the overall process such that the original transaction of blockchain network 101 has utilized the data and update blockchain network B 102 as facilitated by the interoperability network 103 and the mapper 107.
The transformed transaction can then be forwarded to the second blockchain network (Block ‘B10). The forwarding of the transformed transaction can be via a node of the interoperability network that is participating in the second blockchain network. The mapper of the interoperability network can than await receipt of a result of the consensus algorithm of the second blockchain network. Upon receipt of the consensus of the second blockchain network (Block 212) either in the form of a rejected transaction or committed transaction, the mapper determines consensus (i.e., a form of consensus on consensus) for the interoperability network (Block 214). The interoperability network can find consensus (Block 216) where each of the target blockchain networks return a commitment of the respective transformed transaction. In some embodiments, additional criteria can be included in the consensus algorithm of the interoperability network. Where consensus is not reached by the interoperability network then the received transaction is rejected (Block 218), which is related to the first blockchain network causing the originating transaction to fail to commit.
If the interoperability network reaches consensus based on the consensus on consensus with the target networks, then the transaction is validated, and the transaction is recorded for the transaction of the second blockchain network (Block 220). The successful consensus is relayed to the first blockchain network via a node of the interoperability network that participates in the first blockchain network (Block 222). The mapper of the interoperability network can than await receipt of a result of the consensus algorithm of the first blockchain network. Upon receipt of the consensus of the first blockchain network (Block 224) either in the form of a rejected transaction or committed transaction, the mapper determines a second consensus (i.e., a form of consensus on consensus) for the interoperability network (Block 226). The interoperability network can find consensus where the first blockchain network returns a commitment of the initial transaction. In some embodiments, additional criteria can be included in the consensus algorithm of the interoperability network. Where consensus is not reached by the interoperability network then the received transaction is rejected (Block 228). If consensus on consensus is reached, then the transaction of the first blockchain network is validated and the transaction is added to the blockchain of the interoperability network (Block 230).
The interoperability network can be implemented at least in part as a peer-to-peer blockchain network 308 as illustrated in one example embodiment. The blockchain networks that are serviced by the interoperability network can similarly be implemented as a peer-to-peer blockchain network 308. The example of
In this example, as will be described in greater detail below, a transaction generator 1101 of the tenant system 3021 may generate a request to (1) add/insert a new record to/into a physical object associated with the tenant system 3021 or (2) modify/update an existing record of the physical object associated with the tenant system 3021. The physical object may include a set of fields for each record and is stored in a portion/partition of the tenant level objects 304B of the multi-tenant server 304 associated with the tenant system 3021 such that a physical object is only accessible to the tenant system 3021 (e.g., the tenant system 3022 and the tenant system 3023 are not permitted to read or write to the physical object of the tenant system 3021) where a physical object is a committed block or similar data structure in a blockchain. The request may cause the addition of a record in a shadow object in the portion/partition of a tenant level objects 304B associated with the tenant system 3021. The shadow object represents uncommitted data related to a physical object (i.e., data for which a consensus amongst the peers/tenants in the peer-to-peer blockchain network 308 has not yet been achieved). The shadow object may be used by the transaction queue 304A for generating a transaction object, which will be distributed/made available to the other tenant systems 3022 and 3023 for receiving consensus for the proposed addition/modification to the physical object of the tenant system 3021.
In one implementation, the set of fields of the transaction object is a subset of the fields of the physical object and the set of fields of the transaction object are defined by an exchange object, which is included in the network level objects 304C. In this implementation, the exchange object may include a set of exchange fields, which will be included in the transaction object, and each exchange field of the exchange object may be mapped to a field in the physical objects of the tenant systems 3021-3023. For example, a physical object of the tenant system 3021 may include fields A-D, a physical object of the tenant system 3022 may include fields E-H, and a physical object of the tenant system 3023 may include fields I-K. In this example, a first exchange field of the exchange object of the peer-to-peer blockchain network 308 may be mapped to the field B of the tenant system 3021, the field F of the tenant system 3022, and the field I of the tenant system 3023. Similarly, a second exchange field of the exchange object of the peer-to-peer blockchain network 308 may be mapped to the field C of the tenant system 3021, the field E of the tenant system 3022, and the field J of the tenant system 3023. Accordingly, when a proposal for adding/modifying a record for the physical object of the tenant system 3021 is received, the corresponding transaction object includes the first exchange field with a value from field B of the proposed physical/shadow object and the second exchange field with a value from field C of the proposed physical/shadow object. The exchange object provides a uniform transaction object via mapping metadata for verification/validation purposes in the peer-to-peer blockchain network 308 while allowing the tenant system 3021 to only reveal particular portions of information to other tenants/peers in the peer-to-peer blockchain network 308 (e.g., sensitive information/fields in physical objects may not be included in transaction objects which are distributed amongst tenant systems 3021-3023 in the peer-to-peer blockchain network 308 and later included in distributed ledgers).
As described herein, the multi-tenant server 304 may perform many of the functions of the peer-to-peer blockchain network 308 on behalf of the tenant systems 3021-3023. In particular, the multi-tenant server 304 may include a virtual space/organization for each of the tenant systems 3021-3023. Each virtual space/organization may include data and applications/services for corresponding tenant systems 3021-3023 and is logically separate from all other virtual spaces/organizations of other tenant systems 3021-3023. For example, each virtual space/organization may include tenant level objects 304B corresponding to respective tenants/tenant systems 3021-3023 and separate instantiations of or access to blockchain services 304D. In this configuration/architecture, the virtual space/organization for each tenant system 3021-3023 may perform one or more blockchain functions/operations on behalf of the corresponding tenant system 3021-3023. For example, in response to receipt of a request from the tenant system 3021 to add/insert a new record to/into or modify/update an existing record of a physical object of the tenant system 3021, the multi-tenant server 304 may generate a shadow object record in the virtual space/organization of the tenant system 3021 within the multi-tenant server 304. In response, a transaction queue 304A may generate a transaction object corresponding to the record in the shadow object using the exchange object of the peer-to-peer blockchain network 308, such that the transaction object includes exchange fields with data from the shadow object, and a set of cryptographic keys of the tenant system 3021 such that the transaction object may be distributed or otherwise be made available to virtual spaces/organizations of the other tenant system 3022 and 3023.
In particular, the security service 312 of the blockchain services 304D may encrypt each exchange field of a transaction object based on permission/privilege levels of each tenant system 302. For example, the security service 312 may determine that the tenant system 3021 has read, update, and insert permissions/privileges for first and second exchange fields. In contrast, the tenant system 3022 may only have read permission for the first exchange field and read and update permissions for the second exchange field. Lastly, the tenant system 3023 may have no permissions/privileges in relation to the first exchange field and read, update, and insert privileges for the second exchange field. In this example situation, the security service 312 may generate a first set of keys for the tenant system 3021, a second set of keys for the tenant system 3022, and a third set of keys for the tenant system 3023 based on the private and public keys of the tenant system 3021-3023 and the assigned permission/privilege levels. The first set of keys allow the tenant system 3021 to read, update, and insert data in relation to the first and second exchange fields; the second set of keys allow the tenant system 3022 to read the first exchange field and read and update the second exchange field; and the third set of keys allow the tenant system 3023 to read, update, and insert data in relation to the second exchange field. Accordingly, as described above and as will be described in greater detail below, the security service 312 of the multi-tenant server 304 provides permission/privilege level control of data in the blockchain network 308.
After distribution of the transaction object, the virtual spaces/organizations of the other tenant systems 3022 and 3023 may thereafter analyze the transaction object to determine whether validation/verification is appropriate. The transaction queue 304A may wait for validation/verification from the virtual spaces/organizations of the tenant systems 3022 and 3023 such that consensus for the proposed alteration to the physical object of the tenant system 3021 is achieved. In response to this consensus, a virtual space/organization of a leader tenant system 3021-3023 may (1) add a record or modify a record (as appropriate) in a corresponding physical object and (2) add a corresponding entry/block to a distributed ledger of the leader tenant system 3021-3023. Thereafter, the virtual space/organization of a leader tenant system 3021-3023 may transmit a request to the virtual spaces/organizations of the other/remaining tenant systems 3021-3023 to commit the change to their physical objects (based on a mapping defined in the exchange object) and/or add a corresponding entry/block to a ledger of these tenant systems 3021-3023. As illustrated above and as will be described in greater detail below, the cloud environment provided by the multi-tenant server 304 (e.g., the virtual spaces/organizations provided by the multi-tenant server 304) may be used for managing blockchain transactions between the tenant systems 3021-3023. In particular, the security service 312 encrypts exchange fields such that permissions/privileges (e.g., read, update, and insert permissions/privileges) may be enforced per peer/tenant system 302 and per exchange field.
In an embodiment, the interoperability network includes a mapper 314 that enables a mapping of data and/or metadata of one blockchain to the data and/or metadata of another blockchain. The mapper 314 can utilize mapping objects, exchange objects or similar data structures to map the fields of data and/or metadata between the physical object or transaction object of one blockchain to another blockchain. The mapper 314 can support mapping of blockchain objects between any number and variety of blockchain networks. The mappings can be declarative and input by administrators of the interoperability network, developers of any of the blockchain networks that participate in the interoperability, or similarly input by related user. The management of mappings can be limited by permissions to users of blockchains affected by the mappings, e.g., developers of blockchains into which a transaction object or similar blockchain object or data structure is being mapped.
Each element of the computing environment 300 of
As shown in
Each of the tenant systems 3021-3023 may be a computing system that may be operated by one or more users. For example, each of the tenant systems 3021-3023 may be a personal computer (PC), a workstation, a laptop computer, a tablet computer, a mobile phone, a smartphone, a personal digital assistant (PDA), or the like. As will be described in greater detail below, the tenant systems 3021-3023 may communicate with the multi-tenant server 304 to modify/add/store and retrieve data.
The tenant systems 3021-3023 (sometimes referred to as client, peer, or user systems) may each include a screen/display (e.g., a liquid crystal (LCD) display) for presenting an interface (e.g., a graphical user interface (GUI)) to a user, including an interface presented in a web page. As will be described in greater detail below, each of the tenant systems 3021-3023 may include a corresponding transaction generator 1101-1103 for receiving inputs from a user to alter a physical object associated with the tenant system 3021-3023 (e.g., addition of a new record in the physical object or modification of an existing record in the physical object) and triggering the process of obtaining consensus (e.g., verification/validation) from the other tenant systems 3021-3023 in the peer-to-peer blockchain network 308 for the alteration.
The tenant systems 3021-3023 may each be associated with one or more organizations/tenants. For example, users of the tenant system 3021 may be customers of a first organization/tenant and a user of the tenant system 3023 may be a customer of a second organization/tenant. Organizations/tenants may be any firm, corporation, institution, association, or society that has contracted with an administrator of the multi-tenant server 304 to provide users access to data stored therein via the tenant systems 3021-3023.
In one implementation, the multi-tenant server 304 may be any computing device that provides users access to resources via the tenant systems 3021-3023 and the communication network(s) 306. For example, the multi-tenant server 304 may provide users of the tenant systems 3021-3023 access to data in one or more physical objects and/or one or more corresponding distributed peer ledgers that describe changes to the physical objects. For example, a physical object of the tenant system 3021 may correspond to a medical lab report. In this example implementation, the records in the physical object may include a lab report identifier field, a patient name field, a lab network identifier field, a lab test identifier field, a patient identifier field, and a social security number field. When an alteration/change is desired to a physical object of a tenant system 3021-3023 (e.g., addition of a new record to a physical object or modification of an existing record in a physical object), the multi-tenant server 304 uses the transaction queue 304A, the tenant level objects 304B, the network level objects 304C, and the blockchain services 304D to attempt to make these alterations in the peer-to-peer blockchain network 308 (e.g., alterations reflected in physical objects and distributed ledgers associated with the tenant systems 3021-3023).
The multi-tenant server 304 may include various elements of hardware and software of a multi-tenant system. As used herein, the term “multi-tenant system” refers to those systems in which various elements of hardware and software may be shared by one or more tenants. For example, the multi-tenant server 304 may simultaneously process requests for a great number of tenants, and a given database table may store records for a potentially much greater number of tenants. The multi-tenant server 304 may include an application platform including a framework (e.g., services and metadata) that allows applications to execute, such as the hardware or software infrastructure of the system. In one implementation, the multi-tenant server 304 includes separate virtual spaces/organizations (sometimes referred to as portions or partitions) for data/objects as well as services of each tenant system 3021-3023. For example, each tenant system 3021-3023 may be assigned a separate virtual space/organization. Each virtual space/organization is a logical partition within the multi-tenant server 304 and includes separate tenant level objects 304B that are only accessible to that tenant system 3021-3023 and are inaccessible to other tenant systems 3021-3023 (e.g., tenant systems 3021-3023 cannot read and/or write tenant level objects 304B of another tenant system 3021-3023) in addition to services used by the multi-tenant server 304 on behalf of the corresponding tenant system 3021-3023 (e.g., blockchain services 304D).
As shown in
Although shown with three tenants/peers (e.g., the tenant systems 3021-3023), in other implementations, the peer-to-peer blockchain network 308 may include more or fewer tenants/peers. For example, the peer-to-peer blockchain network 308 may include two, four, five, or more tenants/peers with corresponding tenant systems 302. Accordingly, the use of three tenants/peers is for illustrative purposes.
The membership service 402A may generate a set of public keys (PKs) and private/secret keys (SKs) for each tenant/tenant system 3021-3023 in the peer-to-peer blockchain network 308. In one implementation, the public keys are generated based on a determined private key. For example, a one-way cryptographic hash function (e.g., SHA256) may be used to generate public keys for the tenant systems 3021-3023 based on corresponding private keys. In one implementation, the public keys and the private/secret keys may be stored by the membership service 402A in the wallet object 404C following generation. As will be described in greater detail below, the transaction queue 304A may utilize the private/secret keys stored in the wallet object 404C for generating transaction objects and sets of permission keys for each of the tenant systems 3021-3023. In particular, the public keys and private/secret keys may be used by the transaction queue 304A for implementing cryptographic elements of transactions used by the peer-to-peer blockchain network 308 and the security service 312 may use the permission keys for enforcing permission/privileges of tenant systems 3021-3023.
The membership service 402A may determine an exchange object for the peer-to-peer blockchain network 308. In one implementation, the exchange object is defined by a set of exchange fields and mapping metadata that defines mappings between each exchange field and fields in physical objects of the tenant systems 3021-3023. For example,
For the example physical objects 4061-4063 shown in
The mapping of exchange fields 604 to fields 506, 512, and 518 of physical objects 4061-4063 indicates a relationship between the fields 506, 512, and 518 of physical objects 4061-4063. For instance, using the example above in which the physical object 4061 represents medical lab reports and the physical object 4062 represents patient files, the field 5062 of the physical object 4061 may correspond to a patient identifier for which a corresponding medical lab report was generated and the field 512H of the physical object 4062 may correspond to a patient identifier for which a corresponding patient file represents. As shown in
In some implementations, each tenant/tenant system 3021-3023 may be part of multiple blockchain networks, including the blockchain network 308. Each of these blockchain networks may include overlapping membership with the blockchain network 308 and/or may include additional peers/tenant systems 302. In some implementations, the network object 404A may include identifiers for each blockchain network managed by the multi-tenant server 304, the peers object 404B may include identifiers for each peer/tenant system 302 in the blockchain networks managed by the multi-tenant server 304, the wallet object 404C may include keys for each peer/tenant system 302 in the blockchain networks managed by the multi-tenant server 304, and the digital assets object 404D may include exchange objects 602 for each blockchain network managed by the multi-tenant server 304. In some implementations, the tenant level objects 304B for each tenant system 302 may include a mapping object 416. Each mapping object 416 includes the mapping metadata for the corresponding tenant system 302. For example, the mapping object 4161, which corresponds to the tenant system 3021, includes mapping metadata that maps exchange field 6041 to field 5062 of the physical object 4061; exchange field 6042 to field 506N of the physical object 4061; and exchange field 6043 to field 5061 of the physical object 4061. In contrast, the mapping object 4162, which corresponds to the tenant system 3022, includes mapping metadata that maps exchange field 6041 to field 512H of the physical object 4062; exchange field 6042 to field 5121 of the physical object 4062; and exchange field 6043 to field 5122 of the physical object 4062. Lastly, the mapping object 4163, which corresponds to the tenant system 3023, includes mapping metadata that maps exchange field 6041 to field 5182 of the physical object 4063 and exchange field 6042 to field 5181 of the physical object 4063. Accordingly, each mapping object 416 only includes mapping metadata associated with a corresponding tenant system 302.
The security service 312 may determine permissions/privileges (sometimes referred to as permission/privilege levels) per each exchange field 604 and tenant system 302. For example, the blockchain network 308 may offer read, update, and insert privileges per each exchange field 604. In this example, the security service 312 may determine that the tenant system 3021 has read, update, and insert permissions for the exchange fields 6041-6043. In contrast, the tenant system 3022 may only have read permission for the exchange field 6041 and read and update permissions for the exchange fields 6042 and 6043. Lastly, the tenant system 3023 may have no permissions/privileges in relation to the exchange field 6041 and read, update, and insert privileges for the exchange fields 6042 and 6043. The determination of privileges/permissions may be based on an indication from an administrator or a subscription level of the tenant systems 302.
The security service 312 may generate a set of permissions keys for each tenant system 302. The sets of permissions keys may be used by or on behalf of the tenant systems 302 for accessing one or more exchange fields 604. For example, each set of permission keys may include a separate key for each exchange field 604 and each permission/privilege level of a tenant system 302. For example,
The transaction management service 402B of the blockchain services 304D may receive (1) a proposed new record to add to a physical object 4061-4063 or (2) a modification to an existing record of a physical object 4061-4063. For instance, as described in the above example, the physical object 4061 may correspond to medical lab reports and the transaction management service 402B of the virtual space/organization 4141 may receive a request to add/insert a new lab report record 504 from the tenant system 3021. In another example, again the physical object 4061 may correspond to medical lab reports and the transaction management service 402B of the virtual space/organization 4141 may receive a request to modify an existing lab report record 504 from the tenant system 3021.
The security service 312 may determine if the tenant system 3021 has adequate permissions/privileges to perform a received request (e.g., the security service 312 determines whether the tenant system 3021 is authorized to add/insert a new lab report record 504). In one implementation, this determination is based on the security object 4181, which includes keys for each permission/privilege level 706 of the tenant system 3021. In particular, in response to failing to locate a permission key for each exchange field 604 requested to be inserted and corresponding to the insert permission/privilege 706, the security service 312 may determine that the tenant system 3021 does not have adequate permissions/privileges to perform the received request may move to reject the request.
In contrast, in response to locating a permission key for each exchange field 604 requested to be inserted and corresponding to the insert permission/privilege 706, the security service 312 may determine that the tenant system 3021 has adequate permissions/privileges to perform the received request.
The transaction management service 402B of the virtual space/organization 4141 generates a record in a shadow object 4081 corresponding to the received request (i.e., the new record). The shadow object 4081 may correspond to the tenant system 3021 and may include all the fields 5061-506N of the physical object 4061. In contrast to the physical object 4061, which stores committed data that is also represented in a corresponding peer ledger 4101 of the tenant system 3021 (e.g., additions/modifications to records 504 of the physical object 4061 of the tenant system 3021), the shadow object 4081 represents un-committed data to the physical object 4061. As will be described in greater detail below, the data in the shadow object 4081 of the tenant system 3021 needs to be validated/verified through consensus by the other tenant systems 3022 and 3023 before being committed to the physical object 4061 and represented by the peer ledger 4101 of the tenant system 3021. This committal and representation may also extend to the physical objects 4062 and 4063 and peer ledgers 4102 and 4103 of the tenant systems 3022 and 3023 as will be described in greater detail below.
The event management service 402C and/or the transaction queue 304A may generate a transaction object based on (1) the record 8041 added to the shadow object 4081 and (2) the exchange object 602 of the peer-to-peer blockchain network 308. In particular, the transaction object may include values for each of the exchange fields 6041-6043 and data/field values from the record 8041 added to the shadow object 4081 in corresponding exchange fields 6041-6043. For example,
As shown in
In one implementation, generation of the transaction object 902 may include adding a signature to the transaction object based on (1) the record 8041 from the shadow object 4081, (2) a unique assigned identifier of the transaction object 902 (e.g., an identifier assigned sequentially to transaction objects 902 as they are generated), and (3) the private key of the tenant system 3021 (i.e., the private key of the tenant system 302 proposing the alteration). For example, the record 8041 and the unique assigned identifier of the transaction object 902 may be merged or otherwise combined together to form a single message and the private key of the tenant system 3021 may be used to encrypt the message (e.g., using a one-way cryptographic hash function, such as SHA256) to form a digital signature. Accordingly, the transaction object 902 includes the record 8041 from the shadow object 4081 along with the signature generated using the private key of the tenant system 3021.
In some implementations, the security service 312 may separately encrypt each exchange field 604 of the transaction object 902 using (1) the private key of the tenant system 3021 (i.e., the private key of the tenant system 302 proposing the alteration); (2) a permission key of each tenant system 302 that has a permission/privilege 706 related to the exchange field 604 (i.e., permission keys of tenant systems 302 that have read, update, and/or insert privileges associated with the exchange fields 604); and/or (3) a public key of each tenant system 302 that has a permission/privilege related to the exchange field 604. In these implementations, using permission keys of each tenant system 302 that has a permission/privilege related to the exchange field 604 ensures that only these tenant systems 302 have access (e.g., read access) to corresponding exchange fields 604. In some implementations, private keys, public keys, and/or permission keys may be used along with a cryptographic function (e.g., SHA256) to generate encrypted data.
Returning to
The transaction management service 402B may monitor responses from the tenant systems 3022 and 3023 to determine if consensus has been reached regarding the transaction object 902 or if consensus has failed to be reached. In one implementation, the consensus management service 402D may define the threshold or rules for use by the transaction management service 402B in determining when consensus has been reached by the tenant systems 3022 and 3023 regarding the transaction object 902. For example, in some implementations, the consensus management service 402D may indicate that consensus requires all of the tenant systems 3022 and 3023 to verify/validate the transaction object 902, while in other implementations, the consensus management service 402D may indicate that consensus requires a majority of the tenant systems 3022 and 3023 to verify/validate the transaction object 902. In some implementations, the consent management service 402E indicates the rules and/or operations used by the tenant systems 3022 and 3023, and in particular the virtual spaces/organizations 4142 and 4143 associated with the tenant systems 3022 and 3023, to determine if verification/validation of the transaction object 902 is proper. For example, the consent management service 402E may indicate that the public key of the tenant system 3021 is used along with the signature and message in the transaction object 902 for determining whether the transaction object 902 originated from and was authorized by the tenant system 3021.
The transaction management service 402B and the transaction queue 304A may discard the transaction object 902 in response to failing to obtain consensus from the tenant systems 3022 and 3023 (e.g., failing to obtain consensus as defined/indicated by the consensus management service 402D). In some implementations, discarding the transaction object 902 may include indicating to the tenant system 3021 that the transaction object 902 and corresponding alteration to the physical object 4061 (i.e., addition of a new record 504 to the physical object 4061 or modification of an existing record 504 to the physical object 4061) has been rejected by the peer-to-peer blockchain network 308 (i.e., consensus in the peer-to-peer blockchain network 308 was not achieved/obtained). In response to receipt of notification that the transaction object 902 and corresponding alteration to the physical object has been rejected by the peer-to-peer blockchain network 308, the virtual space/organization 441 may delete the record 8041 in the shadow object 4081 corresponding to the transaction object 902.
The transaction management service 402B may commit the transaction object 902 and/or the record 8041 in the shadow object 4081 corresponding to the transaction object 902 for which consensus was achieved on behalf of a leader tenant system 3021-3023. In some implementations, a leader tenant system 3021-3023 may be randomly selected from amongst the tenant systems 3021-3023 in the peer-to-peer blockchain network 308 by the membership service 402A. When the leader tenant system 3021-3023 is the tenant system 3021 (i.e., the tenant system 3021-3023 that instigated or was otherwise associated with the alteration to the physical object 4061), the transaction management service 402B in the virtual space/organization 4141 of the tenant system 3021 may commit the record 8041 in the shadow object 4081, which corresponds to the transaction object 902 for which consensus was achieved, on behalf of the tenant system 3021. In this situation, committal may include adding the record 8041 from the shadow object 4081 to the physical object 4061. When the leader tenant system 3021-3023 is the tenant system 3022 or the tenant system 3023, the transaction management service 402B in the corresponding virtual space/organization 4142 and 4143 of the tenant systems 3022 and 3023 may commit the transaction object 902 that consensus was achieved on behalf of the tenant system 3022/3023. In this situation, committal may include adding a record 510/516 to or modifying a record 510/516 in the physical object 4062/4063 that includes the field values 806 from the shadow object 4081 mapped to corresponding fields 512/518 in the physical objects 4062/4063 as indicated by the exchange object 602 or corresponding mapping object 416.
The transaction management service 402B may add an entry/block in the peer ledger 4101-4103 corresponding to the transaction object 902 on behalf the leader tenant system 3021-3023. In particular, the transaction management service 402B of the virtual space/organization 4141-4143 of the leader tenant system 3021-3023 may add an entry/block in the peer ledger 4101-4103 corresponding to the transaction object 902 on behalf the leader tenant system 3021-3023. The entry/block added to the peer ledger 4101-4103 may include several pieces of information. For example, as shown in
Returning to
One or more tenant systems 302 may attempt to read one or more exchange fields 604 in a corresponding peer ledger 410. For example, the transaction object 902 that was added to the peer ledgers 4101-4103 of the tenant systems 3021-3023 in the example above included the exchange fields 6041-6043. As indicated above, each of the tenant systems 3021 3023 have assigned permission/privilege levels, which are indicated in corresponding security objects 4181-4183. Accordingly, permission/privilege levels of tenant systems 3021-3023 in relation to exchange fields 604 are independent. For example, the virtual space/organization 4141 of the tenant system 3021 may attempt to read the exchange field 6041 of a transaction object 902 stored in the peer ledger 4101. Since the security object 4181 of the tenant system 3021 includes a permission key for reading the exchange field 6041 (i.e., KEY_A), the virtual space/organization 4141 of the tenant system 3021 will be able to successfully to decode the value in the exchange field 6041 for the transaction object 902 stored in the peer ledger 4101 based on this permission key (i.e., KEY_A). Similarly, since the security object 4182 of the tenant system 3022 includes a permission key for reading the exchange field 6041 (i.e., KEY_J), the virtual space/organization 4142 of the tenant system 3022 will be able to successfully to decode the value in the exchange field 6041 for the transaction object 902 stored in the peer ledger 402 based on this permission key (i.e., KEY_J). However, since the security object 4183 of the tenant system 3023 does not include a permission key for reading the exchange field 6041, the virtual space/organization 4143 of the tenant system 3023 will not be able to successfully to decode the value in the exchange field 6041 for the transaction object 902 stored in the peer ledger 4103.
As illustrated above, the components of the multi-tenant server 304 manage data in the peer-to-peer blockchain network 308 on behalf of the tenant systems 3021-3023. In particular, the cloud environment provided by the multi-tenant server 304 may be used for securing data in transaction objects 902 stored in peer ledgers 410 such that unauthorized users/tenants/peers cannot view sensitive data.
In some implementations, the computing environments 400A and/or 400B may be built on top of a platform 412 comprised of services and/or metadata for implementing the other components of the multi-tenant server 304. In some implementations, the blockchain services 304D may include additional services, such as a coin service 402F for tracking records and items associated with each tenant/peer.
As used above, the term “user” is a generic term referring to an entity (e.g., an individual person) using a system and/or service. A multi-tenant architecture provides each tenant with a dedicated share of a software instance and the ability (typically) to input tenant specific data for user management, tenant-specific functionality, configuration, customizations, non-functional properties, associated applications, etc. Multi-tenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants. A tenant includes a group of users who share a common access with specific privileges to a software instance providing a service. A tenant may be an organization (e.g., a company, department within a company, etc.). A tenant may have one or more roles relative to a system and/or service. For example, in the context of a customer relationship management (CRM) system or service, a tenant may be a vendor using the CRM system or service to manage information the tenant has regarding one or more customers of the vendor. As another example, in the context of Data as a Service (DAAS), one set of tenants may be vendors providing data and another set of tenants may be customers of different ones or all of the vendors' data. As another example, in the context of Platform as a Service (PAAS), one set of tenants may be third party application developers providing applications/services and another set of tenants may be customers of different ones or all of the third-party application developers. A user may have one or more roles relative to a system and/or service. To provide some examples, a user may be a representative (sometimes referred to as an “end user”) of a tenant (e.g., a vendor or customer), a representative (e.g., an administrator) of the company providing the system and/or service, and/or a representative (e.g., a programmer) of a third-party application developer that is creating and maintaining an application(s) on a Platform as a Service (PAAS).
One or more parts of the above implementations may include software and/or a combination of software and hardware. An electronic device (also referred to as a computing device, computer, etc.) includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM), Flash memory, phase change memory, solid state drives (SSDs)) to store code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory (with slower read/write times, e.g., magnetic disks, optical disks, read only memory (ROM), Flash memory, phase change memory, SSDs) and volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)), where the non-volatile memory persists code/data even when the electronic device is turned off or when power is otherwise removed, and the electronic device copies that part of the code that is to be executed by the set of processors of that electronic device from the non-volatile memory into the volatile memory of that electronic device during operation because volatile memory typically has faster read/write times. As another example, an electronic device may include a non-volatile memory (e.g., phase change memory) that persists code/data when the electronic device is turned off, and that has sufficiently fast read/write times such that, rather than copying the part of the code/data to be executed into volatile memory, the code/data may be provided directly to the set of processors (e.g., loaded into a cache of the set of processors); in other words, this non-volatile memory operates as both long term storage and main memory, and thus the electronic device may have no or only a small amount of volatile memory for main memory. In addition to storing code and/or data on machine-readable storage media, typical electronic devices can transmit code and/or data over one or more machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals—such as carrier waves, infrared signals). For instance, typical electronic devices also include a set of one or more physical network interface(s) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. Thus, an electronic device may store and transmit (internally and/or with other electronic devices over a network) code and/or data with one or more machine-readable media (also referred to as computer-readable media).
Electronic devices are used for a variety of purposes. For example, an electronic device (sometimes referred to as a server electronic device) may execute code that cause it to operate as one or more servers used to provide a service to another electronic device(s) (sometimes referred to as a client electronic device, a client computing device, or a client device) that executes client software (sometimes referred to as client code or a tenant system) to communicate with the service. The server and client electronic devices may be operated by users respectively in the roles of administrator (also known as an administrative user) and end user.
In electronic devices that use compute virtualization, the set of one or more processor(s) 1122 typically execute software to instantiate a virtualization layer 1108 and software container(s) 1104A-R (e.g., with operating system-level virtualization, the virtualization layer 1108 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple software containers 1104A-R (representing separate user space instances and also called virtualization engines, virtual private servers, or jails) that may each be used to execute a set of one or more applications; with full virtualization, the virtualization layer 1108 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and the software containers 1104A-R each represent a tightly isolated form of a software container called a virtual machine that is run by the hypervisor and may include a guest operating system; with para-virtualization, an operating system or application running with a virtual machine may be aware of the presence of virtualization for optimization purposes). Again, in electronic devices where compute virtualization is used, during operation an instance of the software 1128 (illustrated as instance 1106A) is executed within the software container 1104A on the virtualization layer 1108. In electronic devices where compute virtualization is not used, the instance 1106A on top of a host operating system is executed on the “bare metal” electronic device 1100. The instantiation of the instance 1106A, as well as the virtualization layer 1108 and software containers 1104A-R if implemented, are collectively referred to as software instance(s) 1102.
Alternative implementations of an electronic device may have numerous variations from that described above. For example, customized hardware and/or accelerators might also be used in an electronic device.
A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, user electronic devices, server electronic devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video).
In one implementation, the system 1140 is a multi-tenant cloud computing architecture supporting multiple services, such as a customer relationship management (CRM) service (e.g., Sales Cloud by salesforce.com, Inc.), a contracts/proposals/quotes service (e.g., Salesforce CPQ by salesforce.com, Inc.), a customer support service (e.g., Service Cloud and Field Service Lightning by salesforce.com, Inc.), a marketing service (e.g., Marketing Cloud, Salesforce DMP, and Pardot by salesforce.com, Inc.), a commerce service (e.g., Commerce Cloud Digital, Commerce Cloud Order Management, and Commerce Cloud Store by salesforce.com, Inc.), communication with external business data sources (e.g., Salesforce Connect by salesforce.com, Inc.), a productivity service (e.g., Quip by salesforce.com, Inc.), database as a service (e.g., Database.com™ by salesforce.com, Inc.), Data as a Service (DAAS) (e.g., Data.com by salesforce.com, Inc.), Platform as a Service (PAAS) (e.g., execution runtime and application (app) development tools; such as, Heroku™ Enterprise, Thunder, and Force.com® and Lightning by salesforce.com, Inc.), an analytics service (e.g., Einstein Analytics, Sales Analytics, and/or Service Analytics by salesforce.com, Inc.), a community service (e.g., Community Cloud and Chatter by salesforce.com, Inc.), an Internet of Things (IoT) service (e.g., Salesforce IoT and IoT Cloud by salesforce.com, Inc.), industry specific services (e.g., Financial Services Cloud and Health Cloud by salesforce.com, Inc.), and/or Infrastructure as a Service (IAAS) (e.g., virtual machines, servers, and/or storage). For example, system 1140 may include an application platform 1144 that enables PAAS for creating, managing, and executing one or more applications developed by the provider of the application platform 1144, users accessing the system 1140 via one or more of user electronic devices 1180A-S, or third-party application developers accessing the system 1140 via one or more of user electronic devices 3080A-S.
In some implementations, one or more of the service(s) 1142 may utilize one or more multi-tenant databases 1146 for tenant data 1148, as well as system data storage 1150 for system data 1052 accessible to system 1140. In certain implementations, the system 1140 includes a set of one or more servers that are running on server electronic devices and that are configured to handle requests for any authorized user associated with any tenant (there is no server affinity for a user and/or tenant to a specific server). The user electronic devices 1180A-S communicate with the server(s) of system 1140 to request and update tenant-level data and system-level data hosted by system 1140, and in response the system 1140 (e.g., one or more servers in system 1140) automatically may generate one or more Structured Query Language (SQL) statements (e.g., one or more SQL queries) that are designed to access the desired information from the one or more multi-tenant database 1146 and/or system data storage 1050.
In some implementations, the service(s) 1142 are implemented using virtual applications dynamically created at run time responsive to queries from the user electronic devices 1180A-S and in accordance with metadata, including: 1) metadata that describes constructs (e.g., forms, reports, workflows, user access privileges, business logic) that are common to multiple tenants; and/or 2) metadata that is tenant specific and describes tenant specific constructs (e.g., tables, reports, dashboards, interfaces, etc.) and is stored in a multi-tenant database. To that end, the program code 1160 may be a runtime engine that materializes application data from the metadata; that is, there is a clear separation of the compiled runtime engine (also known as the system kernel), tenant data, and the metadata, which makes it possible to independently update the system kernel and tenant-specific applications and schemas, with virtually no risk of one affecting the others. Further, in one implementation, the application platform 1144 includes an application setup mechanism that supports application developers' creation and management of applications, which may be saved as metadata by save routines. Invocations to such applications, including the transaction queue 304A, the tenant level objects 304B, the network level objects 304C, and the blockchain services 304D, may be coded using Procedural Language/Structured Object Query Language (PL/SOQL) that provides a programming language style interface. A detailed description of some PL/SOQL language implementations is discussed in U.S. Pat. No. 7,730,478 entitled, METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by Craig Weissman, filed Sep. 21, 2007. Invocations to applications may be detected by one or more system processes, which manages retrieving application metadata for the tenant making the invocation and executing the metadata as an application in a software container (e.g., a virtual machine).
Network 1182 may be any one or any combination of a LAN (local area network), WAN (wide area network), telephone network, wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. The network may comply with one or more network protocols, including an Institute of Electrical and Electronics Engineers (IEEE) protocol, a 3rd Generation Partnership Project (3GPP) protocol, or similar wired and/or wireless protocols, and may include one or more intermediary devices for routing data between the system 1140 and the user electronic devices 1180A-S.
Each user electronic device 1180A-S (such as a desktop personal computer, workstation, laptop, Personal Digital Assistant (PDA), smart phone, etc.) typically includes one or more user interface devices, such as a keyboard, a mouse, a trackball, a touch pad, a touch screen, a pen or the like, for interacting with a graphical user interface (GUI) provided on a display (e.g., a monitor screen, a liquid crystal display (LCD), etc.) in conjunction with pages, forms, applications and other information provided by system 1140. For example, the user interface device can be used to access data and applications hosted by system 1140, and to perform searches on stored data, and otherwise allow a user 1184 to interact with various GUI pages that may be presented to a user 1184. User electronic devices 1180A-S might communicate with system 1140 using TCP/IP (Transfer Control Protocol and Internet Protocol) and, at a higher network level, use other networking protocols to communicate, such as Hypertext Transfer Protocol (HTTP), FTP, Andrew File System (AFS), Wireless Application Protocol (WAP), File Transfer Protocol (FTP), Network File System (NFS), an application program interface (API) based upon protocols such as Simple Object Access Protocol (SOAP), Representational State Transfer (REST), etc. In an example where HTTP is used, one or more user electronic devices 1180A-S might include an HTTP client, commonly referred to as a “browser,” for sending and receiving HTTP messages to and from server(s) of system 1140, thus allowing users 1184 of the user electronic device 1180A-S to access, process and view information, pages and applications available to it from system 1140 over network 1182.
In the above description, numerous specific details such as resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding. It will be appreciated, however, by one skilled in the art, that the invention may be practiced without such specific details. In other instances, control structures, logic implementations, opcodes, means to specify operands, and full software instruction sequences have not been shown in detail since those of ordinary skill in the art, with the included descriptions, will be able to implement what is described without undue experimentation.
References in the specification to “one implementation,” “an implementation,” “an example implementation,” etc., indicate that the implementation described may include a particular feature, structure, or characteristic, but every implementation may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same implementation. Further, when a particular feature, structure, or characteristic is described in connection with an implementation, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other implementations whether or not explicitly described.
Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations and/or structures that add additional features to some implementations. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain implementations.
In the following description and claims, the term “coupled,” along with its derivatives, may be used. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other.
The operations in the flow diagrams are be described with reference to the exemplary implementations in the other figures. However, the operations of the flow diagrams can be performed by implementations other than those discussed with reference to the other figures, and the implementations discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagrams.
While the flow diagrams in the figures show a particular order of operations performed by certain implementations, it should be understood that such order is exemplary (e.g., alternative implementations may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
While the above description includes several exemplary implementations, those skilled in the art will recognize that the invention is not limited to the implementations described and can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus illustrative instead of limiting.
