WO2023205772A1 - Système de registre distribué de gestion et d'emballage de contenu multimédia et son procédé de fonctionnement - Google Patents

Système de registre distribué de gestion et d'emballage de contenu multimédia et son procédé de fonctionnement Download PDF

Info

Publication number
WO2023205772A1
WO2023205772A1 PCT/US2023/066059 US2023066059W WO2023205772A1 WO 2023205772 A1 WO2023205772 A1 WO 2023205772A1 US 2023066059 W US2023066059 W US 2023066059W WO 2023205772 A1 WO2023205772 A1 WO 2023205772A1
Authority
WO
WIPO (PCT)
Prior art keywords
digital
wallet
video
channel
eam
Prior art date
Application number
PCT/US2023/066059
Other languages
English (en)
Inventor
Joseph Ward
Charles Myers
Sam BERGSTROM
Original Assignee
Edge Video B.V.
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 Edge Video B.V. filed Critical Edge Video B.V.
Publication of WO2023205772A1 publication Critical patent/WO2023205772A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241Advertisements
    • G06Q30/0273Determination of fees for advertising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/14Payment architectures specially adapted for billing systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/14Payment architectures specially adapted for billing systems
    • G06Q20/145Payments according to the detected use or quantity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0282Rating or review of business operators or products
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q2220/00Business processing using cryptography

