KR20190124938A - Decentralized peer to peer ride share system - Google Patents

Abstract

The present invention relates to a decentralized P2P rideshare system. According to an embodiment of the present invention, the decentralized P2P rideshare system includes: a portable passenger device requesting a ride to use a rideshare service; a portable driver device selecting the ride requested by the portable passenger device to provide the rideshare service; and a blockchain technology or tangle technology-based network creating a smart contract on the ride requested by the portable passenger device, and posting the smart contract so that the contract can be selected through the portable driver device. According to the present invention, since a central management system included in the decentralized rideshare system requires a minimum amount of expense for management by functioning only for technical management and update, there is no extra broker or agency incurring brokerage charges, so profits for drivers can be increased.

Description

Decentralized P2P Rideshare System {DECENTRALIZED PEER TO PEER RIDE SHARE SYSTEM}

The present invention relates to a decentralized P2P rideshare system, and more particularly, to a decentralized P2P rideshare system that is not centrally managed.

As transportation develops, many people need more transportation. Apart from public transportation such as taxis and buses, the share of ride-sharing services is increasing rather than using taxi services, which are rather expensive. These rideshare services are offered by companies such as Uber, Lift, Gett, Juno, Curb, Sitbaq, Via, Summon, Bridj, Arro, and Flywheel.

The rideshare service has a lower cost than public transportation such as a taxi, and has the advantage of using a community rideshare service in which several people can share the same vehicle. In addition, you can make a reservation based on an app such as a smartphone, not based on an existing phone, use a bus such as a minivan, and use a door-to-door that can completely replace the existing taxi service. door to door) can provide services.

As such, the conventional rideshare service provides a unique service by various companies, but has a common structure.

First, the driver is serviced as an independent individual, not the company's job. That is, unlike conventional taxis or other public transportation, the driver is an independent individual registered as a driver service in each company's service and provides the service as a commissioned third party or an independent contractor.

Once registered, the driver may provide services by logging in to the system at a desired time zone, rather than providing a service during a specific time zone. As a result, the driver can work as much as he / she wants or needs, even if he or she is on the rideshare. In addition, the driver may generate additional revenue at a convenient time as a side job even if there is a separate main business.

In addition, conventional rideshare companies have a centralized system structure. Centralized systems mean that the rideshare system is managed by a broker or central management corporation (CMC).

These brokers and brokers are responsible for managing or updating the rideshare system to operate efficiently without disruption, and for managing and controlling personal information about drivers and passengers in key locations. It also designs the principles and conditions of the rideshare system and regulates and oversees all financial transactions, including payment systems. It also monitors the smooth execution of the principles and conditions of the rideshare system and resolves disputes between the driver and passengers.

Here, importantly, trust plays an important role in brokers and brokers, who act as trusted mediators of drivers and passengers.

In this way, brokers and intermediaries, the most important role of a centralized system, should play a role of promoting trust, and passengers are provided with services for the amount paid and drivers pay the fees for services provided. Play the role that can be received.

That is, in order to give the driver and passenger confidence or confidence in a transaction between two strangers, the broker or broker keeps the fare prepaid by the passenger, confirms that the passenger has arrived at the destination, and then pays the driver. That is, the passenger trusts the broker or broker to keep the money paid until he arrives at the promised destination, the driver transports the passenger to the promised destination, and then the broker or broker will pay the negotiated amount. I trust that.

However, as described above, in the centralized rideshare service, it is important for the broker or broker to inspire trust in the rideshare system, but there are various disadvantages. First, if a broker or broker charges a low fee for transportation while requesting a high fee from the driver, the driver's profits will be reduced, resulting in a lower service level for the driver.

And the rules and conditions of the rideshare system are set in favor of the broker or broker, not the driver. In addition, it is difficult for the driver to provide additional services according to the strict compliance of the broker or broker, and the driver has to pay a fee periodically, not immediately after the service is provided by the broker or the broker.

Republic of Korea Patent Publication No. 10-2016-0065956 (2016.06.09)

The problem to be solved by the present invention is to provide a decentralized rideshare system that can overcome the various disadvantages of the conventional centralized rideshare system.

A decentralized P2P rideshare system according to an embodiment of the present invention includes a passenger portable device requesting a ride to use a rideshare service; A driver mobile device that selects a ride requested by the passenger mobile device to provide the rideshare service; And a network to which a blockchain technology or a tangle technology is applied, which generates a smart contract for a ride requested by the passenger mobile device and publishes the generated smart contract to be selected through the driver mobile device. can do.

In this case, the network may generate a passenger electronic wallet so that the ride fee can be paid by the passenger portable device and a driver electronic wallet so that the ride fee can be paid by the driver mobile device.

The passenger portable device may deposit a reservation fee into the smart contract to request a ride to use the rideshare service, and the smart contract may store the deposited reservation fee.

Here, if the rideshare service is not normally concluded at the fault of the passenger while the passenger uses the rideshare service, the reservation fee may be paid by the driver electronic wallet.

The driver portable device may deposit a reservation fee to the smart contract to provide the rideshare service, and the smart contract may store the deposit reservation fee.

In this case, if the rideshare service is not concluded normally at the fault of the driver while the driver provides the rideshare service, the reservation fee may be paid by the passenger electronic wallet.

The passenger mobile device and the driver mobile device each include a GPS system, and the controller for controlling the network uses the GPS information of the passenger mobile device and the driver mobile device to board the boarding information and move the vehicle to the passenger's driver. One or more of distance information and getting off information can be checked.

Here, when the controller does not check the GPS information in any one of the passenger portable device and the driver portable device, the cross-interaction security using the communication function or the photographing function included in the passenger portable device and the driver portable device, respectively. Through code authentication, one or more of boarding information, moving distance information, and getting off information of the passenger may be checked.

Here, the controller for controlling the network checks the state of the battery of the passenger portable device and the driver portable device, and if the battery status of the passenger portable device and the driver portable device corresponds to a specific condition, the passenger carry The device and driver can display a manually inputable interface on the mobile device.

