WO2017117621A1 - A system and method for managing the copyright ownership, brand assets, quality control and public display of video content received from many sending users. - Google Patents

Abstract

A system and method for managing the copyright ownership, brand assets, quality control and public display of video content received from many sending users (whether known or unknown to the receiving user), where the sending users could use any number of devices to create and transmit video content, and where the endpoint display of the video content could be in many end-point locations and on a variety of devices.

Description

TITLE OF INVENTION

A system and method for managing the copyright ownership, brand assets, quality control and public display of video content received from many sending users.

TECHNICAL FIELD

The disclosure generally relates to the field of electronic communications and more specifically, to the creation of video content by one or more users, on one or more independent devices, where the video content will be sent to a receiving user, where the receiving user may or may not know the sending users, where the receiving user requires the content to conform to certain requirements, where the content received will be transmitted by the receiving user to many end-points, and where the receiving user in order to transmit the content to the end-points requires either (i) copyright ownership of the transmitted content; or (ii) permission from the copyright owner to transmit the content to the end-points (for example, if the end-point publicly displays the content as part of a business not related to the sending user).

BACKGROUND ART

[0001 ] Electronic communication via video is already very common, and there already exists technology to manage video creation, transfer and distribution. There also exist some solutions to manage brand identity (such as displaying a company logo during a video) and copyright ownership of the video content.

[0002] Examples of existing solutions include: one point to many point video file transfer (eg, online services which receive one uploaded video file and transmit it to many video hosting services and/or social media services);

one point to many point video URL transfer (eg, a user can send a message with an embedded video URL to Twitter, which displays the video to its audience and also re- sends the message to a linked Facebook account, where the same video URL is displayed to the Facebook audience);

many-point to many-point video transfer (eg, video conferencing software that enables multiple participants in multiple locations to all see each other

simultaneously on their screen by video streaming of each participant to all the other participants);

one point to many point video display, where the owner of a video allows many other users to display that content on their own online publication system, without transferring ownership of the video or copyright (eg, a Youtube video creator allows the display of their Youtube video on websites that do not belong to Youtube or the video creator);

solutions that allow users to create videos on their device (eg, an app on a mobile device, or software on a computer), and send those videos to a variety of locations (such as Facebook or Twitter), usually one location at a time;

software that allows employers can allow their employees to create videos with the employer's brand as part of the video content (such as showing the employer's logo in a special animation at the start of the video), and where copyright and ownership of the video content is automatically transferred to their employer as part of normal copyright law.

[0003] However, there are still significant limitations in these solutions, particularly in the areas of copyright ownership (particularly where no formal copyright agreement exists between users), quality control, brand control and scalability.

[0004] There does not exist a scalable solution which automatically handles copyright transfer, brand control and quality control for many situations, whether the sending user is an employee or a non-employee, where the sending user is known or unknown to the receiving user, and where the solution is enforced automatically and customisable such that the receiving user may scale the solution to as many users as they want, while still allowing custom copyright agreements and brand usage rules for each individual user or type of user.

[0005] The existing solutions do not provide more useful ways to manage many unknown users, many received videos, and many secure access-restricted end- points, where the received videos may or may not be required to have a consistent brand identity across all videos, in a way that is scalable and automatic.

[0006] The current solutions require the receiving user to know the sending user, such as "inviting" them by email to join a service, or by the receiving user importing a list of known contacts into the service. In these situations, the receiving user is required to know the contact details of the sending user, and the users usually have an agreement in place before the video content is created, where the agreement stipulates who will own the copyright and content of the video. For example, an employer receiving video content from an employee where copyright law already awards the copyright ownership to the employer by default, or the receiving user receives video content from a contracted party such as a media agency, where part of the contract specifies who will own the copyright of the content.