Definitions

  • the present invention relates generally to a multimedia content management and packaging system, media guides, and more particularly, among other things, to a multimedia content management and packaging systems and media guides with distributed ledger (e.g., a blockchain system) capability.
  • distributed ledger e.g., a blockchain system
  • the present invention also relates generally to searching for content objects and other media-related data across one or more multimedia content streams, and more particularly, among other things, a local searchable dictionary.
  • Modem consumer and industrial electronics especially devices with an image and video display capability, such as televisions, projectors, smart phones, and combination devices, are providing increasing levels of functionality to support modem life which require the display of managing multimedia information.
  • the expansion of different display types coupled with larger display format sizes and resolutions require ever larger amounts of information to be stored on digital media to capture images and video recordings.
  • Research and development in the existing technologies can take a myriad of different directions.
  • Image and video display systems have been incorporated in televisions, smart phones, projectors, notebooks, and other portable products. Today, these systems aid users by providing viewing opportunities for available relevant information, such as images, graphics, text, or videos in a variety of conditions. The display of digital images provides invaluable relevant information for the user. [0006] However, displaying multimedia content has become a paramount concern for the consumer. Mobile display systems, fixed display system, and other modem display systems must access ever increasing amounts of multimedia content with limited physical storage and screen spaces. Larger multimedia content can consume more communication bandwidth during transmission, reducing the utility of remote display systems. The sheer volume of available multimedia content decreases the benefit of using the tools.
  • a further issue is that the background art contemplates live indexing, in a centralized manner, video programs and content thereof for later searching .
  • Such an index takes time to update and is generally designed to be exhaustively cumulative with the goal to index all instances of a content object occurrence within a video program and save such indexed data permanently in a centralized server system.
  • the present invention embodiments provide a distributed ledger multimedia content management method.
  • the techniques described herein relate to a distributed ledger multimedia content management method, the method including: associate a publisher digital wallet with a first digital video channel account, the first digital video channel account including a first channel digital wallet of a distributed ledger system; determine a digital currency reserve balance of the first channel digital wallet; determine a periodic pay rate at least based on the digital currency reserve balance; and in response to (i) an operable coupling of a user digital wallet and a video player and (ii) the video player providing at least content of a first digital video channel, credit a stream-to-eam digital currency balance that is associated with the user digital wallet, the credit step based at least on the periodic pay rate and, optionally, a periodically determined activity score of connected digital wallets, the connected digital wallets being operably coupled to a respective video player that is also at least providing the content of the first digital video channel.
  • the techniques described herein relate to a method further including operably coupling, in response to a digital wallet transaction, a digital video channel manager with the publisher digital wallet.
  • the techniques described herein relate to a method, further including receiving, by the digital video channel manager, a first channel account creation request, with the associating step including providing, by the digital video channel manager and in response to the first channel account creation request during the operably coupling step, a wallet address of the first channel digital wallet.
  • the techniques described herein relate to a method, further including providing, by the digital video channel manager and in response to the first channel account creation request, a stream-to-eam code sippet for operably coupling the video player with a stream-to-eam server.
  • the techniques described herein relate to a method, with the providing the stream-to-eam code snippet step including providing a Uniform Resource Locator to a stream-to-eam application of the stream-to-eam server.
  • the techniques described herein relate to a method, with the providing the stream-to-eam code snippet step including providing a Uniform Resource Locator to a stream-to-eam application of the stream-to-eam server and the wallet address.
  • the credit step including credit, by the stream-to-eam server, the stream-to-eam digital currency balance that is associated with the user digital wallet.
  • the techniques described herein further include periodically sending, by the stream-to-eam server, the stream-to-eam digital currency balance to the video player.
  • the techniques described herein relate to a method, with the credit step including periodically crediting the stream-to-eam digital currency balance in response to (i) the operable coupling of a user digital wallet and a video player and (ii) the video player at least providing the content of the first digital video channel.
  • the techniques described herein relate to the method of any of the above claims, further including transferring, via a distributed ledger transaction, the credited stream-to-eam digital currency balance from the first channel digital wallet to the user digital wallet.
  • the techniques described herein relate to the method of any of the above claims with the credit step further including crediting the stream- to-eam digital currency balanced based at least on the periodic pay rate and the periodically determined activity score.
  • the techniques described herein relate to a method with the crediting step including calculate the periodically determined activity score based at least on one or more of a muted playback state of the video player, an unmuted playback state of the video player, a foreground presentation of the video player, a background presentation of the video player, a notification subscribe action, a content object identification correction, a content objection identification tagging, a content object identification confirmation, a wallet balance, and a character-recognition confirmed content object identification.
  • the techniques described herein relate to any one of the above implementations or the first aspect, and further includes receiving, by the first channel digital wallet, a digital currency.
  • the techniques described herein relate to a method further including re-determining, in response to receiving the digital currency, the periodic pay rate based on the digital currency reserve balance.
  • the techniques described herein relate to any one of the above implementations or the first aspect, further including associating a first network domain with the first channel digital wallet, and in response to (i) the operable coupling of the user digital wallet to the video player, (ii) the operable coupling of the video player to the first network domain, and (iii) the video player at least providing content of the first digital video channel of the first streaming domain, credit the stream-to-eam digital currency balance that is associated with the user digital wallet, the credit step based at least on the periodic pay rate and, optionally, the periodically determined activity score of the connected digital wallets, the connected digital wallets being operably coupled to the respective video player that is also at least providing the content of the first digital video channel of the first network domain.
  • the techniques described herein relate to a method, with the associating the first network domain step including associating a first network domain name of the first network domain with the first channel digital wallet.
  • the techniques described herein relate to a method with the associating the first network domain name step including receiving the first network domain name.
  • the techniques described herein relate to any one of the above implementations or the first aspect, with the operably coupling the publisher digital wallet step including operably coupling the publisher digital wallet of a first blockchain with the first digital video channel account, the first digital video channel account associated with the first channel digital wallet of the first blockchain, with the determine the digital currency reserve balance including determining a reserve cryptocurrency balance of the first channel digital wallet, with the determine the periodic pay rate step including determining the periodic pay rate based at least on a reserve cryptocurrency balance, and with the credit the stream-to-eam digital currency balance step including credit a stream-to-eam cryptocurrency balance that is associated with the user digital wallet, the credit step based at least on the periodic pay rate and, optionally, the periodically determined activity score of the connected digital wallets.
  • the techniques described herein relate to any one of the above implementations or the first aspect and further include selecting a target reserve balance for the first channel digital wallet, the target reserve balance being a fraction of the digital currency reserve balance, and the determine the periodic pay rate including determine the periodic pay rate based at least on the target reserve balance.
  • the techniques described herein relate to a method of operating a distributed ledger multimedia content management system, the method including: associate, by a server, a publisher digital wallet with a first digital video channel account, the first digital video channel account including a first channel digital wallet of a distributed ledger system; determine, by the server, a digital currency reserve balance of the first channel digital wallet; determine, by the server, a periodic pay rate at least based on the digital currency reserve balance; and in response to (i) an operable coupling of a user digital wallet and a video player and (ii) the video player at least providing content of a first digital video channel, credit, by the server, a stream-to-eam digital currency balance that is associated with the user digital wallet, the credit step based at least on the periodic pay rate and, optionally, a periodically determined activity score of connected digital wallets, the connected digital wallets being operably coupled to a respective video player that is also at least providing the content of the first digital video channel.
  • the techniques described herein relate to a system including: at least one processor; and a memory storing instructions that cause the at least one processor to perform a distributed ledger multimedia content management method, the method including: associate a publisher digital wallet with a first digital video channel account, the first digital video channel account including a first channel digital wallet of a distributed ledger system; determine a first digital currency reserve balance of the first channel digital wallet; determine a periodic pay rate based on the determined digital currency reserve balance; and in response to (i) an operable coupling of a user- viewer digital wallet and a video player and (ii) the video player at least displaying video content of a first digital video channel, credit a stream-to-eam digital currency balance that is associated with the user- viewer digital wallet, the credit step based at least on the periodic pay rate and, optionally, a periodically determined activity score of connected digital wallets, the connected digital wallets being operably coupled to a respective video player that is also at least providing the content of the first digital video channel
  • the techniques described herein relate to a non- transitory computer-readable medium containing computer executable instructions that, when executed by a processor, cause the processor to perform a distributed ledger multimedia content management method, the method including: associate a publisher digital wallet with a first digital video channel account, the first digital video channel account including a first channel digital wallet of a distributed ledger system; determine a digital currency reserve balance of the first channel digital wallet; determine aperiodic pay rate based on the digital currency reserve balance; and in response to (i) an operable coupling of a user digital wallet and a video player and (ii) the video player at least providing content of a first digital video channel, credit a stream-to-eam digital currency balance that is associated with the user digital wallet, the credit step based at least on the periodic pay rate and, optionally, a periodically determined activity score of connected digital wallets, the connected digital wallets being operably coupled to a respective video player that is also at least providing the content of the first digital video channel.
  • the techniques described herein relate to a blockchain multimedia management method, the method including: calculate, for at least a first time period, a wallet-specific activity score for a respective digital wallet that is operably coupled to a respective video player that is at least providing content of a first digital video channel, thereby providing respective wallet-specific activity scores for respective operably coupled digital wallets; determine, for at least the first time period, a total wallet activity score of the respective operably coupled digital wallets based at least on the respective wallet-specific activity scores; and credit, for each of the respective operably coupled digital wallets, a respective stream-to-eam digital currency balance based at least on the total wallet active score, the wallet-specific activity score, and a periodic pay rate of the first digital video channel.
  • the techniques described herein relate to a method with the calculate step including periodically calculating the wallet-specific activity score, the determine step including periodically determining the total wallet activity score, and the credit step including periodically crediting the respective stream-to-eam digital currency balance.
  • the techniques described herein relate to a method further including transfer, to each of the respectively operably coupled digital wallets, the respective stream-to-earn digital currency balance.
  • the techniques described herein relate to a blockchain multimedia management method, the method including: calculate, for at least a first time period, a wallet-specific activity score for a respective digital wallet that is operably coupled to a respective multimedia player that is at least providing content of a first video channel, thereby providing respective wallet-specific activity scores for respective operably coupled digital wallets; determine, for at least the first time period, a total wallet activity score of the respective operably coupled digital wallets based at least on the respective wallet-specific activity scores; and credit, for each of the respective operably coupled digital wallets, a respective watch-to-eam digital currency balance based at least on the total wallet active score, the wallet-specific activity score, and a periodic pay rate of the first video channel.
  • the techniques described herein relate to a blockchain multimedia management method, the method including: calculate, for at least a first time period, a wallet-specific activity score for a respective digital wallet that is operably coupled to a respective audio player that is at least providing content of a first audio channel, thereby providing respective wallet-specific activity scores for respective operably coupled digital wallets; determine, for at least the first time period, a total wallet activity score of the respective operably coupled digital wallets based at least on the respective wallet-specific activity scores; and credit, for each of the respective operably coupled digital wallets, a respective stream-to-eam digital currency balance based at least on the total wallet active score, the wallet-specific activity score, and a periodic pay rate of the first audio channel.
  • a method for providing a plurality of watch-to-eam channels includes: determining a watch-to-eam rate for each of a plurality of watch- to-eam channels based at least on one of each digital wallet channel balance of the plurality of watch-to-eam channels and a number of user digital wallets that are operably coupled to each of the plurality of watch-to-eam channels; and displaying, by a video player, the plurality of watch- to-eam channels, the displaying step including periodically arranging the plurality of watch-to- eam channels based on a relative ranking of the watch-to-eam rate for each of the plurality of watch-to-eam channels.
  • the watch-to-eam rate is a periodic pay rate.
  • a method of operation of a multimedia guide system includes: determining, by the system, respective periodic pay rates of channel digital wallets based on a respective digital currency reserve balance; obtaining, by the system, a respective number of connected digital wallets being operably coupled to a respective video player that is providing content of channels associated with the channel digital wallets; calculating, by the system, a respective channel pay rate for each of the channels based at least on the respective periodic pay rates and the respective number of connected digital wallets, thereby providing a basis for ranking each of the channels by relative channel pay rates; and displaying at least a subset of channels according to the calculating step, with the displaying step including animating, by the system and in response to a change in a relative channel pay rate ranking, the change in ranking order in at least the subset of channels.
  • the techniques described herein relate to a system including: at least one processor; and a memory storing instructions that cause the at least one processor to perform any method of the above aspects.
  • the techniques described herein relate to a non- transitory computer-readable medium containing computer executable instructions that, when executed by a processor, cause the processor to perform any method of the above aspects.
  • a method for providing a search dictionary for streaming video programs includes receiving, by a media player, at least one streaming video program of the streaming video programs; obtaining, by the media player and during the receiving the at least one streaming video step, content object data that is associated with content objects of the streaming video programs, the content object data including a content object ID that indicates an identified content object and a timestamp that indicates an identification time of the identified content object; buffering, by the media player, the at least one streaming video program; and updating, by the media player and during the buffering step, a local searchable dictionary with the content object data, the updating step including adding at least the content object ID and the timestamp as a dictionary entry to the local searchable dictionary.
  • the updating step further includes removing, from the local searchable dictionary, the content object data based at least on the timestamp and a buffered video segment ID of the at least one streaming video program that resides in a local buffer memory of the media player.
  • the buffered video segment ID including at least one of a video segment sequential number, a video segment timestamp, and a video segment timecode.
  • the method further includes receiving, by the media player, a video streaming manifest that includes the buffered video segment ID.
  • the video streaming manifest includes at least one of an HTTP Live Streaming manifest that includes the buffered video segment ID and an MPEG-DASH (Dynamic Adaptive Streaming over HTTP) manifest that includes the buffered video segment ID.
  • the method further including obtaining further content object data including the content object ID and a further timestamp that indicates a later identification time than the identification time, and with the updating step further including modifying, in the local searchable dictionary, the dictionary entry based at least on the further timestamp.
  • the obtaining step includes at least one of receiving, by the media player, the content object data and identifying, by the media player and via video content analysis, the identified content objects.
  • the content object data includes a streaming channel ID, the content object ID, and the timestamp and the adding step including adding, by the media player and dunng the buffering step, at least the streaming channel ID, the content object ID, and the timestamp as the dictionary entry to the local searchable dictionary.
  • the method further includes providing, by the media player, a search GUI; receiving, by the media player and via the search GUI, a search query for the local searchable dictionary; and displaying, by the media player and via the search GUI, a search result list that selectively displays at least one of the content object ID, a channel ID, and a video program ID.
  • the method further includes providing, by the media player and in response to a user selection via the search GUI of a result from the search result list, a matching streaming video program of the streaming video programs that includes at least one of the identified content objects, the channel ID, and the video program ID.
  • the providing step includes providing, by the media player and in response to the user selection via the search GUI of a content object result from the search result list, a matching streaming video program portion based on a timestamp entry of the local searchable dictionary that is associated with the content object result.
  • the providing step includes providing, by the media player and in response to the user selection via the search GUI of a content object result from the search result list, the matching streaming video program starting from a time value of the timestamp entry of the local searchable dictionary that is associated with the content object result.
  • the updating step is implemented in real time or near real-time.
  • the content object data includes a personality ID as the content object ID
  • the obtaining step including obtaining, by the mediaplayer and during the receiving the at least one streaming video step, media personality data that is associated with media personalities shown in the streaming video programs, the media personality data including the personality ID that indicates a media-exposed personality and the timestamp that indicates an identification time of the media-exposed personality
  • the updating step including updating, by the media player and during the buffering step, the local searchable dictionary with the media personality data, the updating step including adding at least the personality ID and the timestamp as the dictionary entry to the local searchable dictionary.
  • the personality ID includes a personality character string.
  • the personality ID includes a personality name.
  • the media personality data includes the personality ID that indicates the media-exposed personality and the timestamp that indicates a facial identification time of the media-exposed personality.
  • a method for providing a search dictionary for content objects of real-time streaming video programs includes: receiving, by a server, each real-time streaming video program of the real-time streaming video programs; applying, by the server and during the receiving step, video content analysis to each real-time streaming video program, thereby providing identified content objects of the real-time streaming video programs; transmitting, by the server and during the receiving and applying steps, content object data that is associated with the identified content objects, the content object data including a content object ID and timestamp that indicates an identification time; receiving, by a user equipment operably coupled to the server, the content object data; and updating, by the user equipment, a local searchable dictionary with the content object data, the updating step including adding at least the content object ID and the timestamp as a dictionary entry to the local searchable dictionary.
  • FIGs. 1.1 and 1.2 are block diagrams of distributed ledger multimedia content management systems.
  • FIG. 2 shows a distributed ledger multimedia content management method.
  • FIGs. 3 to 12 show a blockchain multimedia content management examples.
  • FIG. 13 shows a periodic activity score table.
  • FIG. 14 shows a blockchain stream-to-eam method.
  • FIG. 15 is a schematic diagram of a blockchain stream-to-eam session.
  • FIGs. 16 to 23 show blockchain media guide presentations related to user wallet activities.
  • FIGs. 24. 1 and 24.2 are block diagrams of a live search system.
  • FIG. 25 shows a method for providing a search dictionary for a streaming video program.
  • FIG. 26 shows a live searchable streaming session.
  • FIGs. 27 to 31 show media guide presentation related to live searching.
  • FIG. 32 shows an example of locally searchable dictionary entries.
  • FIGs. 33 and 34 show live search method embodiments.
  • FIGs. 35 to 37 show media guide presentation related to watch-to-eam.
  • image is defined as a pictorial representation of an obj ect.
  • An image can include a two-dimensional image, three-dimensional image, video frame, a calculated file representation, an image from a camera, a video frame, or a combination thereof.
  • the image can be a machine-readable digital file, a physical photograph, a digital photograph, a motion picture frame, a video frame, an x-ray image, a scanned image, or a combination thereof.
  • the image can be formed by pixels arranged in a rectangular array.
  • the image can include an x-axis along the direction of the rows and a y-axis along the direction of the columns.
  • the term “content” and “content object” are defined as a media object.
  • Content can include video, images, audio, text, graphics, a social feed, RSS data, news, other digital information, or a combination thereof.
  • multimedia content is defined as a media object that can include multiple types of media.
  • the multimedia content can include video and audio, video with graphics, graphics with audio, text with audio, a social feed, RSS data, news, other digital information, or a similar combination.
  • the horizontal direction is the direction parallel to the x-axis of an image.
  • the vertical direction is the direction parallel to the y-axis of an image.
  • the diagonal direction is the direction non-parallel to the x-axis and non-parallel to the y-axis.
  • module can include software, hardware, or a combination thereof.
  • the software can be machine code, firmware, embedded code, and application software.
  • the hardware can be circuitry, processor, a graphical processing unit, digital signal processor, calculator, integrated circuit, integrated circuit cores, or a combination thereof.
  • digital asset may refer to a blockchain asset such as a cryptocurrency or other blockchain currency, non-fungible tokens, and other unique or limited-edition digital assets that may be transferred and associated with a wallet.
  • Wallet refers to a digital wallet or digital wallet application interface. Digital wallets may include hardware and software implementations or combinations thereof (e.g., a Metamask® application as an interface between a web3 application and a hardware wallet).
  • Digital wallet transaction and “wallet transaction” may include a signed blockchain transaction that identifies and/or verifies a wallet. A wallet transaction may be signed by the private key associated with the sending wallet address.
  • a unique digital asset may have a unique ID to represent a particular digital asset.
  • a unique digital asset may also be unique in the sense that a unique ID of said digital asset represents a (unique) class of assets (e g., a particular set of functional NFTs) and may offer semi-fungibility.
  • Video content analysis includes the capability of automatically analyzing video to detect and determine temporal and spatial events via one or more algorithms.
  • Example VCA techniques include object detection, segmentation, face recognition, and alphanumeric recognition of digital images and/or videos (e.g., character recognition).
  • Object detection detects, in digital images and/or videos, instances of semantic objects of a certain class (e.g., humans, buildings, or cars). Facial identification and detection are particular examples of VCA.
  • Audio object detection include audio analysis tools like Shazaam®, which can detect and identify songs and provide related data such as artist, group, and the like.
  • Live and video-on-demand (VOD) streams are provided in segments via a sequence of small chunks or segments (e.g., of seconds or shorter in length).
  • a file called a manifest file or playlist file, is used to specify information of available streams and variant bitrates for the item of streaming content, and may also specify the Hypertext Transfer Protocol (HTTP) locations of the segments, particularly for live streaming.
  • Example protocols include is HTTP Live Streaming (HLS) and Moving Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HTTP (MPEG-DASH). Both protocols are used to deliver live video streams via unicast to a multitude of client devices over Internet Protocol (IP) networks. Both encapsulate video, audio, closed-captions, trick-play streams, and metadata associated with a video channel into media containers that typically are delivered to client devices over HTTP unicast, although embodiments also include peer-to-peer network architectures.
  • IP Internet Protocol
  • live stream includes live events (e.g., the concurrent capture, encoding, and streaming of live events) and previously recorded video streams that are transmitted to and/or by a plurality of user devices such that each device, within a latency window, is receiving and playing the same segments at approximately the same time as other user devices.
  • live events e.g., the concurrent capture, encoding, and streaming of live events
  • previously recorded video streams that are transmitted to and/or by a plurality of user devices such that each device, within a latency window, is receiving and playing the same segments at approximately the same time as other user devices.
  • real-time streaming includes concurrent transmission.
  • Concurrent transmission may include a content delivery network of servers transmitting to user device and/or an application- defined network of nodes that both receive and transmit a streaming video program.
  • “Local buffer” may include physical and/or virtual memory that contains buffered multimedia data, including multimedia data that is received before playback and kept after playback by a media player. Examples include a memory operably coupled to a video decoder and cache memory.
  • FIGs. 1.1 and 1.2 are block diagrams of distributed ledger multimedia content management system 100.
  • Example distributed ledger networks 119 include blockchain implementations and associated (1) native digital assets such as, for example, Ethereum (Ether or ETH), Fantom (FTM), and Polygon (MATIC), and (2) smart contracts 118.
  • Ethereum Ethereum
  • FTM Fantom
  • MATIC Polygon
  • System 100 may include a publisher digital wallet 1 2 and user digital wallet 108, either of which may be a software wallet (e.g., a Metamask® app operable with a browser module), a hardware wallet (e.g., a Ledger® Nano or Trezor® wallet), or a combination thereof (e.g., a hardware wallet confirming a transaction initiated via a web browser wallet application).
  • a software wallet e.g., a Metamask® app operable with a browser module
  • a hardware wallet e.g., a Ledger® Nano or Trezor® wallet
  • a combination thereof e.g., a hardware wallet confirming a transaction initiated via a web browser wallet application.
  • channel manager module 104 via publisher account 105, may manage digital asset transfers between a channel wallet such as first, second, and N-channel wallets 110, 112, and 114. That is, a channel-specific wallet (e.g., wallets 110, 112, and 114) may be funded for awarding one or more activities associated with user digital wallet 108 (e.g., streaming and other X-to-Eam wallet activities).
  • user digital wallet 108 accumulates rewards off-chain and rewards are periodically updated on-chain via a blockchain transaction from a publisher’s channel wallet to a user digital wallet.
  • both an individual and global or channel activity scores for user digital wallets 108 may be determined and said user digital wallets 108 are credited with a digital asset (e.g., a cryptocurrency or non-fungible token) based on a user wallet’s respective individual active score.
  • a digital asset e.g., a cryptocurrency or non-fungible token
  • the individual activity score is normalized or otherwise adjusted by an activity score of the whole channel, such as the channel activity score sum of the individual wallet scores of wallets 108 that are coupled to a video player 116 that is streaming at least a particular channel.
  • channels are organized by one or more network domains from which streaming content (e.g., audio, video, and/or multimedia content) may originate or otherwise stream, unicast, broadcast, and/or transmit from.
  • a user digital wallet 108 may accumulate further credits off chain that are eventually transferred, on chain, from, for example, first channel wallet 110 to user digital wallet 108 for activities of a user (e.g., streaming, tagging, muting, un-muting) via the video player 116 and/or audio player 117 that is operably coupled to the user digital wallet 108.
  • Video player 116 and/or audio player 117 can be user equipment (e.g., smartphone, laptop), streaming device, video game counsel, radio player, and/or a satellite radio player.
  • an operable coupling includes connecting a wallet via a log-in or sign-in step/transaction for providing and/or confirming the wallet address that will be credited via an X-to-eam paradigm such as interact-to-eam, tag-to-eam, watch-to-eam, and/or listen-to-eam, among other examples provided herein.
  • Interact-to-eam, watch-to-eam, and/or listen-to-eam may also be applied to satellite or over-the-air analog or digital audio and video channels being played on a media player (e.g., user equipment, a television, a radio player) that is operably coupled to a user digital wallet.
  • a media player e.g., user equipment, a television, a radio player
  • X-to-Eam module 107 may interact with smart contract 1 18 (e.g., an application that is operable within distributed ledger network 119) for initiating daily or other periodically timed transfers of off-chain credited balances from channel wallets 110, 112, and 114 to user digital wallet(s) 108.
  • smart contract 1 18 e.g., an application that is operable within distributed ledger network 119
  • Browser module 106 may include a web browser (also referred to as an Internet browser or simply a browser), which is an application software for accessing the World Wide Web or a local website.
  • a web browser also referred to as an Internet browser or simply a browser
  • the web browser retrieves the necessary content from a web server and then displays the page on the user’s device.
  • video player 116 and/or audio player 117 may be browser applications.
  • server 103 may include channel manager module 104 and X-to- Eam module 107.
  • Module 104 may include functions such as channel editor 120, digital wallet generator 122, and period rewards calculator 124.
  • Module 107 may include functions and/or data structures such as determining a stream-to-eam (S2E) channel activity score 126, a S2E period interval 128, a S2E wallet activity score 130, initiating a S2E credit transfer 134, determining a S2E wallet ranking 136, managing S2E channel wallets 138, and/or calculating, transmitting, and/or updating a S2E channel wallet credit balance 140 associated with a user wallet.
  • S2E stream-to-eam
  • channel editor 120 may allow access, via a publisher digital wallet 102, to one or more channels.
  • Digital wallet generator 122 may, in response to a channel creation request, as shown in FIGs. 3 and 4, generate a unique digital wallet address for a particular channel such as a channel wallet.
  • Periodic rewards calculator 124 may determining a periodic pay rate based on a digital currency (reserve) balance of the channel wallet. For example, calculator 124 may determine a daily amount to be paid to user wallets over a 24-hour period. Said amount or daily rate may be based on a “balance target” after a weekly or monthly time period. In one example, a channel wallet balance of 60 ETH would result in a daily rate of 1 ETH such that, after 30 days and assuming no further transfers to the channel wallet, half of the channel balance remains (i.e., a reserve balance of 30 ETH).
  • the daily rate is adjusted in response to transfers increasing a channel wallet’s balance and/or a weekly or monthly scheduled time.
  • the channel wallet with a reduced 30 ETH balance may, at the 1st of the next month, have its daily pay rate adjusted to 0.5 ETH for a balance target of 15 ETH (i.e., the default daily pay rate may be based on a balance target of 50% of the channel balance at the time the daily pay rate is recalculated).
  • S2E channel activity score 126 may be determined by summing the activity scores of individual wallets coupled to a player that is streaming or otherwise playing media of a particular channel. In some embodiments, score 126 is updated multiple times in a day and/or hour, such as a rate of once per minute, which may be altered by adjusting S2E period interval 128 to shorter or longer periods (e.g., adding scores every 1 minute to 1 hour). S2E wallet activity score 130 may calculate and/or receive a user wallet activity score for every time period, as set by interval 128.
  • S2E credit transfer 134 may initiate transfers that reflect accumulated credit balances of a S2E channel wallet credit balance 140, which generally accumulates as a user is watching and/or listing to a program of a channel while the user digital wallet 108 is coupled to a media player. Transfer 134 may occur on a daily, weekly, hourly, or some other basis and thereby re-setting or otherwise reducing (off-chain) balance 140 and increasing the on-cham balance of the user digital wallet 108.
  • S2E wallet ranking 136 may calculate and/or provide activity score rankings of user wallets 108 on a per channel basis, a global basis, or both, among other examples.
  • S2E channel wallets 138 may receive and/or manage wallet addresses.
  • wallets 138 may include a list of wallets that are blocked from X-to-Eam for particular channels or on a global basis. Other examples may include a minimum watch time before X-to-Eam rewards may accrue and/or be credited to a user wallet. In some examples, wallets 138 only requires receiving a wallet address from a connection operation, a log-in, or other operable coupling transaction to earn X-to-Eam eligibility.
  • a user wallet may only be eligible for X-to-Eam for a single channel at a time, at least for certain activities (e.g., a particular user wallet cannot be credited EAT from two different channel wallets at the same time for all or a sub-plurality of the activities shown in table 1300 of FIG. 13).
  • FIG. 2 shows distributed ledger multimedia content management method 200, which may begin with operably coupling a publisher digital wallet with a digital video channel manager at step 202.
  • An operable coupling may require a wallet signature transaction or other confirmation that verifies the publisher digital wallet.
  • a wallet may further incorporate a two-factor authentication application for further security.
  • An operable coupling may occur, for example, to directly couple publisher wallet 102 with channel manager module 104.
  • step 202 includes module 104 operable coupling with browser module 106 or an application thereof (e.g., a Metamask software wallet application operable with module 106 and coupled to wallet 108).
  • a channel manager may associate the publisher digital wallet with a first digital video channel account, the first digital video channel account including a first channel digital wallet, as shown in FIGs. 3 to 5.
  • Step 204 may include the cryptographic steps for generating a digital wallet address in response to a request, confirmation, and/or other message.
  • a channel manager may associate a first network domain with at least one of the first digital video account and the first channel digital wallet.
  • content that is originating (e.g., streaming) or otherwise associated with this domain will be eligible content for a user wallet to earn from a channel wallet.
  • a channel manager may determine a digital currency reserve balance of the first channel digital wallet.
  • a channel manager may determine a periodic pay rate bast at least on the digital currency reserve balance.
  • step 210 may have, for example, a monthly reserve balance target such that a predetermined fraction of the reserve is spent (e.g., 10 to 90% of wallet’s reserve balance).
  • Step 210 may recalculate the periodic pay rate every day, week, or month and/or in response to receiving digital currency, thereby increasing the digital currency reserve balance.
  • Step 212 includes crediting a stream-to-eam digital currency balance that is associated with a user digital wallet based at least on the periodic pay rate and, optionally, a periodically determined score of user digital wallets. Step 212 may occur every minute or other time period length.
  • the daily budget may be credited to user wallets 1,440 times a day for crediting each minute.
  • each user wallet receives an equal share per period.
  • a user can interact with various audio or video player functionalities to increase a periodically calculated activity score.
  • a total activity score is calculated for each interval, and a user wallet is credited a proportioned share of that interval’s budget with respect to the total activity score for that program or channel.
  • FIGs. 3 to 12 show a blockchain multimedia content management examples and particularly a workflow of channel manager guide 301, which may include channel manager presentation 300, address bar 302, cursor 304, ADD CHANNEL icon 306, publisher wallet area 308. If a publisher clicks on icon 306, text-entry' box 402 (e.g., a pop-up window) may appear in response, as shown in FIG. 4. Box 402 includes text-entry area 404 to enter a name of the channel to be published. In some embodiments, the default channel name is a digital wallet address. After cursor 304 clicks “OK”, channel table 502 is provided, as shown in FIG. 5.
  • Table 502 may have columns for a channel name, associated network domain(s), associated wallet address(es), reserve balance (given in EDGE Activity Token or EAT), number of live viewers, number of viewers over a 24-hour period, periodic reward rate (e.g., 24-hour rewards), channel wallet deposit icon 504, and a get code snippet icon 506.
  • Cursor 304 may click on network domain edit icon 508 and text-entry box 602 may appear in response, as shown in FIG. 6.
  • a publisher may enter a network domain name in area 404, which may restrict X-to-Eam to content of only listed domains.
  • cursor 304 clicks “OK” a network domain name may appear in table 502, as shown in FIG. 7.
  • edit icon 508 may remain to associate further domains with a channel wallet.
  • Cursor 304 may click channel wallet deposit icon 504 to initiation a transfer to the channel wallet address, as shown with numerical-entry box 802 with numerical-entry area 804. After cursor 304 clicks, “OK”, a transaction may occur or is otherwise advanced to transfer the amount entered into area 804 from the operably coupled publisher wallet (e.g., wallet address 0x... PuB) to the channel wallet (e.g., wallet Ox... Chi). In some embodiments, the transfer originates and is approved by a publisher digital wallet. In some embodiments, confirmation box 902 appears, as shown in FIG. 9, in response to said “OK” click of FIG. 8. In response to a publisher using cursor 304 to click “OK”, a blockchain transaction may occur that transfers a cryptocurrency from the publisher wallet to the channel wallet.
  • the operably coupled publisher wallet e.g., wallet address 0x... PuB
  • the channel wallet e.g., wallet Ox... Chi
  • confirmation box 902 appears, as shown in FIG. 9, in response to said “OK” click of FIG
  • the channel wallet Ox. . . Chi now has a balance of 1000 EAT and a calculated 24-hour reward rate of 16.67 EAT at a 500 EAT monthly target budget.
  • code snippet box 1102 may appear with code snippet area 1104, as shown in FIG. 11.
  • Area 1104 may include code snippet text for a publisher to copy and paste.
  • the text includes a URL to Watch2Eam.js with an input of channel wallet address “Ox... Chi”.
  • the HTML ⁇ script> src attribute is used to specify the URL of an external JavaScript file.
  • this is JavaScript for configuring a media player (e.g., a web browser) to provide X-to-Eam paradigms for user wallets that operably coupled to said media player (e.g., code for operably coupling a media player and/or user wallet to X-to-Eam module 107).
  • a media player e.g., a web browser
  • X-to-Eam paradigms for user wallets that operably coupled to said media player
  • code for operably coupling a media player and/or user wallet to X-to-Eam module 107 e.g., code for operably coupling a media player and/or user wallet to X-to-Eam module 107.
  • FIG. 12 shows table 502 with three channels for wallet Ox. . . PuB.
  • Fig. 13 shows various activities and/or playback video states that may modify a user wallet activity score for a given period. Further examples of user wallet activities are shown in FIGs. 18 to 23. Background presentations (e.g., a minimized window) will generally achieve lower activity scores than Fullscreen and unmuted presentations.
  • FIG. 14 shows a blockchain stream-to-eam method 1400.
  • Step 1402 includes calculating, for a time period (e.g., an interval), a wallet-specific activity score for each digital wallet that is operably coupled to a video player that is providing first digital video channel content. That is, step 1402 is determining an activity score for user wallets that are streaming and/or interacting with first digital video channel content.
  • a time period e.g., an interval
  • a wallet-specific activity score may be based on the associated watch time and the cryptocurrency balance (e g., EAT) of said wallet Said balance may be normalized to compress the range of values such as taking a square root of, for example, the sum of the amount of EAT earned (but not yet paid) and current EAT balance of a wallet, as shown in FIG. 16. That is, in some embodiments, viewers with larger EAT balances may earn relatively higher activity scores based on having a greater amount of EAT in their wallet with respect to other viewers’ wallets’ EAT balances.
  • EAT cryptocurrency balance
  • Step 1404 includes determining, for the time period, a total wallet activity score of the operably coupled digital wallets.
  • Step 1406 includes crediting, to each operably coupled digital wallet, a respective stream-to-eam digital currency balance based at least on the total wallet active score, the wallet-specific activity score, and a periodic pay rate of the first digital video channel.
  • step 1406 includes dividing a wallet-specific activity score by the total wallet activity score and then multiplying the result by the channel wallet budget for the time period (e.g., a minute)
  • Step 1406 may include transmitting the calculated credited amount to a respective video player for display to a user.
  • Step 1406 may then return to step 1402 for the next time period. Additionally or alternatively, step 1404 may return to step 1402 for the next time period.
  • Step 1408 includes transferring, from a first channel digital wallet to each of the operably coupled digital wallets, the respective stream-to-eam digital currency balance.
  • method 1400 may perform step 1408 on a daily, weekly, or monthly basis.
  • step 1408 may be performed in response to a user wallet claim request or similar message/transaction.
  • Step 1408 may include a blockchain transaction transfer (e.g., on-chain transfers conducted and recorded on the blockchain and typically require the sender paying a transaction fee or “gas” to facilitate).
  • step 1408 refers to when the user wallet was operably coupled to the video player during at least step 1402 (i.e., during the recited time period of step 1402).
  • An “operable coupled wallet” may include user wallet 108 directly or indirectly coupled with video player 116.
  • a user wallet 108 operably couples with browser module 106 or an application thereof (e.g., a Metamask software wallet application operable with module 106 and coupled to wallet 108).
  • example embodiments include operably coupling a video player directly with user wallet 108 or indirectly via interfacing modules and/ applications.
  • a log-in or sign-in operable coupling info (e.g., a user wallet address) may be stored or cached by browser module 106 to automatically sign-in or log-in for future X-to-Eam sessions.
  • an unlocking condition for X-to-Eam may include an operable coupling with a wallet and media guide system (e.g., successfully performing a log-in).
  • stream-to-eam and tag-to-eam rewards may require a connected wallet (e.g., an operable coupling).
  • earning rates are adjusted depending on the one or more states of a media guide player and/or a user device that is running the media guide player application. For example, muting a main presenting program may lower the stream-to-eam rate. Allowing access to a user device camera may raise a stream-to-eam rate for verifying that a user is actually viewing and/or listening to a program.
  • earning rates for stream-to-eam and tag-to-eam may vary by program. For example, advertising may pay higher rates than main programing and even variation among programs, when in a program a user starts viewing, and/or under what conditions (e.g., minimum number of user wallet).
  • allotments for stream-to-eam tokens or other blockchain currency may be provided on a program and/or time basis (hourly, every half hour). That is, a pool of a blockchain currency (e.g., a reserve) is allotted to be shared amongst the viewer-users that are watching (stream-to-eam) and/or tagging (tag-to-eam).
  • a pool of a blockchain currency e.g., a reserve
  • FIG. 15 shows a multimedia blockchain system 1500, which includes user equipment (UE) 1502 and server 1504.
  • UE 1502 and server 1504 may both include I/O 1506, processor 1508, memory 1510, OS 1512, and display unit 1518.
  • decoder(s) 1520 decode at least a sub-plurality of programs from a multi-program transport stream (MPTS) (e.g., video stream 1532) for local UE viewing and (2) re-transmitting stream 1532 over a partial mesh network topology (as video streams 1532a, 1532b, and 1532n) defined at the application layer, although other configurations and arrangements of software, hardware, and network topologies can be implemented in other embodiments.
  • MPTS multi-program transport stream
  • video stream 1532 may be a single-program video stream transmitted by a content delivery network server that is separate and distinct from server 1504.
  • Encoder(s) 1522 may encode video for streaming as video stream 1532.
  • OTA Rx media module 1530 may receive analog or digital channels that are modulated on an RF signal.
  • Notification module 1548 may receive notification requests and provide, in response, notifications to a user.
  • Conditional unlock module 1505 may unlock one or more features (e.g., X-to-Eam) depending on, for example, a whether a digital wallet is operably coupled application 1516 and/or digital wallet module 1505.
  • media streaming Rx media module 1526 may be operable to receive (e.g., via streaming media Tx module 1524) and transmit a plurality of video streams as part of network 1514, which may an application layer overlay network.
  • the network 1514 may include, among other techniques, an application layer streaming video data according to one or more smallworld topologies within a self-healing and self-organizing network (e.g., a small world wide-area peer-to-peer network).
  • Such a network enables nodes (e.g., UE 1502 and/or server 1504) to enter and leave the network 1514 with minimum-to-no disruption to the presentation of programs of the video streams (e.g., multichannel video streams) by other nodes that remain a part of the network.
  • UE 1502 and/or server 1504 may be part of a peer-to-peer (P2P) overlay network, typically implemented at the application layer, or a hybrid network thereof (e.g., a commercial server commutatively coupled to a P2P overlay network, with said server not being coupled as a node in the sense that it does not re-transmit and/or receive further programs that the network 1514 is sharing).
  • P2P peer-to-peer
  • Streaming Media Tx Module 1524 may respectively stream to further UEs (not shown) via video streams 1532a, 1532b, and 1532n. That is, application 1516 may dynamically implement, via overlay network module 1546, one or more a video streams, as needed as part of a possible self-organizing and self-healing network (e.g., network 1514). For example, the number of video streams 1532a, 1532b, and 1532n may dynamically increase or reduce within the network 1514.
  • S erv er 1504 may further include stream-to-eam module 1501 and channel manager module 104.
  • Stream-to-eam module may receive and calculate wallet activity scores and an individual, channel, and global (e.g., an entire network) basis.
  • wallet activity module 1503 may calculate a user digital wallet activity score, which module 1503 periodically sends to module 1501 as activity data 1534.
  • data 1534 may relay, via module 1503, activity scores, activity score sums of a period, and/or various user wallet actions (e.g., one the listed actions of table 1300) to module 1501 so module 1501 can calculate all or some activity scores on the server side.
  • application 1516 provides module 1501 with data 1534 such as playback state information, including muting state, volume, and/or player window state (open, minimized, full-screen) for calculating a user wallet activity score.
  • application 1516 is, includes, or operable within a web browser module (e.g., Mozilla® Firefox)
  • Module 1501 further provides application 1516 wallet credit data 1536 and wallet ranking data 1538.
  • Wallet credit data 1536 may be periodically sent to update a credited user wallet amount as a result of an X-to-Eam calculation based on user wallet activity scores.
  • Wallet ranking data 1538 may rank a user wallet on a per channel and global basis based on said wallet’s activity score in relation to other user wallet’s activity scores (e g., as shown in FIGs. 22 and 23).
  • Module 1501 monetizers a user’s participating in data characterization for, among other reasons, categorizing content objects. For example, a user may interact with a (graphic) frame for tagging and/or confirming tags of individuals presenting, participating, or otherwise shown on a program. Tags may include real names and/or usernames of social media platforms such as Twitter®, Facebook®, Linkedln®, and the like. Display module 1528 may provide a drop-down menu while a user types a full name. Additionally or alternatively, the drop-down menu may provide a list of social media usernames or handles.
  • a user may interact with a (graphic) frame for tagging and/or confirming tags of individuals presenting, participating, or otherwise shown on a program.
  • Tags may include real names and/or usernames of social media platforms such as Twitter®, Facebook®, Linkedln®, and the like.
  • Display module 1528 may provide a drop-down menu while a user types a full name. Additionally or alternatively, the drop-down menu
  • Digital wallet module 1505 may be a user digital wallet such as user digital wallet 108 of FIG. 1. 1 and/or an application interface with a hardware wallet. It may transmit or cause to transmit user digital wallet data 1540 including, for example, a digital wallet address that is operable with blockchain network 1542. Data 1540 may be transmitted over network 1514 and blockchain/transaction data 1544 may be received, processed, and transmitted via blockchain network 1542. Module 1501 may initiate, via blockchain/transaction data 1544, a transfer transaction which will update, in blockchain network 1542, the respective balances of a user digital wallet associated with module 1505 and a channel digital wallet (e.g., channel wallets 110, 112, and/or 114 of FIG. 1.1), thereby executing the transfer transaction that was initiated by module 1501.
  • a channel digital wallet e.g., channel wallets 110, 112, and/or 114 of FIG. 1.1
  • off-chain transaction may occur over network 1514 and on-chain transaction may occur over blockchain network 1542.
  • module 1505 and/or an associated user digital wallet initiates a “claim” transaction, thereby causing (assuming a successful transaction) the user digital wallet to have an updated on-chain balance that includes the previously pending off-chain cryptocurrency credit that accrued from X-to-Eam activities.
  • Video stream 1532, activity data 1534, wallet credit data 1536, and/or wallet ranking data 1538 may be transmitted, off-chain, together in the same data packet or in separate data packets over network 1514.
  • FIG. 16 shows media guide 1601 with wallet UI 1616 expanded to shows wallet interface 1616a, which shows audio NFT 1620, facial recognition NFT 1622, functional NFT 1624, and claim icon 1618.
  • Interface 1616a may further show blockchain currency data associated with the wallet address, including a wallet balance, a staked balance, NFTs, rewards received via NFTs, and session balances from watch-to-eam, tag-to-eam, and share-to-eam.
  • NFTs 1620, 1622, and 1624 may be owned by a wallet and/or the NFTs 1620, 1622, and 1624 may be staked via a staking contract for earning blockchain currency or other function.
  • Audio NFT 1620 may be an NFT that earns, for a wallet, a blockchain currency (e.g., EAT) when associated audio content is detected in a program.
  • a blockchain currency e.g., EAT
  • audio NFT 1620 may be associated with a particular song or ensemble such that NFT 1620 earns EAT in response to detecting said song or a song from said ensemble in a program.
  • Facial recognition NFT 1622 earns, for an associated wallet address, a blockchain currency when an associated face is detected in a video program of, for example, a video stream.
  • NFT 1622 may represent facial recognition data of a media personality or the like to allow viewers, among others, to earn currency based on said media personality appearing in an video program.
  • Functional NFT 1624 may represent a particular media guide functionality. For example, NFT 1624 may allow for advertisement free displaying of programs. Other functional NFTs 1624 may include a rewards multiplier, decrease of claim fees, NFT rewards multiplier, transmit programing to the network (e.g., an additional program to the MPTS), among other possibilities.
  • Conditional unlock module 1550 of FIG. 15 may utilize one or more of the wallet data shown in FIG. 16 (e g , one or more balances and NFTs) to unlock one or more functionalities such as X-to-Eam.
  • Claim icon 1618 may be a UI element for a user to transfer session balances to a user wallet. In some embodiments, a transfer may occur without a user manually claiming.
  • Banner 1607 shows a user’s token balance 1608, which may be a total balance in a user’s wallet and/or a session balance from one or more sessions.
  • Activity score 1610 may show one or more scores or graphical indicators thereof for the user wallet activity.
  • Channel rank 1612 may show a ranking of a user wallet within a channel that the user is watching.
  • Overall rank 1614 may be a ranking of a user wallet relative to all channels.
  • Wallet UI 1616 may interact with a software or hardware wallet to perform functions like operably coupling, receive, send, stake, and other wallet-related functions.
  • a user may be rewarded in a blockchain currency for “tagging” or identifying people such as media personalities and entering an identifying name, such as a real name or username of a node application or of another platform (e.g., Twitter®).
  • FIG. 17 shows display unit 1518, which shows media guide 1701 with a main program 1700, which shows a person 1702 to be identified.
  • Frame 1704 may outline at least a facial region of person 1702 for, among other possibilities, allowing a user to identify person 1702 or confirm the identity of person 1702 via an interaction with interactive area 1706.
  • a user may be rewarded with a blockchain currency for watching, tagging, and/or listening to programs displayed on display unit 1518.
  • the graphic components of banner 1607 may be differently arranged across display unit 1518.
  • wallet UI 1616 maybe detached from the presentation of main program 1700 such that it resides in a distinct area above, below, or to the side of program 1700.
  • Banner 1607 may “disappear” after a decay duration and re-appear after a user interaction (e.g., a cursor being moved across or towards a lower portion of program 1700).
  • FIG. 18 shows media guide 1801 with main program 1800 and interactive area 1806 for a user to provide an objective determination as to whether person 1702, with frame 1704, is correctly identified as “Jon Bath”.
  • Thumbs up icon 1802 e.g., an upvoting recognition of table 1300
  • thumbs down icon 1804 e.g., a downvote recognition of table 1300
  • said user’s token balance 1708 may increase from a tag-to-eam reward.
  • identified facial descriptors (of a video stream) that triggered a false positive identification may be deemed, in response to a user-viewer’s feedback, as a ‘’rejected facial descriptor” and associated (e.g., via a cluster ID) with a data cluster representing confirmed, rejected and/or identified facial descriptors of a media personality or other individual.
  • FIG. 19 shows media guide 1901 with a main program 1900 that shows people 1902a, 1902b, and 1902c with respective frames 1904a, 1904b, and 1904c.
  • Graphic IDs 1914a, 1914b, and 1914c respectively include interactive areas 1906a, 1906b, and 1906c; photo IDs 1908a, 1908b, and 1908c; identified name 1910a, 1910b, and 1910c; and username 1912a, 1912b, and 1912c.
  • interactive areas 1906a, 1906b, and 1906c provide icons for a user to affirm or disaffirm the individual being of the identity shown in a respective graphic ID 1914a, 1914b, and 1914c.
  • interactive areas may include the entire graphic ID so that, for example, clickable links can be included with one or more of photo IDs 1908a, 1908b, and 1908c; identified name 1910a, 1910b, and 1910c; and username 1912a, 1912b, and 1912c.
  • a user may directly enter a name or username or correct a name or username displayed within a graphic ID.
  • FIG. 20 shows interactive areas 2006a, 2006b, 2006c as an interactive graphic ID and further includes plus icon 2002a, 2002b, and 2002c, and bell icon 2004a, 2004b, and 2004c.
  • the plus icons 2002a, 2002b, and 2002c may respectively allow for user interaction to “follow” or other related functionality the identified person. Additionally or alternatively, a user may interact with one or more of bell icons 2004a, 2004b, and 2004c to receive notifications, both within and “outside” of main program (e.g., as shown in FIG. 21) when the associated identified person is being shown on a program.
  • said notifications may be time stamped and/or trigger the relevant program.
  • the notification may be displayed for a predetermined amount of time.
  • Display 2124 of FIG. 21 shows desktop 2100 with overlayed notifications 2101, 2102, and 2104.
  • a user may click on either notification 2102 or 2104 and, in response, launch or otherwise present a node application for playing a buffered program beginning at the timestamp associated with one of said notifications 2102 and 2104.
  • notifications 2101, 2102, and 2104 may include audio notifications.
  • FIG. 22 shows media guide 2201, which may interact with cursor 2202, and main program 2200.
  • frame 1904c may be clickable by bringing cursor 2202 close to or within frame 1904c, as shown by FIG. 22 with frame 1904c graphically changing from a dashed lined, as shown in FIG. 20, to a solid line in FIG. 22.
  • a frame may change colors or other graphic change to indicate to a user-viewer that said frame is interactable with mouse clicks or similar inputs. If cursor 2202 is outside this interactive area of frame 1904c, a mouse click will not trigger an interaction with frame 1904c.
  • one interactive response is providing text entry box 2302 (e.g., a popup window).
  • Box 2302 accepts a real name and/or a social media handle or username 2304 text for mapping a social media profile to facial detections or confirmation of previous manual and/or algorithmic mappings, such as the “tagging” user wallet actions listed in table 1300.
  • the tagging activity of the tagged personality may be confirmed via character-recognition text 2306, which may be a graphic element of a video program and/or closed caption text that is processed via a character recognition technique such as character recognition (“CR” in table 1300) of on-screen text graphics and/or closed captions data (e.g., subtitles).
  • character recognition e.g., character recognition (“CR” in table 1300) of on-screen text graphics and/or closed captions data (e.g., subtitles).
  • CR- confirmed content object identification activities e.g., tagging a media personality
  • FIGs. 22 and 23 show a token balance 1608 of 8,933 EAT, an activity score 1610 of 1677, a channel rank of 3 out 75 user wallets, and an overall rank of 10 out 801 wallets.
  • FIGs. 24.1 and 24.2 are block diagrams of live search system 2400, which may include server 2403 and browser module 2406.
  • content analysis module 2404 may be implemented via server 2403.
  • module 2404 may be implemented on a client or user-device side (e.g., as an extension or plug-in of a browser application at the network edge).
  • Module 2404 may apply various VCA techniques including facial detector 2410, content object detector 2412, and/or audio object (e.g., a song) detector 2414 to Live Stream 1 2435, Live Stream 2 2437, and Live Stream N 2439.
  • Each live stream may be separate channel and/or multimedia program (e.g., a video program or audio program presented with a graphic overlay).
  • Module 2404 applies one or more of detectors 2410, 2412, and 2414 to identify discrete content objects occurring within the live stream, such as media exposed personalities and provide temporal data that indicates a time that the content object was detected by module 2404.
  • Module 2404 as an external module or internal module of browser module 2406, may provide browser module 2406 content object data 2441 that includes a content object identification (ID) that indicates an identified content object and a timestamp or similar temporal value that indicates an identification time of the identified content object.
  • Content object data 2441 may include data of content objects that are identified across live streams 2435, 2437, and 2439.
  • a user may search across multiple streams for content objects residing in the user’s local buffer (e.g., a memory buffer operably coupled to a decoder) as well as within the non-local, network “buffer” of live streams that the user may not be currently receiving but can direct the video player to play (in addition to or in replacement of a currently viewed live stream(s)).
  • a non-local buffer window may be a pre-defined value (e.g., 30 seconds) or dynamically determined based on segment or temporal data of manifest files (e.g., including segments that are cumulatively equal to a time duration that is shorter or equal to the non-local buffer window).
  • the non-local buffer window may be representative of network buffering resources such as a buffering server that provides a DVR “seek window” for livestreamed video.
  • the content obj ect ID may include their real name and/or their social media handles.
  • a content object ID may be a string or other character-based descriptor of the identified object.
  • such content objects may be obtained from character recognition such as sports games with the content object ID being the team names.
  • the content object ID may be the song’s name and/or the performing group and/or individual artist’s name.
  • Live Stream Video Data 2443 may include one, some, or more video programs than that of live streams 2435, 2437, and 2439. That is, data 2443 include video stream data of one and/or a plurality of video programs within a transport stream.
  • Media player 2416 may play audio, video, and multimedia programs and include audio players and video players.
  • Media buffer 2417 may temporarily store a plurality of segments of the media content.
  • Media buffer 2417 may include data in a reserve area of memory (e g., the buffer) with “pre-loaded” audio or video data in RAM and audio and video data that has already been played back (e.g., a buffer may include a local, DVR-like “seek window” that contains both future and past content up to a local buffer limit).
  • Dictionary module 2404 and Live Search module 2407 will be described in more detail below.
  • System 2400 may include a distributed ledger network 2419.
  • Example distributed ledger networks 2419 include blockchain implementations and associated (1) native digital assets such as, for example, Ethereum (Ether or ETH), Fantom (FTM), and Polygon (MATIC), and (2) smart contracts 2418.
  • System 2400 may include a user digital wallet 2408, which may be a software wallet (e.g., a Metamask® app operable with a browser module), ahardware wallet (e.g., aLedger® Nano or Trezor® wallet), or a combination thereof (e.g., a hardware wallet confirming a transaction initiated via a web browser wallet application).
  • a software wallet e.g., a Metamask® app operable with a browser module
  • ahardware wallet e.g., aLedger® Nano or Trezor® wallet
  • a combination thereof e.g., a hardware wallet confirming a transaction initiated via a web browser wallet application.
  • user digital wallet 2408 accumulates rewards off-chain that are periodically updated on-chain via a blockchain transaction from a publisher’s channel wallet to a user digital wallet under a watch-to-eam paradigm, as detailed in one or more of the EDGE Video applications.
  • Browser module 2406 may include a web browser (also referred to as an Internet browser or simply a browser), which is an application software for accessing the World Wide Web or a local website. When a user requests a web page from a particular website, the web browser retrieves the necessary content from a web server and then displays the page on the user’s device.
  • player 2416 may include dictionary module 2404 with functionalities such as add entry 2420, remove entry 2422, and modify entry 2422 of local dictionary 2424. Example entries of and/or for local dictionary 2424 are shown in FIG. 32.
  • An example add entry 2420 functionality is adding a content object entry in response to receiving content object data that includes at least a content object ID and temporal data indicated an identification time value and/or segment ID of a video stream.
  • An example modify entry 2422 function is updating a timestamp or similar value to the last detected time in response to receiving further detection of a content object already entered into local dictionary 2424.
  • Example remove entry 2422 functionalities may be based on a pre-set time value (e.g. 30 seconds) since the time of the last detection. Additionally or alternatively, remove entry 2422 functionality may include comparing a “matching” search result’s timestamp, segment ID, or the like with the buffered values. Should the timestamp not match or otherwise correspond to a buffered timestamp and/or segment ID value(s), the associated content object ID may be removed from local dictionary 2424 as shown, for example, by step 3406 of FIG. 34.
  • Live Search module 2407 may include search dictionary 2426, GUI 2428, Go to Timecode 2430, Go to Channel 2432, and Go to Channel and Timecode 2434 functionalities, which will be explained in more detail with reference to FIGS. 27 to 31.
  • FIG. 25 shows method 2500 for providing a search dictionary for streaming video programs, among other possible multimedia programs.
  • Step 2502 includes receiving, by a media player, at least one streaming video program of the streaming video programs, which may be concurrently streaming such that each program (of the streaming video programs) is showing different content at the same time.
  • Step 2504 includes obtaining, by the media player and during the receiving the at least one streaming video step, content object data that is associated with content objects of the streaming video programs, the content obj ect data comprising a content obj ect ID that indicates an identified content object and a timestamp that indicates an identification time of the identified content object.
  • a media player may locally (e.g., at the edge or by the UE) detect and timestamp content object detections within a received video program.
  • content object detection from the received and/or other video programs may be provided by a server that receives and applies VC A to a plurality of video streams that are accessible to the media player.
  • Step 2506 includes buffering, by the media player, the at least one streaming video program.
  • Step 2506 is an example of locally buffering a received video program in contrast to network buffering of other streaming video programs that a media player may access via a contentdelivery network server or a peer node (e.g. a node of a decentralized CDN).
  • a contentdelivery network server or a peer node e.g. a node of a decentralized CDN.
  • Step 2508 includes updating, by the media player and during the buffering step, a local searchable dictionary with the content object data, the updating step comprising adding at least the content object ID and the timestamp as a dictionary entry to the local searchable dictionary.
  • FIG. 26 shows a multimedia system 2600, which includes user equipment (UE) 2602 and server 2604.
  • UE 2602 and server 2604 may both include I/O 2606, processor 2608, memory 2610, operating system (OS) 2612, and display unit 2618.
  • UE 2602 may include media player application 2616 and server 2604 may include media server application 2617.
  • decoder(s) 2620 decode at least a sub-plurality of programs from a multi -program transport stream (MPTS) (e.g., video data 2443) for local UE viewing and (2) re-transmitting video data 2443 over a partial mesh network topology (as video streams 2435, 2437, and 2439) defined at the application layer, although other configurations and arrangements of software, hardware, and network topologies can be implemented in other embodiments.
  • MPTS multi -program transport stream
  • video data 2443 may be a single-program video stream transmitted by a content delivery network server that is separate and distinct from server 2604.
  • Encoder(s) 2622 may encode video for streaming video data 2443.
  • Live Search module 2630 may search dictionary module 2603, which is being periodically updated by adding and removing entries of a local (to UE 2602) searchable dictionary.
  • media streaming Rx media module 2626 may be operable to receive (e.g., via streaming media Tx module 2624) and transmit a plurality of video streams as part of network 2614, which may an application layer overlay network.
  • the network 2614 may include, among other techniques, an application layer overlay network module 2646 that streams data according to one or more small-world topologies within a self-healing and self-organizing network (e.g., a small world wide-area peer-to-peer network).
  • Display module 2628 may provide a various overlay graphics along with decoded video for display on display unit 2618.
  • Notification module 2648 may provide auser visual notifications of content object detections as detailed in the EDGE Video applications.
  • Content analysis module 2650 may perform one or more techniques described in reference to content analysis module 2404 of FIGs. 24.1 and 24.2.
  • FIGs. 27 to 31 show media guide 2701 with progressive presentations 2700a to 2700e related to live searching.
  • presentation 2700a shows, along with personality 2703, banner 2707 with a token balance 2708 of 8,933 EAT, an activity score 2710 of “477”, a channel rank 2712 of 3 out 75 user wallets, and an overall rank 2714 of 10 out 801 wallets.
  • Wallet UI 2716 may interact with a software or hardware wallet to perform functions like operably coupling, receive, send, stake, and other wallet-related functions, which is shown in more detail in the EDGE Video applications.
  • Media guide 2701 may further include address bar 2702 for displaying and/or entering URL addresses and the like, live search bar 2704, and cursor 2705a.
  • Presentation 2700b of FIG. 28 shows cursors 2705b, which is now a text cursor in response to a user moving cursor 2705a near or within live search bar 2704.
  • Presentation 2700b shows a user typing the letter “T” in bar 2702 and a result list 2709, with dictionary entries 2709a, 2709b, 2709c, 2709d, and 2709e being displayed.
  • Presentation 2700b thus shows, visually, examples of search dictionary 2426 and GUI 2428 functionalities of FIG. 24.2
  • Entry 2709a displays a media personality name, “Taco Kop”, on the Sportz Ball Channel, along with a timestamped entry. In some embodiments, said timestamp entry may reflect the last time a content object/media personality was detected in a live stream.
  • Entry 2709b shows the channel name, “Talk Now Channel”.
  • Entry 2709c show a content object detection of a tambourine instrument on the Muzik Channel. A fictional character, Teddy Roosevent, is shown by entry 2709d, and the show, “The Lonely Ranter” on the channel “Talk Now” is shown by entry 2709e.
  • FIG. 29 shows a user now inputting “Ta”, which limits result list 2709 to entries 2709a, 2709b, and 2709c.
  • Presentation 2700d of FIG. 30 shows cursor 2705a that’s no longer a text cursor in response to a user moving it close or within the area of entry 2709a.
  • presentation 2700e of FIG. 31 is provided.
  • Media guide further shows graphic ID 3114, with identified name 3110, username (e.g., a social media handle) 3112, and photo (e.g., a social media profile image) 3108. Further details concerning graphic IDs are given in the EDGE Video applications.
  • presentation 2700e shows an example of Go to Channel and Timecode 2434 functionality of FIG. 24.2, by taking both the channel and timecode data to “redirect” the video player’s main program to the selected content object’s detection time within alive stream.
  • Go to Timecode 2430 functionality is implemented in cases that the selected content object is associated with the same channel being presented as the main program (i.e., not channel change is needed) and merely changes the playback time of the main program to the latest content object detection time or a corresponding value thereof (e.g., a segment ID).
  • Go to channel 2432 may not include temporal data and will change the channel to the current time of the live stream. Such embodiments may be desirable for longer duration content objects like athletic events, movies, songs, and the like in comparison to a detected appearance or other occurrence of a particular object, animal, or media personality.
  • FIG. 32 shows various dictionary entries of dictionary 3200, including physical objects, real people, fictional characters, a song, and football game.
  • offset values may be provided in addition to a timestamp in order for a user to switch to the channel and begin playback at the appropriate time (e.g., when the content object was detected).
  • either timestamps or segment IDs e.g., sequential integer values
  • FIG. 33 shows live search method 3300.
  • Step 3302 includes receiving, by a media player and via a search GUI, a search query for the local searchable dictionary.
  • Step 3304 includes displaying, by the media player and via the search GUI, a search result list that selectively displays at least one of the content object ID, a channel ID, and a video program ID.
  • Step 3306 includes receiving, by the media player, a selection from the search result list. For example, a user may click a search result, as described above and in reference to FIG. 30.
  • Decision 3308 determines if a selection is located within a local video buffer. For example, a selected content object ID may be associated with a temporal value that matches or otherwise corresponds to a video segment currently residing in a UE’s local video buffer. Alternatively or additionally, decision 3308 may be based on a selected channel ID matching a channel ID of locally buffered video data. [0147] If decision 3308 is in the affirmative, step 3310 may include playing, by the media player, a locally buffered video program segment based on a timestamp of the dictionary entry that is associated with the search result selection. In embodiments without temporal or segment ID data tied to a search result, a similar method step may simply switch to the buffered channel at a preset or arbitrary starting point for playback.
  • step 3312 may play, by the media player, a network buffered video program segment of the selected channel based on a timestamp of the dictionary entry that is associated with the search result selection. That is, step 3312 may utilize non-local buffering resources or even latency between, for example, a CDN server and a UE, as “buffered video program data”, particularly if content objects are identified, via a server, seconds before the corresponding video program data reaches and/or is played by a UE.
  • the local dictionary may remove entries based on both local buffering capacity as well as non-local buffering capacity such that search results are generally restricted to content objects that a video player can seek to within a local and non-local buffer.
  • FIG. 34 shows live search method 3400.
  • decision 3402 may determine if a matching content object timestamp entry is reflected in a local buffer. This may include comparing, for example, HLS manifest data with temporal data and/or segment IDs. Additionally or alternatively, decision 3402 may be based on a channel ID or program ID matching an ID of buffered data.
  • decision 3404 may determine if the matching content object timestamp entry is expired or otherwise not reflected in a stream manifest. For example, content object that are being detected on streams that are not buffered via a local UE, may be removed from a local dictionary based on pre-set period of time such as 30 seconds after the last detection, representing a possible 30-second seek window of an audio or video stream. Alternatively, temporal data from HLS manifest data may be added up to determine if particular HLS segments are seekable or otherwise within a network buffer that a UE media player can access for playback.
  • step 3406 includes removing the matching content object entry from the local searchable dictionary, thereby removing the matching entry before step 3304, which displays results that a user may seek or “jump to” among, for example, a plurality of live streams.
  • FIG. 35 shows media guide 3501 with presentation 3500a, which includes channel banner 3503.
  • an individual wallet/user’s watch-to-eam rate may be based on the total funding of a particular channel wallet and the total number of viewers of a channel that have their digital wallet operably coupled.
  • channel banner 3503 may order channels 3502, 3504, and 3506 in terms of earning potential for a user-viewer.
  • channels 3502, 3504, and 3506 may be ranked, along the x-axis, according to, for example, a channel pay rate or watch-to-eam rate (the terms will be used interchangeably).
  • a periodic rewards calculator (not shown) may determine a periodic pay rate based on a digital currency (reserve) balance of a respective channel digital wallet.
  • a calculator may determine a daily amount to be paid to user wallets over a 24-hour period. Said amount or daily rate may be based on a “balance target” after a weekly or monthly time period.
  • a channel wallet balance of 60 ETH would result in a daily rate of 1 ETH such that, after 30 days and assuming no further transfers to the channel wallet, half of the channel balance remains (i.e., a reserve balance of 30 ETH).
  • the daily rate is adjusted in response to transfers increasing a channel wallet’s balance and/or a weekly or monthly scheduled time.
  • the channel wallet with a reduced 30 ETH balance may, at the 1st of the next month, have its daily pay rate adjusted to 0.5 ETH for a balance target of 15 ETH (i.e., the default daily pay rate may be based on a balance target of 50% of the channel balance at the time the daily pay rate is recalculated).
  • a channel activity score may be determined by summing the activity scores of individual wallets coupled to a player that is streaming or otherwise playing media of a particular channel. In some embodiments, such score is updated multiple times in a day and/or hour, such as a rate of once per minute, which may be altered by adjusting a period interval to shorter or longer periods (e.g., adding scores every 1 minute to 1 hour).
  • a wallet activity score may calculate and/or receive a user wallet activity score for every time period, as set by an interval.
  • channels 3502, 3504, and 3506 are ranked based on the total number of coupled or “watching” wallets and the channel daily pay rate.
  • the channel daily pay rate may be divided by the number of wallets that are earning rewards from that channel or, for example, 100 ETH daily pay rate divided by 100 wallets would give the channel pay rate score of “1”.
  • the channels with the highest pay rates are featured in a banner along the x- and/or y-axis and are dynamically ranked according to a channel’s relative pay rate score, which is representative of an individual pay rate that a viewer’s wallet would receive.
  • Animation 3508 may designate that the watch-to-eam base rate for channel 3506 has passed the rate for channel 3504. As such, and as shown by presentation 3500b of FIG. 36, channel 3506 is now shown to the left of channel 3504, with channel 3502 maintaining the highest watch- to-eam rate.
  • channel banner 3503 is interactive such that, in response to a user interaction (e.g., via cursor 2705a) of any of channels 3502, 3504, and 3506 results in the selected channel being the main presentation, as shown by presentation 3500c of FIG. 37 of “CH7”.
  • the present invention thus has numerous aspects.
  • the present invention valuably supports and services the historical trend of reducing costs, simplifying systems, and increasing performance. These and other valuable aspects of the present invention consequently further the state of the technology to at least the next level.
  • the multimedia content management and packaging system of the present invention furnishes important and heretofore unknown and unavailable solutions, capabilities, and functional aspects for processing image content.
  • the resulting processes and configurations are straightforward, cost-effective, uncomplicated, highly versatile and effective, can be surprisingly and unobviously implemented by adapting known technologies, and are thus readily suited for efficiently and economically manufacturing devices fully compatible with conventional manufacturing processes and technologies.
  • the resulting processes and configurations are straightforward, cost-effective, uncomplicated, highly versatile, accurate, sensitive, and effective, and can be implemented by adapting known components for ready, efficient, and economical manufacturing, application, and utilization.
  • embodiments may include Video-on-demand streams provided by a commercial server to a user device (e.g., computer, smart phone, streaming device, gaming counsel) that is running a watch-to-eam application (e.g., a media player application) that is operably coupled to a digital wallet.
  • a user device e.g., computer, smart phone, streaming device, gaming counsel
  • a watch-to-eam application e.g., a media player application
  • Embodiment streams include audio streams, video streams, and interactive streams (e.g., video game streaming or “cloud gaming”), among other media streaming examples.
  • embodiments may implement one or more modules (e.g., X-to-eam module 107) as a browser plug-in, a standalone application, an embedded module in a video player, or an embedded module in a web page containing a video player, among other possible software architectures.
  • said one or more modules may be communicatively coupled to a server.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Un procédé comprend l'association d'un portefeuille numérique de publicateur à un premier compte de canal vidéo numérique qui comprend un premier portefeuille numérique de canal d'un système de registre distribué; la détermination d'un solde de réserve de monnaie numérique du premier portefeuille numérique de canal; la détermination d'un taux de paiement périodique au moins sur la base du solde de réserve de monnaie numérique; et en réponse à (i) un couplage opérationnel d'un portefeuille numérique d'utilisateur et d'un lecteur vidéo et, (ii) le lecteur vidéo présentant au moins un contenu d'un premier canal vidéo numérique, la créditation d'un solde de monnaie numérique de type "gagner en diffusant" associé au portefeuille numérique de l'utilisateur, l'étape de crédit étant basée au moins sur le taux de paiement périodique et, éventuellement, sur un score d'activité déterminé périodiquement pour les portefeuilles numériques connectés, les portefeuilles numériques connectés étant couplés de manière opérationnelle à un lecteur vidéo respectif qui fournit également au moins le contenu de la première chaîne vidéo numérique.
