Requirements for Patents Ownership Blockchain Ledger

The goal of this project is to develop the business requirements for a blockchain that concentrates on the ledger and smart contract aspects of a blockchain to document, enforce, and track ownership of patents as well as track other attributes of patents such as family history and terminal disclaimers.Most companies that are in fields, such as high tech, where the generation of patents are expected have employment contracts that commit employees to assigning ownership rights in inventions conceived on the job to their employers. However, when a patent application is filed there is a lot of manual paperwork that must be created, signed, and filed to assign ownership of the invention to the employer. This is multiplied by the number of inventors that collaborated on the invention. This paperwork sometimes is forgotten. Often employees change jobs before the paperwork is filed. The problem is compounded by divisional and continuation applications that may be filed years after the original. This is especially true since the America Invents Act stresses the need for new assignments for the divisional and continuation applications. Employment contracts in the form of smart contracts can be used to automate the generation of assignment paperwork.However, there are a lot of non-software details to work out. Who has the authority to enter the current ownership of existing patents, the current state of employment contracts, new employment contracts, associations between new patents and employees, etc. Can a smart contract be developed that is valid in all 50 states? What if a court ruling forces a change? Must the smart contract be retroactively changeable? Other issues will be discussed if the project is accepted and are contained in attached files.

RF circuitry marketing strategy/plan

We have developed novel circuitry for 5G mm-wave wireless communications. We would like to license the technology into new semiconductor products and offer design services to help integrate it into new products. The project includes:analysis of the RF semiconductor space to identify potential licensees for the technologyidentification of appropriate contacts at the identified companies, where possiblecritique of current marketing materialssuggestions and development of additional marketing materialsanalysis of appropriateness of potential marketing methods - e.g., direct contact of individuals, email, LinkedIn, website, etc.plan for marketing the technology and design services

Native Blockchain Foundation Development

BackgroundA cellular operator is starting a new wireless network in a developing country where a non-trivial percentage of the population may not have access to the banking system. In addition to managing the cellular contracts with subscribers, the operator eventually wants to provide other services such as money transfer and purchase or exchange of goods via smartphones. The operator wants to manage this through a distributed ledger system, but wants it to be independent of existing blockchains such as Bitcoin and Etherium which require payment back to those systems and are beholden to the developers and users of those systems.Requirements and recommendations1) Native blockchaina. Not built on Bitcoin, Etherium, etc.b. History not stored on Bitcoin, Etherium, etc.2) Recommend looking at Hyperledger Fabric or Hyperledger Iroha as starting points3) Permissioned, not publica. Anyone can join (subject at some point to a cellular subscription), but only trusted entities can verify transactions4) Modular, plugable consensusa. Start with Byzantine Fault Tolerant (BFT)5) Modular, plugable encryption6) Subchain support7) Must not preclude supporting a coin or token at a later date8) Support for smart contractsa. C++ support preferred, but not required9) Support for mobile apps at a later date10) No GNU GPL licensed open source alloweda. Open source software licensed under other licenses, such as the Apache 2.0 license https://www.apache.org/licenses/LICENSE-2.0 is allowed upon approval of the license

Dynamizing Public Transport - Simulation