[0007] Current solutions do not offer a way to control transfer of copyright ownership between video producers that are not employees of a company or who are not under an existing agreement with the company. Particularly, existing solutions do not offer a way to control who own the copyright when a sending user is not yet known to the company. This limits the employer from receiving content from a wide variety of other sources, such as customers, admirers, staff family members, industry journalists, bloggers, online content creators, and so on. While these groups of people could potentially send video content to the receiving user (for example a blogger may review a company's product in a video resulting in an excellent promotional video for the company), copyright agreements are rarely accurately described, leaving some ambiguity which poses a legal risk for the users involved. Or a copyright agreement has to be manually created, sent, signed, returned and filed, which is not scalable and is a deterrent to many users (both sending and receiving users alike). Thus it is unlikely that these groups of people would create and send video content to the receiving user, and if they did it is unlikely that the receiving user would publish the video content.

[0008] Similar to the issue of copyright ownership, existing solutions have

weaknesses which puts receiving users at risk with regards to their brand (the "image" of their company) and their reputation. [0009] Existing solutions force receiving users to only receive videos from a limited pool of content creators who are already known to the receiving user, so that the receiving user may rely on agreements such as an Employment Agreement or an agreement with a media agency to prevent unauthorised usage of their brand assets. If they have such an agreement in place, the receiving user may allow the existing solution to distribute. The receiving users do not have a way to allow sending users that are not yet known to them to create videos with their brand showing in the video, and send that video to the receiving user, while still protecting the brand from misuse by the unknown sending user. Thus the receiving user cannot scale up their operation to receive branded videos from a larger group of suppliers.

[0010] For example, existing software solutions allow a user to create a video on their mobile device, and process the video on the device in such a way that the receiving user's company logo is added to the sending user's video. The user is then presented with options to send the video to the receiving user, or save the video to their device's general file storage. Saving the video to the user's device, particularly saving the file to the device's general file storage for easy retrieval by the user, creates a security loophole - the sending user could then transfer the video from their device's general file storage to any other destination that they want to (such as publishing that video to their own personal social media accounts), without permission from the company. Or the user could create content that intentionally damages the reputation of the receiving user (such as derogatory or offensive content), add the company's brand so that the resulting video looks "authentic" and approved by the company, and then publish this video to social media accounts that they control on Youtube, Twitter and Facebook, creating public damage of the company's brand and reputation - damage that is not easy to erase. This means that if a company uses existing solutions and allows users to make branded videos on a mobile device, then the company loses control of their brand, and puts their public reputation at risk.

[0011 ] While the receiving user could process videos received from unknown sending users in order to add their brand to the videos, this creates a processing load on the receiving user's processor (eg, a computer or server), particularly if a large number of videos are received and require such processing (for example, 1000 videos require processing simultaneously), which may lead to further issues of cost, hardware and software to handle this increased load. A better solution is to allow the sending users to process their videos on their own devices so that the receiving user's brand is added during that processing on the device, before sending the video to the receiving user. There are existing solutions that do process the receiving user's brand into a video created on the sending user's device, however these solutions have the previously described weaknesses of security (allowing users to save videos to their devices and export from the device to other locations), the sending users must be known to the receiving user, and the users must have a prior agreement about who own the copyright in order to reduce the risk of litigation over copyright ownership.

[0012] A third point of weakness with existing solutions is they lack a scalable, automatic way for a receiving user to process and distribute a large number of received videos to many destination end-points, while receiving those videos from a variety of sending users, and while maintaining brand control, quality control and clear copyright ownership in the content from those users.

[0013] For example, a company will often have a branded Youtube channel, Twitter profile, Linkedin account and Facebook page. The company has standards for visual quality, video content and the way their brand (such as their logo and slogan) are used. The company often prefers to have their video contented branded in a similar way to their existing Youtube channel, Twitter profile, and so on.

[0014] There is no easy way to enforce compliance with the company standards, or to enforce security of access to their social media accounts, with even a small number of users.

[0015] The typical situation currently is a company may have one staff member with access to those social media accounts, and perhaps one external agency may have access as well. The company cannot scale beyond that limitation, because if they allow more users to submit content to those social media accounts, then they choose to either reveal the access information (such as a login password), or they have to receive the video content manually via web transfer, adding their brand to the video via a video editing software program, formatting the video for display on the web, then manually uploading those video files to a hosting service, and submitting the hosted video plus company-approved text (such as a headline and company-related keywords) to many end-points.

[0016] These existing methods become unworkable as more and more users submit video content to the same company, particularly if the sending users are not known to the receiving user.

[0017] In summary, existing solutions put a company at risk from damage to their brand and reputation, and from damage by litigation due to ambiguous copyright ownership issues. To minimise their risk, they are forced to receive video content from a limited pool of known suppliers, where they have prior agreements about copyright ownership. They cannot open up to a wider range of video content creators, particularly the vast range of creators that they do not yet know or have existing agreements with, thus miss out on opportunities to promote their business, raise public awareness of their brand and mission, educate and inspire at a larger scale, which in turn translates to a lower economic return than they could realise if they could safely access the larger pool of content creators without the risks described above.

SUMMARY OF INVENTION TECHNICAL PROBLEM

[0018] The existing solutions do not provide more useful ways to manage many unknown users, many received videos, and many secure access-restricted end- points, where the received videos may or may not be required to have a consistent brand identity across all videos, and where the received videos may require varied copyright agreements, in a way that is scalable and automatic.

[0019] Additionally, there is no general method of receiving videos from multiple users, who may be using different devices or interfaces, who may or may not have authority to access the restricted end-points, and who may or may not be trusted with "quality control". [0020] In general, the current state of the art lacks, inter alia, a system and method for allowing multiple users (both known and unknown to the receiving user) to send video content to the first user, where the video content is forced to conform to branding and quality guidelines of the first user, and where the sender and receivers are using different devices and interface, and where the sender does not need to have knowledge of the end-points or their access information, or the receiving user's video file preferences, and where copyright ownership is clearly agreed on and recorded.

SOLUTION TO PROBLEM

[0021 ] The solution outlined in this document proposes to address these issues, by providing a method to manage brand security and reputation, while receiving video content from users known or unknown to the company, where the videos are made on devices with secure or unsecure processing environments that may or may not provide security of the company's brand. And it controls the copyright agreements between many users and the company, such that the company may publish the content supplied by many users, without risk of litigation over copyright ownership. It controls brand usage by limiting the sending user's usage of a receiving user's brand to approved uses only. It limits the sending user to sending a branded video (where the video content has the receiving user's brand showing in it) to only the receiving user, and prevents the sending user from sending the video to any other destination. The method allows the company to receive video content from a vast range of suppliers (known and unknown), while protecting their brand reputation and managing copyright ownership in an automated, scalable way.

[0022] A receiving user may wish to allow many unknown users to send videos to the receiving user, where the video will contain content that automatically meets the receiving user's brand requirements, copyright ownership and quality control requirements. The unknown users may or may not know the receiving user's contact information (email address, phone number, mail address, etc). Instead, the sending user may simply enter an identifier for the receiving user, such as a known company name, a person's name, or a website address. The system will use this input to look up the correct receiving user, without revealing any contact information to the sending user. The system will also retrieve the preferences of the receiving user for brand control, copyright ownership, and quality control, and apply those preferences to the sending user's video content. The system will record who owns the copyright of the video, according to the preferences of the sending and receiving users. And if the video meets the standards of the receiving user, the system will transmit the video to the receiving user's desired destinations.

[0023] Disclosed is a system and method that includes, for example, a copyright management module, a brand management module, a quality control module, a routing engine that receives a video from any of various entry points, including mobile devices, computers, web input, and application programming interface (API) function calls. The routing engine determines the identity of the destination user to receive the video content, and according to the destination user's requirements performs processing, quality control, adds information required for each specific destination. The routing engine determines the endpoints to which the destination user wishes to send the video, the endpoints can be one or more of web, email and API function calls. The destination endpoints are independent of the source entry points, and the video sender does not need to have knowledge of the endpoints, or endpoint-specific access information. The routing engine applies information to accompany the video as appropriate for each endpoint, and transmits the video and information to the endpoints. The routing engine allows for end-points to be dependent on other end-points, and use one end-point as part of a message to another end-point. In this case, the routing engine will wait for the first end-point to be delivered, then use that result as part of the transmission to the second end-point.

ADVANTAGEOUS EFFECTS OF INVENTION