According to the present invention, since the central management system included in the decentralized rideshare system requires only a minimum operating cost because it performs only a technical operation and update role, there is no separate broker or broker, so there is no broker or broker No fee is incurred, which can increase the driver's profit.

In addition, in a decentralized rideshare system, drivers are completely independent, so they can provide creative services to improve their service quality, and decide on the fare system to provide more valuable services to passengers. It can be effective.

And since drivers do not have brokers or brokers, they do not have to pay the fees on a regular basis.

In addition, all transactions can be carried out in the cryptocurrency through the blockchain or tank network or by converting the cryptocurrency into a credit currency through another exchange gateway, thereby increasing the stability of the transaction.

1 is a view illustrating a tank network in a decentralized P2P rideshare system according to an embodiment of the present invention.
2 to 6 are views for explaining the flow of the de-centralized P2P rideshare system according to an embodiment of the present invention.

Preferred embodiments of the present invention will be described in more detail with reference to the accompanying drawings.

1 is a view illustrating a tank network in a decentralized P2P rideshare system according to an embodiment of the present invention.

The decentralized P2P rideshare system according to an embodiment of the present invention uses a distributed ledger technology used in a blockchain or tangle. Accordingly, the decentralized P2P rideshare system according to the present embodiment may operate in compliance with a contract with only a driver and a passenger, without an agent or an intermediary. For this purpose, the decentralized P2P rideshare system includes a smart contract (40).

The smart contract 40 allows drivers and passengers to use a decentralized P2P rideshare system with confidence. The smart contract 40 digitally signs and verifies the contract between the driver and the passenger. And it can be a computer protocol that enforces consultations or outcomes. As such, the smart contract 40 enables reliable transactions without the involvement of third parties.

This smart contract 40 transfers a single asset or currency to the program, the program executes the code to automatically approve the constraints, and whether the asset is transferred to the contractor or refunded to the sender. Decide At the same time, the blockchain distributed ledger can store and duplicate the document to apply a certain level of security and immutability.

In this embodiment, the smart contract 40 keeps the fare to be paid by the passenger in the smart contract 40 in a trust payment format similar to an escrow service so that no double payment occurs. The smart contract 40 keeps the fare on behalf of the driver until the passenger arrives at the destination, and pays the fare to the driver when the passenger arrives at the destination. At this time, if the passenger does not arrive to the specified destination, the smart contract 40 is canceled, the fare associated with the smart contract 40 is refunded to the passenger.

Blockchain technology uses a distributed ledger. Distributed ledger technology (DLT) is a technology in which each node (individual) in a distributed network shares a database and keeps it synchronized without control of a central server or a central administrator.

Blockchain technology is a shared distributed database technology through consensus, and blockchain constitutes a unit of time as a sequence of blocks in the framework of distributed ledger. One block contains data, and a block function is formed using a hash function to form a chain. The blockchain thus constructed is a single ledger, which is replicated and shared to distributed nodes without a central authority or administrator, so that everyone manages (records, stores and forwards) and synchronizes the authenticity.

In this distributed environment, P2P network is realized, and each node (individual) broadcasts a series of processes to send and receive data in a block, so that verification nodes (miner to PoW and validator to PoS) Through consensus, it establishes an architecture that chains sequentially by validating the authenticity of data and verifying its integrity with the system.

In this case, the data included in the block may include not only transaction details but also all existing data. Therefore, the blockchain technology can be extended to the smart contract 40 and numerous applications.

The type of blockchain technology can vary depending on differences in consensus, participation, data verification and data viewing rights.

And the data recorded in the blockchain is usually irreversibly recorded, and the data cannot be modified arbitrarily without a lot of consent or agreement. The data recorded in the blockchain is open to all participants, and in the case of transaction data, even transaction details and balances can be disclosed.

Participants using the blockchain participate anonymously by default, and all data management can be done anonymously. In the blockchain, data is verified for consistency and integrity through distributed multiple consensus, which can make it difficult to process data in real time.

Also, in the present embodiment, a tangle can be used, which is a technology used for IOTA among cryptocurrencies. Tangle uses DAG (directed acyclic graph) protocol. It aims to improve system design and automated payment between things (M2M) for the IoT area by improving structure, speed, determinism, and fees, which are disadvantages of blockchain.

This IOTA mechanism is in a white paper, which develops a mathematical approach rather than a concrete protocol implementation.

Tangle technology is to solve the problem that various conflicts can be caused by the blockchain distinguishing a user requesting a transaction from a user who approves a transaction (ex. Mimer). It is a system that requests and approves. In other words, in tangle technology, a user must approve two "previous transactions that have not yet been approved," "tip," to request a new transaction. As a result, the miner does not need a miner and does not incur any commission because the miner plays the role of the miner.

In tangle technology, transactions are not just approved, but in cryptocurrencies like Bitcoin, they perform similar operations (hashcash-lite), such as hashcash, which is performed when miners approve a transaction. This is to prevent spam or civil attack when there is no fee. The hashcash-lite in tangle technology finds a nonce that has a particular form in which the transaction history and nonce hash value to approve are accepted. It checks that the two transactions do not conflict with the previous transaction and adds a new one if there is no problem.

Referring to FIG. 1, the tangle network elapses from left to right. That is, each box is a 'tip', and the rightmost gray and yellow boxes are unapproved transactions that have recently entered the tangle network. As each transaction approves previous transactions, an arrow marks the object of approval. The user must approve two past transactions to add a new transaction. For example, a transaction z is approved by v and t, which is called direct approval, and because a transaction z does not approve o transactions directly, but indirectly through v, it is called indirect approval.

And a transaction is a Genesis transaction. Initially occurring transaction, it is approved either directly or indirectly by all transactions. The Genesis transaction also holds all the IOTA tokens for the first time and is then sent to a different founder address.