PCT/US2023/066059 2022-04-21 2023-04-21 Système de registre distribué de gestion et d'emballage de contenu multimédia et son procédé de fonctionnement WO2023205772A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202263363342P 2022-04-21 2022-04-21
US63/363,342 2022-04-21
US202263365343P 2022-05-26 2022-05-26
US63/365,343 2022-05-26

Publications (1)

Publication Number Publication Date
WO2023205772A1 true WO2023205772A1 (fr) 2023-10-26

Family

ID=88420649

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/066059 WO2023205772A1 (fr) 2022-04-21 2023-04-21 Système de registre distribué de gestion et d'emballage de contenu multimédia et son procédé de fonctionnement

Country Status (1)

Country Link
WO (1) WO2023205772A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190058910A1 (en) * 2017-08-20 2019-02-21 Cisco Technology, Inc. Decentralized content distribution
US20200058019A1 (en) * 2018-08-16 2020-02-20 Free Stream Media Corporation d/b/a Samba TV Viewer data access management
US20210149696A1 (en) * 2018-10-16 2021-05-20 Eluvio, Inc. Decentralized content fabric

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190058910A1 (en) * 2017-08-20 2019-02-21 Cisco Technology, Inc. Decentralized content distribution
US20200058019A1 (en) * 2018-08-16 2020-02-20 Free Stream Media Corporation d/b/a Samba TV Viewer data access management
US20210149696A1 (en) * 2018-10-16 2021-05-20 Eluvio, Inc. Decentralized content fabric

