U.S. patent application number 15/804899 was filed with the patent office on 2018-11-01 for providing data to a distributed blockchain network.
The applicant listed for this patent is INTERNATIONAL BUSINESS MACHINES CORPORATION. Invention is credited to Risham Y. CHOKSHI, Autumn GOOD, William LIVESEY, Andie SCHROEDER.
Application Number | 20180313798 15/804899 |
Document ID | / |
Family ID | 63916551 |
Filed Date | 2018-11-01 |
United States Patent
Application |
20180313798 |
Kind Code |
A1 |
CHOKSHI; Risham Y. ; et
al. |
November 1, 2018 |
PROVIDING DATA TO A DISTRIBUTED BLOCKCHAIN NETWORK
Abstract
A method, comprising receiving, by a computing system, sensor
data from a first sensor unit at a first location, converting, by
the computing system, the sensor data into a standardized format,
receiving, by the computing system, additional data corresponding
to a first parameter at the first location and forecast data
corresponding to the first parameter at the first location,
generating, by the computing system, predicted future sensor data
based on a comparison between the additional data, the sensor data,
and the forecast data, writing, by the computing system, the sensor
data, the additional data, and the predicted future sensor data
into a blockchain ledger, and submitting, by the computing system,
the ledger to a distributed blockchain database.
Inventors: |
CHOKSHI; Risham Y.; (North
Brunswick, NJ) ; GOOD; Autumn; (Austin, TX) ;
LIVESEY; William; (Seattle, WA) ; SCHROEDER;
Andie; (Alston, MA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
INTERNATIONAL BUSINESS MACHINES CORPORATION |
Armonk |
NY |
US |
|
|
Family ID: |
63916551 |
Appl. No.: |
15/804899 |
Filed: |
November 6, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15499432 |
Apr 27, 2017 |
|
|
|
15804899 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
Y02P 90/845 20151101;
G01D 9/005 20130101; G06F 21/78 20130101; G01N 33/004 20130101 |
International
Class: |
G01N 33/00 20060101
G01N033/00; G01D 9/00 20060101 G01D009/00 |
Claims
1. A method, comprising: receiving, by a computing system, sensor
data from a first sensor unit at a first location; converting, by
the computing system, the sensor data into a standardized format;
receiving, by the computing system, additional data corresponding
to a first parameter at the first location and forecast data
corresponding to the first parameter at the first location;
generating, by the computing system, predicted future sensor data
based on a comparison between the additional data, the sensor data,
and the forecast data; writing, by the computing system, the sensor
data, the additional data, and the predicted future sensor data
into a blockchain ledger; and submitting, by the computing system,
the ledger to a distributed blockchain database.
2. The method of claim 1, further comprising receiving, by the
computer, additional sensor data from a second sensor unit at a
second location.
3. The method of claim 2, wherein the sensor data from the first
sensor unit corresponds with carbon dioxide emissions at the first
location and the additional sensor data from the second sensor
corresponds with carbon dioxide emissions at the second
location.
4. The method of claim 1, further comprising: receiving, by the
computing system, blockchain timing instructions from a user;
wherein the writing into the ledger is in accordance with the
blockchain timing instructions.
5. The method of claim 1, further comprising: comparing, by the
computing system, the sensor data with a first threshold value; and
in response to a determination that the sensor data includes a
value that exceeds the first threshold value, sending, by the
computing system, a notification to a user.
6. The method of claim 5, wherein: the first threshold value is
received from the user by the computing system; and the first
threshold value corresponds with a carbon dioxide emission
allowance for the user.
7. The method of claim 1, further comprising: comparing, by the
computing system, the sensor data with a first threshold value
received from a user; and in response to a determination that the
sensor data includes a value that exceeds the first threshold
value, acquiring, by the computing system, an additional carbon
dioxide emission allowance for a user.
8. The method of claim 1, wherein the first parameter corresponds
with a temperature.
9. A method, comprising: accessing, by a computing system, a block
of a distributed blockchain database, the block including a first
ledger comprising sensor data and additional data corresponding
with a first parameter for a location of a first sensor unit; in
response to a determination that a value of the sensor data exceeds
a first threshold value, receiving, by the computing system, a
notification; in response to receiving the notification, acquiring,
by the computing system, additional allowances to increase a total
allowance value above a base allowance value; writing, by the
computing system, information corresponding to the acquired
allowances into a second ledger; and submitting, by the computing
system, the second ledger to the distributed blockchain
database.
10. The method of claim 9, wherein: the first threshold value is
less than the base allowance value; and a base allowance level is
less than the total allowance value.
11. The method of claim 9, further comprising, in response to
acquiring the additional allowance, determining a second threshold
value, the second threshold value being less than the total
allowance value.
12. The method of claim 11, further comprising: in response to a
determination that the value of the sensor data exceeds the second
threshold value, receiving a second notification; in response to
receiving the second notification, acquiring additional allowances
to increase the total allowance value; writing information
corresponding to the acquired allowances into a third ledger; and
submitting the third ledger to the distributed block chain
database.
13. The method of claim 9, further comprising receiving future
sensor data, the future sensor data being based on a comparison
between the location, the sensor data, and forecast data
corresponding with the first parameter.
Description
BACKGROUND
[0001] The present disclosure relates to monitoring environmental
parameters and, in some embodiments, trading environmental
parameter allowances, and more specifically, to methods and systems
for collecting, analyzing, acquiring and storing environmental
parameter data in a distributed database that maintains a growing
list of ordered records.
[0002] Carbon trading markets provide a financial incentive to
reduce carbon emissions. For example, companies may be allowed a
certain amount of carbon dioxide (a threshold limit) that they may
emit over the course of a specific period of time. Companies
emitting more carbon dioxide than the threshold limit may purchase
a right to emit additional carbon from another company whose carbon
emission allowance is then reduced by the amount purchased. Thus,
the total amount of carbon emission allocations remains the same.
However, these markets can be fragmented and disparate, which may
lead to suboptimal carbon trading. For example, lack of proper
standards for carbon emission measuring techniques leads to a drop
in consumer confidence which further results in a suboptimal
performance of the carbon trading market. Additionally, the carbon
trading market relies on carbon emission data that may be prone to
error. For example, one currently used carbon emission calculation
process utilizes a number of intermediaries between carbon
allocation buyer and seller which may lead to inaccuracies.
SUMMARY
[0003] According to an embodiment, a method includes receiving
sensor data from a first sensor unit. The method also includes
receiving weather data of a first location of the first sensor
unit. In an embodiment of the method, receiving the sensor data
includes receiving sensor data from a second sensor unit and
receiving weather data includes receiving weather data of a
location of the second sensor unit. In an embodiment, the first
sensor unit is configured to detect carbon emission from a first
source in the first location and the second sensor unit is
configured to detect carbon emission from a second source in a
second location. The method also includes converting the sensor
data into a standardized format, writing the sensor data and
weather data into a ledger, and submitting the ledger to a
distributed blockchain database. In an embodiment, the method may
also include receiving blockchain timing instructions from a user
and writing to the ledger in accordance with the blockchain timing
instructions. The method, in an embodiment, may also include
comparing the sensor data with a first threshold value. In response
to a determination that the sensor data includes a value that
exceeds the first threshold value, the method may also include,
sending a notification to the user. In an embodiment of the method,
the first threshold value is received from the user and the first
threshold value corresponds to a carbon allowance for the user. In
an embodiment, in response to the notification, the method may also
include, conducting a trade to acquire additional carbon allowance
or to sell excess carbon credits. In an embodiment, the sensor data
corresponds with an amount of carbon detected by the first sensor
unit. The method may also include, in an embodiment, receiving
forecasted weather data for the location of the first sensor unit,
predicting future sensor data based on a comparison between the
weather data, the sensor data, and the ledger.
[0004] According to another embodiment, a method includes accessing
a block of a distributed blockchain database. The block includes a
first ledger comprising sensor data and weather data for a location
of a first sensor unit. The method also includes, in response to a
determination that a value of the sensor data exceeding a first
threshold value, receiving a notification. The method also
includes, in response to receiving the notification, acquiring
additional allowances to increase a total allowance value above a
base allowance value. The method also includes writing information
corresponding to the acquired allowances into a second ledger and
submitting the second ledger to the distributed blockchain
database. In an embodiment, the first threshold value is less than
the base allowance value and the base allowance value is less than
the total allowance value. The method may also include, in an
embodiment, in response to acquiring the additional allowances, a
second threshold value is determined. The second threshold value is
less than the increased total allowance value. In an embodiment,
the method also includes, in response to a determination that the
value of the sensor data exceeding the second threshold value,
receiving a second notification, in response to receiving the
second notification, acquiring additional allowances to increase
the total allowance value, writing information corresponding to the
acquired allowances into a third ledger, and submitting the third
ledger to the distributed block chain database. In an embodiment,
the method also includes receiving future sensor data. The future
sensor data is based on a comparison between the location data, the
sensor data, and forecasted weather data.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 shows an illustrative diagram of a system that
collects and stores environmental parameter data in accordance with
various embodiments;
[0006] FIG. 2 shows an illustrative block diagram of an example
computing system for processing environmental parameters, in
accordance with various embodiments;
[0007] FIG. 3 shows a block diagram of an example block chain
database, in accordance with various embodiments;
[0008] FIG. 4 shows a flow diagram illustrating aspects of
operations that may be performed to acquire environmental emission
allowances, in accordance with various embodiments;
[0009] FIG. 5 shows a flow diagram illustrating aspects of
operations that may be performed to acquire environmental emission
allowances and submit a ledger to a block chain database, in
accordance with various embodiments; and
[0010] FIG. 6 shows an illustrative block diagram of an example
data processing system that can be applied to implement embodiments
of the present disclosure.
DETAILED DESCRIPTION
[0011] The usefulness of emission trading markets is tied to the
optimal measurement of emissions of an environmental parameter
(e.g., carbon dioxide). However, emission trading markets rely on a
system that is fragmented and disparate. Further, emissions data is
prone to error because conventional systems are based on human
estimates and calculations. For example, carbon dioxide emitters
measure their own carbon dioxide emissions, then have the measured
emission data verified by a trusted third party. The emitters then
may use the verified carbon dioxide emission data for carbon
trading using a separate trading market. Therefore, it is desirable
to develop a trusted system which automatically measures emissions
and stores emissions data in a distributed database (e.g., a
blockchain database). The stored emission data then may be utilized
for trading emission allowances. In accordance with various
examples, a system may be provided to measure environmental
parameter emissions using sensors (e.g., internet of things (IoT)
sensors) and store the emissions data in a blockchain database.
Users may utilize the stored emission data from the blockchain
database to perform emission allowance trading. In accordance with
other examples, a system may utilize the emissions data and compare
the data with past weather information from when the data was
generated to predict future emissions based on weather
forecasts.
[0012] The embodiments described herein include a plurality of
computer systems, each of which may store a blockchain database.
The computer systems may be connected to each other through a
network, thus, a distributed blockchain database is formed. The
disclosed embodiments further include a plurality of sensor units
placed at a plurality of different locations, each sensor measuring
an environmental parameter, such as carbon dioxide emissions. In an
embodiment, the environmental parameter is measured and transmitted
by the sensor unit to a computing system. The environmental
parameter data is added to the blockchain database which is
replicated by all the computer systems. Because the data stored in
a blockchain database is exceptionally difficult to alter once
committed to the blockchain, the system and methods described
herein provide a robust trail of environmental parameter data and
other related transactional records. In some embodiments, the
measured emission data may exceed a threshold value resulting in
acquiring one or more additional environmental emission
allowances.
[0013] FIG. 1 shows an illustrative diagram of a system 50 that
collects, converts, stores, analyzes, and acquires data in
accordance with various embodiments. The system 50 includes a
plurality of computer systems such as computing system 100 and
users 120A-N. The system 50 further includes a network 105 and
sensor units 110, 115 which may be placed at different geographic
locations. In an embodiment, the sensor units 110, 115 are IoT
sensors, such that the sensor units 110, 115 may be any physical
device that includes embedded electronics that allow the sensor
units 110, 115 to sense emissions at the location that the sensor
unit is located. The computing system 100 can be configured to
receive sensor data (i.e., emission data) from the sensor units
110, 115. For example, the computing system 100 may receive and
store carbon dioxide emission data sensed by sensor units 110, 115
from multiple geographic locations. More particularly, the sensor
unit 110 may sense carbon dioxide emissions at one geographic
location (e.g., a smoke stack in Pittsburgh, Pa.), while sensor
unit 115 may sense carbon dioxide emissions data at a second
geographic location (e.g., a smoke stack in Philadelphia, Pa.). The
emission data detected by sensor units 110, 115 then may be
transmitted to computing system 100, in some embodiments, through
the network 105. Thus, the sensor units 110, 115 have transmission
capabilities to enable the sensor to transmit the sensor data to
the computing system 100. Further, the computer systems (computing
system 100 and users 120A-N) may form a distributed network which
maintains and builds upon a blockchain database. For example,
computing system 100 and each of the user 120A-N may maintain a
copy of the blockchain in their respective blockchain database 102,
122, 132, and 142.
[0014] As discussed above, in some embodiments, there may be a
plurality of sensor units at a plurality of different locations
transmitting sensor data to the computing system 100. For example,
the sensor units may be placed at different locations by a trusted
third party (such as a government organization) where the sensor
units measure some data (such as carbon dioxide emission data). The
placement of the sensor units 110, 115 is illustrative and is not
intended to state or imply any limitation with regard to the type
of system with which various embodiments may be implemented. Many
modifications to the example placements of the sensor units 110,
115 and the computing system 100 may be implemented in various
embodiments.
[0015] In some embodiments, the computing system 100 may include
one or more processors and one or more memories (not shown), and/or
a distributed blockchain database 102. In some embodiments, the
computing system 100 can be a cognitive computing system that
ingests and analyzes data from multiple sources. In some
illustrative embodiments, the computing system 100 may be the IBM
Watson.TM. system available from International Business Machines
Corporation of Armonk, N.Y.
[0016] The sensor units 110, 115 may include a processor, a memory,
one or more sensors, a communication interface and a location
sensor (such as a Global Positioning System (GPS)). The sensors
(not shown) in the sensor units may measure a certain quantity of
an environmental parameter such as carbon dioxide. For example, the
sensor unit 110, 115 can be placed at a location of direct carbon
dioxide emission such as a chimney of a coal plant where the
sensors may measure carbon dioxide emission from the coal plant.
Measuring carbon dioxide emission may include: detecting and
measuring carbon dioxide emission data (in parts per million) for a
first time period using the sensors and transmitting the measured
carbon dioxide emission data to the computing system 100 through a
communication link (such as 111, 116, 101) over network 105 (for
example, the internet). The sensor unit may also calculate the
cumulative carbon dioxide emission data which may be the total
carbon emission data received in a certain time interval which may
be a longer time interval than the first time interval.
[0017] In some embodiments, the users 120A-N can be one or more
computer systems employed by emitters (such as fossil burning
plants emitting carbon dioxide, etc.). The users 120A-N may include
one or more processors and one or more memories (not shown). A
distributed blockchain database 122, 132, 142 may be stored in the
one or more memories and may include an operator. The users 120A-N
may include any other computing device elements generally known in
the art including buses, storage devices, communication interfaces,
and the like. The users 120A-N may further be equipped to analyze
the emission data received through the blockchain database. The
users 120A-N may also participate in emission allowance trading
with other users in the distributed blockchain network or through
any other network. For example, user 120A may receive a
notification related to carbon emission data exceeding a threshold
value. This threshold value may correspond or be based on the
emission allowances for a particular user. For example, the user
120A may have an allowance to emit 100 tons of carbon dioxide per
year. The user 120A may transmit to the central computer system 100
that it would like to set a threshold value of 90 tons of carbon
dioxide. Thus, if the carbon emission data for the current year
exceeds 90 tons of carbon dioxide, the central computer system 100
may generate and transmit a notification to user 120A that the
threshold value (i.e., 90 tons of carbon dioxide) has been
exceeded. This may prompt the user 120A to acquire additional
carbon allowances from another user, such as user 120B using a
carbon trading market.
[0018] As discussed above, measuring emissions may include
measuring an environmental parameter emissions (for example, in
parts per million) for any time period. In some embodiments, the
time period for which the emissions are measured can be preset or
in other embodiments, the time period can be programmable. For
example, the timing sequence can be a fixed timing waveform such
that the sensor units 110, 115 measure the environmental parameter
(e.g., carbon dioxide) when the sequence is at a higher logic and
transmit the measured emission data when the sequence is at a lower
logic. The fixed timing sequence is illustrative and is not
intended to state or imply any limitation with regard to the type
of timing sequence with which various embodiments may be
implemented
[0019] In some embodiments, the sensor units 110, 115 can be
programmed to alter the timing sequence. In some embodiments, the
timing sequence may be programmed through the communication links
111, 116. For example, the sensor units 110, 115 may be programmed
to measure the environmental parameter more frequently in an event
the sensors measure a higher than average amount of the
environmental parameter. In some embodiments, the timings sequence
can be altered by the trusted third party through the communication
interface in the sensor unit. In other embodiments, the timing
sequence may be altered by an emitter through their respective
users (i.e. users 120A-N) via a communication interface in the
sensor unit.
[0020] FIG. 2 shows an illustrative block diagram of computing
system 100, in accordance with various embodiments. The computing
system 100 may include a transceiver 200, a processor 210, and a
blockchain database 102. The processor 210 may further comprise a
converting circuit 212, a writing circuit 214, and weather
determination circuit 216.
[0021] In some embodiments, the transceiver 200 is configured to
receive data, such as sensor data through the communication link
101. For example, the transceiver 200 may receive carbon emission
data transmitted by the sensor units 110, 115. In an example
embodiment, the computing system 100 may be configured to request
and receive weather data of a geographic location of a sensor unit
through the weather determination circuit 216. For example, the
sensor unit 110 may be placed in a coal burning power plant in a
first geographic location (e.g., a coal burning plant in Texas) and
the sensor unit 115 may be placed in another fossil fuel power
plant located in a second geographic location (e.g., a smoke stack
in Colorado). The weather determination circuit 216 may request
weather data of each of the first and second location through a
trusted third party weather server (such as a commercial weather
service, government weather service etc.) and/or receive direct
weather reports from the sensor units 110, 115 which, in some
embodiments, may, in addition to sensing emissions, may sense
weather data as well. In some embodiments, the weather
determination circuit 216 may request the weather data at a fixed
rate (for example, every hour or every day) or at a programmable
rate.
[0022] Upon receiving the environmental parameter data from the
sensor units 110, 115, a converting circuit 212 may process and
convert the data into a standardized form by performing a
mathematical function on the received data. For example, carbon
emission data may be measured in parts per million by the sensor
unit 110 and may be converted to a standardized form of metric ton
per year. This transformation may require the converting circuit
212 to apply the mathematical function to the received emission
data resulting in converted emission data.
[0023] Following the conversion to the standardized form and
receiving weather data of each location of the sensor units, the
writing circuit 214 may write the environmental parameter data and
the weather data into a ledger to be incorporated into a blockchain
which is stored in blockchain databases 102, 122, 132, 142. The
writing circuit 214 may also write transactional data records
related to emission allowance values and data related to a request
for additional emission allowance in the ledger. The emission
allowance value may be the allowed emissions per unit of time (e.g.
year) for a specific emitter. The emission allowance value can be
transmitted to the computing system 100 by the user 120A-N
associated with the specific emission allowance value. For example,
the emission allowance value for carbon emissions for user 120A may
be provided by user 120A. In other embodiments, the emission
allowance value can be preset by a trusted third party (such as an
environmental protection agency, government, etc.). The writing
circuit 214 may also write into the ledger cumulative converted
emission data which may be the total converted environmental
parameter emission data received for each user 120A-N.
[0024] The writing process may be instantaneous or may occur with a
writing timing sequence. For example, for the instantaneous writing
process, the emission data and the weather data may be written into
the ledger instantaneously or immediately following the conversion.
In other embodiments, converted emission data may be stored in
memory (not shown) and written into the ledger as directed by a
writing timing sequence. For example, the writing timing sequence
may have a writing period and a non-writing period. During the
writing period the writing circuit 214 may be directed to write
converted emission data and the collected weather data into the
ledger, and during the non-writing period, the writing circuit 214
may not write data into the ledger. The writing timing sequence of
the writing circuit 214 is illustrative and is not intended to
state or imply any limitation with regard to the type of system
with which various embodiments may be implemented. Many
modifications to the example writing timing sequence of the writing
circuit 214 may be implemented in various embodiments.
[0025] The ledger may be submitted to the distributed blockchain
database (102, 122, 132, 142) following writing data into the
ledger. For example, the distributed blockchain database may
receive a submit request and the central computer systems scoring
the distributed blockchain database (such as 100, 120, 130, 140)
initiate attempts to mine or unlock a new block in the block chain.
The computer system that successfully mines a new block attaches
the ledger in the new block and propagates the new block to the
distributed blockchain network. Therefore, all the central computer
systems (such as 100, 120, 130, and 140) scoring the distributed
blockchain database 102, 122, 132, and 142 receive a copy of the
ledger. As discussed above, the ledger may include transactional
data, emission data from each sensor unit 110, 115, weather data
from each location of the sensor units 110, 115, and may also
contain the cumulative emission data for each user 120A-N.
[0026] FIG. 3 shows a block diagram of an example blockchain
database (such as 102, 122, 132, 142), in accordance with various
embodiments. FIG. 3 shows an illustrative architecture of
blockchain database 102, although the architecture can apply to any
other or all of the other blockchain databases disclosed herein.
Blockchain database 102 may include one or more blocks, blocks
300A-N as indicated by the ellipses. In each block, a ledger
containing converted emission data, weather data, cumulative
converted emission data, environmental emission allowance values
and other transactional records are stored. For example, ledger
310, which comprises sensor data 305 (e.g., converted emission
data), weather data 307, and transactional data 309 is stored in
the block 300A. Similarly, ledger 330 comprises sensor data 335
(e.g., converted carbon data), weather data 337, and transactional
data 339 which is stored in the block 300N. Therefore, each of
blocks 300A-N is a group of ledgers containing records. In some
embodiments, each block is chained or contains information that
relates it to the previous block in the blockchain database.
[0027] Each of central computer systems 100, 120, 130, 140 from
FIG. 1 may be configured to add a block, such as block 300A, to the
distributed blockchain database 102, 122, 132, 142. In this
example, block 300A already exists in the blockchain database 102.
Mining or adding a block is the process of adding additional
blocks, such as block 300N to the distributed blockchain database
102, 122, 132, 142. In order to successfully mine the block 300N,
one of central computer systems 100, 120, 130, 140, or any other
computing system associated with the blockchain network, may solve
an arbitrary problem and provide its solution to the remaining
computer systems in the network. In some embodiments, the arbitrary
problem requires one of central computer systems 100, 120, 130,
140, or any other computing system associated with the blockchain
network, to determine an arbitrary value, such that when hashed,
the block content along with the arbitrary value is added to the
blockchain.
[0028] FIG. 4 shows a flow diagram illustrating aspects of
operations that may be performed to acquire additional
environmental emission allowance in accordance with various
embodiments. Though depicted sequentially as a matter of
convenience, at least some of the actions shown can be performed in
a different order and/or performed in parallel. Additionally, some
embodiments may perform only some of the actions shown. In some
embodiments, at least some of the operations of the method 400 may
be provided by instructions executed by the computing system
100.
[0029] The method 400 begins in block 405 with receiving sensor
data from a first sensor unit. For example, the sensor data may
comprise any type of environmental parameter emission data (e.g.,
carbon dioxide emission data) measured by the first sensor unit 110
at a first location (i.e., the location of the sensor unit 110). In
block 410, the method 400 continues with receiving weather data of
the first location. For example, the weather determination circuit
216 may request weather data of a first geographic location (e.g.,
Pittsburgh) of the sensor unit 110 through a trusted third party
weather server (e.g. government weather database). In another
example, the sensor unit 110 may sense the weather conditions and
transmit the sensed weather conditions as data to the central
computer system 100.
[0030] The method 400 continues in block 415 with converting the
sensor data into a standardized format. For example, the received
emission data may be different than a standardized unit based on a
consensus of different parties. In an example embodiment, the
received emission data may be in parts per million whereas the
consensus unit for the emission data may be metric tons per year.
Therefore, to maintain a uniform system of engagement, the emission
data is converted into the standardized format (in this case,
metric tons per year). Following the conversion process, the
converted emission data may be stored in a local memory of the
computing system 100 where the computing system 100 may also count
and register a cumulative converted carbon data in the local
memory.
[0031] The method 400 further continues in block 420 with writing
the sensor data and writing weather data of the location of the
sensor unit into a ledger. In some embodiments, the block 420 may
also write environmental emission allowance data, cumulative
converted emission data, and transactional records related to the
emission allowance into the ledger.
[0032] The writing may be instantaneous or occur in accordance with
a writing timing sequence. For example, the instantaneous writing
sequence may direct the converted emission data, the weather data,
and the cumulative converted emission data to be written into the
ledger instantaneously following the conversion. In some
embodiments, the converted emission data may be first stored in
memory and then written into a ledger as directed by a writing
timing sequence. The writing timing sequence may have a writing
period and a non-writing period, where during the writing period
the writing circuit 214 may be directed to write the converted
emission data and weather data into the ledger and during the
non-writing period, the writing circuit 214 may not write any data
into the ledger.
[0033] The method 400 continues in block 430 with comparing the
cumulative converted emission data with a first threshold value.
The method 400 further continues in block 435 where a determination
is made as to whether the cumulative converted emission data
exceeds the first threshold value. For example, over time, with
continuous carbon dioxide emission, the received carbon emission
data adds up and the cumulative converted carbon dioxide emission
data may reach 90% of the allowance value. In some embodiments, the
first threshold value may be preset by a user (such as one or more
of users 120A-N). As describe above, the emission allowance value
set for each of the emitters may be received by the central
computer system 100 through a trusted third party (such as
environmental protection agency etc.).
[0034] Once the cumulative converted emission data exceeds the
first threshold, the computing system 100 notifies the
corresponding user as described in block 440. In this example, the
first threshold value is 90% of the carbon dioxide emission
allowance value. Therefore, once the cumulative converted carbon
dioxide emission data shows that 90% of the carbon dioxide emission
allowance has been reached, the computing system 100 may generate
and transmit the notification to the corresponding user.
[0035] In block 445, the method 400 continues with comparing
forecasted weather data with the converted emission data determined
in block 415 and the weather data determined in block 410 of the
first location. For example, the processor 210 may gather the
forecasted weather data through a trusted weather server and
compare it to historically collected emissions data and the
corresponding weather data. In block 450, the method 400 continues
with predicting a future data trend. For example, using a computer
program on such a large data set may provide insights over future
trends in the emission data based on the weather. For example, if
the temperature is 20 degrees Celsius (C) for one hour and the
emission data shows 0.1 ton of carbon dioxide is emitted during
that one hour, then the system may predict that whenever the
temperature is 20 degrees C., the emissions rate will be 0.1 tons
per hour. Therefore, if the forecasted weather shows 20 degrees C.
for tomorrow for 6 hours, then the processor 210 may determine that
for those 6 hours, 0.6 tons of carbon dioxide will be emitted.
[0036] The method 400 continues in block 455 with writing the
predicted future trend of the emission data into a ledger which may
be submitted to the distributed blockchain 425. After successfully
mining a new block, the miner attaches the ledger in the new block
and propagates the new block to the distributed blockchain network.
Therefore, all the central computer systems 100, 120, 130, and 140
storing the distributed blockchain database 102, 122, 132, and 142
receive a copy of the ledger which may contain the sensed emission
data, the weather data, and/or the predicted future trend of the
emission data.
[0037] The method 400 continues 460 in determining if the user
wants to conduct a trade. As described above, the predicted future
trend of the emission data propagates to all the computer systems
which may include the users 120A-N. For example, user 120A may
receive the future trend of the emission data and may utilize this
data to make the decision to trade. For example, the user 120A may
determine that based on the future emission data, the user's
emission allowances will be exceeded shortly; therefore, the user
120A may trade for additional emission allowances prior to
exceeding the allowance. Thus, the trade may include a request to
buy additional emission allowances. In block 465, the method 400
continues with conducting the trade. For example, user 120A may
conduct the trade with user 120B and obtain the additional emission
allowances.
[0038] FIG. 5 shows a flow diagram illustrating aspects of
operations that may be performed to acquire additional emission
allowances and to submit a ledger to the distributed blockchain in
accordance with various embodiments. Though depicted sequentially
as a matter of convenience, at least some of the actions shown can
be performed in a different order and/or performed in parallel.
Additionally, some embodiments may perform only some of the actions
shown. In some embodiments, at least some of the operations of the
method 500 may be provided by instructions executed by computing
systems 120, 130, 140.
[0039] The method 500 starts in block 505 with accessing a newest
block from the distributed blockchain database. The newest block
may include a ledger containing converted emission data, weather
data, cumulative converted emission data, forecasted weather data,
and/or a predicted future trend of the emission data. The method
500 continues in block 510 with determining if the cumulative
converted emission data exceeds a first threshold value. The first
threshold value may be user specific. For example, user 120A may
have the first threshold preset at 90% of its emission allowance
value. Similarly, user 120B may have a first threshold value set at
60% of its emission allowance value. Thus, in block 515, if the
cumulative converted emission data exceeds the first threshold
value for any of the particular users, a notification may be
received by the corresponding user. For example, after accessing
the newest block from the distributed blockchain database, user
120A may receive a notification, in some embodiments in the ledger
of the newest block, if the cumulative converted emission data
exceeds the first threshold value.
[0040] The method 500 continues in block 517 with determining if
the user wants to conduct a trade. For example, user 120A may
analyze the predicted future emission data to determine if the user
120A needs to acquire additional emission allowance. The method 500
continues in block 520 with acquiring additional allowances in
response to the result of the determination of block 517. For
example, user 120A may acquire additional allowance thereby
increasing the total emission allowance for that user. The user
120A may further write (as shown in block 525) the additionally
acquired allowance data and/or the total allowance data in a new
ledger and submit (as shown in block 530) a transaction showing the
acquired allowances and/or the total allowances to the distributed
blockchain database. After successfully mining a new block, the
miner may attach the new ledger in the new block and propagate the
new block to the distributed blockchain network. Therefore, all the
central computer systems 100, 120, 130, and 140 of the distributed
blockchain database receive a copy of the ledger.
[0041] The method 500 further continues in block 535 with a user
120A determining a second threshold value and further in block 540
determines if the cumulative converted emission data exceeds the
second threshold value.
[0042] FIG. 6 is a block diagram of an example data processing
system in which aspects of the illustrative embodiments may be
implemented. Data processing system 600 is an example of a computer
that can be applied to implement the computing system 100 or any of
the user systems 120A-N in FIG. 1 and FIG. 2, in which computer
usable code or instructions implementing the processes for
illustrative embodiments of the present invention may be located.
In one illustrative embodiment, FIG. 6 represents a computing
device that implements the computing system 100 augmented to
include the additional mechanisms of the illustrative embodiments
described hereafter.
[0043] In the depicted example, data processing system 600 employs
a hub architecture including north bridge and memory controller hub
(NB/MCH) 606 and south bridge and input/output (I/O) controller hub
(SB/ICH) 610. Processor(s) 602, main memory 604, and graphics
processor 608 are connected to NB/MCH 606. Graphics processor 608
may be connected to NB/MCH 606 through an accelerated graphics port
(AGP).
[0044] In the depicted example, local area network (LAN) adapter
616 connects to SB/ICH 610. Audio adapter 630, keyboard and mouse
adapter 622, modem 624, read only memory (ROM) 626, hard disk drive
(HDD) 612, compact disk read-only memory (CD-ROM) drive 614,
universal serial bus (USB) ports and other communication ports 618,
and peripheral component interconnect/peripheral component
interconnect express (PCI/PCIe) devices 620 connect to SB/ICH 610
through bus 632 and bus 634. PCI/PCIe devices may include, for
example, Ethernet adapters, add-in cards, and personal computer
(PC) cards for notebook computers. PCI uses a card bus controller,
while PCIe does not. ROM 626 may be, for example, a flash basic
input/output system (BIOS).
[0045] HDD 612 and CD-ROM drive 614 connect to SB/ICH 610 through
bus 634. HDD 612 and CD-ROM drive 614 may use, for example, an
integrated drive electronics (IDE) or serial advanced technology
attachment (SATA) interface. Super I/O (SIO) device 628 may be
connected to SB/ICH 610.
[0046] An operating system runs on processor(s) 602. The operating
system coordinates and provides control of various components
within the data processing system 600 in FIG. 6. In some
embodiments, the operating system may be a commercially available
operating system such as Microsoft.RTM. Windows 10.RTM.. An
object-oriented programming system, such as the Java.TM.
programming system, may run in conjunction with the operating
system and provides calls to the operating system from Java.TM.
programs or applications executing on data processing system
600.
[0047] In some embodiments, data processing system 600 may be, for
example, an IBM.RTM. eServer.TM. System p.RTM. computer system,
running the Advanced Interactive Executive (AIX.RTM.) operating
system or the LINUX.RTM. operating system. Data processing system
600 may be a symmetric multiprocessor (SMP) system including a
plurality of processors 602. Alternatively, a single processor
system may be employed.
[0048] Instructions for the operating system, the object-oriented
programming system, and applications or programs are located on
storage devices, such as HDD 612, and may be loaded into main
memory 604 for execution by processor(s) 602. The processes for
illustrative embodiments of the present invention may be performed
by processor(s) 602 using computer usable program code, which may
be located in a memory such as, for example, main memory 604, ROM
626, or in one or more peripheral devices 612 and 614, for
example.
[0049] A bus system, such as bus 632 or bus 634 as shown in FIG. 6,
may include one or more buses. The bus system may be implemented
using any type of communication fabric or architecture that
provides for a transfer of data between different components or
devices attached to the fabric or architecture. A communication
unit, such as modem 624 or LAN adapter 616 of FIG. 6, may include
one or more devices used to transmit and receive data. A memory may
be, for example, main memory 604, ROM 626, or a cache such as found
in NB/MCH 606 in FIG. 6.
[0050] The present invention may be a system, a method, and/or a
computer program product at any possible technical detail level of
integration. The computer program product may include a computer
readable storage medium (or media) having computer readable program
instructions thereon for causing a processor to carry out aspects
of the present invention.
[0051] The computer readable storage medium can be a tangible
device that can retain and store instructions for use by an
instruction execution device. The computer readable storage medium
may be, for example, but is not limited to, an electronic storage
device, a magnetic storage device, an optical storage device, an
electromagnetic storage device, a semiconductor storage device, or
any suitable combination of the foregoing. A non-exhaustive list of
more specific examples of the computer readable storage medium
includes the following: a portable computer diskette, a hard disk,
a random access memory (RAM), a read-only memory (ROM), an erasable
programmable read-only memory (EPROM or Flash memory), a static
random access memory (SRAM), a portable compact disc read-only
memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a
floppy disk, a mechanically encoded device such as punch-cards or
raised structures in a groove having instructions recorded thereon,
and any suitable combination of the foregoing. A computer readable
storage medium, as used herein, is not to be construed as being
transitory signals per se, such as radio waves or other freely
propagating electromagnetic waves, electromagnetic waves
propagating through a waveguide or other transmission media (e.g.,
light pulses passing through a fiber-optic cable), or electrical
signals transmitted through a wire.
[0052] Computer readable program instructions described herein can
be downloaded to respective computing/processing devices from a
computer readable storage medium or to an external computer or
eternal storage device via a network, for example, the Internet, a
local area network, a wide area network and/or a wireless network.
The network may comprise copper transmission cables, optical
transmission fibers, wireless transmission, routers, firewalls,
switches, gateway computers and/or edge servers. A network adapter
card or network interface in each computing/processing device
receives computer readable program instructions from the network
and forwards the computer readable program instructions for storage
in a computer readable storage medium within the respective
computing/processing device.
[0053] Computer readable program instructions for carrying out
operations of the present invention may be assembler instructions,
instruction-set architecture (ISA) instructions, machine
instructions, machine dependent instructions, microcode, firmware
instructions, state-setting data, configuration data for integrated
circuitry, or either source code or object code written in any
combination of one or more programming languages, including an
object oriented programming language such as Smalltalk, C++, or the
like, and procedural programming languages, such as the "C"
programming language or similar programming languages. The computer
readable program instructions may execute entirely on the user's
computer, partly on the user's computer, as a stand-alone software
package, partly on the user's computer and partly on a remote
computer or entirely on the remote computer or server. In the
latter scenario, the remote computer may be connected to the user's
computer through any type of network, including a local area
network (LAN) or a wide area network (WAN), or the connection may
be made to an external computer (for example, through the Internet
using an Internet Service Provider). In some embodiments,
electronic circuitry including, for example, programmable logic
circuitry, field-programmable gate arrays (FPGA), or programmable
logic arrays (PLA) may execute the computer readable program
instructions by utilizing state information of the computer
readable program instructions to personalize the electronic
circuitry, in order to perform aspects of the present
invention.
[0054] Aspects of the present invention are described herein with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems), and computer program products
according to embodiments of the invention. It will be understood
that each block of the flowchart illustrations and/or block
diagrams, and combinations of blocks in the flowchart illustrations
and/or block diagrams, can be implemented by computer readable
program instructions.
[0055] These computer readable program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to
produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or blocks.
These computer readable program instructions may also be stored in
a computer readable storage medium that can direct a computer, a
programmable data processing apparatus, and/or other devices to
function in a particular manner, such that the computer readable
storage medium having instructions stored therein comprises an
article of manufacture including instructions which implement
aspects of the function/act specified in the flowchart and/or block
diagram block or blocks.
[0056] The computer readable program instructions may also be
loaded onto a computer, other programmable data processing
apparatus, or other device to cause a series of operational steps
to be performed on the computer, other programmable apparatus or
other device to produce a computer implemented process, such that
the instructions which execute on the computer, other programmable
apparatus, or other device implement the functions/acts specified
in the flowchart and/or block diagram block or blocks.
[0057] The flowchart and block diagrams in the Figures illustrate
the architecture, functionality, and operation of possible
implementations of systems, methods, and computer program products
according to various embodiments of the present invention. In this
regard, each block in the flowchart or block diagrams may represent
a module, segment, or portion of instructions, which comprises one
or more executable instructions for implementing the specified
logical function(s). In some alternative implementations, the
functions noted in the blocks may occur out of the order noted in
the Figures. For example, two blocks shown in succession may, in
fact, be executed substantially concurrently, or the blocks may
sometimes be executed in the reverse order, depending upon the
functionality involved. It will also be noted that each block of
the block diagrams and/or flowchart illustration, and combinations
of blocks in the block diagrams and/or flowchart illustration, can
be implemented by special purpose hardware-based systems that
perform the specified functions or acts or carry out combinations
of special purpose hardware and computer instructions.
[0058] The descriptions of the various embodiments of the present
invention have been presented for purposes of illustration, but are
not intended to be exhaustive or limited to the embodiments
disclosed. Many modifications and variations will be apparent to
those of ordinary skill in the art without departing from the scope
and spirit of the described embodiments. The terminology used
herein was chosen to best explain the principles of the
embodiments, the practical application or technical improvement
over technologies found in the marketplace, or to enable others of
ordinary skill in the art to understand the embodiments disclosed
herein.
* * * * *