The blue box is not yet approved by all tips, so it is hard to see the confirmation, and these transactions can be confirmed by new tips over time. And the green box shows that it is approved by all the tips.

A gray box is a tip that has not yet been approved, and can change to a blue box as new tips come up over time.

IOTA users can set and approve their own approvals, and transactions with large amounts can be set to high approvals and vice versa. The degree of acceptance may be measured through a markov chain monte carlo (MCMC) algorithm that performs a tip selection algorithm. If all transactions follow the tip selection algorithm, how many times the tip selection algorithm is executed, and how many times the indirect approval from the tip is granted, can be weighed.

For example, applying 10 tip selection algorithms, if approved 8 times, can be considered 80% approved. And conflicting transactions are resolved through the tip selection algorithm. Only one of the two conflicting deals survives and the other is discarded.

Each transaction can be marked with a number, which is an indicator of the weight of the transaction. In this case, two numbers may be displayed in each box, and the smaller number represents the own weight of the transaction, and the larger number represents the cumulative weight. The weight can be proportional to the amount of work invested when requesting a transaction.

Cumulative weight is expressed as the sum of the intrinsic weight of the transaction and the intrinsic weight of the transactions that approve the weight. In one example, the cumulative weight of D is 1 (D) +1 (A) +3 (B) +1 (C) = 6. As a result, when a new tip is added, the cumulative weight of the transactions that the tip is approved directly or indirectly may increase by the weight of the tip, with the cumulative weight indicating the cumulative approval of the transaction and the confirmation rate. Can be represented. In addition, weight can be a factor in maintaining network security such as tip approval by applying MCMC algorithm for attack.

In tangle technology, you can create off-chain tangles (flash channels) like Bitcoin's lightning network or Ethereum's raiden. As a result, it is possible to process large transactions through channels without having to post transactions in the main tangle. This is because offline environments in M2M networks are essential for secure data management (recording, storage and delivery) and must be able to interoperate between IoT networks that are subject to dissimilar protocols.

Tangle technology uses a Layer 2 data transfer protocol module called MAN (masked authenticated messaging). MAN is a feature that encrypts and transmits data streams, making it suitable for industries that require data integrity and privacy.

This tangle technology allows participants with channel IDs to access encrypted data. In MAN, public mode, private mode and restricted mode can be used to control visibility and access. In this case, the public mode may publicly announce in an individual or a device based on data integrity and immutablity. Private mode can be used in devices that communicate privately with each other. Restricted mode can control access rights of participants by adding an authentication key to private mode.

MAN encrypts and transmits messages, but does not encrypt and transmit IOTA tokens. IOTA adds encryption to token transfers to improve privacy, improving IOTA's anonymity and fungibility. A mixer can be used for this purpose, and the mixer is a function that can not be tracked in the process of sending and receiving tokens.

Tangle technology as described above, there is no transaction fee, M2M payment between the Internet of Things, it is possible to do business that enables nano payment. Unlike the current blockchain technology, parallel processing of data is possible, and as the number of network participants increases, the throughput increases and the speed increases. In addition, the more network participants, the more verifiers, so the network stability increases.

2 to 6 are views for explaining the flow of the de-centralized P2P rideshare system according to an embodiment of the present invention.

2 to 6 are flowcharts illustrating the flow of the decentralized P2P rideshare system according to the present embodiment.

First, referring to FIG. 2, the passenger turns on the passenger portable device 30. At this time, in the present embodiment, the passenger portable device 30 may be a smartphone, a tablet PC or a laptop, etc. capable of making an Internet connection with the GPS system. The passenger handheld device 30, in this embodiment, requires an internet connection to connect to the blockchain or tank network.

The GPS system of the passenger portable device 30 is then turned on. In this case, the passenger portable device 30 may log on to the blockchain / tangle network 10 through a mobile ride sharing program (decentralized application).

The passenger logs into the system using the passenger mobile device 30 to use the decentralized P2P rideshare system.

At this time, if the passenger is not registered in the decentralized P2P rideshare system (No), the registration process may proceed. At this time, the passenger provides one or more of the passenger's photo information, detailed contact information and ID information to the decentralized P2P rideshare system. In this embodiment, the decentralized P2P rideshare system can establish a secure digital identity online including a driver's license online to use blockchain technology, and can be used securely and immediately in multiple services like other mobility services. Can be. The decentralized P2P rideshare system reveals only part of the identity card, while the rest of the information can be encrypted on the blockchain to protect passenger privacy.

The passenger applies to create a passenger wallet 20 to use the decentralized P2P rideshare system. Here, the passenger wallet 20 is used to pay a fee of the rideshare system, receive a refund, and register and use the rideshare system. The passenger wallet 20 may be a rideshare cryptocurrency wallet.

And the application can be made by submitting the contact and ID information to the controller of the blockchain / tangle network 10, the blockchain / tangle network (10) controller is the actual contact number of the contact submitted by the passenger for the safety of passengers and drivers It may be checked to see if it is.

To this end, the blockchain / tangle network 10 controller transmits an authentication code to the passenger portable device 30, and the passenger goes through the process of resubmitting the authentication code to the blockchain / tankle network controller to confirm the contact information. Then, the blockchain / tankle network controller checks whether the authentication code is normal and issues a passenger wallet 20 (PX wallet) to the passenger portable device 30.

The passenger wallet 20 may be connected to the smart contract 40 generator of the rideshare system, and the payment and refund of the ride fee may be automatically performed as the smart contract 40 generator is connected to the smart wallet 40 generator.

Here, the public key of the passenger wallet 20 serves as a unique identifier for the rideshare system and cannot be duplicated.

The external wallet can deposit cryptocurrency into the rideshare wallet and is a cryptocurrency wallet other than the decentralized P2P rideshare system of this embodiment.

