Note: Descriptions are shown in the official language in which they were submitted.
BACKGROUND
The advantages of a decentralized database have been stressed upon by many
sources, mostly
relating to cryptocurrency and business management. While these large-scale
applications are
useful in their own way, smaller scale applications such as private or
commercial security can also
have merit. A security system with such a decentralized database that can
verify accessors while
being difficult to tamper with would be effective. Blockchains inherently
contain a record of past
activity while being difficult to fake. A system that uses blockchain
technology and a user
login/password system would solve these problems.
FIELD OF INVENTION
The system described relates to blockchain technology and the study of
decentralized databases
and their applications. The system also falls under electronic security
systems.
DESCRIPTION
The system is composed of nodes.
One such example of the function of these nodes (shown in FIG. A) would be
keys (001, 003),
keyholes (002), and server(s) (004), which may or may not be the only example
of nodes. (001) and
(002) show an example of a hardware element used as a key with a hardware
element used as a
keyhole. (003) shows the same relationship as (001) but with software
components, the example
given being a smart device with an installed software application as a
software key. (004) shows an
example of a possible network of servers that the keys and keyholes interact
with, which in this
example is a peer-to-peer network (P2P).
An interaction between a key and a keyhole allowing user access is referred to
in this document as
a transaction. This may or may not be the only example of possible
transactions for this system.
Keys and keyholes may or may not store the following information which may or
not be the only
information stored within: an identifier that the system can recognize belongs
to a valid node, a
record of the identifiers of other nodes, and a record of previous valid
transactions. An identifier
may or may not be exclusive to a particular key or keyhole as long as it is
valid (fulfills
requirements that allow it to serve as an identifier which may or may not
include characteristics
such as number of transactions, type of data, format of data, etc. which may
or may not be
customizable by the user). The record of previous valid transactions may or
may not include all the
valid transactions that have occurred since the initialization of the system,
and may or may not be
truncated in some way.
CA 2986731 2017-11-27
The number of transactions stored on the keys and keyholes may or may not be
the same,
whether among themselves or each other. The record of transactions may or may
not be updated
on some basis, regular or irregular, and may or may not be updated based on
the record of
another valid node or other source.
The information that is sent across the networks between nodes may or may not
be encrypted
with some known algorithm. The information contained within nodes may or may
not be
encrypted with some known algorithm.
The key(s), keyhole(s), and server(s) may or may not be connected in some way
to other server(s)
in a larger network beyond just the system owned by the user
The server node may or may not be computationally stronger than non-server
nodes, and the role
of a server node may or may not be assigned to an another node which may or
may not occur at
any time and may or may not be computationally weaker. The reasons for this
may or may not
include user settings, server availability, system condition, etc.
The key nodes may or may not be computationally weaker than other nodes, and
may or may not
have any computing ability of their own. The keys may or may not rely on the
other nodes to
update or otherwise change the information stored within the key nodes.
All nodes may or may not have to be available for communication to allow
access. As long as a
sufficient number of nodes can verify the transaction, the transaction may be
considered valid.
This number of sufficiency may or may not be predetermined by the user or some
other source.
The nodes may or may not be unevenly given importance for the verification
process so that the
verification conclusion of one node can overrule the verification conclusion
of another. This
system of uneven importance may or may not be altered or assigned at any time
by a source
which may or may not be arbitrary, and may require the verification from
certain important nodes
for the transaction to be considered valid.
The addition or the removal of a node requires the entire system to recognize
the change as valid
and may or may not involve the assignment or removal of the node's identifier
that the system can
recognize belongs to a valid node, the node's record of the identifiers of
other nodes, the node's
record of previous valid transactions, and other data that may or may not be
stored on the node.
This assignment or removal may or may not involve any combination and any
number of these
listed previous.
CA 2986731 2017-11-27
The user may or may not override the system using some function which may or
may not be a
username/password system or just a password, an access key which may or may
not be hardware
or software, or some other sort of identification verification entirely. This
override will bypass the
initial verification required in the following two examples given but the
record of entry will still be
stored on the node system in the same way.
The user may or may not choose to have failed transactions stored in the
system in some way as
well. This choice may or may not be made by another entity. The details of the
transaction
attempt may or may not also be stored, whether this implies time of attempt,
frequency of
attempts, identity of attempt, location of attempt etc. These failed attempts
may or may not be
stored in the same way as standard successful attempts, but may or may not be
stored in the same
location, across all nodes, with the same encryption, on the same chain, or in
some other matter
or design.
CA 2986731 2017-11-27
One example of the system's function may comprise of the following steps, as
shown in FIG. B:
1) To gain access, the user will complete an action which will cause a key and
keyhole to initiate a
transaction (101), which may or may not contain information about the
particular key, the
particular keyhole, and other relevant information. This information may or
may not include data
such as the time, the date, the location, the frequency, the device used, the
model of key/keyhole,
etc. There may or may not be other information included.
2)The user may override the system (102) as described previous, in which case
the system
proceeds straight to updating each node with the details of the transaction
(109) and granting the
user access (110).
3)The key and keyhole will accept the information and may or may not check it
for errors (103)
which may or may not include valid signatures, valid data, etc. If none are
found (104), the key and
keyhole will attach their identifiers in some way and broadcast the details of
the transaction across
the system to any available nodes which will do their own verification
independently (105) and
attach identifiers and broadcast the transaction (106) if required. If an
error is found at any point
by any node the transaction is ignored (1X, 1Y).
4)Through this process eventually a copy of the information will reach a
server or servers which
may or may not be the only server or servers in the network, which will have
the identifiers of
each other valid node included (107). The server may or may not be assigned
randomly at any time
depending on several factors which may or may not include user discretion,
server availability,
system condition, etc.
5)The server may or may not verify the data (108) by checking the identifiers
and previous
transactions in the same way as the other nodes. If the copy it had received
has the signatures of
each other node and the server can also verify the data the information is
accepted as valid,
otherwise ignored (14. The server may or may not also verify this information
with other servers
in the system.
6)The server may or may not then append the information to its record of past
transactions and
send out information to each other node (109) which may or may not be the same
information or
have the same characteristics of the information that the server had received,
with the server's
identifier attached.
7)When each other node receives this information, they will check the
information for errors and
if none are found, will send out this information and permanently attach the
transaction to their
record of previous transactions.
8)When the initial nodes receive the confirmation information, the user is
allowed access (110).
CA 2986731 2017-11-27
Another example of the system's function which may comprise of the steps as
shown in FIG. C:
1)To gain access, the user will complete an action which will cause a key and
keyhole to initiate a
transaction (201), which may or may not contain information about the
particular key, the
particular keyhole, and other relevant information, this information may or
may not include data
such as the time, the date, the location, the frequency, the device used, the
model of key/keyhole,
etc. There may or may not be other information included.
2)The user may override the system (202) as described previous, in which case
the system
proceeds straight to updating each node with the details of the transaction
(209) and granting the
user access (210).
3)The key and keyhole will compare their stored records of past transactions
(203). If one record is
completely found within the other (204), the comparison is considered
successful. The keyhole
may or may not also verify that the record of the key has at least all the
transactions that have
occurred between the starting point of the keyhole's record and the key's last
transaction on the
keyhole's record. A failed comparison will cause the node to ignore the
transaction (2X).
4)The keyhole will send out the key's record information across the system to
any available nodes
(205), which may or may not only include keyholes in this instance. Each
receiving node will accept
the information and may or may not check it for errors and do its own
comparison between the
key's record and the receiving node's own record of transactions (206). A
successful comparison
will cause the keyhole to send out this information in much the Same way to
other nodes (207), a
failed comparison will cause the node to ignore the transaction (2Y).
5)Eventually all available nodes will have completed a comparison of the key's
record of
transactions. If the comparison is successful across a sufficient number of
nodes the transaction is
considered valid (208). This number of sufficiency is determined as described
above.
6)All available nodes including the initial key and keyhole nodes will add
this transaction to their
record of transactions (209).
7)The user is allowed access (210).
CA 2986731 2017-11-27