[0024] The system makes significant gains in computer processing performance by distributing the video processing load to user devices, rather than performing 100% of processing at a central computer facility. For example, if 1000 users submit a video simultaneously to one user, and all 1000 videos required certain processing to meet the receiving user's requirements, this would create a significant load on the receiving device. However, the system distributes some or all of the processing to the sending users' devices, such that each of the 1000 devices processes 1 video simultaneously before sending the video to the receiving device, freeing up the receiving device for other tasks, and making the overall system performance much more efficient.

[0025] The system beneficially allows for copyright agreements to be made instantly between sending and receiving users according to pre-determined wishes of each user. For example, a receiving user configures their preferences such that they will only receive videos from users if the sending users agree to transfer copyright to the receiving user. The sending user agrees to this before sending their video content to the receiving user. The system stores the agreement in each case, with identifiers for both parties. The sending user may know or may not know the receiving user, and vice versa.

[0026] The system beneficially allows for a receiving user to receive video content that meets their brand and quality control guidelines from sending users that are known or unknown to the receiving user. A receiving user controls the way that their brand is added (or not added) to videos submitted by sending users. A submitted video can be processed for quality control, brand control, and/or improved viewing on a particular destination endpoint.

[0027] The system beneficially allows for a sending user to send video content to a multitude of receiving users, each with different brand and quality control guidelines, and where the sending user may or may not know the receiving user(s). The system will automatically prepare each video according to the requirements of the receiving user.

[0028] The system beneficially allows for device independent point to multipoint communication. The destination endpoints are independent of the source entry points, and the video sender does not need to have knowledge of the endpoints, or endpoint-specific access information (such as passwords to gain access to an endpoint account). A receiving user controls that user's destination endpoint and configures their preferences for receiving videos from any other users. A submitted video can be processed for quality control, brand control, and/or improved viewing on a particular destination endpoint. Additionally, the receiving user can manage the other users' ability to submit videos to the receiving user, by configuring the system according to their wishes.

[0029] The features and advantages described in the specification are not all inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the disclosed subject matter.

BRIEF DESCRIPTION OF DRAWINGS

[0030] The disclosed embodiments have other advantages and features which will be more readily apparent from the detailed description, the appended claims, and the accompanying figures (or drawings). A brief introduction of the figures is below.

[0031 ] FIG. 1 illustrates one embodiment of an overall multi-user, multipoint to multipoint video management system.

[0032] FIG. 2 illustrates one embodiment of the rules module in a multi-user, multipoint to multipoint video management system, for example, as shown in FIG. 1.

[0033] FIG. 3 illustrates one embodiment of the routing engine in a multi-user, multipoint to multipoint video management system, for example, as shown in FIG. 1.

DESCRIPTION OF EMBODIMENTS

[0034] Reference will now be made in detail to several embodiments, examples of which are illustrated in the accompanying figures (FIGS.). It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the disclosed system (or method) for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.

[0035] FIG. 1 illustrates one embodiment of an overall multipoint to multipoint video management system 100. The video management system 100 includes a device 102, a processing engine on the device 104, a rules module 106, a routing engine 108, a transmission engine 110, an endpoint data storage 112, and endpoints 114. The rules module 106 further includes an account module 202, a user module 204, a copyright module 206, and a brand module 208. The routing engine 108 further includes a processing engine 302, a video file storage 304, a quality control module 306, an information module 308, and an authentication module 310. The

transmission engine 110 further includes a web transmission engine 11 OA, an application program interface (API) transmission engine 110B, and an e-mail transmission engine 110C. The endpoints 114 further include a web endpoint 114A, an API endpoint 114B, and an e-mail endpoint 114C.

[0036] The rules module 106 communicatively couples the device 102. The device 102 communicatively couples the routing engine 108. The routing engine

communicatively couples the transmission engine 110. Specifically, the routing engine 108 couples with the web, API, or email transmission engines 110. The web and API transmission engines 110 couple with the web and API endpoints 114, respectively, through the endpoint data storage 114. The e-mail transmission engine 110 couples with the e-mail endpoint 114.

[0037] A user (the receiving user) joins the system, and creates an account (the receiving account) to receive videos. The rules module 106 records the

configuration of the receiving user's account, including default settings for copyright ownership of video content submitted to the account, brand usage, quality control, security settings, and which endpoints video content may be sent to. Some examples of brand rules may include displaying the video only in high definition format (not standard definition format) to give a higher quality picture in the display, displaying a logo at the start or end of the video, and limiting the duration of the video to under a certain amount of time such as 5 minutes. The rules are set by the receiving user according to their preferences. The video management system 100 enforces the rules for that account on the videos submitted to the account by all other users (the sending users). The receiving user may choose to customise the rules for certain sending users (such as allowing one sending user more freedom with using the receiving user's brand in their videos, or allowing the sending user to retain copyright ownership of their submitted video), or simply enforce the same rules on all sending users.

[0038] The sending user connects to the receiving user's account on any device 102. There are several possible devices that could be connected, including mobile devices, tablets, computers, servers, and other devices that connect by API, which herein shall be referred to simply as "devices 102", "the device 102", etc. The sending user may use any device 102, and any number of devices 102. The sending user may add new devices and stop using existing devices.

[0039] The sending user may or may not be known to the receiving user, and the sending user may or may not contact information about the receiving user (an email address or phone number, for example). The sending user may simply type a known identifier for the receiving user, such as their name or website address.

[0040] When the sending user connects to the receiving user's account, the rules module 106 looks up the receiving user's account configuration in relation to the sending user. The rules module 106 will control the usage of the receiving account's brand and video preparation on each device, according to that device and the account rules. This allows the account and the account's end-points to receive video content from a wide variety of sources and sending users, while enforcing

consistency of the account brand, reputation, visual/audio quality, copyright ownership, and security of access to the endpoints. Maintaining security of the brand on the device is discussed below.