In this embodiment, sufficient cryptocurrency can be sent from the external wallet to cover the ride cost. The rideshare smart contract 40 can be activated only if at least the fare presented by the passenger has been transferred to the smart contract 40, and the rideshare wallet must have sufficient funds to proceed to the next ride reservation stage. Accordingly, the passenger wallet 20 must have sufficient funds to satisfy the ride fee.

The passenger wallet 20 is activated and the live fare may be deposited into the smart contract 40. The ride fee includes a reservation fee.

Passengers activate a ride-request smart contract (RRSC). In this case, since the provided ride fee is always larger than the reservation fee, the reservation fee may be calculated as part of the ride fee. Thus, if the passenger completes the entire ride and pays the full amount, there is no additional charge or fee, but if the passenger does not comply with the original conditions and the ride smart contract is canceled, the amount returned by the passenger will be booked in full on the ride fee. It may be an amount excluding the fee.

When the passenger boards in such a situation that the ride is not completed, the smart contract 40 returns the ride fee to the passenger, and the charged ride fee may be added to the reservation fee in addition to the proceeding ride fee. At this time, the condition that the passenger does not charge the booking fee is when the smart contract 40 is canceled due to the driver's fault.

If the smart contract is canceled due to the reason provided by the passenger, the reservation fee is transferred to the driver. If the smart contract is canceled due to the cause provided by the driver, the reservation fee may be transferred to the passenger.

And the smart contract 40 holds the ride fee. The passenger enters the details of the proposed fare and the destination address into the smartshare 40 template of the rideshare program, and when the proposed fare is transferred from the passenger wallet 20 to the smart contract 40, the smart contract 40 is generated. The generated smart contract 40 holds the fare that the passenger transferred from the passenger wallet 20 to the smart contract 40. The smart contract 40 is programmed to issue payments, refunds and deductions only when certain conditions are met in the payment process.

Every ride request is treated as a separate rideshare smart contract, so passengers enter into a new smart contract through the rideshare program whenever they request a ride. All rideshare smart contracts 40 not selected in the ride pool may be automatically canceled after 24 hours.

The smart contract 40 generated by the ride request is posted to the ride pool. The ride pool will publish all valid rideshare smart contracts, sorted by passenger's pick up location in the ride pool. The passenger may cancel the ride smart contract at any time without losing the booking fee before the driver selects the current ride smart contract 40 from the ride pool. After the driver selects the passenger's ride smart contract and the passenger cancels, the passenger gets back the amount excluding the passenger's booking fee, and the ride smart contract is cancelled. At this time, the booking fee of the passenger is paid to the driver.

2 and 3, if the passenger is registered in the blockchain / tangle network 10, the passenger may log on to the rideshare program network, enter a destination address, and enter a ride fare format. And the ride fee is transferred from the passenger wallet 20 to the smart contract 40. The rideshare program allows only one request at a time. If multiple requests are not allowed and a new ride request is made, the current ride request must be concluded or cancelled. In this case, the passenger inputs an address to go to the rideshare program as a default, but may include an option for inputting a pickup address in case the passenger's pickup address is not the same as the passenger's current GPS position.

Here, entering the destination address may request that the rideshare program enter a 4-pin security pin to assign to the smart contract 40. The pin code can later be used to verify and verify the passenger's driving status (vehicle entry / exit confirmation).

The selection of the ride fee format may automatically generate a ride fee. The rideshare program automatically recommends the ride fare based on the destination entered by the passenger and confirms whether the passenger will accept the automatic ride fare and provide another ride fare. At this time, if the passenger wants to manually set a different ride fare, the rideshare program may request to input a desired ride fare. This is because sometimes passengers can offer less ride fares to attract a lot of attention from the driver or in non-urgent situations.

When the passenger manually inputs the ride fare, it is possible to check whether the passenger wallet 20 has funds for paying the ride fare that the passenger wants to pay. If the funds are sufficient (Yes), the ride fee is deposited from the passenger wallet 20 to the smart contract 40, and if the funds are not sufficient (No), transfer enough cryptocurrency to cover the ride fee from the external wallet. do. After the transfer, the ride fee is booked as a booking fee in the smart contract 40 in the passenger wallet 20. The ride smart contract 40 is then posted to the ride pool.

The ride pool may post all valid rideshare smart contracts 40 classified in the ride pool as the passenger's pickup location.

When the ride fee is automatically generated, the ride fee is paid from the passenger wallet 20 to the smart contract 40. The smart contract 40 holds a ride fee, a portion of which may be booked as a booking fee.

If the ride request requested by the passenger is not selected by the driver within the 'T1' time, the passenger can confirm whether to request a ride increase or cancel the ride request in order to attract more drivers. Here, allowing the ride fee to be lowered will attract more drivers as much as possible and may encourage the driver to choose the ride request. In addition, if the passenger sets the ride fare manually, the passenger may be given the opportunity to modify the ride fare. For example, even if a passenger has previously paid the same fare multiple times for the same ride, the fare may vary depending on different conditions, such as peak hour traffic or late night traffic. At this time, when the passenger raises the ride fee, the passenger deposits the additional amount in the smart contract 40 in the passenger wallet 20.

Referring to FIG. 3, the driver turns on the power of the driver portable device 50. At this time, in the present embodiment, the driver portable device 50, like the passenger portable device 30, a smartphone or the like that can be connected to the GPS system and the Internet may be used. Turn on the GPS system of the driver mobile device 50 to be performed. In this case, the driver portable device 50 may log on to the blockchain / tank network through the mobile rideshare program.

Here, if the driver is not registered in the decentralized P2P rideshare system (No), the registration process may proceed. When a new driver registers with a decentralized P2P RideShare system, the driver can present the driver's license along with details of the driver's contact details, insurance information, etc., along with the driver's picture. Using this information, the decentralized P2P rideshare system creates a data file.

The driver's data file may be a driver's business promotion and information file that passengers can view and refer to at any time. The driver data file is stored in the blockchain / tangle network 10 and both the input information and the modified information can be posted for passengers to see. In this case, personal information such as an identification number of the driver may be encrypted. The driver data file records driver ratings and reviews, includes vehicle information, such as the model of the vehicle and vehicle photos, and includes driver photos for passenger reference, contact information used by the rideshare, and any additional information the driver wants to promote his services. May be included.