Similar Documents

Publication Publication Date Title
US11678000B2 (en) Method and system for providing social media content synchronized to media presentation
US9992537B2 (en) Real-time tracking collection for video experiences
US9538250B2 (en) Methods and systems for creating and managing multi participant sessions
KR101774039B1 (ko) 온라인 소셜 네트워크에 대한 자동적 미디어 자산 업데이트
US20150256885A1 (en) Method for determining content for a personal channel
US10419794B2 (en) Systems and methods for synchronizing media asset playback from multiple sources
EP2779676A1 (fr) Guide de programme basé sur une image intuitive permettant de commander un dispositif d'affichage tel qu'une télévision
US20230379531A1 (en) Systems, apparatus and methods for rendering digital content
US20140141877A1 (en) Methods and systems for visually distinguishing objects appearing in a media asset
WO2023205772A1 (fr) Système de registre distribué de gestion et d'emballage de contenu multimédia et son procédé de fonctionnement
US20220174345A1 (en) Systems and methods for storing content items based on consumption history
EP3205087A1 (fr) Guide de programmes électronique affichant des recommandations de service multimédia
WO2023201167A2 (fr) Système de registre distribué de gestion et de conditionnement de contenus multimédia et procédé d'exploitation afférent
US10965984B1 (en) Minimization of video re-buffering using local animation

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: 23792808

Country of ref document: EP

Kind code of ref document: A1