[0041 ] The sending user prepares a video on the device 102 for submission to the receiving account. There are several ways they could do this, depending on the device. One way is to record a video on a mobile phone using the phone's camera. Another way is to upload a video file from a computer to a web interface. Another way is to send a video file programmatically using an API. An API allows the creation of many additional interfaces that a sending user may use to send videos to the account. For example, a 3rd party mobile app could be developed which uses the API to send videos on behalf of its users to specific accounts. The API function is discussed further below.

[0042] The device 102 may be configured to allow the use of processing engine A 104, where videos are partly or completely processed on the user's device to prepare it for the receiving account (such as applying the receiving account's brand assets like a logo, watermark, branded video introduction, trademarks, and brand- related sound assets), if the rules module 106 allows it for this account and device. One embodiment of processing engine A 104 may be part of a specific software program on the device, such as a mobile app on a mobile device, a software application on a computer, or a processing environment on a server, where such software can create a secure environment that is not normally accessible to the user of the device. If the use of processing engine A 104 is allowed on the device, the system may configure some aspects of the device to perform the role of processing engine A 104, such as transferring brand asset files to a secure storage location on the device that is not normally accessible to the user of the device, and enforcing the strict use of those assets according to the account rules on every video prepared on the device for submission to the account. A sending user may be connected to many different receiving accounts, and use the same device for all those accounts, in which case some accounts may allow the use of processing engine A 104 on that device, and other accounts may deny its use on that device.

[0043] The routing engine 108 receives a video file and any accompanying information about that video file (collectively called the "video data") from a device 102, determines where the video is to be sent, and prepares the video for