3 and 4, when the driver data file is generated, the driver wallet 60 is generated. The driver wallet 60 subscribes to the blockchain / tangle network 10 controller for the rideshare. The driver contact and ID information is submitted to the blockchain / tangle network 10 controller. The blockchain / tangle network 10 controller verifies that the contact submitted by the driver is a true contact number. To create a cryptocurrency wallet for use in a decentralized P2P rideshare system, the driver's contacts need to record the correct contact number and the correct ID. The blockchain / tangle network 10 controller sends an authentication code to the driver mobile device 50, and the driver resubmits the verification code to the blockchain / tangle network 10 controller from the driver mobile device 50 to the contact number. Check. Then, the blockchain / tangle network 10 controller checks the submitted authentication code and issues the driver wallet 60 to the driver, thereby generating the driver wallet 60.

The driver is registered in the decentralized P2P rideshare system and the driver wallet 60 paying the reservation fee has sufficient funds. At this time, if there is not enough funds in the driver wallet 60, the external wallet transfers enough cryptocurrency to cover the reservation cost of the driver. In order for the driver to activate the passenger's rideshare smart contract 40, the reservation fee may be activated only when the reservation fee is transferred to the smart contract 40. As a result, if there is not enough funds in the driver wallet 60, the progress to the next step may be suspended.

The reservation fee of the driver may prevent the driver from deviating from the conditions of the smart contract 40. If the driver does not comply with the terms of the smart contract, the driver may lose the reservation fee. In this case, the reservation fee is provided to the passenger in the form of a refund, and if the driver complies with the smart contract conditions, the reservation fee can be fully refunded to the driver wallet 60. Here, the reservation fee of the driver is held in the smart contract 40 until the ride is completed.

All ride requests are posted to the ride pool and can be posted classified according to the passenger's pickup location. All ride smart contracts are posted in the ride pool and are visible to all parties, passengers and drivers. The driver can select the passenger's ride request through the ride pool.

The driver selects a contract that is most suitable for the driver among the rideshare smart contracts 40 posted in the ride pool. When the driver selects the smart contract 40 available in the ride pool, the driver can view information about the passenger's pickup location, destination location and the fare the passenger is willing to pay.

And when the driver selects a smart contract, the RideShare program provides information such as the driver's contact information, driver photos, car information, and driver reviews, the driver's GPS location and the estimated time of arrival (ETA), and a link to the driver data file. Information and the like may be transmitted to the passenger portable device 30 for passengers to confirm. Driver data files allow passengers to view driver reviews and service ratings.

The passenger portable device 30 may generate a notification regarding the selection of the driver, and the passenger who has received the driver information may select to accept or reject the driver within the 'T2' time. If the driver is rejected, the smart contract 40 is posted back to the ride pool, and the driver may be blocked from selecting the smart contract 40 again.

And if the passenger does not choose to accept or decline the driver within the 'T2' time, the smart contract 40 may be canceled from the ride pool.

The driver's wallet 60 transmits the driver's reservation fee from the driver's wallet 60 to the smart contract and the smart contract 40 holds the reservation fee. When the passenger approves the driver, the driver receives a notice in the rideshare program that the passenger has accepted the driver, and the driver approves the booking fee to the smart contract 40. The reservation fee of the driver is a fee held by the smart contract 40 in case the driver does not comply with the smart contract conditions.

When the driver's reservation fee is deposited in the smart contract 40, the smart contract between the passenger and the driver is activated. When the smart contract 40 is activated, the driver must comply with the terms of the smart contract until the end of the ride so that the driver can return the driver fee when the ride is completed.

When the driver's reservation fee is transmitted to the RRSC, GPS signals of the passenger and the driver are connected, and the locations of the passenger and the driver can be displayed on the search map. The estimated arrival time (ETA) for the driver's pickup location can be calculated by the navigation system, registered with the RRSC, and displayed on a map visible to both passengers and the driver.

As such, the smart contract 40 of the passenger and the driver is activated, and as shown in FIG. 5, when the driver's reservation fee is transferred to the smart contract 40, GPS signals of the passenger and the driver may be combined and tracked. The driver's GPS location and estimated arrival time are communicated to the passenger using GPS and traffic information.

The driver moves to the passenger's pickup position, and the driver arrives at the passenger's pickup position. It checks to see if there is a passenger at the pick-up location, and if there is no passenger (No), it waits for 'T4'. Here, if necessary, after the "T4" time has elapsed, the driver may increase the waiting time or cancel the smart contract. In the case of canceling the smart contract, the driver's reservation fee is returned to the driver wallet 60, and the amount of the passenger's ride fee excluding the reservation fee is returned to the passenger wallet 20. And the passenger's booking fee can be deposited in the driver wallet 60, the smart contract 40 is terminated.

When the driver arrives at the passenger's pickup position, the passenger picks up the passenger if the passenger is at the pickup position.

The passenger can also wait for the driver at the pick-up location and verify that the driver has arrived at the pick-up location after the estimated time of arrival (ETA) determined by the system. If the driver arrives, the passenger boards the driver's vehicle, and if not, confirms that he or she will cancel the ride request. If you do not cancel the ride request, the passenger will continue to wait for the driver and if you cancel the ride request, the smart contract will be cancelled.

At this time, if it is not proved that the passenger boarded the driver's vehicle within T3 hours after the estimated arrival time ETA, the RRSC is automatically canceled. The ride fee stored in the smart contract 40 is refunded to the passenger, and the booking fee of the driver is refunded to the driver. Or, if the driver does not pick up the passenger at the expected arrival time and does not cancel the smart contract, the driver cannot accept another smart contract until the smart contract 40 is cancelled.

The passenger enters the ride requirements again after the smart contract 40 has been canceled and posts the new smart contract to the ride pool.

