[go: up one dir, main page]

WO2024091861A2 - Couchette pneumatique et réseau internet pour la protection communautaire des personnes, la visualisation et la navigation virtuelles et l'authentification des preuves - Google Patents

Couchette pneumatique et réseau internet pour la protection communautaire des personnes, la visualisation et la navigation virtuelles et l'authentification des preuves Download PDF

Info

Publication number
WO2024091861A2
WO2024091861A2 PCT/US2023/077499 US2023077499W WO2024091861A2 WO 2024091861 A2 WO2024091861 A2 WO 2024091861A2 US 2023077499 W US2023077499 W US 2023077499W WO 2024091861 A2 WO2024091861 A2 WO 2024091861A2
Authority
WO
WIPO (PCT)
Prior art keywords
video
source
user
seat
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2023/077499
Other languages
English (en)
Other versions
WO2024091861A3 (fr
Inventor
Arjuna Indraeswaran Rajasingham
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of WO2024091861A2 publication Critical patent/WO2024091861A2/fr
Publication of WO2024091861A3 publication Critical patent/WO2024091861A3/fr
Priority to US19/189,201 priority Critical patent/US20250315901A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G06Q20/123—Shopping for digital content
    • G06Q20/1235—Shopping for digital content with control of digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the present inventions provide a new structure and passenger transport paradigm for accommodating passengers in a vehicle with particular attention paid to safety, utility and comfort, social networks including a technology configured to enable community engagement in personal protection and methodologies for virtual visualization and navigation in a remote physical space and provides a mechanism for verification and authentication of video and other evidence.
  • a technology configured to enable community engagement in personal protection and methodologies for virtual visualization and navigation in a remote physical space and provides a mechanism for verification and authentication of video and other evidence.
  • Structural plate 3C 23-003 - laterally contoured seat back lower section provides lumbar support and also for the lower occupant support, accommodates structural plate 3C 23-004 – Sleep space without lateral intrusion using structural plate 3C embodiment 23-005 – Shoulder space and arm rest 23-006 – Plate 3C 23-007 – laterally contoured seat back lower section facilitates angled accommodation with occupant facing the flat bed, and in some embodiments may also provide additional space for the occupant behind.
  • 23-008 – Lumbar support that in some embodiments is slidable up and down along the angled surface of the lower seat back, and inflatable for comfort.
  • 23-009 Shown in a low position 23-009 - Flat bed housing with a end cutoff to offer more space to adjoining passenger bed.
  • 23-010 Lowest level of the up[per deck for the center aisle on the upper deck. Notably the level of this section can be in some embodiments lower with AirSleepers rather than regular seats.
  • 23-011 intermediate level of the floor of the upper deck that will in some embodiments support the seat section of the AirSleeper. 23-012 - High level of the upper deck to support the sleep surface.
  • 22-013 attachment to fuselage wall structure on sides 22-014 - stairs to lower deck. Galley may be placed below the stairs 22-015 – Seat section of the AirSleeper2.
  • Controls in some embodiments will be attached to the mobile/adjustable seat bottom below arm rest level. Most such embodiments would have such controls on the side of the seat away from the aisle.
  • 24-009 – Back rest 24-010 – Lumbar Support which can be raised and lowered along the spine and can be inflated or deflated to suit the comfort of the occupant. Inflation in some embodiments are with a manual bellows pump.
  • Controls in some embodiments will be attached to the mobile/adjustable seat bottom below arm rest level. Most such embodiments would have such controls on the side of the seat away from the aisle.
  • 24-011 Pivotal support for seat to allow swiveling. Swiveling action may in some embodiments be locked to the axis of the bed or to the axis of the fuselage. Some embodiment have a slid able attachment of the pivot in the direction of the axis of the fuselage to allow people of smaller stature to move forward and those of larger stature to move back.. Some of these embodiments have locking mechanisms in 2 or more positions along the slid able axis.
  • 24-012 – seat bottom (embodiment shown is a symbolic representation with only the rear portion of the seat, a full seat will be shaped and sized for comfort 24-013 – Contoured shape of fixed seatback, including lean-back surface, orthogonal to the axis of the bed that will allow occupant to lounge or recline with feet up on bed surface.
  • This embodiment does not have the contoured adjustable seat but uses the surfaces of the cavity for a seat.
  • 24-015 Cable connecting manual or motorized actuator to the lumbar support to lower or raise the lumbar support. Controls in some embodiments will be attached to the mobile/adjustable seat bottom below arm rest level. Most such embodiments would have such controls on the side of the seat away from the aisle. 24-016 – Spring damper assembly to retract flip out steps to closed position. Manual operation case for opening stairs. The stairs can also be deployed with a servo. Figs 24-014 and 24-015 show the stairs open and fully extended spring damper and also with it partially closed with a partially retracted spring damper. The spring loading will retract the stairs against a damper that will slow the motion. The weight of the passenger and the delay caused but the damper will keep the stairs open and deployed for use.
  • “C” NFT 26-006 Video/Image retrieval from Time machine Map using radar and time/date selection.
  • ZKP Zero Knowledge Proof
  • Fig 23-1 and Fig 23-2 are of multiple stacked units
  • Fig 23-3 and Fig 23-4 are an embodiments of the structure with a flat plate 3 (Plate 3C) which reduces the complexity for manufacture.
  • Fig 23-5 is a single stack structure embodiment which may include the Plate 3C with the wider sleep space and steps .
  • Fig 23-6 is a single stack structure embodiment which may include the Plate 3C, and with the contoured seatback to offer more space for the adjoining bed, and upper seat back with an enclosed space for resting the head and for an arm rest.
  • Fig 23-7 shows an embodiment with a laterally contoured seat, contoured on the aisle side for angled sitting and lumbar support, and laterally contoured on the inner side to accommodate structural plate 3C or other structural members.
  • the contoured lower part of the seat provides lumbar support as well.
  • Fig 23-8 shows the lumbar support in a low position. Some embodiments allow the lumbar support to slide along the surface of the seat back and in some embodiments it is inflatable.
  • Fig 23-9 shows the lumbar support in a high position. Some embodiments allow the lumbar support to slide along the surface of the seat back and in some embodiments it is inflatable.
  • FIG. 23-10 Shows the air sleeper architecture with the flat bed housing comprising a cutoff at its end resulting in more space in the high-priority region for the neighboring occupant - in the hip region, while depleting space at the foot and for the passenger using this bed housing.
  • Fig 23-11, 23-12, 23-13, 23-14 refer to AS2 shows a section of the fuselage with the upper deck constructed to optimize vertical space required for both the lower and upper decks.
  • the floor is not flat across but has several levels based on optimal heights for the two decks.
  • the lower deck requires walking height above the two aisles, and requires adequate space for headroom around the seat or air sleeper configurations on the lower deck.
  • the architecture is organized such that the central aisle serves the seats or air sleepers on either side. The sleep space is high enough to allow for the headroom on the lower deck in the center of the cabin where the center passengers do not need substantial headroom particularly in the case of air sleepers which have a lower height requirement in the center.
  • the seat area on the upper deck which also caters for under seat storage with a bin or a drawer.
  • Fig 15, 16 refer to the AS2 AirSleeper showing the structural support for the upper deck with hangers from the top surface of the fuselage wall structure. Some embodiments of these hangers are constructed to be on the aisle side and the inner side of the seat section of each air sleeper and in some embodiments may be connected along the access of the vehicle to increase the rigidity of these hangers when there is an axial load such as the deceleration of the vehicle.
  • Fig 23-17 shows the Defender Internet-based network for vulnerable people.
  • Fig23- 18 shows an emergency mode switch which activates the Emergency Ready state.
  • Fig 23-19 show the Radar feature to notify teams in an emergency alert .
  • Figure 24-01, 02, 03, 04 shows and embodiment of the air sleeper with stairs (24-001) deployed for reaching the upper tier mini suites.
  • double-sided video screens (single-sided screens are another embodiment) that will have in some embodiments different programming on each of the screens for the adult in the mini suite, and for the child on the other side of the screen, and facing in the opposite direction of the adult.
  • Such an embodiment will reduce weight.
  • On the upper tier some embodiments have screen (24-004) supported by the seatback of the mini suite ahead as shown and can be folded to be flush with that seatback.
  • On the lower tier the screen (24-005) may be folded up towards the ceiling or sideways towards either the foot well of the upper tier or the screen of the adjacent mini suite behind.
  • the embodiment shown also includes one embodiment of the latch system for the child seat.
  • the embodiment also shows a foot well for the upper tier mini suite that is contoured to minimize the obstruction of the visual corridor door of the lower tier mini suite along the axis of the flatbed. Such a contour will need to optimize the visual corridor for the lower tier mini suite and the foot space for the upper tier mini suite.
  • the embodiment also shows a contoured adjustable seat (24-003), which in some embodiments is configured to rotate about a vertical axis approximately in the gluteal region of the occupant.
  • Such payment enables the occupant to swivel from facing forwards along the axis of the cabin,-the utilitarian position for egress and ingress, for meal service, and for working on a desktop with computers and other materials - to a position facing forward along the axis of the flatbed, which is considered to be a comfort position-where the occupant can have his/her legs up on the flatbed to either lounge, recline, to watch a movie on the screens, and in the case of the mini suites on the window side, to look out the window.
  • This will arrangement in some embodiments can be locked in the two positions as noted above.
  • Figure 24-05, 06, 07, 08, 09, 11, disclose a embodiment of a single stack of air sleeper mini suites.
  • FIGS. 24-05, 06, 07 show the contoured adjustable seat aligned to the axis of the flatbed so that the occupant is facing the visual corridor right up to the end of the flatbed, and in the case of window mini suites, to look out the window.
  • Figure 24-08, 09, 11 show the upper mini suite contoured adjustable seat aligned to the axis of the corridor i.e. the usually position, and the lower mini suite contoured adjustable seat aligned to the axis of the flatbed.
  • Figures 24-07 and figure 24-08 also show the support structure 24-021, for a child seat in a position above the sleep space of the flatbed.
  • the structure is attached in this embodiment to the shear plates and the lateral support members
  • Figure 24-10 discloses the contoured adjustable seat.
  • Embodiments of the seat have one or more of a headrest is seatback and lumbar support.
  • the disclosed embodiment has a seat bottom (24-012), with a pivot (24-011), and attached to a spine (24-008) wherein the attachment may be a pivotal attachment controlling tilt of the spine relative to the seat bottom.
  • Such an adjustment may be with a servo motor, or a manual lever.
  • a lumbar support (24-010) which in some embodiments has a inflatable feature to increase and decrease the bulk of the lumbar support for the personal preferences of the occupant.
  • inflation may be achieved with a pump that is either a manual bellows pump or a electric pump. Controls of an electric pump may be in the vicinity of the armrest of the contoured seat.
  • the spine has attached to it in this embodiment is seatback (24-009) which again may be adjusted for height by sliding along the spine.
  • Such controls may be manual with levers or with a servo with controls conveniently located in the vicinity of the armrest of the contoured adjustable seat.
  • the headrest (24-007) is attached to the spine, and may be slidably attached to move up and down for the comfort of the occupant controls either manual or electric with a servo, with controls located in a convenient location for the occupant as in the case of the seatback and the lumbar support possibly in the vicinity of a armrest of the occupant.
  • Figure 24-13 shows an embodiment of the contoured adjustable seat where the height controls for one or more of the lumbar support the seatback and headrest are controlled by cables. Such cables may have their controls in the manual case to a convenient location for occupant control. Alternatively, the vertical adjustment movements of the cables could be actuated. A servo motor in the vicinity of the spine and electric controls provided to the occupant for convenient access.
  • Some embodiments of the contoured adjustable seat have the pivot 24-011 on the seat bottom 24-012, to be slidable in the direction of the axis of the vehicle or parallel to the Isle. This will accommodate people of larger or smaller stature to get the table feature at a convenient distance.
  • Such assigning arrangement can be manually or electrically actuated.
  • Some embodiments have multiple positions for locking the seat bottom to the loadbearing members of the structure. Lower part for the occupant will pass through the pivot and sliding mechanism, if the seatbelt is mounted on the contoured adjustable seat, and therefore needs to be designed with such loading in mind.
  • An alternative embodiment would have seatbelt attached to the fixed components of the mini suite with direct load paths of the shear plates and/or lateral support members.
  • Figure 24-12 shows an embodiment which does not use a contoured adjustable seat, but rather uses the cavity as shown, with a special feature of having a leaning surface orthogonal to the axis of the flatbed, to facilitate sitting up and leaning back on such are support service while reclining with feet up on the flatbed.
  • Figure 24-014 and figure 24-015 discloses an embodiment of the flip up stairs.
  • Figure 24-014 shows the stairs deployed.
  • Figure 24-015 shows the stairs partially flipped up for storage.
  • the steps 24-017 are pivotally attached to the support member 24-019 along a horizontal axis.
  • On the other side (the outer side) of the steps is pivotally attached the control lever 24-020. Raising the lever or pulling it towards the support member folds up the stairs.
  • the top end of the control lever is accessible to the occupant in a seated position in the upper tier mini suite.
  • control mechanism including servo operated actuation of the steps, with the burden of additional weight.
  • the stairs are constructed to support the weight of the occupant with one or both of: a tail of the step on the opposite side of the pivot shown protruding into the support member 24-019. In the deployed position the upper surface of the tail contacts the upper surface of an aperture in the support member and thereby provides support for the occupant on the other side of the pivot; a phlange 24-018 which is a part of the support member 24-019 that lies just under the step when deployed, and therefore provides it support when deployed.
  • the spring damper 24-016 is constructed to keep the stairs in the flipped -up position normally, and is used to control the movement of the stairs when deployed.
  • Some embodiments of the spring damper comprise a spring loading which is tensile and foldsup or flips up the steps. Against the force on the lever for deployment or the weight of the occupant the spring is extended. The damper in this embodiment will slow down the rate of closure of the deployed stairs, so that the stairs don’t close in the time interval between steps being taken by the occupant while climbing up.
  • Such a damper mechanism who have multistage properties, where the initial folding by a few degrees is very slow to allow the occupant adequate time between steps in what could be a worse case or slow case situation.
  • Fig 25-01 shows the timelines for recorded media.
  • source 1 streams are represented by S1 t0 to S1 tF , for times t 0 to t F .
  • source 2 streams are represented by S2 t0 to S2 tF .
  • User / viewer 1 begins to capture the stream from source S1 at some time U1 t0 (S1), with the parameters of S1 at that time recorded.
  • the user/viewer 1 continues to view the stream from source S2 until U1 tF (S2), which may be before source S2 terminates streaming.
  • the cryptographic representation of the streams of both S1 and S2 with their digital signatures are created in one embodiment of the invention, and are available for checking the authenticity of copies of these complete video streams.
  • cryptographic representation of the received streams to U 1 of each of the constituent streams from S 1 and S 2 In this embodiment their digital signatures created, for future reference to copies which may be checked by the instant invention for their authenticity.
  • Fig 25-02 shows another embodiment of the invention that modularizes each of the source streams S 1 and S 2, to fixed time length units, and records their cryptographic representation as a digital signature. Therefore, each of the streams have a sequence of digital signatures for each 10 second interval. The time of each interval of 10 seconds is used only as an example, and any suitable timeframe can be used for the units of the modular structure of each of the sources.
  • the plurality of source streams have modules of 10 seconds that are synchronized with the start time of the Source stream and at 10 second intervals thereafter until the end of the Source stream.
  • the beginning and end of each 10 second module coincides for all the streams in the network.
  • the user’s receive the streams from the sources e.g. S1 and S2. Therefore, they receive one or more of the 10 second modules which must have the same cryptographic representation. There may be a short period of less than 10 seconds where the user U 1 for example, is receiving a stream ahead of synchronized beginning of the next streamed 10 second module.
  • the user U1 may terminate his/her reception of the source ahead of the end of the then current 10 second module.
  • digital signatures must be identical to the of the respective sources. Therefore, this embodiment, while it does not capture the digital signatures of the leading few seconds before the first and second module and that of the period Trailing the last 10 second module, has a unique property that the user U 1 stream inputs have the same digital signatures as the sources. Moreover, this is true for a sequence of sources that are streamed by the user U1, when each of the streams have the digital signatures of each of the modules of the plurality of streams.
  • the digital signatures of each of the clips tokenizes the clips as assets that can be traded.
  • the source would be the issuer of the tokens, and they will be registered in the wallet of the source. Thereafter, they are tradable.
  • streaming of the clip to a user could require a payment from the user to the source.
  • smart contracts can use smart contracts to execute the financial transaction at the time the tokenized clip is transferred from the source to the user.
  • the transaction structure – element of Block in Block Chain There are many elements that can be inserted as transactions into each block. These can include the actual times of commencement and end of a stream received by user. They can also include the digital signatures and the identifying source and viewer IDs and the start time of the modules. There can be many of these modules and therefore many of these transactions for a single streaming session.
  • Transaction element examples Source ID Viewer ID Stream Commencement time Stream End Time Stream Digital Signature -Video Source ID Viewer ID Module start time Module Digital Signature -Video Source ID Viewer ID module start time Module Digital Signature -return Voice channel
  • the structure of the video stream may have included in its metadata the location of the source. This will of course be part of the data that will be represented by the cryptographic digital signature.
  • the location information at each point in time may be separately provided as a data point in the transaction structure.
  • Fig 25-03 shows the application in a multi-participant videoconference.
  • each of the sources stream their videos to each of the other parties and each of the streams will be cryptographically signed and available for the users for verification of their recordings.
  • the sources are distinct from the users the same process would apply but there will be fewer interconnections and necessary videos for cryptographic verification.
  • the source streams are maintained as recordings, and pointers on those source recordings at the times of commencement and ending of user access to those recordings are maintained as pointers (See Fig 25-05) .
  • the source recording is split into modules as before in some of the prior embodiments, and each of those modules is hashed to get a digital signature which can serve as a token.
  • the modules will begin at the time of commencement of the source stream, and successive modules will commence at fixed time periods after that commencement.
  • the start time of the source recording is of course recorded, tored e, the time ource ents will split the source recording into two parts, the first being up to the commencement of the first user sharing time, and th i d f th t di hi h i lit i t d l d h h d f i l i i t bl k
  • User he cords such that the modules required to reconstruct any one of the user streams will be known.
  • commencement of the first module of the source was at the time of commencement of the source stream, there may not be in alignment in time of the commencement of any one of the user streams and the start/end of modules.
  • Some embodiments of the system do not have a facility for downloading the streams to the user, but rather allow access to the user for viewing their recordings within the system. Other embodiments, allow the user to download the streams that they have selected and watched. In such embodiments, they will be presented with the modules and their respective hashes, or in other embodiments, users are represented with their entire recordings, with additional information on the commencement of each module, the module duration, and the hashes for each of the modules. This will enable the user to reconstruct precisely the clips that constitute each of the modules and their respective hashes.
  • y stream recording will delay the time when it’s hash can be inserted into a transaction into a block and entered into the block chain
  • a market clearing algorithm will select the best licensee option if licenses are to be restricted. In some embodiments there is no issue of an NFT at all but in traditional fashion, simply provide the asset with an access license.
  • Fig 26-004 video available for viewing and in some embodiments downloading.
  • Some embodiments have watermark on video and have a second priced phase where the user can pay additional fee for downloading the video.
  • the “C” NFT has attributes of the “B” NFT but in addition includes the right to query for block position and verify the asset at that block position.
  • asset saved location as referenced on the block transaction is encrypted and is accessed with private keys and therefore such verification is not available to the public who have access to the block chain information alone.
  • Some of such embodiments may use the private key of one or more custodians of the video network and/ or the private key of the Source that generated the data.
  • the encryption in some embodiments will be with the Source Private key and Network Admin Public key.
  • Video (or image or evidence documents or other asset) are saved in the indelible storage facility such as IPFS. It is assigned a URL ⁇ in the IPFS system. An IPFS CID hash ⁇ is made available for reference to the IPFS URL address for access to the asset such as the video. This hash ⁇ is Encrypted using the Source Private key and the Video Network Public key to create the encrypted CID hash ⁇ encrypted. ⁇ encrypted is on the transaction record. The Video Network Private Key will be needed for decryption later.
  • Meta data such as location, time and other parameters of the record may be included.
  • a Signature for verification of the creating Source of the video or evidence is constructed with the Source Private Key and ⁇ encrypted .
  • the Source Public Key is also made available to the Video Network eg Wiink! .
  • Fig 26-009 shows the information flows when the “C” NFT is purchased.
  • the ⁇ encrypted is decrypted using the Video Network eg Wiink! Private key. This may be in some embodiments be done in a Video Network Server to maintain confidentiality of ⁇ .
  • the Internal Video Network Server queries IPFS to get the Asset such as the video and Serves that content to the User.
  • the Block information is also available to the User as this is public information but in addition it may be curated by the Video Network Server to present in formation in a better format.
  • there is a Signature Verification that can be activated with the Source Public Key that is maintained by the Video Network/Wiink! and made avialbe to the purchaser of the “C” NFT, to verify that the ⁇ encrypted did in fact come from the Source.
  • the time and location in the case of evidence not location but characterizing key words
  • Users can find the information directly on the block chain.
  • Fig 26 – 010 in some embodiments, ZKP (Zero Knowledge proof) techniques well known in the background art are used to demonstrate to the user that the video served up by the Video Network/Wiink! server is in fact the video stored at the address ⁇ in IPFS, and the was derived from the CID ⁇ , which was decrypted from ⁇ encrypted , without revealing ⁇ , or ⁇ to the buyer of the “C” NFT.
  • Some examples of possible ZKP systems are ZK-STARKs and ZK-SNARKS.
  • Fig 26-011 shows additional encryption of the final evidence or video asset that is made available to the “C” NFT purchaser for addition security.
  • the Video Network Server will require the Public key of the “C” NFT purchaser to make this possible.
  • the air sleeper needs egress and ingress for the upper tier occupants.
  • the embodiment shown in figures 23-1 and 23-2 provide such egress and ingress access steps that are positioned under the foot space of the upper tier occupant. There positioned in such a way as to minimize obstruction of egress and ingress of the lower tier occupants.
  • the air sleeper requires bracing with one or more shear planes to provide rigidity to the structure in the event of rapid deceleration of the vehicle. Additional embodiments of such a shear plane, are disclosed namely structural plate 3C.
  • the angled shear plane does not have a section adjoining the lateral tubes, configured to be orthogonal to the lateral tubes. This makes the construction of the structural assembly lower cost and also possibly lower weight.
  • a construction of the structural plate 3C does not intrude into the sleep space of the adjoining bed of the occupant.
  • the embodiment shown include a version of the seat structure that has a contoured lumbar support that also becomes an adaptation that aligns to the plate 3C. Some embodiments by symmetry and for enhancing the lumbar support will have a similar contour on the aisle side of the seat. As may be seen from the figures such an arrangement widens a narrow point in the bed providing greater utility for the occupant in a sleeping position.
  • the lumbar support adaptation of the seat can also provide more space for the occupant behind the seat.
  • the upper part of the seatbacks may be controlled on one or both sides to offer space for armrests and also for head support in the event the occupant wishes to rest with their heads against the side supports. It is particularly useful for setting up aligned to the bed.
  • added lumbar support 23-003 is installing in some embodiments. This not only allows adjustment for people of different height, but also allows a sitting position that is angled to the axis of the aircraft and pointing substantially in the direction of the bed. The back support contour supports the occupant in such positions.
  • AirSleeper2 Fig 23-11, 23-12, 23-13, 23-14 refer to AS2 shows a section of the fuselage with the upper deck constructed to optimize vertical space required for both the lower and upper decks.
  • the flow is not flat across but has several levels based on optimal heights for the two decks.
  • the lower deck requires walking height above the two aisles, and requires adequate space for headroom around the seat or air sleeper configurations on the lower deck.
  • the architecture is organized such that the central aisle serves the seats or air sleepers on either side. The sleep space is high enough to allow for the headroom on the lower deck in the center of the cabin where the center passengers do not need substantial headroom particularly in the case of air sleepers which have a lower height requirement in the center.
  • the seat area on the upper deck which also caters for under seat storage with a bin or a drawer.
  • Fig 23-15, 23-16 refer to the AS2 AirSleeper showing the structural support for the upper deck with hangers from the top surface of the fuselage wall structure.
  • hangers are constructed to be on the aisle side and the inner side of the seat section of each air sleeper and in some embodiments may be connected along the access of the vehicle to increase the rigidity of these hangers when there is an axial load such as the deceleration of the vehicle.
  • the vertical sections of the floor structure of the upper deck will act as shear planes as they are attached to the inner hangers.
  • hangers will have a significant with in the direction of the axis of the vehicle to increase resistance to share loading. This may be an important design consideration considering that the aircraft needs to our certification with a 16 G loading along the axis of the vehicle. Such considerations will supplement the role of the floor as a shear plane to support loading in the axial direction of the vehicle under severe deceleration.
  • the instant invention constructs a network of trusted friends with known geo-locations in real time, that is available in an emergency for the further construction of a team curated in a specific and particular way from the most likely persons to help, chosen in a way specific to this invention, with the additional requirement of being physically within a specific distance of the victim.
  • the invention in some embodiments uses streamed video from the victim’s camera and streamed video from one or more members of the team members indexed by their location and available for viewing by any one of the other team members.
  • Selection of any one of the streamed camera views is by tapping/clicking on the icon for the desired team member’s view in one or both of the current field of view of the team member and a local map with the team members and victim.
  • the positions of icons in the current field of view of a viewing team member provides “the lay of the land” or obstructions, suitable paths etc for the viewer and in addition indexes and shows the icons of the positions of other members of the team who may be selected as well for their fields of view.
  • some embodiments have audio voice channels for conference among the team members to construct collective intelligence both from being able to share the views from any of the team member cameras and benefitting from their pooled insights to track down and apprehend the offender.
  • trust relationships between the trustor and trustee may in some embodiments be directional and in others non-directional.
  • the trustees of any victim are provided information that allows them to make decisions using their own directional trust circle to alert and enable members of their own trust circle located in the vicinity of the victim - the rescuers - to navigate to the location of the victim.
  • the solution in some embodiments has a feature where the rescuers work in a team with the ability to virtually navigate to any one of the camera views of other rescuers, or the victim and place each one of the team in the local 3_D visual environment so that relative locations are easily internalized with one or both of a map and locations in the real environment identifiable by icons which may be selected to move to those points of view
  • This technical solution for the noted problem is constructed as a new technology with an Internet based trust network that indexes the locations of the mobile phones (sources) of participating members to the physical locations of those mobile phones, thereby creating a digital twin of the visual space inhabited by the participating members.
  • SOS notifications are sent to each one i of the members TC 0 (i) of the victim’s trust circle (TC 0 ) such that upon acceptance of the notification by any one of the TC 0 (i) , it enables those members of the victim’s trust circle (TC 0 ) that have accepted the notification (the “Level 0 Team”), to act in a unique and particular way to defend the victim.
  • the network Upon notification to the i th member of TC 0 , referenced here as TC 0 (i), the network offers TC 0 (i) it immediately streams the camera view of the victim and encourages the Level 0 Team Member to search for the victim and notify authorities.
  • that streamed video of the victim includes an overlay with icons on the positions of all the Trust Circle Member of that TC 0 (i), denoted TC 1 , that happen to be in that neighborhood.
  • the TC 0 (i) is enabled to select icons of all those members of his TC 1 in that visual neighborhood seen in the streamed video of the victim.
  • the TC 0 (i) is presented with a supplementary map (that may be a popup map), with a radar feature that identifies all the members of TC 1 within a radar radius that is set for a default value of 500m but can be modified by the TC 0 (i) .
  • the TC 0 (i) views the map, sets the radius of the radar and selects notify and the selected members of the TC 1 are notified.
  • Level 1 Team (i) Those that accept the notification are member of Level 1 Team (i) , from the TC 0 (i)
  • the Level 1 Team (i) members are immediately presented with the camera stream of the victim and in addition on an overlay of that stream, selectable icons of all the other members of Level 1 Team (i) in the locations of each of those Level 1 Team (i) members. These icons upon selection switch to the videos of the camera streams of the selected Level 1 Team (i) member.
  • this selection feature enables each Level 1 Team (i) Member virtually navigate the space and to thereby build a mental 3-D model of the neighborhood by internalizing the camera streams of the victim and the camera streams of the Level 1 Team (i) Members to enhance intelligence of the Level 1 Team (i) for the task of apprehending the offender.
  • Some embodiments have in addition an audio conference feature among the Team Members to allow them to strategize the process of apprehending the offender with the knowledge of the 3-D structure of the environment.
  • Some embodiments have in addition a map of the neighborhood with the selectable icons of the Level 1 Team (i) Members, so that the members have in addition to the mental image of the 3D space from selecting the icons on the visual image overlays, can also get a sense of the map representation of the layout.
  • Some embodiments may integrate all the Level 1 Team (i) teams for all “i” to a single Level 1 Team.
  • the embodiments shown have a first and second TC teams ie Level 0 Team and Level 1 Team (i) .
  • the system can be extended to multiple levels of Trust Circles, where for example the Level 1 Team (i) members are enabled to contact their own Trust Circles and engage their participation with the information infrastructure noted above and iteratively in the higher level teams eg, Level 2 Team (i,j) , Level 3 Team (i,j,k), Level N Team (I, j, k, .7)
  • Level 2 Team (i,j) e.g., Level 3 Team (i,j,k), Level N Team (I, j, k, .
  • Figure 24-01, 02, 03, 04 shows and embodiment of the air sleeper with stairs (24-001) deployed for reaching the upper tier mini suites.
  • double-sided video screens (single-sided screens are another embodiment) that will have in some embodiments different programming on each of the screens for the adult in the mini suite, and for the child on the other side of the screen, and facing in the opposite direction of the adult.
  • Such an embodiment will reduce weight.
  • On the upper tier some embodiments have screen (24-004) supported by the seatback of the mini suite ahead as shown and can be folded to be flush with that seatback.
  • On the lower tier the screen (24-005) may be folded up towards the ceiling or sideways towards either the foot well of the upper tier or the screen of the adjacent mini suite behind.
  • the embodiment shown also includes one embodiment of the latch system for the child seat.
  • the embodiment also shows a foot well for the upper tier mini suite that is contoured to minimize the obstruction of the visual corridor of the lower tier mini suite along the axis of the flatbed. Such a contour will need to optimize the visual corridor for the lower tier mini suite and the foot space for the upper tier mini suite.
  • the embodiment also shows a contoured adjustable seat (24-003), which in some embodiments is configured to rotate about a vertical axis approximately in the gluteal region of the occupant.
  • Such payment enables the occupant to swivel from facing forwards along the axis of the cabin,-the utilitarian position for egress and ingress, for meal service, and for working on a desktop with computers and other materials - to a position facing forward along the axis of the flatbed, which is considered to be a comfort position-where the occupant can have his/her legs up on the flatbed to either lounge, recline, to watch a movie on the screens, and in the case of the mini suites on the window side, to look out the window.
  • This will arrangement in some embodiments can be locked in the two positions as noted above.
  • Figure 24-05, 06, 07, 08, 09, 11, disclose a embodiment of a single stack of air sleeper mini suites.
  • FIGS. 24-05, 06, 07 show the contoured adjustable seat aligned to the axis of the flatbed so that the occupant is facing the visual corridor right up to the end of the flatbed, and in the case of window mini suites, to look out the window.
  • Figure 24-08, 09, 11 show the upper mini suite contoured adjustable seat aligned to the axis of the corridor i.e. the usually position, and the lower mini suite contoured adjustable seat aligned to the axis of the flatbed.
  • Figures 24-07 and figure 24-08 also show the support structure 24-021, for a child seat in a position above the sleep space of the flatbed.
  • the structure is attached in this embodiment to the shear plates and the lateral support members
  • Figure 24-10 discloses the contoured adjustable seat.
  • Embodiments of the seat have one or more of a headrest is seatback and lumbar support.
  • the disclosed embodiment has a seat bottom (24-012), with a pivot (24-011), and attached to a spine (24-008) wherein the attachment may be a pivotal attachment controlling tilt of the spine relative to the seat bottom.
  • Such an adjustment may be with a servo motor, or a manual lever.
  • a lumbar support (24-010) which in some embodiments has a inflatable feature to increase and decrease the bulk of the lumbar support for the personal preferences of the occupant.
  • inflation may be achieved with a pump that is either a manual bellows pump or a electric pump. Controls of an electric pump may be in the vicinity of the armrest of the contoured seat.
  • seatback (24-009) which again may be adjusted for height by sliding along the spine.
  • Such controls may be manual with levers or with a servo with controls conveniently located in the vicinity of the armrest of the contoured adjustable seat.
  • the headrest (24-007) is attached to the spine, and may be slidably attached to move up and down for the comfort of the occupant controls either manual or electric with a servo, with controls located in a convenient location for the occupant as in the case of the seatback and the lumbar support possibly in the vicinity of a armrest of the occupant.
  • Figure 24-13 shows an embodiment of the contoured adjustable seat where the height controls for one or more of the lumbar support the seatback and headrest are controlled by cables. Such cables may have their controls in the manual case to a convenient location for occupant control. Alternatively the vertical adjustment movements of the cables could be actuated. A servo motor in the vicinity of the spine and electric controls provided to the occupant for convenient access.
  • Some embodiments of the contoured adjustable seat have the pivot 24-011 on the seat bottom 24-012, to be slidable in the direction of the axis of the vehicle or parallel to the Isle. This will accommodate people of larger or smaller stature to get the table feature at a convenient distance.
  • Such assigning arrangement can be manually or electrically actuated.
  • Some embodiments have multiple positions for locking the seat bottom to the loadbearing members of the structure. Lower part for the occupant will pass through the pivot and sliding mechanism, if the seatbelt is mounted on the contoured adjustable seat, and therefore needs to be designed with such loading in mind.
  • An alternative embodiment would have seatbelt attached to the fixed components of the mini suite with direct load paths of the shear plates and/or lateral support members.
  • Figure 24-12 shows an embodiment which does not use a contoured adjustable seat, but rather uses the cavity as shown, with a special feature of having a leaning surface orthogonal to the axis of the flatbed, to facilitate sitting up and leaning back on such are support service while reclining with feet up on the flatbed.
  • Figure 24-014 and figure 24-015 discloses an embodiment of the flip up stairs.
  • Figure 24-014 shows the stairs deployed.
  • Figure 24-015 shows the stairs partially flipped up for storage.
  • the steps 24-017 are pivotally attached to the support member 24-019 along a horizontal axis.
  • On the other side (the outer side) of the steps is pivotally attached the control lever 24-020. Raising the lever or pulling it towards the support member folds up the stairs.
  • the top end of the control lever is accessible to the occupant in a seated position in the upper tier mini suite.
  • control mechanism including servo operated actuation of the steps, with the burden of additional weight.
  • the stairs are constructed to support the weight of the occupant with one or both of: a tail of the step on the opposite side of the pivot shown protruding into the support member 24-019. In the deployed position the upper surface of the tail contacts the upper surface of an aperture in the support member and thereby provides support for the occupant on the other side of the pivot; a phlange 24-018 which is a part of the support member 24-019 that lies just under the step when deployed, and therefore provides it support when deployed.
  • the spring damper 24-016 is constructed to keep the stairs in the flipped -up position normally, and is used to control the movement of the stairs when deployed.
  • Some embodiments of the spring damper comprise a spring loading which is tensile and folds up or flips up the steps. Against the force on the lever for deployment or the weight of the occupant the spring is extended. The damper in this embodiment will slow down the rate of closure of the deployed stairs, so that the stairs don’t close in the time interval between steps being taken by the occupant while climbing up.
  • Such a damper mechanism who have multistage properties, where the initial folding by a few degrees is very slow to allow the occupant adequate time between steps in what could be a worse case or slow case situation.
  • the active network of the virtual navigation system may be linked to a block chain network (with nodes) and including the Sources and Users as transactors in the VNS. Therefore, participating Sources and User Members will have their transaction copies on the block chain.
  • the transaction object structure will contain unique identifying information related to segments of the communication from Source to User ( and/or the reverse audio channel if present).
  • the transaction object structure will contain unique identifying information related to segments of the communication from Source to User ( and/or the reverse audio channel if present).
  • a User navigates from one Source to another he/she leaves footprints of the path from one Source to the next.
  • For each Source therefore, there is a start time and location that defines the beginning of the segment from that Source, and an end time and in location that defines the end of the segment from that Source.
  • each of those segments from the Source comprises data and a unique summary representation of the data such as a checksum/hash we characterize the segment.
  • the time duration between start and finish of the segment can be computed.
  • the protocol for communication of each segment will be established at the time of communication (for example in web RTC the SOP exchange establishes the common protocol between Source and User interface communication nodes).
  • the transaction structure in the block chain used to authenticate communications in the VNS may in embodiments contain one of the following sets of information or variations thereof, in addition to the standard elements of transaction objects (eg in Ethereum: Nonsc, to, gasprice, gas limit, v,r,s) : 1. The start time and location, end time and location, checksum/hash of segment between start time and end time, protocol for communication. 2. The start time and location, end time and location, checksum/hash of segment between start time and end time. 3.
  • a Block The end time and location, duration of segment, checksum/hash of segment between start time and end time.
  • One or more of such transactions areincluded in a Block.
  • the systems and units of each of the parameters above must be predefined.
  • An alternative in some embodiments would define transactions with synchronous event capture in fixed periods - say every minute with location and time records and checksums for the period, rather than using the start time and in time with locations.
  • a Source can also be a User, and therefore, record segments for self-consumption with the block chain activated for authentication.
  • Each block of the block chain will include multiple transactions some of which will include the cryptographic signature hash or token that is generated along with the identities of the transactors (in this example the Source and the Viewer) and the time and other relevant parameters as required that define the transaction along with a block number and a nonce. It will also include the hash from the previous block. This data is then hashed to give the hash of the block for use in the next block. See Fig 25-04.
  • Video content (and in some embodiments the audio back channel as well), in some embodiments as hashed/check summed to create a token using a protocol as defined herein, so that the recording of streamed video can be verified with the same process for digital signature creation of the received stream and compared for authenticity.
  • This activation with the BlockChain network can be achieved at the User interface communications node which is a client on the active network with the block chain network, with client commands programmed to instruct activating or deactivating the block chain for the current segment.
  • the blockchain applications for smart contracts may in some embodiments for example be programmed for Ethereum in Solidity with an API for a node.js application and use web3.js libraries to interact with the block chain).
  • Payment for tokens with the use of the block chain for any segment can utilize the standard approaches for payment such as in Ethereum. Users and Sources have wallets and the Blockchain will in some embodiments include financial transactions. Moreover, if there is future value in a segment from a Source, Users may wish to pay a price to receive that segment. This price can be set by the Source. The payment can be made in some embodiments on the block chain network such as Ethereum or Bitcoin. Future value of such segments could vary widely depending on the scarcity or abundance of the segment available from Users that have recorded the segment. If the segment has been authenticated on the block chain the value may be even higher. The availability of Sources in a particular context or location at a particular time (an event) will vary.
  • the reverse voice channel segment from the User to the Source can also be part of the transaction on the block chain if the block chain is activated in some embodiments.
  • text may be used on the screens of the Users interface capturing the reverse channels from Users to the Source.
  • a conventional video conference architecture can be used with a star configuration of connections of bilateral interactions. See Fig 25- 03 where Source(i) and User(i) are interfaces of the same person.
  • a similar architecture can be used for (2 way) telephone calls and teleconferences.
  • a checksum/hash of a composite video transfer may be used to authenticate the bundle of communications, if individual videos are combined and transferred to each of the participants in a star configuration.
  • Such a bundle can also be tokenized for an authentic record of a conference or call.
  • the block chain will constitute multiple transactions and in aggregate these transactions may include multiple segments from Sources to Users in the local space of an event of interest ex-post.
  • the block chain will therefore offer a mechanism for authentication of "truth media" by using multiple perspectives of the available sources.
  • Some embodiments will have smart contracts in the block chain (eg Ethereum) that search for locations in available transactions, identify sets of segments between Sources and Users, identified the Users that own the segments (They may have paid a non- zero price for the segments to the Source), and negotiate with each of the Users (the Source may also be a User) for their Ask price for access to their segment. These will then be combined and presented to the requester who may also be on the block chain as a User. The requester may then choose one or more of the Source segments.
  • Some embodiments will include in the smart contract the redundancy information on every Source segment in the possession of the Users, so that the User may use this information to recognize the redundancy in his/her Ask price.
  • the requester will pay for the "gas" or cost for the smart contract.
  • the use of tokens by users/viewers received from the sources can be in some embodiments a license for viewing but not for further dissemination. This could be stipulated in the smart contracts.
  • the source may then be able to sell multiple copies of the same token/video clip to multiple users. Token/video clips may also be saved by the source and released at a later date as historical record.
  • Fig 25-01 shows the timelines for recorded media.
  • source 1 streams are represented by S1 t0 to S1 tF , for times t 0 to t F .
  • source 2 streams are represented by S2 t0 to S2 tF .
  • User / viewer 1 begins to capture the stream from source S1 at some time U1 t0 (S1), with the parameters of S1 at that time recorded.
  • the user/viewer 1 continues to view the stream from source S2 until U1 tF (S2), which may be before source S2 terminates streaming.
  • the cryptographic representation of the streams of both S1 and S2 with their digital signatures are created in one embodiment of the invention, and are available for checking the authenticity of copies of these complete video streams.
  • cryptographic representation of the received streams to U 1 of each of the constituent streams from S 1 and S 2 In this embodiment their digital signatures created, for future reference to copies which may be checked by the instant invention for their authenticity. In this embodiment there is no possibility of verifying that segments of streams from sources S1, S2 are the same as the streams from these two sources received by user U1.
  • Fig 25-02 shows another embodiment of the invention that modularizes each of the source streams S 1 and S 2, to fixed time length units, and records their cryptographic representation as a digital signature. Therefore, each of the streams have a sequence of digital signatures for each 10 second interval. The time of each interval of 10 seconds is used only as an example, and any suitable timeframe can be used for the units of the modular structure of each of the sources. However, in this embodiment the plurality of source streams have modules of 10 seconds that are synchronous.
  • each 10 second module coincides for all the streams in the network.
  • the user’s receive the streams from the sources e.g. S1 and S2. Therefore, they receive one or more of the 10 second modules which must have the same cryptographic representation. There may be a short period of less than 10 seconds where the user U 1 is receiving a stream ahead of synchronized beginning of the next streamed 10 second module. Moreover, the user U1 may terminate his/her reception of the source ahead of the end of the then current 10 second module. With the exception of these periods both before the commencement of the first complete 10 second module that is received and after the last complete 10 second module until termination of the stream, on the other 10 second module digital signatures must be identical to the of the respective sources.
  • this embodiment while it does not capture the digital signatures of the leading few seconds before the first and second module and that of the period Trailing the last 10 second module, has a unique property that the user U 1 stream inputs have the same digital signatures as the sources. Moreover, this is true for a sequence of sources that are streamed by the user U1, when each of the streams have the digital signatures of each of the modules of the plurality of streams. In this embodiment, it is possible to trace back the digital signatures of the modules received by the user to the digital signatures of those streamed by the source. This is in addition to, these two references being used to verify purported copies of the video streams of the user with the cryptographic digital signatures.
  • the digital signatures of each of the clips tokenizes the clips as assets that can be traded.
  • the source would be the issuer of the tokens, and they will be registered in the wallet of the source. Thereafter, they are tradable.
  • streaming of the clip to a user could require a payment from the user to the source.
  • Such embodiments can use smart contracts to execute the financial transaction at the time the tokenized clip is transferred from the source to the user.
  • a payment could be for what is effectively a license for use by the user, and may restrict further distribution by the user in some embodiments.
  • the transaction structure — element of Block in Block Chain There are many elements that can be inserted as transactions into each block.
  • Transaction element examples Source ID Viewer ID Stream Commencement time Stream End Time Stream Digital Signature -Video Source ID Viewer ID Synchronous start time Module Digital Signature -Video Source ID Viewer ID Synchronous start time Module Digital Signature -return Voice channel
  • the structure of the video stream may have included in its metadata the location of the source. This will of course be part of the data that will be represented by the cryptographic digital signature.
  • the location information at each point in time may be separately provided as a data point in the transaction structure.
  • the related transaction as: Source ID Viewer ID Latitude Longitude Elevation Synchronous start time Module Digital Signature
  • additional information which may be separately inserted into the transaction or made a part of the metadata of the video stream are for example the facing direction of the camera, the field of view and other parameters related to the camera.
  • Fig 25-04 is an embodiment of the Block in the Block chains. Notably there can be many types of transactions of which one is shown.
  • Fig 25-03 shows the application in a multi-participant videoconference.
  • each of the sources stream their videos to each of the other parties and each of the streams will be cryptographically signed and available for the users for verification of their recordings.
  • the sources are distinct from the users the same process would apply but there will be fewer interconnections and necessary videos for cryptographic verification.
  • the source streams are maintained as recordings, and pointers on those source recordings at the times of commencement and ending of user access to those recordings are maintained as pointers (See Fig 25-05) . Therefore, in such embodiments, the source recording is split into modules as before in some of the prior embodiments, and each of those modules is hashed to get a digital signature which can serve as a token.
  • the modules will begin at the time of commencement of the source stream, and successive modules will commence at fixed time periods after that commencement. The start time of the source recording is of course recorded, so that the commencement time of each module is known.
  • Each of the clips are in this embodiment hashed and stored for use in assembling the blocks for subsequent admission to the block chain.
  • the source may not activate the block chain/cryptographic feature.
  • the user is enabled to activate this feature and commence the modularization of the source stream recording from the time of the commencement of the stream to the first user .
  • the entire source recording may be retroactively divided into modules and hashed and stored as separate modules, other embodiments will split the source recording into two parts, the first being up to the commencement of the first user sharing time, and the remainder of the source stream recording which is split into modules and hashed for inclusion into blocks immediately upon the availability.
  • the Source may not even record the stream ahead of the first User request for cryptographic verification.
  • the user commencement time pointer and the ending time pointer are maintained in the records, such that the modules required to reconstruct any one of the user streams will be known.
  • commencement of the first module of the source was at the time of commencement of the source stream, there may not be in alignment in time of the commencement of any one of the user streams and the start/end of modules. Therefore two possible embodiments are possible, where the users stream is augmented to include the sections of the stream that either precede or follow the user stream to bring it in line with the module termination times. In this embodiment, the user will have slightly more information than what was actually transmitted to that user.
  • the module endpoints closes to the start and the end of the users stream, and lying within the user stream are used as the endpoints for the collection of modules representing the users stream, and used for hashing and as input for the blocks in the Block chains.
  • Some embodiments of the system do not have a facility for downloading the streams to the user, but rather allow access to the user for viewing their recordings within the system. Other embodiments, allow the user to download the streams that they have selected and watched. In such embodiments, they will be presented with the modules and their respective hashes, or in other embodiments, users are represented with their entire recordings, with additional information on the commencement of each module, the module duration, and the hashes for each of the modules.
  • each of the segments of the stream provided by the source to each one of the users can be in their entirety be hashed and become tokenized.
  • this is far less efficient as some segments of the source recording will have multiple users but in this instance, each of those instances will need to have a separate hash which is more computationally intensive.
  • the time of availability of the entire user stream recording will delay the time when it’s hash can be inserted into a transaction into a block and entered into the block chain.
  • Source video to authenticate suspect third party video. If the suspect video is from the same source as what is available in the network, the process of verification or authentication would be simply checking the tokens are digital signatures of the available source video clips alongside that of the suspect video. However, the suspect video may be from a different perspective to what is available in the source video clips.
  • the source light fields are created from the source video, to create a parent light fields from all available sources in the neighborhood, and using the elements of the parent light field the perspective of the suspect video can be constructed and checked for authenticity.
  • Some embodiments could use AI techniques from the deconstructed light fields to generate new views or construct the 3D models of the neighborhood as a time sequence as the video progresses.
  • Such 3D models can also be constructed as previously disclosed from a plurality of frames from multiple perspectives i.e. from multiple sources such models can then be used to refute suspect video.
  • the instant invention can be used for a broad range of evidence that was collected at a place and a time or a particular context and the time for future authentication and use.
  • This can be for example a video that was captured at a particular place at a particular time which is authenticated with regard to such attributes. It can also be written evidence that was collected and known at a particular time, and that may be represented by one or more characteristics such as fields, keywords etc., or in fact images which were composed at a particular location and time, or context and time.
  • the preferred embodiment that will be described in detail will be the invention used for video evidence. The same principles are extendable to the other classes of evidence or information in other embodiments.
  • Such authentication is provided in this invention, where the block chain such as Ethereum, is used to embed a transaction at a particular time in a block so that that time is authenticated and unchangeable in the block chain.
  • the preferred embodiment therefore uses video data by a video network.
  • Some embodiments of the video network will have an ownership NFT minted to the wallet of the source of the video.
  • Such videos may be stored by the source for future review. They can also be used by other users on the network for simply viewing the videos with information about location and time of generation of the videos.
  • the third possibility is for users to seek evidence at a particular location and time with her willingness to pay for authentication that the evidence was created at that place and time.
  • Each of these have different kinds of access NFT tokens.
  • Such NFT tokens are priced differently depending on demand. They may be for us fixed prices set by the sources or the video network (Wiink! Or using a bid ask negotiation process to define the clearing price depending on the demand and supply of that particular NFT token where there is a limited supply to be sold.
  • a “B” NFT can be ranted to users that sim l bu a video asset that’s available without an e .
  • a B NFT can be sold to those who buy the video asset license with its metadata, but not the authentication using the block chain.
  • a second payment for a “C” NFT is possible for purchasing the block chain authentication.
  • a first class of embodiments of this invention can have the video /image url ⁇ directly pointed to (usually as a hash ⁇ - in some embodiments the IPFS CID) the IPFS or other indelible storage location.
  • a second more important class of embodiments of the invention will not disclose the evidence/video/image asset location ⁇ or for that matter the IPFS CID ⁇ in the public domain. Instead the encrypted version ⁇ e ncrypted of the representative hash ⁇ of the IPFS location ⁇ of the evidence/video/image asset will be available in the public domain in such a web resource.
  • users will be able to search the block chain for any of the metadata elements, but will not be able to get to the address hash ⁇ of the evidence/video/image asset as that would be encrypted. All that will be available will be the ⁇ encrypted .
  • This class of embodiments offers to the public a characterization of the asset through the block chain, so that they can search for their target assets and if such assets are available, they will know that access is possible through the video network/Wiink! for a price.
  • the decryption process will be where a smart contract or similar process, will take as input the encrypted address hash ⁇ encrypted , from the JSON file characterization (see below), and one or more private keys controlled by the video network (Wiink!), generate the decrypted hash ⁇ , and send this hash that represents the URL in the IPFS system, to retrieve the evidence/video/image asset stored in the IPF system, and disclose to the user the evidence/video/image asset but not its IPSF URL location, or its decrypted hash ⁇ .
  • Such a smart contract or similar process may use in addition in some embodiments, well-known techniques in zero knowledge proof systems (ZKPS) such as ZK-STARK and ZK-SNARK each of which have their own benefits and shortcomings.
  • ZKPS zero knowledge proof systems
  • the key role is to keep the actual address of the asset private.
  • the encrypted representation use of the address can also have a verification signature using the source, for later decryption and verification of source by the user who at the time of purchase of the license NFT, is endowed with the public key of the source.
  • Metadata to varying extents can be added to the transaction.
  • various techniques to create secondary chains well-known in the background are can be employed.
  • the specific transaction information may only be maintained for example in the full nodes.
  • the source public key in some embodiments will be transferred to the network, and maintain in the network for later use.
  • Some embodiments may also have the availability of a signature of the asset represented by hash. This can be a concise representation that can be used for comparison to fake representations of the “same” or similar videos.
  • Fig 26-003 other embodiments may have a ask price quoted and the user is invited to offer a bid price. Here, a market clearing algorithm will select the best licensee option if licenses are to be restricted. In some embodiments there is no issue of an NFT at all but in traditional fashion, simply provide the asset with an access license.
  • the “C” NFT has attributes of the “B” NFT but in addition includes the right to query for block position and verify the asset at that block position.
  • asset saved location as referenced on the block transaction is encrypted and is accessed with private keys and therefore such verification is not available to the public who have access to the block chain information alone.
  • Some of such embodiments may use the private key of one or more custodians of the video network and/ or the private key of the Source that generated the data.
  • the encryption in some embodiments will be with the Source Private key and Network Admin Public key.
  • Video (or image or evidence documents or other asset) are saved in the indelible storage facility such as IPFS. It is assigned a URL ⁇ in the IPFS system. An IPFS CID hash ⁇ is made available for reference to the IPFS URL address for access to the asset such as the video. This hash ⁇ is Encrypted using the Source Private key and the Video Network Public key to create the encrypted CID hash ⁇ encrypted. ⁇ encrypted is on the transaction record. The Video Network Private Key will be needed for decryption later.
  • Meta data such as location, time and other parameters of the record may be included.
  • a Signature for verification of the creating Source of the video or evidence is constructed with the Source Private Key and ⁇ encrypted .
  • the Source Public Key is also made available to the Video Network eg Wiink! .
  • Fig 26-009 shows the information flows when the “C” NFT is purchased.
  • the ⁇ encrypted is decrypted using the Video Network eg Wiink! Private key. This may be in some embodiments be done in a Video Network Server to maintain confidentiality of ⁇ .
  • the Internal Video Network Server queries IPFS to get the Asset such as the video and Serves that content to the User.
  • the Block information is also available to the User as this is public information but in addition it may be curated by the Video Network Server to present in formation in a better format.
  • there is a Signature Verification that can be activated with the Source Public Key that is maintained by the Video Network/Wiink! and made available to the purchaser of the “C” NFT, to verify that the ⁇ encrypted did in fact come from the Source.
  • the time and location in the case of evidence not location but characterizing key words
  • Users can find the information directly on the block chain.
  • ZKP Zero Knowledge proof
  • the present invention provides a structure using the block chain to authenticate evidence.
  • This includes video evidence at specific locations that constitute events and also documentary evidence which may be in specific fields of use but also have creation dates which are embedded in the block chain.
  • visible encrypted hash p encrypted that may be viewed by the user, along with an unseen private key provided by the evidence/video network, resulted in the private and undisclosed URL address to retrieve the disclosed asset that is delivered to the user.
  • Example of JSON file in IPFS storing the information of the video asset (note here there is only the encrypted version of the URL hash available.
  • private keys for encryption can take many forms in other embodiments of the invention. There can be for example multiple private keys controlled by coalitions with in the Video network. The key role is to keep the actual address of the asset private.
  • the encrypted representation use of the address can also have a verification signature using the source, for later decryption and verification of source by the user who at the time of purchase of the license NFT, is endowed with the public key of the source.
  • Metadata to varying extents can be added to the transaction.
  • various techniques to create secondary chains well-known in the background are can be employed.
  • the specific transaction information may only be
  • SUBSTITUTE SHEET (RULE 26) maintained for example in the full nodes.
  • the source public key in some embodiments will be transferred to the network, and maintain in the network for later use.
  • Some embodiments may also have the availability of a signature of the asset represented by hash. This can be a concise representation that can be used for comparison to fake representations of the “same” or similar videos.
  • Fig 26-003 other embodiments may have a ask price quoted and the user is invited to offer a bid price.
  • a market clearing algorithm will select the best licensee option if licenses are to be restricted.
  • Fig 26-004 video available for viewing and in some embodiments downloading. Some embodiments have watermark on video and have a second priced phase where the user can pay additional fee for downloading the video.
  • the “C” NFT has attributes of the “B” NFT but in addition includes the right to query for block position and verify the asset at that block position.
  • asset saved location as referenced on the block transaction is encrypted and is accessed with private keys and therefore such verification is not available to the public who have access to the block chain information alone.
  • Some of such embodiments may use the private key of one or more custodians of the video network and/ or the private key of the Source that generated the data.
  • the encryption in some embodiments will be with the Source Private key and Network Admin Public key.
  • Fig 26-006, 26-007 there is a cost of verification. This can be priced as a single charge per user as a persistent access C NFT, or priced on a per verification basis or repurchase of a “C” NFT as a per use access NFT.
  • Video or image or evidence documents or other asset
  • IPFS indelible storage facility
  • IPFS indelible storage facility
  • It is assigned a URL ⁇ in the IPFS system.
  • An IPFS CID hash p is made available for reference to the IPFS URL address for access to the asset such as the video. This hash p is Encrypted using the Source Private key and the Video Network Public key to create the encrypted CID hash Pencrypted.
  • Pencrypted is on the transaction record.
  • the Video Network Private Key will be needed for decryption later.
  • Meta data such as location, time and other parameters of the record may be included.
  • a Signature for verification of the creating Source of the video or evidence is constructed with the Source Private Key and pencrypted .
  • the Source Public Key is also made available to the Video Network eg Wiink! .
  • Fig 26-009 shows the information flows when the “C” NFT is purchased.
  • the pencrypted is decrypted using the Video Network eg Wiink! Private key. This may be in some embodiments be done in a Video Network Server to maintain confidentiality of p .
  • the Internal Video Network eg Wiink! Private key.
  • SUBSTITUTE SHEET (RULE 26) Server queries IPFS to get the Asset such as the video and Serves that content to the User.
  • the Block information is also available to the User as this is public information but in addition it may be curated by the Video Network Server to present in formation in a better format.
  • Signature Verification that can be activated with the Source Public Key that is maintained by the Video Network/Wiink! and made available to the purchaser of the “C” NFT, to verify that the e ncry P ted did in fact come from the Source.
  • ZKP Zero Knowledge proof
  • Some examples of possible ZKP systems are ZK-STARKs and ZK-SNARKS.
  • Fig 26-011 shows additional encryption of the final evidence or video asset that is made available to the “C” NFT purchaser for addition security.
  • the Video Network Server will require the Public key of the “C” NFT purchaser to make this possible.
  • the present invention presented provides a new paradigm for implementing key safety features comfort and convenience features for occupants in vehicle. It will become apparent that the present invention provides a structure using the block chain to authenticate evidence. This includes video evidence at specific locations that constitute events and also documentary evidence which may be in specific fields of use but also have creation dates which are embedded in the block chain.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Seats For Vehicles (AREA)
  • Alarm Systems (AREA)

Abstract

Agencements pour la sécurité et le confort dans les véhicules et une solution de réseau internet pour la défense des personnes vulnérables dans les situations à risque et la navigation et visualisation virtuelles avec authentification.
PCT/US2023/077499 2019-06-03 2023-10-23 Couchette pneumatique et réseau internet pour la protection communautaire des personnes, la visualisation et la navigation virtuelles et l'authentification des preuves Ceased WO2024091861A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US19/189,201 US20250315901A1 (en) 2019-06-03 2025-04-24 Air sleeper and internet network for community sourced personal protection, virtual visualization and navigation and authenticating evidence

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
US202263418862P 2022-10-24 2022-10-24
US63/418,862 2022-10-24
US202263433468P 2022-12-18 2022-12-18
US63/433,468 2022-12-18
US202363463394P 2023-05-02 2023-05-02
US63/463,394 2023-05-02
US202363464709P 2023-05-08 2023-05-08
US63/464,709 2023-05-08
US202363538267P 2023-09-13 2023-09-13
US63/538,267 2023-09-13
US202363545186P 2023-10-22 2023-10-22
US63/545,186 2023-10-22

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US19/189,201 Continuation-In-Part US20250315901A1 (en) 2019-06-03 2025-04-24 Air sleeper and internet network for community sourced personal protection, virtual visualization and navigation and authenticating evidence

Publications (2)

Publication Number Publication Date
WO2024091861A2 true WO2024091861A2 (fr) 2024-05-02
WO2024091861A3 WO2024091861A3 (fr) 2024-08-02

Family

ID=90831845

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/077499 Ceased WO2024091861A2 (fr) 2019-06-03 2023-10-23 Couchette pneumatique et réseau internet pour la protection communautaire des personnes, la visualisation et la navigation virtuelles et l'authentification des preuves

Country Status (1)

Country Link
WO (1) WO2024091861A2 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6659225B2 (en) * 2001-09-13 2003-12-09 The Boeing Company Stairway for enabling access to an overhead area within a fuselage of an aircraft
US11254433B2 (en) * 2006-12-14 2022-02-22 Arjuna Indraeswaran Rajasingham Occupant supports and virtual visualization and navigation
EP3774484B1 (fr) * 2018-04-04 2023-06-07 Zephyr Aerospace, LLC Configuration de l'ensemble de sièges pour véhicules
WO2022133330A1 (fr) * 2020-12-18 2022-06-23 Strong Force Vcn Portfolio 2019, Llc Gestion de parc de robots et fabrication additive pour réseaux à chaîne de valeurs

Also Published As

Publication number Publication date
WO2024091861A3 (fr) 2024-08-02

Similar Documents

Publication Publication Date Title
AU2019204712B2 (en) Managing sensitive data elements in a blockchain network
US10397785B2 (en) Handheld video visitation
US7256816B2 (en) Systems and processes for scheduling and conducting audio/video communications
CN103178965B (zh) 使用多因素或密钥式分散对数据进行保护的系统和方法
US20030070072A1 (en) System and method of identity and signature and document authentication using a video conference
US20180131870A1 (en) System for publishing digital images
US20080059331A1 (en) Secure interactive digital system for displaying items to a user identified as having permission to access the system
CN111741351B (zh) 一种视频数据处理方法、装置及存储介质
CN106407766A (zh) 安全文件共享方法与系统
WO2014150277A2 (fr) Procédés et systèmes permettant d'aboutir à des transactions sécurisées
US20130100352A1 (en) Distributed video mixing
CN113704831B (zh) 一种参与方无需同时在线的数字签名多方生成方法及系统
US11269404B2 (en) Occupant support
US10921885B2 (en) Occupant supports and virtual visualization and navigation
JP2024022535A (ja) 固有のセキュアなディープリンクを介したビデオ会議ミーティングスロット
US20250315901A1 (en) Air sleeper and internet network for community sourced personal protection, virtual visualization and navigation and authenticating evidence
WO2024091861A2 (fr) Couchette pneumatique et réseau internet pour la protection communautaire des personnes, la visualisation et la navigation virtuelles et l'authentification des preuves
KR20190011226A (ko) 가상현실에 기반한 공연 예매 및 관람 서비스 시스템 및 방법
JP7288022B2 (ja) 画像表示システム、画像表示プログラム、画像表示方法及びサーバ
JP2024022537A (ja) 固有のセキュアなディープリンクを介したビデオ会議ミーティングスロット
KR20230126285A (ko) 다양한 현실과 가상 세계에서의 단일형 건물 거래 운용 방법
KR20230120517A (ko) 메타버스 nft 작품거래시 nft 사전 진품관리 프로세서와 블록체인 거래 서버 서비스제공시스템
Yang et al. Creating Adaptive Views for Group Video Teleconferencing–An Image-Based Approach
US6694332B2 (en) Method and system for electronic search warrants
WO2020257547A1 (fr) Systèmes et procédés de stockage sécurisés

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23883591

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 2023883591

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2023883591

Country of ref document: EP

Effective date: 20250526

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23883591

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 2023883591

Country of ref document: EP

Effective date: 20250526