transmission to the various endpoints. The routing engine may perform processing on the video file, if necessary (for example if processing engine A 104 was not used to process the video on the sending user's device). The routing engine may produce multiple copies of the video file to be sent to different endpoints 114, if for example different endpoints require different file formats or file compression settings. The routing engine 108 may add more information to the video data that will be transmitted (such as specific text required for specific endpoints). And the routing engine may add endpoint access information (such as security login information, or API passwords) if required for each endpoint. The routing engine is described further below.

[0044] The endpoints 114 represent the actual systems and interfaces for displaying the video to viewers, or using the video data in some useful way beyond the bounds of the system (for example, a 3rd party file storage system, or 3rd party software application that performs further processing on the video file). The transmission engines 110 send video data to their respective endpoints 114. The transmission engines 110 may also send the video data to a storage 112, as described below, before the video data is received at the endpoint. The transmission engines 110 and endpoints 114 are described further below.

[0045] Some endpoints 114 are used as part of the video data in a transmission to another endpoint. An example is where a first endpoint is a video file hosting service such as Youtube, and a second endpoint is a "display only service" which cannot host the video file and relies on the file being hosted elsewhere. In this case, the transmission engine 110 would transmit the video data to the Youtube endpoint first to achieve the hosting of the video file, then use the hosting information supplied by that endpoint as part of the video data sent to the second endpoint. This process is automated and handled by the routing engine 108. Thus, the endpoint 114

communicatively couples the routing engine 108.

[0046] The endpoint data storage 112 holds information about the location of the endpoint (eg, a URL to a location where the video is displayed), the data sent to the endpoint (such as text accompanying the video file), and the response from the endpoint (eg, a set of data from a service such as Youtube, which contains additional information about the display of the video at the endpoint). Data held in this storage allows users to quickly access the endpoint locations that relate to a specific video if necessary, such as if in the future there is a copyright infringement order relating to a particular video, the user can use this data in the storage to quickly remove the various copies of the infringing video from the endpoints that relate to that infringing video.

[0047] A video can be sent by a sending user from a device 102 to a receiving account which transmits the video to multiple endpoints 114. The information to gain access to the endpoints (such as login password information or API access codes) is never revealed to the sending user. The receiving account can have a large number of sending users, all submitting videos from many devices, without the sending users having knowledge of the access information for the endpoints. The endpoints at which a video is displayed or used is under control of the receiving account owner (the receiving user) and is not of concern for the sending user. The receiving user may add, change or remove endpoints at the receiving account (for example using a web interface), without the need to notify the sending user. The receiving user receives videos that match their branding rules, and transmits those videos to their endpoints, without managing that process manually themselves.

[0048] The account may add or remove sending users at will (for example using a web interface), without the concern of security risk from endpoint exposing access information. The account may impose brand usage rules and video processing rules to any video created for the account on any device added by any sending user, without having to track or police brand asset usage themselves. The account can manage copyright ownership of submitted video content from any sending user.

[0049] Conversely, the sending user can be a sending user of many accounts, and submit videos to various receiving accounts and their respective endpoints, without having to obtain the access information for those endpoints or manually prepare the video files for those endpoints' specific requirements. The sending user is not required to manage the correct brand usage, file settings (such as file compression settings), or display settings (such as width and height of the video, high definition or standard definition format, sound levels or "no sound" levels, etc) on videos for each account. The system 100 will prepare each video to match the receiving account's branding rules, and submit each video to the account's endpoints. The sending user's time and effort spent preparing their video and achieving the result of sending it to the account's endpoints is drastically reduced. An example of this is a video production agency with multiple clients, where the agency can simply and easily submit videos to multiple clients' social media profiles, without having to format each video for each social media profile or handle the upload to each profile themselves. The system 100 can manage the multiple clients' endpoints and the submission of videos to all those endpoints. The clients benefit by not having to share their login information with the agency, removing a layer of security risk and eliminating that step in the workflow.

[0050] Most videos require some processing to prepare them for sending to various endpoints, and to prepare them according to the requirements of the receiving account. The receiving account owner may choose to allow the use of processing engine A 104 in order to save time and expense by distributing the processing load from a central location (such as a server configured to process the files), to each user's device performing this processing. An example scenario is the Account has 1000 users, who all submit a video file to the Account simultaneously. Rather than have a central computer (such as a server) perform 1000 processing tasks, the Account can be configured to have the 1000 processing tasks performed on each user's device, so that each of the 1000 devices performs just 1 processing task, and the central computer does not have to perform these tasks at all. This increases performance and speed of the overall process by 1000 times.

[0051 ] Processing engine A 104 may process the video file to achieve certain file compression settings, display settings (such as width and height of the video, high definition or standard definition format, sound levels or "no sound" levels, etc), according to the requirements of the receiving account rules.

[0052] Processing engine A 104 may process the video file to apply the receiving account's brand assets and brand usage rules to the video. Brand assets may include, for example, a logo, trademarked sounds, animation, and any other visual, audio or technical feature that the receiving account owner considers to be a part of their brand. Such items are usually copyrighted, and some are trademarked.

[0053] A receiving account may be configured to allow the use of processing engine A on any device, and for any sending user. However, the receiving account may be configured to only allow the use of processing engine A 104 for certain users and not for other users.

[0054] A receiving account may be configured to allow the use of processing engine A 104 only if there is a "secure environment" on the device which prevents

unauthorised usage of the brand assets, prevents unauthorised access to the brand asset files, and prevents videos that have been processed from being sent to unauthorised destinations or endpoints. An example of a "secure environment" on a device is a software application that protects and prevents access to the files (brand asset files and processed video file), such as for example, a mobile app where the mobile device file storage system is not normally accessible by the user and the mobile app limits the destination endpoints that the device user may save or transmit the resultant video file to.

[0055] Some receiving accounts may be configured to prevent a user from saving the processed video on their device, and only allow a processed video to be sent to the receiving account on the system 100, possibly deleting the processed file from the device after transmission, so that no copies of videos containing their brand assets are stored outside of a secure system.

[0056] FIG. 2 illustrates one embodiment of the rules module 106. The rules module 106 receives a request from a device 102 to connect a sending user to a receiving user's account. The rules module 106 looks up information about the account, the user, the brand assets and brand rules for the account, the copyright ownership configuration for this account, rules concerning different types of devices, video file settings (for example, width and height of the video display dimensions, sound volume levels, high definition format or standard definition format, etc), and any other relevant settings.The rules module 106 delivers a set of rules to the device.

[0057] The rules module 106 may transmit brand asset files to the device 102 for use in processing engine A 104, or enforce the removal of existing brand asset files from the device 102. In one embodiment, the rules are enforced through a software application on the device, for example. The rules may change the sending user's video (for example, by adding content to it such as a logo animation or a

trademarked sound, compressing the video file, or re-sizing the video's display dimensions), and enforce a copyright ownership agreement, according to the needs and preferences of the receiving user's account.

[0058] The rules module 106 includes an account module 202, an account database 210, a user module 204, a user database 212, a copyright module 206, a copyright database 214, a brand module 208, a brand file storage 216, and a brand database 218. The account module 202 communicatively couples with the account database 210 and the user module 304. The user module 204 also communicatively couples with the user database 212 and the copyright module 206. The copyright module 206 also communicatively couples with the copyright database 214 and the brand module 208. The brand module 208 also communicatively couples with the brand file storage 216 and the brand database 218.

[0059] The account module 202 obtains account data from the account database 210. The sending user may identify the account they wish to connect to by any of a number of unique identifiers, such as an official business name (for example, "Google"), a unique job title (for example, "President of the USA"), a unique website address (for example "uniquewebsite.com"), an email address, a unique combination of text characters (for example "MyUniqueAccountName", a phone number, or some other unique identifier. Receiving users can define these identifiers for their receiving account, and send these definitions to the rules module 106 which stores them in the account database 210. These account definitions and other settings can be defined, for example, using a web based interface that communicates with the rules module. The users may define preferences for their account relating to who owns copyright of the video content sent to their account. Users may define brand usage rules, such as quality control roles relating to their brand and whether they restrict the storage and processing of their brand files in videos on certain kinds of devices or in certain software applications. Users may upload brand files to their account which are stored in the brand file storage 216. Users may define video file settings (for example, width and height of the video display dimensions, sound volume levels, high definition format or standard definition format, etc) which define how video files must be formatted before being sent to various endpoints 114.

[0060] A user can restrict the account to receive content only from certain users, or they can receive content from all users. A user may also block other individual users from sending content to their account, through a custom approval or blocking process. [0061 ] The user module 204 obtains user data from the user database 212. Each user may be connected to multiple accounts, and have different permissions and rules applied to them for different accounts or different devices that they use. The user module 204 delivers data corresponding to the user's relationship to the receiving account.

[0062] The copyright module 202 obtains copyright data from the copyright database 210. The copyright module 202 also stores copyright agreements between each sending user and receiving account in the copyright database 210.

[0063] The copyright module performs 2 main functions (though is not limited to these functions alone):

(i) Store a record of the receiving account's default setting for copyright ownership of content submitted by any user to the receiving account. The default setting is that the account owner will own the copyright of any content submitted to the receiving account. The default setting could be changed to have all sending users retain copyright ownership for their content, or a 3rd party (such as a parent company) could receive copyright ownership for that content.

(ii) Each user who joins the receiving account agrees to the terms of who receives copyright ownership, as part of the terms of joining the account. The copyright module stores a record of this agreement at the time when the user connects to the account.

(iii) Users who do not agree, may not send content to the receiving account.

(iv) Each individual agreement between the receiving account owner and a sending user may be modified, for example by using a web interface. The user may arrange with the receiving account owner to override the default setting, and retain copyright ownership of their content when submitted to the account or some other custom agreement. This custom copyright ownership setting could be set on a case by case basis with each user, or with each piece of submitted content, if so desired. (v) The copyright module applies the agreed copyright terms to each piece of submitted content, and stores a record of the copyright ownership of that submitted content.

(vi) Users can make changes to the stored copyright ownership agreements of any piece of content at any time, if agreed between all relevant parties involved, for example by using a web interface.

[0064] The brand module 208 obtains brand data from the brand database 218. The brand module 208 also stores brand asset files in a brand file storage 216. An account owner may choose to configure their account such that all video content submitted to the account be processed in a way such that the account's brand is displayed as part of the video. For example, the account owner may create a rule (for example, using a web interface) such that the account's logo must always be displayed at the start of every video submitted to the account. The logo would be an image file or video file, and would be stored in brand file storage 216. The rule would be stored in brand database 218. The brand module 208 would enforce the rule when a user wishes to send a video to the receiving account.

[0065] If the receiving account is configured to allow the use of processing engine A 104, then the rules module 106 may copy the receiving account's brand asset files from the brand file storage 216 to the sending user's device 102, and those files will be stored on the user's device 102 for future usage and processing according to the receiving account's rules. The rules may allow the user to process the video on their device using the stored brand asset files, such that the brand assets are added to their video on their device, using processing engine A 104.

[0066] If the receiving account does not allow their brand assets to be copied to user devices, then the sending user will submit their video with no brand assets applied to it, and the brand assets will be applied on the server in a secure environment at processing engine B 302.

[0067] FIG. 3 illustrates one embodiment of the routing engine 108 in the system of FIG. 1 . The routing engine 108 includes a processing engine B 302, a video file storage 304, a quality control module 306, a quality control database 312, an information module 308, an information database 314, an authentication module 310, and an authentication database 316.

[0068] The processing engine B 302 communicatively couples the video file storage 304. The video file storage 304 also communicatively couples with the quality control module 306. The quality control module also communicatively couples with the quality control database 312 and the information module 308. The information module 308 also communicatively couples with the information database 314 and the authentication module 310. The authentication module 310 also

communicatively couples with the authentication database 316.

[0069] Processing engine B 302 is not located on the user's device, and the user of the device has no ability to access the location of processing engine B. In one manifestation it could be located on a server where the device user has no access to that server except through the system's interfaces.

[0070] Processing engine B applies any receiving account rules to the received video that were not applied at processing engine A 104 on the sending user's device.

[0071 ] An example scenario is when the sending user's device is considered an "unsecure environment". An "unsecure environment" in this scenario is any device that allows the device user to easily access the brand asset files, such as storing the brand asset files in a computer's standard accessible filing system, rather than storing the files inside an application that protects and prevents access to the files.

[0072] An example of an "unsecure environment" on a device is for example a desktop computer, and the software application used to upload the video file to the routing engine 108 was a normal web browser. In this example, the browser and computer do not offer protection of files stored in the computer's file storage system, and those files are easily accessible by the sending user. The receiving account owner cannot prevent the device user from accessing the brand files independently, using the brand files in ways that do not accord with the account's brand rules, and possibly copying the brand assets or exploiting them. So in this example, the receiving user may configure their account to not allow the use of processing engine A 104, not transfer any brand files to the computer, and instead configure their rules such that the sending user transmits a video which is not processed to the routing engine 108, where processing engine B 302 will perform all necessary processing in a "secure environment".

[0073] If necessary, the receiving account's brand asset files are added to the video file during processing at processing engine B 302 in a similar way described for processing engine A above.

[0074] If the user submitted the video from a secure environment such as a software application where the brand assets where protected from unauthorised access (eg a mobile app), and the brand assets where already applied to the video according to the brand rules, then processing engine B 302 will not perform any further editing of the video to add the receiving account's brand assets.

[0075] Next, the received video file is transferred for storage to video file storage 304. The video file storage 304 is configured to store files based on copyright ownership. If the receiving account is configured to award copyright ownership of submitted videos to the account owner, then the video files are stored in a folder belonging to the account owner. If the account is configured to retain copyright ownership with the sending user, then the video files are stored in a folder belonging to the sending user.

[0076] The quality control module 306 analyses the content of the video. It filters the content for audio quality, visual quality, offensiveness and any other negative attribute that could cause a negative consequence for the account owner if this video was made public. The analysis can be performed programmatically (for example using a programming function to check for moments in the video where the audio levels are too loud, or a face recognition function to check for human faces if the account requires all videos to show a human talking, a speech recognition program to check for offensive words in speech from the video's audio stream). The analysis can also be performed by a human (such as a member of the account whose membership is configured to allow them to review other users' videos). Videos that fail to meet the criteria set in the rules of the receiving account can be rejected and/ or deleted and prevented from being made public. [0077] The information module 308 prepares data for each of the receiving account's end-points according to the requirements of the end-point, and prioritises the sending to each end-point. The information module 308 may set a date and/or time for transmission to the end-point (for example, if the user wants to send only one video per week to Youtube, and has already sent one this week). It may also set rules for a transmission to one end-point to wait on the successful outcome of transmission to another end-point, if one end-point is dependent on another. The information for each end-point can be added programmatically using default settings stored in the information database 314, or it can be added manually by a human (such as a member of the account whose membership is configured to allow them to add text content to other users' videos) and that manually-entered data may be stored in the information database 314.

[0078] Examples of the information module 308 performance might be: i) A Youtube end-point requires a video file, text title, category name, and an optional text description. It is not dependent on any other end-points, and so it can be sent immediately. ii) A Linkedin end-point requires a text message and a compulsory link to a Youtube URL. Thus, this end-point is dependent on another end-point being completed first - the Youtube endpoint from (i).