Here, when the driver does not appear in the pick-up position, the smart contract is terminated, and the passenger may receive the driver's reservation fee to the passenger wallet 20 in exchange for damage. Passengers can then write their assessments and reviews to the driver data file in a centralized P2P rideshare system.

5 and 6, a time point at which the driver and the passenger move together will be described.

Up to this point, the passenger and the driver have performed their actions at their respective points to proceed with the same ride, but when the passenger boards the driver's vehicle, they travel together until they reach their destination. Accordingly, the GPS signal of the passenger portable device 30 and the GPS signal of the driver portable device 50 may generate the same location signal.

After the passenger rides in the driver's vehicle, the driver portable device 50 and the passenger's mobile device are both turned on. If both GPS are on, proceed to the destination address.

However, if neither the GPS signals of the driver portable device 50 and the passenger portable device 30 are turned on, it is checked whether the GPS of the driver portable device 50 is turned on. At this time, if it is confirmed that the GPS of the driver portable device 50 is turned off, the device waits for T5 hours, and when it is confirmed that the GPS of the driver portable device 50 is turned off even after the T5 time, the smart contract is terminated. The passenger's ride fee is then refunded to the passenger wallet 20 and the driver's booking fee is paid to the passenger's passenger wallet 20.

At this time, if the GPS signal of the driver portable device 50 is turned on, it is possible to verify whether the passenger has boarded by using a cross device verification (CVV). At this time, the CDV is a system for verifying by inputting the security code to the driver portable device 50 through the rideshare program. At this time, it is a system that can not be confirmed by a single party without the other party's consent, the security code is transmitted only to the party entering the security code, it can be set when the smart contract is first formed.

Also, make sure that the GPS signals of the driver and passenger are moving in the same direction at the same time. Both the driver and passenger positions are monitored while the GPS signals of the driver portable device 50 and the passenger portable device 30 are turned on. Accordingly, if two GPS signals are moving in the same direction at the same time, the passenger is determined to be in the driver's vehicle.

At this time, if the two GPS signals do not move in the same direction at the same time, the smart contract is terminated. Then, the passenger's ride fee is refunded to the passenger wallet 20 and the driver's reservation fee is paid to the passenger wallet 20. Here, as described above, the driver is given importance to maintain the function of the driver portable device 50, and the driver is responsible for it. Accordingly, when a problem occurs in the driver mobile device 50 and the GPS of the driver mobile device 50 is turned off, the responsibility is passed to the driver, and in return, the driver's reservation fee is paid to the passenger wallet 20.

If both GPS signals move in the same direction at the same time, it is checked whether the GPS signals of the driver and the passenger both move a certain distance. When both GPS signals travel a certain distance, the first verification is automatically completed. If both GPS signals do not travel a certain distance, it can be manually verified through communication between the driver portable device 50 and the passenger portable device 30 through CDV, RF communication or Bluetooth communication.

In addition, if necessary, verification may be performed whether the passenger has boarded the vehicle. If verification has not been performed, the vehicle may be stopped and induced to be verified again. If the passenger is not in the vehicle, cancel the smart contract. In this case, the verification is not performed even when the vehicle is stopped, because the passenger or driver may not be cooperative in the verification process, in which case the smart contract is terminated. In this case, the driver reservation fee is refunded to the driver wallet 60, and the passenger has traveled a predetermined distance, so that the fare of the passenger is refunded to the passenger wallet 20 except for the reservation fee. And the passenger's booking fee is paid to the driver wallet 60.

Upon completion of the first verification, a copy of the smart contract 40 is sent to the passenger and driver's email for the safety of the passenger and driver upon completion.

The first attestation is confirmed in the smart contract 40 when the passenger boards the driver's vehicle, and the first attestation can be activated by:

How to verify boarding by exchanging signals between driver handheld device 50 and passenger handheld device 30 through RF or Bluetooth communication. Passenger uses his / her passenger handheld device 30 to verify the QR code or barcode of the driver. Primary verification can be activated by means of scanning and by the GPS signals of the driver and the passenger traveling the same distance in the same direction at the same time.

As described above, the first verification is completed and the copy of the smart contract 40 is sent to the passenger and driver's e-mail, the information is delivered at the end of the ride in the conventional centralized system, but according to the present embodiment This is because centralized P2P rideshare systems do not allow passengers to get off at the secondary attestation. For example, there is a fight or dispute that the second attestant disembarkation attestation cannot be activated. In this way, rather than until the end of the ride, the information contained in the ride smart contract 40 may be delivered to the e-mail, which is designated by the passenger and driver, together with time information.

Once this first verification is complete, it continues to the destination address.

In this case, referring to FIG. 6, before the passenger arrives at the destination, the passenger may get off from the driver's vehicle. To this end, it is checked whether the GPS signals of the driver and the passenger continue to move simultaneously in the same direction. If the GPS signal continues moving in the same direction at the same time, it continues to the destination address.

However, if the GPS signals of the driver and the passenger do not continuously move in the same direction at the same time, check whether the GPS signals of the driver and the passenger are separated by a specific distance or more. If it is not separated over a certain distance, wait until it is separated over a certain distance and check again if it is separated over a certain distance.

If the driver's and passenger's GPS signals are separated by more than a certain distance, it can be confirmed that the passenger got off the vehicle. Accordingly, the ride smart contract is concluded, and the distance traveled to the time when the driver's and passenger's GPS signals are separated is calculated as a percent classification. The calculation at this time calculates the distance traveled to the time point at which the GPS signal is separated and pays the corresponding amount to the driver's wallet 60, wherein the fare paid includes the reservation fee of the passenger.

The remaining amount paid to the driver wallet 60 is refunded to the passenger wallet 20, and the driver reservation fee is refunded to the driver wallet 60.