BackgroundPublic transportThe current state of public transport is pitiful. It hasn’t changed in almost 100 years. A simple Google Maps search can demonstrate that the length of time it takes for a bus to get from point A to point B is 3 times longer than it takes a car. Besides being slow, public transport is also expensive and inefficient. Transit buses are usually almost empty and have a gas mileage of 3.26mpg, versus the 23.41mpg of a car. Further, public transport is rigid and user unfriendly. Bus schedules are set months in advance on the basis of historical data. Such a system does not adapt well to disruptions.The sorry state of the public transport system is one of the major reasons people choose to drive.And how to fix itMake public transport serve the people instead of the other way around. Lyft and Uber have proven that private transport can be made more efficient than the taxi system. A similar principle can be adapted to public transport, and can provide larger gains in efficiency. Each patron of such a system would have a smart phone with an app with which they can make a request for transport to whichever destination they desire. All the requests would be processed in a Central System which would then calculate the optimal routes and distribute public vehicles accordingly. The vehicles would be equipped with another smart phone directing them where to go and whom to pick up. The patron would then get a confirmation of their request along with the estimated waiting time and the estimated time for the arrival to the final destination. The Central System would group nearby patrons desiring similar destinations in the same vehicles.For such a system to be efficient, it is necessary to have vehicles of different sizes. Smaller size vehicles would serve less dense areas and non-peak hours. Somewhat similar to the “park and ride” systems, larger vehicles would transport larger number of riders from one side to another side of the city. Smaller vehicles would gather riders to the larger vehicles, and on the destination side, smaller vehicles would distribute riders to their final destinations.Value propositionsWould this system be faster?Undoubtedly yes. As soon as a patron makes a request, the Central System would calculate the optimum route based on the final destination and would reroute the closest/best suited vehicle for pick up or assign an unused vehicle to the task. To avoid wait times due to transfers between vehicles, the Central System would time the arrival of the smaller vehicles to arrive at roughly the same time as the larger vehicle.Furthermore, this system would be able to instantly adapt to new conditions by adding more vehicles in times of need or taking unused vehicles off the road.Would this system be less expensive?It should be. The cost savings come from better utilization of vehicles, as vehicles would only be deployed when needed. In addition, smaller vehicles cost less and utilize less gas than larger buses. As well, cost savings come from more optimized routes, which travel shorter distances while carrying the same or larger number of passengers. Cost savings climb as the ridership and the number of vehicles climbs.Proving the conceptThere already exist datasets which can be used to test this theory. Among others, Brisbane and Singapore collect data with start and end points for each trip taken (“tap in” and “tap out” data) for all their public transport patrons. Given the originating point, destination point, and the originating time of day, this data can be used to simulate the solution proposed. By running multiple simulations with different variables, including the number of vehicles, the ratio of smaller to larger vehicles, the number of available drivers, the number of transfers, the average time of waiting for transport, and the fuel consumption, an optimum set of variables can be chosen.Would it be too expensive to throw away a large number of buses and replace them with smaller vehicles?It is not necessary to make such a drastic change. Every public transport system replenishes their fleets yearly, retiring older buses and buying new ones. The change in the fleet could be achieved gradually by buying smaller vehicles instead of traditional buses for a few years until the optimum fleet configuration is achieved.What would the drivers gain from this system?In the existing system, drivers have little flexibility in choosing their shifts. This system would allow for drivers to pick their working hours. The system could incentivize drivers to drive at the times of greatest need by giving higher wages.For the system to achieve maximum efficiency, it is necessary to have an optimum number of drivers on the road at all times. This can be achieved by giving drivers freedom to choose. For example, they might be allowed to choose 80% of the times they want to ride but might be obligated to drive 20% of the time when the Central System needs drivers but has no volunteer drivers available.How would this system be able to adapt to new conditions?The proposed solution should be much better at reacting to congestion, accidents, and other disruptions. The Central System would possess knowledge of the positions and speeds of all vehicles, and would utilize traffic data from sources like Google Maps and alike. This would allow the System to avoid congested areas and reroute traffic in real time.How to get cities to undertake this change?Most people cringe when faced with the prospect of trying to introduce a change in municipal governance. However, there are hundreds of thousands of cities in the world wrestling with the public transport problems. Armed with the simulation results showing advantages of the proposed solution, it should be possible to persuade at least a few cities to switch to the new system. Given the nature of the solution, it is very likely that these first projects would be widely publicized, especially if the results are higher user satisfaction, lower cost, less pollution etc. This should result in a push by citizens in other cities to adopt a new system and give city councillors ammunition for the change.RequirementsInput dataData set containing tap-in, tap-out information for a representative city for a period of time.Map of the city.Among others, Brisbane and Singapore collect data with start and end points for each trip taken (“tap in” and “tap out” data) for all their public transport patrons.Use existing infrastructure - subway, tram, train, ferryThe simulation needs to be able to stipulate “hard-coded” routes with “hard-coded” stops for the existing infrastructure.hybrid model – mix of hardcoded schedule + dynamized scheduleIt is likely that client cities will want to switch to the new system gradually, over a period of months or even years. The simulation should be able to import existing bus/tram/train/ferry routes and schedules and use them together with the dynamized vehicles. The imported data would effectively define the percentage of the rides fulfilled by the old vs new system.This should be done in conjunction with the “use existing infrastructure” requirement – the implementation should be common for both.The hybrid simulation using e.g. Brisbane data set would import the routes and schedules for the vehicles in the old system, but would use the actual travel data for these vehicles from the data set. This will enable a more realistic simulation.RouteEach route has GPS coordinates translatable to the streets on the map.APIUse Google Maps API or a different suitable API, to calculate routes.Ensure repeatability by ignoring traffic congestion when asking Google Maps for routes.Traffic congestion dataEnsure that the simulation does not ignore traffic jams, congestion, slowdowns which are present in the input data. (Using existing API like Google Maps will insure this.)Simulation timingThe simulation should be run without any “peeking into the future”. The simulation should run sped up X times, but the timing of the requests (corresponding to the tap-in data) should be preserved. Also, care should be taken to ensure that the simulation is not affected by the fact that Google is calculating routes for a live city for the simulation – i.e. running the simulation during peak traffic hours may result in slower results if traffic congestion information is not ignored in API requests.Route planningUses tap-in time and location and tap-out location. (Tap-out time will be the result of the simulation)Adaptable for different citiesThe simulation infrastructure should be created in such a way to allow reuse for different cities:using different maps, type and number of vehicles, existing infrastructure (subway, tram, train, ferry…)Two types of vehicles: large (bus) and smallVary the small vehicle sizeVehicle size, especially for the small vehicle, needs to be configurable so different simulations can be done to determine the best vehicle size.Google uses Chrysler Pacifica minivan which has 8 passenger seats and can drive 55km on an electric battery.https://tech.slashdot.org/story/18/11/14/0152236/waymo-to-start-first-driverless-car-service-next-monthTBD: calculate fuel savings with hybrid cars – e.g. Chrysler Pacifica saves 55km every day. It can save more if it can be recharged while not in use.Preferred stopsThe system should give preference to existing bus stop locations because they have already been cleared as safe to use for buses. Therefore, even if a patron requests a service when away from a bus stop, he/she should be made to walk to the bus stop, unless being picked up by a car, in which case there is more flexibility.Sharing of bus stopsUse bus stops for small vehicles as well but ensure that it is not used by a bus at the same time.No stops on certain roadsE.g. no stops on highways.OutputMaximum and average time of waiting for transport (output result)Maximum and average time of waiting between transfers (output result)Total fuel consumption (output)Total vehicle hours travelled (for each vehicle type)Number of kilometers travelled by vehiclesMaximum and average travel on footFor each simulation run:List of passenger routesList of vehicle routesVariablesIt must be possible to run the simulation over and over with different parameters. The purpose for this is to identify the optimum set of parameters for the cost/convenience analysis. This is not very well thought out - some of these variables will end up as the output statistics instead…Average trip time (output result)Maximum and average number of transfers (input)Maximum number of large vehicles (input)Maximum number of small vehicles (input)Average number of active large vehicles (input)Average number of active small vehicles (input)Average utilization of vehicles (input and output)Avg. number of passengers vs maximum the vehicle can accept. All these “number of vehicles” variables are inter-dependant. However, we need to be able to tune vehicle these numbers. E.g. make the “sensitivity” to the need for more vehicles tunable: wait until utilization is 100% for all vehicles in an area before deploying another vs. as soon as the utilization in a small area is 50%, deploy another vehicle…Maximum number of available drivers (input)Average number of active drivers (input)Number of kilometers travelled by vehicles (input and output)The routes asked for from the API can be optimized for speed versus distance.Maximum and average travel on foot (input and output)Input data only has the tap-in, tap-out data – not the additional travel on foot data. Our simulation needs to allow for a certain travel on foot to pick-up, from drop-off and, if necessary for transfers.When comparing with input data, we would need to make some assumptions regarding the average food travel – for example based on the average half distance between bus stops.Simulation needs to provide the backbone for the real-time trip handling in a delivered product.Even though the simulation has no real time requirements, it would be very beneficial if the route planning code can be reused in the deployment.