[0079] The information module 308 will obtain the required data for the Youtube endpoint, attach the data to the transmission, set a rule to wait for the successful transmission to the Youtube end-point, obtain the Youtube URL from that

transmission, then set that Youtube URL as part of the data for the transmission to the Linkedin end-point.

[0080] Next, the authentication module 310 retrieves the authentication data for the receiving account's end-points from the authentication database 316, and attaches the appropriate authentication data for each end-point to the transmission data for the end-point. The receiving account owner may add, edit or remove the

authentication records for various end-points, for example by using a web interface. [0081 ] The authentication module provides a way to allow multiple users to submit videos to a receiving account's end-points on 3rd party platforms, without revealing the authentication information (login information or API access tokens) of those end- points to any of the users. The invention advantageously allows the receiving account to receive videos from a wide variety of sending users (known and unknown), manage the copyright ownership of the received videos, enforce brand consistency and display guidelines, and send those videos to many public display locations on the internet, without posing a security risk to the receiving account by exposing login information or ambiguous copyright ownership of those publicly displayed videos (particularly in cases where the sending users are previously unknown to the receiving account owner).

[0082] Next, the routing engine 108 sends the video and transmission data to the appropriate transmission engines 110, which will transmit the video and data to the appropriate end-points 114. A single video may be sent to multiple end-points, which means a video may be routed to multiple transmission engines. Since the