At this time, if the passenger's GPS signal is turned off during the ride, the rideshare program will wait for the estimated arrival time (ETA) plus T6 hours, and if the driver's GPS signal arrives at the destination address within that time, the passenger will return to the destination. A second proof of arrival is confirmed. Alternatively, if the secondary attestation is not confirmed, the driver arrives at the destination address and then waits for T6 hours to automatically confirm the second attestation and the ride is completed, all charges are normally processed and the smart contract 40 is concluded.

If the driver's GPS does not arrive at the destination address within the expected arrival time + T6 hours, the decentralized P2P rideshare system does not cancel the smart contract 40 until the driver arrives at the destination address and stays for T6 hours. Therefore, the driver cannot proceed with the other smart contract 40 until the smart contract 40 is cancelled. As a result, the driver cannot select another ride until the second attestation is finalized, so the smart contract 40 must be approved by the passenger for second attestation to arrive at the destination address or to interrupt the ride during the ride at the request of the passenger. It can be processed and fastened normally. If the driver and the passenger do not cancel or verify the smart contract 40, after 24 hours the smart contract 40 is canceled from the decentralized P2P rideshare system, and the fee held by the smart contract 40 They are refunded to the driver and passengers.

When the driver and the passenger arrive at the destination, the driver portable device 50 and the passenger portable device 30 are both operated. When all works normally, the second verification is performed by exchanging RF communication, Bluetooth communication, or wifi signal between the driver portable device 50 and the passenger portable device 30. Alternatively, the passenger may perform the second verification by scanning the QR code or the barcode of the driver using the passenger portable device 30. When the second verification is completed, the total fee including the booking fee is paid to the driver wallet 60. The reservation fee of the driver is refunded to the driver wallet 60.

If both the driver portable device 50 and the passenger portable device 30 do not operate normally, the arrival of the destination address is confirmed by CDV or the second verification is performed. At this time, if the secondary attestation fails or fails, if the driver waits for the T6 time at the destination location, the arrival of the destination is automatically verified and the secondary attestation is completed. Accordingly, the total fee including the reservation fee is paid to the driver wallet 60, and the driver reservation fee is refunded to the driver wallet 60.

When the smart contract 40 is concluded, the ride completion information is transmitted to an e-mail address of the passenger and driver. Passengers can upload driver reviews and reviews to the centralized P2P rideshare system.

On the other hand, the controller for controlling the network checks the state of the battery of the passenger portable device 30 and the driver portable device 50, the result of the check that the battery state of the passenger portable device 30 and the driver portable device 50 is When certain conditions (eg, when the battery is discharged or fail), an interface that can be manually inputted to the passenger portable device 30 and the driver portable device 50 can be displayed on each display.

As described above, the decentralized P2P rideshare system may use the decentralized P2P rideshare system while the owner of the vehicle does not use the vehicle as the autonomous vehicle market grows in the future. In this case, there may be a problem of trust between the autonomous vehicle and the passenger, which can be provided by a two-step authentication method using a decentralized P2P rideshare system.

On the other hand, as the fragrance material having a function such as respiratory disease treatment is coated on the outer surface of the passenger portable device 30, it exhibits the effect of fatigue recovery, health promotion, etc. of the user.

The fragrance material may be mixed with a functional oil, the mixing ratio of the fragrance is 95 to 97% by weight of the functional oil is mixed 3 to 5% by weight, the functional oil 50% by weight of Tangerine (Tangerine oil), palmitore It consists of 50% by weight of palmitoleic acid oil.

The functional oil is preferably 3 to 5% by weight relative to the perfume. When the mixing ratio of the functional oil is less than 3% by weight, the effect is insignificant, and when the mixing ratio of the functional oil exceeds 3 to 5% by weight, the function thereof is not greatly improved while the manufacturing cost is greatly increased.

Tangerine oil among functional oils include citronellol, linalool and cital as main chemicals, and it is effective in relieving stress through antiseptic, antispasmodic and sedative effects.

 Palmitoleic acid oil is an antioxidant that is good for dry or aged skin and has excellent effects on cell regeneration, sterilization and skin inflammation treatment.

As the functional oil is coated on the outer surface of the passenger portable device 30, it serves to contribute to the user's fatigue recovery, health promotion and the like.

In addition, the antifouling coating layer coated with the antifouling coating composition may be formed on the outer surface of the driver portable device 50 so as to effectively prevent the attachment and removal of the pollutant.

The anti-fouling coating composition includes alkanolamide and ampopropionate in a molar ratio of 1: 0.01 to 1: 2, and the total content of alkanolamide and ampopropionate is 1 to 10 based on the total aqueous solution. Weight percent.

The alkanolamide and ampopropionate are preferably in a molar ratio of 1: 0.01 to 1: 2. When the molar ratio is out of the above range, the coating property of the substrate is decreased or the moisture absorption of the surface is increased after the coating, thereby forming a coating film. There is a problem that is eliminated.

The alkanolamide and ampopropionate have a problem in that 1 to 10% by weight of the total composition aqueous solution is preferred. If the content is less than 1% by weight, the applicability of the substrate is lowered. Crystal precipitation is likely to occur due to an increase.

On the other hand, it is preferable to apply | coat by the spray method as a method of apply | coating this antifouling coating composition on a base material. The final coating film thickness on the substrate is preferably 500 to 2000 kPa, more preferably 1000 to 2000 kPa. If the thickness of the coating film is less than 500 kPa, there is a problem of deterioration in the case of high temperature heat treatment, and if the thickness of the coating film exceeds 2000 kPa, crystal precipitation of the coated surface is liable to occur.

In addition, the present antifouling coating composition may be prepared by adding 0.1 mol of alkanolamide and 0.05 mol of ampopropionate to 1000 ml of distilled water, followed by stirring.

In addition, a sound absorbing layer may be applied to the inside of the case protecting the blockchain / tangle network 10 controller.

Needle punch felt may be used as the felt constituting the sound absorbing layer.

Examples of the fibers constituting the sound absorbing layer made of the needle punch felt include polyester fibers, nylon fibers, polypropylene fibers, acrylic fibers, and natural fibers.