information module 308 may have set a date and/or time for transmission to the end- point, or it may have set rules for a transmission to one end-point to wait on the successful outcome of transmission to another end-point, then the transmission engines 110 control when a transmission is made to the end-point, and the engines may include queues to delay the transmissions accordingly.

[0083] If the end-point requires authentication (for example, if the end-point is a 3rd party service such as Youtube that is accessed via an API web service and requires authentication before it will receive the video transmitted by the transmission engine 110), then the transmission engine 110 uses the authentication data provided by the routing engine 108 from the authentication module 310 to connect to the end-point 114.

[0084] The web transmission engine 11 OA sends the video and data to a web interface so that the video is publicly viewable by any person using a standard web browser. The web transmission engine stores video data in a end-point data storage 112 that the public can access if the video is defined by the receiving account as publicly viewable. [0085] Additionally, an Application Program Interface (API) 114B can access the video data storage 112 to retrieve video data, and then use that data to perform any action allowed by the account rules configuration, such as displaying the video to a public or private audience (through a web browser or some other application), process the video file using an independent external system, store the video file and data at another data storage location independent and external to the system 100, and transmit the video and data to further destinations.

[0086] In one embodiment an API can be used to send video files and data from a device 102 to the routing engine 108, or retrieve video data from the endpoint data storage 112. API functions are provided by the routing engine 108. Applications, for example with specialized graphical interfaces, can be developed using the API for interacting with the routing engine. Some API functions may require authentication, for example to ensure that a user is sending or retrieving data that only that user is permitted to send or retrieve.

[0087] The following are examples of API functions, in one embodiment:

account— Returns the rules about an account (copyright ownership rules, brand usage rules, video file settings, etc) from the rules module 106;

upload— send a new video to the routing engine 108;

send— send a video that is already stored on the system 100 to the transmission engine 110 and endpoints 114;

show— Returns a single video and its accompanying data, specified by an

identification parameter;

update— change information or data relating to a video in the endpoint data storage 112

[0088] The "external service" transmission engine 110C sends video files and data to a service independent of and external to the system 100. Examples of

independent and external services are Youtube, Twitter, Facebook and other services not part of the system 100 that allow the system 100 to connect to them and transmit data to them. The transmission engine 110C will send the video and data in a format that matches the required format of the external service endpoint 114C. [0089] The e-mail transmission engine 110D sends messages via SMTP (simple mail transfer protocol) (or any other appropriate electronic mail protocol) to an appropriate destination e-mail server. The e-mail transmission engine 110D also can be configured to function with, for example, a messaging application programming interface (MAPI).

[0090] The invention also provides a way for the account owner to manage copyright ownership, branding consistency, quality control, and content guidelines for videos submitted to their account, in a programmatic way across all the users (known and unknown) and all devices connected to their account.

[0091 ] Some portions of above description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof.

[0092] As used herein any reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

[0093] Some embodiments may be described using the expression "coupled" and "connected" along with their derivatives. It should be understood that these terms are not intended as synonyms for each other. For example, some embodiments may be described using the term "connected" to indicate that two or more elements are in direct physical or electrical contact with each other. In another example, some embodiments may be described using the term "coupled" to indicate that two or more elements are in direct physical or electrical contact. The term "coupled," however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.

[0094] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having" or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive or and not to an exclusive or. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present).

[0095] In addition, use of the "a" or "an" are employed to describe elements and components of the embodiments herein. This is done merely for convenience and to give a general sense of the invention. This description should be read to include one or at least one and the singular also includes the plural unless it is obvious that it is meant otherwise.

[0096] Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for a device independent communications platform. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosure is not limited to the precise construction and components disclosed herein and that various modifications, changes and variations which will be apparent to those skilled in the art may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope as defined in the appended claims.

CITATION LIST PATENT LITERATURE

Patent US6711622 - Video and audio streaming for multiple users

Patent US20140013230 - Interactive video response platform

Patent US20070038636 - Video resume internet system

Patent US7987492 - Sharing a streaming video

Patent WO2013131189A1 - Cloud-based video analytics with post-processing at the video source-end

Patent US20120213275 - Scalable video coding and devices performing the scalable video coding

Patent US9100461 - Automatically publishing streams to multiple destinations

Patent US20140376623 - Distributed Encoding of a Video Stream

Patent US20150195321 - Providing control information to a multimedia server

Patent US9135412 - Token-based security for remote resources

Patent US9106887 - Adjusting encoding parameters at a mobile device based on a change in available network bandwidth

Patent US7352953 - Method and apparatus for recording and storing video information

Patent US20030093790 - Audio and video program recording, editing and playback systems using metadata

Patent US20100088394 - Multipoint publishing

Patent US20130145388 - System and method for applying a database to video multimedia

Patent US20080178234 - Video sharing platform providing for posting content to other websites

Patent US20070101387 - Media Sharing And Authoring On The Web

Patent US6888477 - Distributed on-demand media transcoding system and method Patent US7627892 - Multiple methods for transacting, publishing and purchasing copyrighted digital content

Patent WO2005124642A1 - User software for facilitating copyright licensing and compliance

Patent WO2010044819A1 - Copyright database management and reporting system Patent US8401009 - Device independent message distribution platform

Patent US5706211 - Message communications system

Patent US5745692 - Automated systems administration of remote computer servers Patent US6226668 - Method and apparatus for web messaging

Patent US9137530 - Video communication method and system for dynamically modifying video encoding

Patent US8508569 - Video communication method and system

Patent US20140267578 - Video injection for video communication

Patent US5689800 - Video feedback for reducing data rate or increasing quality in a video processing system

Patent US20100019989 - Display system, display method, information processing apparatus, and computer-readable storage medium

Patent US20100333004 - Method, apparatus and system for modifying a composite video signal

Patent CN1599453A - Method for dynamic regulating video transmission

Patent CN1906949A - System and method for the dynamic resolution change for video encoding

Patent CN1969558A - Method and apparatus for video encoding optimization Patent US7987492 - Sharing a streaming video

Patent US8594655 - Remote activation of video share on mobile devices

Patent US20080256583 - Method and system for sharing video over a network

Patent WO2015094237 A 1 - Sharing video in a cloud video service

Patent US20040054665 - Apparatus for sharing and storing mass video data in video geographic information system and management method thereof

Patent US8997167 - Live streaming video sharing system and related methods

Patent US8856961 - Processing copyright notice of media file

Patent EP2120172A1 - Method and system for legally sharing copyright-protected digital contents

NON-PATENT LITERATURE www.OneLoad.com - an online software platform for uploading, distributing videos to multiple social destinations. This solution focuses on sending the video file to end- points, with no multiple user scenario, no brand management or copyright

management. www.Hootsuite.com - an online solution that allows a company to have a team of authorised users (employees and clients) that are allowed to post content to multiple social media accounts, with some monitoring of content posted to end-points in order to provide a type of quality control over the posted content, however this monitoring takes place after content is publicly visible at the end-point and potentially damaging to a company's reputation and brand. www.Videolicious.com - a solution for Enterprise companies to allow employees to make videos using their brand asset files on the employees' mobile devices, and save the branded video to the device, then send the branded video manually to any end-point (eg, manually upload the video to a Youtube account), including unknown and unauthorised end-points such as exporting the video file from the mobile device to any computer and then transferring the video file to a USB portable storage device, or uploading the video file to a non-authorised Youtube account belonging to another company or person not affiliated with the owner of the brand assets, or emailing the video file to any person or any email address.

Claims

1 . A method for device-independent, point to multipoint video brand

management, copyright management and transmission system, the method comprising: receiving from a first computing device of a first user a selection of one or more endpoints for receiving videos from the first user; receiving, from the first computing device, authentication information to enable authenticated connection to those endpoints requiring authentication; receiving, from the first computing device, textual information according to the requirements of each endpoint; receiving, from the first computing device, data files such as video, sound and image files, that when added to other video content displays the first user's public brand as part of that video content; receiving, from the first computing device, selections which comprise a set of rules describing how the first user wishes their brand files to be added to video content; receiving, from the first computing device, a selection describing whether the first user allows a second user to store the first user's brand files on the computing device of the second user; receiving, from the first computing device, a selection describing whether the first user allows the second user to add the first user's brand files to video content, where the addition of the brand files to the video content is performed by the second user's computing device; receiving, from the first computing device, a selection defining who will own the copyright of the video content transmitted from the second user to the first user; receiving, from a computing device of the second user, a request to transmit video data and information to the first user, wherein the information contains identification of the first user as an intended recipient, and wherein the information includes an identification of the second user as a sender of the information; identifying, by the computer processor, in response to the transmission request, the rules of the first user for receiving video content from the second user; determining whether the first user allows the second user to transmit the video information to the first user; determining whether the first user allows the second user to store their brand files on the computing device of the second user; determining whether the first user allows the second user to add the first user's brand files to video content, where the addition of the brand files to the video content is performed by the second user's computing device; determining whether the copyright of the video content will be owned by the first user or second user, if the second user transmits the video content to the first user; displaying, on the second user's computing device, a proposal about whether the copyright of video content submitted to the first user will be owned by the first user or the second user; receiving, from the second user's computing device, an agreement to the copyright ownership proposal displayed on the second user's computing device in the previous step; recording, by the computer processor, in response to the agreement received, the agreement of the second user to the rules of the first user in relation to sending video content to the first user; transmitting, to the second user's computing device, according to the rules of the first user, the files and information necessary for the second user to create video content for the purpose of sending that video content to the first user; controlling, on the second user's computing device, according to the rules of the first user, access to the files and information necessary for the second user to create video content for the purpose of sending that video content to the first user; controlling, on the second user's computing device, according to the rules of the first user, usage of the files and information necessary for the second user to create video content for the purpose of sending that video content to the first user; processing, on the second user's computing device, according to the rules of the first user, the video content created by the second user in a way that matches the display requirements of the first user; receiving, from the computing device of the second user, a transmission of video data and information to the first user, wherein the information contains identification of the first user as an intended recipient, and wherein the information includes an identification of the second user as a sender of the information; processing, on the computer processor, according to the rules of the first user, the video content created by the second user in a way that matches the display requirements of the first user, if the video content does not already match the requirements; applying, for each of the endpoints, textual information to the video information based on the endpoint requirements; applying, for each of the endpoints, authentication information to the video information based on the endpoint requirements; formatting the video file and information into an appropriate format for each of the endpoints; and transmitting the video file and information to each of the endpoints in the

appropriate format.

2. The method of claim 1 , wherein the sending user does not have a previous relationship with the receiving user.

3. The method of claim 1 , wherein the receiving user's stored information comprises display preferences of the receiving user, wherein the display preferences affect the video content sent by a sending user to the receiving user, and cause the video content to be rejected if it does not match the display preferences of the receiving user.

4. The method of claim 1 , wherein the sending user and the receiving user form an automated agreement to transfer copyright of their video content from the sending user to the receiving user, before the sending user sends the video to the receiving user, and the agreement is stored electronically.

5. The method of claim 1 , wherein the sending user does not specify an endpoint, and the endpoint is specified by the receiving user from a plurality of endpoints.

6. The method of claim 1 , wherein transmitting the video file and information to the endpoint comprises first transmitting the file and information to one endpoint, receiving data from that endpoint in response, then attaching that data to the video file and information transmitted to another endpoint.

7. The method of claim 1 , wherein broadcasting the video file to an endpoint comprises:

generating a web page which displays a video player that can play the video file such that the video content is shown to a human observer; and

transmitting a uniform resource locator of the web page to one of the endpoints.

8. The method of claim 1 , wherein broadcasting the video file to an endpoint comprises generating machine-readable code in response to an API call such that a server can process the generated code to obtain information about the video file, and can then perform various actions, for example in one embodiment the server may display a video player that can play the video file such that the video content is shown to a human observer.

9. The method of claim 1 , further comprising: receiving an indication of a certain date and time when the receiving user prefers to send a received video file to an endpoint, wherein the video file and its accompanying information is broadcast to the endpoint at that date and time.