It is preferable that the thickness of the said sound absorption layer is 0.5-16 mm. If the thickness of the sound absorbing layer is less than 0.5 mm, a sufficient sound absorbing effect is not obtained. If the thickness of the sound absorbing layer is more than 16 mm, the height of the case is reduced and the space of the case is not sufficiently obtained.

The unit weight of the sound absorbing layer is preferably set to 5 ~ 500g / m ² . If it is less than 5 g / m ² , a sufficient sound absorption effect is not obtained, and if it exceeds 500 g / m ² , the light weight of the case cannot be secured, which is not preferable.

The fineness of the fibers constituting the sound absorbing layer is preferably in the range of 0.1 to 20 decitex. If it is less than 0.1 decitex, it is not preferable because absorption of low frequency noise is difficult and cushion property is also reduced. It is also undesirable to exceed 20 decitex because it is difficult to absorb high frequency noise. Especially, as for the fineness of the fiber which comprises a sound absorption layer, it is more preferable to set it as the range of 0.1-15 decitex.

Since the sound absorbing layer is provided inside the case, it is possible to reduce noise when driving the controller.

In addition, the outer surface of the case may be coated with a color change portion that changes color depending on the temperature. The discoloration unit may be applied to the case surface by two or more thermochromic substances that change color when a predetermined temperature or more is separated into two or more sections according to the temperature change, and thus the step change of temperature may be determined. A protective film layer is applied to prevent the discoloration part from being damaged.

Here, the color change part may be formed by applying a temperature change material having a color change temperature of 40 ° C. or higher and 60 ° C. or higher, respectively. The color change part is for detecting the temperature change of the paint by changing the color according to the case temperature.

Such a color change part may be formed by applying a color change material that changes color when a temperature is higher than a predetermined temperature to the case surface. In addition, the thermochromic material is generally composed of a microcapsule structure of 1 ~ 10㎛, it can be colored and transparent due to the binding and separation phenomenon depending on the temperature of the electron donor and the electron acceptor in the microcapsules.

In addition, the color change material is a fast color change, it may have a variety of color change temperature, such as 40 ℃, 60 ℃, 70 ℃, 80 ℃, such a color change temperature can be easily adjusted in a number of ways. Such thermochromic materials may be used in various kinds of thermochromic materials based on principles such as molecular rearrangement of organic compounds and rearrangement of atomic groups.

To this end, the discoloration unit is preferably formed to be separated into two or more sections in accordance with the temperature change by applying two or more thermochromic materials having different discoloration temperature. The temperature discoloration layer is preferably a temperature discoloration material having a relatively low temperature discoloration temperature and a temperature discoloration material having a relatively high temperature discoloration temperature, more preferably having a discoloration temperature of 40 ° C. or higher and 60 ° C. or higher. The color change part may be formed using a temperature change material.

Through this, it is possible to check the temperature change of the case step by step to detect the temperature change of the paint, and thus the controller inside the case can be operated in the optimal state, and prevent the damage of the controller due to overheating in advance. Can be.

In addition, the protective film layer is applied on the discoloration part to prevent the discoloration part from being damaged by an external impact, and easily check whether the discoloration part is discolored, and at the same time, considering the weakness of the temperature discoloring material in heat, It is preferable to use.

As described above, the detailed description of the present invention has been made by the embodiments with reference to the accompanying drawings. However, since the above-described embodiments have only been described by way of example, the present invention is limited to the above embodiments. It should not be understood, the scope of the present invention will be understood by the claims and equivalent concepts described below.

10: Blockchain / Tangle Network
20: Passenger Wallet
30: Passenger mobile device
40: RideShare Smart Contract
50: Driver Mobile Device
60: driver wallet

Claims (8)

A passenger mobile device requesting a ride to use a rideshare service;
A driver mobile device that selects a ride requested by the passenger mobile device to provide the rideshare service; And
A network to which a blockchain technology or a tangle technology is applied, which generates a smart contract for the requested ride on the passenger mobile device and publishes the generated smart contract to be selected through the driver mobile device. Decentralized P2P rideshare system.
The method according to claim 1,
The network is a decentralized P2P rideshare system for generating a passenger electronic wallet to pay the ride fee on the passenger mobile device, and a driver electronic wallet to receive the ride fee on the driver mobile device.
The method according to claim 2,
The passenger mobile device deposits a reservation fee into the smart contract to request a ride to use the rideshare service,
The smart contract is a decentralized P2P rideshare system for storing deposit fees.
The method according to claim 3,
The reservation fee is paid to the driver's electronic wallet if the rideshare service is not concluded normally at the fault of the passenger while the passenger uses the rideshare service.
The method according to claim 2,
The driver mobile device deposits a reservation fee into the smart contract to provide the rideshare service,
The smart contract is a decentralized P2P rideshare system for storing the deposit reservation.
The method according to claim 3,
The reservation fee is paid to the passenger electronic wallet if the rideshare service is not concluded normally at the fault of the driver while the driver provides the rideshare service.
The method according to claim 1,
The passenger mobile device and the driver mobile device each include a GPS system,
The controller for controlling the network checks at least one of boarding information, travel distance information and getting off information on a vehicle in which the driver of the passenger operates using GPS information of the passenger portable device and the driver portable device.
If the controller fails to check the GPS information in any one of the passenger portable device and the driver portable device, the cross-interaction security code authentication may be performed using a communication function or a photographing function included in the passenger portable device and the driver portable device, respectively. De-centralized P2P rideshare system to check any one or more of the passenger boarding information, travel distance information and getting off information through.
The method according to claim 1,
The controller for controlling the network checks the status of the battery of the passenger portable device and the driver portable device, and if the battery status of the passenger portable device and the driver portable device corresponds to a specific condition, the passenger portable device and Decentralized P2P rideshare system that displays a manually inputable interface on a driver's mobile device.

Images